Hey - i was just joking. I haven't heard of any plans that Niko is actually doing someting like that :-). Even thought it wouldn't surprise me.Eternl Knight wrote:irrNet, maybe. If Niko decides on developing his own irrPhysics, it will be the point of absolute absurdity.
IrrEdit and friends - Big Waste of Niko's and friends' time
I love Irrlicht and i don´t mind waiting for improvements. But i needed a proper water shader like this one: http://www.gametutorials.com/Articles/R ... cWater.htm. So i decided to try OGRE3D because i did not succeed with implementing collision detection into this example. With OGRE3D i get at least a kinda "water looking" shader, not nearly as good as in this example, but it also uses only half of the shader power (meaning double framerate). I think thats about it, really realistic water uses lots of power and even if your comp can cope, I don´t think its fun if it sucks on other peoples machines.
So i think its more a performance problem than anything else that Irrlicht still has no realistic water shader. Grr, i don´t like to learn another engine API, but what can i do as a "0.25"-programmer ? I am pretty glad that i came that far.
So i think its more a performance problem than anything else that Irrlicht still has no realistic water shader. Grr, i don´t like to learn another engine API, but what can i do as a "0.25"-programmer ? I am pretty glad that i came that far.
If anyone is interested, here is my point of view:
irrEdit is a tool currently needed by lots of people. According to the download statistics and email support requests, really, really a lot of people. So if I have some time (and currently I don't have that much of it), I'm trying to improve the tool until most people have what they need.
At the same time, also Irrlicht is being improved together with the tool, and in addition Hybrid, Bitplane and Thomas are giving their best to improve the rest of Irrlicht and are doing a great job, IMO.
You know, we are doing this for free and most of us also have jobs and a private life. So sometimes there are times which I would call release-holes. Periods where we don't have that much time and we are not doing a release for some months. If you take a look at the Irrlicht release history, we had those several times now, and always people come up with theories like 'has irrlicht development has stopped?' - 'I'm going to switch to $otherEngine$' - 'maybe the developer should invest more time into $somefeature' - and things like that. It's a bit annyoing somehow - but I've got used to it.
Believe me, the next release will come and we will have some new nice features in it - for sure. It's just a little bit unfair to say that we should invest more development time in the feature that you need currently instead of the feature some other people need.
irrEdit is a tool currently needed by lots of people. According to the download statistics and email support requests, really, really a lot of people. So if I have some time (and currently I don't have that much of it), I'm trying to improve the tool until most people have what they need.
At the same time, also Irrlicht is being improved together with the tool, and in addition Hybrid, Bitplane and Thomas are giving their best to improve the rest of Irrlicht and are doing a great job, IMO.
You know, we are doing this for free and most of us also have jobs and a private life. So sometimes there are times which I would call release-holes. Periods where we don't have that much time and we are not doing a release for some months. If you take a look at the Irrlicht release history, we had those several times now, and always people come up with theories like 'has irrlicht development has stopped?' - 'I'm going to switch to $otherEngine$' - 'maybe the developer should invest more time into $somefeature' - and things like that. It's a bit annyoing somehow - but I've got used to it.
Believe me, the next release will come and we will have some new nice features in it - for sure. It's just a little bit unfair to say that we should invest more development time in the feature that you need currently instead of the feature some other people need. Big project brings big onus, Niko... You have started Irrlicht...
I downloaded it too some time ago, because i only wanna only try it. People like fun programs and people download them because they are curious... Engine improvement and correction are more important by the time.download statistics
IMO not. Your team have skipped fundamental part of job and irrlicht became an engine for newbs only (pros don't wanna to correct (and add missing features ) your engine when there are many engines already ready for use... simple business rule )...addition Hybrid, Bitplane and Thomas are giving their best to improve the rest of Irrlicht and are doing a great job, IMO.
I guess we 're all interested to hear your opinion, after 4 pages of discussionIf anyone is interested, here is my point of view:
.I 'm just going to comment on the things I have something different to say.
Excuse my ignorance but how exactly is irrlicht improved?At the same time, also Irrlicht is being improved together with the tool, and in addition Hybrid, Bitplane and Thomas are giving their best to improve the rest of Irrlicht and are doing a great job, IMO.
Unless I 'm missing something obvious, all that's going on is bug-fixing. Not that something is wrong with that, but "bug-fixing" is not "improving"
.OK, I 'm not reading the rest of your message because I too have given this lecture more than once beforeYou know, we are doing this for free and most of us also have jobs and a private life.
.I 'm not disagreeing with you on this.
What I don't get is if someone hands you the code that adds a feature (or improves an existing one), why is it unfair exactly?It's just a little bit unfair to say that we should invest more development time in the feature that you need currently instead of the feature some other people need.
Dude, go on with Ogre and become happy with it.Valtras wrote:...and irrlicht became an engine for newbs only (pros don't wanna to correct (and add missing features ) your engine when there are many engines already ready for use... simple business rule )
Sure, there might be some features which are not in, but for my needs Irrlicht is the best choice. It's small, it's fast, there are no other dependencies. Of course, I'm far away from making a professional game, but I love Irrlicht and its not a
It fits my needs. I wonder what you're expecting? Why are you so harsh? Irrlicht is not so buggy as you write. Tell me some of these so important "bugs"!shitty engine without adoption in good looking games
I'm sure, there will be some semi-professional games in the future made with Irrlicht. Please tell me some professional games which are made with Ogre. Real professionals usually use their own engine or buy a "real" one, not such "playgrounds" like Irrlicht or Ogre.
Regards - Xaron
@Valtras, you're embarrassing yourself. Better shut up.
@niko, this is all well and understood. If you read this thread again, you will see that most people didn't attack any of what you defend in your post.
But what about the issues raised in this thread?
What direction is irrlicht leading? What are the planned milestones? I am not asking when they are planned and what exactly, but the general direction.
Is something planned about vertex formats and hardware buffers, in the foreseeable future? What about a proper animation system?
Can we help? Is there the possibility to contribute not in vain? How is it coordinated?
What about the svn-mailing-list proposal?
Please answer these questions too.
@niko, this is all well and understood. If you read this thread again, you will see that most people didn't attack any of what you defend in your post.
But what about the issues raised in this thread?
What direction is irrlicht leading? What are the planned milestones? I am not asking when they are planned and what exactly, but the general direction.
Is something planned about vertex formats and hardware buffers, in the foreseeable future? What about a proper animation system?
Can we help? Is there the possibility to contribute not in vain? How is it coordinated?
What about the svn-mailing-list proposal?
Please answer these questions too.
Look at ogre's main page.Please tell me some professional games which are made with Ogre
I don't like projects which are leaving correct way of development. Irrlicht was good, before IrrEdit, Klang and other unnecessary stuff...I wonder what you're expecting? Why are you so harsh?
some few professionals... In present times developers don't have time for designing and coding engine... Only big corporations make their own engines. Most of pros buy engine... most amateur teams without budget use good, free engine to start career...real professionals usually use their own engine
Do you not understand?! There is nothing planned! They're doing only that what they want...Is something planned about vertex formats and hardware buffers, in the foreseeable future? What about a proper animation system?
majority law... i think more people need basic improvments in irrlicht than irredits, klangs fangs, gangs...... feature some other people need.
-
hey_i_am_real
- Posts: 44
- Joined: Thu Sep 28, 2006 2:27 pm
- Location: Europe
When i decided to give a try to IrrLicht few weeks ago, i found lots of bugs with the OpenGL-driver ...Xaron wrote:Irrlicht is not so buggy as you write. Tell me some of these so important "bugs"!
I identified some of them and i made some patches proposal.
Hybrid immediatly updated SVN.
Now, the SVN OpenGL-driver is a little less bugged, but there are still lot of bugs in it :
- the fog does not work with shaders (i provided a patch proposal for it, and it's still waiting for some experienced advice)
- under Linux, if 32bpp color mode is not natively supported, the fullscreen does not work (the driver should automaticly switch to a compatible video mode, 24bpp or 16bpp)
- one of the bug Hybrid tried to fix created an other bug with particles (i think it's related to opengl states)
- some gray-map without an alpha channel are not converted to a normal-map with an alpha channel, and the parralax-shader does not work (i almost identified the bug, but i'm not yet experienced ennough to solve it, and Hybrid is busy now
)And i'm pretty sure i could find some more ...
I could fix them all myself as i did with the 4 first of them, but my modifications may become incompatible with further SVN and i'll be condamned to stick to my own version of the engine (like Spintz is doing) unless somebody dare to debug this Opengl-driver once for all.
That's few bugs ... few little bugs ... but they make Irrlicht not really reliable to use as a cross-platform engine.
Also, i don't even have tried to code anything with it yet, 'cause i've spent all my available time to identify bugs, to study the source-code and to try to fix them ..........
Well, yes, Irrlicht is free, Nikko and his friends are not our slaves and they did a lot of work for us, and that's great
But all of these littles bugs are ruining the engine, because they make it not reliable or suitable ...
And because the dev team isn't available 24/7, users who provide patches proposal wait several weeks before they see them included into the SVN. And what we get is a large waste of motivation/energy and interrest, and a giant collection of patches all scatered all around here or there with "R.I.P. ?" floating around ...
Maybe the solution would be to make a "Community version" of the engine. Every patches provided by some users are tested by some others users, and once it's done, it's included into the "SVN - Community version" of the engine.
And once the official dev-team are available, they update the official SVN of the project at will.
so, what do you think about that ???
I think your idea is good, but unreal. If engine will became community engine, all patches would be incompatible with others ( thousands of particles patches, driver patches... noone will know which patch works truely correctly ). Any project need a team that will have to look into pathes and choose the best ones (and integrate them into engine). Main team members should improve engine instead of correcting bugs... Every project need work organisation...
-
hey_i_am_real
- Posts: 44
- Joined: Thu Sep 28, 2006 2:27 pm
- Location: Europe
Well I was planning on avoiding this thread, but I eventually decided to perk up and say something..
On the original topic, I think irrEdit is anything but a waste of time. I probably won't use it myself for a few versions, but there are tons of benefits.. I could list them all but it'd be another 5 pages before I'd finished writing this post so I won't.
As for me avoiding important issues, that's usually when I'm trying to hide my ignorance! I'll try and do this less in future and admit when I haven't got a clue.. no promises though!
On the difference between "bugfixes" and "improvements" I think the bugfixes are more important. There's no excuse for not testing and integrating a nice easy bugfix, while a huge extra feature needs more time and testing.
As for direction, I think we can only get this from discussion.. so, discuss! Start a thread, post bugs, requests and patches to the tracker so they don't get buried in the forums
On the original topic, I think irrEdit is anything but a waste of time. I probably won't use it myself for a few versions, but there are tons of benefits.. I could list them all but it'd be another 5 pages before I'd finished writing this post so I won't.
As for me avoiding important issues, that's usually when I'm trying to hide my ignorance!
I'll try and do this less in future and admit when I haven't got a clue.. no promises though!On the difference between "bugfixes" and "improvements" I think the bugfixes are more important. There's no excuse for not testing and integrating a nice easy bugfix, while a huge extra feature needs more time and testing.
As for direction, I think we can only get this from discussion.. so, discuss! Start a thread, post bugs, requests and patches to the tracker so they don't get buried in the forums
Ok here goes:
Irrlicht is getter fatter and uglier by every release, all we get are boring bug fixes while core annoyances are ignored. the animation system for example is quite poor, it fails to interpolate between animation changes. the art loaders are excessive and useless.
"irrlicht would have look great back in 1995, but now its horrible, it uses outdates extensions to suppourt cards whose users would'nt be interested in running 3d apps anymore. Thus slow and oudated rendering technology. Now irrlicht is an ancient engine getting obese."
The fact that irrlicht was written from a totally (no offense) programmer`s prespective means that many simple artist friendly things are ignored.
-the fact that irrlicht cant have a node that loads sevral textures and still be bumpmapped or parallax mapped. eliminating dynamically lit levels.
what good is a bumpmapped sphere? most people want bumpmapped levels. Moreover animated objects cant be bumpmapped, this can be solved by passing the matrix of the bone transforming vertex being moved to the vertex shader and transforming the normals,tangents,etc.. accordingly or do what i did and abandon the idea of tangent space bumpmaps and use surface space bumpmaps since even the geforce 3 had enough power for that.
it seems like a lot of the feautres were added for the sake of adding them without thinking too much about their applications in games
(yes... irr isnt a game engine but why not make it good enough to render one)
for example we cant add materials on a sub node basis, a whole node carries just one material, im sure many old games had the ability to have a transparent window on a car with cube mapping while still being under one object and not creating a node for it.
some attempts have been made to compensate for this like MY3D but this should be a core irrlicht feature
This may be due to the huge number of formats which are called "interchange formats" beacuse they are intended to just transport vertex data between modelling apps rather than serious high descriptive files.
To bring the render ing quality up i had to:
-implement HDR
-On the fly parallax map genration with light map suppourt(this required invasie surgery into the sevral source files)
-dof
-softshadows(this required invasie surgery into the sevral source files)
Image 1 shows normal irrlicht while image 2 shows irrlicht after exposure to high amounts of anabolic steroids
not every one has the patience nor the will to learn to improve irrlicht like me and the other people who made patches
even irrlicht fails at being a modern 100% rendering engine oriented, it cant manage texture like, cubemaps,1d,3d textures,texture compression, special textures like lumininace,depth,greyscale and other stuff which save allot of texture memory
Final message:
Niko look at the changes you made in the irr engine to make it into the rabcat engine and then try implementing them in irrlicht
we cant even edit bones positions on the fly but look rabcat has it. why not implement it
another point irredit is useless, its too generic to be any good its only a node placer we still have to custom engineer it since each person has diffrent entities.
We migh as well use blender as and editor and make our own python scripts that convert stuff in blender into nodes ( i have been doing that to place waypoints etc...)
allot of time saved no customisation or comprimise needed
Irrlicht is getter fatter and uglier by every release, all we get are boring bug fixes while core annoyances are ignored. the animation system for example is quite poor, it fails to interpolate between animation changes. the art loaders are excessive and useless.
"irrlicht would have look great back in 1995, but now its horrible, it uses outdates extensions to suppourt cards whose users would'nt be interested in running 3d apps anymore. Thus slow and oudated rendering technology. Now irrlicht is an ancient engine getting obese."
The fact that irrlicht was written from a totally (no offense) programmer`s prespective means that many simple artist friendly things are ignored.
-the fact that irrlicht cant have a node that loads sevral textures and still be bumpmapped or parallax mapped. eliminating dynamically lit levels.
what good is a bumpmapped sphere? most people want bumpmapped levels. Moreover animated objects cant be bumpmapped, this can be solved by passing the matrix of the bone transforming vertex being moved to the vertex shader and transforming the normals,tangents,etc.. accordingly or do what i did and abandon the idea of tangent space bumpmaps and use surface space bumpmaps since even the geforce 3 had enough power for that.
it seems like a lot of the feautres were added for the sake of adding them without thinking too much about their applications in games
(yes... irr isnt a game engine but why not make it good enough to render one)
for example we cant add materials on a sub node basis, a whole node carries just one material, im sure many old games had the ability to have a transparent window on a car with cube mapping while still being under one object and not creating a node for it.
some attempts have been made to compensate for this like MY3D but this should be a core irrlicht feature
This may be due to the huge number of formats which are called "interchange formats" beacuse they are intended to just transport vertex data between modelling apps rather than serious high descriptive files.
To bring the render ing quality up i had to:
-implement HDR
-On the fly parallax map genration with light map suppourt(this required invasie surgery into the sevral source files)
-dof
-softshadows(this required invasie surgery into the sevral source files)
Image 1 shows normal irrlicht while image 2 shows irrlicht after exposure to high amounts of anabolic steroids
not every one has the patience nor the will to learn to improve irrlicht like me and the other people who made patches
even irrlicht fails at being a modern 100% rendering engine oriented, it cant manage texture like, cubemaps,1d,3d textures,texture compression, special textures like lumininace,depth,greyscale and other stuff which save allot of texture memory
Final message:
Niko look at the changes you made in the irr engine to make it into the rabcat engine and then try implementing them in irrlicht
we cant even edit bones positions on the fly but look rabcat has it. why not implement it
another point irredit is useless, its too generic to be any good its only a node placer we still have to custom engineer it since each person has diffrent entities.
We migh as well use blender as and editor and make our own python scripts that convert stuff in blender into nodes ( i have been doing that to place waypoints etc...)
allot of time saved no customisation or comprimise needed