just run the .octfile that came out of blender into fsrad then the oct file that comes out of that into irrlicht, no obj tools required. irrlicht has native .oct suppourt
Exactly...The good old murphy made a lot of my petitions a reality..I insisted a lot in obj workflows...
as is a general 3d format very supported by tools, specially good for the "poor man" ways..
Omaremad, a question. Are you sure to bet for oct? I allways was a bit down for the fact that it does not support normals for curved surfaces. Murphy did ok doing so, as , well, Fsrad itself does not support em, neither blender has a fast way to generate other thing than "all smooth" or generate the smoothing creases by breaking the mesh, a detail that makes not happy to some of us...
I guess...if u plan on using blender as the scene setup , which for that, my extra step of loading in the irrlicht viewer he made for the blender-exported-oct, works cool as allows a go back and forth fast method of checking, as...well...u never know well how stuff is going...
Yup, lamp only where allowed, if I recall well, but remember: u can do proyectors with meshes, ie like cones, or put a light inside a torcj holder, etc...I think we had a way to not export the fake mesh...
So, I much liked his MIM format; sadly, mim didn't make his way as to be supported fro ever as standard in Irrlicht oficial versions...
MIM
does support perfect vertex normals. Wings3d meshes wehre taken perfect, as well as OBJ+OBJ exports from Giles.
Normals where there as I made em in Wings 3d.
There's then many obj based extra utils he gently made...
obj2mim, my favourite, which did take the obj with texture,and the one with a lightmap tga, and converted in a perfect level ,lightmapped, wit h all perfect, and able to change by text quicly the lightmapping mode, etc, by me, the artist, also...
Oct to obj, which you already used, was another petition of mine...(good old Murphy

) , as so to allow the user fix or add stuff to the final level, ie, add smoothing normals, etc, etc. But I think there were more...
There's a mim loader some where(I have one, at least, maybe one of the latest)... The problem is also fsrad. It wont take normals in consideration, is not only that u loose them, but that it does generate lighting according only to flat surfaces! Do make th etest of adding a cilinder or cone, you will, see in your blender scene to be exported to fsrad as oct...
So, to me the blender route, better use a format like mim, or use a free lightmapper Like LMMAKER, and add a loader which loads great from there...The fact is you seem to like the lights stuff set up inblender, I do too...(but for a good check previous to export at the oct viewer, which wasbest, I remember I used change lights to spot, so to be able to raytrace shados and see how more or less lighting would go... There's as allways, a game of tweaking light colors, distance which light will achieve, and intensity, among other things...)
My main hopes with MIM was that...well, Blender yet does not have 2 uv channels, neither a solid lightmapping solution...was that it'd export as OBJ, you'd do in two steps if get raybaker from macouno to work well i ur case, or in one only step, only the obj with texture. If second case happened u'd need a lightmapper to generate that lightmap tga bitmap file. pitty is I dunno if there's one for Linux, really. In windows, there's Lmmaker, as the free one which I know has no limits in lm size, and supports smoothing normals...Some say is very slow, or have probs with large scenes...I dunno if there'd be a workaround for that, neither the conditions of those ofending 3d scenes...
Then use obj to MIM, and voilá.Way shorter than oct workflows, and more quality for the aspects I mentioned.
Imho that automap uv plugin looks very useful for level editing, kudos
I use Ultimate Unwrap, but for ppl more using Blender, it must rock
PD: I mean, the workflow of oct is good and works...is more up to each one about the flattened only problem..which as I say, is double...wouldnt be enough to just fix normals, or asign by code an autsmooth value...the lightmap was generated for all flatten faces....