I switched to Ogre
Why is using an octree for scene management useless (unless I misunderstand you and you're only saying Ogre's implementation is useless)?
You do a lot of programming? Really? I try to get some in, but the debugging keeps me pretty busy.
Crucible of Stars
Crucible of Stars
-
Baal Cadar
- Posts: 377
- Joined: Fri Oct 28, 2005 10:28 am
- Contact:
It isn't useless. I use it successfully with a project of my own without problems. I also use dotscene as scene format, but parse it myself.
I guess it doesn't do what you expected it to do. Irrlicht's OctreeSceneNode takes a mesh and dissects it into octree aligned chunks more or less. The octree is, as far as I understand this, only used to cull the parts of said mesh itself, not to cull the childs.
Ogre's octree scene manager does something different. It doesn't provide a way to throw a big mesh at it to divide it, but it organises all meshes you add to it in an octree and uses this for culling. Quite a difference. The octree sm is more or less a baseclass for an octree-based scene format. For instance the TerrainSceneManager is a subclass of the OctreeSceneManager and uses the octree for its terrain tiles. OctreeSceneManager provides no world geometry abstraction.
I don't consider Ogre's scene management messy, quite the opposite. There is a clean seperation of concerns between the involved components. And it is extensible and pluggable.
But Ogre doesn't provide a dedicated indoor level format other than BSP, which in itself is a format of days of yore. Sinbad is working on a portal based SceneManager for indoor scenes with tools for automatic creation of the portals or manual placement. (This one and the tools will cost though probably) And for outdoor scenes there is the terrain sm, the paging landscape sm and the octree sm.
I guess it doesn't do what you expected it to do. Irrlicht's OctreeSceneNode takes a mesh and dissects it into octree aligned chunks more or less. The octree is, as far as I understand this, only used to cull the parts of said mesh itself, not to cull the childs.
Ogre's octree scene manager does something different. It doesn't provide a way to throw a big mesh at it to divide it, but it organises all meshes you add to it in an octree and uses this for culling. Quite a difference. The octree sm is more or less a baseclass for an octree-based scene format. For instance the TerrainSceneManager is a subclass of the OctreeSceneManager and uses the octree for its terrain tiles. OctreeSceneManager provides no world geometry abstraction.
I don't consider Ogre's scene management messy, quite the opposite. There is a clean seperation of concerns between the involved components. And it is extensible and pluggable.
But Ogre doesn't provide a dedicated indoor level format other than BSP, which in itself is a format of days of yore. Sinbad is working on a portal based SceneManager for indoor scenes with tools for automatic creation of the portals or manual placement. (This one and the tools will cost though probably) And for outdoor scenes there is the terrain sm, the paging landscape sm and the octree sm.
-
Rikan
I fancy myself as a bit knowledgeable of the inner workings of 3D rendering engines, what they actually have to do in order to get some visible (literally) results, and I'm just about to switch over from Ogre to Irrlicht.
It seems the biggest issues which got the thread started are voided by now... Comprehensive API documentation, good tutorials which DON'T stop before things get really interesting (meaning covering things like targeting objects in a 3D environment, collisions, Render To Texture, shaders).
As a matter of fact, Irrlicht is the third engine I'm looking into, not just the second.
The first one was CrystalSpace - looking quite good, yes, but the biggest drawback (at least in my eyes) was the overburdened use of objects and their factories - quite unbecoming for a realtime application since it adds to the management overhead - as well as flaws with pointer usage may go undetected for a long time but turn out to be the reason for some quite nasty crashes.
The second one was, as I said, Ogre. I won't deny that this engine has lots of features, but the biggest drawbacks were the quite LOONG list of dependencies and several problems with rendering on a platform running an ATI board, namely my laptop.
Irrlicht convinced me first with its list of dependencies - namely none at all, which was a GREAT relief after Ogre - and its lightweightedness, cutting compilation time down to a TENTH of the time compared to Ogre, as well as the size of the resulting library.
Compared to CrystalSpace object handling is a walk in the park. Evey object you obtained using a method which started with 'create' has to be drop()ed after use where objects obtained by other means are merely for reference and would be drop()ed by the engine itself when the situation arises. Easy, no questions.
Having the graphics screen initialized and a model loaded and been shown in just a few lines did convince me. I guess I'm 'old school' of programmers - the shorter the better. Fewer lines mean fewer bugs, less memory consumption and speedier execution.
(As a side note it still baffles me that any upcoming version of Windows more than doubles the system requirements than the previous one - and nobody may give a good reason what the additional resources are used for...)
Several features the Ogre engine has may be done with Irrlicht with just a little work, for example, Overlays look to me like the scene is rendered to a texture and the resulting texture is shown after some post-processing with vertex and pixel shaders.
It seems the biggest issues which got the thread started are voided by now... Comprehensive API documentation, good tutorials which DON'T stop before things get really interesting (meaning covering things like targeting objects in a 3D environment, collisions, Render To Texture, shaders).
As a matter of fact, Irrlicht is the third engine I'm looking into, not just the second.
The first one was CrystalSpace - looking quite good, yes, but the biggest drawback (at least in my eyes) was the overburdened use of objects and their factories - quite unbecoming for a realtime application since it adds to the management overhead - as well as flaws with pointer usage may go undetected for a long time but turn out to be the reason for some quite nasty crashes.
The second one was, as I said, Ogre. I won't deny that this engine has lots of features, but the biggest drawbacks were the quite LOONG list of dependencies and several problems with rendering on a platform running an ATI board, namely my laptop.
Irrlicht convinced me first with its list of dependencies - namely none at all, which was a GREAT relief after Ogre - and its lightweightedness, cutting compilation time down to a TENTH of the time compared to Ogre, as well as the size of the resulting library.
Compared to CrystalSpace object handling is a walk in the park. Evey object you obtained using a method which started with 'create' has to be drop()ed after use where objects obtained by other means are merely for reference and would be drop()ed by the engine itself when the situation arises. Easy, no questions.
Having the graphics screen initialized and a model loaded and been shown in just a few lines did convince me. I guess I'm 'old school' of programmers - the shorter the better. Fewer lines mean fewer bugs, less memory consumption and speedier execution.
(As a side note it still baffles me that any upcoming version of Windows more than doubles the system requirements than the previous one - and nobody may give a good reason what the additional resources are used for...)
Several features the Ogre engine has may be done with Irrlicht with just a little work, for example, Overlays look to me like the scene is rendered to a texture and the resulting texture is shown after some post-processing with vertex and pixel shaders.
I just wanted to pitch (bitch?) in and say that while I find Irrlicht extremely well designed engine that is easy to learn and can be used in a logical manner, it still suffers from some childish problems.
I scrolled few pages back in this topic and noticed there was some argument about things that Irrlicht can do, assuming one codes a little bit more. Like the shaders, or circumventing the (extremely silly and completely moronic) limit of two textures per material (you're screwed if you want diffuse+normal+spec map per material which is about the standard these days, I'd like to mention), would require coding those shaders by yourself or modifying the engine itself (!).
Which completely and utterly destroys the whole point of having an engine, I'm afraid. If I'm using an engine, I'm doing it because I want to have easier time when programming, I'm not wanting to program an engine here after all. That is the main reason why I'm switching to Ogre.
Moving on, Irrlicht does have its plusses. The speed, the builtin GUI and other features, make me feel a bit sad that I have to abandon otherwise good engine because of some childish issues. And it's very unclear to me why these things can't be fixed, I mean, Irrlicht's already 1.0 now.
Anyway, this is the first proper engine I've tried to use, so I might be completely wrong here, but that's my reasons and feel free to whine about them if you like.
I'll sit here and drink, thinking about both you and me.
I scrolled few pages back in this topic and noticed there was some argument about things that Irrlicht can do, assuming one codes a little bit more. Like the shaders, or circumventing the (extremely silly and completely moronic) limit of two textures per material (you're screwed if you want diffuse+normal+spec map per material which is about the standard these days, I'd like to mention), would require coding those shaders by yourself or modifying the engine itself (!).
Which completely and utterly destroys the whole point of having an engine, I'm afraid. If I'm using an engine, I'm doing it because I want to have easier time when programming, I'm not wanting to program an engine here after all. That is the main reason why I'm switching to Ogre.
Moving on, Irrlicht does have its plusses. The speed, the builtin GUI and other features, make me feel a bit sad that I have to abandon otherwise good engine because of some childish issues. And it's very unclear to me why these things can't be fixed, I mean, Irrlicht's already 1.0 now.
Anyway, this is the first proper engine I've tried to use, so I might be completely wrong here, but that's my reasons and feel free to whine about them if you like.
I'll sit here and drink, thinking about both you and me.
I think we can all agree all the engines lack things to be desired, and need improvement. But instead of everyone just saying man this engine is lame, im switching or that engine is lame I'm switching, I think we need to come up with a list of standard features that should be a part of the engine. Then work towards implementing these features.
Your modifications are great. I wonder why Niko doesn't integrate at least some of these features.That's exactly the reason for IrrSpintz.
Examples:
- A lot of people are complaining about the 16 bit indices because of the terrain, so why we use still 16 bit as default?
- Your particle extensions are great, spintz, so why they are not in the engine as default?
- Several bugfixes...
Regards - Xaron
-
hybrid
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
since Niko announced a focus on integration of available features for the next versions the situation should become better now. I'm still not sure about the way this will be done because all developers with access to CVS/SVN are hardly present in the forums (or even don't use CVS actively - is Irrlicht 1.0 checked in somewhere 
)
So one of the developers should become maintainer of the development version and - probably after discussion in the forums - check in new features in the head revision of the publically available sources. I hope that Niko will find some more time for the community as he promised lately.
)So one of the developers should become maintainer of the development version and - probably after discussion in the forums - check in new features in the head revision of the publically available sources. I hope that Niko will find some more time for the community as he promised lately.
at the end of the day if you can design a better engine, go ahead :p
what most people neglect to think about is that these guys are developing it in their spare time, if they worked on it full time it most probably would greatly improve (although there is nothing wrong with it now). I enjoy Irrlicht and I congratulate the Irrlicht team + contributors
what most people neglect to think about is that these guys are developing it in their spare time, if they worked on it full time it most probably would greatly improve (although there is nothing wrong with it now). I enjoy Irrlicht and I congratulate the Irrlicht team + contributors
-
Baal Cadar
- Posts: 377
- Joined: Fri Oct 28, 2005 10:28 am
- Contact:
mR.haHN, the moment I saw your posts in the Ogre forum, I knew I had to watch this thread for a post like this. It is true, Ogre requires basic IDE knowledge to set it up. If you were just a bit more persistent and accepting of help in the forum, you might have gotten it to work.
At least you can't say, I (haffax) didn't try to help you.
At least you can't say, I (haffax) didn't try to help you.
Hey, its ok, I really appreciate your help, but when I saw that the Visual Express installer wanted to download 93 MB, I was just annoyed (I only have ISDN 
)
Sometime, I will try to get OGRE somehow running in *ANY* IDE, but now, I just dont want to "waste" (sorry if this is offending) my time setting up an IDE! Especially when I see that setting up Irrlicht in DevC++ requires 10 mins of work!!
EDIT: I think 1 year or so ago I used OGRE in DevC++ with some DevPak. Setting that Version of OGRE in DevC++ was no problem for me. Thats why I´m so annoyed that OGRE is no longer available for DevC++...
) Sometime, I will try to get OGRE somehow running in *ANY* IDE, but now, I just dont want to "waste" (sorry if this is offending) my time setting up an IDE! Especially when I see that setting up Irrlicht in DevC++ requires 10 mins of work!!
EDIT: I think 1 year or so ago I used OGRE in DevC++ with some DevPak. Setting that Version of OGRE in DevC++ was no problem for me. Thats why I´m so annoyed that OGRE is no longer available for DevC++...
-
Baal Cadar
- Posts: 377
- Joined: Fri Oct 28, 2005 10:28 am
- Contact:
Nah. Not offended at all. 
Dev-C++ is just not used anymore for Ogre. And thus no one keeps the devpacks in sync. This is the more important, as Ogre has quite a lot of dependencies, whose packages have to be kept up-to-date too.
For Irrlicht, Dev-C++ is quite popular, thus the support for it is much better and not having external dependencies makes the whole setup thing easier anyway.
Dev-C++ is just not used anymore for Ogre. And thus no one keeps the devpacks in sync. This is the more important, as Ogre has quite a lot of dependencies, whose packages have to be kept up-to-date too.
For Irrlicht, Dev-C++ is quite popular, thus the support for it is much better and not having external dependencies makes the whole setup thing easier anyway.