Ogre Forums

Warning - longish post.
This is an early attempt at creating something basic out of max :


This the material file that has been generated :

material Material_#11/trunk
{
technique
{
pass
{
ambient 1.0 1.0 1.0
diffuse 1.0 1.0 1.0
specular 0.0 0.0 0.0 0
emissive 0.0 0.0 0.0
scene_blend one zero
depth_check on
depth_func less_equal
depth_write on
depth_bias 0
cull_software back
lighting on
fog_override false
shading gouraud
colour_write on

texture_unit
{
texture DRIFTWD.JPG 2d
tex_address_mode wrap
filtering linear linear point
colour_op modulate
scroll 0.0 0.0
scale 1.0 1.0
rotate 0.0
}
}
}
}

material Material_#11/leaves
{
technique
{
pass
{
ambient 1.0 1.0 1.0
diffuse 1.0 1.0 1.0
specular 0.0 0.0 0.0 0
emissive 0.0 0.0 0.0
scene_blend one zero
depth_check on
depth_func less_equal
depth_write on
depth_bias 0
cull_software back
lighting on
fog_override false
shading gouraud
colour_write on

texture_unit
{
texture Palmfrnd.jpg 2d
tex_address_mode clamp
filtering linear linear point
colour_op modulate
env_map planar
scroll 0.0 0.0
scale 1.0 1.0
rotate 0.0
}
}
}
}

This looks OK in the mesh viewer but looks black in the game :



Any ideas as to what I have done wrong ?

Does the exporter really create this horrible material files? Every option that is possible is listed with their default. Very hard to see anything this way.

Anyway. The problem here probably is that the exporter generated the material names in the mesh file and the material names in the material file differently. Material_#11/leaves in the material file is Material #11/leaves in the mesh. (no underscore) You can either change it by hand in the files, or stop using default material names (don't know max, so no idea what to do exactly). As the bug only happens with default names iirc.

Look into your Ogre.log to see wether the materials have been found.

There are no material errors in ogre.log and here is extract from mesh xml :

<mesh>
<submeshes>
<submesh material = "Material_#11/trunk" usesharedvertices="false" use32bitindexes="false">
<faces count="352">
..
..
</submesh>
<submesh material = "Material_#11/leaves" usesharedvertices="false" use32bitindexes="false">
<faces count="520">

There are two extra materials which I didnt show in materials file which were also exported :

material leaves
{
technique
{
pass
{
ambient 1.0 1.0 1.0
diffuse 1.0 1.0 1.0
specular 0.0 0.0 0.0 0
emissive 0.0 0.0 0.0
scene_blend one zero
depth_check on
depth_func less_equal
depth_write on
depth_bias 0
cull_software back
lighting on
fog_override false
shading gouraud
colour_write on

texture_unit
{
texture Palmfrnd.jpg 2d
tex_address_mode clamp
filtering linear linear point
colour_op modulate
env_map planar
scroll 0.0 0.0
scale 1.0 1.0
rotate 0.0
}
}
}
}

material trunk
{
technique
{
pass
{
ambient 1.0 1.0 1.0
diffuse 1.0 1.0 1.0
specular 0.0 0.0 0.0 0
emissive 0.0 0.0 0.0
scene_blend one zero
depth_check on
depth_func less_equal
depth_write on
depth_bias 0
cull_software back
lighting on
fog_override false
shading gouraud
colour_write on

texture_unit
{
texture DRIFTWD.JPG 2d
tex_address_mode wrap
filtering linear linear point
colour_op modulate
scroll 0.0 0.0
scale 1.0 1.0
rotate 0.0
}
}
}
}

Do not think these matter as they are not referenced by mesh.

Delete all lines:
ambient 1.0 1.0 1.0
diffuse 1.0 1.0 1.0
specular 0.0 0.0 0.0 0
emissive 0.0 0.0 0.0
scene_blend one zero
depth_check on
depth_func less_equal
depth_write on
depth_bias 0
cull_software back
lighting on
fog_override false
shading gouraud
colour_write on


In you material.
Those line are useless because it is all set to default parameters.
And also:


tex_address_mode clamp
filtering linear linear point
colour_op modulate
env_map planar
scroll 0.0 0.0
scale 1.0 1.0
rotate 0.0

It appears to be a problem with lighting. When the tree is reduced in size the top of it is textured correctly.

My guess : invert the normals on all the faces. You can do that inside 3DS max before exporting.

edit : i just read your last post ! almost sure it s a normal problem now, because you probably resized the tree without normalizing the normals. Invert th enormals inside Max before exporting and when you resize your tree use Entity:: setNormaliseNormals

Each time your do a scale operation on an Entity you need to normalize the normals. The normals are used by hardware for lighting process, their lenght must be equal to 1.

use only this to debug, then add all you need. If you see the textures the material is bad formatted, see Ogre.log maybe is something there. if you don't see the textures the model is bad.

other way is not scale the model, i see in practice that if you scale the model in 0.5 0.25 or 0.33 (is what I test) the model is black. no matter what you do. not scale.

I have done further testing just using a simple box from max :



With normals inverted :



This is what is how max shows it:



My material file is now simplified to :

material Material_#25
{
technique
{
pass
{
texture_unit
{
texture terrain_detail.jpg

}
}
}
}

I tried the ogre head mesh in the scene and it showed up correctly.

You don't seem to be looking at the Ogre.log - this is an essential piece of information when debugging things like this.

did you tried your model with normals inverted ??? It s possible that the max script which calculate the normals only do it good in some situations. So this can explain the cube hadn t to have its normals inverted, but the model you showed us need it. Please try your model ( the palm ) with normals inverted and tell us if it s working or not. ( of course don t scale it for a first try ).

You ll maybe ask me why the cube is transparent in some areas and not black lilke your first mode: the answer can probably be that you played with the parameter cull software

BlasterN
other way is not scale the model, i see in practice that if you scale the model in 0.5 0.25 or 0.33 (is what I test) the model is black. no matter what you do. not scale.

As far as i know this is totally wrong. Everything is working good, you only have to normalize the normals after a scale like in all realtime 3D...

@ Sinbad : he does -> "There are no material errors in ogre.log"

Once I had checked "export uv sets" when exporting - everything came right.
I was thinking that I only had to check that when I used UV unwrap on the model but I was obviously wrong....

I am a little confused as to what exporter I should use - the one in ogreaddons or the Octopus exporter.
My experience with them is that the octopus exporter seems to have better material options but the ogreaddons exporter has better animation options.
Anybody else have any thoughts on these exporters.

I recomment using the Octopus one as it is more actively maintained. (as it's based one the 3dsexporter, I don't understand why it would provide less animation support though)

Hello,
Here is who can you helped.
In 3ds max, when you has some texture on a mesh, it is necessary to take a slots materials free and to resume quite your textures with the pipette, what goes created one materials multiple then has the export marks « export UV sets » without what the model is quite black.
I take advantage of it for rested my problem with models animated, without marked this compartment model every black but the model is perfectly animated, on the other hand if « export UV sets marked » the model is completely destroyed thank you for your answer.

Hi,

actually, the octopus exporter does prevent to have non biped objects in a biped object. I had a model that had some additional, handset bones attached to the biped model which was skinned.

I was not able to export the skeleton of that model. The octopus exporter always threw an export error telling me that a non biped object is in the skeleton. !This is not nice!

Best regards,
Metron