Irrlicht feature enhancements

[BlindSide]

Cant you set the shape of water mesh?
Oh, Irrlicht is even more dumb and limitated than I tought!

Well, theoretically there is no problem with changing the shape of water surface... you have to create triangle shape that will cap your tank and apply the water shader to it.

A bit offtopic but, I find the built-in water scene node very limited and wouldn't mind if it was removed (The exact same technique can be much performed much easier and much more efficiently using a simple vertex shader). It would be good to do a cleanup of all the outdated scene nodes still present in Irrlicht and streamline it a bit.

[hybrid]

Replacing a working node with one that won't work on e.g. old iPhones seems a little counter productive. Moreover, the node is working properly, as long as it is used correctly. There's no doubt that it could be made more efficient in certain situations. Maybe even changing it to a scene node animator would be good. But nevertheless always backward compatible.

[ent1ty]

Staying backward compatible is sweet, but my opinion is that this is what is counter productive. If someone wants to run Irrlicht on iPhone, why don't let them use older version of engine?

[randomMesh]

Staying backward compatible is sweet, but my opinion is that this is what is counter productive.

Why? What's the problem with an additional scene node?

If someone wants to run Irrlicht on iPhone, why don't let them use older version of engine?

Why don't let them use the most recent version of the engine?

I really like to keep that node since it works fine for me. I can't use any shaders on my hardware.

[stefbuet]

An other problem is that if we use vertex shader to animate the mesh, users won't be able to use any other shaders on the water surface. For exemple you can use EMT_REFLECTION_2_LAYER or any other shader effects while using the water surface node.
But what about :
node = smgr->addHardwareWaterSurfaceSceneNode();
With the most used effect reflection_2_layer?

By the way, this is a really simple shader, so I think experimented users who need this won't have so much problems to do it. We could even put the shader snippet on the wiki?

[ent1ty]

Staying backward compatible is sweet, but my opinion is that this is what is counter productive.

Why? What's the problem with an additional scene node?

There is no problem with one scene node, but should you apply this strategy everywhere, you are really missing out. Like the D3D8 driver, almost no-one uses it, and because of that little thing, you will have to recompile engine if you want to use HLSL with shader model 3.0.
But I guess I should be glad that Glide is not supported \

I can't use any shaders on my hardware.

Well then I absolutely understand why you thinks so^^. But for people, who are aiming for better hardware, it is a handicap.

[Bate]

A cheap SM2.0 gfx card is less than 20€... so, come on

[slavik262]

I'd fully agree with BlindSide. I know that support of lower-end hardware is important to Irrlicht, but it seems like a general trend that older, outdated parts are being held on to at the cost of keeping Irrlicht up with current hardware. As ent1ty said, it's not just the one scene node, but the overall approach we see in other places as well. Direct3D8 should be dropped. People who want support with older devices can feel free to use OpenGL, but it's crazy that you have to recompile just to use Shader Model 3.0. If Irrlicht is going to keep up with modern hardware and other engines, it has to grow and evolve.

[Kalango]

Well i do not agree with all that has being said.
As important as old versions compatibility may be, it is also important for irrlicht to get up to new technologies and stuff that can bring people (specially more devs) to the engine.
I am sorry but i will have to compare Irrlicht to Ogre-like engines, some are newer but seem way more evolved than irrlicht.
I like irlicht, but i see that its evolution is slow and sometimes i think i may want to change from irrlicht to another engine. I see that, without really great great effort, you just cant make something like a next gen game or one simple comercial game.
Sometimes it amazes me that i dont see any kind of comercial games or so using irrlicht as i see using other engines.
Also, its interesting see that the devs say that the forums are all fileed up with rrlicht patchs and add ons but, for a beginer is hard to find them (the search tool sux). The wiki is realy short of updates and it could use more links to threads that the 'todo' category seem to point (when there is somethng solved already like the post processing add on)...
Oh well...

[slavik262]

I am sorry but i will have to compare Irrlicht to Ogre-like engines, some are newer but seem way more evolved than irrlicht.

