Murphy's Irrlicht Mesh file format

[Murphy]

So many messages! If I don't respond to something in particular, please ask again. We have so many subjects up in the air, it's kind of too bad it's all in one thread. Ah well.


First, here's a screenshot of Irrlicht showing vermeer's level with lightmaps. It's really banded, probably because of Irrlicht loading the texture as 16 bit. This was done with a very experimental .X -> .MIM converter, and then loading the .MIM into Irrlicht. In this particular image, I actually just converted the second set of UVs and stored them as the only set of UVs in the MIM since the first set wasn't much to look at anyway (no offense! ).



vermeer:
In regards to gmax... I didn't consider that it was extensible until you started talking about scripts for it. I haven't really looked into it yet (I don't have the gmax help files yet), but it's possible that a .MIM exporter be written for it (i.e. gmax->MIM instead of gmax->yafray->MIM). Not sure how much work that'd be yet. The yafray XML format also seems to contain the necessary info. Did you say you had a Max script to output OBJ from gmax? Where can I get that?

You quoted "Only real UVW Mapping is supported. UV mapping that is assigned through the material editor isn't seen by the exporter.". What's the difference?

You also quoted "YafRay uses a much smaller scale than gmax". I actually plan to implement a "scale" attribute attribute in MIM, so you can get the loader to do scaling for you.

"The fact is...There's REALLY few formats with two UVs...indeed, apart from ASE and x....hmmmmm........ " Don't forget MIM. MIM could actually be fairly easily extended to many UVs, but there's not much point in that now.

What I was getting at with trying to get the lightmapper to generate more lightmaps is... a lightmap texture isn't really just one image. It's actually a whole lot of little images (lightmaps for individual faces) packed into one bigger texture. What I was trying to get was the lightmapper to fill up one full texture so it'd need to start a second one (it appeared that the lightmap.tga was almost but not entirely full), so that I could see how references to multiple lightmap textures were referenced in the .x file. This is sort of a nonstarter at the moment, since UU apparently doesn't reference the textures at all.


Electron:

IMHO, the best way to convert from most formats to MIM would be to write a loader from the format to irrlicht. Then we simply need an irrlicht function that can write an IMesh to MIM format.

I had indeed thought of using MIM as a way to persist Irrlicht's state (which could be quite useful!), but I don't think that's necessarily the best way to convert most formats to MIM. For one thing, if we already had a loader for every format we wanted to use... I don't think there would be nearly as much need for MIM!

I think that in at least some cases, writing a converter to convert from something to MIM or an exporter that converts to MIM will be easier than writing an Irrlicht loader for the given format, even though the two are functionally equivilant. I have several reasons for thinking this, and I'll only barely scratch the surface here with what really boils down to a single reason: The features of a given format do not always map directly to features of Irrlicht. The format may contain extra information or be missing information that needs to be synthesized. There may be several ways of mapping information in that format into Irrlicht, and no one method will be the best way all of the time. In that situation, I know I would prefer to manipulate the data as an intermediate step, leaving me with a "finished product" which is exactly what I want, rather than depend on the loader to get me from my raw material to my finished product every time the program runs.

My point being that I think MIM, as a file format to directly represent a simple Irrlicht mesh as Irrlicht uses it itself, has merits of its own. And it's practical to implement it now (obviously). The more complex features of meshes (i.e. animation) in Irrlicht aren't really a part of Irrlicht's core, as I see it... they're really more a product of its loaders. So, yeah, persisting those aspects of meshes couldn't be done gracefully now. I gather from what you said that the NX project is aiming to bring those from the loaders into the core itself, which I think is definitely a good thing if it can be done well.


RabidLockerGnom:

i would LOVEto be able to call animations on certain parts of the mesh (doors etc..), or basically just be able to work with actual pieces of the model rather than the whole darn mesh...lol

Yeah, I've had that sort of thing in the back of my head too, with some ideas of ways to do it... tie individual pieces of things to code. Just some ideas floating around. Of course, people do pretty well using the methods available now too.


On using two files to hold to sets of UVs:
An idea that's been touched on a lot is that of using two files each containing one set of UVs and bringing them together. This might be another example of something MIM is good for. It wouldn't be too hard to make an OBJ+OBJ -> MIM converter. Or X+X -> MIM, either (the only reason that'd be harder is because I don't currently have code to parse X files and my understanding of their details is currently limited). Of course, I could also modify the Irrlicht OBJ loader to load two OBJs, but this is kind of hackish.

Are there good workflows that lead to two OBJ files? CShop can lead to two .X files. Anything else?


On X files with two sets of UVs:
You know, I don't think I'd have too much trouble converting the Irrlicht .x loader to load two sets of UV coords, but it'd be a bigger pain to make it so it could load one OR two. That is, I could do it but then even .x meshes with one set of UV coordinates would waste space (8 bytes per vertex?) storing a second set which is never used. I've actually started this, but I suppose I'd want to do it all and do CXAnimationPlayer and maybe CXMeshFileLoader with templates. One thing I'd probably need to finish it is... an example of a lightmapped .x with referenced textures. Or maybe I'm overestimating the value of that. I don't know. Really, this is probably more easily done by converting to MIM, though you don't get the other features of .x that way if you need them. Which I don't. And, thus, my interest in doing it might be a bit low.


All right, more later...

[afecelis]

the screenshot looks nice, even in 16 bits!

MIM format seems great and seems to have a bright future with Irrlicht.

you can grab the Gmax to Obj exporter here; go thru the readme since the exporting process is a bit tricky :
http://www.danielpatton.com/afecelis/files/gmax2obj.zip

[Murphy]

Here's the Bedroom level that comes with CShop rendered in Irrlicht via an experimental CSM -> MIM converter.


The CSM format stores the lightmaps inside the CSM file, but my converter pulls them out. Currently it puts them in TGAs, but changing it to use JPEG or BMP or many other formats is only a couple keystrokes.

[Murphy]

More notes on CSM->MIM conversion:
Thanks for the link to the document on the CSM format, afecelis (and the OBJ exporter for GMax too). It would have taken a while longer without it, and I probably wouldn't have bothered.

The CSM format is actually a pretty good fit for both Irrlicht and MIM. It contains one texture channel and one lightmap channel, which is cool. Also, each mesh inside the CSM has flags to indicate if it has a lightmap (not all do -- in the 'bedroom' scene, objects like the bed/dresser/wall sockets do not). A mesh can also be flagged for vertex lighting (the aforementioned items are all vertex lit).

So far, I've only bothered to figure out the flag for whether a mesh uses a lightmap, so that I can apply the lightmaps correctly. However, there's some obvious room for expansion here. As I've mentioned, the MIM format can store lights (though this isn't used yet). If I converted the CSM lights to MIM lights, and made Irrlicht actually use them... and then honored the vertex lighting flag in the CSM file... well, obviously then you'd have both lightmap and vertex lightning for CSM->MIM converted scenes.

