Murphy's Irrlicht Mesh file format

[mohaps]

i am working on a gile[s] loader for irrlicht if you are interested...

[vermeer]

Thank you , that's very kind of you. Well, the fact is I like the OBJ2MIM solution as I have OBJ export also in a number of packages like Blender , XSI, etc..

Yet though, it is allways handy, for example: I use several OBJ and 3Ds exporters for Blender, as well, as sometimes I've done conversions with Milkshape, sometimes with Ultimate Unwrap. As there's allways some uses that are done better with a workflow than another, and also viceversa.

So, all that kind of stuff is very welcome.

I haven't posted on your threads of the tools you are giving, and though as I said I am not for the moment (could be in a future ) in any Irrlicht project, what you all (Murphy, you, Etcaptor, etc) do, becomes very useful for Irrlicht comunity and in general for the open source engine.

[Murphy]

gile[s] has its own format?

I realize I've been letting this project slide, so I've decided to do a simpler version of OCT2OBJ for the time being. Basically that just means you'll have to run it twice -- once to get the lightmap and again to the textures. And no automatic OCT to MIM step.

It'll be a bit more of a pain, but it'll work.

[vermeer]

"gile[s] has its own format?"

Yup, and it's great if mohaps do a loader, but there are strong advantages of an OBJ to MIM thing, as I was saying, for it opens the door of: a) multiple high end packages that are able to produce great lightmaps b) practically any free or cheap package that can't output nor work with 2 UV channels, the posibility of produce it with the 2 objects trrick, while having the great OBJ features (smoothgroups, several materials per object, no polycount limit, etc) I can think of several situations when I may be not interested in a direct Gile[s] output. Even more, the OBJs that Gile[s] output, I can touch them in Milkshape, or Ultimate Unwrap , or Lith, a direct import would not allow me that. yet though it has other advantages.

"I realize I've been letting this project slide,"

English is not my first language, so , I don't understand that, but I think you have worked a lot in the project. As I was saying, the OBJ2MIM, the MIM format itself for irrlicht, the OCT2OBJ (allowing GI lightmaps for free! ) are simply great.

As far as I see it, what then they gotta do is use OBJ2ANT Trancos tool, having set the emitters polygons with a different material, so: use obj2ant to get the mat file from that retouched OBJ, in the ascii mat file set a value for the light intensity/color (usually 1,1,1) like explained in Trancos readme, load the ant in Trancos modified FSRAD, export to OCT+lightmap. Then OCT2OBJ, then asign an standard texture to a copy of the lightmap OBJ, previously making some UVs for the texture channel (not just using the one generated for fsrad also for texture, would not be good for the type of slicing it does) .Finally, use OBJ2MIM I think is quite more simple than it sounds in thi sisngle paragraph. I have made these steps,(well, not oct2obj, nor OBJ2MIM ) and are not hard.

" so I've decided to do a simpler version of OCT2OBJ for the time being. Basically that just means you'll have to run it twice -- once to get the lightmap and again to the textures. And no automatic OCT to MIM step."

