blitz has got b3d why not Irrlicht Irr3d?

vermeer · Post by **vermeer** » Fri Jan 14, 2005 9:55 am

Exporters for each package?

While nice, a hell of a work for the coder that makes it...

I think is easier to translate from the more standard format to an irr format.

What i am seing more as a barrier is lightmaps , for now. You can export a fully bone weighted and animated x file from any package, freely, from Lightwave, Maya, of course Max, ultimate unwrap, Blender, character Fx, Open Canvas, gameSpace, etc... True, there are some problems, but the workflow is not complex if make a bit trial and error with setttings, and in some cases (Ultimate Unwrap does not need it, for example) save with MS Meshview tool.

So, in that, at least we can live with x... Of course more power would be lovely but...imho lightmaps as is now is forcing to use very limited mesh editing tools...i know many people like q3 maps, I do too, but i have worked in comercial games, and the possibilities using a real modeller are so much greater. 128x128 in a lightmap, as a limit, is too much of a limit, for me, as well as convex only geometry, etc. Not to mention most of the good packages are not usable for comercial, Gmax license is not 100% clear -neither its future- etc. I think Afecelis has done a great job about that though, and for alot of projects, is perfect. I'd just wish Irrlicht also had the powerful possibility.

Support of x 2nd UV channel (and of course the ability of the engine in "understanding" the tga asigned to it as a lightmap) would suffice for most projects. But having no smooth groups support, a 65,000 tris limit, and being quite a complex-for-the-coder format, may make it not the ideal step to convert from...but...heck, there's little mro eoptions than that one, available in a number of packages (I am trying to avoid the "per package" plugin...neoengine author said it very well...not gonna make a plugin for every package out there...)

And the freebies and uber cheap tools (Ultimate unwrap supports both x bone and weights anim, 2nd uv(in x and ase), lightmap asignment, ase and x export. A jewell. ) is cool to support them.

X has wider support, so a converter to the Irr format would be clever for that. If a coder can answer me if two meshes of 65k tris kills a lot the frame rate, I mean it kills significantly more than a 130,000 tris single mesh... then, x is not the option... If it does not kill it, heck, rarely ur gonna output for now so huge meshes ingame, even 65k is a load. But many games are done of many entities/meshes, so I guess must be not a problem. If this is so, x is right to go for levels. Only, no smooth groups, but yet there's the dirty trick of unwelding in ur seams. Blender is probably gonna go this route.

ASE to irr, would be way more powerful, if fully supported the format. but in terms of lightmaps, it leaves it only -that I know- to Ultimate Unwrap an Max (there's a Blender exporter, but no way, Blender yet has NOT got 2nd uv channel...)

So, if the 2 meshes per terrain or full level, is not a performance issue for Irrlicht, I'd say..heck , go for x...perhaps a lot of familiarity with the format is already there, I dunno...People have got more or less familiar with it, also, 3d art tool wise...

Also, in what is "only levels" there's WAY more packages supporting it. There's one of the eaiser to handle and learn modellers, the japanese Metasequoia LE, LE is non usable for comercial projects. Is really good fo rstatic objects and has been used widely in flight SIM for making custom planes, parts, etc, with a lot of quality. Though was though mainly for character modelling. It has point to point modelling, and non solid modelling, the opposite to wings (though I yet prefer wings) Metasequoia LE exports X files perfectly, though no 2nd uv support.

Other free tools like Zmodeller also support x export. Yet no 2nd uv, lightmap channel. Luckily, seems some tools for free already support it, like Delgine editor.

Finally, I'd go fo ran x to irr converter, and add lightmaps support to that irr format, plus of course, the ability to port the second UV channel that is in the x file, towards the irr format. If for coding issues (i don't know coding) is hard to make it read the asigned lightmap tga, heck, if it can later on just be linked easily by the coder in the engine, good to go...

X bones animation with weights, is already directly being imported by irrlicht. So while I agree with Electron on it'd be ideal if irr format supported that x feature also, I'd say follow the kiss rule, and take it easy, lightmaps have for now quite a much harder workflow -speaking on at least a number of tools for a workflow, not only one- than x. And actually the workflows limit in power, which I see worse.

ideally though, the Irr format should count on a pair of converters towards it: ASE and x. While I priorize clearly x for reasons mentioned, well, if after that, an ASE converter is done, then , more features are available (smooth groups, camera animations, lights, more than 65,000 triangles per mesh.)

So, the Max users and Ultimate Unwrap users, could export a more featured level. But as I say, I think we should priorize the "for the masses" concept.

Being there Delgine now, free with two Uvs...or Slim Shady...(or combined with it) ...Blender exports X : I expect an update of the x exporter to support 2nd uv once it gets supported in blender. Not soon: the nex update is to improve char animation, happily.

Electron · Post by **Electron** » Fri Jan 14, 2005 9:46 pm

I don't know exactly what in the .x file is limited to 65k tris, but Irrlicht's meshbuffers use 16-bit indices, so can't load more than 65k vertices of a single material type anyway.

bal · Post by **bal** » Fri Jan 14, 2005 10:08 pm

