Found it. It’s the “samples” property of the “light_settings” in the world data. Higher samples results in smoother baked images. And here we go with another field in the lightmapper…
x blueprintrandom
the problem I see with that approach is a usability one. Simply “soft” flagging the object requires the user to remember that flagged objects are subject to peculiar handling which is not enforced by the UI. The user will still be able to do everything he wants with the light and the logic behind it will simply break. The net result of such oddities will be the user thinking “hey, blender is crap!”. And we don’t want to be responsible for that, do we?
The will for a light manager is strong, it’s the knowledge that lacks behind. As I said, there are issues with a hypothetical plugin in to manage lights that I don’t know how to solve. Yet.
More or less what I can think of it right now is:
The plugin adds two buttons (somewhere), one labeled “add static light” and one “add dynamic light”.
All static lights are (somehow) compiled into lightmaps, removed before the game starts and re-added when the game ends. Otherwise the edited scene won’t be consistent between test runs.
Dynamic lights are also removed, replaced with empty objects managed by a script that handles a fixed pool of lights, and re-added.
This would be the base and it would also be completely useless because the point of dynamic lights is in their behavior. The necessary next step would be to find a way (which I haven’t found) to let the user add scripts to those dynamic lights, in a way that is consistent with the workflow of bge - which involves logic bricks and python scripts.
And that’s it: I have no idea how to do that, how, at runtime, take the logic bricks temporarly attached to the empty placeholder and re-link them to the managed light, for the time that light is active.
I have noted that adding a lamp from a hidden layer,
then adding the same lamp removes the first lamp.
what about using LOD to pool what lights are ‘free’
and then the dynamic light objects add light command, uses a message rather then a add object actuator, or even have adding the lamp type have a different behavior? like look up the deleted light properties, and morph one of the lights off the list?
also, having lights that die, add themselves back to the list?
and in python have the addObject code have a flag to see if its adding a light?
(to use your list)?
How exactly lighting works in bge is, for me, unfathomable. One of the craziest thing I found is that if I have a model in an inactive layer of a blender file, I libload that file then add to the scene the model, the light in the inactive layer of the loaded file still influence my model, even if I never asked for it to be added. I can’t tell how much I hate that :D, I always have to remove all lights from the blender files before to use them as libraries, then when I want to change something in the model I have to re-add a light, do the changes and then remember to remove the light again…
I don’t know if it is possible to overwrite the endObject() call of a game object. In theory subclassing the light might work but I never tried it.
The game properties of the light objects are not a problem because that kind of attribute is common to all game objects. If the only thing a script could do would be to read/write game properties then it wouldn’t notice if the “owner” is a light or an empty.
Things get weird when we take into account attributes that are specific to the light types (energy, light color, distance that sort of things).
It might be possible to trick the scripts designed for lights by subclassing the empty-owner of the script controller using, again, a subclass. It’s another thing that should be tested.
I have updated the plugin to add ambient occlusion map and fixed a couple of things (resizing images, lightmap texture values, error checking).
I haven’t found a way to add the ambient occlusion map to a dynamic lighting compatible lightmap that didn’t looked abysmal so ambient occlusion maps are “Static” or “Image” only. A node material would probably be needed for correct results (in fact even the dynamic lightmap should use nodes but passing from materials to node in a way that can be undone is beyond my level of focus on this thing).
how hard is it to replace a bge material, with a modern shader compatible with android? would a way to spare alot of headaches just be to disable the old system and just steal the data you need?