Murphy's Irrlicht Mesh file format

vermeer · Post by **vermeer** » Fri Feb 18, 2005 8:57 pm

blender tends to be a nifghtmare when exporting objects due to the pivots rhing..

looks like you did edits with tab, and mesh data got relocated in relation to the original position and lights.I maybe using a very old version of the exported, as to be true, iI ve been more lately with mim tools, so...but in general, i'd recommend model something outside, or at least make it be a single object with one origin, preferrably at zero, and dont touch that...with some older versions of the exporter, was needed a vtrl+a to apply size and rotation, or change a value in script, but murphy also fixed that....

my advice is import an obj, and dont touch the geometry other than materials , uvs, etc.for long time i allways needed to do ctrl a with single mesh level and lights. (sometimes each pair of light+level,later, just all an ctrl a.)

that's the reason of all get relocated...it gets WAY more messed adding several meshes...
my advice is have it all being a single mesh out and import the obj...imho, wings is better modeller

and worked nicely in this wotkflow...i only found the prob when starting to move lights...and when saw that adding meshes made ctrl a not enough...

its fixable, by handling meshes and its origins,there are cool tricks:

-you can relocate an origin mesh to its mesh center
-you can put an origin to whatever a curosr is
-u can put cursor to selection,whatever the selection is
-u can put cursor to grid, and....if doing so, previously go clicking in the center in 4 views, so when u hit shift s to snap cursor to grid, the cursor will go to 0,0,0.

can do much more stuff if get into edit ,select all verts, play with this...

but imho, is faster start a new with obj reimporte d as whole, and go placing lights.

the textures need to be asigned in uv window, which werent...

sure there's a safe worflow to not mess, or recover the xform data easily, but i got more excited with mim tools...

ive been today playing with xsi to try to extract as lightmap that wonderful mental ray rendering....man , photons,photons,photons...ugh....

maybe i just stay with giles, its quite easier...xsi is something i learn slowly...is too large and different.

but already can rig an animate characters....which was my interest...

Murphy · Post by **Murphy** » Sat Feb 19, 2005 2:59 am

afecelis wrote:and what about the geometry all going crazy compared to the original .blend file?

vermeer wrote:my advice is import an obj, and dont touch the geometry other than materials , uvs, etc.for long time i allways needed to do ctrl a with single mesh level and lights. (sometimes each pair of light+level,later, just all an ctrl a.)

First, make sure you're using the 1.0.1 release of OCTTools, afecelis.

But.... yes... the orientation it ends up at is different than how you are viewing it in the .blend file. This is just the orientation I chose for how it gets exported. Indeed, it's sort of off for Blender... Blender considers Z as height, whereas in OpenGL, etc. Z is usually depth. So you have to look at it from the top. Though I just realized that Blender is winding in the wrong direction, so one of the axes is flipped. How many times did we look at this without realizing it was backwards, Vermeer?

Unfortunately, I got so used to looking at it this way that now I've probably made all the MIM converters flip it...

There's also a problem with light positioning in that the exporter expects each object to have its origin at 0, which Vermeer and I never noticed because we were only using a single mesh. This is my first script for Blender and I'm still learning the ropes.

Edit: Okay, I guess Vermeer did notice it. Just me who didn't.

I'll do an updated release later.

afecelis · Post by **afecelis** » Sat Feb 19, 2005 3:19 am

hooray!

So I found a bug? hehehehe

Vermeer: I gotta re-take my blender downloaded tuts to check all those texturing options. Any links you got in your pockets?

It's funny how something like units of measurement or axes system coordinates differ from one continent to another..... even weirder how they can affect output in an engine.

anyway, the tools look way too cool and interesting to take the chance of letting them just pass by and not learning them....they're just too tempting and they really refresh the Irrlicht scene. Can't wait to try MIM!!!

so if we look back, now we got several alternatives between free and not-so free:
1. Lord Tranco's pulsar tools with Jox's lmts loader (new version out)
2. Lord tranco's oct2 ent to obj to blah to fsrad (experimental...very, only Vermeer understands it

, lol)
3. Zdimitor's My3d format-3dsmax exporter and loaders;excellent if you got the $$$ for 3dsmax
4. Gmax+q3map2build to edit map files and compile them without using quake 3 or radiant.
5. MIM and Octtools!!!

edited after feeling the biggest embarrassment of my life: 6. Mohaps' CSM loader (Cshop lightmapped files) for Irrlicht

it pays to fool around and experiment with stuff huh?

cheers!

mohaps · Post by **mohaps** » Sat Feb 19, 2005 3:35 am

do not forget

The CSM Loader

Murphy · Post by **Murphy** » Sat Feb 19, 2005 3:54 am

afecelis wrote:So I found a bug? hehehehe

Yup... umm... sorta?

You certainly brought it to my attention. Thanks.

