[2.2] Dynamically baking lightmaps

[rujialiu]

Hi!

I'm trying to use Ogre 2.2's baking feature to increase performance: bake direct lighting of slow lights (mostly ltc area lights) into lightmaps and use them as regular lightmaps. Ogre 2.2 already supports "bake_lighting_only" and "use_emissive_as_lightmap" (though they're not documented), but managing the lightmaps is a big headache for me.

The traditional lightmap baking involves uv unwrapping/packing ahead of time, which is not an option for me because our scene is dynamic, so I want to re-use existing uv for the lightmaps. That means we need one additional emissive texture for each subitem that needs to use the lightmaps. That also means we can't share datablocks between subitems that use lightmaps because every subitem's lightmap is likely to be different What's more, there will be a LOT more textures...

Another (small) problem is that we don't have a dedicated texture type of lightmaps so for datablocks that already has a emissive texture, we had to disable the lightmap (which is ok, but it's easy to screw it up!), and since we're using emissive factor, we need to be careful not to let it be multiplied with the lightmap (this is mentioned by the document, but again, it's easy to screw it up)

Any ideas for alternative solutions or how to make it easier to handle?

[dark_sylinc]

This sits somewhere between "user should handle it" and "Ogre should handle it or provide help".

Indeed, managing this stuff is heavily annoying. A big PITA.

First, HlmsDatablock::clone is obviously going to come very handy. Since like you said, each baked object will need to use a different datablock (basically one datablock per baked texture).

The solution I can think of is a sort of "Meta Datablock", one that exposes a very similar public interface as HlmsPbsDatablock, but that forwards these calls to each of the datablocks it manages. i.e. something like this:

Code: Select all

class MetaPbsDatablock
{
    std::vector<HlmsPbsDatablock*> mDatablocks;
    
public:
    void setBackgroundDiffuse( const ColourValue &bgDiffuse )
    {
        foreach( datablock in mDatablocks )
            datablock->setBackgroundDiffuse( bgDiffuse );
    }
    
    ColourValue getBackgroundDiffuse(void) const
    {
        return mDatablocks.back()->getBackgroundDiffuse(); //Supposedly they're all the same value. You could assert this is followed
    }
}

You could use our llvm script Other/clone_datablock/clone_datablock.py to assist in the autogeneration of this interface (read all public functions, and generated code that forwards it).

And for generating the datablock I can think of something like this:

Code: Select all

//Iterates the subitems, checks if the datablock is already managed by us, if not then clone the datablocks,
//and add them to an existing MetaPbsDatablock
metaDatablockManager->prepareForBaking( item );

We could provide this interface for you, but I'm not 100% sure on the details and if it would be flexible enough to be usable when we provide it (i.e. it may require heavy customization)

[rujialiu]

This sits somewhere between "user should handle it" and "Ogre should handle it or provide help".

Indeed, managing this stuff is heavily annoying. A big PITA.

We could provide this interface for you, but I'm not 100% sure on the details and if it would be flexible enough to be usable when we provide it (i.e. it may require heavy customization)

yeah... it's best to handle all these on our side. Later I found that a more annoying thing is... many materials use warping uv, so we cannot use the original uv because lightmap should not be repeated :-S