Plugins

[Josh]

One of the coolest aspects of Leadwerks Engine has been the ability it gives shader authors to implement new effects. On that note, how do you see a formal plugin system for Leadwerks3D working? I am thinking a number of hooks will be available in the engine, on both a per-entity and system wide basis. A plugin class will look something like this:

 

class Plugin

{

std::multimap<int,void*> hooks

}

 

The Plugin object can be created in a DLL or other library, and retrieved. Then the engine will have a function like this:

RegisterPlugin(Plugin* plugin)

 

And all the hooks in the hooks multi-map will be added to the engine.

 

Is there a way this could be architected so that the plugin can access the same instance of the Leadwerks3D command set? Any ideas there?

[Pixel Perfect]

Your basic outline sounds good but I don't have any experience of implementing plugin architecture. Hopefully others do and can contribute. Certainly this needs some careful concideration as if you get this right it could be a very powerful feature and selling point.

[Benton]

Editor plugins would be nice too...

[AggrorJorn]

Do you also mean plugins like special editor plugins? It would be nice to be able to build menu's for the editor where we can create our pluging with.

 

Command examples:

1. EditorMouseClick
   
2. EditorDrag
   

[Josh]

Do you also mean plugins like special editor plugins? It would be nice to be able to build menu's for the editor where we can create our pluging with.

 

Command examples:

1. EditorMouseClick
   
2. EditorDrag
   

Not in particular, the workflow in the editor is way too specialized for that. It isn't like you just click a toolbar to select with the mouse, click another to rotate, click another to translate. That kind of behavior is easier to program, but we care most about making a really easy to use editing workflow with a minimum number of mouse clicks.

[Roland]

Here is some loose ideas

 

In general some kind of OnEvent system callback. I don't know if you have some kind of base class in LE3 like the TEntity in LE2 but lets assume that.

 

void OnEvent( TEntity& source, const EventData& data );

 

where Event is a enumeration of various supported events

namespace Event
{
    enum  Type
   {
        Collision,
        Create,
        Destroy,
        Update, 
        ...
        ...
     };
}

and EventData is a base structure for any data that

may belong to the event

 

struct EventData
{};

 

This structure would then have various implementations depending

on the event type. Like this ficitional event

 

struct CreateEventData : public EventData
{
   TVec3 CreatePostion ;
   TVec3 CreateRotation;
};

 

The user registers callbacks of interest

 

void myCreateCallback( TEntity& source, const EventData& data  )
{
     // we know that this is a Create Event with CreateEventData
     const CreateEventData& eventData = static_cast<const CreateEventData&>(data);

     // use eventData and source.
    // source was created at eventData.CreatePosition etc.....
}

 

LE3::register( Event::Create, myCreateCallback ); // LE3 will call myCreateCallback each time a TEntity is created ...

 

... later on

 

LE3::unregister( myCreateCallback); // we dont bother anymore

[Rick]

What kind of plugins are you talking about here if not editor plugins?

[Roland]

Was that question for me or for Josh, Rick. If it was for me I was talking generally, not about the editor in specific.

[Rick]

Sorry was @Josh to get a feel for what he's thinking with this. Is this so we can create external applications that link into the editor? For example like a flowgraph or something of that nature?

[Benton]

No I think he means *engine* plugins, nothing for editor, but, like, GUI for games...at least thats what I think...

[Thomas Pittman]

I've written plugins in the past for 3d Max, and it has a very powerfull system in place for extending what it can do. Having a general read through/overview of how it does things could give you some ideas: http://docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-SDK-Programmer-Guide/files/GUID-717D0F11-78F1-4C0E-878F-506A31911E4D.htm

 

 

Each plugin dll starts by describing what it is (a new modifier, a general utility, a new material type, a new texture format importer/exporter, etc). So you can tell max that you are a texture import plugin, which then extends the BitmapIO parent class, tells max what file extensions it handles, and implements functions for reading the texture data into Max's internal bitmap structures. Or you can tell max that you are a modifier plugin, which extends the Modifier class and implements functions that describe what types of data on a mesh it changes and a function for applying that modification.

 

Everything has unique ID numbers, letting you do things like subclass their built-in objects and let Max still instantiate them via a factory mechanism. Then you can extend the functionality of anything in the program. Similarly, its got formalized ways of storing parameters, retrieving parameters, blocks of data, etc, so that they can be shared between plugins with no knowledge of each other's internal workings, and to get automatically saved into the scene file. Be sure to give the plugin users a Load/Save function that lets them store any data that they want, and if you are saving plugin data inside of the Leadwerks map files, be sure to always record in version information of the plugin and what plugin it came from so that it can be ignored/handled gracefully if the plugin isn't present.

 

It also lets you create your own interface panels and such inside of 3d Max, and ties you into their windows message loop, so any keyboard/mouse/gui functionality can be done (you just have to pay attention to whether or not the plugin indicates that they processed the message or not). There's also formalized systems for registering your plugin's functions for keyboard hotkeys and to be able to be put into the menus/toolbars. They also have a more specialized event notification system, letting you register a function for when the scene is saved, loaded, changed, etc in various ways.

 

You get at most of the scene data by calling a global function that gives you a pointer to all of the scene data, letting you access just about anything you want (all nodes, meshes, lights, material libraries, shaders, etc).

 

For Leadwerks, a plugin could also indicate whether or not it should be loaded just in editor mode or just in game mode, and there should be a flag somewhere indicating what the current state of Leadwerks is. There's no need for something like a texture importer plugin to be active outside of the editor, as it will have already converted the textures into Leadwerk's native texture format long before the end user playing the game sees the data. A pathfinding plugin would need to create additional tools in the editor to configure it, and only the actual pathfinding code to be active when in game.

 

 

This is just one possible way of doing it, might be overkill for a game engine.