Sorry, that was too good to pass up. No, I''m not going to ask the stupid question that''s been asked so often a sticky ended up being made. I''m going to ask a question about 3D. You may all put the torches and pointy objects down now. What is the best way to store a series of triangles or quads in a file? I''m trying to keep track of the most things I can, but I don''t want to have 3-4 meg maps by the time I''m through. So far I''m storing the texture ID of the polygon, texture coordinates (to stretch and tile stuff), the XYZ coordinates of each point, and the RGBA color (so I can have, say, a blue house or a red house with the same texture, as well as having alpha transparency too; this is with glColor, btw). This is for every polygon. Surely, there''s a better way to do this? It also seems as though I''ll be chewing up a lot of overhead by switching textures and seeting new colors every polygon... Any suggestions on how to make it run as smooth as possible? (I''m rather new to this domaine, if you can''t tell. )

quote:Original post by RuneLancer
So far I''m storing the texture ID of the polygon, texture coordinates (to stretch and tile stuff), the XYZ coordinates of each point, and the RGBA color.

I hope you realise that the texture id you use to bind a texture is different each time your application runs. You''ll need to reference the actual texure filename and somehow associate that with your texture id.

quote:I''ll be chewing up a lot of overhead by switching textures and seeting new colors every polygon... Any suggestions on how to make it run as smooth as possible? (I''m rather new to this domaine, if you can''t tell. )

Per-poly (or even per vertex) colours are not a problem - you can just bung them in an array running parallel with your vertex positions and it''ll work fine. Per-poly textures however is another matter. You should batch your triangles by surface properties (particularly textures and material settings) so you end up drawing all polys with a texture at once.

Whether you group your polys at load time or when you actually save them to disk is another matter. If you''ve got things like characters and objects odds are you''ll only have a single texture per object. For things like levels you''ll probably have textures spread all over the place and it might be easier to group them into batches just before rendering (after figuring out whats visible).

By texture ID, I don''t mean OpenGL''s texture ID, but rather the in-game ID I use to refer to the various textures I''ll have loaded in memory.

So I should group stuff by property? That gives me a few ideas...

I could group by texture, and then in every texture group, group by color. Since I will probably be using the same color (1.0f 1.0f 1.0f) for most of the polygons, I''d have large chunks I could group together. Or an other option would be to have a flag stating wether I want to change the colors or not, and if this flag is on I''d have an extra set of data for the colors. Otherwise, I''d use 1.0f 1.0f 1.0f by default.

That would mean loading stuff sequentially instead of just memcpy''ing right into my array, but load-time is where the player expects a few seconds of delay anyways. And, really, loading a few hundred kilobytes of data sequentially takes, what, a few seconds at most?

I''ll try that. I''m still mostly thinking in 2D, where tiles have to be in the same order that they''ll be displayed since they''d be blitted in a for loop that covers the map''s X/Y area. With polygons, it doesn''t matter. So I guess proper organization of my vertices could help reduce redundant data in my map files...

quote:Original post by RuneLancer
Or an other option would be to have a flag stating wether I want to change the colors or not, and if this flag is on I''d have an extra set of data for the colors. Otherwise, I''d use 1.0f 1.0f 1.0f by default.

My gut feeling is that would be the better choice. You''ve effectivly got an optional set of vertex colours that way, and the case where you have a single non-white colour for a group of polys is unlikely.

quote:That would mean loading stuff sequentially instead of just memcpy''ing right into my array, but load-time is where the player expects a few seconds of delay anyways. And, really, loading a few hundred kilobytes of data sequentially takes, what, a few seconds at most?

Load & save time is effectivly ''free'' (within reason) so if you can save runtime speed and/or memory by a slightly more complex load mechanism thats a good trade off.

quote:I''ll try that. I''m still mostly thinking in 2D, where tiles have to be in the same order that they''ll be displayed since they''d be blitted in a for loop that covers the map''s X/Y area.

I find the easiest way of thinking about this is to have some sort of abstract renderer layer inbetween the drawing code and OpenGL. That way you can do something simple (like an x/y loop over visible tiles and draw each in order) which looks like regular blitting. But what your renderer is actually doing is not drawing them directly but putting them into groups ready for a final, optimally sorted, drawing bit just before you swap your display buffers.