Archived

This topic is now archived and is closed to further replies.

khirsah

Texture coords and non-static meshes

Recommended Posts

khirsah    122
Is there a nice way to handle submitting texture coords for meshes whose vertices are going to be changing dynamically? For example, texturing a cube properly requires duplicating vertices (so that different texture coords can be submitted for one vertex) but then you''d need to keep track of the duplicated vertices when moving them around. The only solution I can find is to draw things by hand using glBegin()/glEnd()...

Share this post


Link to post
Share on other sites
khirsah    122
If you duplicate vertices, that addresses rendering, but then how would you handle updating all the duplicated verts when one of them moves?

Share this post


Link to post
Share on other sites
python_regious    929
Well, if you''re using some sort of interpolative animation, then it''s not an issue, as all vertices will be moved, including the duplicates.

Other than that, you must have some sort of physical model that governs how all the vertices move, so again, it doesn''t become an issue because you''re applying the model to all of the vertices...

Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
khirsah    122
Yeah, the problem is that vertices can be updated depending on other vertices (this is for modeling softish objects like cloth or blobs). I guess your solution would work fine if all vertices were completely independent.

Oh well, might have to try a different approach.

Share this post


Link to post
Share on other sites
python_regious    929
Well, I take it you hold a data structure of connections between vertices. All you''d do is duplicate those connections for the duplicate vertex. That way it''d be updated exactly the same as the original.

Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
khirsah    122
Been trying to work that through, but I still don''t see how it would work... If you had two triangles connected at one (duplicated) vertex (like a *really* degenerate piece of cloth ), and collision detection finds that one triangle is caught on something such that the shared vertex is moved, you''d still have to search through the "connections" to update the duplicate.

Share this post


Link to post
Share on other sites
python_regious    929
Well the duplicate vertex would just become another vertex in the set, it''s just that it starts at exactly the same position, and has the same connections as another vertex ( so follows the same path ). You wouldn''t have to do any special case stuff.

Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
khirsah    122
But for collision you''d also need to duplicate the triangle, or you''d still have to special case for the duplicated point (since it might have the same connections/edges but wouldn''t move the same way because there''s no face to collide against). And if you duplicated the triangle, then you''d need to special case for rendering to avoid drawing triangles twice anyway. Besides, there''s no guarantee that the duplicated vertices will be updated in an order which always results in them following the same path (one duplicate could be updated, then a dependent neighbour, then the other duplicate), unless you made the whole thing parallel.

I''m sure this could be *made* to work, but originally I was just hoping there was some API facility for submitting vertices independently of texture coords and normals. For now I''ll be happy to just take the hit and draw things less efficiently.

Thanks for your help anyway.

Share this post


Link to post
Share on other sites