Tweaks and clips to make things work on ThreeJS

[patriciogonzalezvivo]

Took some minor work to make this work correctly on ThreeJS. Mayor changes are:

• ThreeJS inject a float luminance(vec3) function. Unfortunately they don't use any kind of define flag for it that we could use to single it out and prevent the collision. I should touch bases with @mrdoob and other ThreeJS maintainers to have a more robust solution for the future. For the moment I'm removing the dependency to that function just because is a one-liner.

• I'm making look-at matrices right handed by default in OpenGL (GLSL). In the same way we have LOOK_AT_RIGHT_HANDED now we have LOOK_AT_LEFT_HANDED to change the default behavior. This is mostly after a quick google that confirms that right handed view matrices are default on OpenGL. So, I could be totally wrong and misguided.

• fix the previous tonemap() additions to the SH sampling to make it active just for #ifdef GLSLVIEWER. This is temporal, in the longer run I just need to fix the way I'm computing the SH. But now more correct, just like @shadielhajj.

• the rest are smaller things that were surface when trying to make the new PBR pipeline work on WebGL 2.0

Here running in this double ThreeJS/GlslViewer example:

2024-10-29.16-16-03.mp4

[shadielhajj]

@patriciogonzalezvivo I would strongly object to having different default handedness for GLSL and HLSL. This is going to make porting code from one to the other much more difficult. You're right in saying that OpenGL is right-handed, but I think we should have unified handedness across Lygia. Did changing to right-handed by default break anything in the examples? Particularly in the raymarching examples.

[patriciogonzalezvivo]

@shadielhajj examples from lygia_examples have not changes because I have been forcing RIGHT-HANDED since it was introduce. This brings back plug&play-ness on OpenGL workflows. You can see I had to add that flag to all examples that use lookAt here (changes are fairly on at the end passed the images)

[patriciogonzalezvivo]

@shadielhajj I hear your concerns. I feel having a plug&play experience following the platform/driver conventions + define flags to overwrite those defaults, bring options and control while playing to the strengths of having a multi-language library (instead of trans-compiling from/to SPIR-V)

[shadielhajj]

@patriciogonzalezvivo Sadly the handedness issue is all over the place in the industry, as this graphic shows

So I'm not sure sticking to platform conventions does help (because as you can see above, nobody seems to care).
I don't have a strong opinion regarding left vs. right. But I do think we should pick one or the other, otherwise porting/maintaining is going to get even more difficult.
If you insist on switching to right-handed, I would really prefer we do it across all platforms.

[mrdoob]

So I'm not sure sticking to platform conventions does help (because as you can see above, nobody seems to care).

Even the person that did that image didn't care to illustrate right-handed and left-handed correctly either 😁

