Eric wrote:
> Thanks for all the good advice.  I've found a very nice looking solution
> with isosurface (code example 1 below) but I'm having trouble getting a
> function to work right for a height_field alternative (non-working code
> example 2 below).  I did find a posting that gives some info on how to use
> function for height_field, but still could use further advice to get a
> ripple or 'sloshing' appearance.  (f_noise3d gives a nice 'sloshing' with
> an underlying rippled appearance when the x and z parameters are scaled
> differently)
> Thanks!

The problem with height fields is that they are limited to the cube from 
<0,0,0> to <1,1,1>.  The functions for them take, as arguments, X and Y 
rather than X and Z, and the height must never be <0 or >1 (actually it 
can, but it wraps around, which is visually... disturbing).

I find isofurfaces easier because you can define their domain to be 
anything you want; however, it is certainly true that HFs render 
faster*.  If you can scale your function well in a HF, then it would 
probably be a better solution.

...Chambers

*It is conceivable that, in the future, isosurfaces will render faster 
than HFs simply due to the fact that the parse stage remains single 
threaded while the trace stage runs in parallel.  Since isosurfaces 
parse almost instantly, if you have enough cores on hand it the savings 
in parse time could more than pay for the cost of trace time.

Post a reply to this message