Being able to load plugins in irrlicht

[teto]

hi there,


I noticed there is a lot of enthusiastic irrlicht users who send codes to add features to the engine. All of them can't go into the core but some of them could be loaded as plugins as Ogre does. I think of the different directX 10/11 drivers that got created but then their creators vanished with their source code. If they could have written their video driver as a plugin, that would have make it easier to maintain and share it. It might also become easier to drop support for a driver (officially) which would be maintained by 3rd party developers. That's what I had in mind when I started implementing a plugin loader for windows (took me a hour) and then I tried isolating the opengl driver into a dll. I succeeded in decorelating window creation from device creation (I don't think the device should create the driver and immediately attach it to a window, rather it should create a window than the driver should attach itself to the window, that's what I made through a IRenderWindow class).

I've started replacing inheritance to CNullDriver (from COpenGLDriver) by other classes such as ISoftwareImageManager and IHardwareBufferManager and IMaterialManager but still it's too much work if you want to do it the proper way (logger). But that could be a goal we aim at.

As I have some free time ahead of me, I was wondering if there would be some interest in sthg like this. I've talked about drivers, but we could load meshloaders,imageloaders,serializers as plugins (even scenenode if we look at ogre but their system passes parameters as strings).


Matt

[hendu]

Not a good idea IMHO. The indirection of every function has a cost, the complexity of irrlicht would increase a lot, and for what advantage?
So someone can create a binary-only plugin.

Hardly worth it to enable that behavior.

[teto]

Except if you play on an arduino platform, I don't see this as relevant. Or would say ogre is slow because of that ? Furthermore I only told about loading dynamic libraries but the plugin system can also load static libraries (it's nearly the same). So you have the choice.

the complexity of irrlicht would increase a lot and for what advantage?

Depends how you see complexity. On one hand, you might add new classes but you only deport abstractions from IVideoDriver to other classes thus decoupling systems. I could say that adding a renderer right now would increase complexity. one more entry in enum, more #ifdef etc...

So someone can create a binary-only plugin.

That wasn't my point and even so I strongly disagree. Right now, if you want to add any feature, it's a pain you have to change all enums, play with the #ifdef _IRR_COMPILE_WITH_* to get sthg working. Then you need to update to irrlicht next version. So make a patch/apply the patch with all the problems it implies. When u need to stuck with trunk it becomes time-consuming. (I don't speak when you maintain 2 versions of your project).
Many projects maintain their success because of their user(in our case developers) base. Being able to load dynamic libraries allow people to test quickly other members' works without having to wreck their own irrlicht version. And since they can test those projects, there is more feedback and then it encourages its developer.

[serengeor]

Last time I had to deal with a library that uses a lot of plugins.... lets say it didn't end happily ever after. (OpenSceneGraph).
Though I'd like to see something like this implemented, maybe as a separate project/branch/..

[shadowslair]

Take Irrlicht, add some additional libs, some random and dirty implemented features and sh!t, and "Viola!"- you get OGRE. Which is bad IMO. Yes, using external libs/plugins may be useful, but do I want to see it it Irrlicht? Nah...

[hendu]

@teto

Be honest with yourself. If the authors of some DX11 drivers disappeared without source, would you actually be happier with a binary-only plugin?
I wouldn't.


Also keeping a patch is more about properly knowing your version control. It need not be hard at all.

[teto]

Take Irrlicht, add some additional libs, some random and dirty implemented features and sh!t, and "Viola!"- you get OGRE. Which is bad IMO. Yes, using external libs/plugins may be

I don't see why a code in a plugin would be more random and dirty implemented. Depends on who code what. Anything can be seen as a plugin (except your bootloader maybe) even irrlicht which is built on top of opengl/directx/windows etc...
If the plugin doesn't reach your expectation, you are not compelled to use it.

Serengeor> I would be interested in your feedback. Why did you get disappointed ?

Be honest with yourself. If the authors of some DX11 drivers disappeared without source, would you actually be happier with a binary-only plugin?
I wouldn't.

In fact I don't know the story. Of course I would prefer having source (doesn't zlib asks for it ?). All I know is there were 2 more or less working drivers and I can't use either of them.

