Hi Travis,
I agree, re: the scoping rules. For the actual file, I think we might want to have meta-tokens (e.g. like "rubber" and "chrome") and let the visualization app implement a series of known effects, rather than having a specific image technology.
- The number of "bumpy textures" in our brickset is, at least I think, relatively small.
- The rendering technology to be implemented might be rather variable.
For example, a fixed-function renderer could intentionally hack the specularity params to do gritty reflections and at least the overall specularity would be correct. But if provided with an actual bump map, if the renderer can't use it directly, it has no way to know what was intended. I think providing actual bump map images externally is most useful when
(1) the bump map must match the location of a texture map exactly (e.g. this is the extrusion of the painted thing you see) and/or
(2) when the bump map's UV-coordinate application is custom to the model, rather than just a repeating pattern.
The actual bump maps are typically 8-bits per channel; in X-Plane we hit the case where some very smooth, very shallow bump maps showed banding of specular hilites due to the precision limit. We solved this by in some cases adding a scaler factor so that the 8-bits of precision could be used for the full range of bump-perturbations or for high precision very subtle effects. While a number of normal mapping schemes are possible, tangent space bump mapping is often popular because the normal map can be used just like the texture it matches.
Some apps stash the original height map from which the normal map was derived into another texture channel; this lets the app extrude geometry or apply parallax effects to the normal map. (http://en.wikipedia.org/wiki/Parallax_mapping)
Cheers
Ben
I agree, re: the scoping rules. For the actual file, I think we might want to have meta-tokens (e.g. like "rubber" and "chrome") and let the visualization app implement a series of known effects, rather than having a specific image technology.
- The number of "bumpy textures" in our brickset is, at least I think, relatively small.
- The rendering technology to be implemented might be rather variable.
For example, a fixed-function renderer could intentionally hack the specularity params to do gritty reflections and at least the overall specularity would be correct. But if provided with an actual bump map, if the renderer can't use it directly, it has no way to know what was intended. I think providing actual bump map images externally is most useful when
(1) the bump map must match the location of a texture map exactly (e.g. this is the extrusion of the painted thing you see) and/or
(2) when the bump map's UV-coordinate application is custom to the model, rather than just a repeating pattern.
The actual bump maps are typically 8-bits per channel; in X-Plane we hit the case where some very smooth, very shallow bump maps showed banding of specular hilites due to the precision limit. We solved this by in some cases adding a scaler factor so that the 8-bits of precision could be used for the full range of bump-perturbations or for high precision very subtle effects. While a number of normal mapping schemes are possible, tangent space bump mapping is often popular because the normal map can be used just like the texture it matches.
Some apps stash the original height map from which the normal map was derived into another texture channel; this lets the app extrude geometry or apply parallax effects to the normal map. (http://en.wikipedia.org/wiki/Parallax_mapping)
Cheers
Ben