Editor: jMonkeyBuilder

Troubleshooting jMonkeyBuilder
201

Well something must definitely be wrong in the editor, because we would have the same issues in the test examples. And that’s an issue one can’t overlook, I mean… I would have noticed…

Edit: @javasabr do you have a custom skybox material maybe?

202

You can try this HDRI https://yadi.sk/d/FXwIn4QZ37VkB4 , it is working correctly in every software:

blob.jpg1916×1077 390 KB

and gamma corrected variant
blob.jpg1916×1077 364 KB

(as you see gamma shifted in different direction and image get more saturation)

203

Here is what I have in the stock TestPBRLighting where I just disabled the ToneMappingFilter for comparison.

Looks good to me.

@javasabr the things to check : Make sure the hdr Image is in LINEAR color space. Normally the HDRLoader does that for you.
You shoudl have a warning in the log: " The texture Textures/Sky/RoofTop.hdr has linear color space, but the material parameter Texture specifies no color space requirement, this may lead to unexpected behavior.
Check if the image was not set to another material parameter with a linear color space, or that you did not set the ColorSpace to Linear using texture.getImage.setColorSpace()."
IT’s perfectly fine to ignore it because in that case This image is in Linear space on purpose.

204

I use only sky factory

205

I have this warning

206

Well then maybe it has to do with the way you write the final texture into the panel. You use javaFX, maybe thereis something wrong.

207

Now That I think about it I think I had to do something specific in the SDK to have it to work properly
Let me did that up.

208

Alright here we go SDK scene viewer and previews are now gamma corrected · jMonkeyEngine/sdk@20b208b · GitHub

So basically, once you add gamma correction to JME, ALL frame buffers are in linear mode except the last one (the main frameBuffer, the one that writes to screen) that is in srgb mode. The thing is here the last framebuffer is the one written to the panel and idk how it’s done in your editor, but in th AwtPanel there is a parameter to set the frameBuffer to srgb.
Whatever you use for javaFX, there must be something similar, since you most certainly use a frameBuffer to write to an image.
You have to cal frameBuffer.setSrgb(true), and you’ll have a correct gamma corrected pipeline.

209

When I added this parameter to my frame buffer I didn’t see any changes.

            this.frameBuffer = new FrameBuffer(width, height, 1);
            this.frameBuffer.setDepthBuffer(Image.Format.Depth);
            this.frameBuffer.setColorBuffer(Image.Format.BGRA8);
            this.frameBuffer.setSrgb(true);
210

^ this is your issue.
BGRA8 does not have an sRGB equivalent so the frameBuffer will be in linear mode anyway. Use RGBA8 and switch the channels whenever you write to your BufferedImage.

211

Also I can see any changes between:

 final Texture texture = assetManager.loadTexture(key);
        texture.getImage().setColorSpace(ColorSpace.sRGB);

 final Texture texture = assetManager.loadTexture(key);
        texture.getImage().setColorSpace(ColorSpace.Linear);
212

you mean “can’t” right?
that’s what I explained.

Look at how it’s done in the AWTPanel

213

right :slight_smile:

214

I can’t see any changes when I switched to RGBA8 :frowning:

215

Hm, I retested it and… it works :slight_smile:
after:
Imgur
before:
http://imgur.com/BnbEPRB

216

ahahah good… I was out of idea :stuck_out_tongue:
There are several things you might consider to have it really proper in a editor:
When a user choose color from a color panel he expects to se that exact color in the viewport. But ColorRGBA is ALWAYS considered in Linear space by the engine. So basically if you enable gamma correction, pick a color in a color picker for a material, it will be a lot brighter in the viewport. And that’s bad.

What you need to do is to use the ColorRGBA setAsSRGB and getAsSRGB (@pspeed yeah I know the case is wrong ;)) when you transform them back and forth from awt.Color to display them in a color picker.

Hope that helps.

1 Like
217

I will test this case, thanks :slight_smile:

218

these are without lights… :slight_smile:

[Album]
[Album]
2 Likes
219

Nice! Thanks nehon as always :smiley:
I thought fresnel value is incorrect but with this gamma correction everything seem to be neat
One thing I’ve noticed - colour value range is different than we have in unity or substance. Look at the wall and pool. Seems like its gamma is little bit “lighten” also this issue is clear in metal area (probably there is different roughness i shold check, but dark part of the metal is defenetly must be “darker”)

here is the wall pieces left and right

220

So left is Unity and right is JME?
Mhh…I don’t really know how the compute they prefiltered env map…but yeah difference could be due to how we do it…
That’s a hard issue to tackle :stuck_out_tongue: