CompositorLogic Framework

Introduction

The CompositorLogic framework is a small addon framework for Ogre that aims to make advanced compositors dynamically loadable by introducing a new interface for advanced compositors (CompositorLogic) that allow the creator of the compositor to get callbacks with the information required to setup the parameters required for the compositor to work properly. These classes will be dynamically loaded when needed, making compositors much more easy to deploy and share.

Current State

(As of January 2008 - Ogre 1.4.6)

By looking at Ogre's compositor demo, we can see that despite the fact that compositors are defined in scripts, for some of them (in the case of the demo they are HDR, Gaussian Blur and Heat Vision) the scripts are not enough, and they require listeners to be attached to the compositors and their functions to be called before enabling them. If you wanted to incorporate the HDR compositor on your application, even if you compiled the code to a DLL, you would still need to manually link with the library and setup the listeners in your code. This makes the deployment more than just copy-paste. It also makes it much harder to configure compositor chain in scripts, as you need to treat specific compositors in the loader that will load the chain from the script.

Another problem, is that there is no generic interface for specifying viewport-specific compositor parameters. If a pixel shader has a parameter stating the blending factor, we would like to be able to change this blending factor per viewport. This is not possible currently.

We aim to address these two issues and introduce a simple, intuitive API for handling advanced compositors.

Solution

To solve this problem, we will introduce a new API for specifying advanced compositors with code behind them.
This is the API that developers wanting to create a new compositor will implement :

#ifndef _CompositorLogic_H_
#define _CompositorLogic_H_

#include "OgrePrerequisites.h"
#include "OgreCompositor.h"
#include "OgreStringInterface.h"

#include "CompositorLogicPrerequisities.h"

/** An enum for the requested chain position of a certain Compositor Logic
*/
enum ChainPosition {
    /** This compositor can be anywhere in the chain */
    CP_NOT_IMPORTANT,
    /** This compositor must be first in the chain */
    CP_FIRST,
    /** This compositor must be last in the chain */
    CP_LAST
};

/** A class representing a single instance of a CompositorLogic on a viewport
*/
class _CompositorLogicExport CompositorLogicInstance : public Ogre::StringInterface {
public:
    /** Get the requested chain position of this instance
    @returns The requested chain position of this compositor logic instance
    */
    virtual ChainPosition getChainPosition() { return CP_NOT_IMPORTANT; }

    /** Notify the compositor logic instance of the viewport it is attached to.
    @param viewport The viewport that this compositor will work on.
    @remarks Override this to add viewport specific logic code to your 
        compositor, such as setting shader params based on its dimensions
    */
    virtual void notifyViewport(Ogre::Viewport* viewport) {}

    /** Notify the compositor logic instance of the Ogre compositor that has
        been created for it
    @param instance The Ogre compositor instance that this Compositor Logic 
        manages.
    @remarks Override this to add compositor-instance specific logic to your
        compositor, such as attaching a listener.
    */
    virtual void notifyCompositor(Ogre::CompositorInstance* instance) {}

    /** D'tor
    @remarks The CompositorLogicInstance is destroyed before the 
        CompositorInstance, so unregister any listeners here
    */
    virtual ~CompositorLogicInstance() {}
};

/** A factory class managing the creation of a certain compositor
*/
class _CompositorLogicExport CompositorLogic : public Ogre::Resource  {
public:

    /// @copydoc Resource::loadImpl
    virtual void loadImpl() {}
    /// @copydoc Resource::unloadImpl
    virtual void unloadImpl() {}
    /// @copydoc Resource::calculationSize
    virtual size_t calculateSize() const { return 0; }
    
    /** Create an instance of this compositor logic.
    @returns A new instance of the compositor logic
    @remarks This method must be overriden.
    */
    virtual CompositorLogicInstance* createCompositorLogic() = 0;

    /** Get the name of this compositor logic
    @returns The name of this compositor logic
    @remarks This method must be overriden.
    */
    virtual const Ogre::String& getCompositorName() = 0;
};

#endif

Some notes :

• CompositorLogic is parallel to Ogre's Compositor, and CompositorLogicInstance is parallel to Ogre's CompositorInstance.
• CompositorLogicInstance inherits from Ogre's StringInterface, allowing the creator of the compositor to specify per-viewport parameters for each instance of the compositor.
• CompositorInstance's two virtual methods - notifyViewport and notifyCompositor - allow the creator of the compositor to setup advanced parameters requiring advanced logic impossible (at least currently) to implement in scripts.

The user of the program will have to use a different class to setup the compositors in the scene. This is the CompositorLogicManager:

#ifndef _CompositorLogicManager_H_
#define _CompositorLogicManager_H_

#include <OgrePrerequisites.h>
#include <OgreSingleton.h>
#include <OgreResourceManager.h>

#include <vector>
#include <map>

#include "CompositorLogicPrerequisities.h"
#include "CompositorLogic.h"

