-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello,
Ben Discoe wrote: >>From osgexport 2.41, not consistently lit, only by accident :) > The textured Geodes were written with no Material, just a naked Texture2D. > Depending on the arrangement of your scene, you might have a Geode with a > Material above your textured object in the graph, in which case it could > conceivably inherit. Otherwise, 2.41 doesn't give the artist any control of > the lighting properties of textured surfaces. > > If you feel strongly about it, i could add a Checkbox to the exporter so > that people who want the old uncontrolled behavior could still get it. No, that isn't what I meant. Blender allows to have a surface textured and lit and what I meant was that if you are doing the changes to the exporter, it would have been better to properly implement this instead. The old exporter didn't support this at all, AFAIK. > Just FYI, many if not most people do use ambient. I understand if you've > got projects which deal purely with diffuse, or don't use traditional > materials at all (e.g. shader code, etc.) But the common case is that an > artist does want/need to set ambient-diffuse-specular. For OpenGL scenes which are lit? Ambient light? Diffuse/specular - that's for sure, Blender supports that quite well too. But ambient light? I somehow do not see the point - either you are using OpenGL lighting and then the ambient light is not very useful except of brightening up some dark parts of the scene (and you would be probably better served by an additional light source anyway) or you are not and then you should be using lightmaps and/or custom shading. > If that case, you won't like the previous osgexport behavior either, which > is to omit ambient which produces OSG's default (grey). Which seems more > correct to you: > > A. Green and black objects which are both grey on their unlit sides. > B. Green and black objects which are dark green and black on their unlit > sides. > > (A) is the old behavior and (B) is the new behavior. What do you mean by "unlit sides"? Are you using OpenGL lighting? If yes, I am somehow missing how the object could get green and black in the B case, since the calculations are done like this according to your description: L = ambient + diffuse + specular = 1/2 * diffuse + diffuse + specular If the diffuse color was dark green, after adding 50% of the dark green as the ambient component to the final pixel color you will get brighter green that what was specified. I would prefer to set the ambient component to zero vector explicitly instead of "making up" some arbitrary value. > Not a surprise if you read the documentation on the exporter. Then if > becomes a valuable feature, in fact essential for normal lighting behavior > (for those of us who are in fact using OpenGL materials). The traditional > approach is A+D=1, so ambient and diffuse sum to 1 in the OpenGL lighting > model, which is additive. If an artist wants an object to be [0 0 1] when > fully illuminated, they can set Diffuse to [0 0 .666] so that A+D=[0 0 1] at > runtime. Well, this is the first time I see this sort of interpretation of the lighting semantics - where did you find that the ambient vs. diffuse have to sum to 1? That is simply not true and relying on such an assumption could be rather dangerous. So now, if I want pure white, I would have to set diffuse 0.5, 0.5, 0.5 instead to 1.0, 1.0, 1.0 because the ambient component will add another 0.5 ??? > In light of your feedback, i will add one more slider (0..1, default 0.5) > for A/D ratio. Then users like you who want no ambient at all can just set > it to 0, and get the ambient=0 that osgexport 2.41 isn't giving you: No, please drop this. This semantics will be completely incomprehensible and un-intuitive for anybody not using your style of modeling and does not match the OpenGL behavior at all. The three types of light are completely independent and should be treated as such. It is perfectly legal to have both ambient, diffuse and specular components set to 1.0, 1.0, 1.0 - it is probably not what you want, but it is a legal setting. If the user wants to have it that way, let him do so instead of trying to invent new or arguably better semantics. > C. Green and black objects which are both black on their unlit sides. Which is actually the correct behaviour. Ambient light should simulate scattered light from the environment making the parts of the object which would be normally lit indirectly (by scattered light) visible. However, if the parts are not illuminated and there was no ambient component specified (as it is in Blender), these parts MUST be black. Not grey nor anything else. Regards, Jan - -- Jan Ciger GPG public key: http://www.keyserver.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFE62a4n11XseNj94gRAsrQAKCdChjxyK50Guf+14tKLzGBtvEY7gCgza2q IWIukkfJEcc72G1B4j5tWEU= =bgtu -----END PGP SIGNATURE----- _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