IrrlichtNX++'s are 32-bit.

Spintz · Post by **Spintz** » Fri Jan 14, 2005 10:11 pm

Actually IrrNX does not truly have 32 bit indices. It only allows calls to the draw primitive functions with 32 bit indices. Any meshes loaded up by IrrNX still are limited to 16 bit indices.

My own version I have of Irrlicht has support for true 32 bit indices, if anyone wants to know how to make those changes, let me know and I'll post the changes ( there's quite a few, so it'll take a bit ).

BTW, the version I have with 32 bit index buffers works with OpenGL, DX8 and DX9, the software renderer will no longer work.

brcolow_guest · Post by **brcolow_guest** » Fri Jan 14, 2005 10:56 pm

You should post the changes as a new patch over at NX++'s forum: www.irrlichtnx.mmdevel.de I am sure they might be interested.

afecelis · Post by **afecelis** » Fri Jan 14, 2005 11:29 pm

I'm sure Niko would love to see it as well.

Electron · Post by **Electron** » Sat Jan 15, 2005 1:49 pm

Hmm. Might there be some way to make 32-bit indices optional? I agree that they would be useful for some people, but they would greatly increase memory useage, and I for one don't plan on making models with >65k vertices to a material. Perhaps a #define in irrCompileConfig.

Spintz · Post by **Spintz** » Sat Jan 15, 2005 1:54 pm

I looked into making it optional, it would be easy with a compile flag, however, that's not the proper solution. Memory really isn't that large of a consideration, IMHO ( no pun intended

)

Let's even say you have meshes, etc loaded into memory totalling over 10 million primitives. With 16 bit indices, you'd have 20 megabytes of index data, and with 32 bit indices, you'd have 40 megabytes. That 20 megabyte difference really is very small nowadays. Just making everything use 32 bit indices is the best way to go, IMO.

mm765 · Post by **mm765** » Sat Jan 15, 2005 5:20 pm

i dont think that 32-bit indexes only is a good idea. using your example: if you load that up into an indexbuffer on the card you would need additional 20mb of ram on your graphicscard. besides that if youre not using buffers you have to transfer that over the agp/pci/whatever bus every frame so it will hurt your performance.
thats why nx++ has both.

Spintz · Post by **Spintz** » Sat Jan 15, 2005 7:12 pm

nx++ only has both DrawPrimitive functions, that's easy.

The issue I'm talking about is making it so the internals of all the meshes and scene nodes have 16 or 32 bit indices....that would be a lot of work. Maybe things that will be large, like terrain nodes/meshes could have 32 bit indices, but character models and other things should have 16 bit indices.

But you all need to stop saying NX++ has 32 bit indices, it doesn't. It only has added drawPrimitive functions for 32 bit indices, while still retaining the 16 bit indice ones.

mm765 · Post by **mm765** » Sat Jan 15, 2005 7:45 pm

i certainly never said it did. and i didnt say so in my previous post. all im saying is, that 32-bit only will either use up more ram on your gfx-card or make your performance drop.
so calm down a bit pls.

ok i c maybe the last line could be misunderstood. sry for my bad english then.

afecelis · Post by **afecelis** » Sat Jan 15, 2005 9:50 pm

mm, everything is clear. I think we're all aware of the fact that more complex stuff will require more complex hardware.

Having both is a great solution, and it would depend on your target machines you're developing for if you turn 16 or 32 bit indices on.

That's the good thing of open source, the power of choice!!

vermeer · Post by **vermeer** » Sun Jan 16, 2005 12:07 pm

seems it's just that...i encountere the problem with dx8.0 exporter...so, it was limiyted in the plugin.... if its based in 8.1, then probably it can export with more than 65k.... reading this :

The EnhancedMesh sample shows how to use D3DX to load and enhance a mesh. The mesh is enhanced by increasing the vertex count using N-Patch tesselation algorithm.
DirectX 8.1 version of sample adds support for 32-bit indices in meshes (allowing meshes to be enhanced to over 65k vertices on non N-Patch compatible devices).

http://clootie.narod.ru/delphi/download_dx81.html

Not interested in n-patch, but that shows that 8.1 compliant x files should be able to be exported from the packages with more than 65k tris. How much more...I dunno.

Other thing is that internally it supports probably both 32 and 16 bits modes, ideally...i suppose.

Magnus · Post by **Magnus** » Mon Jan 17, 2005 7:14 pm

irrlicht is open source,,, so why dont people just modify the code given to them if they want a .irr or .irrlicht or .whatever file type? theres gotta be a few people who can code that

I know I sure as hell cant though it sounds awesome esspecially a exporter for .blender type files.. thatd be so great

Spintz · Post by **Spintz** » Mon Jan 17, 2005 7:39 pm

I'd love to get into that, I could definitely code it up once I get into that part of the game I'm developing. Since I suck at 3d modelling, I keep putting it off.

I'm in the process of getting the GeoMipMapping stuff working and then to finish off my AtmosphereSceneNode ( which currently uses a skyplane, as opposed to the SkyBox, and hopefully, when done, will be able to display volumetric clouds and such ).