Radakan's OgreLoader & alpha value of material properties

archive contribution-depot-jme2
1
post edit:

Oops, 2 things: 1) I am not a committer and 2) this is *not* a jME defect.
Maybe better to move this post to:
http://www.jmonkeyengine.com/jmeforum/index.php?topic=9097.0

?

Thank you,
foxat
end

Hi all,

I think I discovered a simple bug on OgreLoader MaterialLoader class (got the latest version from SVN).

public ColorRGBA readColor() method correctly read the alpha value of parameters like ambient, diffuse, specular, etc. But it also overrides this value with 1.0F.
See line 140:


131    public ColorRGBA readColor() throws IOException{
132       ColorRGBA color = new ColorRGBA();
133        color.r = (float) nextNumber();
134       reader.nextToken();
135        color.g = (float) nextNumber();
136        reader.nextToken();
137        color.b = (float) nextNumber();
138        reader.nextToken();
139        color.a = (float) nextNumber();
140        color.a = 1.0f;
141        color.clamp();
142       return color;
143    }



Here's the diff:


Index: MaterialLoader.java
===================================================================
--- MaterialLoader.java   (revision 644)
+++ MaterialLoader.java   (working copy)
@@ -137,7 +137,7 @@
         color.b = (float) nextNumber();
         reader.nextToken();
         color.a = (float) nextNumber();
-        color.a = 1.0f;
+        //color.a = 1.0f;
         color.clamp();
         return color;
     }

2

Blaine has taken up this issue at http://www.jmonkeyengine.com/jmeforum/index.php?topic=9097.0.

3

The reason is that it doesn't really make sense to have an alpha value in material parameters. This will e.g require special handling in a shader to support this kind of functionality. Transparency information should be stored in the diffuse texture.

4
Momoko_Fan said:

The reason is that it doesn't really make sense to have an alpha value in material parameters. This will e.g require special handling in a shader to support this kind of functionality. Transparency information should be stored in the diffuse texture.


This question probably arises from incomplete understanding on my part, but would you not use the material alpha setting (with no texture involved) to model colored glass?... come to think of it, I have modeled glass that way, without the involvement of Ogre, in the past.
5
blaine said:

This question probably arises from incomplete understanding on my part, but would you not use the material alpha setting (with no texture involved) to model colored glass?... come to think of it, I have modeled glass that way, without the involvement of Ogre, in the past.

I suppose you can do that. But really, have you ever seen these kinds of models used in games or even detailed 3D applications? The only use for this is for importing a basic model into the viewer and seeing the correct effect. I guess it's okay to support this, but:
1) Only support this functionality for diffuse colors.
2) Never accept zero alpha values (replace with 1.0) otherwise incorrectly exported models will be invisible and you won't know what is going on.
6
Momoko_Fan said:

blaine said:

This question probably arises from incomplete understanding on my part, but would you not use the material alpha setting (with no texture involved) to model colored glass?... come to think of it, I have modeled glass that way, without the involvement of Ogre, in the past.

I suppose you can do that. But really, have you ever seen these kinds of models used in games or even detailed 3D applications? The only use for this is for importing a basic model into the viewer and seeing the correct effect.


I do lots of stuff that I have not seen before, and one thing I do a lot is to use Blender to create models using nested Blender Objects of the most simple type required.  I like jME because I can benefit from performance enhancing designs that I have not seen elsewhere.  To give a specific example bearing on the case at hand, I would like to be able to model drinking glasses using a simple cylider with realistic diffuse and specular coloring.


I guess it's okay to support this, but:
1) Only support this functionality for diffuse colors.

I've defended a use case for non-difficuse transparency above.  A specular value between 0 and 1 (non-inclusive) will only make it into the *.material file if that value has been purposefully set.  Where is the opportunity to somehow get a value between 0 and 1 which would have the harmful side-effect you list, to justify this destructive behavior (overwriting)?

2) Never accept zero alpha values (replace with 1.0) otherwise incorrectly exported models will be invisible and you won't know what is going on.


That's an excellent idea.  I just need to add it in to the conditional I already have in place to issue a warning for this situation.
7
Momoko_Fan said:

The reason is that it doesn't really make sense to have an alpha value in material parameters. This will e.g require special handling in a shader to support this kind of functionality. Transparency information should be stored in the diffuse texture.


I found the alpha problem trying to import into jme a 3d model made with Blender and exported with Ogre's exporter script.
The original model has a sort of glass helmet. A snippet of resulting material file was:


material Glass
{
       receive_shadows on
       technique
       {
               pass
               {
                       ambient 0.500000 0.500000 0.500000 0.372564
                       diffuse 0.250244 0.205022 0.700415 0.372564
                       specular 0.985570 0.985570 0.985570 0.372564 2.500000
                       emissive 0.328237 0.268922 0.918713 0.372564
                       scene_blend alpha_blend
                       depth_write off
               }
       }
}



alpha value of diffuse parameter is set to 0.372564.
OgreLoader replaced that value with 1.0... loosing the helmet transparency.
8

I believe that the combined effect of several fixes I've made to material parsing and for transparency support recently should eliminate the problem described here.

9

Hi Blaine,


blaine said:

I believe that the combined effect of several fixes I've made to material parsing and for transparency support recently should eliminate the problem described here.


I think so, this week end I'm going to test your fixes and to start to prepare some use cases for the loader.
Thank you for your support !
10

Hi Blaine,


foxat said:

I think so, this week end I'm going to test your fixes and to start to prepare some use cases for the loader.
Thank you for your support !


As I said here, the loader works fine (for my tests) and the alpha bug is fixed.