PDA

View Full Version : developers quiz - what kinda FILTERING?



jin choung
06-01-2004, 11:14 PM
howdy,

this is a question for the lw developers and a feature request at the same time:

WHAT KIND OF TEXTURE FILTERING DOES LW EMPLOY?

------------------------------------------------------------------------------------

the feature request is that we get with the program and start using some standardized language so that we don't have to be in the dark about such things and even have to ask.

------------------------------------------------------------------------------------

we DO have mip mapping right? that is called 'texture antialiasing' i believe... that should probably be renamed.

but there seems to be no way to control how the mip map levels are filtered - bilinear? trilinear? anisotropic? eh? eh? eh?

so in the absence of any kind of control over this, what is the default method? NO filtering? i doubt it... i would venture bilinear.... eh? eh? eh?

jin

p.s. eh?

Lightwolf
06-02-2004, 02:30 AM
Hi jin,
from my observations it depends on what area of LW you're talking about.
In texturing LW seems to use mip-mapped triliniar filtering when minifying a texture, and probably bilinear when magnifiying it. There is no anisotropic filtering involved whatsoever (unfortunately).
Reflection, refraction and projection maps aren't filtered at all it seems, especially obvious with enlarged projection maps (i.e. small map, large cone).

I've requested imrpoved filtering a couple of times, I guess NT know about it as well, I'm not sure on their priorities though.

EWA would be a great choice for textures (elliptical weighed average), and can be combined with mip maps plus does very decent anisotropic filtering, at a cost though (but well worth it imho, better than using a higher antialiasing level just to get a decent texture).

Cheers,
Mike - btw, no reason to scream ;)

hazmat777
06-02-2004, 02:50 AM
Your infiniMap plug-in looks amazing. Can't wait to get into it.

Lightwolf
06-02-2004, 02:58 AM
Originally posted by hazmat777
Your infiniMap plug-in looks amazing. Can't wait to get into it.
Lol, thanks... Now you know why I learned to much about texture filtering (...and I still have to implement most of it).
Cheers,
Mike

jin choung
06-02-2004, 08:13 AM
wow,

it does look amazing... how the heck does that compression scheme work?

and is it that with your shader, you're able to completely define your own filtering/mipmap settings?

interesting stuff. thanks for the insight.

jin

Lightwolf
06-02-2004, 08:22 AM
Originally posted by jin choung
it does look amazing... how the heck does that compression scheme work?
Hi Jin,
ECW files are wavelet compressed. In the near future I will support JPEG2000 as well.


and is it that with your shader, you're able to completely define your own filtering/mipmap settings?

Well, no directly. I have to replace LWs texturing engine completely, since infiniMap has to be able to dynamically load parts of the image file for texturing while rendering.
So I basically only load certain mip maps, and you can define a bias of how high res these should be (a memory vs. image quality issue).
Currently I use an image filtering scheme that is similar to LW, but I'm working on EWA as well.
Cheers,
Mike

jin choung
06-02-2004, 08:29 AM
doh!

hahaha, i was TOTALLY going to ask if it was related to jpeg2000! but i know diddly squat about such things so thought i'd spare myself some embarrassment!

hahaha... cool, i so my ability to see relationships is functional!

:)

jin

Mattoo
06-02-2004, 06:14 PM
Uh, dunno if this was answered, kind of went of on a tangent there, but I'm sure Texture Antialiasing has no relation to MIP mapping. I believe it does just what it says - and antialiases (blurs) the texure.

The reason I state this is because of its use in regard to Displacement maps - with Texture Antialiasing ON the mip mapping would be quite a bit more pronounced when applied to geometry... but there is no difference in apparent resolution of the displacement map at differing distances from the camera.

jin choung
06-02-2004, 08:30 PM
actually,

i think i got this from arnie cachelin when he was with newtek. that's when i finally discovered what the heck they were trying to say with that term.

here are a few examples i did at that time to prove what he said.

jin choung
06-02-2004, 08:35 PM
and with taa....

jin

Lightwolf
06-03-2004, 02:43 AM
Originally posted by Mattoo
Uh, dunno if this was answered, kind of went of on a tangent there, but I'm sure Texture Antialiasing has no relation to MIP mapping. I believe it does just what it says - and antialiases (blurs) the texure.
...by using mip maps :)


The reason I state this is because of its use in regard to Displacement maps - with Texture Antialiasing ON the mip mapping would be quite a bit more pronounced when applied to geometry... but there is no difference in apparent resolution of the displacement map at differing distances from the camera.
Of course not. What LWs texturing system expects to filter a texture is something called spot size. Basically the size of the spot in world coordinates of the current pixel (in the final image) being rendered.
For a texture mapped onto an object (using the shading/surface system), that spot size varies with distance to the camera (and should also vary with the angle of the shaded part of the object to the camera, but only does so badly, hence the anisotropic problems).
_However_ for displacement maps, the texture evaluation code gets passed a constant spot size, hence no mip-mapping / texture bluring there.

The main drawback currently is that the spot in LW is circular, i.e. it has a centre and a radius. For anisotropic filtering however, you need an elliptical spot size, i.e. a centre, two radii (and possibly an angle). This is currently not supported in LW, but can be done using a shader (alas, not in a procedural texture though).

