Murphy's Irrlicht Mesh file format

Murphy · Post by **Murphy** » Mon Jan 24, 2005 6:21 pm

Oh yeah...

vermeer:
As far as FSRad generating small lightmaps (packed into the corner)... on the Lightmaps tab of FSRad, set U and V. I think you want smaller values, but I wouldn't swear to it.

vermeer · Post by **vermeer** » Mon Jan 24, 2005 9:32 pm

I think I'm starting to get something more suitable. you bet I'll post the ideal values once I get there, as this is a nightmare...

Ehm....

Did not find ase converters...well, i did, Biturn and Ivcon...I tried with this last one to make a conversion from a with-lights 3ds exported (with wintermute 3ds modified 3ds export script) into an ASE. Sadly, it said it was a 3ds v1.0, and it needed v3.0 or +. Biturn plainly didn't see lights in 3ds files.

3d exploration opens greatly lights of ase and 3ds, but does not save ase.Lithunwrap nor Ultimate can treat lights.

No other ASE converter or plugin for free.

I am going to paste in this post the only scripts i have found...unreal game does not use the lights, so seems they don't add it.

The guy from race car game..didn't see any light routine or reference or comment in the whole script.

The other I think is the previous to one of those....but not sure. Neither saw lights there, and thinks ir even older.

Imho by far your easiest task -or sounds like it- is to simply parse the already output data from VRML 2.0 standard blender 2.35 or + export..as is clean and powerful... And mix with the OBJs to get into FSRAD...

Actually something like that did Trancos, though is a bit heavier to go and add a polygon, needing to teselate there or add extra objects, none of these solutions being ideal (and with some faces with different texture) ..then do the OBJ to mat, change the material you want as light to say 1,1,1 instead of 0,0,0, and then finally do an OBJ to ent with the same base name (that is, the name without extension)

A bit complex, you loose quite some control...

hehe, between this and Gile[s] or Max, there are some eons..

But it's free

But in terms of control, can't say that the file at the end does not ends nice...

Actually, being able to set up some lights normally, and automating a bit so much command line hassle and stuff, it may end up quite "wysiwyg"

the fact is ..i did the first part (generated a new box, asigned a material to some faces of it, made other material for the rest of faces...just for a quick test...) and then did that workflow, asigning 1,1,1 etc... the bad thing is fsrad, whenever it generates the OCT it does not allow you to use a lightmap bigger than 128..i think that's a bad thing...In the company I was we did 2048x2048 lightmap, using dunno if final render or Brazil... man it looked nice...

i don't know if I can generate a 512x512 lightmap not generating the OCt..and then do it again with exactly same settings(except lightmap being 128x128) and pray it wont do a different UV layout...

So to later on use the oct generated BUt the big lightmap...Do you think that'd be possible...

Anyway, i am afraid most people till now is using 128x128 lightmaps...i think quake ones where even smaller, but....

My bad handling of Fsrad may be due to I don't know what does mean a freaking word of those settings...hehe.

BTW, Murphy, I congratulate you once. Giles and all big packages are going to be able to play really nice things with these, and I know we'll get fsrad working, too.

Well, and all those level editors, cshop, etc

for which you already made loaders

right now it is processing a map...I think i'm finally getting the hang of it

vermeer · Post by **vermeer** » Mon Jan 24, 2005 10:01 pm

You know thousands times better than i which is now the best step, reason why i am uploading all the ASE plugins I could grab for Blender, but...In case you may find it interesting, pasting a complete vrml2.0 file, for in case you se it easy to just extract light infos from there....

#VRML V2.0 utf8
# modeled using blender3d http://blender.org/$
# exported using wrl2export.py version $Revision: 1.4 $
# get latest exporter at http://kimballsoftware.com/blender/

NavigationInfo {
headlight FALSE
avatarSize [0.25, 1.75, 0.75]
} # NavigationInfo

DEF Lamp_001 PointLight {
ambientIntensity 0.2
intensity 0.666666666667
location 0.611 0.287 -8.213
radius 20.0
} # PointLight

DEF gp_staticMesh Shape {
appearance Appearance {
material DEF Mat Material {
diffuseColor 0.8 0.8 0.8
ambientIntensity 0.5
specularColor 1.0 1.0 1.0
emissiveColor 0.0 0.0 0.0
shininess 0.196
transparency 0.0
} # Material
texture DEF _046pierres_bmp ImageTexture {
url "046pierres.bmp"
} # ImageTexture
} # Appearance
geometry IndexedFaceSet {
solid TRUE # one sided
coord DEF coord_gp_staticMesh Coordinate {
point [
-0.88 3.706 0.249,
-1.505 3.836 0.301,
-0.753 3.836 0.301,
-0.753 3.6 0.301,

[........................a lot of coords...]

.
.

0.943 -3.151 -0.455,
1.688 -2.99 -0.545,
1.778 -3.151 -0.455,
] # point
} # Coordinate
coordIndex [
0, 1, 2, -1,
0, 3, 15, -1,

[........................a lot of coords...]

.
.
692, 691, 735, -1,
304, 331, 261, -1,
] # coordIndex
texCoord TextureCoordinate {
point [
0.897 0.777,
0.924 0.772,
[........................a lot of coords...]
.
.
0.951 0.436,
0.945 0.433,
0.953 0.433,
] # point
} # texCoord
texCoordIndex [
0, 1, 2, -1,
3, 4, 5, -1,
[........................a lot of coords...]
.
.
4722, 4723, 4724, -1,
4725, 4726, 4727, -1,
] # texCoordIndex
creaseAngle 0.0 # in radians
} # IndexedFaceSet
} # Shape

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

