Texturing

(L) [2006/07/21] [River] [Texturing] Wayback!

A little survey.

How are you guys dealing with texturing.  More precisly, what filtering method did you implemented in your ray tracers?  It is pretty easy to do linear interpolation, but as soon as you have a texture that is a little bit too far away, you get flickers, except if you start to multisample like crazy, in which case, you are not realtime at all!!!

In my one small test ray tracer (using good old KdTree with SAH if you are wondering, but since I've seen that paper on BIH, I'm thinking about redoing everything [SMILEY Smile] ) I have been able to get to a not so bad result in implementing mimaps (and doing trilinear filtering), however, it quickly became quite complex for secondary rays (like shadows, reflections, ...).  My main problem is in finding which mimap level to use!  No as obvious as with rasterizers if you consider that a curved surface doing reflections could create a "zoom in" or "zoom out".  So using a simple distance and angle from the viewpoint cannot do the job (not for secondary rays at least).  Is there any papers anywhere about that subject?  I have not found anything   [SMILEY Sad].

Anyway, I'm starting to do a small analysis and planning for my new implementation with BIH and since it is a problem I have ran into, I was wondering what you guys are doing.  That could give me good ideas!

Thanks everyone

(L) [2006/07/21] [madmethods] [Texturing] Wayback!

The paper you're looking for is "Tracing Ray Differentials" from SIGGRAPH 99: [LINK http://graphics.stanford.edu/papers/trd/]

It describes how to track the equivalent of the mipmap detail value for rays, as they bounce around in a Whitted-style ray tracer. There is an extension for beyond-Whitted-style ray tracing as well, can't remember the exact paper title, just search for "path differentials".

The sooner people start implementing this stuff, figuring out the pluses, minuses, efficient implementation techniques, or even alternatives, the better off we'll be. Differentials or the equivalent are good for all sorts of things (mipmapped textures, self-antialiasing programmable shaders, adaptive tessellation, LOD, eliminating surface acne more robustly, and just estimating ray density for all sorts of reasons).

-G

(L) [2006/07/21] [tbp] [Texturing] Wayback!

In quadrille i was doing bilinear filtering. Always. That was as far as i was willing to go given all my textures were stored as HDR. Always.

Then if you're paying for AA, it should also help. After that point i doubt you have memory bandwidth & cycles to spare.
_________________
May you live in interesting times.

[LINK https://gna.org/projects/radius/ radius] | [LINK http://ompf.org/ ompf] | [LINK http://ompf.org/wiki/ WompfKi]

(L) [2006/07/21] [River] [Texturing] Wayback!

madmethods : Thanks.  Results in the paper look quite interesting.  Now the question is how well it can be implemented.   I'll look into it!

tbp : For AA, I was doing AA only on polygon edges and only where the difference in color with surrounding pixels was high enough.  So that does not help me with texrtures.  About memory bandwidth and cache, I think mipmaps can even help in some cases (like on GPUs).  When you have a polygon with a texture that is far away, you will only use smaller mipmaps, so at the end, you are usign a smaller resolution texture, so less memory is used, more cache friendly.  But that always depend on the type of scene you want to render.  I agree with you, to render models like budha (a single model, not a complete environment), it is overkill.

toxie : Your link is broken (in fact, the .pdf in the web page) [SMILEY Sad] Found it trough google at : [LINK http://graphics.pixar.com/RayDifferentials/paper.pdf].  [SMILEY Very Happy] Took a quick look, and is it me or it is not talking about texture filtering?

(L) [2006/07/22] [madmethods] [Texturing] Wayback!

You should separate the question of filtering from the question of whether you have a MIP-mapped texture. You can do any kind of filtering you like on a MIP-mapped texture (nearest neighbor, bilinear, trilinear, anisotropic, EWA, ...).

In terms of cost overheads, using a MIP-mapped texture is generally a memory performance win over using the base texture. If you just do bilinear from one MIP-map level instead of doing trilinear, then the computational cost of filtering is identical to non-MIP-mapped bilinear. You do have the computational overhead of tracking ray differentials and calculating the MIP-map detail level from them, though.

-G

(L) [2006/08/14] [janos] [Texturing] Wayback!

Here's some info that might prove itself useful.

I've been following all of you guy's work passionately, and I've been eager to contribute, so there I go!

I have been developing shaders for graphics hw for some time now, and I always was stunned by the fact that the graphics hw always managed to pick out the right mipmap (of mipmaps in case of trilinear filtering) for the textures used in a shader. I could try to hint it by giving derivatives, but it would always slow down the rendering without any quality benefit.

For straightforward interpolated across the primitive texture coordinates, it is obvious, but when the texture coordinates are themselves computed by the shader, things become more tricky.

Here's a (hell of a) educated guess on how the hw does this :

Shaders are not evaluated separately on each pixel (i'm sure everybody here knows that much:),

shaders are computed on at least 2x2 pixel blocks. That implies that when it comes to texture reading, four samples are going to be read from the texture at the same time. They cover a quad (sic), which size can be used as an estimate of the texture coordinate derivatives at each point. Of course, this is a little bit biased value, because the derivative computation is not centered around any of the samples, but it does the trick.

Putting this in a RT system will have its intricacies, since you have to wait for the rays of a 2x2 packet to reach primitives with the same material to run the shader, but you will have to do this anyway if you plan to SIMDize your shader computations over several pixels.

This method is much cheaper than explicit derivative computation from the shader (which can be done, "à la" ray tracing differentials, but is really overkill), and has the advantage of being to derive any kind of texture coordinate computation function, especially one that would itself use a texture lookup in the process (An easy example would be a environment cubemap (don't shoot me, it's just an image) pure specular lookup from a reflection vector computed using a normal map).

At this point, the texture coord quad can be used as a source for any kind of texture filtering.

Texturing back