Understanding Procedural Textures.


29-08-2014 01:03:54

I have been going over Ogre Procedural in detail for a project of mine and most of the features I've encountered this far have been understandable with the help of the documentation and a little bit of source diving. However in the Texture functionality in particular I have been running into road blocks over and over. I've been working around them but it's getting to be too many to work around so hopefully some of you can clear some things up. Most of these are related to the Texture filters.

Procedural::Threshold -
For the API, I don't understand what the "mRatio" member does, or why I would want to change it. What is this in ratio to/between? What is the common use case for changing it from the default? Why is it a unsigned char instead of a relative value [0.0-1.0]?

Procedural::Normals -
What is "mAmplify"? It's clear that this is for the normal calculation in both the API doc's and looking at the code...but why would I want to use it? And why is it an unsigned char instead of a relative value? Setting it to 64 default and then multiplying it by 4 prior to converting it to a relative value when processed causes it to have a weird scale that makes no sense to me. Are you trying to cause it to be capped to 4.0 amplification? If so, why?

Procedural::Lookup -
This is mostly an issue with the images in the API docs. As I understand it uses the relative values of the red and green colour channels in the parameter image to get the position of the pixel to retrieve, and places that colour at the current pixel position being processed in the result image. So! In the case of a generic Cell generator without it's mColour member being altered, all of the red and green channels would be the same value for each given pixel (but different sets of values from one pixel to the next depending on how white/black the pixel is, of course). If I understand texture addressing at this stage properly...this should mean that in your provided example all of the resulting colours in the final image should only be colours that exist in the very narrow line from the top left corner to the bottom right corner of this image:

The Green and Red portions of that image should be completely exempt. If so, where does the teal colour in the result image here come from?

Furthermore if Black is (0.0,0.0,0.0,1.0) and if I understand texture addressing at this stage then it should be fetching the colour at the extreme top left corner for every part of the parameter image that is black. In the case of your example, the colour to be retrieved is also black. But the example image you have generated shows it being blue, which is in the opposite corner I'd expect.

Lastly in the actual code where you are assigning the pixel colour to the temporary buffer before moving on you do this:
tmpBuffer->setPixel(x, y, mBuffer->getPixel(v, u));

The V and the U appear to be swapped. Is this by design or a bug? (Thus far I've assumed it was a bug)

Procedural::Light -
I do not understand the light position relative to the texture. I am trying to think of this in terms of 3D space. Is the light position as provided with the texture on a plane facing along the +Y axis? In the source code there appears to be some space conversion:
Ogre::Vector3 light(mPosition.x - 127.0f, -(mPosition.y - 127.0f), -(127.0f - mPosition.z));

What is the purpose of this? Can you help me visualize what is going on in 3D space with all this setup?

That is all for now, but I may have more as I keep on reviewing the library.