Irrlicht feature enhancements
Just noting that I'm also still using the current waterscenenode in a project. And I don't want to add shaders in that project because it should run even on laptop graphic cards which are enough trouble already even without shaders.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Hehe, nicely put. "Shut up if you have no clue", but I'm ok with that and since I'm one of those I'm just observing.hybrid wrote:"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.
Never take advice from someone who likes to give advice, so take my advice and don't take it.
-
shadowslair
- Posts: 758
- Joined: Mon Mar 31, 2008 3:32 pm
- Location: Bulgaria
Um, sorry for bumping here, but I needed to post in this thread. One thing I like about Irrlicht is that you have some solid base code and everything is prepared for you to build over it- adding own scenenodes, materials, animators and on. As everyone`s game is different, developed for different specs you will create your own object hierarchy, effects and on exactly the way you like. Fine, we can have nice and shiny build-in water scenenode, but there will always be someone, who won`t like it this way and again, will create his own.
On the topic: I don`t see any problem with the default plane water scene node- If I need some, I`m sure I`ll be fully capable of creating one in no time, which will be exactly what I need. Plus, I`m 10 times less experienced than most of the users here.
About the shaders: Yeah, I`m for the next gen shaders and on, but assuming most of the gamers have high-end hardware is some quick guess. Still, Irrlicht is engine for 3d and 2d visualisation, not game engine. And I know some engineer collegues using it for visualisation of industrial, machine, or home heating installations, which applications they created in no time, using them in the early decisions, planning and calculations, and making their life easier while working on "real-life" project. What most of the people do is take irrlicht, take some physics engine, code some shaders and "viola!" they have a game engine. We have 12000 registered users and many that are not even registered, not seeing them posting every day, but they are working on their projects, and using Irrlicht for it`s qualities. Yeah, I liked the OGRE demos, but when I created one plane, one light, a skybox and two ninjas - having not more than 2500 trigs on 1680x1050 screen I got 75 fps in release mode. There are so many things OGRE runs in background, that my app cannot breathe. It has auto LOD for all nodes- I was really pleased of the automatically generated LOD for my two 1000 trigs ninjas... I needed LOD for some objects in my game, in fact I needed to switch between 3 different manually created LOD meshes- man, I did this working fine in 30 minutes. It may not be what most of you want, but it was what I needed and I "implemented" it in no time. And I create all my "mods" not inside the engine, but outside, using "original" .dll because I like it this way. And I don`t see any problem recompiling the enigne myself...
As for me- currently I`m creating a game for low-end hardware- about 1.14 processor, 512 ram, 128 video- my pc`s specs. Yeah, I can afford a better one, but this way I do my best for optimizations. Later on, if I decide to port it to some portable device- I`ll easily. If I want to develop it for some 2-core 1Gb video pc, I`ll create higher poly versions of the models, I`d already have high res textures- (most of them are created in 1024x1024), will put many shaders and I`ll be ready. Usually you start with the basic thing, not with the effects and grow up. You start with an original idea, interesting story if you like, good gameplay - Still, I believe graphics are important, but I keep on seeing many games, that will run like a comic book on my pc, if they even run, that only look nice on screenshots, but are not interesting at all for the player...
On the topic: I don`t see any problem with the default plane water scene node- If I need some, I`m sure I`ll be fully capable of creating one in no time, which will be exactly what I need. Plus, I`m 10 times less experienced than most of the users here.
About the shaders: Yeah, I`m for the next gen shaders and on, but assuming most of the gamers have high-end hardware is some quick guess. Still, Irrlicht is engine for 3d and 2d visualisation, not game engine. And I know some engineer collegues using it for visualisation of industrial, machine, or home heating installations, which applications they created in no time, using them in the early decisions, planning and calculations, and making their life easier while working on "real-life" project. What most of the people do is take irrlicht, take some physics engine, code some shaders and "viola!" they have a game engine. We have 12000 registered users and many that are not even registered, not seeing them posting every day, but they are working on their projects, and using Irrlicht for it`s qualities. Yeah, I liked the OGRE demos, but when I created one plane, one light, a skybox and two ninjas - having not more than 2500 trigs on 1680x1050 screen I got 75 fps in release mode. There are so many things OGRE runs in background, that my app cannot breathe. It has auto LOD for all nodes- I was really pleased of the automatically generated LOD for my two 1000 trigs ninjas... I needed LOD for some objects in my game, in fact I needed to switch between 3 different manually created LOD meshes- man, I did this working fine in 30 minutes. It may not be what most of you want, but it was what I needed and I "implemented" it in no time. And I create all my "mods" not inside the engine, but outside, using "original" .dll because I like it this way. And I don`t see any problem recompiling the enigne myself...
As for me- currently I`m creating a game for low-end hardware- about 1.14 processor, 512 ram, 128 video- my pc`s specs. Yeah, I can afford a better one, but this way I do my best for optimizations. Later on, if I decide to port it to some portable device- I`ll easily. If I want to develop it for some 2-core 1Gb video pc, I`ll create higher poly versions of the models, I`d already have high res textures- (most of them are created in 1024x1024), will put many shaders and I`ll be ready. Usually you start with the basic thing, not with the effects and grow up. You start with an original idea, interesting story if you like, good gameplay - Still, I believe graphics are important, but I keep on seeing many games, that will run like a comic book on my pc, if they even run, that only look nice on screenshots, but are not interesting at all for the player...
"Although we walk on the ground and step in the mud... our dreams and endeavors reach the immense skies..."
I still fail to see why D3D8 couldn't be deprecated and people developing for older systems couldn't use OpenGL. Besides, how old of systems are you talking about? DirectX 9 is nearly eight years old and is supported back to Windows 2000. There's really no point in it unless someone out there is still developing for Windows 9x for some reason.
Furthermore, I fail to see how updates to the feature list will compromise Irrlicht's goals of a simple API and support for low-end hardware. Some of the things I pointed out that OGRE has, like generic LOD, would actually help low-end systems a lot. Also, I fail to see how adding support for things like post-processing would jeopardize either goal. Those who are developing for lower-end systems can just not use advanced features like post-processing. It being in the library won't hurt them at all. I also fail to see how adding new features would complicate the API - I applaud Irrlicht on its simplicity and don't understand how adding more would change that.
And again, coming back to the "If you guys cared enough, you'd write it all yourselves" argument:
I see your point in saying that the community can contribute, but I think it's unfair for you to say that "if the community doesn't do it, then they must not care enough." We, like the Irrlicht developers and admins, have lives of our own. My main counterargument though is that as end-users, our priorities are, and should be, on the projects we're developing with Irrlicht, not Irrlicht itself. Just because we're requesting features doesn't mean we "don't care enough to do it ourselves" or that we're too incompetent to create our own implementations. The fact that we're using Irrlicht speaks to the fact that we like the engine. If we didn't care about its future this discussion wouldn't be happening.
Furthermore, I fail to see how updates to the feature list will compromise Irrlicht's goals of a simple API and support for low-end hardware. Some of the things I pointed out that OGRE has, like generic LOD, would actually help low-end systems a lot. Also, I fail to see how adding support for things like post-processing would jeopardize either goal. Those who are developing for lower-end systems can just not use advanced features like post-processing. It being in the library won't hurt them at all. I also fail to see how adding new features would complicate the API - I applaud Irrlicht on its simplicity and don't understand how adding more would change that.
And again, coming back to the "If you guys cared enough, you'd write it all yourselves" argument:
I see your point in saying that the community can contribute, but I think it's unfair for you to say that "if the community doesn't do it, then they must not care enough." We, like the Irrlicht developers and admins, have lives of our own. My main counterargument though is that as end-users, our priorities are, and should be, on the projects we're developing with Irrlicht, not Irrlicht itself. Just because we're requesting features doesn't mean we "don't care enough to do it ourselves" or that we're too incompetent to create our own implementations. The fact that we're using Irrlicht speaks to the fact that we like the engine. If we didn't care about its future this discussion wouldn't be happening.
I think D3D8 is not so much for Windows 98 (hasn't that d3d9 anyway?) but mostly because of the old XBox. And the thing is like Hybrid said - D3D8 hasn't been that much of a problem so far, so there just hasn't been a need for us to kick it out. If you look at the code you can see that it's 90% identical to d3d9 anyway.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Its not that that computers not supporting dx9. Its that Dx8 runs faster than Dx9.
I made a little game before, where i use Dx8 because in Dx9 it runned on 30-40 fps, on Dx8 it was 60-70.
Since I didn't need the technologies what Dx9 supported, why should i use the slower one?
And one thing.. Ppl saying that they need to rebuild the engine to support shader v 3.
1) rebuilding the engine is around...1-2 minutes? really that big problem? xD
2) why cant u uncomment the compile with dx8 by default, and put in the shader model 3? So if somebody want to use dx8, they have to recompile, and shader3 is built in automatically
btw im happy for the low-end supporting, coz im developing my game for laptops, etc.
If u suddenly start to go for nextgen pc's, i can't continue my project with this engine.
And using a outdated engine, is not the best, coz if i find a good code snippet in the forum, and then see its not compatible for my version.. that really sux
I made a little game before, where i use Dx8 because in Dx9 it runned on 30-40 fps, on Dx8 it was 60-70.
Since I didn't need the technologies what Dx9 supported, why should i use the slower one?
And one thing.. Ppl saying that they need to rebuild the engine to support shader v 3.
1) rebuilding the engine is around...1-2 minutes? really that big problem? xD
2) why cant u uncomment the compile with dx8 by default, and put in the shader model 3? So if somebody want to use dx8, they have to recompile, and shader3 is built in automatically
btw im happy for the low-end supporting, coz im developing my game for laptops, etc.
If u suddenly start to go for nextgen pc's, i can't continue my project with this engine.
And using a outdated engine, is not the best, coz if i find a good code snippet in the forum, and then see its not compatible for my version.. that really sux
D3D8 isn't my main concern. Like several have said, it takes mere minutes to recompile. See my other points above. I'm more concerned about why people think that adding "modern" features like generic LOD and post-processing will complicate the API or make it inaccessible to lower-end systems, but to prevent myself from being repetitive, just read my above post.
I dont agree with the 2 version splittin thing, i think it woul require too much time of the devs (who also have beter stuff to do). Also, the water scene node can stay as long as it does not hurt anyone(...hurt..how?). My point is that the engine itself is getting passed too easy. I'm afraid that in some near future it presents iself like genesis3d or crystal space(that is not THAT left behind...but its also quite dead imho).
Also, if the contribution and 'write it yourself' argument is so important...why most of the usefull patches and code snips are left behind and get outdated (without being taken serious)? Wiki is like....inexistent? [this was a critic for moderators and ppl who post code hat seem to not know the existance of the wiki]
Irrlicht lacks more of well polished samples and propaganda than beauty of code and ultlities, and that is what frigtens most of the newcommers....
Also, guys, realize that we are talking about this because we do care about the engine and we dont want to see it dies, and not because of 'competition' and "that one is better" cr@p...
Also, if the contribution and 'write it yourself' argument is so important...why most of the usefull patches and code snips are left behind and get outdated (without being taken serious)? Wiki is like....inexistent? [this was a critic for moderators and ppl who post code hat seem to not know the existance of the wiki]
Irrlicht lacks more of well polished samples and propaganda than beauty of code and ultlities, and that is what frigtens most of the newcommers....
Also, guys, realize that we are talking about this because we do care about the engine and we dont want to see it dies, and not because of 'competition' and "that one is better" cr@p...
I wouldn't remove any old nodes. Maybe just enhance them or make them more efficient.
I have a GLSL water shader applied to an Irrlicht animated water scene node, and it looks fantastic.
I realise I could use a vertex shader for the wave effect, but I want to have the waves work on older hardware without the shader, too.
I have a GLSL water shader applied to an Irrlicht animated water scene node, and it looks fantastic.
I realise I could use a vertex shader for the wave effect, but I want to have the waves work on older hardware without the shader, too.
Josiah Hartzell
I think, that all builtin scene nodes should stay backward compatible (so without shaders). I think also that we needn't 2 versions of Irrlicht for low and more powerful platforms. For modern platforms we need only new drivers eg. D3D11 etc, but this isn't job only for dev team, but for each from us 
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
-
hybrid
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
The problem is that just adding features will make the API bloated, used very different for each feature, require more API changes in each version, etc. Just saying that the API has to be simple to use is not enough. It's even much harder to make features simple to use than to write them. And that's where most of out time goes. And why many add-ons have a very long way until they make it into the engine.slavik262 wrote:Furthermore, I fail to see how updates to the feature list will compromise Irrlicht's goals of a simple API and support for low-end hardware. Some of the things I pointed out that OGRE has, like generic LOD, would actually help low-end systems a lot. Also, I fail to see how adding support for things like post-processing would jeopardize either goal. Those who are developing for lower-end systems can just not use advanced features like post-processing. It being in the library won't hurt them at all. I also fail to see how adding new features would complicate the API - I applaud Irrlicht on its simplicity and don't understand how adding more would change that.
O_o what da......? I beg your pardon but did you really mentioned that people who can not fullfill your standard of developement should just be quiet?hybrid wrote:[...]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.[...]
Dont get me wrong but I use a lib to ease the developement and not to implement some modern (and an increasing number mid) techniques by my own. Of course i can compile my own engine, patch it, teak it, extend it and make it an "ogrekiller".
By the way I use a tweaked version becourse the original irrlicht I used was to limited.
Do you really think that all users which is not able to meet your requierments is abled to implement these things by there own?
Do you really think that 'do it yourself' is the right way for a library which is known for its easiness?
I do not want to complain about all the work and time you are spending. I just hope that you keep the 'nice-looking-stuff-out-of-the-box' idea. Currently it seems more like an 'you-have-to-help-the-ugly-duckling-by-yourown'.
I bag your pardon if it was to insulting.
-
hybrid
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
No, I just said that people who cannot assess the amount of work, that a change or addition might need, should not insist on having some code to be added just because it's there.
Long version: As you might read in this thread or in several others, people complain about the long times that it takes from a first post of an add-on to the final inclusion into the engine. Things to mention here are XEffects, Cg, truetype, cube maps, ... What I said in the quoted text, as part of a very long text before and after this quote, is that there's more to it than just copying the code into the repository. Indeed, quite a lot of time has to be spent after the first version of a patch to make it running correctly in all situations, to make it easily usable, etc. I've told this already hundres of people in endless discussions. And if I mention the actual problems we have with a certain code, they just say that it's good enough for them and that I should therefore add it. After that, most of them usually leave the forum and are never seen again.
So my advice was basically meant to ask for a little more respect for our decisions. It's not that we are deaf, nor did we stop working. Also, these decisions are usually based on in-depth analysis of the code. We are not rejecting anything just for fun. So any constructive discussion, such as this one (actually even any non-destructive one) is usually taken up by the devs and actively participated in. However, this requires a certain rationale on both sides. And that's the only thing I asked for. I also didn't say that any of the posts in this thread was even near to this border. Just a plain wish to keep this discussion here effective. I guess everyone will sign to this.
Long version: As you might read in this thread or in several others, people complain about the long times that it takes from a first post of an add-on to the final inclusion into the engine. Things to mention here are XEffects, Cg, truetype, cube maps, ... What I said in the quoted text, as part of a very long text before and after this quote, is that there's more to it than just copying the code into the repository. Indeed, quite a lot of time has to be spent after the first version of a patch to make it running correctly in all situations, to make it easily usable, etc. I've told this already hundres of people in endless discussions. And if I mention the actual problems we have with a certain code, they just say that it's good enough for them and that I should therefore add it. After that, most of them usually leave the forum and are never seen again.
So my advice was basically meant to ask for a little more respect for our decisions. It's not that we are deaf, nor did we stop working. Also, these decisions are usually based on in-depth analysis of the code. We are not rejecting anything just for fun. So any constructive discussion, such as this one (actually even any non-destructive one) is usually taken up by the devs and actively participated in. However, this requires a certain rationale on both sides. And that's the only thing I asked for. I also didn't say that any of the posts in this thread was even near to this border. Just a plain wish to keep this discussion here effective. I guess everyone will sign to this.