Irrlicht Framework improvement and rewrite

[Guest]

that's just what I try to do.

I know, and it is apreciated!

You don't have the manpower to compete with the all singing and dancing render engines, and that gives irrlicht a more unique place in the world of engines, rather than just another wrapper on an APIs most advanced features with no real day to day use by the intended audience.

[terefang]

I take this as the place to add a few suggestions.

One thing that "does not" separate Irrlicht from other engines is that it uses a
very specific/narrow SceneNode model.

In case of AnimatedMesh-SceneNodes you have to cast the pointer to their specific
class to do anything advanced, like animation or getting joints/bones out of .ms3d/.x
meshes (.ms3d joints are dummytransformationnodes, .x bones are not)

This prohibits using .md3 models without recompliing the engine, since its features
do not easily map to any of those already implemented.

In case of OcttreeSceneNodes, Irrlicht reads only meshdata (eg. from .oct files) and
recreates its own octtree.

Wouldn't it be better to separete SceneNode/Mesh-Types from the Meshloaders ?

Lets sort out the types of nodes:

* Animated
- Meshes (.md2, .md3)
- Joints (.ms3d)
- Bones (.x)

* Static
- Levels (with additional private data; eg. Lights, Spawns, etc.)
- Heightfields (with LOD)
- OctTrees (for performance)

* Other
- Billboards
- Cameras
- DummyTransformations
- Lights
- ParticleSystems
- ShadowVolumes


ad. AnimatedSceneNodes:

Instead of having getMS3DJointNode/getJointName+getMatrixOfJoint/getMD3TagNode
we could have 'one' getAttachmentNode() method with code reused from the ms3d
implementation but available from all fileformats that choose to implement
such information.

Similarly a coheirent setAnimation/addAnimation/linkAnimation/setAnimationLoop
implementation would be nice.


should i elaborate further ?

[hybrid]

I'd like to bump this thread just to allow the current discussions take into account these arguments as well. Furthermore I'm mentioned in a way I'd like to discuss
To add something useful to this discussion (the rest of the text is basically NX bashing )
I'd like to propose a development style which avoids too much confusion and danger of separated Irrlicht branches. Just imagine where Linux would be today if everyone would have branched his own kernel API in the beginning. So people should be encouraged to discuss more on the architecture and API of Irrlicht. But this should be made in the public and without predefined results. I think it will be possible to properly discuss architecture decisions such that changes to the API are not just due to one extension which might need it, but showing a broad consensus of the community. Of course, this will only make sense if there is the hope that commonly accepted decisions will be used in all versions of Irrlicht. But besides IrrlichtNX all branches seem to comply with recent Irrlicht versions.

Ok, now for some arguments of this thread I don't agree with - sorry for finding this thread this late and reactivating it. Please ignore if you don't like X vs Y discussions, as it will probably become one.

whats wrong with this "community" ?
-theres the guy who rather collects patches instead of applying them to a library and publish that one.
-then theres one who posts his code as entries on the wiki
-then there is the question of creating a code-repository for patches and add-ons (came up multiple times)
-then theres this guy who created a nice demo with irrlicht and now goes on to create his own library
-and then there are some who see that irrlicht is not what they need and they try to start something based on irrlicht but "better"(see below on that) or they whine on this forum how bad irrlicht is

Ok, I'm collecting patches. What's wrong with that? No one will be able to use the library in his own app if he's not able to compile the library itself. I'm basically using the engine as is, and I keep some fixes which I find useful in a way that it is easier for me to change to the next version without coding too much. Making these things public is my way of giving back to the community and participating in the development as well. At least I hope that these patches make it easier for others, too.
And I really appreciate the work of Emil as well. Posting to a wiki might not be the best choice to publish code, but it's working and everyone can use it. Both methods are ways to provide a repository.
And hey, there are at least two major spin-offs from Irrlicht already. Yours, which immediately broke with Irrlicht API, and IrrSpintz, which provides quite useful features without completely rewriting the API. Guess which one I prefer

there already is a project started from within this community to make irrlicht more suitable for other things (irrlichtnx). but instead of supporting that and bring your ideas into that project everyone works on his own. i just dont get it.
is it the "not invented here" effect (not created by me cant be good, need to reinvent the wheel) ?
is it that development on nx was stopped for a new project ?

At least for me it was inacceptable to be forced to a completely rewritten API which kept me from NX. Like katoun said, it was no big enhancement redesigning the IrrDevice, but everyone had to agree on the NX style. Isn't your style of branching the best implementation of "not invented here" I feel uncomfortable if someone's trying to tie me to something I did not ask for just by mixing with some things I'd really like to have. Kind of M$ style. But it's a free world, of course, so anybody' allowed to reinvent wheels. But as long as all are incompatible with each other there will also be a large industry for wrapper techniques

[buhatkj]

well I can only speak for my own experience playing with irrlicht since 0.4.2, but I have found that while it is occasionally limiting or overwhelming to have to handle everything but graphics yourself, it also frees you to make what you will of it. The interface is clean, and in only rare cases does it fail to be as easy to use, and simple as possible.
overall I have a hard time backing the idea of any kind of fundamental rewrite or interface change. I like where Irrlicht is going, and I'veliked how it gets there.
some upcoming planned features that interest me in particular are the XML scene node file formats and the skinnable GUI.

[pfo]

