Adler1337 wrote:Most of your problems are because of your lack of c++/3d experience
I never said that I lack C++/3d experience. I learned openGL before learning to use Irrlicht, in fact. Also, "C++ experience" <> programming experience. Irrlicht shouldn't be made more difficult because the tutorials and API often have technical jargon (not just C++ jargon) that isn't clear to everyone else, like, as I mentioned, "EMF_COLOR_MASK". Irrlicht tutorials and naming should not have non-descriptive jargon that is only perhaps used in a few, perhaps elite, 3D programming circles. These are not major changes that I would have liked, but simply the accumulation of small naming differences can have a big effect on the overall ease of use.
Radikalizm:
Which inheritance do you find unnecessary? Using inheritance to reduce having to repeat code and to orderly structure objects with similar properties is one of the cornerstones of an OO design, and I personally haven't found any overuse of this principle in irrlicht, although it's completely possible that I missed something
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.
It's just the entirety of the thing. It's kind of difficult to think about the problems (from an outsider's, or beginning IRRLICHT user's perspective!) now that I know more about how Irrlicht works, which I imagine is a big problem for the devs since they are intimate with it.
A redone website could be good, but just removing the old tutorials would be a decent patch.
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.
In terms of the FPS nature of it: yes, it's mostly about the examples and the lack of non-FPS-type camera options.
My game does now have a global lighting source (a "sun"), but getting the settings correct were basically trial and error. One problem I found was that (I think this may have been already corrected?) directX and openGL had massively different (incompatible) light ranges with one specific setup.
It's just a simple lighting scheme, but it's fine for my purposes. Any bouncing lighting rays (maybe what you guys are talking about?) are way beyond my graphics card anyway.
-----
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.
)