what is missing from irrlicht?

[devsh]

back onto the topic of shadowmapping, during the implementation of PSSM I have found myself solving a quartic equation in order to find the perfect split positions

[Kalango]

@DeVSH: Sometimes its no good you saying what you did if ppl dont see it or if we cant use it...

[CuteAlien]

A lot of the inheritance in Irrlicht seems to be based on perceived efficiency gains. I'll give you an example: static and dynamic meshes and static and dynamic nodes. There's almost no difference between them; the difference does not need inheritance. A flag would work just as well.

There are situations where you are correct, although I personally just know about "modal" states in the gui where I'd like to have it changed from inheritance to a flag one day. But if you find such cases than the reason is more likely historical and not because of efficiency gains (kickout out existing classes is harder than writing them in the first place...).

A redone website could be good, but just removing the old tutorials would be a decent patch.

Work on that is happening.

Edit: I remember an early problem I had. There was no efficient triangle-based way to find what objects are hit that I could find. (that is in the Irrlicht engine itself-- I guess there's a physics engine or two I could use, but it's just more complexity)

It's all based on bounding boxes... This may work well in a game which has stuff that look like boxes, but requires a custom solution for anything else. I remember that there was (I think) a "triangle selector" method but I have not done anything with that yet and I couldn't find any decent explanation for it yet.

My current solution is to use bounding boxes for 3D objects and simply iterate through triangles (via a simple point-triangle intersection routine) for the flat 2D parts.

You should really look again into triangle selectors. There is a collision example (07) and you can also ask in forum when you have troubles with them.

[devsh]

@Kalango: I was just making a point that the features we may want are actually a pain in the ass to implement with bleeding edge efficiency

[hybrid]

Most of your problems are because of your lack of c++/3d experience

I never said that I lack C++/3d experience.
[...]
A lot of the inheritance in Irrlicht seems to be based on perceived efficiency gains. I'll give you an example: static and dynamic meshes and static and dynamic nodes. There's almost no difference between them; the difference does not need inheritance. A flag would work just as well.
[...]
The documentation is somewhat schizophrenic. I have had a number of problems that were only solved by asking on the forums (instead of them being obvious) For instance, the light mapping. I had no idea that you had to reset the normals (er, I forgot the exact command/name of it) after you rescale an object. For efficiency reasons, it makes total sense, but this kind of information is simply not plainly displayed. A lot of such problems are seemingly caused by Irrlicht efficiency practices which are not apparent until you get burned by them.

Sorry to say, but you seem to lack most of the OO things. OpenGL is not C++ at all, btw. But of course, many of the design choices are arguable and there are many other ways to do it. Our way worked so far, even though some decisions make changes harder sometimes. But that's true for all other alternatives as well.
For the separation fo dynamic meshes: It just does not make sense to be able to call setFrameLoop on static meshes. Moreover, having this properly separated hierarchy makes it often easier to extend the engine. It's not necessarily a choice which has to have effects immediately. We need it, though, for future purposes.
Things like rescale normals are explained in the tutorials. You make a joke of yourself. Think about it. This lazyness is hilarious.

[pippy3]

irrLight lacks one, but very trivial asset: a company supporting it.

If there was a studio submitting patches, writing test cases, reading papers and implementing the code, irrLicht would easily be a top notch engine. But even indie studios make the ridiculous choice of writing their own engine. The means they lose out in terms of quality, and irrLicht loses out in terms of patches and credibility.

It would be fantastic if the irrLicht community could have a drive to get some indie studios supporting the engine.

[Adler1337]

If a company supported it then it would no longer be free. Half of what makes irrlicht great is the fact that it is free.

[agamemnus]

OpenGL is not C++ at all, btw.

I didn't say it was. When I was using basic OpenGL, I wasn't using C++ for it.

Things like rescale normals are explained in the tutorials. You make a joke of yourself. Think about it. This lazyness is hilarious.

I'm kind of offended... I don't want to have to read some tutorial to get a simple thing like shading/lighting working "out of the box" (with the Freebasic wrapper). Light normalization after scaling a node should be in the documentation... (edit) in a more obvious place than in some tutorial.

I'm not the only person with hilarious laziness, anyway. The maker of the Freebasic wrapper didn't know that you had to normalize objects after scaling them in order to get the correct lighting, either.

I don't have many solutions here, but again.. something may seem obvious to you, but that something isn't necessarily obvious to people who have never used Irrlicht (or a 3D engine, for that matter) before.

[Lonesome Ducky]

