Hi Kelvin.
glad you thought the post useful. I erred on the side of sending more
data rather than less. Usually a good thing :-).
no, D3D doesnt automatically fallback. I meant 2, as you indicate below
- that a smart application would examine the local configuration and
attempt to use the features on the local machine with that order of
preference.
Note the order of preference I lay out favors the removing of the
z-based artifacts over the niceness of pixel fog. There is the
possibility some applications would prefer to fall back to z-based pixel
fog before range based vertex fog. All developers have to make that call
based on their own criteria, I just happen to think this is a very
reasonable set of fallbacks since it avoids the worst artifacting first.
yes, this particular problem looks likely to be driver related. However
that should be verified with the IHV in question.
hth
Phil
-----Original Message-----
From: Kelvin Chung [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 17, 2001 7:50 PM
To: Philip Taylor
Cc: [EMAIL PROTECTED]
Subject: Re: [JAVA3D] Fog (Linear) Differing Results
Hi Philip,
Great summary. The problem of non W-Friendly projection matrix
is fixed in v1.2.1 beta2 and later (that's bug 4402941 which
we use -1 instead of 1 in _m34). Java3D only set
D3DRENDERSTATE_FOGVERTEXMODE and corresponding values.
Do you mean
(1) If the driver did not support it,
DirectX 7.0 (and later) library will fall back to use fog
in the order:
pixel w-fog
vertex range-fog
pixel z-fog
vertex z-fog
and application don't need to handle it unless the driver
did not support fog at all. Then it is the application
responsible to compute fog manually and put it in specular
color component.
Or
(2) It is the programmer responsibility, Java3D should do :
if (D3DPRASTERCAPS_FOGTABLE && D3DPRASTERCAPS_WFOG) {
use pixel fog
} else if (D3DPRASTERCAPS_FOGVERTEX && D3DPRASTERCAPS_FOGRANGE) {
use vertex range-fog
} else if (D3DPRASTERCAPS_FOGTABLE) {
use pixel z-fog
} else if (D3DPRASTERCAPS_FOGVERTEX) {
use vertex z-fog
} else {
application responsible, give up
}
In the original message, Mark indicate that this problem
also happen under OpenGL which the API simply set glFog(..) and
the library should do all the trick.
So I think this might related to drivers.
Thanks.
- Kelvin
--------------------
Java 3D Team
Sun Microsystems Inc.
>X-Unix-From: [EMAIL PROTECTED] Thu May 17 18:54:11 2001
>X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
>content-class: urn:content-classes:message
>MIME-Version: 1.0
>Thread-Topic: Re: [JAVA3D] Fog (Linear) Differing Results
>Thread-Index: AcDfHMMg6OdzgZYKSMqbJ1fuoTwGhQAHIbZQ
>X-OriginalArrivalTime: 18 May 2001 01:50:14.0205 (UTC)
FILETIME=[E19516D0:01C0DF3C]
>Content-Transfer-Encoding: 8bit
>X-MIME-Autoconverted: from quoted-printable to 8bit by
mail.java.sun.com id f4I1rTk13001
>Date: Thu, 17 May 2001 18:50:09 -0700
>From: Philip Taylor <[EMAIL PROTECTED]>
>Subject: Re: [JAVA3D] Fog (Linear) Differing Results
>Comments: To: Kelvin Chung <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>
>there are two important bits here:
> 1) report all driver bugs
> 2) D3D fog
>
>1) report all driver bugs.
>
>this is SO important. if all ISVs dont report driver bugs they find,
the
>quality of the drivers never gets better. please take the time to
report
>these.
>
>Most IHVs do have helpful dev-rel folk and want to hear this sort of
>thing to make their products better.
>
>they cant if we arent vigilant, we are all in this together.
>
>please.
>
>2) D3D fog.
>
>D3D implements two types of fog: vertex fog and pixel fog.
>
>pixel fog ( sometimes called table fog ) should be preferred over
vertex
>fog since it appears better, as long as the driver correctly implements
>it. note the key statement "as long as the driver correctly implements
>it"****. it appears better since its calculated per-pixel instead of
>calculated per-vertex and then iterated.
>
>pixel fog comes in two flavors:
>
>1) Eye-relative pixel fog ( or w-fog indicated by the
>D3DPRASTERCAPS_WFOG caps bit ) is preferred since it avoids certain
>fogging artifacts due to non-linear distribution of z values in the
>z-buffer.
>
>1) z-based pixel fog. If w-fog isnt supported you get z-based pixel
fog.
>
>if the driver doesnt implement pixel fog, fall back to vertex fox.
>
>vertex fog comes in two flavors:
>
>1) range based fog ( indicated by the D3DPRASTERCAPS_FOGRANGE caps bit
)
>uses the actual distance from the viewpoint to the vertex rather than
>the depth of the vertex; avoiding some rotational artifacts. If
>range-based fog isnt supported, you again get z-based fog.
>
>2) application fog. the application must use its own fog calculations
>when not using the D3D TnL pipeline. the fog factor is calculated and
>placed in the alpha component of the specular color, making specular
>really RGBF in that case.
>
>Regardless of which type of fog, pixel or vertex, you use - your
>application must provide a compliant projection matrix ( what the docs
>call a W-Friendly Projection Matrix ) to ensure that fog effects are
>properly applied. This restriction applies even to applications that do
>not use the Direct3D transformation and lighting engine. If the
>projection matrix isn't compliant with this requirement, fog effects
are
>not applied properly. This is covered in more detail in the D3D doc.
>
>so, to avoid really bad artifacts the order an application should
prefer
>fog features is:
> pixel w-fog
> vertex range-fog
> pixel z-fog
> vertex z-fog
> application fog.
>
>if the application isnt using the D3D TnL pipeline ( which is quite
good
>and has per-processor specific optimizations ) then its highly likely
>that application fog will produce the most uniform results since you
>control your own destiny by informing the iterator what values to
>iterate at each vertex.
>
>and, as always, one must be aware of the bad drivers out there which
>would modify that order of feature preference.
>
>****GetDeviceIdentifier allows a mechanism to identify card/drivers
that
>do not comply with the spec, and provide a last-chance method to
>fallback. Applications that depend on certain functionality should
>consider maintaining an internal list of offending card/drivers and
>performing a fall-back mechanism to ensure correct visual appearance.
>
>> -----Original Message-----
>> From: Kelvin Chung [mailto:[EMAIL PROTECTED]]
>> Sent: Thursday, May 17, 2001 2:57 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: [JAVA3D] Fog (Linear) Differing Results
>>
>>
>> >X-Sender: [EMAIL PROTECTED]
>> >Date: Thu, 17 May 2001 17:49:32 -0400
>> >To: Kelvin Chung <[EMAIL PROTECTED]>
>> >From: Mark Ferneau <[EMAIL PROTECTED]>
>> >Subject: Re: [JAVA3D] Fog (Linear) Differing Results
>> >Cc: [EMAIL PROTECTED]
>> >Mime-Version: 1.0
>> >
>> >Kelvin,
>> >
>> >In the body of the email I indicated J3D (Java3D) 1.2.1_01
>> for both OGL and
>> >D3D. I think, therefore, that this is a driver
>> issue--although I see it
>> >across different machines, boards, and operating systems.
>> So essentially I
>> >should probably not rely on fog looking reasonably consistent across
>> >different platforms or graphics boards.
>> >
>> >Therefore another method will have to be used to achieve the same
>> >effect. Would you agree with that statement?
>> >
>> Not sure. If it is a driver bug we should notify the graphics
>> vendor to fix it. I suppose driver should implement it
>> according to the fog formula.
>>
>> At least under Sparc Solaris the fog effect are consistent.
>>
>> - 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".
>>
>
>=======================================================================
====
>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".