I'm kind of sad I don't have CShop (or the money for it).

[afecelis]

really? those are great news Murphy! that screenshot looks even cooler and it would be a major buttkicker if a CSM2MIM converter could be available.

It seems like your MIM format is very versatile, huh? So far I've seen it interact almost seamlessly with almost 4 other 3d formats!!!!

How about an-all to MIM-frontend GUI converter? sweet huh?

man, many thanks for your work!!! Mohaps also announced a CSM loader for Irrlicht here:
http://irrlicht.sourceforge.net/phpBB2/ ... php?t=5181

perhaps you guys could cross Ideas regarding to the format.

I'm glad the documentation helped; it was gently sent to me by Josh Klint (Cshop's author) and I uploaded it for you since I didn't understand anything

BTW; I'm going to let Josh know about the good news!!!

[Murphy]

If I'm doing it right, the versatility of MIM should mirror the versatility of Irrlicht itself to a very large degree. That's its whole design goal. But, well... you have to consider, MIM is not an interchange format. You will not necessarily be able to convert MIM to any other format -- while you often could, that's not the point of MIM. MIM is meant to be an "end point" format specifically for Irrlicht. The fact that MIMs look right in Irrlicht is a product of the converstion from whatever to MIM doing things specifically so that the result will look right in Irrlicht.

I almost just wrote a CSM loader for Irrlicht, but opted for the MIM converter instead just as a little showcase of MIM. I could write a CSM loader for Irrlicht that matches the capabilities of the MIM converter in maybe an hour.

