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

Graphics - General

-

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

  1. 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;

Log in to vote on this issue

Comments (2)

  1. 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.

  2. 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

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.

Latest issues

See all new issues