Indoor/outdoor environments
Author
I´m looking for a way to combine indoor/outdoor environments in my game. I want to be able to walk around a city and walk in and out of buildings. I have a basic portal engine up and running, but I´m not really sure how to extend it to handle outdoor scenery. Can BSPs be mixed with portals in some clever way? Or do I have to create a seperate terrain engine and switch to it when I hit a portal leading out into the open? (seems a bit overkill for s simple city). What kind of world representation would be efficient? Any hints on how to proceed?
/grey
I''m working on an octree/portal rendering engine.
The principle is easy to figure out, and I hope the code will be as easy to write.
I''m still designing the objects (cause it''s a OO 3Dengine) at the time so I don''t know how efficient it''ll be.
Combination is the key to success.
Or Hybrid rendering if you prefer
-* So many things to do, so little time to spend. *-
The principle is easy to figure out, and I hope the code will be as easy to write.
I''m still designing the objects (cause it''s a OO 3Dengine) at the time so I don''t know how efficient it''ll be.
Combination is the key to success.
Or Hybrid rendering if you prefer
-* So many things to do, so little time to spend. *-
Hi,
all major FPS 3D engines uses a BSP / Portal combo. I suggest you to use portal indoor, and to seperate indoor / high poly areas from the terrain areas with relative low poly counts.
Quadtrees are the way to go for normal outdoor terrain, because the geometry is distributed in a mostyl 2 dimensional way. If you want it easy, you can simply use Octree for everything. They are a good thing between Quadtrees (outdoor) and BSP Trees indoor, because they can handle terran with relative low overhead an are still able to cull high-poly indoor scenes with high-speed. On my homepage, you''ll find an Octree tutorial. When you have questions, you may mail me.
and remember what Ingenu said ! Combining is the key to success. Even some weird Quadtree/Portal/BSP stuff might work...
Tim
--------------------------
www.gamedev.net/hosted/glvelocity
glvelocity.gamedev.net
www.glvelocity.com
all major FPS 3D engines uses a BSP / Portal combo. I suggest you to use portal indoor, and to seperate indoor / high poly areas from the terrain areas with relative low poly counts.
Quadtrees are the way to go for normal outdoor terrain, because the geometry is distributed in a mostyl 2 dimensional way. If you want it easy, you can simply use Octree for everything. They are a good thing between Quadtrees (outdoor) and BSP Trees indoor, because they can handle terran with relative low overhead an are still able to cull high-poly indoor scenes with high-speed. On my homepage, you''ll find an Octree tutorial. When you have questions, you may mail me.
and remember what Ingenu said ! Combining is the key to success. Even some weird Quadtree/Portal/BSP stuff might work...
Tim
--------------------------
www.gamedev.net/hosted/glvelocity
glvelocity.gamedev.net
www.glvelocity.com
Author
Thanks for replying! I´ve been thinking about an octree / portal solution and it might be a good way to do things. As you pointed out, octrees are general enough to handle my kind of environment. And using portals to handle overdraw when rendering heavily occluded regions indoors sounds like a nice complement. I´m definitely going to explore this option further.
/grey
/grey
Well, my idea would be:
Treat each portal as an individual object, from a base portal class. Connect them as you wish, but have separate (virtually) derived children for a portal containing BSP data and one containing Quadtree data.
Each implimentation would have a virtual function derived from the portal base that takes a position and viewport as parameters returns a list of triangles to draw.
The function would look something like this...
vector_3d ** CPortal::GetTriangles(vector_3d &vPosition, CViewport &vpViewport);
In theory, you would only have to call the GetTriangles() function for the portal you are in. It would then get the triangles of all visible portals connected to it, and they in turn would get the triangles of all portals visible from them, add them to the visible triangles in them, and return them to the origional call. The end result would be a nice, neat, array of triangles that can be easially rendered.
Also, it should be relativly easy to imliment each method individually, then "glue" them together in the portal-based inheritence paradigm. Of course, I am one of the (brave) few who does not cringe at the idea of inheritence in high-stress applications, so that may just be my preference. I am sure there are many ways of doing it.
This does raise a question for me, however, as I am working on a 3d terrain-based environment myself. What is the best method for creating/storing terrain maps? What is the best architecture for HSR and PVS? Quadtrees? I eliminated BSP''s early, as they work very well for high surface:volume ratios (or closed environments) but badly for low ratios (closed environments), but I haven''t been able to find much info on any other methods (reading your site when I am done here, Tim). Any suggestions would be helpful.
My $0.02
Nathan Hoobler
Treat each portal as an individual object, from a base portal class. Connect them as you wish, but have separate (virtually) derived children for a portal containing BSP data and one containing Quadtree data.
Each implimentation would have a virtual function derived from the portal base that takes a position and viewport as parameters returns a list of triangles to draw.
The function would look something like this...
vector_3d ** CPortal::GetTriangles(vector_3d &vPosition, CViewport &vpViewport);
In theory, you would only have to call the GetTriangles() function for the portal you are in. It would then get the triangles of all visible portals connected to it, and they in turn would get the triangles of all portals visible from them, add them to the visible triangles in them, and return them to the origional call. The end result would be a nice, neat, array of triangles that can be easially rendered.
Also, it should be relativly easy to imliment each method individually, then "glue" them together in the portal-based inheritence paradigm. Of course, I am one of the (brave) few who does not cringe at the idea of inheritence in high-stress applications, so that may just be my preference. I am sure there are many ways of doing it.
This does raise a question for me, however, as I am working on a 3d terrain-based environment myself. What is the best method for creating/storing terrain maps? What is the best architecture for HSR and PVS? Quadtrees? I eliminated BSP''s early, as they work very well for high surface:volume ratios (or closed environments) but badly for low ratios (closed environments), but I haven''t been able to find much info on any other methods (reading your site when I am done here, Tim). Any suggestions would be helpful.
My $0.02
Nathan Hoobler
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
