Irrlicht Engine

Has anyone thought of doing a Java port of Irrlicht instead of just making the bindings? It would be missing a couple of things, such as a Direct3D renderer.

I think the licence stinks. It actually prevents you from fixing any bugs. It would be nice to keep it BSD like G3D.

I don't think the source has been released. It pisses me off almost enough to point out that fact to the sf admins and have the latest binaries removed. It must be against the T&C.

If you want to add stuff from 1.5 and you have enough time, perhaps you might want to look into making Jirr 1.5 ...

There's no reason why you can't as long as Jirr can render to a java.awt.Canvas. With Eclipse you won't have any rendering order issues because it doesn't use Swing. Having said that, since JDK 1.6 u12, AWT and Swing play nice with each other, meaning Swing components can be rendered atop AWT ...

About pure Java 3D engines being slower because they perform more JNI calls: That's just not true. JNI becomes slow when you pass java object references as parameters, because all that has to be "unpacked" on the native side. Native calls involving only primitives (such as JOGL) are much faster ...

I'm certainly up for devoting time to a next gen irrlicht, although I don't have an abundance of time. Is there any next gen work in progress at the moment?

Render queues sound like a good idea too. And scene manager neutrality. But let's not get too much like Ogre. We should aim to maintain ...

My business partner highly recommends fragMOTION for animating. It's a good general purpose modeller that especially shines when it comes to animation. It also exports to many formats, which probably isn't much of an issue with Irrlicht as it loads many mesh formats, however this can be useful if ...

Ok, I'll recompile the examples with the 1.5 Irrlicht version I have which is built against the November DX SDK. Already have the latest drivers. I'll post any issues to the appropriate thread. Thanks again BlindSide.

Oops :oops:

I was confused from another discussion that mentioned Irrlicht catering to non-compliant compilers and/or STL implementations. Does Irrlicht 1.5 assume ansi/iso C++ compliance these days (perhaps not 100%, but as much as can be reasonably expected)?

Another thing I would like to see ...

Do you mean something like this?


irr::io::IAttributes attribs = device->getFileSystem()->createEmptyAttributes();
node->serializeAttributes(attribs.get());
irr::core::stringc name = attribs->getAttributeAsString("Mesh");
selector = smgr->createOctTreeTriangleSelector(smgr->getMesh(name.c_str ...

Thanks Munger, but unfortunately that doesn't help because IShadowVolumeSceneNode is an abstract class whose implementation isn't available even by including irrlicht.h. It would be nice if these classes could be exposed to those of us that might want to use them as we delve deeper into the engine ...

One report. And another one. I really do appreciate your work and it's my last hope for using Irrlicht unless the shadow issue is addressed soon. My apologies if I offended.

Blindside, with respect to your efforts with XEffectsR and the fact that you have made it freely available, it kind of pisses me off to see you pimping it every second post when it in fact doesn't work properly (the examples keep spamming me endlessly about some floating point errors and other ...

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 ...