Skip to main content
gamedev.net
🔒 Locked

Polygon Sorting

Started by SirCyr 1 reply 350+ views
Original Post
SirCyr
SirCyr
Hello there! Im SirCyr, long time reader first time poster... I''m designing a 3D engine to be used in a space shooter game using OpenGl. I was thinking about how I will render my object list and I came up with the following thoughts or question: -> Each object polygons would be only stored once in the graphic engine and located at the origin. So if I want to have two spaceships that use the same model, I would use two "handles" that would bind a different texture and position. -> My meshes would be stored in a database that would be sorted in a shader tree(As suggested on the Delphi3D site lately) to eliminate state changes as much as I can. Should I build that tree only once? or at each frame for the polygon that are visible...And, if the same mesh, at a given node, is used by more than one model. Does it means that I can''t render them only by one call to OpenGl since I have to transform that mesh two times...Ideally I would like to make only one render call for all the meshes that shares the same texture settings...Do you have some ideas how to acheive that? thansk!
Gabhonga
Gabhonga
You''ve just gave correct answer to yourself :-)
it''s an interesting thing to discuss about, anyways, I''m just designing an engine, but a software rendering one, so I don''t know much about how to do things with OpenGL and if they''re suitable for HW rendering, well, I''ll give it a shot:
let pointers be your friend :-)
of course you can "recycle" the u/v data and such, I do it in my engine in the following way:
first I check every object and clip/cull everything if needed...the seen polys would then be included into a single "renderway poly list" and the according vertices into a "renderway vertex list"...these are interchangably linked (each poly links to 3 vertices, each vertex to a linklist of polys linking to each poly "using" that vertex (I might exclude some unneeded linkings later for perfomance, but right now they''re quite handy during development and for debugging)...plus each poly has 3 links to u/v texture coordinates...each vertex in the list has it''s own shading info, as 2 fighters of the same model would of course be differently shaded when on screen at once (unless they''re at the same position, but that''s illogical and should be eliminated by collision detection (-: )...so this way it accesses a lot of the shared data via pointers, but I don''t actually know if this is really a good approach, for example the texture values are only 2 floats, assignment of them wouldn''t be very much slower then accessing them every time they''re used by a pointer...anyhow I''ll drop the some sharing soon, as I want to implement damage by changing textures/meshes...


muhuhahahahahaha!!!!!!!!
who cares about signatures, anyway....
muhuhahahahahaha!!!!!!!!who cares about signatures, anyway....
SirCyr
SirCyr
Will your software engine be used for a game? It''s nice to see that there is still people interested in it.

Also,

I was thinking about object animation. If I want to animate the model using morphing beetwen key frames, I see two possibilities...

->The first would be to store only the key frames once. And at each frame, transform the model to the desired position...

or

->Use a separate model for each instance of a 3D object and remember the transformation if it is not needed to be transformed at a given frame.

The second one may be more appropriate if I dont need to animate the ship a lot. But I think I would prefer the first solution. As it could be implemented in hardware if present. And if done in software, it would not be that bad because its not complicated character animation. Only to give the ship a organical felling(for maybe some sort of Alien ship...)

But if it would be to have a damaged ship...maybe the second one would be better...

hummm would have to think about it.

What do you think?

:o)



Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.