Agreed. I know Irrlicht is a different beast than OGRE, and both are potent engines, but it seems like OGRE is continuously adding intrinsic, in-engine support for lots of modern day effects while Irrlicht clings to support of older things that a minority of the community even uses. *cough* D3D8 *cough* That isn't to say that Irrlicht does't add anything new, but progress does seem slower. Things OGRE has that Irrlicht would benefit leaps and bounds from:

• LOD support for all scene nodes
• Built-in composter system that easily supports post-processing (I know we have XEffects, but as both its author and Hybrid have said, it's far from being part of the engine itself)
• Multiple effect pass support

I'm well aware that Irrlicht lets you do anything you can in OGRE by writing your own custom shaders, recompiling to support newer shader models, etc., but there's something to be said about those features being built-in. I'm also aware that the Irrlicht developers have lives too, and that the community can help by posting good patches, so I'm sorry if I come off as someone just complaining and not doing anything about it. Know that a lot of us in the community are focusing on our projects with the engine instead of the engine itself.

After reading this post you might want to respond with, "Well if you love OGRE so much, why not switch to it?" My answer to you would be that I love Irrlicht and the simplicity and organization of its API. I'm just worried about it falling behind, and while Irrlicht more than satisfies my needs for the current projects I'm doing, I feel that I'd be tempted to look into OGRE for future projects if I start using more advanced techniques.

[Kalango]

Not just D3D8, but some stuff like reduced support for some kind of shader models. Also Cg support shoul already be deafult (since the patch look pretty good already).
Also "simple" stuff like video playing for default and so on...
You can say "do it yourself", but i say "if i knew how to do it....i would". And also..if i had the time....
Anyways..just a few thoughts...

[Lil Margin]

As important as old versions compatibility may be, it is also important for irrlicht to get up to new technologie

And thats the only thing that pisses me about irrlicht...
it would be better to make one final version for old compatibility computers and start with the next gen irrlicht, lets face it...people use irrlicht more for games then do for anything else and all "true" gamers has a pc thats updated(not saying the latest technologies but they got something worth to play gears of war) so i say moving on with irrlicht to next gen is a good idea.

[blAaarg]

Well, more to the original point of this thread (i.e. the water scene node being eliminated for whatever short-comings it may or may not have), it concerns me that the conversation can rapidly devolve into a b*tchfest about features that Irrlicht doesn't have yet. Those might be useful arguments in considering where Irrlicht might go moving forward with what resources it has available to do so (and I hear ya'), but as far as suggesting Irrlicht should focus on excising currently working and useful features as a path to making it even more "mature", I don't think that actually increases the utility or ease of use of the engine, and so I don't think it actually makes a good focus for direction in the community.

As for myself, I'm using a 2 and a half year lap top that--while not shiny and new--isn't quite ancient yet. It isn't gonna handle pixel shader 3.0, I can't replace the video card, and telling new Irrlicht users that before they try the engine they're going to need to pony-up for top of the line hardware doesn't necessarily make it more accessible or powerful. Also, while I hear that everyone who uses shaders considers them easy, I'm not using them explicitly so the idea of having to write my own shader before I can get existing functionality is a little off-putting. (not that I wouldn't mind learning about shaders, but I haven't really found a tutorial that doesn't assume I'm already familiar with the pipeline/concepts/terminolgy. If anyone wants to point out one out that they find, though, hint hint ) Still, let's not throw the baby out with the bathwater.

One of the things I liked about Irrlicht when I started looking at it (after considering Ogre) was that it seemed to provide both the potential for the user to develop more sophisticated systems, while not requiring a higher level of sophistication to get started. In other words, the fact that there were more "bells & whistles" that were provided available to the user of Irrlicht, doesn't mean one is married to those tools, but can freely integrate other tools as desired/needed. Whereas Ogre seemed to offer an enticing approach to rendering, their insistence that they are "only a rendering engine, go out and learn a bunch of different libraries first before you can use it" didn't really help me as I'm not a team of developers. Irrlicht, it seems to me, has just as tall a ladder but with more rungs at the bottom, and I don't think that's what's "holding it back".

