Very Computer

Hello all,

I was wondering if anyone could help me out with some ideas, tips,
pointers, etc.

I am beginning development of a fairly simple 3D racing game, using
OpenGL.  Each track in the game is a static world consisting of a
closed, polygonal, branching tunnel system (no realtime LOD or
anything).  Id like the tunnels to have an organic look to them, so
they wont have just vertical walls, level floors/ceilings, etc., and
wont consist of simple convex polyhedra.  The tunnels will be modeled
as meshes in 3DS Max.

I need an occlusion culling/PVS/portal (or whatever) algorithm for the
rendering that will be reasonably simple to implement.  Its okay if it
isnt ultra-efficient, as long as it quickly culls out the majority of
polygons that wont be visible (Ill model the tracks with fairly low
poly density, but the tracks could be quite large, and have a high total
poly count).  Ill use a z-buffer, and require a hardware 3D
accelerator.  It wont hurt if a few non-visible polys are sent to the
rendering pipeline.

My thoughts so far are to hand-build a 3D lattice of simple connected
sections enclosing the tunnel system (in 3DS Max), and export it as a
separate object.  Look at http://www.rabens.com/lattice.jpg for a
picture of what I mean.  At runtime, I could determine which sections
were visible (using a portal-like or Descent-like algorithm on the
sections), and render the contents of those sections.  This would
include a number of polys it wouldnt need to, but it should bring it
down to a reasonable set (depending on how well I design the sections).

I was thinking the section visibility determination would be simpler if
I constrained the overall layout of each track to a fairly horizontal
shape (limit how far the track rises and drops).  This way, the section
lattice could be essentially 2D, with two parallel planes for the floor
and ceiling of the entire lattice, and strictly vertical walls and
portals.  (I dont know if youd call it a portal, since it wouldnt
be a narrow opening on a wall, but rather the entire area where one
section adjoins another.)  I could then do the visibility determination
in 2D.  The problem is, I do need to pitch the camera up and down (but I
dont need to roll side to side).  When the cameras looking slightly
down, for example, the portals are a little narrower towards the
bottom and wider towards the top (from the cameras POV), so I dont
think I can just use simple 2D portal clipping.  So, would there be any
advantage to constraining the section lattice to a 2D layout?  If so,
how do I exploit this advantage?

Id appreciate any and all feedback on this.  Is my section-lattice idea
completely insane/stupid/na?ve?  What would be a better way to do this?
Remember, the tunnel system will be an organic-looking mesh, and the
algorithm should be something that can be understood and implemented in
a reasonable amount of time.

TIA,
    Marty Rabens

Quote:>Id appreciate any and all feedback on this.  Is my section-lattice idea
>completely insane/stupid/na?ve?  What would be a better way to do this?
>Remember, the tunnel system will be an organic-looking mesh, and the
>algorithm should be something that can be understood and implemented in
>a reasonable amount of time.

hey
i don't see a reason why implementing a 2d section engine should be
better then implementing a 3d portal engine, the only drawback of
portal engine is that you will need to generate portals and divide
your map into sections/rooms (you should be able to add a feature into
your map editor that will allow you to divide map into portals by
itself (or at least at the place where you wish to , so this problem
should be fairly easy to care about with a bit of additional coding)
but with a 3d portal system you won't be limited in any way while
creating the maps , there shouldn't be any visible difference in speed
but a portal engine can cut down the number of polygons much more
(imageine you're going uphill , a 2d engine won't notice it and you
will draw all the way in front of you , a 3d portal engine will draw
only the road uphill and a bit at the top of the hill but rest won't
be visible from your position)
i think that the lamest (but easiest and creating fairly good results)
way to do it is to create portals with box-shape that cut the tunnel
into pieces , then you just need to find out which faces belong to
which portals (like face 1,2,3,4 belongs to the space between portal 1
and 2 , face 5,6,7,8 belongs to the space between portal 2 and 3
..(of course portals should contain like 50-more polygons (i think
that value between 100 and 200 should be the best , it still depends
on how detailed your tunnel should be , you will have to test the best
solution yourself)) now as your camera is in the space between portal
2 and 3 you just have to check if portals behid are visible , so you
check if portal 2 is visible (as long as portals are boxes it's very
easy to check that , actually every faced shape is easy to check just
it takes more time to check a 20 faces portal - but on some maps it
might bring much better results), if it is visible then you draw faces
that are between portal 2 and 1 , then you check portal 1 and so on...
the same you do to portal 3 , you check if it's visible , if it is
then you draw faces between portal 3 and 4 and check if portal 4 is
visible , if it's visible you draw faces between portal 4 and 5 and so
on... (remember to check if portal 4 is "inside" portal 3 , if it
isn't you can mark it as not visible!) , in a perfect tunnel
enviroment this system is quite ideal and still very easy to code ,
with a bit more effort you can also add crossroads , the trick is that
for every room/section (the place between portals) you make a list of
portals , as for now all such list would look like room 1 portal 1 and
2 , room 2 portal 2 and 3 , ... but we can make room 1 portal 1,2 and
10 ! portal 10 might show you anything you want , you could use it to
make crossroads where you go left or right , not only forward , you
can use it as a window to show a piece of map that's in front of you ,
you can do quite everything with it
well , that's a fairly easy to code and powerfull solution i think , i
believe that most nfs-like games use this or quite similar solutions ,
in case you don't understand something feel free to email me/post a
reply with questions , cu

I would check out doing binary space partitioning along the tunnel
junctions. This is exactly the kind of application (low density, high
overall count,) where BSP excells.

Cheers,

Josh Buckman

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!