IrrEdit and friends - Big Waste of Niko's and friends' time
Well, i decided.. I'm switching to Ogre. Irr's future as good game renderigng engine is very uncertain. I'm workin' on serious project, and i need serious engine. It is needed to fix elemental negletcts, like light limitantion (light0 ... light7), improve built-in shaders (shading is most important part of present engines, isn't it? ) and other stuff like that... just after it all, other tools like irrEd should be considered...
I can't imagine to make serious game on unserious engine which cannot add more than 8 (7) lights to scene. Of course, i cant make shader or improve Irrlicht, but i am working on game, not engine, and i don't have time for correcting that elemental bugs...
I can't imagine to make serious game on unserious engine which cannot add more than 8 (7) lights to scene. Of course, i cant make shader or improve Irrlicht, but i am working on game, not engine, and i don't have time for correcting that elemental bugs...
-
- Posts: 1029
- Joined: Thu Apr 06, 2006 12:45 am
- Location: Tennesee, USA
- Contact:
It is very easy to setup Ogre in C::B (far better than Dev-C++) + Mingw C++ Toolkit;
1) Download night build of C::B and Mingw C++ Toolkit from Ogre's page
2) Install them
3) Download Ogre SDK for Mingw Toolkit and setup it
4) Enjoy!
1) Download night build of C::B and Mingw C++ Toolkit from Ogre's page
2) Install them
3) Download Ogre SDK for Mingw Toolkit and setup it
4) Enjoy!
But i'm working on big project and my conclusion sounds: Irrlicht isn't fit to make serious game with it, although it's good as learning engine ( very simple design )I think we talk about hobby programmers?
Always a good idea to test several engines before starting a large project :-) Ogre is a really good engine and if it got all the features you need than it's certainly the right engine for you.Valtras wrote:Well, i decided.. I'm switching to Ogre. .
First i think _it is_ already a quite good game rendering engine, currently the best one i know with such a liberal license. Saturn did had some complains in his posts where i can agree and Irrlicht could maybe get better in announcing which features are planned. But all in all Irrlicht did move along in the last years at a quite fast pace and since Hybrid is in the team it seems to improve even faster.Valtras wrote: Irr's future as good game renderigng engine is very uncertain.
I'm also working on a serious project and i'm already close to finishing it. If you need that features absolutly and you don't want to programme them, than you can certainly not use Irrlicht (doh). But you should see that the features which you need so urgently are not necessarly the features which everyone else does want. I don't know if more people need an editor or more people need more than eight lights, but programming an editor yourself is a lot more work than getting around the light limit, therefore i think most people would prefer the editor.Valtras wrote: I'm workin' on serious project, and i need serious engine. It is needed to fix elemental negletcts, like light limitantion (light0 ... light7), improve built-in shaders (shading is most important part of present engines, isn't it? ) and other stuff like that... just after it all, other tools like irrEd should be considered...
I can't imagine to make serious game on unserious engine which cannot add more than 8 (7) lights to scene. Of course, i cant make shader or improve Irrlicht, but i am working on game, not engine, and i don't have time for correcting that elemental bugs...
And just in general .... never expect an engine to do everything for you - even the really big and expensive engines won't do that ;-)
Well, I think Ogre blows, won't get into reasons why here.
I had same problems with Irrlicht for over a year, I made IrrSpintz. Dabbled a little with development in IrrlichtNX and Lightfeather, and yes, even tried Ogre. When it all came down to it, the core engine and setup is nice here( aside from renderstates ) and very easy to work with and extend, just using C++. I see no value in all the python, .NET, ruby, etc. stuff. So I made IrrSpintz. I've added Vertex and Index buffers, gotten rid of the SColor problem, Particle System enhancements and addons, animator callbacks, and MANY other changes....that I want.
I also take suggestions from others. And, believe it or not, A LOT of the changes have gone back into Irrlicht. Some of the changes are not refined enough to be brought back in.
Niko has always been shady about the progress and development of Irrlicht, at least to the community( don't know about what hybrid, bitplane, etc. talk about ).
Point is. You have one of the best frameworks for an engine right here....WAY better than the way Ogre is setup, which is just a nightmare. You're enjoying Ogre because you're using it as is. The second you need to change something to make it work they way you exepected/wanted it to, you're going to get heartburn immediately.
I have a very hard time believing that you're going to program a cutting edge technology game, but don't have the resources or ability to manipulate an engine( especially one as simple to extend as this ) to do what you need. If your intention was simply to ask for extension of the light limit( which is obviously the major gripe you have ), a nicely worded suggestion would have been taken in much easier...
I had same problems with Irrlicht for over a year, I made IrrSpintz. Dabbled a little with development in IrrlichtNX and Lightfeather, and yes, even tried Ogre. When it all came down to it, the core engine and setup is nice here( aside from renderstates ) and very easy to work with and extend, just using C++. I see no value in all the python, .NET, ruby, etc. stuff. So I made IrrSpintz. I've added Vertex and Index buffers, gotten rid of the SColor problem, Particle System enhancements and addons, animator callbacks, and MANY other changes....that I want.
I also take suggestions from others. And, believe it or not, A LOT of the changes have gone back into Irrlicht. Some of the changes are not refined enough to be brought back in.
Niko has always been shady about the progress and development of Irrlicht, at least to the community( don't know about what hybrid, bitplane, etc. talk about ).
Point is. You have one of the best frameworks for an engine right here....WAY better than the way Ogre is setup, which is just a nightmare. You're enjoying Ogre because you're using it as is. The second you need to change something to make it work they way you exepected/wanted it to, you're going to get heartburn immediately.
I have a very hard time believing that you're going to program a cutting edge technology game, but don't have the resources or ability to manipulate an engine( especially one as simple to extend as this ) to do what you need. If your intention was simply to ask for extension of the light limit( which is obviously the major gripe you have ), a nicely worded suggestion would have been taken in much easier...
Not really imho. Under the hood Ogre is much more cleanly written. Also from looking at the source, the source code quality is higher in Ogre imho. Ortogonal aspects are abstracted and seperated into their own classes. Which is largely not the case in irrlicht, which makes it less easy to extend and leads to repeatetive code. This separation also makes extension easier, since concerns are not scattered over the whole lib, but nicely encapsuled in a few places.Spintz wrote:Point is. You have one of the best frameworks for an engine right here....WAY better than the way Ogre is setup, which is just a nightmare. You're enjoying Ogre because you're using it as is. The second you need to change something to make it work they way you exepected/wanted it to, you're going to get heartburn immediately.
See for example the animated meshes. Irrlicht has support for X, MS3d and B3D skeletal animation. But since there is no animation system underneath it all, you have to rewrite everything for each format. Each loader has their own bones, frames etc. Eventhough the concept itself is identical. If you somehow want to extend animations API, you have to write the code for each file type seperately. And the client app has to be aware what type of animated mesh it uses in order to attach soemthing to a bone. Tedious.
Also, there is much less need in Ogre to extend it, because you can most of the time just use it. Behaviour is largely configurable and pluggable. In Irrlicht you have a few special case materials, in Ogre you have a material system, that allows you to define passes, blend modes, texture operations, etc as you want them. In Irrlicht you have to change the engine. Same for vertex formats. In Irrlicht you have three to choose from, in Ogre you are completely free in choosing the vertex format and in distributing meshes over buffers. This goes on in all areas, shadows (plug your own texture shadow renderer if you want), resource system, scene management, render order, post effects, etc, etc..
All this comes with the cost, that you have much to learn in the beginning and you don't know where's front and where's back. API docs are huge (though generally better than irrlicht's).
That's to me the distinction and that's also why I believe that irrEdit fits with Irrlicht nicely. Irrlicht is an easy-to-use and ready-to-use package. You get prototyped materials that cover most cases, you get vertex types for most cases and both are easy to understand and use. You can use common filetypes and thus just use models already there. IrrEdit provides a level editor for its native scene format and all is ready to go. And Irrlicht is more suited for low-end hardware. But flexibility is not a strong point of irrlicht.
Spintz, if I may ask: What part did you want to change in Ogre when you tried it?
Ohh men, i don't have time to extend this engine and learn its nuances! Ask a question - Are ya going to make game, or engine? I decided - i'm making a game and this is a point! I have written some my own engines some time ago i need to start project, which i have been preparing for years... and i need the complete engine, not imperfect one... Ogre's developement is far better well organised... engine is ready to make a game on it. ( Look at commercial projects made on it... Irrlicht haven't )
Are ya going to make game, or editor ?Valtras wrote:Are ya going to make game, or engine?
It's too easy to say "since Niko is doing irrEdit, Irrlicht could be hell better !", I love extending the engine and I must really say that Irrlicht fits my needs whereas Ogre DOES NOT !
Moreover, whereas I agreed with the fact that irrEdit needed to have major updates instead of graphical ehancement and tiny stuff like that, I do not agree with this comparison between both engines this post has turned into...
Just take a look at how easy it is to add new features to the engine, Just realize that the Irrlicht engine, if not filled with "ready to use" beautiful scene nodes, is quite easier to code on and to improve... I can really say that because I used Ogre(DotNET also) and made an Irrlicht wrapper for this kind of features, it is really well-made.
BTW : I tested irrEdit 0.5, it is just great even though it needs more stuff
Look at the ones that use Irrlicht without saying or just with a little caption on the About page... Look at Irrlicht's license !( Look at commercial projects made on it... Irrlicht haven't )
A 3D engine is not *just* some screenshots with some beautiful laggy and buggy shaders, if you think it is then I agree, Irrlicht is the worst of all but this is definitely not my point of view.
Irrlicht .NET complete and Cross Platform Wrapper
The kid on my avatar wrote:A painless lesson is one without any meaning
No you may not I'm not going to discuss Ogre in this thread, or in any other boards on this forum.Spintz, if I may ask: What part did you want to change in Ogre when you tried it?
Valtras....then go use Ogre, no one is stopping you. You're not going to get any support here by threatening with leaving and using another engine.....Just do it!
And Saturn, why do you throw OO buzzwords around like they are going out of style -
And you were throwing them around in that camera thread in beginners forum. I'm sorry, but I have a pet peeve with people that preach concepts and buzzwords. In my experience, the people I've worked with that were like that were great managers and PowerPoint engineers, but made for terrible programmers...Ortogonal aspects are abstracted and seperated into their own classes
Last edited by Spintz on Fri Oct 20, 2006 1:08 am, edited 1 time in total.
-
- Posts: 313
- Joined: Tue Nov 01, 2005 5:01 am
Much as my experience is the same as yours, Spintz (i.e. buzzwords are a managers tool, not generally the coders) - I understood & agreed with the quoted comment.
Irrlicht tends to repeat similar code/functions across multiple classes because things are not properly split into "orthogonal aspects" of the engine's functionality. The skeletally animated meshes is a good example of this. The "best" (and most future proof) method of doing this is to make a single "skeletally animated mesh" class and have different file formats fill in the required data as necessary. Instead we have multiple classes implementing boned meshes based on the "file format" (a loading issue) rather than the functionality (a "representation" issue).
I'm not defending Saturn here (as I have not read any of his other threads), just the issue behind the comment you chose to quote.
However, you have 100% of my support on the fact that "I'm moving to OGRE" comments are not needed here, at least not as threats. If you think OGRE is a better engine for you - use it. I personally think OGRE's functionality IS better than Irrlicht's, however I'm prejudiced in regards to licensing. Still, you don't see me making threats here or over on the OGRE boards. If you can do better, Valtras, do so!
--EK
Irrlicht tends to repeat similar code/functions across multiple classes because things are not properly split into "orthogonal aspects" of the engine's functionality. The skeletally animated meshes is a good example of this. The "best" (and most future proof) method of doing this is to make a single "skeletally animated mesh" class and have different file formats fill in the required data as necessary. Instead we have multiple classes implementing boned meshes based on the "file format" (a loading issue) rather than the functionality (a "representation" issue).
I'm not defending Saturn here (as I have not read any of his other threads), just the issue behind the comment you chose to quote.
However, you have 100% of my support on the fact that "I'm moving to OGRE" comments are not needed here, at least not as threats. If you think OGRE is a better engine for you - use it. I personally think OGRE's functionality IS better than Irrlicht's, however I'm prejudiced in regards to licensing. Still, you don't see me making threats here or over on the OGRE boards. If you can do better, Valtras, do so!
--EK
Irredit and visual editor s are indispensable tools for people approaching from the 3D-artist side. What kind of argument is "they can always write their own editor" for them?
It probably sounds kinda selfish to them. Apart from that i find statements like "the development of Irrlicht is somehow undefined" quite discouraging for Niko. If you are "cool programmers" then simply make it better yourself, but don't even think of telling Niko a development plan. As you are able to program an editor yourself, it won't be too hard for you and always better than bullying a project which expands the scope of Irrlicht to artists with a slight affinity to programming.
It probably sounds kinda selfish to them. Apart from that i find statements like "the development of Irrlicht is somehow undefined" quite discouraging for Niko. If you are "cool programmers" then simply make it better yourself, but don't even think of telling Niko a development plan. As you are able to program an editor yourself, it won't be too hard for you and always better than bullying a project which expands the scope of Irrlicht to artists with a slight affinity to programming.
Well, in my experience ignorance doesn't make for good programmers either.Spintz wrote:And Saturn, why do you throw OO buzzwords around like they are going out of style -
And you were throwing them around in that camera thread in beginners forum. I'm sorry, but I have a pet peeve with people that preach concepts and buzzwords. In my experience, the people I've worked with that were like that were great managers and PowerPoint engineers, but made for terrible programmers...Ortogonal aspects are abstracted and seperated into their own classes
Seriously. These are not "buzzwords", these are communication tools. They allow to convey much information with little words and thus make communication more efficient.
I am not a manager, but I am not a code monkey either. Having basic software engineering abilities is a vital part of being a good programmer imho. And what is wrong with concepts? If I can't break down a system into concepts how will I be able to lay out a good design?
And I don't see how your preconceptions about what type of programmer I am warrant this kind of hostility. So instead of throwing dirt into my direction, why not answer the arguments I gave?
-
- Posts: 313
- Joined: Tue Nov 01, 2005 5:01 am
noreg:
There are some of us that ARE putting our money where our mouth is in regards to improvinig Irrlicht. The primary issue (that I see being mentioned) is that YOU never get to see it as the only patches accepted (other than Niko's) are bug-fixes.
Most all successful open-source programs have an active benevolent dictator. The issue with Irrlicht is not the "benevolent dictator" part, but the "active" bit. If Irrlicht is to move forward, it needs to accept features developed by people other than Niko, as he is lately (more often than not) busy with something else.
--EK
There are some of us that ARE putting our money where our mouth is in regards to improvinig Irrlicht. The primary issue (that I see being mentioned) is that YOU never get to see it as the only patches accepted (other than Niko's) are bug-fixes.
Most all successful open-source programs have an active benevolent dictator. The issue with Irrlicht is not the "benevolent dictator" part, but the "active" bit. If Irrlicht is to move forward, it needs to accept features developed by people other than Niko, as he is lately (more often than not) busy with something else.
--EK