Wow!
Kyle Wayne Kelly
Computer Science Student
University of New Orleans
504-391-3985
http://www.cs.uno.edu/~kkelly
Glory to God!
----- Original Message -----
From: "David" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 20, 2001 8:18 PM
Subject: Re: [JAVA3D] Performance, LOD and optimization
> 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".
>
>
===========================================================================
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".