Oh, and the ASE blender plugins...

http://uploads.savefile.com/redir/96651.zip

And finally got something going....is just that the viewer I think does a 16bit shading or something...but textures are ok. Yet would not be able to use the output if it were just me...

till tomorrow!

Murphy · Post by **Murphy** » Tue Jan 25, 2005 1:54 am

Actually something like that did Trancos, though is a bit heavier to go and add a polygon, needing to teselate there or add extra objects, none of these solutions being ideal (and with some faces with different texture) ..then do the OBJ to mat, change the material you want as light to say 1,1,1 instead of 0,0,0, and then finally do an OBJ to ent with the same base name (that is, the name without extension)

Yeah, this is just too much work, though. That's why I'm intent on the idea of using exported lights from Blender and possibly other packages -- just so much easier.

the bad thing is fsrad, whenever it generates the OCT it does not allow you to use a lightmap bigger than 128..i think that's a bad thing
...
i don't know if I can generate a 512x512 lightmap not generating the OCt..and then do it again with exactly same settings(except lightmap being 128x128) and pray it wont do a different UV layout...

So to later on use the oct generated BUt the big lightmap...Do you think that'd be possible...

Anyway, i am afraid most people till now is using 128x128 lightmaps...i think quake ones where even smaller, but....

Well, the real problem isn't the size of the lightmap texture itself (i.e. whether it's 128x128 or 512x512), but the density of the individual lightmaps inside it. The latter can be adjusted with the U and V parameters on the Lightmap tab.

But the same solution (running it once creating a OCT to get the UVs and again to make a higher resolution lightmap) occurred to me too. You could do it, but you'd have to adjust the U and V parameters on the Lightmap page correspondingly so that it packs the texture the same way.

Anyway, this is all sort of irrelevant. As I mentioned, my version of FSRad exports TGA textures, and I think I said earlier that it wouldn't be too hard to have it even export an OBJ. But I've opted for an even simpler solution, which was to extend the OCT format to output any size lightmap, and then modified my OCT2OBJ to work with them. Only a couple minutes of work.

BTW, Quake 3 lightmap textures are 128x128... I'm not sure how big the individual lightmaps inside are. Quake 2 just has the individual lightmaps (most are VERY small... like 4x10 and such) and they get packed into a texture when the level is loaded.

In case you may find it interesting, pasting a complete vrml2.0 file, for in case you se it easy to just extract light infos from there....

Yeah, all the data needed is in there, but I don't particularly want to write a VRML importer for FSRad! VRML is a pretty complex scene description format.

A much easier solution would be, for example, to extend Blender's OBJ exporter to also include some simple lighting information. This would only work with Blender, of course. But it wouldn't be hard for people to add support to other modelers.

I still think ASE might be the way to go.

Hopefully next time I work on this project I'll be able to settle on an approach.

Your screenshot is looking pretty good. What was your workflow? Did you have to adjust the FSRad settings?

Murphy · Post by **Murphy** » Tue Jan 25, 2005 8:29 am

I did a bit more work on this tonight. Just experimenting, not a final workflow.
FSRad can also import its OCT format, so I wrote a quick OCT exporter for Blender. The downside here is that it doesn't support vertex normals, so there's no smoothing (the up side is that it was easy).
Anway, I loaded Vermeer's level into blender, and placed three lights. Exported to OCT. Loaded up the OCT in FSRad and rendered some lightmaps. Then I used my experimental OCT2OBJ to get an OBJ, then OBJ2MIM to get it into Irrlicht.
Here's the result:

MikeR · Post by **MikeR** » Tue Jan 25, 2005 10:36 am

That's looking really good.

Murphy · Post by **Murphy** » Tue Jan 25, 2005 11:05 am

