actually, vertex normals are better for standard workflows...IE: XSI , metasequoia, wings3d(and many exporters convert smooth groups into more common vertex normals) do support vertex nromals, as several other softwares...smooth groups is more a thing of Max, Milkshape...Poser. But Milkshape for example, will import well vertex normals. It seems VN are more frequently kept intact in conversions.
So, if irrlicht and your tools support vertex normals, that's enough. Smooth groups I'd consider secondary once the other is in.
The oct2obj smoothng normals restoring...is surely nice, but...i think problem is in fsrad...
[ a note here: even if not including vertex normals in blender exporter. Indeed, that part is weak in blender. No hard edges support. All solid or all smooth. That simple. So, imho the key need would be...force fsrad apply some autosmooth value to all faces. I'll explain: many tools have an angle threshold so that from sharper than that angle it'd create a hard edge. A crease in smoothing(i guess this can be ported with vertex normals) is not a break in the mesh, though.) .So, if users types a value for all meshes, or certain meshes, of 45º, then, all pair of faces sharper than that angle will be a hard edge. All less sharper will be treated smooth,no smoothing seam there.Looks continuous. If fsrad would apply this autosmooth value at least, as usually buildings with some curved surfaces tend to work well with 45 - 60 º of autosmooth (depends on how much 3d face "darkening" occurs in engine if too few hard edges are present) , it'd apply the VN, and *then* would calculate the lightmaps. This would allow that curved surfaces would be considered in the fsrad render, as smooth shading, not faceted, and fsrad would be usable in more serious workflows... But to me, and also as I am not a programmer, sounds a way hard task, and get into the internals of the code of another person. ]
. Reason why I would not use FSRAD in my workflows: lightmaps are generated in fsrad without taking in account smoothing normals. So, a curveds surface's lightmap is rendered faceted allways...can be seen even at Fsrad original screenshots page...in the cones and cilinders...
So, what fails in the oct workflow is not the blender exporter (quite good already) , neither the viewer (quite wysiwig), and probably neither in the loader for irrlicht. (an oct2obj+viewer(already done) would convert it all in a general useful tool for artsist, not only irrlicht related projects ) .What may be failing a bit is FSRAD itself, for the vertex normals lack, that is, previous calculation.i guess applying vertex normals with an autosmooth value over the oct, or OBJs, would not be hard (trivial with OBJs, by the artist himself, the advantages of OBJ for artwork pipeines ) But the lightmaps would allways be wrecked, no matter what u do to the mesh: the lightmap pixels have been calculated without taking in account by fsrad the hard and smooth edges of the scene.
Anyway, what I meant was that a whole environment, or a less-steps one, like your new lightmapper project, is preferrable. I use Gile[s] generally, but I very personally like more the fsrad's results(when no curved surfaces are in, that is
).
been playing these days also with the lmmaker 3.8 from windsoft , whose download does not seem to exist anywhere in the net from my search results...only the temp files of 15 days that I upload...
And well, if your worries with your lightmapper is speed, man is it slow with the sample scene and radiosity activated...FSRAD was really slow too, with avergae settings. But I simply have that asumed, like when one does a Max+Final Render lightmap. Or XSI. Is rays, radiosity. It's slow.
But is the needed price.
Anyway, most surely the tool eats a load of your free time, and I truely understand that
You did a load of work for irrlicht. I should find a permanent server and upload all the stuff I have from you -of the one you allowed me to post- as I think many people are yet dealing with *.3ds for scene levels!
indeed...if I find the time I should put as many freeware and open source files as I can upload and distribute (if allowed) , as lots of ppl ask for them in many forums.
however, I'm allways curious on your developments. those tools were very usable in games workflows.