Cheers,
Mike

P.S. If you want to dig deeper into the subject (texture filtering seems to be a science on itself ;) ), here are a couple of links out of google:
http://www-users.itlabs.umn.edu/classes/Fall-2001/csci5980/notes/Texture_Mapping1.ppt
http://www.cs.virginia.edu/~gfx/Courses/2001/Advanced.spring.01/ppt/lecture07.ppt
And especially:
http://www.cs.princeton.edu/courses/archive/spring04/cos426/papers/heckbert86.pdf

fxnut
06-03-2004, 07:45 AM
Originally posted by Mattoo
Uh, dunno if this was answered, kind of went of on a tangent there, but I'm sure Texture Antialiasing has no relation to MIP mapping.

Yep, you're correct. Mip-mapping is a technique used in almost exclusively in real time 3D engines. The 3D engine just stores smaller versions of each texture and uses the smaller versions of textures for polygons that are further away. In a sense, this is effectively pre-antialiasing the texture. So for a 256 square texture, you'd store a 128, 64, 32, and 16 square versions.

It would be extremely unlikely that Lightwave would use mip-mapping when performing a render, since the major problem with it is that you get discontinuities in the texture resolution. Lightwave uses the spot size to determine how much of a texture it needs to sample, and then interpolates from an image based on that value. Lightwolf is right when he states that elliptical spot sizes would produce a much better quality of antialiasing.

Regards

Andy

jin choung
06-03-2004, 07:52 AM
hey andy,

errrr... actually, you're quite wrong. sorry to contradict ya but when you are, you are.

mip mapping is used in both maya (explicit settings and labeled as such) as well as in lw (it's simply called texture anti-aliasing).

whether in real time or renders, the necessity for mip-mapping becomes clear in cases like my posted images... there's no way not to get that kind of aliasing artifact without mipmapping.

and yes, you do incur the issue with discrepancy between mip map levels but that is indeed the subject of this thread:

FILTERING. the kind of filtering that you employ determines how seamless the mipmap levels are.

jin

Lightwolf
06-03-2004, 07:54 AM
Originally posted by fxnut
Lightwave uses the spot size to determine how much of a texture it needs to sample, and then interpolates from an image based on that value.
...and this is where the mip map actually comes into play.
If you have a spot that, say, covers a quarter of your image, a naive approach would be to find the average of all pixels in that area. That would take ages for large images.
With mip maps, you basically only sample from the levels where one pixel (of the current mip-map level) closely approaches your spot size (actually, you tend to use the current level and the next higher, more detailed one, and interpolate between those -> trilinear filtering).

Btw, If I'm not entirely mistaken, the LW manual even states the memory requirements for the mipmaps generated by layout.

Cheers,
Mike

Lightwolf
06-03-2004, 08:02 AM
...as a simple test: Load an image and texture an object with it (use a huge image). Create one with image filtering on, one where you turn it off. Create two separate scenes.
Now compare the memory requirements (use the task manager in windows) of the two scenes when rendering. (Just to be on the safe side, re-open LW before you change scenes).
The scene without image filtering should take less memory (mind you, I haven't tried this with the current releases, but, if my memory serves me right, this did make a difference in 6.x).
Cheers,
Mike

...and while we're on the topic:
Pixel Blending only affects images that get enlarged (i.e. spot sizes smaller than a pixel of the texture), and is probaly some kind of biliniar, maybe bicubic filtering.
Also, I assume the blur strength associated with the texture antialiasing just massages the spot size (in its simplest form, it might just be a multiplier of the spot size).
...wildly guessing again ;)

fxnut
06-03-2004, 08:25 AM
I stand corrected :D I always assumed that when LW referred to mipmaps, it was talking about the texture preview in the OpenGL window. But what you said Lightwolf makes a lot of sense. I can see it would be faster to store the mipmaps than to have to recalculate the interpolation repeatedly.

Thanks for the heads up :)

Lightwolf
06-03-2004, 08:35 AM
Originally posted by fxnut
Thanks for the heads up :)
:) Anytime...

..just don't get me started on the other filtering techniques (did I mention SAT maps ? ;) ).
Cheers,
Mike - yeah, I know, I can be a geek sometimes... :cool:

Mattoo
06-03-2004, 01:35 PM
Originally posted by jin choung
actually,

i think i got this from arnie cachelin when he was with newtek. that's when i finally discovered what the heck they were trying to say with that term.

here are a few examples i did at that time to prove what he said.

Indeed you are right then. You're also right about its need for renaming. I allways just assumed that it was truly just bluring the textures (since that's what it does in the little preview window).

It never occured to me it was related to mip mapping. Learn something new everyday - as they say.

Mattoo
06-03-2004, 03:23 PM
Originally posted by Lightwolf
...by using mip maps :)

-SNIP-
Cheers,
Mike


Not exactly an appropriate response since it does just as I said. Texture Antialiasing is more than just mip mapping - otherwise why would it blur an image when used in regard to Displacement maps, but also when the pixels of said texture are larger than the screen pixels it's rendering to.

