IrrEdit and friends - Big Waste of Niko's and friends' time

hybrid · Post by **hybrid** » Sun Oct 22, 2006 10:56 pm

Yeah, I'm back

I hope my recreation will survive this thread

Eternl Knight · Post by **Eternl Knight** » Mon Oct 23, 2006 5:11 am

I don't think anyone is expecting the 24x7 support and so on that you guys seem to be getting from the thread. If they are, bollocks to them!

The issue I think some of the "older" folks (and by that I mean, those that have been involved with Irrlicht more than a month or so) is that the only patches we tend to be seeing added to the "official branch" are bug fixes.

Yes, these are important. Very important. But so are many of the other patches being created. Unless I am mistaken (and I sincerely apologise if I am), we are still limited to 16 bit indexes!

--EK

omaremad · Post by **omaremad** » Mon Oct 23, 2006 10:26 am

Excellent summary EK i couldnt have aid it better

The issue I think some of the "older" folks (and by that I mean, those that have been involved with Irrlicht more than a month or so) is that the only patches we tend to be seeing added to the "official branch" are bug fixes.

I have devloped a conspiracy theory about irrlichts devlopment status, but i think i btter not reveal it till i have more evidence.

Btw my posts were very harsh but i made it so to show that:
1-We must not kid ourselves irrlicht isnt the best 3d open source api out there
2-Even the older users even though they adapt they still get annoyed by irrlicht's flaws

If any one wants to compare irrlicht and ogre with an analogy here is one lol(im not good with analogies buts its a good summary decsribing the diffrences between irrrlicht and ogre)

Irrlciht is like petrol; fast ignition but burns out quickly
(good for begginers but you need to keep adding "fuel" to keep devlopment on bigger projects going)

ogre is like diesel:slow ignition but burns for longer
(harder for begginers to start making things using it but the "fuel" or exsisting code lasts longer both for not becoming out of date and the fact that it need very little adjustments for big projects)

omaremad · Post by **omaremad** » Mon Oct 23, 2006 10:31 am

Btw i agree with bitplane on the fact game dev should be fun, it should be fun for the coders but also more importantly the users. Ground breaking "eye candy" cant make a game fun it only turns it into a movie which is the oppsoite of gaming.

This might be ironic coming from some one who likes shaders so much, but im not particulary creative when it comes to game ideas and my idea of fun is to learn new concepts; im merely making them for my own entertainment rather than aiming for the games to be fun to others since that is an art few can master.

hybrid · Post by **hybrid** » Mon Oct 23, 2006 1:30 pm

There are several new things which were added since 1.0 release: Screenshot and image writers, non-power-of-two textures, antialiased fonts, skydome, b3d support, sphere node, binary .x, scene serialization, 4 textures per material, factories, .mesh support, allocators (just a quick brwose through the changes file).
And removing bugs is also quite important

Moreover, many patches that I am hosting need some more work to correctly fit into the current architecture. Some of the mesh importers that were planned for 1.1 had problems with the allocator addition (in fact they had mem leaks or bugs mostly) and have to be fixed before integration. Just as compressed textures (which are not compatible with the changes to the textures handling anymore). And I did not find enough time to change my spotlights implementation to separate files and interfaces, yet.
The 32bit patch availabe is not working anymore. Moreover, just changing to 32bit is not really pleasant in terms of memory consumption. The IIndexBuffer interface from IrrSpintz would have been a candidate but I wanted to invest some more time to check if some more changes would give some benefits and thus avoid more changes to this interface later on. Finally, most gfx cards prefer 16bit indices (or at least face groups with a size that fits into 16bit) to get better render performance. There is a trade off between fewer gfx library calls and the availability of vertices to be rendered by the parallel pipelines: If you make a huge mesh buffer and put that one into one batch call you can save cycles there, but the hardware stalls until all vertices are available. So it is usually much better to change the loading and generating routines to split buffers into parts instead of using 32bit buffers (which will come at some point).

sio2 · Post by **sio2** » Mon Oct 23, 2006 1:37 pm

omaremad wrote: I have devloped a conspiracy theory about irrlichts devlopment status, but i think i btter not reveal it till i have more evidence.

Come on - spill the beans. You know you can't allude to conspiratorial evidence and not back it up.

Analogy: Irrlicht is like that high-performance sports car that you buy and think is great until you find it has no reverse gear. Err...that's just a joke, by the way.

sio2 · Post by **sio2** » Mon Oct 23, 2006 1:49 pm

A lack of animation interpolation is a big issue, IMHO. Anyone else agree?

BTW I agree with a lot of what Valtras has said though perhaps I may have put things more diplomatically.

Halan · Post by **Halan** » Tue Oct 24, 2006 8:55 pm

there is no power-of-two textures support? wow. thank you

hybrid · Post by **hybrid** » Tue Oct 24, 2006 9:29 pm

