Sign in to follow this  

Storing Objects(entities), How should you access it? World or local?

This topic is 4559 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Well Im in the midst of rewriting large parts of my engine now that I have a much better idea on how things run. So now im rewriting my ObjectManager. Im used to storing my object's verticies by every single one and where it ACTUALLY exists in the world(world coords). Well say I have 5 of the same object? Is the best way to solve this, is to save the object's verts as local coords(object coords) instead of world coords? Then have a matrix or so that contains its rotations and translations, and just multiply that against the current matricies? Then have the calculations done inside of the shaders? This way I can just set the vertex and index buffer and just render multiple times? Or should I just store real world coords for every object(entity)? Of course this takes up alot more space.. So basically Im looking for whats best here? Pros and Cons? How you all do it and why? Thanks much, Brad

Share this post


Link to post
Share on other sites
Yes, you ideally want two classes.

One class represents the mesh as loaded from disk, stored in local coordiantes, this I call a 'Mesh'. This contains vertices and indices. It also has a model space AABB.

The next class is an instance of the mesh, which I call 'MeshInstance', which refers to the 'Mesh' object, and has a 'Space' Object, which contains a location, a rotation, and a scaling. You can ask a meshinstance for its localtoworld or worldtolocal transform, and it will calculate it from these values.

You can also ask for an AABB, and it will transform the model space AABB from its Mesh into world space, and then take those extents as the world space AABB.

You only have to load the Mesh once, and can have many instances. The vertices and indices are only stored once. Also, the MeshInstance will probably have its own material info, so you can have two of the same geometry, with different textures & shaders applied.

Share this post


Link to post
Share on other sites
This is almost exactly what I wanted to do. What all updates do you have to pass for dynamic objects every frame? Because your view matrix isnt changing, and your local matrix isnt changing... you just pass in the new rotation, translation, and scale values? Or just as one 4x4 matrix?

Share this post


Link to post
Share on other sites
I don't store a composite matrix or world AABox at all. They are computed as needed. Until it shows up in the profile as a problem, you really don't want duplicate data, because it's so easy to get out of sync.

When I need to, I just call Object::Space::GetWorldBounds() or Object::Space::GetWorldToLocalMatrix() or Object::Space::GetLocalToWorldMatrix().


Share this post


Link to post
Share on other sites
Ok, but you do store rotations and translation right? As seperates then? This is underneath yer object(entity) class, not mesh class. Im just wondering what would be quicker at this point for gaining info about the object, out of a matrix stored in the object or out of the held rotations and translation values stored in the object. And which would be less space and/or any difference. Not a big deal I can run tests on each with alot of objects, but some people may find certain ways to be easier to deal with, some which are faster, size differences, or all of the above :).

Thanks for the help.

Btw, I didnt mean to store the world matrix under each object, I meant store how the object should react that is different from the local coords held on the shared mesh.

Share this post


Link to post
Share on other sites
Well I have a quadtree that acts as my graph essentially, if i have my lingo right. It controls where is everything and what needs rendered as far as lights/objects and what not is available. Ill read that article though and see what new pops up.

Share this post


Link to post
Share on other sites

This topic is 4559 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this