It's already doing pixel blending, so quite why it blurs it further in these instances is confusing to me.

I'm well aware of what mip mapping is, if I didn't I'm sure Sony would fire me on the spot, although granted, I don't have the deep understanding of it that you do.

I've always turned TAA off due to the added bluring, I had no idea it was tied to mip mapping - just assumed LW did that anyway - but just had badly implemented it.

Lynx3d
06-03-2004, 04:08 PM
@ Mike: I just wondered why you said you couldn't do it as a procedural texture, since you have to provide a pretty complete micropoly structure to evaluate a texture, but i just realized that not much of it makes it through to a procedural texture handler :(

Perhaps you could "cheat" with a shader and procedural texture in one plugin file, passing the micropolygon directly, and use the standard evaluation for the rest of the textures...hm but what happens if someone uses the procedural outside the shader...k stupid idea i guess :)

The next time you complain at Newtek about texture filtering in LW, add another vote from me ;)

Lightwolf
06-04-2004, 02:42 AM
Originally posted by Mattoo
Not exactly an appropriate response since it does just as I said. Texture Antialiasing is more than just mip mapping - otherwise why would it blur an image when used in regard to Displacement maps, but also when the pixels of said texture are larger than the screen pixels it's rendering to.

It's already doing pixel blending, so quite why it blurs it further in these instances is confusing to me.

Well, texture antialiasing uses mipmaps in Lightwave, so (in LW) they are related (though the terminology can't be interchanged). mipmapping in this context is just one (of many other) ways to reduce texture lookups during the filtering process.
Pixel blending is a different beast, and only concerns texture pixels that are larger than screen pixels.
Cheers,
Mike

Lightwolf
06-04-2004, 02:51 AM
Hi Lynx3D,

LWTextureAccess doesn't get the normal of the geometry to be shaded passed, and you'd need that to get the angle between the viewing ray and the surface to properly calculate an anisotropic filtering ellipse.
Funny enough, LWMicropol has that information, but is not accessible from a procedural texture (at least the last time I looked).

I'm not sure if a workaround is possible, this could get messy in multithreaded rendering. I also guess that hacking the workaround would take more time than actually sussing out the filtering :(

bummer :)

Cheers,
Mike

Lynx3d
06-04-2004, 04:46 AM
Originally posted by Lightwolf
Funny enough, LWMicropol has that information, but is not accessible from a procedural texture (at least the last time I looked).

Yea just what i found out, hasn't changed in LW8 unless they didn't update the SDK doku...


Originally posted by Lightwolf
I'm not sure if a workaround is possible, this could get messy in multithreaded rendering. I also guess that hacking the workaround would take more time than actually sussing out the filtering :(


Well all my plugins are pretty messy and most effort went into cheating LW to make it work :P

Also i think the shader access itself has to be changed radically, to be able to return values to the proper final buffers, also lights that produce multiple samples are returned as a weighted sample or something, at least shaders+area lights = crap... :(
Or is there something i missed? I already asked on the SDK yahoo-group ages ago but no answer. I stopped all my shader efforts, it's pointless.

Lightwolf
06-04-2004, 05:08 AM
Originally posted by Lynx3d
Well all my plugins are pretty messy and most effort went into cheating LW to make it work :P
Yep, that is what I hate about writing LW plugins (and I've just about covered every class there is).

I don't think you've missed anything. I guess this means a big hats of to Steve Worley for his coding efforts, not only because he produces very fast code, but because he puts all the effort into it to make it work from within LW (which, I'm sure, uses up more than 50% of his coding time).
Cheers,
Mike

Lynx3d
06-04-2004, 05:30 AM
Actually, i wouldn't have expected anyone to take the effort and write something like FPrime, it's insane somehow.
I'm almost sure 75%+ of the FPrime effort has to be integration with LW and the actual renderer suffers from that...
And apparently he's still breaking his head about a smoother integration, before he can push it to a sophisticated render engine.
I'm sure he could write improved texture filtering, AA, GI sampling, some photon mapping and all the stuff, but it's all about the realtime feedback for now, as that is the revolutionary feature of the product after all.

Btw, how good is FPrimes texture filtering? IIRC someone complained that it is actually worse than LWs.
Unfortunately my wallet doesn't want me to buy FPrime...

Lightwolf
06-04-2004, 05:45 AM
Well, fprime uses a completely different rendering paradigm, just about the opposite of, let's say, renderman.
While PRMan tries to render a perfect picture with one pass, FPrime renders extremely crudely, and uses the passes to add samples and improve the final quality.
I assume FPrime just evaluates the surface using the provided texture functions in the SDK (which would be the easiest way to do it), so the initial texture sampling is probably identical to what LW produces. I guess though that LWs _render_ antialiasing minimizes the artifacts a bit more than FPrime does with the passes.
If FPrime actually parses/evaluates the texture layers on surfaces, _then_ it could use its own texture filtering, but Steve would have to re-code all image texture mapping types as well.
One thing I know for sure is that FPrime properly filters projection maps, unlike LW.

I'm definetly guessing here now :)
Cheers,
Mike