Texture coords and non-static meshes
Author
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()...
Vertex arrays + index arrays. Wonderful things.
Death of one is a tragedy, death of a million is just a statistic.
Death of one is a tragedy, death of a million is just a statistic.
Author
If you duplicate vertices, that addresses rendering, but then how would you handle updating all the duplicated verts when one of them moves?
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.
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.
Author
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.
Oh well, might have to try a different approach.
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.
Death of one is a tragedy, death of a million is just a statistic.
Author
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.
), 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.
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.
Death of one is a tragedy, death of a million is just a statistic.
Author
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
