Irrlicht Engine

Bullet integration
I know this is a rendering library, but i feel like physics and collision detection goes hand in hand with rendering.
Pro's

• Bullet is ZLIB
  easier/faster addition of collision and physics
  integration with collada files
  IRRedit with real time physics anyone?

Con's

• Hard to do(i would love to help)
  might take away focus from rendering engine

Thoughts and ideas ?

Why Bullet rather than Newton, Havok, PhysX or even better, PAL who all have already a wrapper? Also, no. Just a bad idea on the short range.

twilight17 wrote:I agree with kburkhart84, we should have at least 1 format that's completely supported, be it irrmesh or .x (or any other format). Irrlicht's current support is iffy. You have to go through trial and error to find a format that works for your needs.

None of the existing formats will have all features, simply because no such format with all features exists. So it's either irrmesh or no full support for all Irrlicht features (e.g. .x doesn't do more than one texture).

Dorth wrote:Why Bullet rather than Newton, Havok, PhysX or even better, PAL who all have already a wrapper? Also, no. Just a bad idea on the short range.

All those physics wrappers are working very well already. And I don't see the manpower in the team to support several wrappers in the engine (not even one IMHO). But irrExt might make this available with better Irrlicht integration, it'd just need an official maintainer to join the irrExt team. I'd favor PAL due to the wide support of engines...

i remember irrblend has its own binary irrmesh format, which is very fast. maybe can consider about that format?

Yes, might be a good idea.

hybrid wrote:

twilight17 wrote:I agree with kburkhart84, we should have at least 1 format that's completely supported, be it irrmesh or .x (or any other format). Irrlicht's current support is iffy. You have to go through trial and error to find a format that works for your needs.

None of the existing formats will have all features, simply because no such format with all features exists. So it's either irrmesh or no full support for all Irrlicht features (e.g. .x doesn't do more than one texture).

I understand that part, which may be why it is ends up better to expand on the .irrmesh format. The problem we could run into are possible file size issues(mainly considering having all of Irrlicht's features). Also, export from our 3d modeling programs could also get troublesome, unless someone knows how to create exporters from said programs. The problem is that some of us use blender, some use maya, etc... so by attemting to use the .irrmesh format, even when all the specs are worked out, you still would need manpower to get it working.

er...
probably it is a nonsense, but...seen in other engines...what about a converter?

That is, a converter that can eat a md5, b3d or x file ---> exports an animated irrmesh binary(or ascii) file...

and obj --> irrmesh for statics...

for example.
yep, surely a nonsense

We already have a converter from all supported meshes into the writeable meshes, including .irrmesh. This leads to an editable XML file, though, which is not really desireable as final format. But it's easily posible to write an XSLT script to convert to a new binary format. So the important part is to define a new irrmesh binary version. Is there any reason to avoid a simple binary serialization of the XML format with a fixed tag order?!

(I guess that question is not directed to me )

No, it's a general task for anyone who likes to do this

hybrid wrote:Is there any reason to avoid a simple binary serialization of the XML format with a fixed tag order?!

It would be nicer if we had some binary data reader/writer that implemented IXMLReader/Writer and worked everywhere without changing the code, but it looks like this would be impossible. So I agree that a simple, fast binary format with fixed tag orders would be the best option.

I think currently more important problem than mesh format is IImage/ITexture stuff and inherit, so *.dds, floating point textures etc. MRTs don't require prebuilding current Irrlicht texture stuff, only implementation it. If You need I can update my MRTs stuff to current SVN revision, so We can implement it very quickly. This code is 100% working and tested on many platform: NVIDIA / ATI (of course MRTs support on graphic card is required, so SM2.0, but GF FX series has got poor support of MRTs) and differences systems Windows XP / Vista / Linux.

I vote for compressed textures.... they are a directx 6 feautre!

omaremad wrote:I vote for compressed textures.... they are a directx 6 feautre!

Yes, this is old, but VERY VERY VERY important stuff.