Irrlicht Engine Classes, and seperation

[Halifax]

Alright, I know this would kill backwards-compatibilty, and break the API, but I am just curious. The engine appears well designed, and mostly is, except for some things which don't appear as if they belong.

For example, the SceneManager. I would expect a SceneManager to only deal with things that are intrinsic to the scene such as a SceneNode, SceneNodeAnimator, SceneCollisionManager, etc. But for some reason the SceneManager is also dealing with things such as the MeshCache, a MeshManipulator, MeshWriter, etc.

Doesn't this give the impression that some kind of seperation is needed. For example, I believe that it would be beneficial to have a ResourceManager, as well as other things, to facilitate this. The ResourceManager would take care of loading all assets such as textures, meshes, etc.

I believe that not only would this prove for a much cleaner API, the classes would be less cluttered, the documentation could be navigated easier, and the engine can be modified easier as well.

These are just my opinions, and I would be more than happy to provide numerous patches, including documentation, if other people believed that this would help/the developers.

[JP]

It makes some sense i suppose... though i don't know if it's particularly necessary, it could just be taking seperation a bit too far... But then if you want a simple to use set of classes and functions then that's the way to go...

It would certainly be a massive breaking of the API but to be fair 1.3.1 -> 1.4 at least had some pretty big breakages with the event receiver and scene node parameter changes so breaking the API doesn't seem to be such a big reason to not do something like this.

[Halifax]

It makes some sense i suppose... though i don't know if it's particularly necessary...

Agreed, it isn't particularly necessary, but it does make things easier for n00bs and pros alike.

it could just be taking seperation a bit too far... But then if you want a simple to use set of classes and functions then that's the way to go...

Yeah, I think the key would be to do selective seperation.

[lostclimategames]

ogre would be a good graphics engine to look into for more modular, oo code

[rogerborg]

Sure, if you want to crib from the engine that Hitler wrote.

[hybrid]

Even though the discussion is officialy dead at this point now, since we reached the Nazi analogies now, I'll give some feedback.
We already discussed a better scene manager concept, though with no final results, yet. However, having some structs for scene management only is definitely good, the tasks of the rest have to be analysed and put into some useful stuff with a new name then. Anyway, this is not the most urgent thing to work on, there are other places which might get a refactoring with more important benefits for the users as well. The mix of I/O handling, window management, and basic setup inside the device class should IMHO be resolved first. This might help for things such as input controller abstraction, multiple window integration, clean video driver integration, ...
But always keep in mind that simply adding another interface into a growing structure won't resolve any of the problems automatically, and that ease of use is always a major concern for Irrlicht.

[Halifax]

ogre would be a good graphics engine to look into for more modular, oo code

Obviously I have been using Irrlicht for a fairly long time, and I don't like the setup or the philosphy of the Ogre engine at all.

I believe that you know that everybody on this forum is smart enough to change engines if they wish.

[FlyingIsFun1217]

Well, if anything, I would imagine that such an API break would be saved for a new version (major, such as 2.0).

But I wholly support the idea!

FlyingIsFun1217

[rogerborg]

We could just pull a Microsoft and go straight from 1.4 to 2.0. Or switch to names rather than numbers, a la Ubuntu. 1.4, then Blundering Dodo then Horny Echidna.

On the substantive issue of API changes, I'm savagely apathetic. I don't really mind which interface the functionality is exposed through, since a find-and-replace in app code would take care of migrating from ISceneManager::foo() to IDongleManager::foo(). Although given the ongoing confusion caused by just the OnEvent() and constification changes in 1.4, I can see it being a much bigger deal than it ought to be.

We could conceivably leave the existing API in place, but mark it as deprecated, with the usual result that everybody would ignore that and keep using it right up to the point where it's removed, then bitch and moan just as loud as they would have done had it been removed in the first place. It's all good stuff, really.

[lostclimategames]

Obviously I have been using Irrlicht for a fairly long time, and I don't like the setup or the philosphy of the Ogre engine at all.

I believe that you know that everybody on this forum is smart enough to change engines if they wish.

true, I havent looked into ogre that much, what about it is wrong, just too strict, Im asking because ive been thinking about trying it for a while, and everyone says its big pro/con (dependant on your view) is that it is very very strict.

[Lekane]

