Re: ASDGen insets?

New Message Reply Date view Thread view Subject view Author view

Yair Kurzion (yair++at++polygon.engr.sgi.com)
Tue, 9 Mar 1999 12:18:24 -0800 (PST)


Hi Geoff !

> We have had some success using Yair's ASDGen code to generate paging
> ASD's. Now we are wondering how difficult it would be to extend it a
> bit. What we would like is to be able to specify a different maximum
> level of detail for each tile, so that we can generate a high level of
> detail only in the tiles we are most interested in. Is this a feasible
> and/or sensible approach? If not, does anyone have a better suggestion?

Feasible ? I think so.
Time-consuming ? I think so too :-)

Looking at the ASDGen code, I can see some things that have to change.
Note that this is only my guess at the real complexity of the problem.

o I assume that for every tile you know (from some magic source) how many LOD's
  you wish to generate. This should probably come from a per-tile user function
  that takes the bounding rectangle of a tile and returns the number of LOD's.

o I assume that the function you specified in pfdASDGenElevationFunc knows how
  to return low-res elevation for non-inset areas, and hi-res elevation inside
  the in-sets. I also assume that that function can accept (x,y) grid locations
  in the main ASD grid coordinates and convert to in-set coordinates when (x,y)
  fall inside an in-set.

o In order to keep the main ASDGen logic unchanged, you have to keep a uniform
  tile size across the entire ASD, and generate more LOD's for the in-set tiles.

  It may sound easier to break the in-set tiles into smaller tiles and keep
  the number of LOD's per tile, but ASDGen uses the regular grid topology
  to compute global primitive ID's so I think you should avoid modifying this
  logic.

o In pfdASDGenerate, the `grid' structure has to change for every tile. in-set
  tiles will have a denser grid.

o The function grid2ASD already takes a specific number of LOD's so you should
  plug the desired number.

o The code in rearrange_tiles should be more forgiving when a tile-file is not
  available. Also, it should avoid saving empty tiles.
  Writing info cfg_filename, you should not write out tile levels that do not
  exist. This should keep convasd happy.

o Note that rearrange_tiles packs tiles together so that the tile edge of each
  level is a half the tile edge of its parent level. The original tile size is
  the size of the highest LOD tiles. For example, If you have an ASD with 5
  levels and an in-set with 14 levels, the non-in-set tiles will become very
  large (2 ^ (14 - 5) times the original tile size). You'd have to modify
  rearrange_tiles if you want to change this behavior.

o Now, here is the more difficult part. I think you can get reasonable results
  without it (see below) :

  A general note on running ASD's with varying maximum LOD: Take the following
  case: In the drawing, T0 is a triangle of the highest LOD on the boundary
  of some tile,(boundary == vertical line). T0's neighbor has grandchildren
  of 2 or more LOD's higher. If T0 is of LOD 7 then T1, T4, T6 are of LOD 9.
  ASD will never display T0 together with any of T1, T4 or T6 in the same
  scene because this will result in T-vertices along the vertical edge.

  However, if T0 leaves the viewing frustum, ASD may suddenly allow T1, T4 or
  T6 in. This will result in a popping effect.

  The way to overcome this is to make sure that the highest LOD on two sides
  of ANY edge in the entire ASD differs by no more than 1. So, you'd have to
  gradually increase the highest LOD from the in-set tile edge towards its
  center. The best way to do this (IMHO) is to start by generating the full
  inset tile, and then scan the result and remove triangles along the edge.
  (Actually, it is enough to zero out the child pointers at the parent triangle)
                                     ___________________
                                   /| /
                                  / | /
                                 / | /
                                / | /
                               / | T0 /
                              / | /
                             / T1 | /
                            / | /
                           /--------| /
                          / \ T2 /| /
                         / \ / | /
                        / T3 \ / | /
                       / \/ T4| /
                      /-------------| /
                     / \ /| /
                    / \ T5 / | /
                   / \ /T6| /
                  / T7 \ /___| /
                 / \ /\ /| /
                /___________\_/__\/_|/

  The prune code puts many efforts into keeping this 1-LOD difference. It may
  serve as an example for keeping this behavior.

  If you completely ignore this point, your ASD's should build fine, but you
  may experience some triangles popping along the edge of your in-set tiles.

I hope I didn't scare you out of trying it ...
-yair

-- 
\_________  \_____  \__    \__  \_____         Yair Kurzion
\_________  \_____   \__   \__  \_____         yair++at++sgi.com
       \__     \__   \____\__      \__   http://reality.sgi.com/yair
       \__          \__  \__                Work: (650) 933-6502
       \__          \__   \__               Home: (408) 226-9771
       \__          \__    \__             

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Tue Mar 09 1999 - 12:18:49 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.