>X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
>content-class: urn:content-classes:message
>MIME-Version: 1.0
>Thread-Topic: [JAVA3D] Interpretation of depth buffer values
>Thread-Index: AcDkTSvdLxML+ashRnOAPFAqMqP+IgASurDQ
>X-OriginalArrivalTime: 24 May 2001 21:34:12.0292 (UTC) FILETIME=[460F7040:01C0E499]
>Content-Transfer-Encoding: 8bit
>X-MIME-Autoconverted: from quoted-printable to 8bit by mail.java.sun.com id
>f4OLbMj26622
>Date: Thu, 24 May 2001 14:34:10 -0700
>From: Philip Taylor <[EMAIL PROTECTED]>
>Subject: Re: [JAVA3D] Interpretation of depth buffer values
>Comments: To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>
>its almost assuredly dependant on the hardware. thats why zbuffer
>formats are typically treated as opaque.
>
>one tactic to use is to write some known values to the zbuffer by
>rendering objects at certain known locations ( z=0, z=1, z=near-plane,
>z=10, z=100, z=far-plane, etc ) and reading those values back. do this
>at startup or some other opportune time early on. that will allow you to
>determine what kind of mapping the hardware is using.
>
>note some cards dont have a true z-buffer...eg scene capture cards ala
>PowerVR. Kyro and KyroII are decent cards, and PVRI and PVRII are out in
>the marketplace in some numbers so you will run into this case. off the
>top of my head, I am not sure what they return for z-buffer reads.
>
>Its also possible some hardware would fail zbuffer locks now or in the
>future. for example D3D explicitly disallows front-buffer locks with DX
>8, so features that used to exist dont always continue to exist...and
>thus cant be counted on.
>
>Sun engineers would have to comment on what Java3D would do for
>DepthComponentFloat if there is no z-buffer or the z-buffer is
>unreadable...
>
For OpenGL version,
----------------------
glDrawPixels(width, height, GL_DEPTH_COMPONENT,
GL_FLOAT, floatData);
glReadPixels(xOffset, yoffset, width, height,
GL_DEPTH_COMPONENT, GL_FLOAT, floatData);
are used, it is up to the driver to handle the case when there
is no z-buffer or it is not readable.
For D3D version using DX 7.0 (i.e. Java3D v1.2.1 ),
-------------------------------------------------
If device has no z surface needed,
i.e. dpcTriCaps.dwRasterCaps & D3DPRASTERCAPS_ZBUFFERLESSHSR
then all the read/write depthcomponent will silently ignore.
Otherwise, the z surface is created. If during z surface lock
D3D return fail, a message will printout
"Fail to lock surface " with error code and operation return
without doing anything.
For D3D version using DX 8.0 (i.e. next Java3D 1.3 release)
----------------------------------------------
The specification only allow locking the depth surface
to read/write when D3DFMT_D16_LOCKABLE format is used.
But this means we can't use stencil buffer by specific
format D3DFMT_D24S8 for features such as DecalGroup.
Thus DepthComponent can't coexist with other features
in Java3D that required stencil buffer.
Right now the depth format available is search with
stencil buffer has priority. So under the nvidia driver,
if display mode is 16 bit than DepthComponent is support.
If the z surface fail to get using DX function
GetDepthStencilSurface(), an error message will
display when -Dj3d.debug=true is used on startup.
All read/write DepthComponent is ignored.
Same thing happen when lock surface fail.
- Kelvin
--------------
Java 3D Team
Sun Microsystems Inc.
===========================================================================
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".
