Chris:
That is a really old e-mail of mine you dug up. The "straight-line"
scenario I was refering to was the problem of terrain transitions from one
texture to another, a problem which we solved by using procedural texture
generators and shaders which can compute the proper texel for any real world
coordinate, taking into account terrain slopes and the world-artist's
geographic areas and their terrain rules.
Our terrain engine is "done" at least for now. I have an endless series of
improvements I want to make, but its good enough
for now. We have a viewable range of, well anything up to 12800 meters with
pretty good results. I tried a LOT of different ways to go, including
adaptive quad-trees, but finally settled for static quad-trees for the
terrain. We import a GIS heightmap and generate geometry cells and
procedural texture cells for 200m, 400m, 800m, 1600m, etc up to 6400 meter
cells.
Each level is controlled by a LOD descriptor that defines the following:
1. The sparseness of the heightmap scan
2. the amount of polygon crunching to do in percentage of total polygons
3. The size of the texture
4. The density of the detail texture
5. The name of the detail texture
6. Whether or not to share the parent's texture
7. The number of children in one dimension (2 for right now for all levels)
We run a program that generates all the geometries and textures into files
(soon to a jar) and we are coming in at 20mb per 135 sq km, which is pretty
decent, although we have plans to reduce that further
. We then define an array of spherical bounds which define the
minimum LOD level in relation to the person. So everytime they move 40
meters or so we recusively drop down through the tree starting at the top
and check to see if the cell violates the layered bounds. When it does, it
builds n children and drops down inside of them, whereupon it continues. So
we can say we want the highest lod detail within a 400 meter radius, and we
never want the 3200 or up LOD version within 800 meters. If we don't do
this we can get too close to a low res version approaching major colinear
cell boundries (like in the very center of a 12k cell). During this pass a
list of nodes is built. This list is then passed to the renderer which
determines which cells have been removed from the last pass and which need
to be added. It then modifies the scenegraph accordingly and then prunes the
tree to remove children that arn't needed anymore.
There were some tricks needed to seemlessly merge the different LOD meshes.
Since they are done at a different sample rate, a far cell will sometimes
"pull up"
and show gaps in the geometries. We changed the sample algorithm to sample
outside the cell and consider adjoining cells.
Feedback from the team is that there is no sense of paging or slowdowns or
hiccups at all. The LOD changes are noticible, but not really bad at all.
There is some popping, but not generally in outline of the mountains. The
textures appear to be seemless. The farther cells are being built with
fewer and fewer polygons.
I am attaching a picture of a view from our wold builder, which shows the 3d
scene
and the the corresponding terrain map. Note the grid cells in the terrain
view,
those represent different LOD levels.
Dave Yazel
Cosm Development Team
http://www.cosm-game.com/
----- Original Message -----
From: chris thorne <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 20, 2001 7:34 PM
Subject: Re: [JAVA3D] Performance, LOD and optimization
Hi Dave,
can you tell me what the results of your texture experimets were?
What is the "straight line syndrome " you refer to?
regards,
Chris
"Yazel, David J." wrote:
5. I think I have finallly found the right "combination" for large terrain
in Java3d. I have experimented with lots of different configurations and
the following seems to offer the best performance/flexibility. You are
going to laugh because it is counter-intuitive. First of all I found out
that the "number" of shapes does not impact framerate assuming that the
number of verticies remains constant. Only one texture can be shown per
shape, so there are advantages to having smaller shapes. If you recall,
yesterday I had a grid of 200x200 height values mapped into a 4,000 x 4,000
area, with a total of 80,000 triangles. Well I decimated the heightmap down
to 50x50, still mapped to 4000 x 4000, reducing the number of triangles to
5000. Also, I orginally had 50 triangles per "cell" (single sub-mesh)
knitted together to make a single larger. Now I kept reducing the "unit
size" of the submesh and looking for performance drops. I expected to see
performance drops because dropping the unit size of the sibmesh results in
more sub-meshes being generated. But I dropped it all the way down to ONE
without losing performance. (now is when you can start laughing) So my
whole terrain over 4000 x 4000 virtual coordinates ends up being 2500 meshes
of two triangles each (as a deformed square). The WONDERFUL thing about
this is that you can stretch a 128x128 texture on that size mesh very
nicely, which allows you to define a 50x50 map of textures to cells. I will
be experimenting more this week on this, but it allows you to solve the
"straight line" syndrome by playing with texture coordinates and doing a
little bending. I will post some screenshots if I can get something to look
reasonably good.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
