Model::SetBounds()

[SpiderPig]

If I'm not mistaken, Model::UpdateBounds() must loop through all vertices to calculate the extends of the mesh.  In some situations this is a waste of time as for my voxel terrain I know the extents of the mesh without looping through the vertices.  I therefore would like to save that little bit of time and just set the bounds of the mesh manually if possible?  Is this practical?

float size = 128.0f;

model->SetBounds(0.0f, 0.0f, 0.0f, size, size, size);

OR

Aabb = Aabb(0.0f, 0.0f, 0.0f, size, size, size);
aabb.Update();
model->SetBounds(aabb);

 

[Josh]

Do some tests to see how much mesh->UpdateBounds() takes. Use Microsecs() for best accuracy.

Optimization is good but you should only optimize things that are slow. If something is not taking any appreciable time in the first place, then optimizing it is not worthwhile.

[SpiderPig]

Yeah your right, I should've speed tested things first.  I just despise loops   In debug updating the bounds on a total of 700k vertices took 1760 us.  Release was like 30us.  I've also realised if the predicted size of my model hasn't changed between updates I don't need to even call UpdateBounds().

Will setting new mesh data to a model and not updating the bounds have any adverse effect in any way?  As far as I can tell it would either cull early or too late if the new vertex data is outside or too far inside the old bounds.

[Josh]

Mesh::Modify() already updates the bounds so there is no need to call it yourself. A much more intensive process is converting the vertex data into the format the GPU uses, which is more compressed than the vertex layout the user sees. However, this is all happening on the main thread, which gets up to 16 ms to execute before there is any problem, and your meshes should be updating in chunks of a limited size, so I think there's not much room for improvement here.

[SpiderPig]

Yeah I thought that might be the slowest part.  All good though.  I'll be making some pretty small chunks (16^3) verts max so I don't think this will be a problem.