My guess is that the generation of PreFilterEnvMap on android is invalid, and SceneComposer will generate PreFilterEnvMap and save it in the j3o file. So that android can directly obtain PreFilterEnvMap.
Currently, this is how I use it. This is a feasible solution.
Sorry if Iām repeating anything that has already been said - I have been less active and consequentially out of the loop on this thread since Iāve been sick this month.
I think the best way to understand the light probe is to just think of it as an advanced AmbientLight. All of the other lights will work the same as they do in the Lighting.j3md shader (aside from the AmbientLight which is used by PBRLighting.frag to scale the LightProbe in version 3.3+, so its essentially a color multiplier for the light probe).
So if you had only a light probe that was entirely blue, that would be very similar to using a blue ambient light with the old Phong shader.
I took some time to experiment with this, and while Iām not 100% certain yet, I think that Iām finding the best way to bake a light probe is to switch all of the materials back to the phong shader first. Then you can set the AmbientLight and DirectionalLight to their optimal brightness and color, and generate the lightprobe from there.
I do this because I have noticed that it can be difficult (or near impossible) to generate an accurate probe from an existing PBR scene, since the PBR scene will appear washed out until you place a light probe - and if you first place a separate light probe that was not generated from that scene, then it will also be inaccurate when you generate the new probe in the scene. Although you can still get by doing this if the external probe closely matches the colors in your pbr scene and sky.
Thanks for your helpful insights, @yaRnMcDonuts.
Last night I generated a light probe for a specific sky by hacking TestPBRLighting
and writing the resulting probe to a J3O. When I loaded that probe into PBR scene (in More Advanced Vehicles), it provided the ambient light that MAV was lacking. So Iām making progress.
On the other hand, I still donāt have probe generation working in Maud. Iāve generated many probes in Maud, but they never provide any perceptible illumination. I suspect this is because LightProbeFactory
is making assumptions that Maud violates. Iāve filed a couple side issues at GitHub, but havenāt yet dug down to the root cause. Iāll come back to that later when I have more experience with PBR.
That is strange, my initial thought would be that this could be due to an improper radius, location, or node hierarchy for the light probe. But it also sounds like you know that already since you got it working in the MAV project.
When you generate the light probe in Maud, are you immediately attaching it to the scene and noticing no illumination?
If so, then I wonder if you could get it to work if you alter the code to instead save the light probe to a j3o after generating it in Maud, and then immediately reload it with the assset manager like youāre doing in the MAV project where itās working. Maybe the result of that experiment could offer some more insight into what is causing things to not work in Maud.
Maud attaches the probe immediately, just like TestPBRLighting does.
I donāt want to turn this into a troubleshooting topic. Maud is a side project. As I said, Iāll come back to it later. Stay tunedā¦
By the way, Iāve started watching your YouTube tutorials (on PBR). Theyāre very helpful. Thank you!
I wish the videos had subtitles, thoughā¦
Here are the links in case others are interested:
Iām glad you find them useful
I checked the subtitle situation and seems like the autogenerated subtitles are there, though they are wrong here and there. I never messed around with manual subtitling on youtube yet, but from the looks of things, it doesnāt look like something that can be quickly added, especially on longer videos. With the finals coming up, I sadly donāt think I currently have the time to look into it properly
I notice that LightProbe.setColor()
doesnāt affect the render. A bug or a feature?
Iāve noticed this and wondered as well.
The ambient Light can be used to achieve the same thing in 3.3 now, but there still could be a use-case for making LightProbe.setColor()
work so that a single probe can have its color edited.
But I think you could also edit a single probeās color by attaching an Ambient Light to a Node that contains only the light probes you want to alter, so that method may not be necissary now that AmbientLights work with light probes. I think that was Nehonās plan from the get-go even though it didnāt make it in until 3.3, which could be why the LightProbeās color has always been ignored in the shader.
Thatās a neat trick! Thank you for enlightening me, so to speak.
Another detail to be documented.