ColorRGBA values are not clamped, but documentation says so

I'm currently looking into jMonkey a bit and noticed that the documentation (User's Guide and JavaDoc) of class ColorRGBA says that "anything [the color components] less than 0 will be clamped to 0 and anything greater than 1 will be clamped to 1". The code does not do this, though.



There was a call to method clamp() in every setter method, but these calls were commented-out about 2 years ago. (Revision 3831) While the user can still call clamp() manually, it seems as if it is never called automatically when setting the color component values.



This is probably an oversight in the documentation or in the code base. Maybe someone who knows whether the code or the documentation is correct can look into this. :slight_smile:


I notice that this is still currently the case…



ColorRGBA values of (2.5f, 2.5f, 2.5f, 0) work perfectly fine for lighting a scene.

Is this a valid way to implement lighting? Or should all lighting in the scene add up to maximum of 1?



My question is; Is the ColorRGBA clamping between 0 and 1 going to be returned or will the claming be defently removed?

Unless you are using HDR these values are effectively clamped.

One of the reasons I ask is because with the ambient Light on ColorRGBA(1f, 1f, 1f, 0) our scene seems really dark…

with ColorRGBA(4f, 4f, 4f, 0)) it seems much better.







http://i.imgur.com/SoGBV.png

For lighting, the brighter the color, the brighter the light… that’s definitely true, HDR or not.

ColorRGBA often represents lighting intensity rather than simply a color. This is why the clamping was removed. Also if you require values like 4.0 to achieve lighting in your scene then it is possible you’re doing something wrong.

We are currently trying out new lighting system in our game where it is required that the entire scene is lighted only by the ambient color (during nighttime). This means that the OBJ Models should have the same Ambient color behavior as the TerrainQuad.

In the TerrainLighting.vert line 99 it states:

AmbientSum = vec4(0.2, 0.2, 0.2, 1.0) * g_AmbientLightColor; // Default: ambient color is dark gray



The value of 0.2 is thus the standard? The MTL file for OBJ materials would also suggest this ( http://people.sc.fsu.edu/~jburkardt/data/mtl/mtl.html ).



Can you confirm this?



Thxs,

Maxim

It is the standard in jME3 if you do not specify material colors

Okay, thanks for the conformation.