Getting back on topic: Katoun, you expressed some interest in a previous post (can't find it now) of cleaning up the material interface. I am in favor of that, I have seen ogre's material interface and its really slick, and easy to use with different renderers. If Irrlicht could do that, that would be sweet! I would be interested in working on such a project. As far as changing anything else in the engine, I think it would break its simplicity and make it clunky. Niko got it right when he said there are too many game features to implement in an engine to satisfy everyone, at some point you have to implement some specifics yourself (like physics, networking and sound).

[zenaku]

Here's a design change that I'd like to see:

Standardization on one string type in all the interfaces. No more irrString, char *, wchar * crap everywhere.

IMO char * and wchar * should all go away. We should make IrrString a std::basic_string with char_type = wchar and use that on all interfaces. Converting wchar_t to char internally in the functions that need char *'s is easy enough. It sure would make full unicode support easier

[pfo]

I second Zenaku's suggestion, and offer another one: more XML reading / writing routines, and better ones too. It would be nice if there were routines to read / write vectors, colors, etc... Also, the writer should be able to take more arguments than wchar_t *, I mean IXMLWriter::writeElement(core::stringw, bool, core::stringw, core::stringw, core::stringw, core::stringw, etc...) WHAT IS THAT?! I use a lot of XML writing, and these few shortcomings are a pain.

[mm765]

hybrid, im afraid you were missing the point i wanted to make with that post (just a little) which is probably my fault for being somewhat unclear.

i didnt mean to say that what people do is bad (like your collection of patches), i wanted to say that its bad (in my opinion) to see how people develop things in parallel instead of working together, which, of course, irrspintz delivers a perfect example for.
(i will name stuff now because i feel stupid for talking about "a certain fork")
Does irrspintz have all your patches integrated ? let me guess - it doesnt. why ? its like 5 minutes work and it would help people that want to have your patches integrated with the new features in irrspintz.
and to make this clear imo its not only spintz's fault that it doesnt happen - you couldve also asked him to add them to give something "even more valuable" to the community.
so - yes your patches are all good and nice and irrspintz is also really nice -
but why the hell arent you guys working together ?

and to clear up some other point: irrlichtnx was purely irrlicht with added patches and fixes, it was only after niko said that he didnt want to use cvs(which is totally ok, its his decision - and of course your decision to work alone is also ok im just wondering why), that there was no reason anymore to keep it 100% compatible - and it was made clear with a new name (nx++) that it wasnt anymore.
so at any point from then on, someone couldve said "heh let me take over nx, i want to keep patches but also want to stay compatible with irrlicht" - nothing happened (the cvs repository still exists) - you still collect your patches and spintz creates irrspintz - and whoever else does whatever else (dont want to pick on you two so much, because at least youre doing something and dont just talk like some others )

but whatever - do what you want and how you like to do it (as i said its your decision) - i just wanted to clear up the misunderstandings and started to rant a bit again - sorry for that.

[mm765]

forgot something...

Like katoun said, it was no big enhancement redesigning the IrrDevice, but everyone had to agree on the NX style.

no it wasnt a big enhancement but a very useful one - for example you can read/write files without creating a device/renderwindow,
can redirect and filter log-messages, have a much better event-system and, of course, all the other advantages of using a singleton

Isn't your style of branching the best implementation of "not invented here"

the "not invented here" in my post was with regard to working together and not in regard to any api design changes.
nonetheless - all api changes were discussed (on forum and irc) so it wasnt "not invented here" but "how can we make things better".
there has, for example, been quite a discussion about the changes to the event system.

I feel uncomfortable if someone's trying to tie me to something I did not ask for just by mixing with some things I'd really like to have.

i dont recall forcing you to use nx or any part of it or trying to tie you to anything.
if i remember correctly,i sent you an email/pm, ASKING, if you wanted to join the nx-team instead of listing the patches on your page - you declined - i never asked again/said anything in that direction.
but at least i tried to work together...

Kind of M$ style.

the rest of your message was ok (criticizism is good, because its the only way to learn and become better) but comparing anything i took part in to MS, i take as a personal insult.

[hybrid]

Sorry to mess up with nx and nx++. I never saw the former, I think, but the webpage and things were not that clear about when it was nx and when nx++. So I probably always meant nx++.

I feel uncomfortable if someone's trying to tie me to something I did not ask for just by mixing with some things I'd really like to have.

i dont recall forcing you to use nx or any part of it or trying to tie you to anything.
if i remember correctly,i sent you an email/pm, ASKING, if you wanted to join the nx-team instead of listing the patches on your page - you declined - i never asked again/said anything in that direction.
but at least i tried to work together...

No, it was not you asking me to join nx++ team which tried to tie me, it's the fact that the major API changes forced me to rewrite lots of my code but any advantages (at that time) were still to come. So I had to obey to nx++ API without getting any really new features. I guess that advanced logging is also possible with Irrlicht's implementation of loggers. And IIRC the singleton implementation had been discussed quite long, but without any consensus (at least for the public forum discussions). So it might have been better to add some features without completely changing architecture and API at that point.

Kind of M$ style.

the rest of your message was ok (criticizism is good, because its the only way to learn and become better) but comparing anything i took part in to MS, i take as a personal insult.

Sorry for that. Don't want to make any personal attacks. But I think it was pretty much my feeling at that time. And one of the main reasons to extract the bug fixes from NX and make them available for plain Irrlicht. Never got to the point where advanced features were back ported, due to lack of time. But I still have the code and maybe...

Just a short remark on why not working together with others (from the other post). Mainly lack of time. I have my job, two children, and currently also my PhD thesis to prepare. Moreover, my job will terminate next april, so I also have to prepare for the time thereafter. And I'm lazy

[JPulham]

Irrlicht works great...a rewrite would bring out different bugs that need fixing. Upgrading maybe, but the current version works great. keep it backwards compatable and focus on fixing existing bugs, not making new ones.

[elander]

mm765:
Could someone give me an example of where Irrlicht fails at being production ready. I'm sure there are some, but I'm still new to game programming that I can't think of any myself.

Irrlicht is an opensource project driven by contributions. Thinking of it in comercial terms is a mistake. A project configuration is needed to easy the use of contributors code in a painless way and help people understand the dependencies in the code quickly without having to browse trought the entire code. Some things can be easly added to the engine trough plugins and dlls which helps contributors and people interested in using contributors code even more.

http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=10158