What I wanted to underline is that supporting plugin could help seeing new features since you could switch between stable and unstable version. Right now to make it into the core, your code needs to be perfect which is fine but takes time. Allowing plugins speeds up things since more users can test and send their feedbacks beforehand. Irrlicht's dev spend a lot of time on bug hunting. A plugin system would allow to send them more mature (more tested) "features". You can't compare it to using trunk. Since once you port your code to trunk, you can't go back (api changes). With plugins you can go back and forth between versions.
For example a driver version supporting opengl 5.0, another one with 4.2 etc... and there would be only one "officially" supported.

[serengeor]

Serengeor> I would be interested in your feedback. Why did you get disappointed ?

Well, the biggest problem was figuring out how to get all dependencies, compile and load in the application. Simply it wasn't clear on how things should be set up and the whole library depended on those plugins.
I'm sure it wouldn't be too much trouble if you're already familiar with the API, or there were some good guide on setting things up


Actually, I had my own idea about this kind of thing.
What I was missing in irrlicht was the 'ability' to use your own windows,scene managers, etc. What I mean is that when you create irrlicht device, you already get a scene manager, gui environment, window and so on. It would be a lot easier to change some things in your own classes derived from the same interfaces and pass them some way to, for example device without modifying the library internal classes.
Now that I think about it, it sounds like I'm talking about plugins too.

[teto]

I agree the biggest problem with plugins would be to provide the toolchain to compile them.

About your other point I totally agree with you. Irrlicht shouldn't create a scenemanager/guienvironment, except if you ask for it.

Among the strong points of irrlicht, there is its simplicity the first time. I clearly remember it worked straight out of the box and I think it should remain this way. It should keep at least the software video driver (with one opengl/directX maybe) and current gui environment embedded to be able to run on its own but at the same time, I think it would be nice to be able to load them from dynamic libraries for more advanced users. As far as video drivers are involved, it would force a cleaner implementation (differ platfrom dependant window from rendering context initialization for example).

Btw, it would hardly ask for any api change since irrlicht is somehow already "plugin" friendly (with its heavy OOP style).

[Granyte]

the idea of optional plugin is nice but having a video driver as a plugin just sound bad to me

[hybrid]

I really like the idea to detach window and driver creation some more. You can't do this on Windows alone, though, would require work on at least all three major platforms. Because they all do the window and driver creation very different. Whether this makes it into some kind of plugin or not does not matter for me, as my concern is first of all getting strong relations on Windows with GL out of the code.

[mongoose7]

Why do you need "binary" plugins? Why could you not use the method of mesh loaders, say, where you register your mesh loader. You should, in the same way, be able to load the video driver.

Code: Select all

device = createDevice(...);
video = createVideo(...);
smgr = createSceneManager(...);
window = createWindow(device, video, smgr, ...);

It would need the parts of the video driver to be modularised, though.

At least, instead of providing a symbolic constant for the video driver, one could register a video driver and use the value returned to create the window.

[ACE247]

PLUGINS, PLUGINS, PLUGINS! Until the socket is overloaded.
If you want to add something to irrlicht compile it in properly because you have the source.
When I need/want to use plugins I usually just implement the plugin functionality into the Code/Program that links to irrlicht.
The only reason for irrlicht to support plugins is if it weren't open source but free to use(like irredit), but it isn't and the gain just isn't worth it when you've got the full source code to work with. Because If you can afford to write a whole new renderer as a binary plugin you can certainly also just adapt or write a new one for irrlicht. Making a new binary only driver plugin only not to share the source just isn't nice. [period]

[mongoose7]

Sure, but we've been waiting for 10 years for a DirectX 11 driver. If it had been possible to load a video driver 10 years ago, someone would have written one and today we'd be debating about how to put it in the engine.

I'd be interested to see what happens to Nadro's FVF code. If it is not integrated in the short term then Irrlicht really is frozen in the past.

So, really, the debate is not about putting binary plugins into Irrlicht source, but about putting coded plugins into Irrlichts ossified binary.

[Steel Style]

I second mongoose I really think that we shouldn't mess things up, teto is not saying that you should use binary
because they are cool and they can prevent us to share the source. That's would be a bad habit. But I think he is
pointing the fact that it's would be nice to have a greater modularity on the some important objects. And this
will lead IMO to more contributions.

Driver is not the only object needing for such things. Imagine that you wish to implement a two SceneManager one
completely based on LOD optimizations and the other one on multiple specific shader techniques as defered rendering.
If you want to give to the user the ability to select between those two SceneManager it's currently impossible, without
a lot of change on the irrlicht core.