Irrlicht Engine

Darktib wrote:Make is cool, it can also brew coffee. However, if I want to use visual studio then makefile are not really good - as I want to control the build step from the IDE, not from a file. That's why solutions like cmake or premake are better

well no cmake prevent you from doing that cmake will overwrite your custom setting everytime you attempt to build with visual studio

Premake!!!!!

Moving to git/github would be great, I find it a lot more clear, (github) enables better communication and discussion of code, merging seems easier (that impression may come from me having more experience with git), branching is way easier. The only thing it doesn't handle well is binary files (which irrlicht needs for examples).
I would be interested in some reasons others might have against moving to git, but that would belong in a different thread.

Yeah, we should switch to git (or hg - I'm fine with either). I hope we can do so as soon as 1.9 is out. Small binaries are not much of a problem usually and they don't change often.

I would welcome a switch to git. It is much better for multiple people to work on the code and merge their stuff. git hosts like github make it easy to issue pull requests. And switching from subversion is not hard. You can "import" an SVN repository with git-svn so that it becomes a git repo, then push it on your git server. It's really simple

When hybrid's gone the cats jump on the table That'd be some return surprise for him, "oh btw we git now".

TBH I prefer svn I learned SVN on my own mainly because irrlicht use it and this session took a class about agile programming and we got git imposed.

In about 1 month git successfully ranked itself near CMAKE in my hate list

thats only because FrotEnds for Git are soo poop and incomplete (especially graphical ones)

as a backend Git is quite superior to SVN (branching and merging is a lot better)
plus I think one could give everyone access/permissions to branch but not to touch/merge main branch which would make patch tracking a lot better

If half of the battle between Git and SVN is usability, then the front end is part of that. I've never worked with Git, so I can't say anything about it's front ends. Anyone have a good one?


my .02 on the change discussion:
1) We can remove/archive the first software renderer. No one uses it that I know of. Don't ditch the SoftwareRenderer2 (Burnings) - I use it, mostly for learning, but also, it does work in places where OpenGL won't and where I don't want to use plain old dx8 for varying reasons.

2) Keep the containers. It sounds odd, but the containers can be extended and modified without building whole new classes etc. just for things like string modification. Personally, I like having the function implementations all in front of me rather than trying to figure out the STL.
Though while we're on the topic,there are some things that could be cleaned up I guess. e.g. lines 47-52 and 60-65 of irrString.h seem completely pointless.

3) What's wrong with the fixed-function pipeline? I'm not an expert on this, so you guys will have to tell me what the issue is here (other than "it's slow"). Seems to me it's easy enough to read and figure out where to insert things. What's the alternative? (link?)

chronologicaldot wrote:2) Keep the containers. It sounds odd, but the containers can be extended and modified without building whole new classes etc. just for things like string modification. Personally, I like having the function implementations all in front of me rather than trying to figure out the STL.
Though while we're on the topic,there are some things that could be cleaned up I guess. e.g. lines 47-52 and 60-65 of irrString.h seem completely pointless.

The STL containers are far more advanced than the irrlicht ones and can perform complex optimizations which are really hard or even impossible to adopt. For beginners the stl often seems too difficult but if you get used to it you can write more efficient, less error prone and better readable code in less time.
Another aspect is that the stl containers are more compatible. I often wrote code first with a can-do-everything-Type and laster replaced it with a more efficient one, for example first used std::map and later replaced it with std::unordered_map (hashtable) or the cache efficient boost::container::flat_map without having to rewrite my code.

The fixed function pipeline is like the grandpa... everybody loves him, but the sad fact is that some day he will abandon us.

Currently, the modern graphics card just emulate the whole fixed pipeline within their bowels through the programmable pipeline, and that's mainly the reason to drop the fixed pipeline. How many old graphics cards are around these days that aren't able to support the programmable pipeline?

The point is: what approach to use for the new irrlicht 2.0? It could just provide a complete deferred rendering/lighting support, with all the features available (hardware/shader skinning, instancing...) and have it like that, but that could enter the realm of the programmer's work. Then, the other way is "DIY" and leave the engine as simple as possible, as it is right now, where everything is codeable from the begining to the end, something i like, but that to some extent is slow for software development.