If you don't want to use the waterscene node--or want to create a new one and offer it to others--that's fine. When something better comes along, the old version can be deprecated if it's not compatible. And I'm not saying there aren't limitations to Irrlicht (there are, just as there are to anything other engine that's offered) or that some people haven't made some legitimate points. Just that "what do we need to get rid of" and "what do we need to add" are two different discussions. And, yes, at some point those discussion merge, but I'd look to more of an approach of expanding usability first rather than cutting out existing functionality.

The existence of the current water scene node isn't hurting anyone. I'm not against focusing more on, say D3D10/11, etc., just, let's not break the interface more than necessary.

[Virion]

As important as old versions compatibility may be, it is also important for irrlicht to get up to new technologie

And thats the only thing that pisses me about irrlicht...
it would be better to make one final version for old compatibility computers and start with the next gen irrlicht, lets face it...people use irrlicht more for games then do for anything else and all "true" gamers has a pc thats updated(not saying the latest technologies but they got something worth to play gears of war) so i say moving on with irrlicht to next gen is a good idea.

I'd vote for this one. Let us split Irrlicht into 2 versions - one which support the older technology and another one that goes for next gen.

[hybrid]

As important as old versions compatibility may be, it is also important for irrlicht to get up to new technologie

And thats the only thing that pisses me about irrlicht...
it would be better to make one final version for old compatibility computers and start with the next gen irrlicht, lets face it...people use irrlicht more for games then do for anything else and all "true" gamers has a pc thats updated(not saying the latest technologies but they got something worth to play gears of war) so i say moving on with irrlicht to next gen is a good idea.

I'd vote for this one. Let us split Irrlicht into 2 versions - one which support the older technology and another one that goes for next gen.

Oh yeah, brilliant idea Remember that we're already short on time for the first version
There's really no point to throw out d3d8. It's working code, and no one really pays for it, neither the user nor the developers. If a new feature can be added to d3d8 as well, it's done so, otherwise that driver just falls behind like the SW drivers. We don't postpone any updates just because we didn't update the d3d8 driver so far.
Moreover, if you really intend to develop anything with Irrlicht, you *must* recompile it on your own. We don't provide debug versions of Irrlicht, and you should usually adapt the release settings to your project's one. So don't complain about these five minutes to spend once for each version. You should really rethink your arguments before posting next time.
The current Irrlicht code should be capable of being used with any shader model - sometimes only after recompilation. The reason that we currently provide the precompiled version with a DX SDK from 2004 is that the shaders used in the core engine are from that date. If someone sees some benefits from providing newer shaders, e.g. for the normal mapping, we might consider updating both the shaders and the DX version. For now, it's simply not necessary from the engine's point of view.
Not meant offensive in any way, but the Cg patch is in no way ready for inclusion. The differences in the APIs between HLSL/GLSL approach and Cg are too large. I did start to merge those a few month back, but did not yet finish. Nevertheless, such patches are well worth the work, because right now people can already use Cg, and it makes the jobs easier for us developers as well. So I really appreciate esp. Nadro's job and also added his occlusion query patch (also much reworked) recently.
As most readers of this thread might already found out, Irrlicht has its strength in different areas than, e.g., Ogre. It's the simplicity of the API and its support for low-end hardware. And we'll cling to both of these features. Both make updates to the feature list indeed hard, and can lead to long update times. However, it keeps a significant market for Irrlicht, while we might get annihilated once we become yet another shader-based render engine. Not that we rule out this technique at all, BlindSide is the one who is working on shader-based extensions for Irrlicht. But we will always keep the original low-end versions of the effects, and we will also keep working on those. And in case we really come to a point where one technique prohibits another one, the backward cmpatible will be given priority. I doubt, though, that such a situation will really happen.
Ok, any other things? Well, maybe just another reminder that keeping these foundations in mind, and writing excellent, well tested, and nicely fitting patches will increase their addition probability. Moreover, all those patches could be managed within the irrExt project if someone would volunteer for this job. Seems that no one really cares that much, though. And to those that reply "But I cannot code that well": In that case please also avoid discussions like this one, because you cannot assess the actual situation of projects like Irrlicht. Just ask for features on our feature tracker and let the rest for people who can assess it.

BTW: Renamed and moved the thread, as the original topic wasn't really the point here.