However, this brings to mind another advantage to writing MIM converters as opposed to writing Irrlicht loaders for every format as proposed by Electron -- one of practicality. Irrlicht releases don't necessarily come very often. Releasing loaders that will be part of Irrlicht proper will require a release. And each bug fix or improvement won't show up until the next release (except on the messageboard which isn't really the best medium for updates!). This also puts a burden on Niko, who undoubtably already has more ideas for Irrlicht than he has time to implement.

I'm hoping Niko will choose to incorporate MIM into a future version of Irrlicht (and possibly use it as a basis for a native Irrlicht format -- you're more than welcome to do this, Niko. I only didn't name it .Irr because I didn't want to invade your "namespace" ). Then converters can be written that convert to MIM, and the MIMs will just work. The converters can be updated seperately from Irrlicht, and won't require recompiling when they're updated.

I'm certainly not saying MIM is the answer to any problem, I'm just reinforcing my point that MIM as a format itself has advantages.

It also has at least one disadvantage: It's fairly slow. This is really just due to its textual nature. If I ever find it to be a real problem, it wouldn't be difficult to create a "Binary MIM" format containing the same data with the same flexibility while loading much faster.

[Murphy]

BTW, if anyone wants to send me some dual .x files (i.e. one textured, one lightmapped), I'd take a look at converting them to MIM. The only ones I have to look at now are from CShop, and there's no guarantee that CShop and other things would necessarily do it in exactly the same way, so it'd be a good idea to look at some from different sources.

[vermeer]

I can very easily provide that....

gonna read the thread now, though...looks like you're doing a really incredible good job on this...

So....is it how I am understanding?

You are making available th possibility of loading a pair of x files, one with texture in uv channel 1, and another with the the lightmap in the also channel 1, and your converter actually mounts a MIM file with texture in channel1 and lightmap in channel2 ? WOAH.

If that is so, you are actually avoiding the need of use of Gmax. Gmax I was proposing because I don't know any other free package allowing 2 uv channels export and handle...But...if is just that way...then...You are actually allowing anyone with any freebie to produce two uv channels lightmaps in irrlicht! That is, once loaded in the engine...which rocks totally.

The only need is actually any tool to output a tga or whatever the format bitmap file... the lightmap. Blender can do, also, Slim shady, fsrad, deled, lumetools, etc. And of course all the great highend packages. Now, a tga is totally compatible, no matter what package or platform are ppl using..blender output perfectly x files, indeed, it canm output dx7 and dx8(jox, and ben versions, even) .But there are other linux packages allowing a simple x export with an uv channel 1 bitmap. In windows, there's metasequoia le, lithunwrap, zmodeller, deled, 3dcanvas, etc,etc...all freeware....yay.

But i have not read the thread...I read slowly as english is not my language...but is probably the stuff that has interested me more in months in Irrrlicht forums...!

I'll read it right now, as perhaps what you are doing is standard DP Pro way: loads actually twice the geometry...which is actually not so good, but well, for very low count levels, it could do...I'd rather prefer the professional way


Em, I'll read it all now

Congratulations!!

[vermeer]

not read yet,


just to mention I can provide that what you ask for from a HUGE quantity of sources...the x files, I mean, as I have lots of this freebies (besides comercial packages like xsi, purchased) and know well how to handle them.

I'll do so , to provide you with the best material.

[vermeer]

@MURPHY

[ Beware...I type as I read...probably you clear up issues at the end...my end conclussions are always the final concepts ]

"It's really banded, probably because of Irrlicht loading the texture as 16 bit"

Yes, sure. Actually there's a trick for that, i think, the coders here can easily tell you which is it

"This was done with a very experimental .X -> .MIM converter"

yet though it looks nice, very wysiwyg respect to wht I had done .

" In this particular image, I actually just converted the second set of UVs and stored them as the only set of UVs in the MIM"

humm...not bad solution, but it's needed an actual multiply mode or similar, to really produce the lightmapping effect... A merged texture wont do the same...

" since the first set wasn't much to look at anyway (no offense! Wink ). "

True XD ..The fact is that,,,well, I made so crappy the 1st uv channel(automatic UVs, indeed), that no texture would fit ok for a quick job, so, I just made a plain color texture. Reason why you don't notice any difference with just a texture+lightmap merged. Well, I think you ctually did not merged both...the solid one was slightly blue, to put something..I think u loaded directly the lightmap only in channel1...

ok, ok, I know, was a test...

"i.e. gmax->MIM instead of gmax->yafray->MIM"

hmm...not so sure, I'm afraid. Gmax files are binary, anyone would have tried, and there's a *huge* comunity of avid users, modders, and maxscripters trying to overcome the limits... SInce way long...what i have heard is it's binary and would not be an easy task...in case possible.Reason why all use just the listener maxscript window in gmax. (ie: yafray clear script route..)

