FX Composer 2.5 Render to Texture ?

Hello,

I read in the user guide that FX Composer 2.5 is able to "Render to
Texture".

But no further explanation or example is given ?!?

Can somebody give me a clue how this could be done ?

I think it might be usefull for debugging purposes ?!?

Also is it possible to save the texture to a file ?

Bye,
Skybuck.

Ok,

What I am after is something that can explain it...

And apperently it's called "SAS" or "SASS"... I have seen people mention
this...

It stands for:

"Standard Annotations and Semantics"

And a document about it is here:

http://developer.download.nvidia.com..._SAS_v1_01.pdf

This document does not come with FX Composer 2.5 nor does it come with the
cg toolkit.

So it must be downloaded/viewed seperately ! It boggles the mind !

Anyway this should sooner or later be integrated into the FX Composer help
file because without it understand the cgfx files would become pretty
difficult if not impossible, and that would also prevent creating them from
scratch or modifieing them successfully ?! Especially for complex examples
?!

Basic examples would be very nice to start with it !

Now me go read it some more !

(It also has a section about render to target and such ! )

(Don't know yet if it can also do a save to image... ? I would expect it
would somehow be possible )

Bye,
Skybuck.

Even this document does not completely describe what's needed to work with
textures... be it input or output.

There is another concept which is necessary to fully understand textures...
it's called "samplers".

tex2D function "samples" from texture, or to say it in other words, "it
takes a sample from a texture".

Sample being some kind of point/texel/color.

This is were presumably filtering comes into play... maybe something I once
heared about "subpixels" or so...

So when a texture coordinate falls between "texels" then it could be
interpolated/subtexeled

Lineair probably means no subpixeling/subtexeling it rounds to nearest real
texel.

Bi-linear... not sure it might take two coordinates/texels and take the
average color of that.

Tri-linear... is probably three coordinates around the text coordinates and
takes the avage color of those three texels.

When dealing with gpgpu programming this interpolating feature might not be
desired... so setting it to lineair might give best results... though the
texture coordinates should end up on texels anyway.. but still... using
anything else might give slight floating point drift... or if coordinates
are of by 0.5 might screw it badly... so it seems wise thing to do... though
enabling this interpolating stuff could indicate if the coordinates are
proper or inproper

That's my theory at least !

Finally here's a link to another little document/tutorial explaining
samplers a bit... there is probably more official documentation available
somewhere... <gje hmm talk about fragmented documentation ! >

http://http.developer.nvidia.com/CgT...chapter03.html

Bye,
Skybuck.

Mon, 21 Sep 2009 04:02:00 +0200 schrieb Skybuck Flying:

> Lineair probably means no subpixeling/subtexeling it rounds to nearest
> real texel.
>
> Bi-linear... not sure it might take two coordinates/texels and take the
> average color of that.
>
> Tri-linear... is probably three coordinates around the text coordinates
> and takes the avage color of those three texels.
>
> When dealing with gpgpu programming this interpolating feature might not
> be desired... so setting it to lineair might give best results... though
> the texture coordinates should end up on texels anyway.. but still...
> using anything else might give slight floating point drift... or if
> coordinates are of by 0.5 might screw it badly... so it seems wise thing
> to do... though enabling this interpolating stuff could indicate if the
> coordinates are proper or inproper
>
> That's my theory at least !

No. Normally (in the context of modern gpu rendering), even plain
textures are 3D pyramidal objects, when they are mipmaped (the normal
picture plus serveral downsampled versions). Mipmapping is mainly used
to improve image quality, but also to lower memory bandwith consupmtion,
of course.

Shaders normally only need two address 2 dimensions (the hardware
then automatically derives the mip-level to use).

For mipmapped 2D image textures, linear and bilinear filtering
is the same thing. The resulting color is lineary interpolated
from a square of 4 pixels:

result = ( fx) * (fy*c0 + (1-fy)*c1)
+ (1-fx) * (fy*c2 + (1-fy)*c3);

where fx and fy are the fractions [0..1] of the texture adresses
and c0..c3 are the texture contents.

In this case (linear or bilinear) filtering, only one mipmap-level
of the texture is sampled.

Trilinear filtering then adds a linear interplotation with one more
mip-map level, giving smoother miplevel transitions.


One problem with this linear filtering is that there only exists
one mipmap-level "z" coordinate. Everything is fine as long as
the textured surface is parallel to the screen and rendered
evenly scaled. If it is not, then the hardware won't have a
chance to choose a good mip-level for the texture fetch using
above mentioned methods (one of the xy coordinates will change
much faster then the other with respect to screenspace
[change per pixel]). The hardware also accelerates anisotropic
texture filtering for this reason. This kind of filtering
does something similar to the linear filtering, but separetly
takes the rate of x and y changes per fragment into account
(by blending even more texels).

The thing you wre talking about (fetching nearest point) is
called "point sampling", or simply "no filtering".

Gruss

Jan Bruns

On Sep 21, 4:02*am, "Skybuck Flying" <BloodySh...@hotmail.com> wrote:
>
> Bi-linear... not sure it might take two coordinates/texels and take the
> average color of that.
>

Nope.

> Tri-linear... is probably three coordinates around the text coordinates and
> takes the avage color of those three texels.
>

Um, no.

> That's my theory at least !
>

Why have "theories"? This is all well documented, don't you
think it would be better to know the truth instead?


--
<\___/>
/ O O \
\_____/ FTB.

Skybuck Flying wrote:

> That's my theory at least !

Stop theorizing. Read the documentation, it's all there:
http://www.opengl.org/registry/

Your questions about texture rasterization are all answered in detail in
<http://www.opengl.org/registry/doc/glspec21.20061201.pdf> chapter 3.8


Wolfgang
--
OpenGL tip #42:
How to exactly map texture texels to screen pixels:
<http://preview.tinyurl.com/cgndc8>

Shut the f u c k up