Irrlicht Engine

This squirrel will be a happy squirrel when decals make it into Irrlicht.

Seriously does noone else think this is a killer feature? And far more important than any cutting edge stuff?

And that old decal scene node floating around doesn't cut it for an actual game. Needs clipping and perhaps culling amongst other things. I tried once myself and failed. One day, oh glorious day, I will try again. But I think it might be beyond my skills. [/disclaimer]

Don't be afraid to add your requests to the feature requests tracker, not only will they be stored forever until someone decides to implement them, but it will also increase Irrlicht's ranking and activity stats on SourceForge

OK, I added patch with MRTs support to Irrlicht Patch Tracker

ikari734 wrote:

Also, what's the cost/benefit of moving processing to the GPU as opposed to supporting multithreading in Irrlicht to allow effective use of multiple CPU cores?

I could be wrong, but most games these days use both GPU and multithreading. You have the GPU handle all the graphics related-stuff (transformation and lighting calculations), and use the CPU to process physics, animation, scene management, and user input, using worker threads. And since transformation, lighting, and rasterisation is quite a grunty process in its own right, the GPU has enough on its plate, so if you have a nice multicore processor, why not use that to do various non-graphics-related work?

I would very much like the next version of Irrlicht to include multithreaded support natively, so that the CPU could be processing the second frame, while the GPU is processing the first frame. Most games do it that way anyway. That's what the swapchain is for in DirectX.

I completely agree, multi-threaded support is a MUST now a days. Can we get that in the next release, or the start of it? I have used TBB and am a professional C++ developer. If no one else could do this, could I add this support?

Any suggestions or patches regarding this or any other feature are highly welcome. No promise, though, that they will be included in the next release or so. But it will definitely not delay the process

Shane wrote:I completely agree, multi-threaded support is a MUST now a days.

OK, but support for what, exactly? I mean what do you consider to be internal to Irrlicht (e.g. streaming loading), and what's in the application domain (e.g. synchronising access to the scene graph for manipulating it from an AI thread).

Shane wrote:If no one else could do this, could I add this support?

It's great that you're keen to do this, but are you ready to:

1) Implement it across all Irrlicht platforms and build environments?

2) Support it, including replicating and addressing the inevitable bugs and not-bugs that get discovered by users, many of which will be of the "I was just doing stuff, and stuff broke!!!!11!!" type?

I don't have any problem with adding support for (e.g.) streaming loaders, it's the thought of supporting multithreaded operations that fills me with dread.

It needs to be done though. I am working on a project that will need threading at some point if my team continues to use the Irrlicht engine. I am afraid that when we get to that point, maintaining a threaded version of Irrlicht, and getting new updates of the engine will be difficult.

I understand that supporting it for other people will be time consuming too. So this will have to be a decition our team makes in the coming months. Maybe we can take this offline and discuss more.

I actually did create a streaming asyn IO class for Irrlicht about a year ago, funny you would use that as an example.

I'm sorry what do you mean by application domain? Are you talking about the code (game logic) that is using the engine?

Ok i just tried to make a simple multithread meshloader....but that doesn't work. Bc when only calling the load mesh function in another thread irrlicht is kinda not loading the textures...i guess thats bc it needs to upload the texture to opengl/dx inside the mainthread.
other then that why not simply precache all needed meshes for the level???if u are not programming a seamless world game u won't need multithread loading. ok i know that argument is just dumm^^
anyway what i like to see in the next release is a callback between the renderstates. Like before all solid/transparent are drawn and of course the userdefined. that would make some things like changing rendertargets easy for some special nodes. Like the glass pane. U could make the pane itself be a some userdefined material so it is rendered after all the others. then before it i rendered u change from the texture target to another texture or the screen and u draw the pane. oh and one other thing in the early versions of irrlicht i was able to copy the whole screenbuffer to a targettexture by simply calling set rendertarget without clearing th color and depthbuffer but today this won't copy the screenbuffer..this is kinda good for other effects but i would like to see a copy current buffer to this. well thats me so far. Because the stuff about the vertexbuffers is comming but slowly

I think it could be useful if the enige fires an event when beginScene/endScene started/finished.

Of course there should be the possibility to turn this on and off as I can image this could cause some performance issues when not needed.

Sylence wrote:I think it could be useful if the enige fires an event when beginScene/endScene started/finished.

This isn't really useful, beginScene/endScene are called by the user anyway, so the user should know when they're called. Events only make sense for things that happen inside the engine.

Sylence wrote:Of course there should be the possibility to turn this on and off as I can image this could cause some performance issues when not needed.

Two events per frame shouldn't make much of a difference.

On the topic of multi-threading.. Perhaps we should have a separate thread for this?

bitplane wrote:On the topic of multi-threading.. Perhaps we should have a separate thread for this?

Indeed. It seems lots of people are starting to get interested with this idea (me as well) and would be better discussed in another thread.

xDan wrote:This squirrel will be a happy squirrel when decals make it into Irrlicht.

And that old decal scene node floating around doesn't cut it for an actual game.

Hi, xDan.

There is a decal node??! I've never saw it inside IRRlicht before!

Are we talking about the texture we can put over a mesh that match perfectly the poly face and use an alpha for blending with the face?

Yes this would definitively improve the look of levels if we had a feature like this. I'm using this a lot in Hammer to make the level less regular, use it also to create some interesting details like adding fake elements (as fake windows, fake vents, grafittis etc)

Sylence wrote:I think it could be useful if the enige fires an event when beginScene/endScene started/finished.

The "light manager" patch that I have waiting in the tracker is really a "scene manager callback" class that allows the app to get callbacks at the start and end of each rendering phase, and before each scene node is rendered. That should hopefully provide the functionality that you need.

rogerborg wrote: The "light manager" patch that I have waiting in the tracker is really a "scene manager callback" class that allows the app to get callbacks at the start and end of each rendering phase, and before each scene node is rendered. That should hopefully provide the functionality that you need.

Yeah thats what i meant a callback before each rendering phase.

christianclavet wrote: Hi, xDan.

There is a decal node??! I've never saw it inside IRRlicht before!

Are we talking about the texture we can put over a mesh that match perfectly the poly face and use an alpha for blending with the face?

Yes this would definitively improve the look of levels if we had a feature like this. I'm using this a lot in Hammer to make the level less regular, use it also to create some interesting details like adding fake elements (as fake windows, fake vents, grafittis etc)

http://irrlicht.sourceforge.net/phpBB2/ ... php?t=3464

What I was referring to is posted by Armen138 on page 2. It just uses a single quad of two triangles I believe. And there is no clipping of "overhanging" decals..

See it in action here