Rendering a Scene/Map
Author
Ok, I''ve read allot of articles about how to draw things to the screen and different ways that make it fast to draw terrains etc... However, I have never found an article that discuses ways in which a game engine should draw an entire scene. naturally this involves drawing both the terrain and the objects that appear in the scene, however if you have a large scene then this would be rather slow.
Is there anyone out there who would be willing to discuss this or even point me in the direction of an article they have read?
I''m wondering in what way i should structure the information describing a map, ie...do I have one structure to list all the Objects in the map and one structure to describe the terrain of the map?
For the structure listing the objects is there any particular type of structure that allows the engine to quickly decide which objects currently need drawing or not? (ie are they in view or within a particular range?)
Thanks!
--Josh
octrees are good, they can really quickly occlude stuff. if the circumstances are right, you can cull 7/8ths of the level in one bounding box test. if its mostly indoors, take a look at BSPs
Author
The other problem is that some objects in the scene will move over time...If I were to use an octree or a Quad tree, how would I be able to calculate what the next quad/oct it should be placed into is?
after you build the octree, once things are moving don''t make any new nodes. so if an object moves, start in the root node, and check which child node its in. then find out which child node it is in of those, until you reach a node without any children (leaf). if the object intersects two node borders, put it in the lowest parent that encloses both the borders, even if that means it gets stuck in the root node.
Author
ok then. I''m beginning to understand how this is going to work then, it''s making more and more sense.
Generally would an engine also have a list of all the objects within the map so that it could perform routine operations on it every frame...
Actually, one way of doing it would be to let every dynamic (moving or otherwise changing) object to have a time associated to it indicating the last time that it was processed using the physics enging (ie for rotate functions or something) in that way you could simply process JUST the objects within view and the others would still have moved by the time you turn back to view them...
Am I getting this do you think? do you know of anyone doing this before? is this common?
Generally would an engine also have a list of all the objects within the map so that it could perform routine operations on it every frame...
Actually, one way of doing it would be to let every dynamic (moving or otherwise changing) object to have a time associated to it indicating the last time that it was processed using the physics enging (ie for rotate functions or something) in that way you could simply process JUST the objects within view and the others would still have moved by the time you turn back to view them...
Am I getting this do you think? do you know of anyone doing this before? is this common?
Well, if you leave things for too long before you process them again, you run into a lot of trouble when there are many objects that could potentially interact. Say you have 100 balls bouncing around that are outside of the viewing frustum, and so not being processed. Then, suddenly the camera turns and they *are* in the frustum, and the last 10 seconds needs to be processed all at once. There are obvious problems with multiple collisions, etc etc. It might be better to implement some form of that idea in moderation, say, only process the objects out of the view 5-10 times per second instead of every frame. Neat idea ;o
Author
Yes, I was thinking about that idea a little more and thought that If the objects were moving then their movement wouldn''t be processed when you arn''t looking at them, meanwhile the object may be supposed to be moving into the viewing area. I guess that''d be a large problem in it, however for things like Periodic rotation of an object and things like that then it shouldn''t affect the way the scene works too much then.
I just read in an article that Octrees are expensive at runtime (I can imagine that they are) and that they are better suited to static models.
(http://www.gamasutra.com/features/19991109/moller_haines_02.htm)
If this is the case then what is a "better" method of culling for dynamic models?
I just read in an article that Octrees are expensive at runtime (I can imagine that they are) and that they are better suited to static models.
(http://www.gamasutra.com/features/19991109/moller_haines_02.htm)
If this is the case then what is a "better" method of culling for dynamic models?
wait a sec, are ALL the things in your scene dynamic? with an octree, you have to build the octree on loading/level compile or something, and then in the game when thigns are moving around, don''t create/delete new nodes like when you compile the octree.
Author
No...Not ALL things in the scene are dynamic...
It''s an outdoors engine, So you have trees, the terrain, buildings etc that remain in the same place, (however they may dissapear or their state changes (that wouldn''t affect the way in which the octree functions though would it?) then you also have your dynamic objects...ie cars/buses/planes/animals/people that sort of thing
It''s an outdoors engine, So you have trees, the terrain, buildings etc that remain in the same place, (however they may dissapear or their state changes (that wouldn''t affect the way in which the octree functions though would it?) then you also have your dynamic objects...ie cars/buses/planes/animals/people that sort of thing
then here is what you do. when you load the level (or compile it if you have an editor), put everything into it, creating nodes as necessary. once its loaded, and things are moving, don''t mess with the nodes at all, just move the things around in it, but without creating new nodes. you only need to calculate which node its in if it moves, so the only things that would be finding a new node to be in are things that are moving.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