Ah yes "some tutorial." Why would they put in a place as counter-intuitive as the examples that help you learn how to use the engine? That's just crazy. You obviously plan on making a project out of this, and you should have at least glanced over the tutorials to actually learn how to use it. A lot of the questions and comments you make are easily answered by said tutorials.

[agamemnus]

Ah yes "some tutorial." Why would they put in a place as counter-intuitive as the examples that help you learn how to use the engine? That's just crazy. You obviously plan on making a project out of this, and you should have at least glanced over the tutorials to actually learn how to use it. A lot of the questions and comments you make are easily answered by said tutorials.

I didn't actually use the Irrlicht tutorials for that; I used the API and Freebasic examples of the individual parts of the engine. I guess I just don't agree that tutorials are meant to show how something works as opposed to give an example of a bunch of parts. (Edit) In other words, I don't agree that the tutorials should be used to, for example, tell me that I need to "normalize" a node after scaling it in order for things to map correctly. That should be self-contained in the comments for the API, or preferably in a manual.

(Kind of rambling on here a little now)

When I need to remember how a part or command works, I don't want to have to remember what tutorial it's covered in. I just want to type in that command name and see exactly how it works, preferably with an example. This is the style that the Freebasic manual and php.net use.

[fmx]

I guess I just don't agree that tutorials are meant to show how something works as opposed to give an example of a bunch of parts. (Edit) In other words, I don't agree that the tutorials should be used to, for example, tell me that I need to "normalize" a node after scaling it in order for things to map correctly. That should be self-contained in the comments for the API, or preferably in a manual.

No offense, but most people would react to that kind of opinion with:
"Tough, that's your problem, deal with it".

However it might be more productive if you could try writing a Tutorial yourself to demonstrate what you would like to see.
At the very least, it would help out other beginners who might share your view on what a Tutorial is supposed to be about

Remember: we're all part of the irrlicht community here
we all have the option to help it grow (by contributing in whatever way we can) or leaving it to rot (like most other free engines).

[Radikalizm]

@agamemnus
I'm sorry, but I really can't agree with you on this, it's the very essence of the tutorials to explain the steps you have to take to get a certain task done
API documentation is supposed to give you an explanation of how certain classes or functions work themselves and what they're used for, not to tell you which steps you may have to take after you've used that particular class or function, which could essentially be an infinite amount of different steps since not everyone wants to achieve the same goal as you

And seeing your comments about the freebasic wrapper, I again strongly advise you to consider switching to C++, this not only will give you a more powerful language to work with, but it will probably give you a better understanding of actual OO principles and why certain architecture decisions were made in the irrlicht engine

[agamemnus]

And seeing your comments about the freebasic wrapper, I again strongly advise you to consider switching to C++, this not only will give you a more powerful language to work with, but it will probably give you a better understanding of actual OO principles and why certain architecture decisions were made in the irrlicht engine

... no, thank you. I disagree on all points, and even if I agreed I would not be willing to convert about 18,000 lines of code to C++.

No offense, but most people would react to that kind of opinion with:
"Tough, that's your problem, deal with it".

I posted here to give my opinion and thoughts, not to be told what programming languages or programming paradigms to use.

I probably should have just shut up and run for the hills several days ago -- it's not pleasant to post your thoughts and then see the thread turn into a bashing of not just your opinion but of you personally, and it looks like this thread is going there. If you are correct that most people would react this way, then such an environment would encourage groupthink and not be conducive for constructive discussion, and this in turn would shrink instead of grow the community.

However it might be more productive if you could try writing a Tutorial yourself to demonstrate what you would like to see.
At the very least, it would help out other beginners who might share your view on what a Tutorial is supposed to be about.

Remember: we're all part of the irrlicht community here
we all have the option to help it grow (by contributing in whatever way we can) or leaving it to rot (like most other free engines).

I don't agree with the tutorial-writing approach. I would be more interested in helping set up a manual type thing, perhaps help out with the stalled wiki. I'm not at the level of knowledge with the engine where I can contribute to that significantly, though. I could try, I suppose.

I am contributing in other ways that I can for now; I've posted a few suggestions in this forum and replied to a few posts in the Beginner's forum.

[Lonesome Ducky]

It's not bashing, it's telling you to read and use the tutorials. Seeing as irrlicht isn't well known and completely free and opensource, a manual is likely never coming. The wiki is pretty much dead for all intents and purposes, and it would take a lot to revive it. Also, I haven't seen any bashing of you personally, so don't be over-dramatic.

[ChaiRuiPeng]

I think it would best to act maturely. In thread that our good members we try to give you well path for achieving what you want to achieve. We can not help if you take advice personally.