AUTOMAPUV~ An automatic UV script for blender map makers.

[vermeer]

WOW thats a lot to read, i'll read it now but just a point to make, why do we need smoothed normals if we arent using dynamic lighting?

sorry, dynamic lighting?

Dunno what it means...unless means lights moving around or something...

any engine has opengl smoothing normals...

moreover smoothed surfaces? i exported an arc just fine.

But...did you add a lot of tris/quads for it? Did you try and make an arc out of just 6 segments and add smoothing normals to it (maybe splitting at the edges so make sharp borders of the bricks) ...and...well...fsrad, we Murphy and I checked well...does not consider smoothing normals in any way...neither oct format, nor his plugin of export from blender...

lastly doesnt blender average the normals on any mesh you want and the oct exporter exports these normals?

Blender can do smooth allnormals if you hit th ebutton or were already smooth...the oct exporter does export em flatten, no normals, unless I've come crazy or some really secret update has happened...

i exported and lightmapped meshes with flipped and "good" normals and they worked just fine.

dunno...unless you mean not inverted, not black artifacts...

you want perfect normals so curved surfaces are perfectly lightmapped?

I mean in any old engine there's smoothing normals,(smooth groups) , and also the lightmapper in teh 3d package, did generate lightmaps according to where there's a rounded normals surface and when it's flattened, so light will be a gradient, or cut planes of lighting...instead of considered as revolution continuous surface.

Look, I made a pair of blends for you, one faceted, one with smoothing normals, check that if you wish so, with oct and fsrad and finally the engine...

http://www.savefile.com/files/3118721

( oh, those are done with blender 2.42 )


and an screenshot of what I'd expect as an artist to see in the engine (the smoothed one. And with the "cuts" where eacatly I did em...)(click to enlarge)

for me the "normal" oct flow works fine, i have one mesh that is produced by clicking the go button on fsrad then importing in irrlicht, not to metion the higher speed as there is no need for double the polygons to be rendered, moreover with shaders we can truely render multitextured objects in one pass(some cards add extra polygons internally for lightmaps)

I have a suspiction you see curved surfaces rounded through the use of many polies (while then indeed would be flattens between the faces, and so calculated lightmap also as fsrad can do other thing...)

The lightbaker script is fine but it require mannual UV of the meshes for effciency moreover

To be true, even in jobs, I prefer manual making of the second uv channel, but yep is more comfortable an automatic one...Have u tested Archimap plugin for blender...it does that...besides...I do usually use Ultimate Unwrap for the auto stuff...actually I use blender little, tho I know well many of its uses.

it exports to one mega huge texture so it can be problematic If

you can resize it to smaller later...oh, you mean the great packer of fsrad doing 128x128 without sacrifying quality....yep, few lightmappers do it so good...But i cant stand no curved surfaces good shading...Murphy told m e adding that to fsrad, as he already has modified it, would have been a load of work...

its so impratical and time consumeing and not very hardware friendly.

is what u have in blender for now, but I guess stuff can be done giving it some effort by artists...

please show me artifacts that arise when using the oct method, maybe i can do some bug fixes

Would be cool if u could simply add smooth normals to the blender exporter, Murphy told me it didnt have em, and ideed, I never could see well rounded cones or cilinders in the viewers if exported as oct...but yes with mim...hmmm..so...? then is that irrlicht can do smoothing normals, no? As his viewers where simply irrlicht.

btw Spotlights are easily emulated and are better this way:

add a cone of mesh around a point light! You would need that cone anyway for the lamp/light source mesh

Yup, I mentioned to him above, I not only did those tries with Murphy, also many other sort of projecting meshes effects...is a new world... even more with multi coloured lights....

Btw blender can do smoothing groups if you were complaining about all smooth with this statement:

Quote:
other thing than "all smooth" or generate the smoothing creases by breaking the mesh,

Just go in edit mode and select faces then press smooth, the selected faces are only smoothed , the others remain unchanged.

is not exactly a pro solution...I'll tell u why. The other stay flattened , is not a hard edge between smoothed surfaces. If the other part was also curved, which is so often happenning, u'd be forced to see th eother part flattened. I meant, u can do with splitting (maybe best way is with P, detaching parts) , but neither is ideal. Yet the best workaround for now...