Isn't it possible to have a mix of both approaches? for example, provide the hardware skinning support, the instancing, and a basic pipeline, while it was possible to override any part of it to have finer control, for instance. But that just sounds so "ogrish" XD

In fact, Irrlicht 2.0 could be merely a cleanup of Irrlicht as it is right now, with the latest GL/DX11-12 support, and some missing features (cubemaps...) that Irrlicht should long have within, as Irrlicht in fact, has been always an API to "hide" the rendering API below more than an engine on its own. But then again, C++ accepted within the STL because it was used on every program (and they are far more optimized it seems than the irr ones...), thus Irrlicht could accept within some commonly used routines, like the shadowmap generation and projection, any type of dynamic scene culling, streamed assets loading or a postproduction pipeline, so any Irrlicht user could just grab the engine, load graphics, and put them into motion on its own and have great graphics in a moment.

If there was also an integration with any physics lib around, it would be just great besides. I know there is people who think this doesn't belong to the realm of the engine, but the same we have joystick support, it could be integrated, as another compile setting, and i think it would ease a big deal the integration with any other physics simulation system

Hi, Mel! Great comments! I would really like that too!

Only a comment about physics:

As with the (simple) collision detection build into irrlicht (which IS a "not unimportant" feature - in forums of other engines sometimes users complain, that they have to fire up a physics engine just to achieve this), we could integrate a also "simple" physics engine, like e.g. the "Irrlicht Dedicated Physics Engine". It's not Bullet, but it would be "integrated", meaning: it just works, with every compiler and on every system irrlicht runs on (i don't like any more to collect external libraries and try to compile and link different versions until i find one that works - until the next changes).

If it's maintained by the community or even the original author it can evolve into something valuable (we will never catch up with a beast like Bullet, but that's also true for other components: need more that the build in GUI can provide? - take another one; need more joystick axes - use SDL, and so on and so on until you swap out the whole engine and take another one or write your own).

The problem is the same as with everything else. Whatever you do that escapes a bit from the hiding the API behind philosophy is really outside the scope of Irrlicht. Perhaps, the point would be to create also an interface common for the physics simulations and work from that point. But that's just a suggestion. And Irrlicht's collisions aren't that bad either, maybe they aren't as efficient as one would like, but unless you need perfectly simulated animations, which is what physics do, with a few calculations, you can get not the perfect thing but something close enough to be useful. Obviously you don't have convex body animations for free, but for simpler stuff, it is more than enough in many cases.

Another suggestion for IRR2.0 something it could have also is an authoring tool, just like Unity or Unreal Engine so the usage of the engine was as quick as possible.

Another suggestion for IRR2.0 something it could have also is an authoring tool, just like Unity or Unreal Engine so the usage of the engine was as quick as possible.

You mean like IRRedit, but open sourced? Currently there is only 2 active developers on Irrlicht, this could be perhaps better started off by the community and put in irrEXT.

If such thing would exist, I would really like it to only use Irrlicht ressources (all of the engine + gui) because it would be easier to port to other platforms (irrEdit only use windows GUI and would need to be rewritten to work on Linux, Mac), and be able to not only place assets but create something like Unreal (block tool to create walls + floor).

Irrlicht 2.0+ would need better support for assets as it's having now. By that I mean that it would need a way to stream assets instead of "locking" the application while it load, ability to have at least one saver that save will most of the features (right now b3d is the most supported format for animated models, if we could have a saver that save all that).

Better control over animations would be really important, as to at least define animation "names" with the frame range, set separate animations on limbs (legs are walking, arms are aiming), append, or apply animation from a skeleton on ANY instance. But I don't expect this for 2.0 (perhaps later), as the devs are trying already to do some much stuff on the rendering side, platforms (iphone, android support, directx, fvf, etc) and cleaning stuff up, asking this for 2.0 would require more developers.