Thanks. And done entirely with free and royalty free tools too (unless I'm terribly mistaken).

Here's some notes:
You can see some of the magenta light leaking out around the edge of that sconce, but that's nothing that increasing the density of the lightmap wouldn't fix.

I've still got to tune the relationship between Blender's lights and FSRad a bit more. As it is, they look a bit darker lightmapped. Of course, you also have to figure that when you look at it in Blender, there's no shadowing. And that the gamma setting in FSRad is an additional variable in the mix.

Along with adding TGA export, I've fixed a few bugs in FSRad including one that's important (color values weren't clamped, causing a haloing effect around bright lights) and another that is useful (limiting the number of iterations now works). I'll be making my tweaked version available (sourcecode too, and it now compiles with VC++2003), of course.

puh · Post by **puh** » Tue Jan 25, 2005 11:41 am

I can't wait want to try all this stuff by myself.

vermeer · Post by **vermeer** » Tue Jan 25, 2005 12:04 pm

Yeah, this is just too much work, though. That's why I'm intent on the idea of using exported lights from Blender and possibly other packages -- just so much easier.

been thinking on it...A material that emits light...seems as if only matter the rgb value put in text? 1,1,1 ? ideally, to make real GI it should count on real texture colors, but I highly doubt that. That's how happens in real life. i suspect it make light bounc in a very realistic way, making light go spreading here and there.. not sure.At least it looks quite GI like.

Well, the real problem isn't the size of the lightmap texture itself (i.e. whether it's 128x128 or 512x512), but the density of the individual lightmaps inside it. The latter can be adjusted with the U and V parameters on the Lightmap tab.

Also the size...usually, a bigger lightmap would allow no jaggies in diagonal proyected shadows, or the excesive blur to fix it...yet though, seems fsrad work some sort of different way to avoid this....

But the same solution (running it once creating a OCT to get the UVs and again to make a higher resolution lightmap) occurred to me too. You could do it, but you'd have to adjust the U and V parameters on the Lightmap page correspondingly so that it packs the texture the same way.

No way..it'd have to be micro precission..matching pixels with UVs is really difficult , to not output light or shadows unwanted bleeding..even more with this micro chunks...this could be a problem...but anyway, is the free option..128x128 we're seing that in fsrad it can do ..more or less.

Anyway, this is all sort of irrelevant. As I mentioned, my version of FSRad exports TGA textures, and I think I said earlier that it wouldn't be too hard to have it even export an OBJ. But I've opted for an even simpler solution, which was to extend the OCT format to output any size lightmap, and then modified my OCT2OBJ to work with them. Only a couple minutes of work.

sounds good but...No normals this way?

A much easier solution would be, for example, to extend Blender's OBJ exporter to also include some simple lighting information. This would only work with Blender, of course. But it wouldn't be hard for people to add support to other modelers.

Sounds good. yet though, I have experienced not that many people in the indy and free world using Blender. I know, but I am seing that lately as a fact...BTW, Poseray puts lights into OBJs, curiously.
http://user.txcyber.com/~sgalls/

Not of much use for this...

"I still think ASE might be the way to go."

Well, thinking a bit better...This all is for provide a free for all solution, while having quality. I think Blender should be the epicenter of it. Simply the other free tools aren't power enough, fucntional enough, or open . So, yep, probably whatever the modify you do to a python exporter, ase, or whatever, would be good to go even if only for blender. Blender is available for all platforms, and the mentioned here is to use just as a level maker, not that u need to learn blender. Anyway, when someone wants to learn level making, needs to learn some level editor

So, ase sounds good. I think the unreal one based is the mor erecent one, though dunno if is the more ase standards compliant..anyway, two of them, are done for a particular game, the other one, I don't know, is much older.

The other day i found a complete definition of ASE format, at wikipedia or something...But i supposed you already know good sources.

"Your screenshot is looking pretty good. What was your workflow? Did you have to adjust the FSRad settings?

My main problem with fsrad is I don't know what each setting does really, so I try to imagine... I think low density, and the other values, I don't remember....

I did a bit more work on this tonight. Just experimenting, not a final workflow.
FSRad can also import its OCT format, so I wrote a quick OCT exporter for Blender. The downside here is that it doesn't support vertex normals, so

argh..beware, that's the main problem with slimshady and lume tools...caculations from models with no normals tend to look reallyugly...though in this case, dunno, as actually seems what fsrad does is subdivide and do radiosity....a subdivided emsh will have the smoothness greater, though not as smooth as if it also carried normals info...

Anway, I loaded Vermeer's level into blender, and placed three lights. Exported to OCT. Loaded up the OCT in FSRad and rendered some lightmaps. Then I used my experimental OCT2OBJ to get an OBJ, then OBJ2MIM to get it into Irrlicht.
Here's the result:

Sounds it could be a definite workflow. You end up with an OBJ + textures...it maybe good if actually FSRAD does not takes normals intoconsideration anyway, or subdivides too much for the normals be a factor to actually consider...that's only see through..."art tests"...

or knowing better than I know how actually FSRAD works and what each setting means...

hey...I know programmers prefer to pass stuff when is more mature...but I could help in seing if it's not producing the usual artifacts you can have in lm, sulaco's, or slimshady...

I mean, in case you want to pas me by email or something...I can pass you my email via PM message .

Unless you'r ok to just upload already to somewhere...

With an OBJ and tga export, I have way much more control to know what's happening..for my viewers and utils.

So you already have a working full workflow..great...so, it's blender oct exporter... no inbetween steps <great> load direct into fsrad....GO button..

...your OCT2OBJ.....My workflow ends there, as I'm allways an artist, just that... But this whole thing would be of not much use if you hadn't made your OBJs to MIM code.

You worked a lot, already. if you could upload or send, I could see it in even more situations

In other order of things...I'm getting slowly the grips of this FSRad...

(even when my actual tool is, and will of course be Gile[s]). I just like that free paths are available.

vermeer · Post by **vermeer** » Tue Jan 25, 2005 12:15 pm

"Thanks. And done entirely with free and royalty free tools too (unless I'm terribly mistaken). Smile"

yep, very nice lighting

(about all made by free tools...Absolutely, the level was done totally in Wing3d, that shares a lot of its situation with Blender: mac, win, linux versions, totally free for coemrcial even (BSD license))
An dthe quick UVs(done with Ultimate Uwnrap) I made were so bad(even for a sample) that I am happy you are not using them

"Here's some notes:
You can see some of the magenta light leaking out around the edge of that sconce, but that's nothing that increasing the density of the lightmap wouldn't fix."

How does it changes color? It does sound misterious to me...
Indeed, itf that's translated to pixels, the colored lighting...well, put saturation to zero(not convert to greyscalemode, that'd be only 256 tones gradients, is quite different to rgb wit no color

) in any 2d package in the tga, and that's all

