PBR NaN to half conversion errors

So I am mucking around with the PBR pipeline. I really like the results so far, and to make life hard on myself i am generating my own hdr maps in blender.

It all works pretty good up until i add some nebula billboards. Then i get the following error.
java.lang.UnsupportedOperationException: NaN to half conversion not supported! at com.jme3.math.FastMath.convertFloatToHalf(FastMath.java:971) at com.jme3.texture.image.DefaultImageRaster.setPixel(DefaultImageRaster.java:134) at com.jme3.environment.util.CubeMapWrapper.setPixel(CubeMapWrapper.java:196) at com.jme3.environment.generation.IrradianceMapGenerator.generateIrradianceMap(IrradianceMapGenerator.java:167)

I am using the TestPBRLighting code as is with just the hdr map replaced.

screen shot is also worth a 1000 words.

Clearly there is some gradient conversion problem or something. Not sure on the best way to address this.

It should be noted that i did get this problem with another off the shelf hdr image. That is the NaN problem.

Could you provide the said HDR file?

Of course. Didn’t think of that. It was my bed time. Err most things don’t like hdr images, so i am hosting on my website. But only temporarily. http://blackrobingames.com/untitled.hdr

So i have been playing with the images and i can’t really find out what is wrong. other than some gradient thing or something. I tried making my own nebula, and of course it could be some sort of problem in blender. However without the image billboards it works perfectly.

on this page the “milkyway” zip has a milkyway_small.hdr has the same problems. sIBL Archive

Ok got the same issue on my end gonna investigate.

1 Like

Awesome. I managed to get something working. I used a full skymap in blender rather than billboards. Obviously i would like to do my own with and without billboards, so knowing what is wrong would be grand. But no rush. Also i did go through the source a little. Nothing jumped out at me.

Not sure it’s linked, but it seems there is an issue in the HDR file reader. the env maps have some weird spots in them.

I suspect it is. Since these spots then dominate the lighting. Well at least that is what it looks like.

While your here :smiley: also when i set the EnvironmentCamera size to anything other than 128, it seems to just no produce a lightmap. In fact 127 cause a hard crash in my video drivers. Other values just never seem to make a light probe. However it doesn’t seem to matter that 128 is used so not sure about that.


Correction. It seems to work fine with POT.

yes of course you need a power of 2.

I realize my error as soon as i thought about what the parameter was. I was thinking light probe size/radius. In error of course.

Ok I narrowed the issue to FastMath.convertHalfToFloat that produce NaN or Infinite values. But it seems intended depending on the value. I can’t question the math behind it, so I guess the issue comes from the data in the image fed to the convertHalfToFloat, so basically… the HDRLoader.
Makes sense, those spots are weird anyway.

The env cam could check that and throw an error though :stuck_out_tongue:
I realize it’s not completely obvious. Since i made it it was fairly obvious to me :stuck_out_tongue:

1 Like

I did read your implementation notes. Once i though about it, it made sense, size of texture used that is also mipmaped. However it mostly just doesn’t render the probe, so i was wondering why my scene was so dark and didn’t appear properly lit. But hay i found it.


Yea don’t know what the deal is with those few hdr files. Thing is that i use very bright square emitters without issue in blender. Some alpha blended billboard and it breaks. But now a full skymap is working.

Again thanks for all your efforts.

Well I’m using the milkyway map you pointed out anyway, to rule out the “made my HDR file in blender” thing.
Photoshop opens it no problem and with no weird spots so the file is valid anyway.

EDIT: and thanks to you for testing. It’s nice to see someone testing my stuff :stuck_out_tongue:

This is going to be LIVE at PAX down under. So lots of people will be seeing it in action.

I really like PBR. Since i do physics it has appeal. But the trick is always getting the Environment map.

Oh also i do go through the source. If i did or when i find something broken, you wouldn’t object to a pull request if i fix it?

I wouldn’t, of course :wink:

man… i don’t get it… some pixels are read with weird values. For example :
this is the raw data : r: -32, g: 119, b: 119, e: 114
e is the exposure.
This converts to float rgb as :
r: 5.340576E-5, g: 2.8371811E-5, b: 2.8371811E-5
which to me looks like pretty much black…
then converted to half float (16bit component floats) and then to short (idk why we need this…probably to store it in a short buffer)
r: 768, g: 32624, b: 32624
which makes little sense to me but w/e.
The problem is that 32624 produce POSITIVE_INFINITY once converted back to float. (yeah because we need floats)

the weirdest thing is that those pixels are actually not the spots that you can see in the picture…

I thought e in RGBE is exponent?

You’re right,it’s actually exponent.