Irrlicht Engine

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

I'm not asking for advice. I do take it personally when I don't ask for advice and I am given advice.

agamemnus wrote:

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

I'm not asking for advice. I do take it personally when I don't ask for advice and I am given advice.

My advice: get used to it.

I'm not asking for advice. I do take it personally when I don't ask for advice and I am given advice.

16 years of programming, yet you are acting like a child Something doesn't add up. This topic was for discussing improvements to future versions of irrlicht. You gave a suggestion and we discussed it. Nobody was insulting you.

I'm just going to say, agamemnus has a point, while the normals thing might be a bad example if it is covered in the tutorials, there are plenty of odd gotchas that are not.

We can all dream of perfect documentation In an ideal world, the docs would tell a complete newbie everything they need to know. It is impossible to achieve, but don't shoot down people just for dreaming the dream. This is just an opinion thread after all.

Yes, but documentation is not necessarily restricted to just the API docs. And if things are explained in tutorials or examples, it's just as good in many situations. It's not correct to criticize the quality of the documentation because of soem thing not being explained at all places all over. And even less if it's just because of laziness of some person. Moreover, the tutorials are part of the API docs since Irrlicht 1.5 or so, and of course you have to read the full API docs if that's the only thing you want to work with.
To make this point clear: We do support any enhancement of the documentation of Irrlicht. Every part of it. And we try to improve the API docs in each release. We also support and write new tutorials and do our best to make the engine very easy to work with. Just post (constructive) updates and suggestions here on the forum or on our feature tracker. Or just write new tutorials and submit those.

what about adding more materiall methods to the irrlicht engine?

1) enable some methods for change a parameter of the material instead of loading a new material:

ex: instead of loading a new material giving the chance to change only 1 texture and prevent lots of others stuff to beign changed (if hundred of materials are used there will be a significant performance increase)

driver->setTexture(u16 layer,ITexture* texture).

2)enable ignoring materials. (a material that override all existing materials)

ex: i want to render a scene for a deffered shadow tecnquique.. The only thing i need is a depth map. so all things like multitexturing, texturing, lighiting tecniques are not really needed.

So first i render the whole scene with a unique material (I.E. emt_solid) from the point of view of the light source
then i render my real scene and apply shadows (as I seen in a thread in code snippets).

This has some advantages:
1) not time needed for changin materials when rendering the 1st depth map
2) shaders not computed and more time saved for rendering again, but now the extra computing is removed from gpu instead of cpu.

Like now for preventing extra computation time i keep separed a pointer to each meshbuffer and then I iterate all meshbuffers keeping only 1 material instead of changin it again and again.

It is a simple solution and maybe can be implemented in irrlicht natively.

I'm not reall yusre what you mean by 1). A way to change all textures at once? Or to render the next mesh with only a texture changed? The former seems quite useless, the latter is already happening in Irrlicht (because we avoid render state changes which are not needed).
for 2) we have the override maaterial. It does not work for material type, yet. But you can disable the color buffer rendering and thus improve the render speed when only rendering to depth buffer.

(sorry for english i wrote it very fast)
1) yeah i mean change only 1 texture (or any other parameter, this will skip any check.) but maybe the performane gain is not so much

2) I know about override material, and I always render only to depth buffer for casting shadows, but seems that the "driver->setMaterial()" of each scene node is called anyway.


A) keep a list of all the meshes(after having applied the culling rendered nodes are 40-100)
B) set up the material
C) render to depth buffer all meshes without changing material.

I use the 2nd scene manager for this. I don't know why it is faster but it is. especially with several hundreds of scene nodes (400-500) and a fps of 150 ... (without the point 2 the fps is in the order of 130-140)..

maybe i'm wrong . but this can be a starting point.

I think Irrlicht's animation system is what really needs improvement. Layered animation blending is pretty much standard for animations.

I'm almost sure that you are not the only one asking for improving the animation system

especially rigged models are heavy for rendering.

fmx wrote: @devsh
you really dont have a clue how much your skills are worth, do you?

I dont take sides and I have no idea who was kind enough to offer you $100, but I would happily pay you double that just to keep your project opensource so everyone could benefit from it (its not an offer BTW, just a fact)