Vermeer: I gotta re-take my blender downloaded tuts to check all those texturing options. Any links you got in your pockets?

(Doing my best Vermeer impression)
Did you read my quick how-to on texture mapping in Blender? The method I describe works with the OCT exporter. You can read it in the FAQs/HowTos/etc. forum... http://irrlicht.sourceforge.net/phpBB2/ ... php?t=5391

5. MIM and Octtools!!!

Of course, MIM and OCT don't do any lightmapping themselves, though they support the use of Blender/FSRad, CShop, DeleD, gile[s], etc., etc.

I'm planning to add a converter for OpenBSP .obsp files to MIM, but I think the currently released OpenBSP binaries may not correspond to the source files. I don't want to bother with getting the tools to build with my old version of Delphi, so I've emailed the author and will hopefully be able to resolve it when I hear back.

I'm also hoping to include another improvement to FSRad with my new OCTTools release...

afecelis · Post by **afecelis** » Sat Feb 19, 2005 4:41 am

WHOA!!! Mohaps, my man!!!

I'm sorry!!! you're right!!!!

the CSM loader is a major butt-kicker!!!!! definitely a must in the indie lightmapper list!!!!

plz forgive my bad memory!!!!

ps. We never got to chance to talk. Drop me a line at: afecelis at gmail dot com

Murphy · Post by **Murphy** » Sat Feb 19, 2005 4:49 am

mohaps wrote:do not forget

The CSM Loader

Or the gile[s] loader?

Murphy · Post by **Murphy** » Sat Feb 19, 2005 8:06 am

Another screenshot. Three cubes lit at runtime by the same lights used to lightmap the scene.

Also, the new update of OCTTools is up. You can download it from www.constantthought.com/project/OCTTools.

Mainly it fixes some stuff in the Blender exporter -- object origins are now honored, flips Y and Z so that front view in Blender is front in Irrlicht, winds faces the other direction.

I also adjusted the color clamping in FSRad. It used to be that where a colored light was really bright, it would "blow out" into white, but now it is just limited to the maximum brightness that the particular color can be. For example, in the screenshot above, around the yellow light in the sconce, you'd probably have seen some white with the old method, but now it just looks yellow.

niko · Post by **niko** » Sat Feb 19, 2005 11:59 am

Wow, very nice. Cool. (Yes, stupid comments, but that is what came into my head immediately

]

vermeer · Post by **vermeer** » Sat Feb 19, 2005 2:45 pm

lol

well, it's important to know that the irrlicht author is liking it

er...murphy, sorry, was gonna send u that sample file to show that (not good or bad, just thing that happens) matter we talk bout, but ...said to myself, hey, why not try with my brand new xsi...man, even after vieweing the rendering and render concepts DVD and hours of trial and error with the ui, got t o something...but left it at the poiint of -finally- achieving a -very- nice gi rendering , in the proccess of using rendermap to bake the lighting to uv tga, i got stuck. or perhaps tired. the only left hand neither helps in xsi...

my head ended full of photons, emitters, transmitters, ...only a few things were known from previous, the typical area light stuff.

anyway, its rather interestin. u handle a lot that stuuff.

yup, did not bout that origin prob when many meshes as was not sure if was me wrecking it, and we were in a countdown to get into mimtools...i guessed if ther was a prob id first had to ensure was not my fault, and if didnt, some one elkse could fix the code once ur those months out...

btw, ive seen thi blender problem before, been tester o x plugin ,anbd some other...blender is one of a kind, different to all, and not perfect..but freee!

Murphy · Post by **Murphy** » Sun Feb 20, 2005 3:01 pm

Here's another new screenshot:

Okay, I know what you're thinking... this is just a screenshot of the new per pixel lighting demo, right? Only sort of.

Since one of MIM's major goals is to reflect Irrlicht's internals, well... I just had to have MIM support the new Irrlicht material types, right? Of course.

So that's what this is. This is the per pixel lighting demo, except that I've changed some of the code. You wouldn't know it to look at though -- it looks exactly the same. The difference is that I've changed Niko's code (comments and empty lines removed):

Code: Select all

scene::IAnimatedMesh* roomMesh = smgr->getMesh(
	"room.3ds");
if (roomMesh)
{
	smgr->getMeshManipulator()->makePlanarTextureMapping(
			roomMesh->getMesh(0), 0.003f);
	video::ITexture* colorMap = driver->getTexture("media//awall_color.jpg");
	video::ITexture* normalMap = driver->getTexture("media//awall_height.bmp");
	driver->makeNormalMapTexture(normalMap, 20.0f);
	scene::IMesh* tangentMesh = smgr->getMeshManipulator()->createMeshWithTangents(
		roomMesh->getMesh(0));
	scene::ISceneNode* room = smgr->addMeshSceneNode(tangentMesh);
	room->setMaterialTexture(0,	colorMap);
	room->setMaterialTexture(1,	normalMap);
	room->getMaterial(0).EmissiveColor.set(0,0,0,0);
	room->setMaterialFlag(video::EMF_FOG_ENABLE, true);
	room->setMaterialType(video::EMT_NORMAL_MAP_SOLID); 
	tangentMesh->drop();
}