Oh, then...well, then no need to do the UVs after you have lightmaped? I was counting on just they may import an untextured and non UV mapped OBJ, trusting on generate the UVs in Lithunwrap or Blender once they have exported the oct, and then to obj with your new tool. This way could be possible too. Anyway, the only interesting way would be if Fsrad would allow the preview of radiosity but with basic textures loaded, as to see how light and shadows look together with textures. But if not possible exactly so, probably it wont matter much if radiosity is generated first, and texture UV channel1 (actually they'r all time dealing with channel1, is mim which will have two) only in the exported oct2obj OBJ (well, in a duplicated file of it )

Perhaps I am missing something, or the workflow could be like that?

The workflow keeps being free, of very high quality, and not really complex. Wha i like of it is, having the final thing in OBJs you open the door to solving zillions of prblems arised usually in 3d worrks in the artist side, which weren't possible with just LMTS ouput (direct to engine) , besides, it's really good to make a GI lighting solution available for free to everybody
Of course, is not totally comfortable, but Blender is quite harder than all this, and people use it

[puh]

I would like to ask is this the final way of getting lightmapped map in IRR:

1. Create 1.obj+1.mtl with UV for texturing
2. Copy this to 2.obj+2.mtl
3. Translate 2.obj+2.mtl->2.ant+2.mat using OBJ2ANT by Lord Trancos
4. Modify 2.mat
5. Use 2.ant+2.mat in FSRad by Lord Trancos and get 3.oct
6. Translate 3.oct->3.obj+3.mtl using OCT2OBJ
7. Combine 1.obj+1.mtl with 3.obj+3.mtl using OBJ2MIM to 4.mim
8. Load 4.mim into IRR

vermeer, I couldn't understand correctly:

then asign an standard texture to a copy of the lightmap OBJ, previously making some UVs for the texture channel (not just using the one generated for fsrad also for texture, would not be good for the type of slicing it does)

what you mean here?
Anyway, could you please show me why I can't use LMTS file for all that? Technology the same, but I don't need step 2 and 7, and load .lmts straight into IRR. All textures UV remains, lightmap UV generated by FSRad.

The only pozitive possibility would be to create lightmap UV by hands and force FSRad use this UV instead of generating a new.

[Murphy]

I would like to ask is this the final way of getting lightmapped map in IRR:

1. Create 1.obj with UV for texturing
2. Copy this to 2.obj
3. Translate 2.obj->2.ant+2.mat using OBJ2ANT by Lord Trancos
4. Modify 2.mat
5. Use 2.ant+2.mat in FSRad by Lord Trancos and get 3.oct
6. Translate 3.oct->3.obj using OCT2OBJ
7. Combine 1.obj with 3.obj using OBJ2MIM to 4.mim
8. Load 4.mim into IRR

Using my current workflow, I think it's much easier than that.

1. Create and texture a model using whatever tool. Save as anything Blender can import (or just make it in Blender). Call this 1.whatever.
2. Add lights in Blender, and exporter, export 2.oct.
3. Run FSRad, creating 3.oct.
4. Run OCT2OBJ twice and get a textured file (4a.obj) and a lightmapped file (4b.obj).
5. Use OBJ2MIM to combine 4a.obj and 4b.obj to 5.MIM

You could use a workflow similar to the one you describe as well (I think you've got a slight error), but I think mine is simpler and easier to get good results most of the time. In particular, because you don't need to edit materials by hand and, instead, get to light in it Blender and get a bit of a preview. It's easy to repeat this process and continue making changes.

[vermeer]

"what you mean here?
Anyway, could you please show me why I can't use LMTS file for all that? Technology the same, but I don't need step 2 and 7, and load .lmts straight into IRR. All textures UV remains, lightmap UV generated by FSRad.

Idea The only pozitive possibility would be to create lightmap UV by hands and force FSRad use this UV instead of generating a new"


As far as I know, there were problems to get the texture uvs in channel 1 and have a uv channel2 with the lightmap with lmts workflow...

besides, any additional retouch is easy to do in OBJs, but with LMTS you're tied only to trancos tools. While this maybe enough fo rmany cases I think more flexibility is better. There are loads of situations in which you wish to have a pair of OBJs previous to a MIM 2 uv channels compile.

" Using my current workflow, I think it's much easier than that.

1. Create and texture a model using whatever tool. Save as anything Blender can import (or just make it in Blender). Call this 1.whatever.
2. Add lights in Blender, and exporter, export 2.oct."

Ouch. I thought you finally were not making the blender exporter...oh, I see, you were not making the ent exporter.
Then it's even simpler than I explained. yet though, the way I explained, can be used with other tools than Blender.

" 3. Run FSRad, creating 3.oct."

Whay the naming "number.*" ? Ok, you create one oct here(firstly I understood u created 3 octs , reading that sentence )

" 4. Run OCT2OBJ twice and get a textured file (4a.obj) and a lightmapped file (4b.obj)."

How do you get the texture and uv channels1 from the oct file? thought they were lost...so, initial Uv 1 texture coords, base texture ones, kept preserved in their way blender-->fsrad--->oct ? Well, the workflow is even better than I thought.


" 5. Use OBJ2MIM to combine 4a.obj and 4b.obj to 5.MIM "


If it is just that way, is really simple.

[puh]

As far as I know, there were problems to get the texture uvs in channel 1 and have a uv channel2 with the lightmap with lmts workflow...

I found no problems. The only thing is that I convert all tga's to png's, and hack a little bit the final lmts to change "tga" to "png" with hex-editor.

There are loads of situations in which you wish to have a pair of OBJs previous to a MIM 2 uv channels compile

But don't forget - it must be absolutely equal files. One vertex more - and no mim will be produced, isn't it? Or even worsed - if vertex order changed - what will happen?

Whay the naming "number.*" ?

It's just in my example.

How do you get the texture and uv channels1 from the oct file? thought they were lost...

He mean 4a.obj from 2.oct, which was converted directly from Blender.

Well, Murphy, your way seems to me good also, same as Lord Trancos approach. Anyway, any new updates for Irrlicht are welcome, and vermeer is right - more ways - more flexible - more freedom.

[vermeer]

" There are loads of situations in which you wish to have a pair of OBJs previous to a MIM 2 uv channels compile

But don't forget - it must be absolutely equal files. One vertex more - and no mim will be produced, isn't it? Or even worsed - if vertex order changed - what will happen? "


Yup. is not a matter of add an extra vertex I mean, you will be just picking the OBJ in Lithunwrap (for example, it is free and we have it hosted now at Bal's site, and is way easy to use) and asigning it a material Lith does not change vertex order. Also, if you re save just same copy from Lith, it's impossible it would be different: load the obj, just change the tetxure name to make the two versions. Couldn't be more easy. The changes I was referring to would be to the same OBJ. You just save twice in Lith ....after the modifies. Don't forget is just really one object with one uv channel one texture. You save twice to output the two OBJs for mim and so avoidng ur tool needing two uv channels, which is not common. Lithunwrap allows save UVs and reimport them I have tested. So, while is not necesary, it gives quite a lot of extra editing, like exchanging UVs between objects, changing materials, materials settings (mtl gets written) , etc. As ur saving actually same mesh, UVs and material settings wont be a problem.

Added to this, the fact that OBJ2MIM offers a *huge* advantage ...any package can ouput an obj witha texture in channel1. Even if you are quite expert with Blender u could use certain baking radiosity lighting to UV texture script that is for Blender in Blender org. It's only posted as a paragraph, and I haven't yet tried it. I have not recommended it as the proccess is more complex and limited by far -imho- than all this ways, and has its problems.

Not only that. Lightwave, Maya, Max, XSI, can export as OBJ and bake lights and shadows into a UV tetxure, and then you asign it to chanel1. Simple.

So OBJ2MIM gives direct access for lightampping in Irrlicht in ALL those packages, even not requiring the user the extra knowledge of his/her package on how to generate a second UV channel and multitexturing materials. It supports perfectly actually also my lovely Gile[s].

Quite a lot of advantages.

[Murphy]

But don't forget - it must be absolutely equal files. One vertex more - and no mim will be produced, isn't it? Or even worsed - if vertex order changed - what will happen?

What will happen is that OBJ2MIM will tell you the meshes are not equal and will not produce a MIM.

How do you get the texture and uv channels1 from the oct file? thought they were lost...

He mean 4a.obj from 2.oct, which was converted directly from Blender.

Actually, no. OCT can hold both texture and lightmap coordinates. The problem was with ENT, which (maybe) couldn't (until LT added it?). My Blender exporter exports an OCT with correct texture information (materials and coordinates), and no lightmap coordinates (obviously). Then you run FSRad, which results in an OCT with correct texture AND lightmap information.

Then you run OCT2OBJ twice on the FSRad-output OCT file. The first time, you get an OBJ with correct texture information. The second time you get an OBJ with lightmap information.

Then you run OBJ2MIM to convert those two OBJs to a MIM.

Here's a screenshot showing the result of this workflow using the latest versions of my OCT exporter and OCT2OBJ, which I've just finished:


It's possible to go straight from OCT to a complete lightmapped and textured MIM -- I just haven't written that converter. It's also possible for OCT2OBJ to make both OBJs at once (instead of making you run it twice), but I'm probably not going to end up having that done for the first release.

Lithunwrap allows save UVs and reimport them I have tested. So, while is not necesary, it gives quite a lot of extra editing, like exchanging UVs between objects, changing materials, materials settings (mtl gets written) , etc.

Yeah, you could retexture the entire textured OBJ, and then run it and the lightmapped OBJ (from OCT2OBJ) back through OBJ2MIM. You're PROBABLY better off retexturing the ORIGINAL OBJ, but it's still some added flexibility.

Well, Murphy, your way seems to me good also, same as Lord Trancos approach. Anyway, any new updates for Irrlicht are welcome, and vermeer is right - more ways - more flexible - more freedom.

I think the real advantage is the ability to easily and somewhat interactively place lights in Blender. From there, you're straight into FSRad. Then you can go back and muck with the lights, and straight back into FSRad.


Of course, I could also write an OCT loader for Irrlicht and then you could save straight from Blender to OCT, run FSRad, and then just load up FSRad's output in Irrlicht. That'd be a REALLY fast Blender/FSRad/Irrlicht workflow, and may be worth persuing. It would also let you export a non-lightmapped OCT from Blender which you could just load into Irrlicht to preview and then lightmap it later.


Anyway, the point of MIM isn't just to have an FSRad workflow, that's just one application of it that I've chosen to persue.

[TheRLG]

Wow, this project is looking amazing! I'm so glad you've taken this up. Good luck, keep up the good work!

[vermeer]

"Actually, no. OCT can hold both texture and lightmap coordinates. The "

great, was a bit unsure on that.

"problem was with ENT, which (maybe) couldn't (until LT added it?). My "

Yes, looks like that's so. I am afraid I just didn't pay much attention to it in the moment it was released...I was buying Gile[s]

"Blender exporter exports an OCT with correct texture information (materials and coordinates), and no lightmap coordinates (obviously). Then you run FSRad, which results in an OCT with correct texture AND lightmap information."

Perfect, absolutely great. i read all this post, and people can be happy, there's a way to produce with ease finally a high quality lightmapped scene with two uv channels, using the optimized MIM format

"Then you run OCT2OBJ twice on the FSRad-output OCT file. The first time, you get an OBJ with correct texture information. The second time you get an OBJ with lightmap information."

It seems *really* easy. Cool

"Here's a screenshot showing the result of this workflow using the latest versions of my OCT exporter and OCT2OBJ, which I've just finished:"

WOAH. See, great quality, totally free tools. (once again, people excuse the bad quality of the artist work ,that sample level I made XD without actually texturing)

" It's possible to go straight from OCT to a complete lightmapped and textured MIM -- I just haven't written that converter. It's also possible for OCT2OBJ to make both OBJs at once (instead of making you run it twice), but I'm probably not going to end up having that done for the first release."

I don't know, as you have explained , it sounds really dumb easy already. And as I was telling you, maybe a coder doing art, may feel safer if all is direct: ie, direct to MIM or whatever, but I like that detail of having access to the two OBJs *a lot*. Experience tells me even if you get in the future and even more easy workflow, you should not remove that other one as an option. I know many people would love t ohave that flexibility. (swapping UVs with Lithunwrap is just an small example. )

"Yeah, you could retexture the entire textured OBJ, and then run it and the lightmapped OBJ (from OCT2OBJ) back through OBJ2MIM. You're PROBABLY better off retexturing the ORIGINAL OBJ, but it's still some added flexibility."

I see there are very weird scenarios, where when these things are possible, can avoid to throw a lot of work to the paer bin
Of course, if in the future is added even more direct access as an option, sounds also great

"I think the real advantage is the ability to easily and somewhat interactively place lights in Blender. From there, you're straight into FSRad. Then you can go back and muck with the lights, and straight back into FSRad."

Yup, and settings some lights is really easy in blender

"Of course, I could also write an OCT loader for Irrlicht and then you could save straight from Blender to OCT, run FSRad, and then just load up FSRad's output in Irrlicht. That'd be a REALLY fast Blender/FSRad/Irrlicht workflow, and may be worth persuing. It would also let you export a non-lightmapped OCT from Blender which you could just load into Irrlicht to preview and then lightmap it later."

Sounds extra cool yet though, I answered this paragraph above (I made an error with the quoting) It's cool to have access to the two OBJs, and see who can we deal with the workflow (sure there are new advantages, I just haven't tested it) , while the extra advantage of having "plug an play"(but this, for real ) workflow, would benefit several other lots of users. Yet though, I think is quite simple already.

"Anyway, the point of MIM isn't just to have an FSRad workflow, that's just one application of it that I've chosen to persue."

Yup, having a complete engine format, supporting features like multiple Uvs, and others, sounds really good.

I hope users start to get familiar to all this, as imho is a great advance for irrlicht.

[afecelis]

whoa guys! I'm away for 5 days and all this happened?

I'm missing a ton of fun here!

great work dudes!

ps. @Murphy: that reinterpretation of Vermeer's map looks amazing!!! Nice lightmaps; triple kudos man!

[vermeer]

yup, if u look at it carefully... proyected shadows with soft borders, area shadows and type of lighting, gi ambience... Imho, way a lot of quality with Fsrad. More than enough. (i suppose then it is possible coloured lighting?)

[Murphy]

ps. @Murphy: that reinterpretation of Vermeer's map looks amazing!!! Nice lightmaps; triple kudos man!

Glad you liked it. It only took a couple of minutes in Blender. Just a super quick texturing and a few colored lights.



After talking about an OCT loader for Irrlicht the other day, I decided it would be handy, so I threw it together today.

If the OCT it loads has lightmaps, it'll be lightmapped. If the OCT doesn't have lightmaps, though, I've included a function which will use the light info in the OCT to create dynamic lights.

As an example, I took the OCT file that I exported from Blender to make the previous screenshot. For the previous screenshot, I then ran the OCT through FSRad. For this one, though, I loaded it up in Irrlicht directly and then ran my function to create lights.


As you can see -- no shadows (since they're dynamic lights), but the lighting is somewhere in the same neighborhood. Decent for a preview, anyway. There are a couple parameters that can be tweaked to get it closer still.

If I'd lightmapped the OCT, the results would have been identical to my previous screenshot, but the workflow would have been much shorter.

The loader is currently limited to 128x128 lightmaps in the OCT (that is, it doesn't support my extended OCT format yet), but since you can adjust the lightmap density in FSRad, that's not really a problem).


Anyway, yet another option.