(Here's a much more clear illustration)

[shadielhajj]

Haha, well spotted @mrdoob! Ricardo, while you're here, I'm really curious to hear about your experience with coordinate systems. As well as the rationale (if any) for preferring one over the other.

[patriciogonzalezvivo]

Someone pointed to this one by @FreyaHolmer

[FreyaHolmer]

dang techarthub could've just asked to use my graphic rather than recreating it lol

also, I think it's really really important to try and stick to the canonical ordering of axes to avoid confusion - we've very lucky in that the games industry has settled on always being 100% consistent on matching XYZ to the colors RGB (in that order), it'd be nice to stick to the thumb-index-middle order as well to avoid confusion or accidentally mixing up which finger is which axis

[mrdoob]

Ricardo, while you're here, I'm really curious to hear about your experience with coordinate systems.

Converting rotations and hierarchies from different coordinate systems is a pain. Nowadays, it's probably easy to ask the AI for the right conversion code though.

As well as the rationale (if any) for preferring one over the other.

To me X right and Y up made sense as it follows the orientation of 2D images and made me think of the computer screen as a portal. Then it was a matter of deciding whether Z went towards the viewer or away from the viewer. Towards the viewer felt better to me.

Hope that makes sense.

[FreyaHolmer]

• I'm making look-at matrices right handed by default in OpenGL (GLSL). In the same way we have LOOK_AT_RIGHT_HANDED now we have LOOK_AT_LEFT_HANDED to change the default behavior. This is mostly after a quick google that confirms that right handed view matrices are default on OpenGL. So, I could be totally wrong and misguided.

hmm handedness is unrelated to look rotations in my view - generally handedness is "invisible" in math/code unless you're specifically converting between them. basically - a left handed coordinate system math library looks exactly the same as a right handed one, including a look rotation function. For example, if you say "Z+ is forward, Y+ is up", the math for that look rotation function is the same, regardless of whether your ambient space is left or right handed.

Currently, looking at lookAt.glsl, the LOOK_AT_LEFT_HANDED case is the correct implementation (regardless of handedness) while the LOOK_AT_RIGHT_HANDED variant does a space conversion, negating the X axis, resulting in a coordinate system with the opposite handedness of your ambient handedness. Which is fine to have as a feature! I would just name it differently to make sure it's clear what exactly it does.

Also, I would recommend doing vec3 zaxis = normalize(forward);, that way you ensure it always works even if forward isn't normalized, and, it doesn't cost anything extra because that lets you remove the normalize for the Y axis vec3 yaxis = cross(zaxis, xaxis); since both of those vectors are already orthonormal at that point. (unless you specifically want to support a non-normalized forward direction in the output)

[shadielhajj]

To me X right and Y up made sense as it follows the orientation of 2D images and made me think of the computer screen as a portal. Then it was a matter of deciding whether Z went towards the viewer or away from the viewer. Towards the viewer felt better to me.

Hope that makes sense.

Makes a ton of sense, thank you.
I agree that Y-up feels more intuitive, especially with reference to a 2D context.
I tend to find Z away from the viewer (left-handed) more intuitive as it allows me to think of the Z component as "distance from the viewer". But I guess this boils down to personal preference.

[shadielhajj]

hmm handedness is unrelated to look rotations in my view - generally handedness is "invisible" in math/code unless you're specifically converting between them.

Agreed. In our case, the main impact will be on example code, which will have to be modified in case we decide to switch coordinate systems.

Currently, looking at lookAt.glsl, the LOOK_AT_LEFT_HANDED case is the correct implementation (regardless of handedness) while the LOOK_AT_RIGHT_HANDED variant does a space conversion, negating the X axis, resulting in a coordinate system with the opposite handedness of your ambient handedness. Which is fine to have as a feature! I would just name it differently to make sure it's clear what exactly it does.

Good point. We should probably rename these defines to make it clearer.

Also, I would recommend doing vec3 zaxis = normalize(forward);, that way you ensure it always works even if forward isn't normalized, and, it doesn't cost anything extra because that lets you remove the normalize for the Y axis vec3 yaxis = cross(zaxis, xaxis); since both of those vectors are already orthonormal at that point. (unless you specifically want to support a non-normalized forward direction in the output)

Great point. Thanks.

[patriciogonzalezvivo]

Thank you @FreyaHolmer those are great points! I will work on some corrections.

[patriciogonzalezvivo]

I'm temporally undoing the default LOOK_AT_RIGHT_HANDED for OpenGL (GLSL), and normalizing the forward vector following @FreyaHolmer suggestions.

Originally my intention was to have an "ambient handedness" that change the behavior of all spatial matrices. I thought would be nice to have follow the framework/driver default so the experience is more seamless. But I hear the point so for the moment following mathematical correctness seams safer.

Before settling down with the undoing of that change, did a super professional research to see what were users expectations. I'm adding it here in case we want to give another round of thoughts.

Thank you everyone for your opinions.

[patriciogonzalezvivo]

@shadielhajj do you mind reviewing?

[shadielhajj]

@shadielhajj do you mind reviewing?

@patriciogonzalezvivo Sorry for the delay Patricio. I'm on vacation on an island and off-grid. But will review asap. Apologies again.

[patriciogonzalezvivo]

@shadielhajj oh! that's fantastic! please enjoy and don't worry about this! enjoy!

[shadielhajj]

As far as I'm concerned, I think we're good to go on this one @patriciogonzalezvivo. Sorry again for the delay.