Lightmapping

Great update Sinoid! One thing to note though and I assume you already considered blending dynamic shadows and the lightmaps for this tool?.. but I’m sure you already anticipated this one. :wink:

Maybe something simple like “Bake Scene”, with texture size for the lightmaps as options, etc in GUI, and a switch option between real-time and baked lights.

This is really awesome work, can’t wait to try it out…

This is not a real need at the moment but just thoughts:

Lightmap present in scene.
Can light emmiter drop light only on dynamic objects?
Can lightmapped static model drop shadow only on dynamic objects?

Whoa, really impressive!

Two things I don’t like about baked lighting:

  1. Baking in 3d editor is pain. It takes time, and a lots of repetitive actions, you make it each time you want to move a tiny thing or made a mistake. So, having a one button in-editor baking is super cool.
  2. There always a challenge of getting static and dynamic geometry look similar. And that’s the thing you just can do perfect. They will always be a bit different.

So, how do you see shading on dynamic models? Dynamic lights + cubemap set by zone? What about situation, when some large object casting a shadow, and dynamic model can move into it? Have you considered adding a light probes?


Sun and Lamp Dont have effect on Ground and House.
Only on dynamic objects - Car and Ball.

Car and Ball be able to cast shadows on all objects
(Static and Dynamic)

Question:
Can House cast its shadow only on Dynamic objects (Car and Ball)?
(House himself or any helper mesh or lod mesh)

Your approach looks simialr to this one: geomerics.com/wp-content/upl … ecture.pdf
In action: geomerics.com/wp-content/upl … Subway.mp4

Problems with Lightmaps + dynamic lights
http://discourse.urho3d.io/t/problems-with-lightmaps-dynamic-lights/1073/1
Next images from original post demonstrate problem.

Seems reasonable. There can be only one reflection cubemap per zone, and a bunch of light probes affecting diffuse.

Ability to edit each probe’s position can be essential. In cases like placing them on terrain surface, or making sure no probe placed inside geometry. Navmesh can be a good reference for lightprobe placing.

May be look code in free (MIT licence) Godot engine?

Global Illumination Workflow

Description:
Short demonstration of the Global Illumination workflow in Godot Engine.
A low resolution lightgrid is used so it takes a short time to bake.
The light octree system generates a 3D lightmap, so it makes a secondary UV unnecesary

Then, a dynamic object is moved around the level, fully sampling the light from it?s surroundings.

Looks really cool so far. Have you considered using ptex for storing the lightmaps, a good alternative to traditional uvs and can safe quite a bit of memory.
ptex.us/documentation.html
developer.nvidia.com/sites/defa … 20Ptex.pdf

That is an interesting library sabotage3d, great find. :slight_smile: and great work so far Sinoid :exclamation:

Building platform: windows mingw

note:
LightmapGenerator.h 73
no known conversion from argument 2 from

"Urho3D::VariantMap& <aka Urho3D::HashMap<Urho3D::StringHash, Urho3D::Variant>>"

to

"Urho3D::VariantMap& <aka Urho3D::HashMap<Urho3D::StringHash, Urho3D::Variant>&>"

and ====================

error:
LightmapGenerator.cpp 255
no matching function for call to

"LigtmapGenerator::HandleGenerate<Urho3D::StringHash, Urho3D::VariantMap>"
    HandleGenerate<StringHash<>, VariantMap<>>

Again awesome work ! I am big fan of spherical-harmonics. Are you working on anything to convert HDR images to SH coefficients ? Is there any bands limitation in the current workflow ? I guess 8 bands would be the maximum for games.
Do you have any plans for tracing shadows from the spherical harmonics, although this might be expensive.

There is already a code to convert HDR to SH, I haven’t tested it but it looks interesting: github.com/rlk/sht
Yeah this is the paper but I think it can be extended to fake lights for SH GI effects like in this paper: ppsloan.org/publications/irr … gs_jgt.pdf

I also found this on how to fix UV seams in lightmaps and doing shadows using SH . I think it looks good in the end, as the game is quite nice visually
miciwan.com/SIGGRAPH2013/Lightin … f%20Us.pdf

For simple ambient occlusion should be only 1-2 SH bands which prove me if I am wrong is around 2-4 textures. This would be pretty neat for mobile.

I have ogl texture array support mostly working in a branch of mine.

github.com/friesencr/Urho3D/blo … e2DArray.h
github.com/friesencr/Urho3D/blo … DArray.cpp

I had some errors generating mipmaps. I fell back to letting opengl making the mipmaps for me. Texture array extension support is very good on opengl2. There is also some issue with cubemaps and the deserializer. Cubemap is hardcoded to xml filetype. So a tag should be made and read from for arrays/cubemaps and a serializer/deserializer needs to be added to my code too.

Thanks a lot for the hard work. I have been testing the Lightmapper for a while, thanks to Sinoid it works great. I created a repo with an example it is still work in progress but the basic shaders are working: github.com/sabotage3d/Urho3DLightmapExample
Can’t wait for this to be merged with the master branch :slight_smile:

1 Like

Wow I need try this.

This will be nice for baked light finally! and if someone over here include in Urho3D a way of realtime LPV or something for get realtime GI that will be x2 of awesome to have the 2 options one for more details and the other for don’t need compile and for larger maps.

@Sinoid You guys can use the Purpleprint Kit assets got integrated UV for lightmap originally created for UE4. github.com/Hevedy/PurpleprintKi … try/Simple

You’re doing great work!

There’s some cleanup and documentation required before it’s even PR worthy.

The handling of the lightmaps runtime side is also quite questionable and probably full of exceptional failure cases. I’ve been meaning to look at allowing Resources to spoof as being other resources (or at least indicate who the REAL resource is). The hassle is that from a usability standpoint, lightmapping has to be reasonably non-intrusive … it is unacceptable for lightmapping to interfere with the materials that have been defined.

I’ve been working on some hybrid CPU/GPU GI stuff. It’s going quite well, but no where near primetime. Hilariously, I’ve been enhancing my knowledge of Geometric Algebra to find better solutions, which happens to be exactly what Enlighten uses (only became aware of that after I started diving down that round for reprojection of point clouds, now it’s a patent dancing nightmare).

I want to point out, that at all times, screenspace GI should be an option if you’re doing GI at all. If you’re going to do SSAO, there’s no reason not to do SSDO on top of anything else.[/quote]

I see tests of the SSGI in UE4 and give problems is like the SSR but the reflections you notice less than the light, if you add sometype of dynamic GI you got in UE4 the LPV in alpha/beta status as reference but that LPV or something like that should be better than SSGI.
*Tested in demo scenes probably in a final result game looks better without problems idk.