User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)
Hardware before Shader Model 3 (NV40's at the moment) have 8 high
precision iterators and 2 low precision iterators.
Low precision iterators are 9 bit unsigned integers, hence clamping is
required by the hardware. These 2 iterators have always been the colour
ones with the high precision being used for textures.
SM3 hardware has 10 high precision iterators, so the problem goes away.
Also note the render target format your rendering to will affect the
fragment shader clamp behavior, if you render to a high precision
(float) format than clamping is disabled in the fragment shader output.
Deano
Joshua 'Schwa' Gargus wrote:
>Hi,
>
>By trial and error, I determined that the COLOR output of
>my vertex program was being clamped to the range [0,1].
>I would have expected that the clamping would occur only
>on the output of the fragment program. I worked around
>this by storing the value in TEXCOORD0 instead.
>
>Where is this information documented? I couldn't find it
>in the Cg Toolkit User's Manual.
>
>I don't like this behavior, it seems too much like magic.
>I understand why the fragment color output needs to be
>clamped, but it doesn't seem necessary for the vertex
>color output.
>
>I think I read once that it is possible to create your own
>custom semantics, but again I couldn't find this in the
>User's Manual (maybe I read it in the Cg Tutorial book,
>which I don't currently have access to). Is this true? If
>I am imagining this, the rest of the paragraph does not
>apply. Is it possible to create a custom semantic that
>clamps the value passed from the vertex to the fragment
>program? If not, this is an example of what I mean by magic:
>an un-/poorly-documented exception to the core model of
>the language/runtime that can only be achieved by hacking
>the framework itself (not just by using the framework).
>
>Maybe I'm missing something obvious about why this clamping
>behavior is intuitive and/or necessary. If so, please
>enlighten me.
>
>Thank you,
>Josh
>
>
> _______________________________________________
>Do not post admin requests to the list. They will be ignored.
>Mac-opengl mailing list (email@hidden)
>Help/Unsubscribe/Update your Subscription:
>http://lists.apple.com/mailman/options/mac-opengl/email@hidden
>
>This email sent to email@hidden
>
>
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 27/03/2005
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden
This email sent to email@hidden