Sorry about the late reply, but I was just now looking through this topic.

I thought about having DevSH make the shadows open-source for everyone at Irrlicht, but being 16 I have a bit of a limited budget for things like this.

Besides, it's not a copyright transfer (he's using it in his engine), but it's under ZLib license, though not open to the public.

Anyway, maybe if somebody wanted to split the purchase with me, he could put it up for everyone at Irrlicht to use. (It's completely Irrlicht-friendly, because my game is closed-source and I'm the only developer. There are zero ties to my engine. The 38,000+ lines of code will only leave my cold, dead hands. )

I must admit that I have not read whole this topic,
but I kinda know answer for question, why there is very little high-end games on Irrlicht.

IMO, this is because of community.
Look at people here. We have many great coders, but instead of extending Irrlicht, hacking Irrlicht code, they creating their own engines. Sometimes based on Irrlicht, sometimes from scratch.
My question is, _why_? If 10 people will work on Irrlicht instead their own engines, they can make Irrlicht next-gen engine, instead of 10 average engines.

Back in time when Linus first time released Linux.
In some time later, many people started working on developing Linux, instead of stealing code and creating their own systems.
Because people started working together on one project, instead working alone on their own projects, Linux is great system, that system, which you see today.
If people 20 years ago instead of hacking Linux will copy Linux code and start working on their own systems, today probably Linux will not exist, or still be in 0.x version.

So, people like Devsh, why you working on your own engines?
Blooddrunk is opensource, so this is not commercial project.
So, why you creating new engine, instead of making Irrlicht better?
I cannot understand this.

kazymjir wrote: So, why you creating new engine, instead of making Irrlicht better?
I cannot understand this.

I see this all the time. It always looks easier to build your own version of something, and you're always supremely confident that you can do it better than the last guy. The real complexity and magnitude of the effort doesn't dawn on you until you are well into the process, and most such projects are abandoned long before they are complete.

I agree that it's an enormous waste of effort, but you can't talk programmers out of their "not invented here" bias. They have to learn the hard way.

Some never do.

I can explain to you why I started building my engine from scratch, and why I did not use irrlicht

First of all, there's the obvious aspect of the challenge behind writing your own engine from the ground up. To be honest, I'm more interested in engines and the technology behind them than in the actual writing of games.

Second, while irrlicht is a great graphics engine in my opinion, it does not work towards the design goals which I had in mind; as you know irrlicht tries to support as many low level APIs on as many platforms as possible, with providing about equal quality among them
This causes a lot of implementations within the engine to be related to backwards compatibility, supporting older hardware, and implementing fixes which only specify to certain targets

Before I started writing my engine, and even before I made the decision to write my own graphics engine (the plan was to make it irrlicht-based back then) I wrote down the features I wanted, which included but were not limited to for example an advanced material system able to use external files, a programmable graphics pipeline with an easy to use and well-built shader system, central resource management, task-based multithreading, an engine-specific binary asset format with on-the-fly editing for debug builds and optimizations for release builds, etc.

To be able to implement all of this into irrlicht, I would have to completely gut the engine and rewrite a lot of existing code, so the benefit of just writing an engine from scratch started to shine through

I've been working on this project since the beginning of june, and all of the features listed above have been already realized (some partially) among many others

But I do agree that irrlicht could become more powerful by more community contributions, but as mentioned earlier in this thread (mostly the parts about the fixed pipeline vs a programmable pipeline) there are some design decisions holding back irrlicht somewhat

I can explain to you why I started building my engine from scratch, and why I did not use irrlicht

First of all, there's the obvious aspect of the challenge behind writing your own engine from the ground up. To be honest, I'm more interested in engines and the technology behind them than in the actual writing of games.

Yes, I understand it, I even thought about writing my own engine from scratch for same purpose.
My sentence "So, why you creating new engine, instead of making Irrlicht better?" was about writing new engines based on Irrlicht.

Radikalizm wrote:(...)
To be able to implement all of this into irrlicht, I would have to completely gut the engine and rewrite a lot of existing code

Here you have right.
But I see many projects that don't involve too much in main code, they are just Irrlicht with additional classes and/or modified internal code a bit.
This is what I don't understand.