"I've still got to tune the relationship between Blender's lights and FSRad a bit more. As it is, they look a bit darker lightmapped. Of course, you also have to figure that when you look at it in Blender, there's no shadowing."

you mean you don't see shadows in blender, or that the shadows done in fsrad wil differ a lot -logically- ?

" And that the gamma setting in FSRad is an additional variable in the mix."

Actually, indeed if it matches the purpose slightly, it'd be already a success...i wouldn't expect more than light position -and perhaps strenght- matching...

But is enough to do brilliant levels

"Along with adding TGA export, I've fixed a few bugs in FSRad including one that's important (color values weren't clamped, causing a haloing effect around bright lights) and another that is useful (limiting the number of iterations now works)."

oops, it didn't ...lol. Now I understand...

" I'll be making my tweaked version available (sourcecode too, and it now compiles with VC++2003), of course."

Simply sensational.

vermeer · Post by **vermeer** » Tue Jan 25, 2005 12:39 pm

"What was your workflow? Did you have to adjust the FSRad settings?"

Sorry. Forgot the actual question....

As you know, Wings3d.(initially)

(imported to blender, but the modelling can be done in any, as u know) Then, I made a cube for create the "emiter" Hoping it would help me oclude partially, so to build a fake "spot light" . Hollowed the cube, and set the white material in the depth bottom of it. I dunno if cube walls finally are acting as light directors. Anyway, you see this can be Wings3d--->Fsrad directly. Or with any modeller that can aply materials (any) , Metasequoia, Wing3d, Blender, etc.

Went to the folder I had OBJ2ENT from Trancos. generated the stuff. So, first the *.mat, set the "light" material to have 1,1,1 using note pad to edit *.mat. Now generated also with ob2ent, the ANT file. Ok, went to fsrad, generated there the lightmaps. Yep, low, ow density. And discovered if u put certain settings, it will generate many 128x128 lightmap RAW files, if put other, it generates only one, But i rather prefer one only lightmap texture file.

Man , is curious how calculations time varies so much depending on settings.
It would have been nice if they would have put a one sentence practical explanation of what each value does, in a short legend...

The workflow you provide is so much better.

Murphy · Post by **Murphy** » Tue Jan 25, 2005 1:55 pm

In no particular order...

"been thinking on it...A material that emits light...seems as if only matter the rgb value put in text? 1,1,1 ? ideally, to make real GI it should count on real texture colors, but I highly doubt that. That's how happens in real life. i suspect it make light bounc in a very realistic way, making light go spreading here and there.. not sure.At least it looks quite GI like."

Right, it should count on the texture colors, but I don't think anything actually does that. For a raytracer I've been toying with writing, I'm considering averaging the texture colors to give each material a sort of starting point.

"Hollowed the cube, and set the white material in the depth bottom of it. I dunno if cube walls finally are acting as light directors."

They should be. Yeah, there are some cool things you can do with emitting surfaces, but my problem with it is that Blender and other tools don't support this... leaving you with no preview at all of what your level might look like. And I think having to manually edit all those lights with a text editor would be a royal pain and make lighting a full level well a real nightmare.

There are possibilities, like a little GUI tool that let you set light properties for OBJ "groups". But, you know... I don't think it's really necessary. Just add some more point lights, and I think things will be okay.

And placing lights in Blender just seems soooooo easy in comparison.

You could always create a hollow cone or cube or whatever in Blender and then put a point light inside it to achieve a similar effect to your cube with the back face being the emitter. And then get together a workflow to let us drop groups from the actual geometry -- removing the cone/cube after the lightmapping is done.

"you mean you don't see shadows in blender, or that the shadows done in fsrad wil differ a lot -logically- ?"

I believe the case is that Blender only does shadows for spotlights. And the lights in OCT are point lights. It'd be possible to extend OCT/FSRad with other light types (essentially by doing the "point light inside a cone" method I was just discussing, but doing it all internally), but it'd be a mighty pain.

So, yeah. It does shading, but doesn't do shadows.

Me: "You could do it, but you'd have to adjust the U and V parameters on the Lightmap page correspondingly so that it packs the texture the same way."

Vermeer: "No way..it'd have to be micro precission..matching pixels with UVs is really difficult , to not output light or shadows unwanted bleeding"

I think you'd find it would be okay... you generate the OCT with 128x128, and that comes with texture coords. Then you create a 256x256 lightmap (twice the size) with twice the density -- the UV coordinates should very close. Whatever -- it doesn't matter, since my extended version of the OCT format can output any size lightmap.

Me: "But I've opted for an even simpler solution, which was to extend the OCT format to output any size lightmap, and then modified my OCT2OBJ to work with them. Only a couple minutes of work."

Vermeer: "sounds good but...No normals this way?"

