Re: [Plib-users] How should I use plib?

[Steve B. <sjb...@ai...>]

Troy Yee wrote:
> 
> Sorry for the long post.  I'll ask my question(s)
> up front.  A description of what I've been up to follows.
> 
> Q: What is the best way to create a scene/world using plib?
>    It seems to me that loaders are extremely useful but
>    what is their impact on one's ability to render a scene
>    quickly and efficiently?  Aside from loading a model,
>    and scaling/rotating/translating it what else must be
>    done to manage the scene/world (i.e. BSP trees, LOD, etc.)?

Theoretically - you don't need to do ANYTHING - that's what
SSG is good at.

SSG uses whatever the hierarchy of the scene is in the
model file - and does heirarchical field-of-view checking to
ensure nothing outside the field of view gets rendered.

SSG supports LOD nodes - but if there aren't any supported
in whatever file format you are using - then the loader can't
create any and SSG won't 'magically' insert them.

In TuxKart and TuxAQFH, I've used comment fields with a magic
first character to tell the loader to generate certain kinds
of ssgBranch node that the loader wouldn't otherwise be able
to generate.  That's one way to get LOD nodes into your
scene.

However, the idea is that you dump the scene into SSG and let
it worry about all the rendering issues.

> One of the immediate problems with my ocean approach is that
> the ocean often disappears - it depends on the direction the
> camera is pointing and where in the scene it is placed.  I'm
> guessing that it's getting culled because there are no vertices
> of the ocean inside the view frustum.

No - that's not possible.  SSG computes a bounding sphere around
all the vertices in each leaf node - if any part of the sphere
lies inside the view frustum, the node will be passed on to OpenGL.

Are you creating the ocean model in code - or loading it via
one of the SSG loaders?

If you are creating it, then perhaps you just need to call

   your_node -> recalcBSphere () ;

...to force SSG to recompute a fresh, accurate bounding sphere.

> I mentioned above that the game area is quite large - 2000
> nautical miles on a side.  Although all action will typically
> take place in a very small portion of the map, there is no
> way to decide up front where that might be.  It is also
> possible to 'warp' any entity to any place on the map at any
> time. Since this is a naval simulation, most of the action
> will take place on the water but may be near a major land mass.

Perhaps you should look at Curt Olson's "Terragear" project.

Once you get to scenes more than a few tens of miles across,
the curvature of the earth becomes very significant - and the
amount of polygonal information needed to display things at
a reasonable precision rapidly grows beyond the ability of the
PC to hold it in RAM - so it has to be paged from disk on-the-fly.

> Here's the worst part (I think) of how I'm realizing this land
> in the scene... <cringing in anticipation of being bashed about
> the head>... I'm loading a single instance of a unit sized AC3D
> cube, scaling the height to match the height of a grid point
> (by adding model to ssgTransform node) and translating it to
> the appropriate grid location.  The net result is lots of
> stretched cubes clustered about.

You certainly need some serious help!

You should use a triangular mesh I think.

Take a look at the 'Majik3D' example program.  It demonstrates
creating polygonal terrain from a height field.
 
>  I noted that
> FlightGear has defined a bunch of tiles that get loaded
> in and I assume that something like this is the way to go
> here.

FlightGear's terrain stuff is what is now in 'Terragear' - which
is why I advised you to look there.

> How does one deal with being able to warp the
> camera anywhere on the map though?

Well, it's *VERY* complex.  Because you need reasonably good
precision to stop the ocean from 'shaking' violently, yet you
still need thousands of miles of terrain, you rapidly discover
that floating point numbers are not accurate enough.  You could
consider going to 'doubles' but OpenGL doesn't support them
internally.  In the end you need to keep the camera still and
move the terrain relative to it...this gets insanely messy - but
that's what you need to do.

Then you get into earth curvature - you can't tesselate squares
or rectangles to make a sphere - so you need terrain tiles that
are actualy subtly curved parallellograms.
 
> Well, thanks for your time.  Any pointers/comments would
> be appreciated - perhaps you know of a 'getting started'
> tutorial?  Anyway, welcome to my adventure! :)

Check out Terragear - or start with something MUCH less ambitious
until you get proficient with 3D.
 
-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net