/**
A class in charge of managing compositor logics and their attachment to viewports
*/
class _CompositorLogicExport CompositorLogicManager : public Ogre::ResourceManager,
    public Ogre::Singleton<CompositorLogicManager> {
public:
    typedef std::vector<Ogre::String> CompositorNameList;
    typedef std::vector<CompositorLogicInstance*> CompositorList;
public:
    /** C'tor */
    CompositorLogicManager();
    /** D'tor */
    ~CompositorLogicManager();
    /** Override standard Singleton retrieval.
    @remarks
    Why do we do this? Well, it's because the Singleton
    implementation is in a .h file, which means it gets compiled
    into anybody who includes it. This is needed for the
    Singleton template to work, but we actually only want it
    compiled into the implementation of the class based on the
    Singleton, not all of them. If we don't change this, we get
    link errors when trying to use the Singleton-based class from
    an outside dll.
    @par
    This method just delegates to the template version anyway,
    but the implementation stays in this single compilation unit,
    preventing link errors.
    */
    static CompositorLogicManager& getSingleton(void);
    /** Override standard Singleton retrieval.
    @remarks
    Why do we do this? Well, it's because the Singleton
    implementation is in a .h file, which means it gets compiled
    into anybody who includes it. This is needed for the
    Singleton template to work, but we actually only want it
    compiled into the implementation of the class based on the
    Singleton, not all of them. If we don't change this, we get
    link errors when trying to use the Singleton-based class from
    an outside dll.
    @par
    This method just delegates to the template version anyway,
    but the implementation stays in this single compilation unit,
    preventing link errors.
    */
    static CompositorLogicManager* getSingletonPtr(void);

    /// copydoc ResourceManager::createImpl
    virtual CompositorLogic* createImpl(const Ogre::String& name, Ogre::ResourceHandle handle, 
        const Ogre::String& group, bool isManual, Ogre::ManualResourceLoader* loader, 
        const Ogre::NameValuePairList* createParams);

    /** Get a list of all the available compositor names
    @returns A list of all the available compositor names
    */
    CompositorNameList getAvailableCompositors();

    /** Get an ordered list of all the compositors attached to a viewport
    @param vp The viewport being questioned
    @returns A list of the compositors attached to a viewport, in order of 
        execution.
    */
    CompositorNameList getAttachedCompositors(Ogre::Viewport* vp);

    /** Get an instance of a compositor attached to a viewport
    @param vp The viewport to get the instance from
    @param compositorName the name of the compositor to get
    @returns The compositor requested
    @remarks This method is mainly useful for getting and setting instance-specific parameters
    */
    CompositorLogicInstance* getCompositorLogicInstance(Ogre::Viewport* vp, const Ogre::String& compositorName);

    /** Attach a compositor to a viewport
    @param vp The viewport to attach the compositor to
    @param compositor The name of the compositor to add
    @param enable Enable the compositor after attaching it?
    */
    void attachCompositor(Ogre::Viewport* vp, const Ogre::String& compositor, bool enable = true);

    /** Detach a compositor from a viewport
    @param vp The viewport to detach the compositor from
    @param compositor The compositor to detach
    */
    void detachCompositor(Ogre::Viewport* vp, const Ogre::String& compositor);

    /** Set a compositor's status on a certain viewport
    @param vp The viewport to change the status of
    @param compositor The compositor to set its state
    @param enabled Is the compositor enabled for this viewport?
    */
    void setCompositorEnabled(Ogre::Viewport* vp, const Ogre::String& compositor, bool enabled);
    
private:
    std::map<Ogre::Viewport*, CompositorList> mAttachedCompositors;
};

#endif

This class is parallel to CompositorManager, and has a similar API.
Some notes :

• CompositorLogicManager does not fully replace CompositorManager. Re-ordering existing compositors in a chain, for example, still needs to be done via the CompositorManager.
• It is important to use attachCompositor, detachCompositor and setCompositorEnabled via this new manager in order to proeperly load and run the code needed.
• "Simple" compositors which have no code counterpart can also be used from this manager. A SimpleCompositorLogic class exists to wrap their functionality in this API. Remember - the user doesn't need to know if the compositor has code behind it.
• The getCompositorLogicInstance exists mainly for viewport-specific parameter settings.

Here are some sequence diagrams showing the majot flows of the addon :

Attaching to a viewport

http://nomanogre.googlepages.com/CL_Attaching.png

Setting parameters

http://nomanogre.googlepages.com/CL_Params.png

Disabling and removing

http://nomanogre.googlepages.com/CL_Disable.png

Advantages

• Easier deployment and integration of compositors with advanced code.
• Better decoupling between the compositor and the program that using it.
• Per-viewport parameters, with a shared interface between all compositors. An additional parameter processing layer allows for exposing high-level parameters to the user of the compositor, and translating them to the proper low level (GPU program mostly) parameters in code.
• Automatic sanity control with illegal chains (two compositors that need to be first, for example)

Open Issues / Future Possibilities

1. Currently, the name of the compositor and the filename of the compositor plugin (.comp file) must match. Compositor:HDR -> CompositorPlugin:HDR.comp .
2. In the first version you will have to define the compositor itself in a script.
3. Like plugins, the compositor plugins currently have to be placed in the working directory.

References

Improving the compositor framework thread @ Ogre forums

Schedule

Code can be found here : http://nomanogre.googlepages.com/CompositorLogic.zip