[afecelis]

wow! Ok Vermeer, I here now offer you your graduate degree in advanced blenderology!!!

I wanna check those files you uploaded. And now you bit me with the MIM bug... crawling thru my veins...need info...argghhhh!!

@Omaremad: I loaded the oct file in Irrlicht but it's not finding the texures so it only displayed my level with a weird square texture on them and no lighmaps. Does OCT require a set texture path just like My3d?

[afecelis]

Reading the forums I checked my textures error. Textures have to be placed in the same folder as your executable rather than next to your output.oct file. Funny, huh? But I can't see a thing of lightmaps. My level is to dark even with EMF lighting set to false.

I guess now it's a matter of playing with lighting options in fsrad. I'll try to find someone else's experience on this.

Ps. Someone mentions an fsrad viewer to check you lightmaps. Is there such thing?

[vermeer]

indeedy, for both mim and oct..

lol, I need to make and send u a huge email XD

I guess I'll be able to get from you a perm upload of mim tools with it, hehe


Just I'm delaying to the stuff, as am making full throttle graphics for the mate's project I'm in since a big while...

[afecelis]

NP Vermeer, take your time. I'll be glad to re-host all of that wonderful stuff

I just found the OCT viewer. It comes with the official fsrad (not murphy's hack that comes with OCTtools).
http://www.fluidstudios.com/pub/FluidSt ... ad-004.zip
Using it I cheked that lightmaps were indeed generated, but it's not showing difuse map info:

Not the best of the shots but... Anyway, now I'm more confused as of what I'm doing wrong. Is it in the blender part? the fsrad calculation? or the Irrlicht loading? or a mixture of all of them? I don't like it either to be forced to have the textures by your executable. Not a very clean game structure it will turn out to be (darn, I'm talking like yoda already!).

KK, back to experimentation. If any of you guys got some nice settings in fsrad to try out...

[omaremad]

Remeber this thread is about using fsrad!
If we use the blender baker we can use any format right?

anyway this is about fsrad and during its radiosity caculations the radisosity is done on per plane bounce method and not

per vertex meaning (averaged/smoothed vertices would be never taken into account since per vertex normals would be

diffrent within one face)
so it would affect the lightmap caclulation in any way if we added smoothed normals and it will definitly will not make

the mesh look better if well apply the normals after the lightmap!!! because its too late for that

UNLESS you have lighting turned on on the lightmapped mesh

Normals in fixed function rendering pipelines(real time without shaders) are used for only two things that affect the

visuals:

1-lighting
2-culling

and since lightmapped meshes have lighting off it makes no diffrence how good the normals are

Vermeer i dont really get all the fuss about normals, in your blender picture it looks smoother because there is a light,

blender allows you to see the smoothing even in solid by adding a "fake" light at the viewer's eye position

Still dont belive? export a smoothed cube from blender, as .x

run it in mview see it looks smooth right?

now, lets disable lighting
view->untick lighting

see it looks just like an unsmoothed cube!

and when we run meshes in irrlicht we ussually dont have lighting turned on


if we wanted perfect lightmaps that use the perfect smooth normals we would use blender's light baking script which doesnt

need fsrad, MIM, oct to obj or obj to mim or any of these tool

i tried this script long before this thread with many other solutions and found it too impractical for high speed

devwlopment and rendering

not to metion the high loading times etc... and low res sice the baker script isnt perfect and ussually needs sevral

attempts at tweaking to get the projection settings half decent for most of the mesh

this script was mainly created to save time on non realtime renderinsg where they can afford big high quality and single

textures.

i see the whole workflow of coverting between formats and having huge textures in the end extremly ineffcient in:

1-file sizes
2-rendering times
3-accuracy
4-hardware aprreciation
huge single textures cost more power than smaller textures that add up to the same resoultion as:

-Mipmap generation is slower with bigger textures
-if we exceeded the VRam imagine constantly sending that texture back and forth the AGP

another important point is that archimap operates on one single texture often result on squashing of faces that are

already thin to tiny proportions making them ugly

