Search Issue Tracker
By Design
Votes
0
Found in
5.3.5f1
Issue ID
813564
Regression
No
GetNativeTexturePtr() returns 0 on RenderTexture until colorBuffer property get is called
1. Open user attached project.
2. Play main scene.
3. Watch at console output.
It is coming from TestRenderTextureNativePtr script which is attached to GameObject.
Second line of output is value of renderTexture.GetNativeTexturePtr()
Fifth line of output is value of renderTexture.GetNativeTexturePtr() AFTER calling renderTexture.colorBuffer.ToString()
Expected behavior: GetNativeTexturePtr() value is always returned
Actual behavior: GetNativeTexutrePtr() value is returned only after getting colorBuffer property.
Comments (5)
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Performance drops significantly when many Tilemap modifications are made
- Help icons in the "Multiplayer Tools" window are poorly visible in the dark Unity theme
- Shadows are not present when using unity_SpriteColor and Alpha Clipping in Shader Graph
- [macOS] Secondary display rendering incorrect target and flickering when building for Multi-Display
- "Create Empty Child" Option Creates Root Object When No Parent Is Selected
ModLunar
Mar 03, 2024 04:17
UPDATE: From my testing, actually I didn't observe this issue in Unity 2021.3.30f1. Apologies for the anger, I had spent several weeks fighting native rendering crashing with not much guidance from the NativeRenderingPlugin example GitHub repo since they only read/write texture data in C++ on the CPU on OpenGL. Anyways, neither here nor there -- This maybe should be marked as solved instead, *not* by design!
ModLunar
Mar 02, 2024 23:51
How does stuff like this even get designed?? At least help fill us in with documentation.. I've been at it for weeks in OpenGL / C++ / Unity / C#, and getting RenderTextures to do anything useful at all in OpenGL has been harder than feeding 500 families... ridiculous
CyRaid
Feb 08, 2021 03:20
Wait how is this by design, when not even mentioned in the documentation? Why would referencing colorBuffer change the result of GetNativeTexturePtr()? If it's the case of not being ready, would an 'Update()' method suit better? And in the documentation state 0 means not ready yet? Or better yet, if it's not ready, automatically update or do what's necessary to actually get the native texture pointer?
mdrunk
May 28, 2020 20:34
still an issue in 2019.3. awesome.
wing6031
Jan 02, 2018 09:55
thx,you helped me to fixed the problem!