"The yafray XML format also seems to contain the necessary info"

Looks so, and keeping it all clear and simple, imho

"Did you say you had a Max script to output OBJ from gmax? Where can I get that? "

of course, (just OBJ format cannot port multiple uv materials, but yes can smooth groups (yfray script can with autosmoothing value, quite useful too, have not tested with smooth groups)) I uploaded together with way more not easy to find graphic tools at gently provided Bal's space, I'll put you the link... :

Is in the first post of this page thread (is page 2 of TOOLS STICKY) :

http://irrlicht.sourceforge.net/phpBB2/ ... 3&start=15

"You quoted "Only real UVW Mapping is supported. UV mapping that is assigned through the material editor isn't seen by the exporter.". What's the difference?"


yep, it means that...well, you can do uv mapping using othe rmethod than the standard EDIT UVW,(Unwrap UVW modifier, you can add several, and set each as channel 1, channel2...and then in material editor, make a multimaterial, and asign to different uv channel each submaterial) quite similar to lithunwrap or other unwrappers...ie, you can make a cilindric uv map, and that wont be detected by the script. But I think you can bake those into UVW edit window easily. Anyway, even if restricted to to the tytpical edit uvs thing, it's quite enough an rather more powerful than any typical leditor in uv making, happily

Whatever the final procces is, with whatever the tool/s , I'll write a quick and easy tut on the workflow, like have done other times

"You also quoted "YafRay uses a much smaller scale than gmax". I actually plan to implement a "scale" attribute attribute in MIM, so you can get the loader to do scaling for you. Smile "

Nice... Is allway good Not crucial, I use to learn what scale nmber proportion is... but I love when the exporter has the setting itself

"Don't forget MIM. Wink MIM could actually be fairly easily extended to many UVs, but there's not much point in that now"

So...MIM does not support multiples UVs? How do you do lightmapping once in the engine, then..? I'm a bit lost in this point....

"On using two files to hold to sets of UVs:
An idea that's been touched on a lot is that of using two files each containing one set of UVs and bringing them together. This might be another example of something MIM is good for. It wouldn't be too hard to make an OBJ+OBJ -> MIM converter. Or X+X -> MIM, either (the only reason that'd be harder is because I don't currently have code to parse X files and my understanding of their details is currently limited). Of course, I could also modify the Irrlicht OBJ loader to load two OBJs, but this is kind of hackish.

Are there good workflows that lead to two OBJ files? CShop can lead to two .X files. Anything else? "

I REALLY like this type of idea. It provides the solution to ANY user, with practically any app out there (linux, mac, pc users) As all art grunt out there can output a model with one texture and one ste of Uv coords...the lightmap bitmap generation is a matter of using any of the free lightmappers already out there, or Blender bake lighting (a bit complex) workflow, though radiosity. The fact is...at a time you are opening th edoor to any highend app...till now totally closed...as no way to import a 2 channels file...even x was not having the feature in some of the highend...this way everu highend one has the option, too. The two worlds at a time, from any platform.

OBJ is BY FAR more universal....It does not port multiple UVs, being it the main disadvantage, but in your method, this does not matter happily.
the only thing is you say OBJ is not complete in Irrlicht?? I thought it was...it'd be a pitty...

Many x exporters export in dx 8.0 export...that means 65,000 tris limit ...quite huge, but...you know... dx 8.1 allows more..-anyway, some modifications are yet needed in irrlicht to overpass that limit, but will come surely- Anyway, that count is quite high for get good performance now, but one must do things thinking a bit in th efuture, and machines evolve too quick....

So OBJ, for that, for support of smooth groups info, for WAY easier syntax than X, and for universality (any free tool out there supports it, quite mor ethan X, even being x such a standard)

That is, I'd prefer OBJ, if the generation of two UV channels in MIM, you can do it from the OBJ+OBJ simple files(from their 1st channels)...

The list of the ones supporting OBJ..is quicker done if I put the ones that do not support...and I have to think hard to find one..lol.

if you already have the stuff made for X, great also, as I said, there are way fortunately to output a simple static X from any package , any platform...and it ports a feature not carried by OBJ: vertex colors. While it is rare,some people use those...I don't like vertex colors, as usually need a huge res to get something nice...much better just to paint some stuff even in 2d in the lightmap (like coloured lights for a bulb, etc) bitmap Pixels are way more accurate and don't force increase of polies, so performance does not fail..So, x is god, OBJ is better