most specialised lighmapping tools such as fsrad divide the level into patcthes for better uv tesselation and stretch

reduction.

as a summary:

I fail to see the benifit of using complex workflows that lengthen devlopment time, increase efforts on the artist side,

slower rendering times for the light mapper and the hardware , longer loading times, more ram consuption (double meshes

remember) all to make curved surafecs look nice!!!!



if you have gone to the extent of rendering the mesh twice(2x polygons per frame) with all the previous draw backs to

make curved surfaces look better, why did you not invest in a few more polygons in the curve and save yourself and the

hardware the hassle!!!

its like the saying:

The smart one stitches with the donkey leg

from this ironic statement we can see yes it is smart and impressive to do hard things(to get nice normals the hard way)

but isnt it smarter to just do it the easy way.

I hope you like the moral of the story

here is a pic that came out of my work flow



see nice and simple

blender->frsad->irrlicht
fast simple nice on the hardware and the artist

besides its allot easier to learn for begginners

@afcielis:

Give the blend and the texures so i can see if everything is ok
btw the directory thing can easily be resolved by apending a path string to the oct loader
as easy as
texture=pathstring.append(texturename).c_str()

[afecelis]

Interesting! I'd like to check that fix. Do you have the modded file? I'm used to having the textures next to the mesh file. If possible email it to me or uplaod it somewhere to recompile the engine with it. I'll recheck my .blend file and link you to it in some minutes

[omaremad]

find this line in the oct loader

tex = Driver->getTexture(textures[i-1].fileName);

then do this

std::string filepath;
filepath.append("c:\......");
filepath.append(textures[i-1].fileName);

tex = Driver->getTexture(filepath.c_str());

rember the string.h

[afecelis]

here's my scene, nothing fancy, just a plane floor and 3 cubes:
http://afecelis.gdlib.net/Irrlicht/data.zip

about the fix; you mean add:

Code: Select all

std::string filepath;
filepath.append("c:\......");
filepath.append(textures[i-1].fileName);

tex[i] = Driver->getTexture(filepath.c_str()); 

after

Code: Select all

tex[i] = Driver->getTexture(textures[i-1].fileName); 

??

and what's that about string.h?

thanks for your help!

[omaremad]

the scale on your scene is huge!

its really dark on export but its textured, try scaling down and increasing lightpower in Blender not fsrad.

try more iterations if the results seem too "uniform"

<string.h> is part of std just place it in the header file of the octloader

and the the code i gave u replace the
tex = Driver->getTexture(textures[i-1].fileName);

with
std::string filepath;
filepath.append("./data");
filepath.append(textures[i-1].fileName);

tex = Driver->getTexture(filepath.c_str());

[afecelis]

thanks! I'll try it immediately.

About the code, you mean if using the loader as an external loader or modifying the source file? In such case (and checking your code) it will be defaulted to have the textures always in "./data", right?

string.h is already in the includes of the octloader.
I got this error:


ps. Forgot to ask: about the usage of your script; was it used ok in my file?

[afecelis]

you were right; rescaled the scene and it's showing ok and properly textured. I'm not getting any lightmaps generated after running fsrad though.

[hybrid]

std:string would require <string> instead of <string.h>, but better use core::stringc.

[omaremad]

You are getting lightmaps!

Look at the boundary between the cube and the plane, see the shaddow, it because you have to many lights, try and colour them.

for the proper method of created "path" options for oct loader you would have to make these mods

ps: i never tested these, i just made them while reading your post


in cscenemanager.h public section

add

Code: Select all

char *octpath;

virtual void setOCTPath(char * path);

in the csenemanager.cpp

Code: Select all

void CSceneManager::setOCTPath(char * path)
{
    octpath=path;
}

in the isenemanager.h
public section

Code: Select all

virtual void setOCTPath(char * path)=0;

ine the oct loader i gave you replace the

filepath.append("./data");

with

filepath.append(scene->octpath);

[afecelis]

whoa! that's what I call tech support!

thanks Omaremad. I'll fix them as soon as I return home. Thanks for everything. I hope we nail it this time so that I can work on a better level with lightmaps. Many are sending pm's asking about the tut.