I don't know of any freely availble plugin system; yet it only takes a matter of minutes to create one. It would be advisable to understand how and what works across dynamic boundries and this time spent will save you alot of problems. Here is a few links to get you started and don't be so lazy :(
http://www.nuclex.org/articles/building-a-better-plugin-architecture
http://aegisknight.org/cppinterface.html
http://www.isotton.com/howtos/C++-dlopen-mini-HOWTO/C++-dlopen-mini-HOWTO.html
http://msdn2.microsoft.com/en-us/library/ms682599.aspx

Quote:I don't know of any freely availble plugin system; yet it only takes a matter of minutes to create one. It would be advisable to understand how and what works across dynamic boundries and this time spent will save you alot of problems. Here is a few links to get you started and don't be so lazy :(

While it's true that coding isn't much more than:


Designing a good general purpose plugin system is hard. Unless you specify it for a particular task, you'll need to invent a lot of systems, cross-plugin communication, incredibly complex life-cycle management, interospection systems, and more.

COM/DCOM and their other incarnations are a decent Windows solution. Complex, annoying and extensive, but still, they cover just about all ground.

But mostly, given the static nature of C++, plugin architectures are, without an incredible amount of effort, simply not worth it. C# and Java offer out-of-box run-time pluggable architectures with all the facilities one could need.

This in part contributed to popularity of Java-based web frameworks (run-time hot-swap plug-ins).

Dynamic libraries are the basic solution, as long as you don't push things too hard.

Quote:There are others utility methods, of course, but this is how I thought it. Could this be a (decent) way of doing this?

With dynamic libraries and static typing, the interfaces with which you interact with objects created by plugin are fixed.

For example, in a renderer, you'll call the library, and obtain a void *pointer. You'll assume that it's something you can use.

A generic plug-in design would allow your renderer to submit its context to the library, then let library execute the functions. Once you go into big picture design, you realize that the only way to develop a scalable plug-in system, is to used concepts like Command, Visitor and Inversion of Control.



Here, you need to define the Texture interface. What happens, if you then want to add an advanced texture in a different plug-in? Marble, Wood, ... textures are all exactly the same, they merely define some parameters. What if you want your texture to calculate reflection?


We're talking ray-tracer here...

Breaking it down into functional layers - what is the very essence of a ray-tracer?

- Rays

This way it becomes possible to design a context specific plug-in system that brings this knowledge into design.

When rendering, you create an instance of ray. You then traverse the scene-graph, searching for collisions. On collision, you perform a set of operations, push the results on stack, and continue traversal. When complete (expired, hits light, skybox, ...), you return, and post-process the resulting stack.

An extensible plug-in system here would catpure this functionality. Each plug-in will need basic knowledge of the world (Ray - accessing, creating and casting new, world - querying for interactions with rays).

Your plug-in system would therefore not provide an abstract texture, but the texture handler would be attached to an object. On collision, you call this texture handler, to provide you with result of ray-texture interaction. Even better, let the "material handler" take care of further ray-casting.

Your plug-in system then becomes something like this:


When you create a scene, each object will have default handlers for both. You can then add custom handlers (each in their own plug-in) to handle collisions differently.

This way, you do not need to pass any internal knowledge across plugins, yet still have full control over rendering process.

Your plug-in API can then be expressed as a set of ray-tracing operations. Pixels, Rays, Objects, and ray-casting collision calculations.

Textures, primitives (collision detection also becomes plug-in system to allow creation of arbitrary geometries), calculating reflection, refraction, texture response, shaders(kinda), ... all become plug-ins, without any of them knowing about each other.

If you expose internal details from plug-ins, you'll quickly find the plug-in system isn't pluggable at all.

With such function-oriented system, you can customize every tiny aspect of rendering, and the only penalty you need to pay (not negligible, but managable), is the cost of transporting your ray information across separate modules, while retaining full and complete customizability of the system.

I've written a platform independant plugin system based off of this article. It works very well and is relatively easy to implement.