RFC on new flexible ILightManager

[rogerborg]

Gaa! OK, that should be a full patch now - please let me know if I've missed anything else. I've added an example application with build files, but I've only been able to test it with Visual Studio 2005 on Windows, so testing with other platforms and build environments would be very welcome.

Performance is indeed very much dependent on the user's light manager implementation. I've included both a naive implementation of per-node lighting and a smarter one to illustrate the difference; it's a lot more than I'd expected.

I'd like to know how to set the relation of scene nodes to light scene nodes.

Any way you like.

In the example app, I've shown the use of light scene nodes that are child nodes of the mesh node being rendered. Another use might be:

Code: Select all

 ___________________________...___
|    'Room' scene node      ...   |
|___________________________...___|
   |        |        |         |
 __|__    __|__   ___|___   ___|___
|Light|  |Light| |Mesh #1| |Mesh #X|
|_____|  |_____| |_______| |_______|

When Mesh #1 (to Mesh #X) are rendered, the light manager could check node->getParent()->getChildren(), and turn on all the lights that it finds. This would allow for 'local' lights that light a notional area; a room, geographical area, or similar. This could help with the "lights shining through walls" problem, or simply cut down on the number of lights that are being used to light each mesh.

You imagination (and available cycles) are the only limits on what per-node operations you can carry out.

[rogerborg]

OK, submitted to the tracker. Have at it.

[UPDATE]

Wow, I've just now tested release mode builds, and the difference in difference in (sic) performance is startling .

Compare and contrast:
Mobile 1.7Ghz CPU, Radeon Mobile 9000 GPU:

Debug mode:
Naive per-node lighting: ~35 fps
Smart per-node lighting: ~70 fps

Release mode:
Naive per-node lighting: ~69 fps
Smart per-node lighting: ~70 fps

That's quite astonishing. I guess even the naive per node - per light method might be usable then.

[rogerborg]

Just pimping this again. I've updated the patch in the tracker to fix some minor conflicts; it's still good to go in.

[rogerborg]

Not to get overly whiny, but after expressions of interest from the devs, this is still sitting (and now doubtless rotting) in the tracker. I'm beginning to see why there are so many forks of Irrlicht around.

[hybrid]

First step will be to include the new light scene node structure. When done with this the light manager might come in, but probably not too soon. However, as soon as the patch list on my web page becomes smaller I can make sure that the patches will continute to work with latest SDKs. Anyway, I don't think that there are high chances that your patch will be lost with just 5 patches on the tracker...

[sio2]

Not to get overly whiny, but after expressions of interest from the devs, this is still sitting (and now doubtless rotting) in the tracker. I'm beginning to see why there are so many forks of Irrlicht around.

I'm making a Doom3 model loader (see Project Announcements) and one of the things I'm doing is making the high level shaders with which to light them.

I'm working on an upcoming demo and one of the things I'd like to do is load something like a Quake3 level with lots of MD5 meshes around. The issue, as you know, is that Irrlicht allows max 8 lights set at any one time. For most circumstances a max of three lights will do for lighting meshes. So, the issue is, for every model that's rendered pick the three "best" lights from the 10's (may 100's) of lights from the Quake3 level.

Any thoughts? Would your LightManager help with this kind of thing?

BTW Before anyone points this out, this applies to any other Irrlicht model format as well.

BTW2 SVN Irrlicht now has much improved Quake3 level support. The entity list - and hence the full list of lights - can be obtained.

[sio2]

Not to get overly whiny, but after expressions of interest from the devs, this is still sitting (and now doubtless rotting) in the tracker. I'm beginning to see why there are so many forks of Irrlicht around.

Not to get overly whiny, but the two sample apps mentioned in this thread come up as 404. I was going to have a good look at them...

[rogerborg]

Meh. The source code is definitive, which is why I'm a sad panda that it's currently rotting. I really don't mean to criticise our volunteer devs, but it's problematical to stay enthusiastic when progress appears (from certain very subjective points of view) to have stalled. If I have to maintain my own patches, then I might as well take the hit of switching to Ogre3D instead where all this is already done. That's not a threat or a challenge, just pragmatism.

[sio2]

Meh. The source code is definitive, which is why I'm a sad panda that it's currently rotting. I really don't mean to criticise our volunteer devs, but it's problematical to stay enthusiastic when progress appears (from certain very subjective points of view) to have stalled. If I have to maintain my own patches, then I might as well take the hit of switching to Ogre3D instead where all this is already done. That's not a threat or a challenge, just pragmatism.

FWIW I'll download the patch from the tracker and take a look.

Have you seen the updated Quake3 support in SVN? I've loaded up maps from the official game pk3 and there is a vast improvement. I'm thinking of a demo with your light manager, a Quake3 map and a third-person model moving around the map; this would test things out nicely, I believe.

[hybrid]

Now, if you require an engine which has all this already in to date you should probably consider to change to some other engine. It would be a sad thing for Irrlicht - at least what I've seen from you until now was always pretty useful. And I think there was not only the lonely developer who attested this.
However, you cannot expect that we just put everythign into the engine without any plan. At least for me the current plan tells me to add the new light scene nodes and then continue with the light manager stuff. Maybe you should have a look at the bug forum where almost 4 year old bug reports are floating around. And I have personally maintained a huge patch website for almost 2 years before the first chances to add those things to the core. Without any intentions to offend anyone I'd say that this is indeed the wrong idea of how such projects work. Be happy with the feedback you already got and the fact that a light manager will eventually come.

[rogerborg]

Be happy with the feedback you already got and the fact that a light manager will eventually come.

When?

Urgh, the patch has rotted horribly. If there's still any interest in it, I'll try to get it updated.

[Dorth]

I do have some interest in it. I'd even like it to be expended and officialized. I'd also like Hale Berry naked, oiled and taped in my bed... (wait, where did I hear something similar before). So, whenever you got time and interest.

[hybrid]

Be happy with the feedback you already got and the fact that a light manager will eventually come.

When?

Urgh, the patch has rotted horribly. If there's still any interest in it, I'll try to get it updated.

I don't exactly recall who wanted to take that task at that time, but the last time I asked you about the light manager you said basically to avoid your patch, because it might have some flaws and is already pretty old. So I don't know what's the plann for light management. You might want to ask varmint, who volunteered the last time to take the job.

[rogerborg]

Thanks, I'll update it and see if it actually does what I think that it does.

[rogerborg]

I can haz resunerection?