Right-Handed Projection Matrix

[andr3wmac]

The projection matrix code in lm_setView is right-handed. When used in a renderer that's left-handed the culling has to change based on whether its a lightmap render or a regular scene render. Could you add a setting, perhaps in lmCreate, where left/right handedness could be specified?

Also, does the library make that assumption, or any other assumption about handedness/winding order/culling anywhere else? I ask because I switched the projection function to left-handed and the result was darker leading me to believe the library relies on that handedness to some degree.

[ands]

It is correct that the library currently only works with right-handed coordinate systems.
I plan to support both along with a setting to change the winding order handling.
But I won't have much time to test and release this over the next few weeks.

The only other place where the winding order should matter is in the computation of the hemisphere/hemicube direction here:
https://github.com/ands/lightmapper/blob/master/lightmapper.h#L539
Could you try to swap v1 and v2 on that line for your use case? That should toggle the winding order.

What exactly does your coordinate system look like?
(What direction do +X, +Y and +Z point to?)

[andr3wmac]

What I'm actually doing is porting lightmapper to bgfx:
https://github.com/bkaradzic/bgfx

And the projection functions in bgfx default to left-handed (I think X and Y are the same but Z goes into the screen instead of towards you). Below is a comparison of lightmaps produced by the original + 3 variations from my port. The right-hand projection is pretty close, just a few artifacts to try to clean up. The left-hand projection is darker than the right-hand one and swapping v1 and v2 seems to have made things worse.

Original (from lightmapper):
http://i.imgur.com/5Rl06dd.png

BGFX port with right-hand projection:
http://i.imgur.com/6NZzt3F.png

BGFX port with left-hand projection:
http://i.imgur.com/m9EMw0r.png

BGFX port with left-hand projection + v1 and v2 swapped:
http://i.imgur.com/UWtBqyE.png

[ands]

"What I'm actually doing is porting lightmapper to bgfx"
Cool! :)

The lightmapper rotates the hemi-cubes according to a 3x3 lightmap pixel pattern and adds some jitter to the rotation by calling rand(). This prevents banding artifacts at low hemi-cube resolutions and introduces noise instead which can be filtered reasonably well in postprocessing steps.
So, you won't necessarily get the exact same output from the lightmapper each time.
But your ported right-handed version seems to have some additional artifacts.
Did you use the exact same lightmapper version as the base in both cases?

It seems very odd to me that both left-handed solutions result in similar results (even if darker) at all.
I'm not sure what your scene looks like, but usually pointing the hemi-cube inside the object should result in complete garbage - especially if you write (gl_FrontFacing ? 1.0 : 0.0) in the alpha channel of your renderer, as suggested in the readme.

Can you show what your mesh looks like and what the output of the lightmapper is without any postprocessing?
Could you #define LM_DEBUG_INTERPOLATION and show the debug output of the interpolator (should be written as debug_interpolation.tga to the working dir)?

Do you plan to open source your code?
I could take a look at some point and would help to keep it in sync with improvements in my implementation if you'd like.

[andr3wmac]

My port is actually behind a bit and I don't yet have your changes merged that added interpolation. I plan to add them over the weekend. Perhaps that will change the situation.

I do plan to release it, and under the same license as you did. My only delay was that I wanted to get it fully functional before releasing, but I think either way I'll put the code up this weekend. I'll let you know when it's up.

[ands]

The added interpolation shouldn't fix the problems...
It just allows to render fewer hemi-cubes in regions where the irradiance doesn't change a whole lot.

Thanks for planning to open source it :)
I'll look into it as soon as I can spare some time - maybe in a week or so.

[andr3wmac]

Hey, sorry for disappearing I had some life things get in the way of personal projects. Anyway, I've pushed my bgfx port here: https://github.com/andr3wmac/bgfx as example number 32.

You can find the actual ported lightmapper.h here:
https://github.com/andr3wmac/bgfx/blob/master/examples/32-lightmapper/lightmapper_bgfx.h
Let me know if the way I modified the license at the top is okay I can restructure it if you prefer.

I assume you're unfamiliar with bgfx, the build instructions are here if you need them:
https://bkaradzic.github.io/bgfx/build.html

DX11 is the only working API at the moment.

[ands]

No worries. I'm on holidays anyway :). I will return in about 24h and will look into this over the following days. The header/license is totally fine :). It is PD anyways. I know about bgfx, but never got to use it. This would be a perfect occasion :). Thanks!

[ands]

I ran your code and was able to exactly reproduce your first result. The computation was quite slow though. Now going to learn some bgfx and try to understand your changes :). Since I will be somewhat busy over the next few days, this may take a while...

[andr3wmac]

I believe the source of the slowness is the fact that after filling up the available views in bgfx, we have to call bgfx::frame() to submit the work and that causes a backbuffer flip. Branimir (bgfx author) is planning to add a variation that won't present at the end to avoid this.

No worries on the time, I'm not in a rush.

[ands]

Okay, thanks! That's good to know.

[ands]

I believe both problems (the slightly darker result and the artifacts) could be caused by the translation to floating point sampling coordinates in the shaders and bilinear interpolation instead of nearest sampling.
The sampling position calculations relyed on the truncation to integer coordinates. Your current translation probably results in slightly incorrect interpolated sample weights and possible bleeding of values from a neighbour hemisphere/hemi-cube into the currently processed one.
I have not looked very deep into bgfx yet... does it not support integer texture coordinates/nearest sampling?
At least I'm pretty sure it's not the camera-handedness...

[andr3wmac]

Hey thanks for looking into that. I had wondered if that was impacting it. The hemisphere textures are initialized with BGFX_TEXTURE_MIN_POINT | BGFX_TEXTURE_MAG_POINT, so they should be using point sampling. Even with float coordinates that should have the same net effect, no? The reason I avoided texelFetch is because its only available in the later OpenGL versions and I wanted to try to have support for all the APIs. For instance there is no equivalent for DX9.