Yea I'm back on the board after a long time, busy with school etc etc, anyways, I've started coding again on the engine i was working on some time ago but i got a dilemma now.
The world itself consist out of sectors so you only have to load the sector the player is on and its surrounding sectors in memory which saves a lot of mem and eliminates loading times because new sectors are loaded in a separate thread.
I came across some text about display lists, first thought to cross my mind was to make a list of every sector since the world itself is static so i can make a display list out of it which will decrease the time needed to display the world itself, but here comes the problem:
I need to do some Collision detection with the world offcourse (at least i assume its normal players walk ON the world and wont fall through it ;)) But this cant be done with the display list.
Should i just leave the idea of display lists and draw the world from mem every frame (disadvantage, slower code), should i combine both, so have a list to draw and the sector the player is on (not its surrounding sectors) for collision (disadvantage, more mem usage). Or is there some other solution for my problem?
Scorpie
The world itself consist out of sectors so you only have to load the sector the player is on and its surrounding sectors in memory which saves a lot of mem and eliminates loading times because new sectors are loaded in a separate thread.
I came across some text about display lists, first thought to cross my mind was to make a list of every sector since the world itself is static so i can make a display list out of it which will decrease the time needed to display the world itself, but here comes the problem:
I need to do some Collision detection with the world offcourse (at least i assume its normal players walk ON the world and wont fall through it ;)) But this cant be done with the display list.
Should i just leave the idea of display lists and draw the world from mem every frame (disadvantage, slower code), should i combine both, so have a list to draw and the sector the player is on (not its surrounding sectors) for collision (disadvantage, more mem usage). Or is there some other solution for my problem?
Scorpie
The problem with OpenGL is that you often can't *really* know what a GL call does.
For example, a display list could either be held in system memory, or it could be uploaded to cards that have hardware T&L. There's likely to be some ARB extensions dealing with vertex+index buffers, those might be a better choice over display lists.
For all mostly static objects (whether it be the world or game models), using display lists or other methods that lets the data stay in video card memory and not be transferred on each frame tends to be a good idea.
For example, a display list could either be held in system memory, or it could be uploaded to cards that have hardware T&L. There's likely to be some ARB extensions dealing with vertex+index buffers, those might be a better choice over display lists.
For all mostly static objects (whether it be the world or game models), using display lists or other methods that lets the data stay in video card memory and not be transferred on each frame tends to be a good idea.
I think the most important thing is to transfer all static stuff (textures, geometry) to the GPU. All today's GPUs have hwTnL, so use it!
the thing you mentioned I do like this: _all_ the geometry and textures are inside the video RAM. The geometry is sorted by textures and then by objects [ so: 1) you don't have to switch to a particular texture more than once; 2) groups of triangles form a ready-to-display obejct ]. with this, I do frustum culing on a sphere that would surround the object if it was drawn (the sphere itself ids 'virtual' - its center and radius are stored in an array). if the object passes the frustum culling, then I switch to its texture if neccesary. Then I draw proper number of triangles (which reside in the videoRAM). As for the collision: I have separate 'XYZ' array in the system memory. this array is used for collision detextion. the array is sorted by objects. (actually i wrote the imported which generates such array form the geometry loaded). with this approach you can easily use display lists and have collision detection not affecting the speed (only the memory - insignificantly). ...but - as f0dder said, the is no sense in using display lists for this - use some extensions to load everything to videoRAM. display lists may be used to to some 'multi state-swicthes' in 1 call.
/edit
corrected some typos
the thing you mentioned I do like this: _all_ the geometry and textures are inside the video RAM. The geometry is sorted by textures and then by objects [ so: 1) you don't have to switch to a particular texture more than once; 2) groups of triangles form a ready-to-display obejct ]. with this, I do frustum culing on a sphere that would surround the object if it was drawn (the sphere itself ids 'virtual' - its center and radius are stored in an array). if the object passes the frustum culling, then I switch to its texture if neccesary. Then I draw proper number of triangles (which reside in the videoRAM). As for the collision: I have separate 'XYZ' array in the system memory. this array is used for collision detextion. the array is sorted by objects. (actually i wrote the imported which generates such array form the geometry loaded). with this approach you can easily use display lists and have collision detection not affecting the speed (only the memory - insignificantly). ...but - as f0dder said, the is no sense in using display lists for this - use some extensions to load everything to videoRAM. display lists may be used to to some 'multi state-swicthes' in 1 call.
/edit
corrected some typos
ok thanks for the replys,
ill be off to read about hwTnL and the extensions then :)
ill let you know if i have any questions.
ill be off to read about hwTnL and the extensions then :)
ill let you know if i have any questions.
I'd throw a different spin on that, although I do basically agree.
For starters, its very inefficient to be loading and unloading displaylists to the gpu at runtime.
Think about physical 3d objects you can place in your world which are not deformable.
Things you can construct a world from, like statues, archways, flights of stairs, etc.
It doesn't have to be static, just think in terms of what you could build a "lego" world from.
Picture a level editor where you fly about in 3D, interacting with the world, dropping and manipulating objects rather than looking at planar "blueprint views" of the world.
Anything which is likely to be "instanced" (repeated) is a worthy candidate.
You cheat on the collision detection against these "world objects".
Now think about a 3D terrain, undulating and assymetric.
You for sure don't want to create displaylists of terrain - and you do want nice collision detection against this stuff.
Consider the world terrain as one or more "objects", but not in the displaylist sense.
Draw this stuff manually, performing the collision detection manually also.
Yes, do sort everything by Texture, but rather than making a list of textures per object for N objects, consider making a list of objects per texture for N textures.
This way you can totally eliminate texture thrashing, provided you are relying on the ZBuffer to get the correct occlusion of geometry... not a rational response to a BSP world heh...
Being able to load an object once and instance it N times means you keep a list of loaded "reference objects", with each RefObject owning a list of its actual instances in the world, each with its own position, orientation etc, nice and memory efficient.
For starters, its very inefficient to be loading and unloading displaylists to the gpu at runtime.
Think about physical 3d objects you can place in your world which are not deformable.
Things you can construct a world from, like statues, archways, flights of stairs, etc.
It doesn't have to be static, just think in terms of what you could build a "lego" world from.
Picture a level editor where you fly about in 3D, interacting with the world, dropping and manipulating objects rather than looking at planar "blueprint views" of the world.
Anything which is likely to be "instanced" (repeated) is a worthy candidate.
You cheat on the collision detection against these "world objects".
Now think about a 3D terrain, undulating and assymetric.
You for sure don't want to create displaylists of terrain - and you do want nice collision detection against this stuff.
Consider the world terrain as one or more "objects", but not in the displaylist sense.
Draw this stuff manually, performing the collision detection manually also.
Yes, do sort everything by Texture, but rather than making a list of textures per object for N objects, consider making a list of objects per texture for N textures.
This way you can totally eliminate texture thrashing, provided you are relying on the ZBuffer to get the correct occlusion of geometry... not a rational response to a BSP world heh...
Being able to load an object once and instance it N times means you keep a list of loaded "reference objects", with each RefObject owning a list of its actual instances in the world, each with its own position, orientation etc, nice and memory efficient.
OK Ive read some things about vertex arrays and they seem a lot better to use for my world system instead of using display lists, but i cant seem to find any good info on using a vertex array, does anyone got some tutorials about them? doesn't need to be for masm, can be any language or just a basic tutorial (ill find out how to do it in masm :)).
I got another question for you though Homer, first of all i also use some OO class to load and display a model, so displaying a model several times only requires me to have it in memory one time and i make another class which refers to a model and holds its texturemap, location direction etc etc. But how can i make a list for objects per texture for N textures, since a single model can use multiple textures.
Do i need to introduce another model format which makes it easier to prevent texture trashing or should i draw the model in parts, first draw all parts of all models which use texture #1 in array, then all parts for #2 until #N? because this seems a bit harder to code to me.
Thanks for the replies guys, Scorpie
I got another question for you though Homer, first of all i also use some OO class to load and display a model, so displaying a model several times only requires me to have it in memory one time and i make another class which refers to a model and holds its texturemap, location direction etc etc. But how can i make a list for objects per texture for N textures, since a single model can use multiple textures.
Do i need to introduce another model format which makes it easier to prevent texture trashing or should i draw the model in parts, first draw all parts of all models which use texture #1 in array, then all parts for #2 until #N? because this seems a bit harder to code to me.
Thanks for the replies guys, Scorpie
You need to minimize state changes, as state changes are expensive... so yes, either use a custom model format, or sort per texture and other state-changing parameters.
But how can i make a list for objects per texture for N textures, since a single model can use multiple textures.
I think it's a bad method of playing with 3D. It's wiser to properly prepare textures (so that each texture has everything that a particular object needs), instead of switching through them at runtime.
Look at this texture. Here are some sreenshots of a truck using this texture: 1 2.
The same thing also applies to multitexturing.
----
And here's an example showing how to deal with frustum culling (thanx EvilHomer2k ;) ): 1 2, and frustum cullng is much like collision detection (in the terms of preparing the objects).
offcourse, i shouldn't have to change my model format, i can also change the textures, mix them all together :)
And i already had the idea about frustum culling (didn't know the name, i always call it hitboxes :)), i want to do the collision for complex objects (like players, for realism) in a few phases (2 or 3), first a box around the whole object and if it has a 'hit' then do smaller hitboxes around the limbs and maybe after that even real collision (so with the triangles) but I'm not sure wether or I'm going to implement this, but this is all for some further stage in the project.
Thanks, Scorpie
PS. Still looking for texts on vertex arrays
And i already had the idea about frustum culling (didn't know the name, i always call it hitboxes :)), i want to do the collision for complex objects (like players, for realism) in a few phases (2 or 3), first a box around the whole object and if it has a 'hit' then do smaller hitboxes around the limbs and maybe after that even real collision (so with the triangles) but I'm not sure wether or I'm going to implement this, but this is all for some further stage in the project.
Thanks, Scorpie
PS. Still looking for texts on vertex arrays
I found this nice example on the Net
http://www.devmaster.net/articles/oglVertexBuffer/
and this article:
http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt
greeting Siekmanski
http://www.devmaster.net/articles/oglVertexBuffer/
and this article:
http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt
greeting Siekmanski
Scorpie, the initial hittest should be done with spheres - it's a lot faster :) . I use spheres for the frustum culling, too. My model converter precalculates the BoundingSphereMaxRadius and BoundingSphereMaxRadius2 (squared), which I later use for culling.
yea i thought about that yesterday, its way easier that checking with a box, with a sphere you can just calculate distance between the two centers and if that distance is smaller than radius1+radius2 its a (possible) collision :)
And i have a question about your model converter, how do you use it, do you have to convert some model format with that converter and then it can be used or do you convert on loading (which i don't think but could be possible)
Scorpie
(oh and why is Scorpio ok with the spell checker and Scorpie isn't? :mad:)
And i have a question about your model converter, how do you use it, do you have to convert some model format with that converter and then it can be used or do you convert on loading (which i don't think but could be possible)
Scorpie
(oh and why is Scorpio ok with the spell checker and Scorpie isn't? :mad:)
I convert from .obj to a .bin format, that is as much preprocessed as necessary.
The loading code for this format is several lines of code - once I load the file into memory, I just have to adjust three of its dwords - which are pointers to vertices, faces, and texture.
For PC games, at the converter level you could divide a static mesh in two parts - one submesh for the solid-textured faces, and one submesh for semitransparent faces. This way it'll be faster at runtime to filter-out the polys that need to be z-sorted. This is just one example of what you could pre-process in the converter
Scorpio is the 8th sign in the zodiac, whereas Scorpie is just a character from FarScape (and isn't in the dictionary), that's why the spell checker says it could be an error :)
The loading code for this format is several lines of code - once I load the file into memory, I just have to adjust three of its dwords - which are pointers to vertices, faces, and texture.
For PC games, at the converter level you could divide a static mesh in two parts - one submesh for the solid-textured faces, and one submesh for semitransparent faces. This way it'll be faster at runtime to filter-out the polys that need to be z-sorted. This is just one example of what you could pre-process in the converter
Scorpio is the 8th sign in the zodiac, whereas Scorpie is just a character from FarScape (and isn't in the dictionary), that's why the spell checker says it could be an error :)
study so much.
study so much.
:?:
@Ultrano, your .bin format is a custom one i assume? And which programs makes models to .obj format?
And do you have some text on filtering polys that need to be z-sorted on runtime? I make opengl do this for me now.
Thnx, Scorpie
ps. was kidding about my name not being in the spell checker, didnt know it was the name of a charcter though :)
Yes, my .bin format is custom. Had to be, since my 3D engine is software-rendering only and is mobile-device oriented.
http://www.3dlinks.com/links.cfm?categoryid=1&subcategoryid=11 <- list of useful converters.
In GMax, one of the gamepacks enables export to md3, then I convert to .obj, and finally to bin ^^". Otherwise, I used to make 3D objects in Blender (which supports obj directly).
During modeling, I make different "materials" for semitransparent faces, and then my converter actually reads a text file that describes different materials. There I could find which faces are semitransparent, and filter them out. The txt file looks like:
http://www.3dlinks.com/links.cfm?categoryid=1&subcategoryid=11 <- list of useful converters.
In GMax, one of the gamepacks enables export to md3, then I convert to .obj, and finally to bin ^^". Otherwise, I used to make 3D objects in Blender (which supports obj directly).
During modeling, I make different "materials" for semitransparent faces, and then my converter actually reads a text file that describes different materials. There I could find which faces are semitransparent, and filter them out. The txt file looks like:
; aircraft 09
dyntexture 0003
output mesh0109.bin
scale 5
SwapYZ
mesh Meshes\A09.obj
texture Textures\dyn0003.bmp
; materials description
new Default
color 200:200:200
new Darker
color 157:157:157
new Textured
envmap
new Viewer
color 160:221:239
alpha ; has 50% alpha
I was also thinking about supporting GMax since its free (important) and fairly easy in use as far as i heard.
I've got another question about the vertex arrays though, using the ARB extensions you can load the vertexarrays including textures to the graphicscard, since the graphicscard doesn't have unlimited memory, what will happen if i try to put more objects into it than it can handle?
edit:
Homer, would you also advise 'manual' drawing over vertex arrays and if so, can you explain why?
more edit:
is it necessary to use glEnableClientState and glDisableClientState every frame like in the tutorial from NeHe or is it also sufficient to do the enable on startup and the disable on unloading of the program? (saves 2 calls every frame :))
Scorpie
I've got another question about the vertex arrays though, using the ARB extensions you can load the vertexarrays including textures to the graphicscard, since the graphicscard doesn't have unlimited memory, what will happen if i try to put more objects into it than it can handle?
edit:
Homer, would you also advise 'manual' drawing over vertex arrays and if so, can you explain why?
more edit:
is it necessary to use glEnableClientState and glDisableClientState every frame like in the tutorial from NeHe or is it also sufficient to do the enable on startup and the disable on unloading of the program? (saves 2 calls every frame :))
Scorpie
anyone?
The extension should specify how it responds in case of insufficient memory. DirectX has its "managed objects". You just create object and let DirectX worry about the storage memory. Also DirectX doesn't have THAT much compatibility problems - mainly because there are 'capability bits' instead of 'extension strings'.
but - of course - OpenGL is easier to start with because of its similiarity to WinAPI.
There are 4 'popular' ways to behave in case of insufficient memory:
1) fail silently
2) fail with error
3) silently (transparently to application) use system memory instead of videro memory (software TnL)
4) swap the object with some other object (but due to the way that modern card render the frames, it's usually not possible)
but - of course - OpenGL is easier to start with because of its similiarity to WinAPI.
There are 4 'popular' ways to behave in case of insufficient memory:
1) fail silently
2) fail with error
3) silently (transparently to application) use system memory instead of videro memory (software TnL)
4) swap the object with some other object (but due to the way that modern card render the frames, it's usually not possible)
You want your code to scale to the local hardware.
You should query the hardware for its capabilities, and use the vertex array extension if it is available : that means you should have casecode to manually draw objects when the extension is not available,and/or to supplement vertexarray rendering with manual rendering when the hardware has insufficient memory.
You should ALWAYS check the return values of your calls to opengl api !!!
No such thing as silent failure unless you code it to fail silently ;)
Querying the hardware for its capabilities and setting flags that drive casecode seems like a lot of work, but if you want your applications to run on "anything out there", you have to do it.
You should query the hardware for its capabilities, and use the vertex array extension if it is available : that means you should have casecode to manually draw objects when the extension is not available,and/or to supplement vertexarray rendering with manual rendering when the hardware has insufficient memory.
You should ALWAYS check the return values of your calls to opengl api !!!
No such thing as silent failure unless you code it to fail silently ;)
Querying the hardware for its capabilities and setting flags that drive casecode seems like a lot of work, but if you want your applications to run on "anything out there", you have to do it.