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...
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.
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?!
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.
)