Yes, there is. But only hardware accelerated support. Thus, if you have your app running on a card not supporting the extension you have to recognize this yourself and provide different textures. Otherwise, the known artifacts are visible. This support is therefore not really useful, yet.

Halan · Post by **Halan** » Tue Oct 24, 2006 9:43 pm

oh :/ what hardware is supporting it?

btw: sorry for getting off-topic but ive also an on topic statment

imo i think irrEdit isnt really useful cause im too builidng my own editor. i would find it good if i oculd use the code to modify the editor for my own needs. Well i lovve irrKlang and would also like it to be implented more directly in irrlicht (so there could be like 2 versions of irrlicht, with and without irr klang) so you can easily attach sounds as a child of a node to get the 3d effect

greets,
halan

edit: will there somwhen be a software support like splitting the texture into several textures?

hybrid · Post by **hybrid** » Tue Oct 24, 2006 9:47 pm

Just ask the card capabilities / OpenGL extensions to see if it is supported. There are probably also card series from which on it is supported.
IrrKlang can easily be integrated into Irrlicht using custom scene nodes. There are some implementations for OpenAL available. Should be easily replacable. Maybe Niko or someone else adds one to Irrlicht contributions code.

fakin · Post by **fakin** » Wed Feb 21, 2007 1:27 am

Valtras wrote: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...

well, you can add more than light0-light7 to the scene if you batch render parts of your 3D environment... that trick will do.

SiriusCG · Post by **SiriusCG** » Wed Feb 21, 2007 2:00 am

What is really ludicous here is that *no one* has pushed the current Irrlicht implementation to anywhere near it's limits... and they're wailing about "we need this and we need that"... what nonsense....

I'm switching to Ogre. Irr's future as good game renderigng engine is very uncertain.

I'm reading the pablum that these "serious" game designers are spewing and all I can do is laugh... The "place the blame on the engine" is as old an excuse as it gets...

Irrlicht is a very good engine and the only uncertainty I can see is whether or not these "wanna be" game devs actually can produce something more than a tetris clone...

buhatkj · Post by **buhatkj** » Wed Feb 21, 2007 5:17 am

I'd have to agree about the "OMG I NEED XXX feature" thing, though i am probably just as guilty as anyone of lusting after new features, I just have a different method about it

My projects are all pure hobbies, so there's no rush. for the most part im not even trying to make anything in particular, just play with stuff and learn things. so if i run into a limit, I either try and fix it, or just say "well, im sure if i wait a while, the irrlicht devs will figure this out for me."
and know what, they usually do. given some time. irrklang made openAL obsolete for me (I had made a nice OpenAL wrapper and nodes some time ago), I liked the neatness of the audiere API, but i wanted 3d. IrrKlang is the best of both.
I started to build an XML based editor of my own, then Niko made IrrEdit...almost obsoletes the need for it, if only the userdata bit would get done, but like i said, ill just be patient, then all will be well.
I don't care whether you bought the source engine or what, you WILL have to do some customization to do a complex game, no engine is so generic as to need nothing added to make it perfect for your particular game...its always gonna take some work.

so the bottom line is this, dont bitch. either fix it yourself, or be patient. if you wanna make a feature request, keep in mind its nice to be polite, and above all, patient.
after all, you're getting this for free!!

if you have a particular hard-on for knowing what's on the block as far as irrlicht dev, check out the SVN commit comments, gives a little insight...

kburkhart84 · Post by **kburkhart84** » Wed Feb 21, 2007 6:33 am

I didn't want to post here, but after reading siz pages of mostly CRAP, I have to. I too have looked at the Ogre3d engine. I haven't taken the time to try to properly use it due to the amount of time that would take me. I registered on their forum and confirmed that Ogre could indeed render animated meshes with normal mapped material. The posters their were "surprised" that irrlicht had such a limitation. I then returned here to Irrlicht and posted the New feature request post, that mentioned the same animated mesh material issue. It isn't ready yet that I know of, but since the feature is coming soon, which was about the only reason for me to look at another engine(besides cruddy animation system), I'm going to stick to Irrlicht. I went to Ogre forum and politely thanked the posters, mentioned that Irrlicht was going to get what I wanted, so I was going to stick with it, and thanked the programmers for their Ogre3d engine, (since like Irrlicht, it is a hobby project and free to public). I haven't posted over their since. Why....because Ogre3d no longer interests me. Hey Valtras, if you are going to switch to Ogre3d, feel free to do it. Not to be rude, but no one will miss your "switching engine" threats. If Irrlicht is no longer of interest to you, why continue posting here. That's why I haven't posted at Ogre3d anymore.( Though it also is a fine engine)

Now, I do wish Irrlicht was updated more often and more features were added, but I'm patient. As has been said, it is free, open-source with the least restrictive license I have ever seen. I can't complain at all. Thanks Niko, Bitplane, Hybrid, Thomas for your help on the engine, and thanks all who submit add-ons/bug-fixes/etc... to the engine since I'm not good enough to program them in myself, I DO appreciate it.