"argh..beware, that's the main problem with slimshady and lume tools...caculations from models with no normals tend to look reallyugly...though in this case, dunno, as actually seems what fsrad does is subdivide and do radiosity....a subdivided emsh will have the smoothness greater, though not as smooth as if it also carried normals info..."

There's no way to get vertex normals out of FSRad, and actually... there doesn't seem to be any way to get vertex normals into FSRad either! Earlier, I was assuming that if you read in ASE, it'd use the vertex normals, but I've looked through more of the source, and I think I was wrong. I don't think FSRad uses vertex normals at all, which is sort of disappointing.

As for vertex normals on output... this is largely a non-issue. Once the lightmaps are generated, the smoothed appearance that the vertex normals provide has already been baked in unless you also want to dynamically light the mesh, which isn't that common, as far as I know. If it was REALLY necessary, all is still not lost -- the normals still exist in the original mesh of the level, and a tool could be written that re-incorporate them into the final MIM.

Anyway, with this new knowledge, it seems like my OCT exporter for Blender is really as far as I need to go. switching to ASE or whatever won't really be a gain since FSRad doesn't seem to do anything with the normal information.

"Sounds good. yet though, I have experienced not that many people in the indy and free world using Blender."

Well, they only need to use it for lighting, really. They could model in whatever they want. And if there was demand, it's just a matter of writing an OCT exporter or some sort of converter for whatever modeling package. I could write a program to get lights from DeleD fairly easily, for example, if I was inclined.

"So you already have a working full workflow..great...so, it's blender oct exporter... no inbetween steps <great> load direct into fsrad....GO button.. ...your OCT2OBJ.....My workflow ends there, as I'm allways an artist, just that... But this whole thing would be of not much use if you hadn't made your OBJs to MIM code."

