This topic contains 10 replies, has 3 voices, and was last updated by 
Ethernaut
11 months, 3 weeks ago.
-
Posts
-
After playing with light baking for a while, it seems to me that using the PbrMaterial Emissive map is not an ideal solution, since the Emissive map doesn’t act like an “extra light” channel.
For instance, if I combined this color texture with this “light map” texture in a scene completely without lights, I’d expect to get this:
But instead, when I use the gradient as an emissive texture and set emissive factor to 1.0, I get this (no lights/no env texture/no ambient light). It’s odd that the black pixels in the emissive texture still end up brightening the resulting color:
I’ve had some partial success when using “full” maps – both lighting and color combined into a single texture – but that is very limited, and doesn’t play well with other lights in the scene.
Am I doing something wrong?
If not, it would be great to get a “LightTexture” property or similar in PbrMaterials that simply adds light to the fragment color- ideally, one that defaults to texCoord1, since light maps will almost always be “global” maps with no tiling.
Bonus: supporting floating point images, so that the light map values can go beyond 1.0! If not possible, at least a “LightmapFactor” property to multiply the light texture by values above 1.0, simulating an HDR map. This would work well as long as the lighting is properly normalized out of the 3d package used to create the light maps.
Cheers!
Hmm, I get different results here with a black env and no lights. I get whatever’s coming through emissive, ie: just the ‘fake’ light, no color:
…and the setup code (no light):
123456789scene.AmbientLight=Color.Blackscene.ClearColor=Color.Blackscene.EnvColor=Color.Black 'turn off all env mapping.Local material:=New PbrMaterial( Color.Magenta,0,1 )Local texture:=Texture.Load( "asset::pointlight_light.png",TextureFlags.FilterMipmap )material.EmissiveTexture=texturematerial.EmissiveFactor=Color.White_donut=Model.CreateBox( New Boxf( -1,1 ),1,1,1,material )So it’s ‘working’ here (IMO), but I get that this isn’t what you want anyway, which is effectively a separate ‘self illuminating’ texture similar to what hezkore has been doing with the quake stuff.
Here’s what I’m thinking:
- Add a LightTexture to PbrMaterial. A material with a light texture is a ‘static material’, ie: it’s not really expected to move…
- Static materials will NOT be lit by scene static lights (via eg: LightFlags.Static, possibly directional lights by default?)
- Static materials effectively provide their own ‘static light’ via the LightTexture, and ARE lit once using this ‘light’.
- Static materials are still also dynamically lit by ambient light and dynamic lights though.
- Light textures use second set of vertex tex coords.
Does that sound right?
I’ve actually been working on related stuff over the last few days (have cleaned up the shader system considerably, ouch) and have been thinking about static lighting etc. and am looking forward to getting it going ASAP!
Ok, got it working the right way for emissive now (color texture doesn’t show when all lights are off, only the emissive color). Not sure what I was doing wrong… would still welcome the Light map addition, of course!
I hadn’t thought about using static light flags as a way to control light inclusion/exclusion. It works for me, although I’d probably still set my directional light to dynamic and provide only bounce/ambient lighting in the Light map.
Can’t wait to see the new shader stuff. Is it going to be easier to make custom materials?
Thanks!Super simple demo up and running…
https://ethernaut.itch.io/cube-chamberDownload size is huge for such a small scene, about 50Mb. I hope to keep it much, much lower once we have Lightmap on texCoord1, since I’ll be able to tile the textures on texCoord0 and use a single light map texture on texCoord1. Will also be much sharper!
Still have to find how to bring in those extra texture coordinates, though… will try some of the assimp formats.
Nice demo! Dig the ‘god ray’ too…
Just working on this now, and the way I’m planning to implement LightTexture is to add light texture texels to Scene.AmbientLight when rendering the ambient pass, so perhaps LightTexture should be renamed AmbientTexture? LightTexture is pretty vague…
Using light texture to simply modulate ColorTexture would be another approach, but this wouldn’t take into account metalness, roughness etc, which can affect ambient lighting. If you did just want to modulate ColorTexture I’d rather use something like ColorTexture2, so total Color is ColorTexture * ColorTexture2 * ColorFactor etc.
And of course, we could have both ColorTexture2 and AmbientTexture eventually, but for now I just want to get something working and AmbientTexture seems to be more in line with what you want to do?
That looks great!
So you’d use AmbientOcclusion2 to use texCoord1?
My only concern is that Ambient Occlusion currently seems to work correctly, “blocking” ambient light and reflections. This new light map shouldn’t take any of that into account (I think…) since usually you spit out JUST the channel you want from the 3d app – I.e. indirect light – and If you use a path tracer to obtain that channel from a static mesh it should be correct, with all color spills, contact shadows, etc, and only needs to be added to the final result, with the ambient occlusion still there preventing things like reflections inside cavities.
I need to test it. Maybe it will be just fine!
Can we get a multiplier (LightMap Factor, or something like that)? It doesn’t make sense for Ambient Occlusion, but it would make sense for light maps, since the value should be able to go above 1.0
Thanks!
<edit> Sorry about my ramblings. The point is: Ambient Occlusion map and Light Map can be useful together, serving different purposes. Cheers!
AmbientTexture and AmbientColor now up in develop branch!
123456789Local material:=New PbrMaterial( Color.White,0,1 )material.ColorTexture=Texture.Load( "asset::Slate Tiles II_D.png" )material.AmbientTexture=Texture.Load( "asset::pointlight_light.png" )material.AmbientFactor=Color.White_model=Model.CreateBox( New Boxf( -1,1 ),1,1,1,material )_model.Mesh.CopyTexCoords()AmbientTexure/Color always use second set of texcoords for now, so you need to CopyTexCoords after creating a mesh. Also, gltf2 appears to support 2 sets of texcoords so I’ll add support for that ASAP.
Yay! testing soon…
Just to make sure I understand, If I have a dynamic light and a box with an Ambient Texture, does the ambient texture add light to the total result (light intensity + ambient texture)? Or does it multiply?
Ok, I exported a cube out of Houdini as FBX with two texture coordinate channels, and it can re-import it without losing anything, so the exported file supports 2 uv channels just fine.
Mojo3d-loaders does not seem to be loading the second channel, even though Assimp seemingly supports it. From the Assimp features page: “Loads multiple UV and vertex color channels (current limit is 8)”.
I also wasn’t able to convert to gltf preserving the second uv channel (Clay Viewer doesn’t seem to support it).
Let me try… sigh.. Blender now… (I have Blender allergies).
Blender’s Glb converter seems to have stripped out the second uv channel, even though Blender imports it from the fbx… sad trombone…
But at least the AmbientTextureProperty seems to be doing its job well, thanks Mark!
Here with TexCoord1 copied from TexCoord0:
Here’s the ambient texture:
By Using AmbientFactor = 2.0 I was able to use the ambient texture to both darken (ambient color < 0.5) and brighten (ambient color > 0.5 ) the resulting lighting, with grey being neutral. And it apparently plays well with ambient and dynamic lights too! (needs more testing)
Will try to manually export and load the second texture channel tomorrow, maybe using a text file just for that.
You must be logged in to reply to this topic.