Sorry, I've made a mistake about the 2 UV set support... I double checked and yes, unfortunately it support only 1 set of UV for the OBJ format.

You should try collada then. This format is slow, but is made for interexchange. But I've never tried it much with Irrlicht. Once you have the model in Irrlicht for speed you could save it in .B3D from there.

Mmm.. I did once try to load two identical objects with differing UV sets thentried to programatically transplant one set into another.The problem was that when I exported these two objects (one with plain UV Map and one with a Lightmap)the indexing into the data in the model changed causing bogus memory index reads.

All I know is that if I could get two identical versions of an object where onlythe UV Locations differ, then a First item could be load and set (in irrlicht) to have 2 UV sets .Then the second object is loaded and its UV locations transplanted into the second UV Map i.e. Lightmap..(the second object would then be dropped of course)

The issue, I think, is to get a "3D App Title" that can export two objects with IDENTICAL UV Index Refs yet differentUV positions.. (still looking)

IRRB seems to be the only way this can be done easily (and only from blender) and in very large ascii format..(a working binary form of IRRMESH could help)

The last resort would be to write a complex routine that would analyze the two model polys and "smartly" match upthe UV Locations..

Reached a point where smart shaders and deferred rendering etc won't mean much without a good "Scene Management System"..Trying to learn Irrlicht's "Scenegraph"..(still not able to properly inter-relate my own classes publicly to Irrlicht classes like "ISceneNode")

I also multi threaded the engine with a thread pool design, currently it only threads the onAnimate() function for all nodes as its already highly parallel and safe ( each parent spawns animation tasks on its independent children) so its accelerates software skinning and particles automatically. It gives a huge boost in performance if you omit the draw calls, but since the drawcalls have to happen on one thread the cost of them diminishes the multi threading returns.

It runs on irrlicht 1.8.... 1.9 changes allot of MRT and shader functions and I cant be bothered rewriting all that code.

"Irrlicht is obese"

If you want modern rendering techniques learn how to make them or go to the engine next door =p

Could optimize with what I said above, as well as using the OpenGL extension to specify explicitly MSAA sample locations for 8x or 16x less pixel shader invocations during depth only pass, but I'd have to switch from a cubemap FBO attachment to a Multisample Array.And then obviously a custom resolve, but that could be combined with mipmap chain generation and the blur pass for VSM or other.

Hair experiments in Irrlicht. Takes a few million polygons, but surprisingly I can still move my camera even in debug without problems. Thought for games it might be a little bit slow. It's basically creating cylinders (well... roughly approximated with triangular prism here ... ) along the normals of the polygons with several hair-segments and some random factors. (edit: And yeah, it's probably stupid to use a wood-texture for hair ^_^)

Geeeeeeez! now that's killing the fly with a cannon! XDLooks nice, none the less, i'd go for a "cheaper" (but more efficient) approach that would be, in a nutshell, using the classic fur shader, but with geometry shader, instead of a multipass effect, allows for certain effects, adjustments, and can be very neathttps://www.youtube.com/watch?v=4pXBgsybn0s

Hehe, yeah - should probably do that. The reason I did it this way is because I need that structure for export - this stuff is rendered later with Mitsuba and that expects hair as line-segments. So in other words - this is kinda my debug-code to see if things are correct and to allow modify carpets in real-time before export for the real rendering.