Well, it has a shortcoming at the moment. My Blender OCT exporter doesn't output any texture information in the OCT, and both the exporter and FSRad itself (I think) do some manipulation of the mesh. Thus, I can get the lightmapped level into Irrlicht, but there's no way to get the texture on it too, as using OBJ2MIM to merge a texture OBJ and the lightmap OBJ requires that the two meshes be the same. I think the OCT could hold the texture information too. Indeed, this would be a simpler workflow. Now that it seems like I may be sticking with the OCT exporter (I was originally just planning to use it to experiment with because I thought I'd want to switch to ASE to get vertex normals), I guess I should see about implementing this.

Kind of a bummer about FSRad apparently not supporting vertex normals. I guess that's why you'd buy gile[s]. It still seems like it'll have its uses, and you could always paint over really objectionable parts by hand. I'm not sure what the other good possiblities are. Add vertex normals to Lord Trancos' tool? Try converting the ray tracer I've been toying with into a lightmapper?

As for release times...
I'll probably put something up in the next couple of days. Expect bugs and shortcomings.

I've only done a certain amount of testing. Indeed, I CAN only do a certain amount. And tools like CSM2MIM, I'll probably never have real occasion to use myself.

And in other good news, which I just have to relate because I'm just so darn happy about it... I've been annoyed with the speed of OBJ2MIM. I even did a lot of optimizing on it, fixing lots of things that I find usually slow stuff down, but stilll... for a 420kB OBJ file, it was taking upwards of 15 seconds on my machine to do the conversion (maybe even upwards of 30 seconds or so). I just couldn't stand it anymore, so I gave another pass at optimizing it. I guess I should have profiled the code instead of optimizing blindly, because the slowdown wasn't anything I'd have guessed. Anyway, it takes about three seconds now to convert the same OBJ. Will sure save me some time testing!

puh · Post by **puh** » Tue Jan 25, 2005 2:45 pm

Hi, Murphy. About adding texture info in the OCT files: did you see sources of obj2oct and oct2lmts from Lord Trancos? If you need I can send it to you, as well as sources of his modified version of FSRad. Hope this could help...

nitroman · Post by **nitroman** » Tue Jan 25, 2005 4:14 pm

Add vertex normals to Lord Trancos' tool?

Lord Trancos originally did a version of LMTS with vertex normals... But it was an alpha version with some bugs. Unfortunately, he stopped its development.
Here you can check the discussion about vertex normals:
http://irrlicht.sourceforge.net/phpBB2/ ... l&start=30

Screenshots here:
http://www.geocities.com/dxlab/tmp/lmnew.htm

He even posted binairies:
http://www.geocities.com/dxlab/tmp/lmtools_alpha.html
But I don't know if he posted the source... Maybe you can e-mail him?
If he didn't changed, his e-mail is: lordtrancos AT dubmail DOT net

Hope it helps. BTW great work!

vermeer · Post by **vermeer** » Tue Jan 25, 2005 6:36 pm

@Nitro , do you refer to add normals to FSRAD tool? No you refer to Lume tools...the only problem could be if lightmap is generated badly in curved surfaces for the calculations.... but restoring normals over an OBJ is easy, or just leaving the smooth groups build (the only a bit longer thing, as autosmooth is just setting a value (Murphy, autosmooth blender feature does not work as it should for games matter)) for last step, previous to obj2mim.

@MURPHY

Right, it should count on the texture colors, but I don't think anything actually does that. For a raytracer

I've been toying with writing, I'm considering averaging the texture colors to give each material a sort of starting point.

Well, that'd be freaking good, but I suppose you say for later on, no need to add you extra work..guess that few to no lightmapper out there deals with that...is as we're a lot into radiosity thanks to fsrad and giles

But hey, I never know if you add a feature for plain pleasure

"Hollowed the cube, and set the white material in the depth bottom of it. I dunno if cube walls finally are acting as light

directors."

They should be. Yeah, there are some cool things you can do with emitting surfaces,

yup, like using it to project cathedral kind of crystal, anything that will force projecting a silohuette

but my problem with it is that Blender and other tools don't support this... leaving you with no preview at all

I see..yep, is the only problem with fsrad, loose of control. While so, already as is, if u put some lights , you end with a nice scene.yes , is the control over it what is a bit lost. (but way better than nothing.Or being restricted only to BSP geometry. These methods allow any type of complex geometry

)

There are possibilities, like a little GUI tool that let you set light properties for OBJ "groups". But, you know...

I don't think it's really necessary.

nope, besides, there are allways benefits on building a conection,(perhaps is an start for other coders) even just for this,

with Blender. Is a program very good for becoming a level editor. Really very well equiped.

[

Just add some more point lights, and I think things will be okay. And placing lights in Blender just seems

soooooo easy in comparison.

true

besides, the multiOS is built already

You could always create a hollow cone or cube or whatever in Blender and then put a point light inside it to achieve a similar effect to your cube with the back face being the emitter. And then get together a workflow to let us drop groups from the actual geometry -- removing the cone/cube after the lightmapping is done.

That I hadn't thought of it...maybe...hmmm...I don't know what actually considers fsrad...if it will visualize a face from the opposing face of normal..if so, invert cone walls....hmm...in some angles would be seen...it depends how you set it up/camera route ingame. Othe rthink is use alpha materials. Neither know if fsrad recognize that...if yes, put all as transparent...but it maybe so realistic that fsrad makes light go through transparent materials, too...heh...if not, there u have a workflow. You can even later on just clone these cones, no need to do other thing that allways have an scene with several "light" types, cone, etc... and merge with the actual level...never do them again, then

Only rotate and position them, like with any light.

"you mean you don't see shadows in blender, or that the shadows done in fsrad wil differ a lot -logically- ?"

I believe the case is that Blender only does shadows for spotlights.

In viewport I don't manage even to show spot proyected ones. Maybe I'm too newbie. In render, Omni does render cast ,

proyected shadows...if you set up raytracing for the material, render ray button on, and light "raytraced shadows" button

let it pressed, too. If you don't activate OSA, antialiasing, that is, the preview is going to be instantaneous. At least, the

raw shape of the proyected shadow will be shown with spots and omnis.(point light)

And the lights in OCT are point lights. It'd be possible to extend OCT/FSRad with other light types

I tell, you, once you set up your lights as you think you should, hit render, and in less than a second, at least you see how

shadows will project, at least.Of course, there will be difference, but a raw idea.

(essentially by doing the "point light inside a cone" method I was just discussing, but doing it all internally),

but it'd be a mighty pain.

Give a thought to what I mentioned... is better to save strenghts whenever possible.. But if you think there's better other

way, it's gonna be better , then. I don't know actually Blender, and even less fsRad, so I speak of what i can imagine,

only. have only solid experience in other much different 3d tools.

So, yeah. It does shading, but doesn't do shadows.

there's also 3 modes: solid, shaded, textured. Well, i think in viewport never is proyected...you need a render, I think,

even an uber-quick one.

Me: "You could do it, but you'd have to adjust the U and V parameters on the Lightmap page correspondingly so that it packs the texture the same way."

Vermeer: "No way..it'd have to be micro precission..matching pixels with UVs is really difficult , to not output light or

shadows unwanted bleeding"

I think you'd find it would be okay... you generate the OCT with 128x128, and that comes with texture coords. Then you create a 256x256 lightmap (twice the size) with twice the density --

Does it match it? I mean, I have done so already, but the generated uvmap was different in shape/distribution... I even

have done dividing by 2...I'll try again that..

the UV coordinates should very close. Whatever -- it doesn't matter, since my extended version of the OCT format can output any size lightmap.

hundred times better

Me: "But I've opted for an even simpler solution, which was to extend the OCT format to output any size

lightmap, and then modified my OCT2OBJ to work with them. Only a couple minutes of work."

Vermeer: "sounds good but...No normals this way?

argh..beware, that's the main problem with slimshady and lume tools...caculations from models with no normals tend to

look reallyugly...though in this case, dunno, as actually seems what fsrad does is subdivide and do radiosity....a

subdivided emsh will have the smoothness greater, though not as smooth as if it also carried normals info...

There's no way to get vertex normals out of FSRad, and actually... there doesn't seem to be any way to get

vertex normals into FSRad either!

ooops

Earlier, I was assuming that if you read in ASE, it'd use the vertex normals, but I've looked through more of

the source, and I think I was wrong. I don't think FSRad uses vertex normals at all, which is sort of disappointing. Sad

wait...looked at ...todo.txt, inFSRad-004-LTMod\Project\Source\FSRad ...and....

** Calculate proper normals in OCT file output

Hmm...look at this shot...my main disapointments where the square proyected light up on wall..but blamed it being really

small lightmap file... but the "stone torch" ..should show curved, seems it could be same no normals problem of

slimshady and lumetools?

http://img70.exs.cx/img70/9554/another3vy.jpg

maybe is due to trancos lumetools viewer...I dunno.This, or fsrad outputs bad lightmap for this (banded non smooth in

curved surfaces) , or just the model is no more smooth for its pass by fsrad, and trancos lmts viewer is just showing a non

smooth mesh, not is an effect of "non smooth lightmap" . can't guess it, as have not got possibility to export LMTS or OCT

to my tools...

As for vertex normals on output... this is largely a non-issue. Once the lightmaps are generated, the

Nope, I'm more worried in the fact if it does not take them in account while calculating, will probably produce hard cuts

instead of smooth shading gradients, whenever it finds acurved surface...I though it was doing it right, looking atthe

arc...hmm..maybe is my unwelded crappy level

Yes, if the thing is generated in lightmaps smoothly,(could be as it actually tesselates crazily the mesh: the less need in

that type of mesh of smoothing normals, is reason why probably Blender has not a complete support of it (no smooth

groups/hard edges)) smooth pixel transitions in curved surface, then doesn't matter, in anymoment since then smooth

normals can be fixed.Even more, I can easily add smooth groups to a model if it outputs OBJ.

smoothed appearance that the vertex normals provide has already been baked in unless you also want to

not exactly the same, it has been baked the smoothness of very hi res unsmoothed (in normals terms) but very high count

mesh, which I am suspecting is more than enough, that's why. yet to do a good test out of it.

dynamically light the mesh, which isn't that common, as far as I know.

yep, no need. Dynamical lighting is other route, is too much info radiosity to put in realtime.

If it was REALLY necessary, all is still not lost -- the normals still exist in the original mesh of the level, and a tool could be written that re-incorporate them into the final MIM.

Actually, it's less good if the artist did hardworked hard edges in OBJ, Max or Milkshape (Blender has not got them) making the smooth groups...but even so...workflow could be diferent...hehe, as it will end as OBJ, add the smoothing groups at last. Till then, and for sake of modelling with a close look to final thing, artist would apply an autosmooth value. That's even easy to apply by code, as is to whole mesh.Those artist which just are ok with just applying an autosmooth value, will not suffer from that. The others, can do the real final smoothgroups stuff importing the OBJ in Wings, Milkshape, or Max. ui have even worked in a company and used autosmooth..hehe.If you end up as OBJ, is never a real issue. They'll rebuild smooth groups or apply an autosmooth...Unless it's a way complex cathedral with 200,000 tris and loads of hard egdes...even so, there are quick tricks

And in the worst case, is not like rebuilding UVs, or something like that. The UVs to use are the ones FSRAD made, anyway.

What I'd worry more is..if calculating fsrad is actually not having enough smoothness with a hi res but non normals -smoothed normals. I don't know. I mean, if so, is like in slimshady: the lightmaps in a cilinder is exported in abrupt tones, not a gradient as when light smothly rounds it... That problem would be baked into lightmap. Most probably not, as it subdivides so much the mesh that...

Anyway, with this new knowledge, it seems like my OCT exporter for Blender is really as far as I need to go. switching to ASE or whatever won't really be a gain since FSRad doesn't seem to do anything with the normal information.

Yup. Exactly. I only then would need to test it to export OBJ and tgas, and see if with available free tools, one can deal with possible problems (there are allways problems in 3d

)

"Sounds good. yet though, I have experienced not that many people in the indy and free world using Blender."

Well, they only need to use it for lighting, really.

Yes, not a big issue.

They could model in whatever they want. And if there was demand, it's

yes, OBJ import into blender, *.3ds, and others, already work great.

just a matter of writing an OCT exporter or some sort of converter for whatever modeling package. I could write a program to get lights from DeleD fairly easily, for example, if I was inclined.

No need. It's only handling lights as they do in any level editor. No big thing. Import and export, just that.

"So you already have a working full workflow..great...so, it's blender oct exporter... no inbetween steps <great> load

direct into fsrad....GO button.. ...your OCT2OBJ.....My workflow ends there, as I'm allways an artist, just that... But this

whole thing would be of not much use if you hadn't made your OBJs to MIM code."

Well, it has a shortcoming at the moment. My Blender OCT exporter doesn't output any texture information in the OCT, and both the exporter and FSRad itself (I think) do some manipulation of the mesh. Thus, I can get the lightmapped level into Irrlicht, but there's no way to get the texture on it too, as using OBJ2MIM to merge a texture OBJ and the lightmap OBJ requires that the two meshes be the same. I think the OCT could hold the texture information too. Indeed, this would be a simpler workflow. Now that it seems like I may be sticking with the OCT exporter (I was originally just planning to use it to experiment with because I thought I'd want to switch to ASE to get vertex normals), I guess I should see about implementing this.

As you see, but...Again, if you end up in final point -previous to --->MIM- in OBJ...the workflow would be easy for fianl fix by the artist. Surely anyway he'll have to rebuild normals so...If I understood well...the artist could grab the oct...convert to OBj with your tool...and now produce a duplicated mesh...from the OCT.if actually mesh didn't change that much...-you says it did..then..danger...- even lithunwrap imports *.lub file into another file.Old OBJ will export into this more transformmed OBJ. Seems here it works with no problems if just one material, one group..I think in the comercial version I have, Ultimate, doesn't matter if several materials. Anyway, restoring textures and materials is really easy in any tool. Is only UVs what could be a problem. If mesh did not changed, it could be worked this way.

of course, more ideal is if it retains texture...but that will force you it keeping the texture linked all through the proccess, even during fsrad calculation..sounds hard...Well, if I can test the tools, I can tell you if...at least Lithunwrap could swap the UVs between the files, and which is the exact workflow an dthings to avoid.

Kind of a bummer about FSRad apparently not supporting vertex normals.

yup...

I guess that's why you'd buy gile[s].

Not only for that...i find many other advantages...I play with light color, position light properties, lightmap size (a maximum of 4096x4096pixels, anyway

) , realtime preview all the time, ...quite more settings...In a word, is more powerful...but how much GI accurate is each..plainly, i don't know, as I am seing FSRAD can ouput a lot of quality.
But for me th control is essential. Even though I'm helping here as I think people should have a quality workflow for free

And imho will end much better than what the same person can output today with Gtk Radiant (besides the geometry+lightmap+lighting methoids, etc limits there, it's the license..no good for comercial projects...And a bunch of other matters

)

It still seems like it'll have its uses, and you could always paint over really objectionable parts by hand.

Do you refer over an FSRAD tga in a 2d aplication? yep...indeed, this is done some time in real situations...Indeed, Giles have the interface, but painting in 3d, and I suspect not only for fixing..Indeed, before you came with this possibility, and I was actually going to use wityh a friend of mine Irrlicht for a project, I even considered to use a 3d painter (I have Deep Painte3d purchased, but the free for non comercial Tatoo, can do) just painting like when one paints an oil..in 3d, over it, a lightmap..some shadows, export the shadows only tga, and overlay in second channel..when i commented it..I was told..that there was not a format supporting two uv channels, so it was impossible even to do that fake ...
Anyway, do that all so, is hard , and even if you are anoil painter,(I am) you wont be very physically acurate...besides, it'd take way too long for several rooms.I prefer though to let the 3d tools do that part ...

I'm not sure what the other good possiblities are. Add vertex normals to Lord Trancos' tool? Try converting the ray tracer I've been toying with into a lightmapper?

The problems I see are not if normals don't get finally in the object. restoring it to an OBJ is easy. (if used just an autsmooth is dumb easy in an art tool, or in code(sometimes a setting in importer, a command line switch..) )
Is mor eproblem if the lightmap is not output smooth for hi res not being enough, or if we can't finally port the UVs to a duplicated OBJ(the oct one) from the old textured OBJ. Asinging a texture (linking) or asigning autosmooth value (now that I think, better if u can add a setting by code of autosmooth normals: lith and Blender can't really do that...Wings can, but reimport OBJs in wings tends to be a bit of a problem for not very expert wingers...In the worst case, I can find in my CDs, some ms-dos tool that restore autosmooth normals value to a...I think 3ds, ASE, and obj...is not never more available in inet, but I can upload to Bal's server. Is a really tiny dos converter.Yet though, is dangerous, as loads of info can die in the way. )

I suspect, though, with what u have already, I can provide a safe workflow

maybe I'm wrong, but we could see it.

As for release times...
I'll probably put something up in the next couple of days. Expect bugs and shortcomings. Smile I've only done a certain

amount of testing. Indeed, I CAN only do a certain amount. And tools like CSM2MIM, I'll probably never have real

occasion to use myself.

yup, I know

Well, I can tell you OBJ with Gile[s] has a perfect export

No probs either with Lith, Ultimate Unwrap, and Blender export of OBJs, if used JMS python script, the latest for 2.36(in Blender 2.35 works, too). And some more tools, I don't remember now... Much surely with anything outputting OBj, and as I told you, whatever the feature is lacking in the poor OBJ support of even some highend aplications, can be added with Lith, Blender, Wings,(didn't test Wings obj export, but I am told it's great in code matters...(perhaps the only for free exporting nicely smooth groups(remember:differnt to autosmooth, the cheap solution

))) etc.

And in other good news, which I just have to relate because I'm just so darn happy about it... I've been annoyed with the speed of OBJ2MIM.

YAY!

I even did a lot of optimizing on it, fixing lots of things that I find usually slow stuff down, but stilll...

for a 420kB OBJ file, it was taking upwards of 15 seconds on my machine to do the conversion (maybe even upwards of

30 seconds or so). I just couldn't stand it anymore, so I gave another pass at optimizing it. I guess I should have profiled

the code instead of optimizing blindly, because the slowdown wasn't anything I'd have guessed. Anyway, it takes about

three seconds now to convert the same OBJ. Will sure save me some time testing!

Woah

Well, what i told you, I'm eager to grab even an pre-alpha of these tools, I mean in the art side (the MIM2OBJ is the most important, but I don't code, I just provide the stuff till that point

)

You see, knowing art tricks, sveral problems can be solved, too.

As you see fit better.

But I guess i could removes some of your headaches(perhaps some of the stuff you think is needed to code, is not, and viceversa..) already...

pm me if decide so...