the problem is...
"Of course, I could also modify the Irrlicht OBJ loader to load two OBJs, but this is kind of hackish."

Hmm...I see, There could be a barrier there, then. Ok then, a X+X = MIM two UV, is freaking good to go. I will provide loads of little pargraphs in tools+faq sticky to make the ppl know the HUGE workflows and freebies they can use for this. Indeed, it opens a load of possibilities. from zero to 100, I'd call this.

Only thing is...well, yep, seems you do the good thing: generate in MIM or in engine two uv channels, not like dbpro that duplicates the mesh ,loads twice the polies!

"Are there good workflows that lead to two OBJ files? CShop can lead to two .X files. Anything else? "

LOADS. Man, you'd be amazed. You can really easy convert an OBJ to x, even. Ways... SKIP ALL WHAT IS IN GREEN IF YOU DONT WANT TO READ ABOUT *SOME* OF THE AVAILABLE WORKFLOWS YOU WERE WONDERING ABOUT FOR OBJ--->X ....


-Lithunwrap.Total freeware. (I uploaded also to Bal's site) Uv mappng tool that alos allows all sort of conversions b directional between x, cob, 3ds, obj, etc...
-metasequoia LE. Free for non comercial projects.Will load an OBJ, export as X.
-Blender. Will load an OBJ (also exports it) , or a mountain of formats more, and can export 3 flavours of X files. Multiplatform (mac, win, linux) You can even only use as a converter.
-Anim8or , will allow loading an obj, and doing autosmoothing value.(I know, no x export, just to mention it as another free tool)
-Milkshape...non free, but seems half the world has it...has an extremly good OBJ support, giving access to not just autsmoothing info, great fixing geometry tools, export as X, obj, and every format on earth. I have it purchased also.
-Max will load any OBJ and export as x .Both plugins are free, and as easy to install, as to copy the plugin to plugin folder..: ) versions for every max version.
-Gmax...will load OBJs...no export X. But U can export again as OBJ with the script I put in Bal's site (dunno who is the author of script) , and later on make a conversion with any of the tools.
-there's a non days or feature limted version, neither illegal, of old 3d Exploration(now deeep exploration) , also in tools sticky, th elink. It can import OBJ, export X.
-k3d, multi OS, linux, mac, win...etc....can import an OBJ, export as X.
-zmodeller exports x files, is a car oriented modeller, but can do anything...Some people love it..you can use it even only probably as a converter...I suppose it has the main formats EVERY package out ther have...OBJ, and the crappy, bad, terrible *.3ds....
http://www.zmodeler2.com
(man he's started an skeleton system!)

Well, those are just a very few samples, and a load of comercial software are missing... insert [here] the highend package able to load OBJ and export X and you'll find it works with any

BUT...I rather, rather prefer if you allowed loading OBJs, is more known and used, even than X, and has no polygon limit... plus the sweet smooth groups (Wings3d can ouput an OBJ with smooth groups, though its workflow is cleverer: hard egdes are set directly by the artist) support in that ascii list of coords... (basicly, anything u see with starting with an "S" and blank line...is all the following is in one smooth group , vt for textured vertices, etc...)

OBJ supports, among the main features:
Uvmapping, smooth groups, smoothing autosmooth info (is probably the same, code-wise) , huge meshes...and material links are stored in another material file , the *.mtl (sadly some tools don't output it (blender ideasma plugin DOES it , greatly) ...just like you have seen several tools don't put the material link in x files) ..in the *.mtl is stored then the path of the maps...I think it can port there also specularity values, other maps, etc...well, if the tool supports it and tyhe user decided to export it...(usually the user doesn't know those values)

ANYTHING, can output OBJs And I am speaking about comercial, and free, opensource or freewares....ALL...

Let's continue with the actual reply, lol... Sorry if I'm..."verbose".

"On X files with two sets of UVs:
You know, ....
.... One thing I'd probably need to finish it is... an example of a lightmapped .x with referenced textures"


hmmm...I am afraid i can't provide that, with my actual software..anyone with Max,(my trial ended, i only set it up for solving here workflows methods for Max users with panda X exporter) ,knowledge of lightmaps, and the panda exporter, could output it. Dunno if there's anyone able for that.

I like rather a lot your other OBJ+OBJ option, or even X+X option (if OBJ is not possible) as opens way mor ethe field to users that can only use free software.

"Here's the Bedroom level that comes with CShop rendered in Irrlicht via an experimental CSM -> MIM converter. "

Nice.

Though I don't have purchased Cshop, not any others, but is nice to have one more option.

BTW, Gile[s] is way beter as lightmapper, in quality.(and Max, LW, etc)

seems definitely your irrlicht install is in 16 bits...

"TGAs, but changing it to use JPEG or BMP or many other formats is only a couple keystrokes."

I prefer TGA than jpg

"A mesh can also be flagged for vertex lighting "

Nice...though, I'd vote for the free workflow of the OBjs as an universal solution...(free, non MS Windows only...etc...)

"I'm kind of sad I don't have CShop (or the money for it)"


Neither many of us... The objs solution, allows all that, too... In giles, you can do coloured lighting in the lightmaps , too...you could even paint em manually in the 2d lightmap...with a free 2d tool.

Also, as I mentioned, I prefer to have full flexibility and modelling power, an d full power in radiosity lightmaps generation..both not there in cshop, neiother in other just-level editors... Is much more powerful go the max way, of free powerful obj modeller like WIngs, metasequoia, etc, and great lightmappers like, max, and giles, or the free radiosity one, fsrad.

"It seems like your MIM format is very versatile, huh?"

I think what is versatile is Murphy

well, is could to add an extra tool like chsop...

I only wish the powerful way would be also available

Murphy, I agree with your line of converters to MIM, instead of direct loaders

"I'm hoping Niko will choose to incorporate MIM into a future version"

I hope!

"lso has at least one disadvantage: It's fairly slow. This is really just due to its textual nature"

well, Irrlicht was reading actually text files directly, no? X files allowd in irrlicht are text....and they keep being totally necesary, as is the way to load an animated character in irrlicht...And bones and weights is too complex to code twice...

"BTW, if anyone wants to send me some dual .x files"

Forgot that.

I'll do right now, and OBJ samples, too, and from different tools...now...
So...as I think is better, this instead of the Gmax+yafray way (actually , Gmax can output OBJs )




Afecelis mentioned stuff i'd like to also read you both...(and anyone else, hehe)

"
MIM format seems great and seems to have a bright future with Irrlicht. "

I'm totally convinced

"the screenshot looks nice, even in 16 bits! "

gile[s] is great, even when an artist like me use it crappily
Max and final render, or brazil, etc, can do great wonders...with the OBJ+OBJ solution, or similar, you'd take teh Max generated tga, and just link it to an OBJ ....Awesome...

"you can grab the Gmax to Obj exporter here; go thru the readme since the exporting process is a bit tricky :
http://www.danielpatton.com/afecelis/files/gmax2obj.zip"

Hmm..is the same that i uploaded to Bal's site? it was quite simple to use...

Iuse my mouse trick...it's limited to a certain portion of characters, very small, pero copy, so what ppl do is copy several pargraphs...What i do is...a keep pressed the LMB as I select some first lines....then I press my middle mouse button...it will then start to scroll at uber speed down....as it has middle support by windows...I mean, appears that multidirectional cursor..dunno if all mices do this...it scrolls way much faster than normal selected(keeping allways left and middle(if u have the feature) pressed!) , though u could do it just with standard way.....without dropping any of both buttons....once it reaches the end (several hundered of thousands of polies can lead to a minute or so in scrolling) you hit once RMB, righ mouse button I mean, and it pops up the context menu, select then "copy" ...clicking again in rmb over "copy", I mean. If I remember now welll.

bang, copied.

Is a limit put in the maxlistener...for some reason they left that as a possibility, but haven'0t see it documented in any place...

you see, actually I REALLY prefer to avoid using Gmax, and your OBJ+OBJ (or x+x) method ---> 2 uv channels MIM, actually allows saying good bye to gmax, though some users love it and will keep doing the OBJs with it (Gmax has not go x export, though they could use 3d exploration or any of the mentioned to convert to x)

[Murphy]

vermeer:
Thanks for the loads of info.

"This was done with a very experimental .X -> .MIM converter"

yet though it looks nice, very wysiwyg respect to wht I had done .

...

Well, I think you ctually did not merged both...the solid one was slightly blue, to put something..I think u loaded directly the lightmap only in channel1...

Yeah, the experimental part was just that it isn't fully automated -- it required some "manual" work, since I wasn't parsing the .x files correctly. The real thing to be learned here is that I can, in fact, grab the second set of texture coordinates out of an .X file. It's really easy. (For those who care: The FVFData section for this file was of FVF type XYZ+TEX1 (258) and contains NumVerts * 2 32 bit integer values. These values are the bit patterns for alternating 32 bit (single precision) U and V texture coordinates. Quite easy.).

Yes, loading the lightmap directly to the first channel is exactly what I did, but doing it the correct way (i.e. actually as a lightmap) wouldn't have been much harder at all. As you said -- it was a test.

i.e. gmax->MIM instead of gmax->yafray->MIM"

hmm...not so sure, I'm afraid. Gmax files are binary, anyone would have tried, and there's a *huge* comunity of avid users, modders, and maxscripters trying to overcome the limits... SInce way long...what i have heard is it's binary and would not be an easy task...in case possible.Reason why all use just the listener maxscript window in gmax. (ie: yafray clear script route..)

Well, I actually have some experience reversing file formats, but I was actually thinking along the lines of writing an exporter for gmax, not a file format converter. But, as you've said... there won't be any real reason to do this.

"You also quoted "YafRay uses a much smaller scale than gmax". I actually plan to implement a "scale" attribute attribute in MIM, so you can get the loader to do scaling for you. Smile "

Nice... Is allway good Not crucial, I use to learn what scale nmber proportion is... but I love when the exporter has the setting itself

This is now implemented, though part of it may change (because it works in Irrlicht, but I don't think it's actually valid XML). There are actually two scale values. One is applied to the entire mesh, and the other can be set individually for each mesh buffer. I also added xyz offsets for each meshBuffer, so you can translate a meshbuffer without actually touching the vertex coordinates.

"Don't forget MIM. Wink MIM could actually be fairly easily extended to many UVs, but there's not much point in that now"

So...MIM does not support multiples UVs? How do you do lightmapping once in the engine, then..? I'm a bit lost in this point....

Well, it supports two. Because that's as many as Irrlicht can really handle, as far as I know. I mean, there's no reason you couldn't add any number you wanted in the file, but the current version of the loader only uses the first two.

"TGAs, but changing it to use JPEG or BMP or many other formats is only a couple keystrokes."

I prefer TGA than jpg

Depends on the use, depends on your preferences... but it doesn't matter -- through commandline switches for CSM2MIM, you can select TGA, BMP, PNG, or JPG.


Where things are now
I think the first versions of DMF2MIM and CSM2MIM are pretty much done.

I was working on code to work with X files for use in programs like X2MIM (one file with 2 UVs), XX2MIM (two X files with 1 UV each), XX2X, etc. But I had a sort of gnarly crash and I think DirectX is now acting weird! A reboot would probably fix it, but I decided to fool around with another project instead (if it goes anywhere, I'll be sure to post about it, as I'm sure it'd be of at least some interest).

With some more thought and your input, vermeer, I've decided that my next MIM-related work will be on an OBJ+OBJ to MIM converter. Just to make this clear: this will work by merging the two sets of UVs into a single MIM, not by duplicating geometry. I've got blender, so I thought I'd probably start there. I need to work out the proper workflow for producing lightmapped OBJ+OBJ. Anyway, send along some OBJ+OBJ demos when you have a chance. I wouldn't mind a super quick howto (or a pointer to one) on producing lightmapped OBJ+OBJ in blender either...

[afecelis]

Whoa Murphy! DMF2MIM and CSM2MIM Man! Gr8 news!!!

I was about to send you a a 2 X file (lightmaps-textures) but then I read you wanted something different from a Cshop exported X file, and that's what I have, so I guess an X exported from Giles would be a good test.

So here's where our dear friend Vermeer comes in!!!!

[Murphy]

I was about to send you a a 2 X file (lightmaps-textures) but then I read you wanted something different from a Cshop exported X file, and that's what I have, so I guess an X exported from Giles would be a good test.

Hehe, yeah, I already have an X+X from CShop (one was included with the demo). For the moment, I have decided to go the OBJ+OBJ route anyway. Thanks, though!

Hmm... I just glanced at the gile[s] page and noticed it doesn't support OBJ output! That's too bad. Does it output two X files, or just one (with two UVs)? I'd like to make using gile[s] with MIM easy. If it outputs two single UV X files, then converting those to OBJ and using the OBJ+OBJ to MIM converter wouldn't be hard. Though I feel like it's been said it exports a single X file with two UVs. Someone clear this up? HMMM...

[vermeer]

GREAT!

So, deled (free lite version avilable) , cshop suported!! those are two widely used editors.. Not my cup of tea, but they are for many people, so great


Ok, don't worry, gonna provide you all th efiles and methods.

Exported OBJ with Anim8or, not valid. As Anim8or will not export mtl files of obj, so...no materials info.

metasequoia le (not allowed for comercial use) does not support OBJ export, only import. So I only made the x export in this one.The x file is exporting the image name inside Is dx7 , or previous, I am afraid.

blender dx7 basic native export wont export the texture...it seems....
dx8 one...well, not the native... ben's latest from his site, or my preferred Jox modified version...


Hum...the blender workflow is really complex for non initiated...and besides..I forgot what was needed..now not getting the texture names in the x files..only materials settings...

yep, Is way better the OBJ rout, by all means... Besides it strips texture information (link) in an apart file (*.mtl)

I'll make u all sorts of OBJ exports, and several x ones, I have made quite a fewa already..later on I will upload

[vermeer]

phew, heck....pant...


Blender was not using the USEMAP in mtl exproted file...


Now...not the native, nor even any of the jms or ideasman were working...

finally found one very recent, from JMS, that works, exports the mtl....hechk, anyway, it's really easy to write by hand in note pad just map_Kd 046pierres.bmp , but hey, was looking for one that actually works automatically...

One thing to note...i think mtl exports never work with full path...so, better put the scene in native format, the exported obj, and the imported textured...ALL in one folder.

This way it will allways work...

Ok, sorry, I gotta go now....but...

For now, fully working :

- blender (models ready to upload)
- Ultimate Unwrap (idem)
- Lithunwrap (the tool I more advice, of course I prefer its comercial version,Ultimate Unwrap) A freebie u can download at Bal's space, in tools sticky. Also exported and fully working (checked that JMS obje exported models loaded greately there, with texture attached)
- Milkshape.
- 3d exploration 1.5. that version that all gmax comunity is using to convert md3 files to x. It does not ends with a trial period, nor limits features. It only reminds you to buy from time to time...

All those are working even importing th eOBJ with texture attached, and exporting the obj with a correct mtl texture referenced.

* Crossroads free converter do not generate the mtl file
* Anim8or does not generat th emtl file
* hmmm...sadly, Gmax does not output the material info into a MTL file. Alll the other info, it does.

Anyway, there's enough fully supporting tools (I know Max habware.at exporter works, too) for free, and some of the most used shareware ones, in every tiny feature needed, so...

I'll upload a partial sample of it, in case you need at least some material to start work now, but later on I'll provide a more complete one. It's just that i need t ogo now, and...I have made onlyvery few complet set ones: that is, in most I have checked only with one file, as is identical, is only matter of asigning another texture, and though in all freebies thi sis very quick (even in Blender, what gives problems in blender is other stuff..But JMS script seem to solve it) it was enough to know it was working an dfor u to see the syntax. Though, I'll provide complete pairs later on.

Also more packages...U don't know how many out there...


Like in most formats, though (3ds, obj, x...) what is not so common is that it exports in every package the correct texture reference, but it's quite a bunch already, and I know I'll find many more later....


Uploading also the not-so-easy to find jms last update...it's great.

Uploading this samples to th etemporary free space I got recently, and JMS blender obj script, to bal's site, together with latest ideasman obj blender scripts, as for some reasons, in some occassions, u maybe more interested in using his. For now, the one that seem solves it, is JMS.Though, u need quite knowledge on the facts in Blender to make this output work. As is the free and stronger multiplatform package, I'll make a detailed explanation later on, also.

Lithunwrap is thousand times easier. Ultimate Unwrap is eaiser, and incredibly powerful. Indeed, is the successor of that freeware one.

I'll ouput also an XSI exported natively OBJ from my purchased XSI 4.0 Foundation.if someone has a Maya, please, add the export, too.
i don't have Lightwave, but could decide to try to download Max7 trial, and see if my modem can eat it this weekend...eeek. The trial is full, so can see th eporbs or advanatages of the good x and obj exporters avilable for i t...and tell here.


OK....please, grab JMS latest OBJ script here....grab the othe OBJ script also, u never know...

HERE

argh...upload limit for the OBJ samples, and gotta go now...later....