yihaaaa...
In my totally-totally free workflow pursuit for those not having Cshop, Giles, max, or the like...(and wanting higher res lightmaps than deled's) I have after a *hard* search found several options...been even looking in Raytracers with some bake to texture function...
But no, it perhaps was in much known places...to say that I yet have no idea if these would work.... I have left for later on FSRAD mod thing..I prefer a more friendly tool... So that's what i am digging for . (actually not for me, I'll do with giles or xsi photons)
Here's even the source code (it's said to not be complete, but it's listed all the features we need, unless I left something.Could be that there's no UI to set the lights, I dunno. But even so, I have a 3ds script that finally output lights and cameras out from blender. Blender is terrificly good for a basic scene construction (camera, lights, etc) So, combined with it will work. Even though, if the tool does it all, I have seen preciously that is less problems for the user, fewer tools. )
It's at Sulaco. And I am yet downloading it now. Will test now and tell later. Also found aother free one, that in the least case, produce freely terrains from heightmaps that u edit in the software, allow aplying texture and generating lightmap. My only fear is only for terrain geenration, no mesh import. But surely cool to output lightmaps from terrains generated there.
At last, a third thing...perhaps certain comercial lightmapper provides limited function, but enough for us. Gotta read legal issues and all. yet though, my greatest hopes are in the sulaco one.
Murphy's Irrlicht Mesh file format
Finally making games again!
http://www.konekogames.com
http://www.konekogames.com
so, testing now this one...source provided 
http://www.sulaco.co.za/Nitrogen/Projects.html
dig for lightmap project in that htm
beware: he puts same name to executable zip and source code zip...just right click , "save as" and put another name...otherwise u'll overwrite....
http://www.sulaco.co.za/Nitrogen/Projects.html
dig for lightmap project in that htm
beware: he puts same name to executable zip and source code zip...just right click , "save as" and put another name...otherwise u'll overwrite....
Finally making games again!
http://www.konekogames.com
http://www.konekogames.com
ok, seems that www.toymaker.info is for terrains only, as it does not import a mesh, but allows building a terrain mesh+import texture+generate lightmaps. Good free tool, though. Requires dx9.0c, 9.0b or previous wont work.
The Sulaco tool I'm liking it. It allows uv maps automatic generating and packing, it seems, plus autosmoothing normals recalculation...(as 3ds will usually loose it)
The UI is as spartan as these tools tend to have, but as they seem to be similar, I'm getting quickly the hang of it.
supports curved surfaces, unlike previous ones we've used for free(except fsrad).
The Sulaco tool I'm liking it. It allows uv maps automatic generating and packing, it seems, plus autosmoothing normals recalculation...(as 3ds will usually loose it)
The UI is as spartan as these tools tend to have, but as they seem to be similar, I'm getting quickly the hang of it.
supports curved surfaces, unlike previous ones we've used for free(except fsrad).
Finally making games again!
http://www.konekogames.com
http://www.konekogames.com
hmm..ok, the key seem to be with "size coeficient" u gotta play with the value, as there's allways a good value for it. 
It can end up with very nice auto uvmapping.
Hmmm.Murphy, does it mind that actually the UVs in one final OBJ end up with different uv mapping of the other obj? That is OBJ lightmap object <> OBJ texture object. is it ok?
As Giles, this Sulaco utility, and some others, do their selves the handling of automatic UV, not operating on imported UVs.
It can end up with very nice auto uvmapping.Hmmm.Murphy, does it mind that actually the UVs in one final OBJ end up with different uv mapping of the other obj? That is OBJ lightmap object <> OBJ texture object. is it ok?
As Giles, this Sulaco utility, and some others, do their selves the handling of automatic UV, not operating on imported UVs.
Finally making games again!
http://www.konekogames.com
http://www.konekogames.com
Glad to hear that youre confident that the OBJ meshes won't diverge under reasonable circumstances. This is good news, and you'd know better than I. Of course, and easy way to mess it up would be to accidentally move/rotate one of the meshes, but I suppose an Undo would fix that.
Didn't Trancos have a version of his lightmapper in the works that supported smooth surfaces better? Did it never get released? I seem to remember seeing a shot from it on the forum. Even if it was never released, the sourcecode of the old version is available and I could probably add some smoothness... I believe the problem is that he used face normals as opposed to vertex normals. Even with the current version, you could get better results by tesselating areas of the mesh that look really bad, at the expense of higher geometry.
However, I believe FSRad to be a more powerful tool. If I recall, Trancos' tool used direct lighting, and FSRad is GI. It's just a matter of developing a reasonable workflow, as otherwise it's sort of a pain.
I don't think the output from FSRad is the problem. I should be able to either add OBJ+OBJ+TGAs output or write an OCT (FSRad format) to MIM+TGAs converter without much difficulty. With a bit more difficulty, I could probably add direct MIM support.
Input is a bigger problem. FSRad accepts ASE (3DS text format, right?) and OCT (FSRad's format) for input. I haven't been able to find a current ASE exporter for Blender. So that means I'd either need to write an ASE or OCT exporter for Blender, or develop my own file format and implement it in Blender and FSRad. Seems like adding ASE support to Blender is probably the best way.
What are the Sulaco tool's inputs and outputs?
All that should really matter is vertex count, vertex order, and vertex position. And if I really needed to, I could make it so vertex count and order didn't matter -- only position.
Didn't Trancos have a version of his lightmapper in the works that supported smooth surfaces better? Did it never get released? I seem to remember seeing a shot from it on the forum. Even if it was never released, the sourcecode of the old version is available and I could probably add some smoothness... I believe the problem is that he used face normals as opposed to vertex normals. Even with the current version, you could get better results by tesselating areas of the mesh that look really bad, at the expense of higher geometry.
However, I believe FSRad to be a more powerful tool. If I recall, Trancos' tool used direct lighting, and FSRad is GI. It's just a matter of developing a reasonable workflow, as otherwise it's sort of a pain.
I don't think the output from FSRad is the problem. I should be able to either add OBJ+OBJ+TGAs output or write an OCT (FSRad format) to MIM+TGAs converter without much difficulty. With a bit more difficulty, I could probably add direct MIM support.
Input is a bigger problem. FSRad accepts ASE (3DS text format, right?) and OCT (FSRad's format) for input. I haven't been able to find a current ASE exporter for Blender. So that means I'd either need to write an ASE or OCT exporter for Blender, or develop my own file format and implement it in Blender and FSRad. Seems like adding ASE support to Blender is probably the best way.
What are the Sulaco tool's inputs and outputs?
No, that's just fine. There's really no reason they'd be the same as they use two different textures.Hmmm.Murphy, does it mind that actually the UVs in one final OBJ end up with different uv mapping of the other obj?
All that should really matter is vertex count, vertex order, and vertex position. And if I really needed to, I could make it so vertex count and order didn't matter -- only position."Glad to hear that youre confident that the OBJ meshes won't diverge under reasonable circumstances."
They shouldn't And while I see it rare to happen, if it did, you can allways do the mview trick way...choose a free an unversal tool, like Lithunwrap, Blender, etc. And just make that one compatible (I assume already are) As there's never a problem of compatibility importing for example -mainly- in lithunwrap, and exporting again as OBJ. In the artist side.
" This is good news, and you'd know better than I. Of course, and easy way to mess it up would be to accidentally move/rotate one of the meshes, but I suppose an Undo would fix that."
Yup, I don't think there will be a problem
"Didn't Trancos have a version of his lightmapper in the works that supported smooth surfaces better? Did it never get released? I seem to"
Yes, but he did not released...I think just he got really busy, later on...
Yet though, I am afraid even his updated tool, would export as LMTS, not as OBJ. And is needed the mesh, after all, as these programas all generate its own set of uv coords...
Hmmm ...now that I think...this sulaco thing does not output mesh either..it was not outputting texture, but could be captured by an impant if is not more of 256x256 the lightmap...as what one does is capture that dump...
But as new uv coords are generated..no way..it would force you to touch that code: allow a mesh and texture export. perhaps is trivial, I don't know.
" remember seeing a shot from it on the forum. Even if it was never released, the sourcecode of the old version is available and I could probably add some smoothness... I believe the problem is that he used face normals as opposed to vertex normals. Even with the current version, you could get better results by tesselating areas of the mesh that look really bad, at the expense of higher geometry."
Em...well, I am more about more graphical tools than much command line stuff...But hey, if it comes from Trancos, or your route, good to go...but let me today to see if I can make something of fsrad, sulaco or the other...
One thing i have clear...using a non-normals, non curved meshes one, is definitely not a way to go... SO, I'd discard from now Slim Shady and old Lume tools...
Fs Rad actually would be sweet..i'll see later on if can handle that fs rad trancos modification...
"However, I believe FSRad to be a more powerful tool. If I recall, Trancos'"
Me too.
" tool used direct lighting, and FSRad is GI."
Exactly. The quality is extremely good with fsrad. Must just only see the color bleeding light samples, etc...
is just the workflow I am finding as a real stone rock...I'll see....There's allways a way.
" It's just a matter of developing a reasonable workflow, as otherwise it's sort of a pain."
yes, my own thoughts, too. I'll dedicate quite an effort to the trancos fsrad, as It'd really worth it for the comunity.
"I don't think the output from FSRad is the problem. I should be able to "
The bitmap format I am outputting is my problem...is an *.raw, not a tga, and besides only irfan opens that, i am not getting quality , not even greys in the uv lightmap, for some reason I yet don't know....
"either add OBJ+OBJ+TGAs output"
That would rock better, imho. MUch, much better than the second you mention. As everytime you output an OBJ, you give the artist a lot of flexibility. We can open then the OBJs , even individually, and modify UV maps (I did in an game, as we needed to fix a mip map problem, and only way was scaling Uvs) , reasign textures, lightmaps, etc. And well, the tga, for is quite comon some retouch in 2d packages the lightmap, like apply a blur, etc.
I'd really would advice going for an OBJ+OBJ plus tga route for FSRAD, unless that one adds you extra work compared to the other way.
" or write an OCT (FSRad format) to MIM+TGAs converter without much difficulty. With a bit more difficulty, I could probably add direct MIM support."
That'd be less desirable, probably. While seems MIM is a really great and complete format, the key here is be able to do some fixes in standard tools, this is so often needed in art workflows, that is often much safer go the "standard" formats way till the last moment, whenever possible
imho
"Input is a bigger problem. FSRad accepts ASE (3DS text format, right?) and OCT (FSRad's format) for input. I haven't been able to find a current ASE "
Actually, Trancos wrote an OBJ2ANT util. Is provided in his modified FSRAD geocities page
I have been playing with an ANT made by him, having not much luck till now.
ANT is themodified fsrad ENT format. fsRad didn't even handle UV coordinates, so Trancos added it to the modified version.Is actually highly recommended to use Trancos version.
"exporter for Blender."
There is one, for an old Blender, probaly yet working. I have it. but is not complete...I think is more powerful go the OBJ2ant route...maybe, I am not sure.I may tell you better a bit later.
Curiously, for sulaco I used Blender 3d export. Even one that is done for an engine, so they added 3ds lights positions export, and cameras. But sulaco's didn't grab this lights. No huge issue as one can position a light in the tool (not very accurately)
the problem in sulaco's is..while smooth is ok, etc, it generates rather fast even a 1024x1024 one...the artifacts are really hard to eliminate, or impossible. Just have a look..thi sone is the fewer artifacts one I could made... (pay attention in the red circles I hand painted...)
thumbnail(click for larger)
" So that means I'd either need to write an ASE or OCT exporter for Blender, or develop my own file format and implement it in Blender and FSRad. Seems like adding ASE support to Blender is probably the best way."
ASE is a better chance in general for Blender (for many more engines, not only Irrlicht: jME java engine loads ASE, as many other) .It has not the smoothing info 3ds has, neither the problem with shared uvs that 3ds has, neither the long names, and the format can end up porting way much more features, the no long names in material names problem of 3ds, plus it has not the 65,000 tris limit that *.3ds has.
But seriously, have a look at OB2ANT tool that Trancos made...I am not a coder so I don't know what is better/effortless for you...
IMHO the OBJ route is the way to keep happier to the wider range of artists.
As literally all packages can import/export that format.
"What are the Sulaco tool's inputs and outputs?"
You see...no output, it should be built (code is provided) And it has the articfacts problem.Seems is an scanline or the like, low quality lightmap. But lightining fast, could do for sme people. I prefer quality
Could be a way to go , but the artifacts are terrible. probably is caused for not having a great packing uvs system...I think they get proiduced for too much or not good segmentation, making it share borders of othe rchunks when they shouldn't. It's common to see appear white lights in end of walls, or black ones in places they should not. Does not mind if one grows the lightmap to 1024: as is the packing thing problem, the ratio keeps bad...and it's not enough flexibility to at least tweak it.
" quote: Hmmm.Murphy, does it mind that actually the UVs in one final OBJ end up with different uv mapping of the other obj?
No, that's just fine. There's really no reason they'd be the same as they use two different textures. All that should really matter is vertex count, vertex order, and vertex position."
I'd expect zero probs then with OBJ+OBJ way
" And if I really needed to, I could make it so vertex count and order didn't matter -- only position."
For now, i see no need.
I'll now get patiently back again into FSRad...modified version...Let's see if I can output something nice...I know jox does it...
They shouldn't
And while I see it rare to happen, if it did, you can allways do the mview trick way...choose a free an unversal tool, like Lithunwrap, Blender, etc. And just make that one compatible (I assume already are) As there's never a problem of compatibility importing for example -mainly- in lithunwrap, and exporting again as OBJ. In the artist side. " This is good news, and you'd know better than I. Of course, and easy way to mess it up would be to accidentally move/rotate one of the meshes, but I suppose an Undo would fix that."
Yup, I don't think there will be a problem
"Didn't Trancos have a version of his lightmapper in the works that supported smooth surfaces better? Did it never get released? I seem to"
Yes, but he did not released...I think just he got really busy, later on...
Yet though, I am afraid even his updated tool, would export as LMTS, not as OBJ. And is needed the mesh, after all, as these programas all generate its own set of uv coords...
Hmmm ...now that I think...this sulaco thing does not output mesh either..it was not outputting texture, but could be captured by an impant if is not more of 256x256 the lightmap...as what one does is capture that dump...
But as new uv coords are generated..no way..it would force you to touch that code: allow a mesh and texture export. perhaps is trivial, I don't know.
" remember seeing a shot from it on the forum. Even if it was never released, the sourcecode of the old version is available and I could probably add some smoothness... I believe the problem is that he used face normals as opposed to vertex normals. Even with the current version, you could get better results by tesselating areas of the mesh that look really bad, at the expense of higher geometry."
Em...well, I am more about more graphical tools than much command line stuff...But hey, if it comes from Trancos, or your route, good to go...but let me today to see if I can make something of fsrad, sulaco or the other...
One thing i have clear...using a non-normals, non curved meshes one, is definitely not a way to go... SO, I'd discard from now Slim Shady and old Lume tools...
Fs Rad actually would be sweet..i'll see later on if can handle that fs rad trancos modification...
"However, I believe FSRad to be a more powerful tool. If I recall, Trancos'"
Me too.
" tool used direct lighting, and FSRad is GI."
Exactly. The quality is extremely good with fsrad. Must just only see the color bleeding light samples, etc...
is just the workflow I am finding as a real stone rock...I'll see....There's allways a way.
" It's just a matter of developing a reasonable workflow, as otherwise it's sort of a pain."
yes, my own thoughts, too. I'll dedicate quite an effort to the trancos fsrad, as It'd really worth it for the comunity.
"I don't think the output from FSRad is the problem. I should be able to "
The bitmap format I am outputting is my problem...is an *.raw, not a tga, and besides only irfan opens that, i am not getting quality , not even greys in the uv lightmap, for some reason I yet don't know....
"either add OBJ+OBJ+TGAs output"
That would rock better, imho. MUch, much better than the second you mention. As everytime you output an OBJ, you give the artist a lot of flexibility. We can open then the OBJs , even individually, and modify UV maps (I did in an game, as we needed to fix a mip map problem, and only way was scaling Uvs) , reasign textures, lightmaps, etc. And well, the tga, for is quite comon some retouch in 2d packages the lightmap, like apply a blur, etc.
I'd really would advice going for an OBJ+OBJ plus tga route for FSRAD, unless that one adds you extra work compared to the other way.
" or write an OCT (FSRad format) to MIM+TGAs converter without much difficulty. With a bit more difficulty, I could probably add direct MIM support."
That'd be less desirable, probably. While seems MIM is a really great and complete format, the key here is be able to do some fixes in standard tools, this is so often needed in art workflows, that is often much safer go the "standard" formats way till the last moment, whenever possible
imho
"Input is a bigger problem. FSRad accepts ASE (3DS text format, right?) and OCT (FSRad's format) for input. I haven't been able to find a current ASE "
Actually, Trancos wrote an OBJ2ANT util. Is provided in his modified FSRAD geocities page
I have been playing with an ANT made by him, having not much luck till now.
ANT is themodified fsrad ENT format. fsRad didn't even handle UV coordinates, so Trancos added it to the modified version.Is actually highly recommended to use Trancos version.
"exporter for Blender."
There is one, for an old Blender, probaly yet working. I have it. but is not complete...I think is more powerful go the OBJ2ant route...maybe, I am not sure.I may tell you better a bit later.
Curiously, for sulaco I used Blender 3d export. Even one that is done for an engine, so they added 3ds lights positions export, and cameras. But sulaco's didn't grab this lights. No huge issue as one can position a light in the tool (not very accurately)
the problem in sulaco's is..while smooth is ok, etc, it generates rather fast even a 1024x1024 one...the artifacts are really hard to eliminate, or impossible. Just have a look..thi sone is the fewer artifacts one I could made... (pay attention in the red circles I hand painted...)
thumbnail(click for larger)
" So that means I'd either need to write an ASE or OCT exporter for Blender, or develop my own file format and implement it in Blender and FSRad. Seems like adding ASE support to Blender is probably the best way."
ASE is a better chance in general for Blender (for many more engines, not only Irrlicht: jME java engine loads ASE, as many other) .It has not the smoothing info 3ds has, neither the problem with shared uvs that 3ds has, neither the long names, and the format can end up porting way much more features, the no long names in material names problem of 3ds, plus it has not the 65,000 tris limit that *.3ds has.
But seriously, have a look at OB2ANT tool that Trancos made...I am not a coder so I don't know what is better/effortless for you...
IMHO the OBJ route is the way to keep happier to the wider range of artists.
As literally all packages can import/export that format.
"What are the Sulaco tool's inputs and outputs?"
You see...no output, it should be built (code is provided) And it has the articfacts problem.Seems is an scanline or the like, low quality lightmap. But lightining fast, could do for sme people. I prefer quality
Could be a way to go , but the artifacts are terrible. probably is caused for not having a great packing uvs system...I think they get proiduced for too much or not good segmentation, making it share borders of othe rchunks when they shouldn't. It's common to see appear white lights in end of walls, or black ones in places they should not. Does not mind if one grows the lightmap to 1024: as is the packing thing problem, the ratio keeps bad...and it's not enough flexibility to at least tweak it.
" quote: Hmmm.Murphy, does it mind that actually the UVs in one final OBJ end up with different uv mapping of the other obj?
No, that's just fine. There's really no reason they'd be the same as they use two different textures. All that should really matter is vertex count, vertex order, and vertex position."
I'd expect zero probs then with OBJ+OBJ way
" And if I really needed to, I could make it so vertex count and order didn't matter -- only position."
For now, i see no need.
I'll now get patiently back again into FSRad...modified version...Let's see if I can output something nice...I know jox does it...
Finally making games again!
http://www.konekogames.com
http://www.konekogames.com
vermeer:
Yeah, you seem to have come to the same decision that I did -- FSRad is by far the most desirable tool to work with.
"Actually, Trancos wrote an OBJ2ANT util. Is provided in his modified FSRAD geocities page
I have been playing with an ANT made by him, having not much luck till now.
ANT is themodified fsrad ENT format. fsRad didn't even handle UV coordinates, so Trancos added it to the modified version.Is actually highly recommended to use Trancos version. "
Yeah, I know all this, but, in my opinion, this does NOT make for a smooth workflow. The basic problem is that OBJs don't contain lighting information. Using this workflow, you have to use several tools and do some hand-editing of a text file in order to make certain surfaces in the OBJ emit light. ASE, on the other hand, you get lights.
I care about importing texture coordinates into FSRad that much. It'd be nice, but FSRad will be generating its own for the lightmaps, and those are the ones I really care about. Regardless, using the ASE format should get texture coordinates anyway.
My current thinking for the exact workflow is:
Blender
- Export textured mesh in ASE
FSRad
- Import ASE
- Generate lightmaps
- Save to OCT
OCT2MIM
- Convert OCT to MIM + TGAs
"The bitmap format I am outputting is my problem...is an *.raw, not a tga, and besides only irfan opens that, i am not getting quality , not even greys in the uv lightmap, for some reason I yet don't know.... "
Open it as raw in IrfanView, specifying the appropriate size (128x128 usually), and BGR color ordering. I've added TGA export to my own build of FSRad (took about two minutes), but opening the RAW files that way will give the exact same results.
What results are you getting? Blackness?
Would you see about the ASE exporter for Blender? I found several, all of which are for old versions of Blender and no longer work. If you had a working one, that would save me the effort.
""either add OBJ+OBJ+TGAs output"
That would rock better, imho. MUch, much better than the second you mention. As everytime you output an OBJ, you give the artist a lot of flexibility."
Yeah. The downside is that it'd be more work for me. At the moment, I think I'd lean the OCT2MIM (+TGA) way because it'd be easier (and faster) to get something working.
Yeah, you seem to have come to the same decision that I did -- FSRad is by far the most desirable tool to work with.
"Actually, Trancos wrote an OBJ2ANT util. Is provided in his modified FSRAD geocities page
I have been playing with an ANT made by him, having not much luck till now.
ANT is themodified fsrad ENT format. fsRad didn't even handle UV coordinates, so Trancos added it to the modified version.Is actually highly recommended to use Trancos version. "
Yeah, I know all this, but, in my opinion, this does NOT make for a smooth workflow. The basic problem is that OBJs don't contain lighting information. Using this workflow, you have to use several tools and do some hand-editing of a text file in order to make certain surfaces in the OBJ emit light. ASE, on the other hand, you get lights.
I care about importing texture coordinates into FSRad that much. It'd be nice, but FSRad will be generating its own for the lightmaps, and those are the ones I really care about. Regardless, using the ASE format should get texture coordinates anyway.
My current thinking for the exact workflow is:
Blender
- Export textured mesh in ASE
FSRad
- Import ASE
- Generate lightmaps
- Save to OCT
OCT2MIM
- Convert OCT to MIM + TGAs
"The bitmap format I am outputting is my problem...is an *.raw, not a tga, and besides only irfan opens that, i am not getting quality , not even greys in the uv lightmap, for some reason I yet don't know.... "
Open it as raw in IrfanView, specifying the appropriate size (128x128 usually), and BGR color ordering. I've added TGA export to my own build of FSRad (took about two minutes), but opening the RAW files that way will give the exact same results.
What results are you getting? Blackness?
Would you see about the ASE exporter for Blender? I found several, all of which are for old versions of Blender and no longer work. If you had a working one, that would save me the effort.
""either add OBJ+OBJ+TGAs output"
That would rock better, imho. MUch, much better than the second you mention. As everytime you output an OBJ, you give the artist a lot of flexibility."
Yeah. The downside is that it'd be more work for me. At the moment, I think I'd lean the OCT2MIM (+TGA) way because it'd be easier (and faster) to get something working.
Last edited by Murphy on Mon Jan 24, 2005 2:49 pm, edited 1 time in total.
Another note on free lightmappers...
I've got an free program from like five years ago called RadiosGL which does radiosity calculations. I've looked into converting it to a lightmapper for Irrlicht. The downsides are that it's incredibly slow, and doesn't have much documentation. This has lead to me never actually getting output from it, as I'd tweak a parameter than then have to wait a couple hours to find out my results are useless. This might be able to produce decent results, it's just a matter of figuring out how. The screenshots on their site look nice... http://hcsoftware.sourceforge.net/Radio ... iosGL.html
I've got an free program from like five years ago called RadiosGL which does radiosity calculations. I've looked into converting it to a lightmapper for Irrlicht. The downsides are that it's incredibly slow, and doesn't have much documentation. This has lead to me never actually getting output from it, as I'd tweak a parameter than then have to wait a couple hours to find out my results are useless. This might be able to produce decent results, it's just a matter of figuring out how.
The screenshots on their site look nice... http://hcsoftware.sourceforge.net/Radio ... iosGL.htmlThe Cartography Shop 4.x .CSM Loader for Irrlicht can be found here
http://irrlicht.sourceforge.net/phpBB2/ ... php?t=5208
I think instead of a flat file, a binary file for the Irrlicht Mesh is pretty cool.. I have done some research pretty much on a asimillar track and am currently writing a milkshape3d exporter for the binary .ims format.
ims = Irrlicht Mesh
I think a better pipeline would be an irrlicht based lighting editor where you can import the existing irrlicht meshes and create a level and then use a tool to light map this triangle soup...
this editor is not for modelling but for lighting only.
same editor could be reused for entity placement also.
http://irrlicht.sourceforge.net/phpBB2/ ... php?t=5208
I think instead of a flat file, a binary file for the Irrlicht Mesh is pretty cool.. I have done some research pretty much on a asimillar track and am currently writing a milkshape3d exporter for the binary .ims format.
ims = Irrlicht Mesh
I think a better pipeline would be an irrlicht based lighting editor where you can import the existing irrlicht meshes and create a level and then use a tool to light map this triangle soup...
this editor is not for modelling but for lighting only.
same editor could be reused for entity placement also.
---
Saurav Mohapatra
author, artist and bona fide geek
web: http://www.mohaps.com
email: mohaps AT gmail DOT com
Saurav Mohapatra
author, artist and bona fide geek
web: http://www.mohaps.com
email: mohaps AT gmail DOT com
mohaps:
I considered using a binary file, but used an XML file for a number of reasons. It makes it easy to write exporters and stuff for. It's very flexible in that you can leave various things out and the loader will see that they've been left out or will synthesize values. It's good for debugging/testing... you can manipulate a lot of values (scaling, winding direction, material types) very easily with a text editor. And it's easily extensible, which I think is paticularly good for what is, at this point, a developing format.
I figured if I needed/wanted to, I'd eventually come up with a binary format, and write a converter for MIM to the binary MIM. You'd use the text based format during development, and then convert your files to the binary format for production.
vermeer or whoever:
Can someont take a look at the following obj files (there's two) in something that can view textured OBJs and tell me if either of them looks right? Edit: Nevermind -- got it opened in LithUnwrap
I considered using a binary file, but used an XML file for a number of reasons. It makes it easy to write exporters and stuff for. It's very flexible in that you can leave various things out and the loader will see that they've been left out or will synthesize values. It's good for debugging/testing... you can manipulate a lot of values (scaling, winding direction, material types) very easily with a text editor. And it's easily extensible, which I think is paticularly good for what is, at this point, a developing format.
I figured if I needed/wanted to, I'd eventually come up with a binary format, and write a converter for MIM to the binary MIM. You'd use the text based format during development, and then convert your files to the binary format for production.
Yeah, that seems like a pretty good idea, but I think more work than I am willing to put in on it at the moment.this editor is not for modelling but for lighting only.
same editor could be reused for entity placement also.
vermeer or whoever:
Can someont take a look at the following obj files (there's two) in something that can view textured OBJs and tell me if either of them looks right? Edit: Nevermind -- got it opened in LithUnwrap
Last edited by Murphy on Mon Jan 24, 2005 5:40 pm, edited 1 time in total.
"vermeer:
Yeah, you seem to have come to the same decision that I did -- FSRad is by far the most desirable tool to work with."
Yep, and good news..slowly I'm getting the hang of it. But I agree to something you say bellow: it is not very smooth the workflow as is...It'd be better more of a one shot thing. Besides there's too much non-graphical handling of things...u need to set the material of certain polies, asign it a material, tweak later on a txt ...That added to the fact fsrad by it self is not easy...
I think trancos as usual made a great work, but if it can be shortened, better.
"Yeah, I know all this, but, in my opinion, this does NOT make for a smooth workflow. The basic problem is that OBJs don't contain lighting information. Using this workflow, you have to use several tools and do some hand-editing of a text file in order to make certain surfaces in the OBJ emit light. ASE, on the other hand, you get lights."
Yup..problem is...not many tools output ase, that's the pitty.Yet though, if we could make it work with Blender...well, that's quite an standard, free and powerful tool, besides works in mac,win and linux. Even if is just to set upa basic scene, that's not that hard to learn.
The problem is...ase exporter that export lights...I had a suspiction they weren't doing that. There's two exporters (and one importer) that I have found...none seem to export that.
BTW, I found soemtime ago that VRML2.0 was quite nice for scene porting. It ouput lights, and in general, stuff quite well featured:
With standard included vrml export in blender, I already go this :
"DEF Lamp_001 PointLight {
ambientIntensity 0.2
....blahblahblah"
quite nice settings.
"DEF Lamp PointLight {
ambientIntensity 0.2
intensity 0.666666666667
location 1.772 1.714 -9.59
radius 29.9999828339
} # PointLight
DEF Camera Viewpoint {
description "Camera"
orientation -1.00 0.19 -0.17 2.67
position 0.38 4.91 -7.91
} # Viewpoint"
Seems is the same guy that has the latest non native version, so, safe place to go is :
blender.kimballsoftware.com/
http://kimballsoftware.com/blender/
hmm..no probs, seems is the same version, or almost that the one at the site....
great....I follow looking to the exported file again... now in material part...:
"texture DEF lightmap_tga ImageTexture {
url "lightmap.tga""
it's ouputting any bitmap attached.
in geometry... "solid TRUE # one sided"
Uvs also...
Whatever comes out of Blender, one problem it'd have is no smooth groups, as no smooth groups in blender. As much, a general autosmoothing value or flag it as smooth / flat, I am afraid.
Seems it as least gets out smooth, in a basic way. you may wish to add an autosmooth value, in general to MIM format (not to every converter ! , so to avoid you work. A "weld doubles" sometimes comes useful, but somehow, often smoothgroups are done actually braking the mesh, leaving in same point two verts where tehre was one..so a weld doubles may kill this
)
textures and UVs are coming in the file.For some reason, Ultimate Unwrap is not compatible with it and UVs dont get imported but yes in more standrad converters like 3d Exploration 1.5. And is clearly read in the wrml2.0 (thankfully wrml 2.0 is plain ascii )
So, my vote to VRML, Blender based, rather than ASE blender based.
hmmm...also vertex colors get exported...but the code wont appear if u dont use it, in the export. I painted some colors and get exported. Anyway, I prefer colored lightmaps for tiny lighting details, I prefer base all in bitmap, not vertex count.
Not sure if this VRML 2.0 value :
creaseAngle 0.0 # in radians
refers to auto-smoothing info... (the autosmooth in Blender, anyway, is not real. Is better to have a converter or loader, etc, set an autosmooth value , the standard way. )
Look, the *.3ds exported file (but for I mentioned, a 3ds file is som much poor than ASE or VRML 2.0 )
http://img188.exs.cx/img188/9572/3dswin ... ipt9vw.jpg
The VRML 2.0.
http://img188.exs.cx/img188/9766/blenderwrl29wg.jpg
Both seen in 3d Exploration 1.5.
Both carry the cameras and lights, but vrml carries way more stuff, but is not written in export if not used, keeping filesize really small. It's thought for online, after all.
lately, I have read at somewhere, that the vrml author is partially adding animation. As cameras are exported, in a future, the format itself could allow us porting camera animation, not only lights, mesh, etc.
But I'm not worrried in that for now. Is a separate thing. there are irrlicht UIs for this, what there's not yet, is this , a more flexible lightmaps making system, porting the level as you are doing. And even to a native format
So, yep, perhaps the VRML could be good, and the native one in Blender 2.35 (yet haven't myself upgraded to 2.36) is already, the best to go.
What do you think?
Would it be a good path for...Blender-setup-scene.... --->FSRAD ---->MIM ?
I think could end quite powerful.
Moving a camera or a light and putting settings to it is really easy in Blender, so much better than the usual Lightmappers interface.
To tell you the truth, I like it better than Giles UI for that (though i have already get the hang of it and Giles lightmapping possibilities are amazing )
"I care about importing texture coordinates into FSRad that much. It'd be nice, but FSRad will be generating its own for the lightmaps, and those are "
I see. Yep, it's true. Indeed, I have noticed this is an habit...In Max, I worked in game company, we used to do our own uv maps, had more control over it, but also..more work, and often hadn't the time to do good mapping, so, better so. Giles for example does an explendid job on packing.
"the ones I really care about. Regardless, using the ASE format should get texture coordinates anyway."
have a look at vrml 2.0 in Blender..i am afraid ASE is not carrying lights in both :
http://www.geocities.com/swdoughty/blen ... xport.html
http://www.neewo.de/OldSite/index.html
Indeed, second one is for teh specific implementation for Unreal Tournament ASE...which may differ.
haven't read lights porting in any place...
Even more, in the non unreal ase, the other ase, it says something of not porting normals...
"My current thinking for the exact workflow is:
Blender
- Export textured mesh in ASE
FSRad
- Import ASE"
OOPS...you planned to use the ASE with ase import feature in fsrad, that's why... do I know of a VRML2ASE command line...? Probaly not..or yes I do.... is gonna be complicate that it ports all that stuff, though....
Such a pitty...this vrml 2.0 format blender export (even is native, now!will come in every blender release...great for newbies..)was going to be perfect...
"- Generate lightmaps
- Save to OCT
OCT2MIM
- Convert OCT to MIM + TGAs"
Sounds great.
I'll see if I can find a vrml2 to ASE converted, and that is fully featured...gonna be hard to find...
"Open it as raw in IrfanView, specifying the appropriate size (128x128 "
yep, I already was doing so...it was some bad settings in the ui which I was using, probably..yet haven't dominated it totally...
"usually), and BGR color ordering. I've added TGA export to my own build of FSRad (took about two minutes),"
Woah.
" but opening the RAW files that way will give the exact same results."
yes, I have noticed it
I'll play more with fsrad till I get what i want so I can write a tut, or connections also with the other freebies.
"What results are you getting? Blackness?"
Not now...now is ok, but to small res, even if I set 512x512..it keeps putting all in left upper corner, in 128x128 or so...
"Would you see about the ASE exporter for Blender? I found several, all of which are for old versions of Blender and no longer work. If you had a working one, that would save me the effort."
I only found those two ones, and was perhaps a month ago, could not find any one else...Elysiun search doesn't give more results, either, so that's putting it clear...
"Yeah. The downside is that it'd be more work for me. At the moment, I think I'd lean the OCT2MIM (+TGA) way because it'd be easier (and faster) to get something working."
Already great solution
So, I'll see if I can smooth a bit the workflow so to provide you a path that gives an ASE directly to import into FSRAD, instead of that other ascii the vrml2.0. One that gives lights positions in an ASE is gonna bit somewhat hard to find.. Sadly, the very few times I found ase in tools, is allways much poorly implementations. Happens also with vrml, with the exception of Kimbal's work, who made the vrml 2.0 Blender export, and has also done the plugin for Ultimate Unwrap.
"Another note on free lightmappers...
I've got an free program from like five years ago called RadiosGL which does"
You mean you found it, or you made it..it's just that I specifically found it this mourning, is curious..
" radiosity calculations. I've looked into converting it to a lightmapper for Irrlicht. The downsides are that it's incredibly slow, and doesn't have much documentation. This has lead to me never actually getting output from it, as I'd tweak a parameter than then have to wait a couple hours to find out my results are useless. This might be able to produce decent results, it's just a matter of figuring out how. The screenshots on their site look nice... http://hcsoftware.sourceforge.net/Radio ... iosGL.html "
Oh, it's "they" , ok. Yep, I saw it...you say it takes 2 hours..woah, too much...bad comparison, but Sulaco's takes a minute...gile's in great quality..sometimes 5, 10 minutes...it depends on what you put as effects, of course.
Yeah, you seem to have come to the same decision that I did -- FSRad is by far the most desirable tool to work with."
Yep, and good news..slowly I'm getting the hang of it. But I agree to something you say bellow: it is not very smooth the workflow as is...It'd be better more of a one shot thing. Besides there's too much non-graphical handling of things...u need to set the material of certain polies, asign it a material, tweak later on a txt ...That added to the fact fsrad by it self is not easy...
I think trancos as usual made a great work, but if it can be shortened, better.
"Yeah, I know all this, but, in my opinion, this does NOT make for a smooth workflow. The basic problem is that OBJs don't contain lighting information. Using this workflow, you have to use several tools and do some hand-editing of a text file in order to make certain surfaces in the OBJ emit light. ASE, on the other hand, you get lights."
Yup..problem is...not many tools output ase, that's the pitty.Yet though, if we could make it work with Blender...well, that's quite an standard, free and powerful tool, besides works in mac,win and linux. Even if is just to set upa basic scene, that's not that hard to learn.
The problem is...ase exporter that export lights...I had a suspiction they weren't doing that. There's two exporters (and one importer) that I have found...none seem to export that.
BTW, I found soemtime ago that VRML2.0 was quite nice for scene porting. It ouput lights, and in general, stuff quite well featured:
With standard included vrml export in blender, I already go this :
"DEF Lamp_001 PointLight {
ambientIntensity 0.2
....blahblahblah"
quite nice settings.
"DEF Lamp PointLight {
ambientIntensity 0.2
intensity 0.666666666667
location 1.772 1.714 -9.59
radius 29.9999828339
} # PointLight
DEF Camera Viewpoint {
description "Camera"
orientation -1.00 0.19 -0.17 2.67
position 0.38 4.91 -7.91
} # Viewpoint"
Seems is the same guy that has the latest non native version, so, safe place to go is :
blender.kimballsoftware.com/
http://kimballsoftware.com/blender/
hmm..no probs, seems is the same version, or almost that the one at the site....
great....I follow looking to the exported file again... now in material part...:
"texture DEF lightmap_tga ImageTexture {
url "lightmap.tga""
it's ouputting any bitmap attached.
in geometry... "solid TRUE # one sided"
Uvs also...
Whatever comes out of Blender, one problem it'd have is no smooth groups, as no smooth groups in blender. As much, a general autosmoothing value or flag it as smooth / flat, I am afraid.
Seems it as least gets out smooth, in a basic way. you may wish to add an autosmooth value, in general to MIM format (not to every converter !
, so to avoid you work. A "weld doubles" sometimes comes useful, but somehow, often smoothgroups are done actually braking the mesh, leaving in same point two verts where tehre was one..so a weld doubles may kill this )
textures and UVs are coming in the file.For some reason, Ultimate Unwrap is not compatible with it and UVs dont get imported but yes in more standrad converters like 3d Exploration 1.5. And is clearly read in the wrml2.0 (thankfully wrml 2.0 is plain ascii )
So, my vote to VRML, Blender based, rather than ASE blender based.
hmmm...also vertex colors get exported...but the code wont appear if u dont use it, in the export. I painted some colors and get exported. Anyway, I prefer colored lightmaps for tiny lighting details, I prefer base all in bitmap, not vertex count.
Not sure if this VRML 2.0 value :
creaseAngle 0.0 # in radians
refers to auto-smoothing info... (the autosmooth in Blender, anyway, is not real. Is better to have a converter or loader, etc, set an autosmooth value , the standard way. )
Look, the *.3ds exported file (but for I mentioned, a 3ds file is som much poor than ASE or VRML 2.0 )
http://img188.exs.cx/img188/9572/3dswin ... ipt9vw.jpg
The VRML 2.0.
http://img188.exs.cx/img188/9766/blenderwrl29wg.jpg
Both seen in 3d Exploration 1.5.
Both carry the cameras and lights, but vrml carries way more stuff, but is not written in export if not used, keeping filesize really small. It's thought for online, after all.
lately, I have read at somewhere, that the vrml author is partially adding animation. As cameras are exported, in a future, the format itself could allow us porting camera animation, not only lights, mesh, etc.
But I'm not worrried in that for now. Is a separate thing. there are irrlicht UIs for this, what there's not yet, is this , a more flexible lightmaps making system, porting the level as you are doing. And even to a native format
So, yep, perhaps the VRML could be good, and the native one in Blender 2.35 (yet haven't myself upgraded to 2.36) is already, the best to go.
What do you think?
Would it be a good path for...Blender-setup-scene.... --->FSRAD ---->MIM ?
I think could end quite powerful.
Moving a camera or a light and putting settings to it is really easy in Blender, so much better than the usual Lightmappers interface.
To tell you the truth, I like it better than Giles UI for that (though i have already get the hang of it and Giles lightmapping possibilities are amazing )
"I care about importing texture coordinates into FSRad that much. It'd be nice, but FSRad will be generating its own for the lightmaps, and those are "
I see. Yep, it's true. Indeed, I have noticed this is an habit...In Max, I worked in game company, we used to do our own uv maps, had more control over it, but also..more work, and often hadn't the time to do good mapping, so, better so.
Giles for example does an explendid job on packing."the ones I really care about. Regardless, using the ASE format should get texture coordinates anyway."
have a look at vrml 2.0 in Blender..i am afraid ASE is not carrying lights in both :
http://www.geocities.com/swdoughty/blen ... xport.html
http://www.neewo.de/OldSite/index.html
Indeed, second one is for teh specific implementation for Unreal Tournament ASE...which may differ.
haven't read lights porting in any place...
Even more, in the non unreal ase, the other ase, it says something of not porting normals...
"My current thinking for the exact workflow is:
Blender
- Export textured mesh in ASE
FSRad
- Import ASE"
OOPS...you planned to use the ASE with ase import feature in fsrad, that's why... do I know of a VRML2ASE command line...? Probaly not..or yes I do.... is gonna be complicate that it ports all that stuff, though....
Such a pitty...this vrml 2.0 format blender export (even is native, now!will come in every blender release...great for newbies..)was going to be perfect...
"- Generate lightmaps
- Save to OCT
OCT2MIM
- Convert OCT to MIM + TGAs"
Sounds great.
I'll see if I can find a vrml2 to ASE converted, and that is fully featured...gonna be hard to find...
"Open it as raw in IrfanView, specifying the appropriate size (128x128 "
yep, I already was doing so...it was some bad settings in the ui which I was using, probably..yet haven't dominated it totally...
"usually), and BGR color ordering. I've added TGA export to my own build of FSRad (took about two minutes),"
Woah.
" but opening the RAW files that way will give the exact same results."
yes, I have noticed it
I'll play more with fsrad till I get what i want so I can write a tut, or connections also with the other freebies.
"What results are you getting? Blackness?"
Not now...now is ok, but to small res, even if I set 512x512..it keeps putting all in left upper corner, in 128x128 or so...
"Would you see about the ASE exporter for Blender? I found several, all of which are for old versions of Blender and no longer work. If you had a working one, that would save me the effort."
I only found those two ones, and was perhaps a month ago, could not find any one else...Elysiun search doesn't give more results, either, so that's putting it clear...
"Yeah. The downside is that it'd be more work for me. At the moment, I think I'd lean the OCT2MIM (+TGA) way because it'd be easier (and faster) to get something working."
Already great solution
So, I'll see if I can smooth a bit the workflow so to provide you a path that gives an ASE directly to import into FSRAD, instead of that other ascii the vrml2.0. One that gives lights positions in an ASE is gonna bit somewhat hard to find.. Sadly, the very few times I found ase in tools, is allways much poorly implementations. Happens also with vrml, with the exception of Kimbal's work, who made the vrml 2.0 Blender export, and has also done the plugin for Ultimate Unwrap.
"Another note on free lightmappers...
I've got an free program from like five years ago called RadiosGL which does"
You mean you found it, or you made it..it's just that I specifically found it this mourning, is curious..
" radiosity calculations. I've looked into converting it to a lightmapper for Irrlicht. The downsides are that it's incredibly slow, and doesn't have much documentation. This has lead to me never actually getting output from it, as I'd tweak a parameter than then have to wait a couple hours to find out my results are useless. This might be able to produce decent results, it's just a matter of figuring out how. The screenshots on their site look nice... http://hcsoftware.sourceforge.net/Radio ... iosGL.html "
Oh, it's "they" , ok.
Yep, I saw it...you say it takes 2 hours..woah, too much...bad comparison, but Sulaco's takes a minute...gile's in great quality..sometimes 5, 10 minutes...it depends on what you put as effects, of course.Finally making games again!
http://www.konekogames.com
http://www.konekogames.com
sorry, hadn't noticed Mohaps and your last post....
Imho, blender can accomplish very well the functions of a level editor, placing lights, camera, etc..and has all sort of material editor and modelling features builtin, for a future...besides, it is multiplatform: here tehre are quite a number of Linux irrlicht users, and well, Mac artists could bang levels with it too..all aproach to it, even slight, is good, imho...
"vermeer or whoever: Smile
Can someont take a look at the following obj files (there's two) in something that can view textured OBJs and tell me if either of them looks right? Download here: http://www.constantthought.com/files/objs.zip"
Sorry, haven't noticed, I'll download.
Imho, blender can accomplish very well the functions of a level editor, placing lights, camera, etc..and has all sort of material editor and modelling features builtin, for a future...besides, it is multiplatform: here tehre are quite a number of Linux irrlicht users, and well, Mac artists could bang levels with it too..all aproach to it, even slight, is good, imho...
"vermeer or whoever: Smile
Can someont take a look at the following obj files (there's two) in something that can view textured OBJs and tell me if either of them looks right? Download here: http://www.constantthought.com/files/objs.zip"
Sorry, haven't noticed, I'll download.
Finally making games again!
http://www.konekogames.com
http://www.konekogames.com
Thanks for looking at the OBJ files, vermeer. I guess you read that before I edited it to say that I'd gotten it working.
So, I wrote a quick OCT to OBJ+MTL+TGAs converter. I can then run that through OBJ2MIM to get a MIM viewable in Irrlicht. I've done that here with the version of the Cornell box that comes with FSRad:
So that's at least possible. Now it's getting stuff into FSRad that's the current problem...
So, I wrote a quick OCT to OBJ+MTL+TGAs converter. I can then run that through OBJ2MIM to get a MIM viewable in Irrlicht. I've done that here with the version of the Cornell box that comes with FSRad:
So that's at least possible. Now it's getting stuff into FSRad that's the current problem...
Last edited by Murphy on Wed Feb 02, 2005 12:57 pm, edited 1 time in total.
oh!
ok...
em...the file was not loading, but now it does in both Ultimate and 3d exploraiton 1.5...
I had to place a Kd, instead a Ka in the mtl file, though....
(d = diffuse ? )
I mean, if not, the texture would not appear inmediately attached...
Sounds great...
I'll see now if I find the VRML to ase, or...well, any modeller, apart from Max , that outputs an ASE with lights info...
I'll dig.
ok...
em...the file was not loading, but now it does in both Ultimate and 3d exploraiton 1.5...
I had to place a Kd, instead a Ka in the mtl file, though....
(d = diffuse ? )
I mean, if not, the texture would not appear inmediately attached...
Sounds great...
I'll see now if I find the VRML to ase, or...well, any modeller, apart from Max , that outputs an ASE with lights info...
I'll dig.
Finally making games again!
http://www.konekogames.com
http://www.konekogames.com
Yeah, Lith wanted Kd too (no suprise). Ka is a texture file for ambient lighting (which is really what I want). Kd is for diffuse, as you suspected. Anyway, I switched my OCT->OBJ converter to use Kd anyway, and updated OBJ2MIM so that it looks for Ka OR Kd. My other problem with Lith not loading it is Lith NEEDS the vertices to be in a group (i.e. a "g whatever" must come first). Easy enough.
As far as ASE... I'd settle for ANY ASE exporter that works with current Blender. Adding support for lights should be pretty easy. I think I have tried both of the ones you mentioned and found that they don't work with the new versions of Blender.
As far as ASE... I'd settle for ANY ASE exporter that works with current Blender. Adding support for lights should be pretty easy. I think I have tried both of the ones you mentioned and found that they don't work with the new versions of Blender.