The question was raised about the value of a floating point Z-buffer.
The point here is that for the same number of bits, a fp Z-buffer
uses its bits to distinguish more accurately between near objects
than far objects. As a consequence it should be acceptable to have
a very much greater near/far ratio, particularly for astronomical
objects.
Although some cards e.g. Sun's XVR-1200 have greater than 24 bit
Z-buffer, 32 bits still may not be sufficient. The XVR-1000 and
XVR-4000 (and probably others on the market) use a floating point
Z-buffer.
Another possibility is to use multiple locales separated via
hires coordinates (256 bits), which the Java3D API supports.
On the whole it strikes me as inefficient to compute repeatedly
something that cannot physically change rapidly e.g. the stars in
the sky many lightyears away. Maybe a better approach is to use a
spherical background geometry as discussed in Daniel Selman's book.
I am wondering (and don't know the answer) whether it is possible
to use a floating point Z-buffer when Java3D is rendering via a
software implementation. If it can be done then maybe the background
can be computed infrequently but accurately in software. Again,
there could be some opportunities to exploit JAI tiled images to
compute on demand the tiles required for a particular view.
I'm way out of my depth to comment on the appropriateness or utility
of DepthComponentFloat().
--
============================================================================
,-_|\ Richard Smith - SE Melbourne
/ \ Sun Microsystems Australia Phone : +61 3 9869 6200
[EMAIL PROTECTED] Direct : +61 3 9869 6224
\_,-._/ 476 St Kilda Road Fax : +61 3 9869 6290
v Melbourne Vic 3004 Australia
===========================================================================
===========================================================================
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".
