Hi,

I've tried to export a normal map applied to a geometry from 3D Studio Max using osg exporter. Normal map is placed in Bump map slot as UV channel 2 under maps, in material slot. After exporting the geometry as osg, i cannot see my normal map in the images folder. Is this the correct way of exporting normal maps? I need some suggestion regarding using per pixel lighting and normal maps in Delta3D.

Thanks

Hi,

The Max OSG exporter probably does not handle exporting bump maps. You will have to do a little work outside of Max in order to enable bump mapping in Delta3D.

I would suggest studying the delta3d/examples/testBumpMap example to see how that is accomplished.

-Erik

Hello

If it's just to get the normal map into your file, osgexp in max only does 2 channels on export currently.
Those are Diffuse-Color and Self-Illumination, and for the self-illum you must make sure the check box is on in the material section for this feature. diffuse comes out as texture unit 0 and illum as unit1.

try looking at the bump mapping tutorial for how to use these.

Mr. D

Hi,
Thanks for your suggestions.



We've used osg exporter to export a 3D Studio max scene containing upto 4 UV channels and it handled well .The osg file contains all the 4 UV as texture units from 0 to 3.

Regarding per pixel lighting, we've gone through the Bump mapping example, actually the programs creates a cube by providing the vertice's manually and loading the diffuse and normal maps as separates files into the scene and lighting is computed. For a simple scene it is works good, but is it a feasible solution to load a normal map as a separate image file and bind it to the geometry (in the file)? :-)

We need some suggestions on performing per pixel lighting for a whole scene and not for a single object. We think it is better to capture the normal information in the file, that works for a lot of generic scene.

Any suggestion for capturing the normal information in the file using 3D Studio max?

Hi saransiva, please see the version of testBumpMap that is checked into the trunk of Delta as the example has been completely rewritten. It now works for arbitrary geometry but still calculates the tangents on object load. It also uses the shader manager to apply a phong shaded bump. You might find it more useful.

I took a look at the testBumpMap example in the latest version of delta3d and I'm still unclear on how to implement shaders on more complex geometry than just a sphere or cube.

Do you have to calculate tangents for all vertices for an entire model if you want to use a bump map shader? can anyone provide an example of using bump maps with more complex geometry?

Typically, you have to either export the tangents from your art tool (max, blender, etc...) or you must generate them at run time from the mesh. I believe most games take this approach, even with complex geometry.

TestBumpMap actually showcases a 2nd option. It's called "attributeless" bump mapping since it doesn't require tangents at all. This is possible because the tangent basis is computed in the fragment shader (per pixel). To see this in action, change the bool value in the TestBumpMapApp constructor from "true" to "false" like so:



Keep in mind that although this doesn't require precomputing the tangent, it does place a heavier burden on the GPU.

Thanks GMan,

I'm actually starting with Openflight files (using Creator as my modeling tool). Any idea if it is capable of generating tangents? I assume that the tangent information is saved in a separate file or in the attributes of the model? Is that right?

As for the Attributeless shader, aside from the increased to GPU processing, are there any other advantages or disadvantages to this approach?

I don't have any experience with Creator so i'm not sure what's possible with it. If the tangent information was exported with the model then I would expect it all to be together inside the file with an additional 3 floats for every vertex used to represent the tangent vector. ...Is there something preventing you from just generating them at runtime?

After taking another look at the attributless bump shader, it does appear that there are a few kinks to be worked out. There is something strange with the way the transformations interact with the light direction. This can be seen in the vertex shader as the following:



Also, the specular contribution looks incorrect. Any help fixing these issues would be greatly appreciated.
The technique was taken from ShaderX5 (Chapter 2.6: Normal Mapping without Pre-Computed Tangents by Christian Schueler)