We could conceivably leave the existing API in place, but mark it as deprecated, with the usual result that everybody would ignore that and keep using it right up to the point where it's removed, then bitch and moan just as loud as they would have done had it been removed in the first place. It's all good stuff, really.

LOL, couldn't agree more.

[Saturn]

We could conceivably leave the existing API in place, but mark it as deprecated, with the usual result that everybody would ignore that and keep using it right up to the point where it's removed, then bitch and moan just as loud as they would have done had it been removed in the first place. It's all good stuff, really.

LOL, couldn't agree more.

I don't think this is the point. Separation of concerns is not so much an issue for the API user but rather for the API developer. With proper separation the concerns can be fleshed out and developed independently of each other.
See the examples hybrid brought about the device class.

The (apparent) downside for the user is, that he/she has to fiddle with more objects of different classes than before. Though it might actually help to better fit into the application's architecture this way *if* you know how to OO design anyway.

@lostclimategames, regarding the points mentioned above, Ogre has a very good design. Concepts are properly abstracted into their own type hierarchies and interfaces.
Both pros and cons from a user perspective follow from this.
To access the name of the first texture of a material in irrlicht:

Code: Select all

myMaterial->getTexture(0)->getName();

In Ogre:

Code: Select all

myMaterial->getSupportedTechnique (0)->getPass(0)->getTextureUnitState(0)->getTextureName();

As you can see more objects are accessed in order to do the same job, but at the same time this is what offers the flexibility in Ogre's material system. A material on the first level is a list of implementions (techniques) that can be used as alternatives (If card supports Shader Model 3.0 use the first, if Shader model 1.x the second, if none, the last one) or as LOD levels.
A techniques can have one or more passes. Passes are executed in order and blended according to the scene_blend attribute. Each pass has none, one, or more texture units, each is applied according to the colour/alpha_op(_ex)
Techniques, passes and texture units each have other settings set apply to them and only to them.
This setup is flexible because it allows all the different aspects to be put together in order to create any possible effect, even effects Ogre's authors didn't even think about, it is like building with Lego pieces.

Irrlicht's materials are more compact (even though material layers have been developed recently) and thus easier to use but also less flexible.

This is the trade-off.

[grafikrobot]

I don't think this is the point. Separation of concerns is not so much an issue for the API user but rather for the API developer.

I think it is a concern for the user. For example I personally find that I would like to remove the XML loading/saving from the scene classes as I have no need for them (at least in my current use case). But this isn't really possible as they are tightly integrated when they don't need to be (as demonstrated by the plugin loaders/writers).

So I'm all for making for some modularity improvements. And as usual for me, my support extends to helping with coding and design.

[Halifax]

Well, if anything, I would imagine that such an API break would be saved for a new version (major, such as 2.0).

But I wholly support the idea!

FlyingIsFun1217

The main problem is that with Ogre I felt lost. I will admit that I really didn't take the time, I only took about 1 week. But with Irrlicht the first time I got it out of the SVN it was very easy to build, no deep directories, and stuff like that. When you get Ogre from SVN, it has a crapload of things, with very deep directories. I also don't agree with the fact that almost everything is done through a pulggable DLL interface, thus forcing the user to ship a lot of DLLs if they are using plugins that don't have source code available.

Also I feel that Ogre is abstracted to the point of almost being overly done, that is just my feeling. I have to say it is a great engine though, I oringally wanted to "graduate" from Irrlicht to Ogre, but Irrlicht still just feels right to me. Also the engine is receving some great new features at an amazing pace, so there really is no need to switch.

The one plus, I like, is of course the material system.

We could conceivably leave the existing API in place, but mark it as deprecated, with the usual result that everybody would ignore that and keep using it right up to the point where it's removed, then bitch and moan just as loud as they would have done had it been removed in the first place. It's all good stuff, really.

Quite possibly you could mark it as deprecated for maybe a set period of time (1-3 weeks or more), then change the function name to _nameOfFunction, and then eventually remove it all in all. That would be a more gradual process, but yeah, I doubt people would even follow it anyways.

I don't think this is the point. Separation of concerns is not so much an issue for the API user but rather for the API developer. With proper separation the concerns can be fleshed out and developed independently of each other.

Yes I agree with that.

And yes, this may not be the most important topic, but I just figured I would mention it. I honestly don't have too much a problem with the API as it is now seeing as I learned it basically.

[lostclimategames]

@saturn thanks for the detailed information

@halifax, sorry for the mini thread hijack