Search Issue Tracker
By Design
Votes
4
Found in
2017.1.0f3
Issue ID
946887
Regression
No
Bounds provided in additionalVertexStreams never get used when modifying Vertex data
1. Open the attached "BoundsProject" and "Main" scene
2. Open the "Expand" script, notice that the Mesh Vertex data (along with its Bounds) is modified with additionalVertexStreams
3. Enter Playmode, observe the Sphere moving horizontally, narrow down your Game view so the Sphere would go off-screen
4. Look at the Sphere as it approaches the edge of the Game view, use Step button to see the behaviour more clearly
Actual result - As the Sphere approaches the edge of the screen, it disappears before it goes entirely off screen, the Bounds provided in additionalVertexStreams never get used
Expected result - Bounds provided in additionalVertexStreams are used and the Sphere is culled correctly
Reproducible with - 5.6.3p3, 2017.1.1p1, 2017.2.0b11, 2017.3.0a7, 2019.1.0b10
Note - Click on the "GameObject" in Hierarchy to see the Gizmo off its Bounds
-
Jovssen
Sep 12, 2019 20:41
I don't see why it has to be by design, there isn't a disadvantage to doing it the other way.
It's the MeshRenderer which has these vertexstreams, and it's the meshrenderer which is used in culling (therefore using the bounds).The other solution would be to give the ability to change a MeshRenderer's bounds (set, not only get), but that wouldn't be as elegant because the bounds should really only change when the vertexstreams have changed the vertices, therefore a new bounds should belong inside the vertexstreams.
This excuse of "by design" boils down to "originally we hadn't considered such a use-case, and therefore didn't care about supporting it, so now we still won't".
I haven't encountered a barrier stopping me from placing my own bounds inside the additionalvertexstreams mesh, it just doesn't work. This goes against the entire fool-proof and careful philosophy of unity.
Bounds are intrinsically linked to vertex positions, which CAN be changed by the vertexstreams mesh. -
Rodolphito
Oct 08, 2017 22:56
I have the same mesh on tons of different objects, all being resized quite a bit using additional vertex streams without copying the triangles or uvs, the 'workaround' would imply copying the mesh triangles and uvs loads of times and not using additionalvertexstreams, instead just overwriting the MeshFilter.sharedMesh, which would incur lots more memory overhead than what is necessary. I really need this fix... my objects always disappear if the origin of the world is not in view...
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
- Crash when trying to force Shader to interpret 1/30 as a floating point operation
- Terrain is flickering when adjusting "Compatibility Mode" and "Use Rendering Layers" Settings
- Isometric tiles are flickering and overlapping each other when entering Play Mode with Tilemap Renderer mode set to "Chunk"
- Crash on ParticleSystemParticles::array_reserve when particle system starts
- Docking Text Property Preview Window next to UI Builder breaks the window and causes NullReferenceException
Resolution Note:
By-design because vertex stream are data that will be feed into shaders, i.e. vertex postiion, normal, texcoord, color, tangent. Mesh bounds are not a part of vertex stream so the bound data wouldn't be applied to the original mesh.
User can do this to make sure the "new mesh" has correct bounds:
meshFilter.sharedMesh.bounds = additionalVertexStream.bounds;