.. into this...

Code: Select all

scene::IAnimatedMesh* roomMesh = smgr->getMesh("room.mim");
if (roomMesh) scene::ISceneNode* room = smgr->addAnimatedMeshSceneNode(roomMesh);

I then took the room.3ds file and turned it into an OBJ using LithUnwrap. I ran that OBJ through OBJ2MIM, and then hand-tweaked the MIM a tiny bit. The beginning (interesting) part of the MIM is this:

Code: Select all

<?xml version="1.0"?>
<MIrrlichtMesh>
 <meshBuffer autoTangents="true" planarMapping="0.003">
  <material lighting="false" fogEnable="true" backfaceCulling="true" materialType="EMT_NORMAL_MAP_SOLID" textureFile1="awall_color.jpg" textureFile2="awall_height.bmp" normalMap2="true" normalMap2Amplitude="20" emissiveColor="0,0,0,0" />
  <polygon>
   <vertex x="78.34499" y="20.0" z="-62.523" nx="-0.8660164" ny="0.0" nz="0.5000157" u1="0.55928" v1="0.26304" />
...

You can see the new planarMapping attribute of the <meshBuffer> tag, which automatically does a planar texture mapping using the mesh manipulator. The autoTangents element automatically converts the mesh buffer to one with the new tangents vertex type (you could also manually specify vertex tangents and binormals in each <vertex> tag).

You can see that in the <material> tag, I've enabled the EMT_NORMAL_MAP_SOLID material type, and have used normalMap2 and normalMap2Amplitude to set some appropriate properties for the second texture. I also turned on fog and set the emissive color to 0,0,0,0 -- just like Niko's code did.

The rest of the file is just a bunch of polygons and their vertices.

Anyway, this new code is still in its beginnings (I was out for most of the day and haven't had much time to work on it), but I thought I'd explain why MIM's release has been delayed a bit again.

niko wrote:Wow, very nice. Cool. (Yes, stupid comments, but that is what came into my head immediately ]

I'll take stupid comments like that any day.

Thanks! And thanks for your work on 0.8!

vermeer wrote:yup, did not bout that origin prob when many meshes as was not sure if was me wrecking it

Well, it's fixed now!

No problem about the sample file -- we'll sort it out later.

vermeer · Post by **vermeer** » Sun Feb 20, 2005 5:16 pm

Woah...
[havent understood a word, but whatever...

]

Murphy · Post by **Murphy** » Sun Feb 20, 2005 5:19 pm

vermeer wrote:Woah...
[havent understood a word, but whatever...]

Well, the short of it is that (if I haven't messed anything up...) you can now fully represent Irrlicht's new per pixel lighting materials and vertex type in a MIM file!

Less comprehensive, but even shorter: Adding a bumpmap is now really easy with MIM.

This required a fairly fundamental change in the loader. This is a good thing -- it can now use different vertex types internally (I'd always planned on doing this eventually, but hadn't yet). Among other things, this means it's no longer stuck using two sets of vertex coords even if you only use one of them. That bad part of this is that I implemented these substantial changes as fast as possible, and they're kind of gnarly.

I'm not sure I'll have a chance to clean up the code before I go, so I don't know when I'll get around to it, but it does work.

There's also a few new shortcuts, such as the ability to do some of the mesh manipulator operations on the meshBuffers in the MIM (the planar texture mapper and the tangent conversion) which will make MIM even more of a utility.

I'm personally a fan of the idea of having as much of the mesh information in the mesh file as possible/makes sense and writing as little code to manipulate it at runtime as possible. I think this will let one write better tools to facilitate better workflows -- perhaps most importantly by giving artists more/easier control of the content without having to go through the coders.

vermeer · Post by **vermeer** » Sun Feb 20, 2005 6:27 pm

"Adding a bumpmap is really easy with MIM"

Now, got it.

lol, I'm an artist..hehe.

vermeer · Post by **vermeer** » Sun Feb 20, 2005 6:51 pm

"I'm personally a fan of the idea of having as much of the mesh information in the mesh file as possible/makes sense and writing as little code to manipulate it at runtime as possible. I think this will let one write better tools to facilitate better workflows -- perhaps most importantly by giving artists more/easier control of the content without having to go through the coders."

True. as an artist I rather prefer to have that control over the output.the all in one mim concept or all in one in oct is really sweet, and even better for the artist , the viwers, using even the same engine to view is total wysiwyg for the artist.A dream to work like that

(specially as most artists, we cant code)