You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mesh::duplicate_vertices silently takes indices from the Mesh but doesn't mention it in the method documentation.
This lead to my code breaking because it relied upon indices being present. I added a call to duplicate_vertices and didn't realise my later code that did something for each index was now not running.
I assume not rebuilding the index data is an optimisation. Either way this behaviour should be documented or the code should rebuild the index data if it was previously present.
An alternative could be to have a function duplicate_vertices_without_indices (naming aside) that would have the current behaviour, and change duplicate_vertices to rebuild the index data before finishing. I'm thinking along the same lines as Vec::sort and Vec::sort_unstable, or Vec::remove and Vec::swap_remove having longer/different names for behaviours that have side effects the programmer should take note of.
The text was updated successfully, but these errors were encountered:
The way I see this function is:
It expands the vertices so that no vertex position is reused. Therefore no index appears twice in the index array and may only order the vertices. Now order the vertices array and you dont need the index data anymore.
This can obviously be better documented, but this side effect can be implied with some knowledge about the rasterization process. But - yes - as you have suggested, its only implicit.
I would argue expand_vertices, or even something like integrate_indices is a better name, though. There are probably even better ones.
How can Bevy's documentation be improved?
Mesh::duplicate_vertices
silently takesindices
from theMesh
but doesn't mention it in the method documentation.This lead to my code breaking because it relied upon indices being present. I added a call to
duplicate_vertices
and didn't realise my later code that did something for each index was now not running.I assume not rebuilding the index data is an optimisation. Either way this behaviour should be documented or the code should rebuild the index data if it was previously present.
An alternative could be to have a function
duplicate_vertices_without_indices
(naming aside) that would have the current behaviour, and changeduplicate_vertices
to rebuild the index data before finishing. I'm thinking along the same lines asVec::sort
andVec::sort_unstable
, orVec::remove
andVec::swap_remove
having longer/different names for behaviours that have side effects the programmer should take note of.The text was updated successfully, but these errors were encountered: