Irrlicht Engine

Well if you have ever read Eric Lengyel's chapter in Mathematics for 3D Game Programming and Computer Graphics on Polygonal Techniques, specifically the section called Decal Application, then I'm pretty sure you could grasp the theory a lot more, and possibly implement it yourself. I recommend that you pick the book up, not only for that chapter, but the whole thing is probably one of the most useful books on math for computer graphics!

May I request the patch posted in the thread shown below added to the next release? Would be nice to see that going, though.

http://irrlicht.sourceforge.net/phpBB2/ ... highlight=

Thanks.

dlangdev wrote:May I request the patch posted in the thread shown below added to the next release? Would be nice to see that going, though.

http://irrlicht.sourceforge.net/phpBB2/ ... highlight=

Thanks.

If you look on pages 1 and 2, then you will see a discussion hat already involves the stuff that is included in that patch.

One glaring problem I see right off the bat is the fact that he bypasses the IImage interface for loading the texture, and the other being that he uses the built-in D3DX function to do so in the texture implementation. Thus he prevents the support of OpenGL. That's a great patch if you just want to mess around with DDS support in DX9, but overall I don't think the Irrlicht devs are looking for that.

Lol i just wanted to make the patch to the scenemanager with a callback before each renderpass...and i just noticed that the RenderPasses ESNRP_SHADER_0-ESNRP_SHADER_10 are not pesent anymore in irrlicht 1.5....why??????

Sudi wrote:Lol i just wanted to make the patch to the scenemanager with a callback before each renderpass...and i just noticed that the RenderPasses ESNRP_SHADER_0-ESNRP_SHADER_10 are not pesent anymore in irrlicht 1.5....why??????

Because they were a hack introduced for Quake 3 shaders, they might make an appearance again in 1.6 though
If you have any ideas, please share them here

Well my basic idea is to add a renderpass variable to the SMaterial struct and on standard its set to auto which will then register to the corresponding pass. anyway before renderpass is rendered a callback class is called with the new rederstate as parameter so u know what are u rendering now. i want this to allowto change for example rendertargets between renderpasses. that way i could easily manage stuff like glowing materials or waterscenenodes. only problem is that i would have to be able to copy a rendertgets color and depthpass to another rendertget and of course finally access the depthbuffer itself...

Tada!

this is my wishlist for irrlicht's Santa Devs :

- Single, Unified, Binary, Native irrlicht mesh format
- Integrating VBOs better into irrlicht
- MRTs
- FP textures ( + clod() for vertex shader )
- More than 4 textures layers per material
- Making fpscam rotations relevant to the upvector ( i think clavet asked the same, will help ppl out there )
- Passworded .zip
- Some built-in simple postprocessing feature ( bloom etc. )
- Rotation methods for the 2D images etc ( GUI )

A watered-down version of DX9/OpenGL is not what I'm after, tho. I don't know if my time spent here is even worth it, Sigh.

Halifax wrote:

dlangdev wrote:May I request the patch posted in the thread shown below added to the next release? Would be nice to see that going, though.

http://irrlicht.sourceforge.net/phpBB2/ ... highlight=

Thanks.

If you look on pages 1 and 2, then you will see a discussion hat already involves the stuff that is included in that patch.

One glaring problem I see right off the bat is the fact that he bypasses the IImage interface for loading the texture, and the other being that he uses the built-in D3DX function to do so in the texture implementation. Thus he prevents the support of OpenGL. That's a great patch if you just want to mess around with DDS support in DX9, but overall I don't think the Irrlicht devs are looking for that.

Well no one is holding you back but yourself. If you feel you want that type of stuff, then merge the patch with your checkout.

Otherwise, no one is making you stay here.

Sudi wrote:Lol i just wanted to make the patch to the scenemanager with a callback before each renderpass

The SVN trunk now has ISceneManager::setLightManager(). See example 20.ManagedLights.

While the intent is to expose the lights to allow them to be turned on and off by the user application, the ILightManager interface provides callbacks at the start and end of each render phase (as well as before and after each scene node). You can register a light manager, then ignore all the callbacks except OnRenderPassPreRender().

one rather small feature which i would love to see would be the possibility to add external archive format loaders, like already possible for image and mesh formats.
on top of that, things like the beforementioned encrypted ZIP loading should be easyily implementable by people who need it.


has already been mentioned here shortly:
http://irrlicht.sourceforge.net/phpBB2/ ... highlight=

rogerborg wrote:The SVN trunk now has ISceneManager::setLightManager(). See example 20.ManagedLights.

Awesome!! will have to play with it for a while.

I would like to see more shadow types (like Ogre) and more options for casting shadows, other than just from an IAnimatedMeshSceneNode. On that subject, I would like to see an extension point - subclassing ISceneNode - from which all geometric nodes inherit, whether they be animated or not. This extension point would provide an interface for querying the geometry of a geometric scene node and this facility would be used by things like triangle selectors and shadow casters. So if a scene node is geometric we don't care what its type is to be able to perform collision detection, shadow casting and other tasks.

Also I would like the current shadow casting code to be repaired so that, for example, a warrior viewed from behind holding a sword in front of him with a light in front of him doesn't have the sword's shadow cast on his back.

SSG wrote:I would like to see more shadow types (like Ogre) and more options for casting shadows, other than just from an IAnimatedMeshSceneNode. On that subject, I would like to see an extension point - subclassing ISceneNode - from which all geometric nodes inherit, whether they be animated or not. This extension point would provide an interface for querying the geometry of a geometric scene node and this facility would be used by things like triangle selectors and shadow casters. So if a scene node is geometric we don't care what its type is to be able to perform collision detection, shadow casting and other tasks.

Also I would like the current shadow casting code to be repaired so that, for example, a warrior viewed from behind holding a sword in front of him with a light in front of him doesn't have the sword's shadow cast on his back.

You can just use XEffects for that...

What I'm trying to say is, I'd rather Irrlicht remained lightweight and flexible so we can implement our own shader effects and shadow types without being dragged down by alot of complexity and heavy scene layout.

It's really not a big deal in Irrlicht rendering a few scene nodes to a depth buffer then applying a shadow mapping shader.

IMeshSceneNode is the base for all geometry related scene nodes. However, it's jst for querying the mesh. Once you alter the mesh structures you'll have to know the exact internal implementation (because e.g. altering a vertex position in a static node is simple, but doing the same in a skinned mesh is rather ambiguous in which position (current frame, everywhere, weight controlled, ...) is to be altered and how. Hence, there's no general way without implementing very much which would be usually part of a 3d animation tool, into Irrlicht. But yes, shadows could get some updates.