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
- Articulation Body with 'Revolute' Joint Type has erratic behavior when Upper Limit is set to above 360
- WebGL Player fails to render Scene when Terrain with Detail Mesh is added and WebGPU Graphics API is used
- Inconsistent errors are logged when different types are passed into the Query "Q<>" method in UIToolkit and the ancestor VisualElement is null
- Crash on GetMaterialPropertyByIndex when opening a specific Scene
- Discrepancies in the styling are present when using a TSS file instead of a USS file in custom EditorWindow
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;