Different light shading with compiled objects

[Jamiro]

Hello,

As I'm using compiled and non-compiled objects, I came across something that seems weird. The lighting and shading on the same objects are different when they are compiled and when they are not (for Config.lightmul = 1).

So, this basically means that the same lights cast different results on the same objects depending if those objects are compiled or not, is it supposed to be like that?

[Jamiro]

My question is, does a compiled object have a different light calculations than a non-compiled one? Does it have anything to do with VBO? I know it has nothing to do with max number of lights because I'm only using 1.

I tried to search on the web about this, but nothing came up. Can anyone give me a hint on this? and if its true, how can I accomplish a similar look with compiled objects?

Does it have to do with attenuation formula? (linear vs non-linear)

[Jamiro]

heres an example:

[Jamiro]

Ok, I know now what the problem is. So apparently it seems that compiled objects use linear lighting instead of the quadratic that the non-compiled objects are using, also there's the matter with light limitation on the compiled ones, which is 8, thus having a weird looking scene when compiling all the objects.

As for the light limitation, there's no solution other than using shaders, as for the lighting attenuation method, why does it chage? is it chosen by the hardware? If so, does this mean that when using VBO objects the light will be linear?

My problem is that I want to work with VBOs of course (do want the best performacen for my program) but I do not want the linear attenuation light, therefore I will need to use shaders, the problem is, when I use them I lose the default opengl fog effect, or I need to add it as well to the shader, but creating a shader is hard as hell, so I wanted to stick to default light and fog.

thanks

[EgonOlsen]

It's not linear vs. non-linear. Both use the same, linear approach, but this value http://www.jpct.net/doc/com/threed/jpct/Config.html#lightMul is 10 for non-compiled objects (for historical reasons) but 1 for compiled ones (because of the way in which the fixed function pipeline works). Have you tried to increase the intensity of the light source instead? Or played around with http://www.jpct.net/doc/com/threed/jpct/Lights.html#setRGBScale(int)?

[Jamiro]

Yes, I've only used 1 for Config.lightMul. Both use the same value, so the light brightness is more or less the same, but both yield out different results where the non-compiled objects seem to have a brighter color near the light and then it quickly fades away faster than when using compiled objects. It's more noticeable when using non-compiled objects than when using compiled ones. as you can see in the image above.

No I haven't tested out this setRGB option (I will give it a look afterwards) , but this really seems a difference between lighting because of those "occlusion" like shados on the edges which the compiled objects doesn't have. Notice that I only used 1 light and both scenes use "lightMul = 1"

[EgonOlsen]

That basic light formula is the same. I've noticed some differences between compiled and "normal" objects regarding vertex lighting as well depending on the GPU used. Especially older AMD based ones have a slightly different interpretation of how to shade the polygons which can result in dimmer lighting in some edge (no pun intended) cases. If you can't compensate for that with a brighter light or by changing some other values like the attenuation, you are basically out of luck and might have to switch to shaders.

[Jamiro]

ok, thanks a lot

[Jamiro]

yes, just tested it out now, even with Lights.setRGBScale the scenes have different results when compiled and non compiled, although both will get that "overbrightness" the compiled scene still has more light than the non compiled, and those corners still have that occluded effect.

on another note, is it possible to "pre load" all the objects when not using compiled objects? (more or less the same we do for textures when whe use the preWarm()). the problem is that I get some staggering effect when I'm rendering the object for the first time, I wanted to avoid that by pre loading or prerendering them somehow, is it possible, is there any trick to it?

[EgonOlsen]

When not using compiled objects, I don't see where that staggering effect should come from. For compiled objects, it might be caused by the compilation process...but for uncompiled...I don't see that. Can you narrow it down somehow?

[Jamiro]

I strongly believe that it's being caused by caching up some information (perhaps on java side). The first time I'm rendering an object and depending on said object poly count, I will have a staggering effect maybe meaning there's a loading behind. I dont know if its because java is storing the object data on memory or if its being created on the fly by the engine and sending it to opengl. Could it be that? I will perfotm some tests tonight and will let you know more abou it.

[EgonOlsen]

There might a small hickup when uploading textures, which is why you can preload them. But that applies to compiled as well as uncompiled objects. Have you tried to increase the VM's memory pool?

[Jamiro]

Yes, I'm giving 4gb of mem to the application alone, so it has space to grow, but when using uncompiled objects, I can be rendering a scene for hours, if a new object is rendered for the first time, a small loading will happen once, and then its good to go, but on that loading a small staggering will happen.

[EgonOlsen]

...not sure what that is then...

[Jamiro]

I really think its the normal rendering process (maybe when sending info through the pipeline) and receiving info back from opengl. That may cause that staggering I believe. I event tried to strip the object after created but for non compiled objects it doesnt work as I've read in the documentation.

I strongly believe it's in the "draw" method, which is where the render happensm since it's the object's first time "on screen" it will have some building and rendering process that only happens once.

Thanks anyway for the help