Well, I was wondering if it is possible and feasible to have dynamic lightmaps. I’m not talking about having dynamic light or static light (lightmaps) but having both, switching them depending on the camera distance (light culling).
The main problem and thing I’m asking for is the part where the current light/shadows must be baked to a lightmap before culling it. Is this dynamic baking feasible?, and if so, there is anything already implemented?.
Sure that makes sense, most games do exactly this when they have a day/night cycle or such. Theres no implementation for this afaik but it would anyway depend on what you want to do with it.
Hm… maybe could you point me where to look in jme to get the applied shadow on a geometry material?, maybe a clue?. I’ve been looking at some shadow filters/processors but I can’t find the way I could get the desired result.
Look for ShadowMapX and LightViewProjectionMatrixX, X ∈ <0, 5>
I’ve looked for them in the filter and the desired geometry. The thing is that from the filter I can achieve to get the shadowmaps for the current viewport (and the different textures on it material). The dephfield texture is showing fine, the shadowsmap are completely white. However, this is not what I want as If I want to bake the light for the scene or for a single geometry I can’t rely on the viewport view angle but the not-angle dependant shadow map.
Shadowmaps are white because they are z-buffers.
You need to transform the shadowmap from light’s projection space to camera’s projection space. Use their LightViewProjectionMatrices.
1 Like
I’ve been thinking about adding light baking into the engine for a few years now … and I’m still thinking … it’s a very very icky problem to solve. UDK uses their lightmass system and it takes hours, if not days, to resolve a single level, and those kids know what they are doing.
So in answer to your question: possible, yes. feasible, not really. Unless you have a hell of a lot of time to pour into this, and it is your only project, go for it, otherwise I would recommend focusing on other things, for now.
Perhaps a better angle to approach this problem, is what are you trying to achieve, and why do you think light baking is the solution? We can probably find a more realistic way to solve your issue.
An intermediate solution would be to process all the baking in blender, then implement the result in the engine.
What I’m trying is to have a scene with “lightmap shadowing”, but when, let’s put an example: the player takes an item from the table (the table would have baked in it lightmap the item shadow) so the dynamic shadows are activated, the new shadows (in this case no shadow) is baked on the table lightmap and just after the shadows are deactivated.
This can be also useful backwards: the table is just a shadow receiver and it hasn’t got anything on it. But then, an item is put (a shadow caster), the table lightmap is updated with the new shadow, the item becomes a non-shadow-caster (so, the item is only a shadow-caster when moving).
If this shadows are calculated real-time, why should it take so long to “bake” (maybe is not the right word?) them?.
1 Like
Just do a deferred shading to increase fps with many lights. Additionally, you can omit shadowmap rendering if there is no changes in light’s camera frustum (do it by using some checksum). That is enough to achieve good performance in simple games.
bake is the right word.
My thoughts are as follows … that modern GPU’s are highly optimised to provide real time solutions to lighting problems, they can achieve this by limiting how many calculations are performed by only providing a solution for the current POV… baking the lights needs to be done for every POV possible, and is performed on the CPU (yes you can offload this work to the GPU but that is another conversation).
The problem is not with how much time it takes to render, but to implement a baking you need to do so much stuff, such as:
- generate lightmap texture coords for all objects, which is a complex and difficult task
- bake all possibly lighting situations onto those UV;s, which takes exponentially more time per light
- find a way to store all this information… multiple massive images will work but then you are faces with how to load them back into your engine (which is kinda where I get stuck) since you can’t load too many textures before capping out the hardware limit, and they can really only be 4096*4096 max before hitting more hardware issues, even that is kinda pushing it, which is not even close to enough data to represent a realistic sized scene
- reinvent the OpenGL wheel and perform all lighting calculations in your own code on the CPU
- even if you get this far, you can’t bake specular lighting, so you have still have to handle that
- an ass load of other things I can’t think of right now
baking generally only works for changing light conditions, since you talk about changing the geometry of the scene, you would need to bake for every possible geometric possibility, which exponentially increases the amount of work and storage needed for all the issues listed above.
… basically, it a metric fuck-tonne of work. Yes some ‘AAA engines’ can handle some of these issues, but JME simply hasn’t had the man hours put into it that these engines have.
I am by no means an expert on this, it’s simply something I find interesting, and put a lot of thought into. I would love for others to step in and correct me, since ultimately I would like to find a way to achieve this.
To re-iterate what I mentioned before, unless baked lighting is the sole intended outcome you wish to achieve from your project, you are going to spend way too much time looking into it… my advice would be to make your game work with the currently available tech, and worry about this kind of optimisation later down the track… if you get far enough down the dev path that this, and only this particular issue is holding you back, you will have achieved far and beyond that of any other monkey in here =)
1 Like