Textures - any way of using a normal map?

  • Sarah Cartwright

    I just wondered if there's a way of adding anormal map to a texture?

  • Luke S

    Luke S - 2015-11-22

    @Sarah: welcome to AOI! There is no current way to use a tangent space normal map, though this does come up from time to time. AOI currently uses a hight-map type bump map in its image mapped and procedural textures. There does not seem to be any major obstacle to adding normal maps, though, as internally the rendering system translates the bump map to normals.

    All we really need is to add bit of UI, and tweak the file format to be able to save it. @peter, should we think of adding this to the list for 3.1?

  • Peter Eastman

    Peter Eastman - 2015-11-23

    It's a little more complicated than that. The value that gets stored in a TextureSpec is the gradient of the bump height function. Given that and the local surface normal (that is, the normal of the true surface), the renderer can calculate the perturbed normal vector to use for rendering. But having the texture directly specify a normal direction would require a change to the infrastructure.

  • Luke S

    Luke S - 2015-11-23

    Indeed. A little more digging, and I'm starting to understand better... At least, to have better idea of what I'm missing. What threw me was that the bumpGrad is stored as a vec3, just as a tangent normal would be. Missed that the application math would be different...

  • Pete

    Pete - 2015-11-23

    This'd abslolutely be a very good feature to have, when you need to scale bumped or displaced textures. Would a simple solution be to use the scaling information (from the mapping) into the bump height as well? Mapping affects everything else.

    One other thing, that I have been wondering (not used lately though) is, that the same information as a bump map or a displacement map produces a different outcome. As I recall a bump map needs to be made about 4 times stronger to have a simlar effect. -- I dont know if that is intentional though.

  • Luke S

    Luke S - 2015-11-29

    @pete: sorry for letting this drop.

    I've noticed the issues with scaling displaced textures myself. Might be worth fixing, as in some cases there is no good work around, and I'm not clear as to why scaling the texture with the object does not also affect the bump height/displacement height

    What I've learned is that normal mapping, at least in the fashion discussed, has a very different approach from the existing bump mapping.

    @peter: if one wanted to add support to for a normal map, then, what would it look like? I'm now imagining:

    • another entry in texturespec
    • Associated ui link points in the image and proceedural systems
    • of course, the implementation to take use the data in the rendering stage

    Also would be nice to be able to generate such map from a more complex model, but that requires better UV mapping to be viable.

  • Pete

    Pete - 2015-11-29

    What I've learned is that normal mapping, at least in the fashion discussed, has a very different approach from the existing bump mapping.

    Oh.... My thoughts were on a wrong track entirely.... Just remembered these things:

    With these I was experimenting with a hidden texture layer, that contained the information how the hair should grow, including length, stiffness, density and direction as colors. The strongly modified "Hairy"-script was then reading the colour channels of the hidden layer. (The green one probably shows best the idea.)

    A bit of an unorthodox hack and that is not exactly a normal map but a more general vector map. The idea was basically (in the case of direction) that RGB represents XYZ and 50% gray is a zero-vector. Of course the visualisation for a 'real' vector map should need to be somehow more obvious than a mix of RGB channels wired into colour outputs of a 3D-texture, but I guess that's a kind of a start..

    Here's another one...

    The hairs were placed on rendering triangles with some kind of a statistical system (density, surface area, a random generator...). The problem was that some triangles changed their size so much, that the number of hairs growing on them changed and then all the hair drawn after that triangle got a different pattern. Hence the flickering. I should have used a stiff copy of the troll to map the hair and just copied the (barycentric) triangle coordinates to place each hair on the actor.

    Normal/vector fields should provide interesting possibilities. :D

    Last edit: Pete 2015-11-29
  • Peter Eastman

    Peter Eastman - 2015-11-29

    It doesn't really make sense to provide both a normal direction and a bump gradient. Those are just two different ways of specifying the same thing. Possibly the thing to do is replace the bumpGrad field in TextureSpec with a different field to store the actual normal direction. So the computation currently done by the RTObject would get pushed down a level, to the RenderingTriangle.

    We then have the question of what to do with the UI. The user would specify either a bump map or a normal map, not both. So we have to figure out how that would work.

  • Pete

    Pete - 2015-11-29

    Yeap. I guess the input should still be the bump height, as it is rather difficult to define normal directions for example by an image... But if it'd be handled as a normal map in rendering, then the user would not have to worry about the scaling after texture mapping.

    What Sarah originally said was "add a normal map" .... Makes me think if she meant importing a normal map from an outside source in some kind of a vector format? -- I don't know how these things are handled in the rest of the world. :)

    Last edit: Pete 2015-11-29
  • Luke S

    Luke S - 2015-11-29

    What the UI for an image mapped texture should look like would be fairly simple.

    • use the same image selection that is currently for bump mapping, except:
    • add radio button to select between bump height and normal modes
    • in the normal map mode, users can select what level of blue maps to z=0 (most map generators use 128, but there is one that uses 0)

    UI for procedural textures might be trickier. Perhaps: an additional texture property, along with the AA property, that would switch between bump-height mode, and normal mode. In normal mode, the bump channel is a color channel. I'd expect most procedural textures would wish to still use bump height.

    The applying of a normal map should, I'd expect, be done at the same location bump grad is currently applied, just switch the math over, and make sure bump height inputs are converted to normals, rather than gradients.

    @pete, looks like you could use a more generalized sort of vector map, especially if a lot of that data is being generated procedurally. If most of the data is being imported as images, using a texture as a go between seems reasonable for now. If we implement a normal channel, it would only be good for directions, as by definition these are normalized vectors, ie unit length.

    EDIT: @Pete, We are definitely talking about inputting a normal as a vector, as an alternative to a bump height. These are commonly stored in a standard RGB image, with the color components representing X,Y,Z. The image is mapped to the surface using the standard UV mapping facilities.

    Last edit: Luke S 2015-11-29
  • Pete

    Pete - 2015-11-30

    looks like you could use a more generalized sort of vector map, especially if a lot of that data is being generated procedurally.

    I guess so. At the time I was thinking that a hair-tool with those kind of properties would be nice but I have come to think that behind that there could be a more generic vectorfield tool. Though I'm not sure what to do with that information then. :D


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks