free compiler with lightmaps?

vermeer · Post by **vermeer** » Fri Jul 30, 2004 7:19 am

todo:

* Calculate proper normals in OCT file output

Electron · Post by **Electron** » Fri Jul 30, 2004 12:32 pm

This whole thread has my ignorant brain confused. Isn't a lightmap simply a grayscale texture that could be saved as bmp, tga, jpg, etc? Then it could be added to a model using the EMT_LIGHTMAP or similar material types. I think I'm definitely missing something here.

Fussel · Post by **Fussel** » Fri Jul 30, 2004 1:00 pm

your are right (exept for the greyscale: the lightmap can be crayscale, but it can also be colored(if you have colored lights))

Guest · Post by **Guest** » Fri Jul 30, 2004 1:09 pm

nitroman, lmtools only support, ambient, directional, omni and spot.

vermeer,

Is no good if one can't position some spot lights in an easier way...

Well, in real world light emitters aren't invisible; so creating geometry should not be too bad.

fsrad allows spot lights but is just they didnt add all the stuff to the ent and oct formats?

As I said in OCT an ASE format the (omni/point) lights are converted to patches (geometry). So I think FSRad doesn't use lights in the way we understand them. Just geometry and emissive materials.

it'd be nice to know if it's now possible to load an x file with its standard 2 uv channels

are you sure .X supports two UV channels ?
As far as I know (don't believe me i really don't know) .X supports some sort of "user data", but this means that other modelers will not use that data.

If your lmt tools allow spot...and you already added the alpha version supporting the normals per vertex for curved surfaces... I'd have to make a test with it, and see if it'd be a real, real difference with FSRAD's radiosity..

It's an alpha; not tested well, not finished; as I said, right now, to use normals you should disable shadows. So it's just a preview. Right now the alpha "sucks" for real usage.

If one can't easily put in the level a directional, spot or omni light to build the ambience wished...

to use fsrad we should change our mind, light emitters (the sun, moon, a lamp,...) aren't invisible in real world. Each light needs geometry.

Emitting materials...how's that? each material is emitting light...well, in real life is so...each thing reflects radiation, a part of light wave, certain frequency...but always depending on lights existing

let's say that the sun or a lamp it's a geometry with a material with high emissive (i'm not talking about ambient or difusse) values.

[quoye] slice polygons when necessary to allow them to stay within the lightmap resolution and illuminate the scene using a very precise radiostiy solution[/quote]
Lmtools have the same issue, but instead of spliting the poly it will warm you and will use the max. resolution for the lightmap.

When building lightmaps you have what is know as lumel size. This is the size of a pixel of the lightmap in real world. As i said in lmtools help files:
"So, if you have a wall with 80 units of height and a lumel size of 8, the lightmaps used on that wall will have 8 pixels of height."

So if the max lightmap size is 256x256 but the polygon need a lightmap of 300x120, FSRad will split that poly. While LMTools will use a 256x120 lightmap.

The more I think, the better I think it's been to integrate LMTS new alpha version into irrlicht...

Forgot the alpha till i finish it (maybe these hollydays). To use the official release or the alpha you just need a LMTS v4 loaded, and if i'm not wrong, somebody on this thread has done it.

Electron, a lightmap doesn't need to be grayscale since lights can be other color than white. [/quote]

Guest · Post by **Guest** » Fri Jul 30, 2004 1:17 pm

"So, if you have a wall with 80 units of height and a lumel size of 10, the lightmaps used on that wall will have 8 pixels of height"

(above was wrong)

pd- Maybe I'll begin this evening a tool to convert from some format to .ENT

guest_vermeer · Post by **guest_vermeer** » Fri Jul 30, 2004 6:21 pm

thx for the explanation of emitters...now I understand it and yes, is like in real life, so, cool...

Yes, directx 8 has 2 uv channels, inside the x file.

I knew it,(first time I read was at msdn for dx8.x ) but double checked now with Ultimate Unwrap, which supports dx 8.0 and 8.1.

I think dx9 does it from an external file...I like less that solution..but this way it can do many uv channels more and better multitexturing...but all I insist is keep compatibility with dx8, as most packages support only 8, and anyway, the dx9 engines I have tested with, can load a dx8 bones&weights files, or geometry files....

so, yep, then from what you say I agree on is a good idea to support fsrad.

nitroman · Post by **nitroman** » Fri Jul 30, 2004 7:10 pm

so, yep, then from what you say I agree on is a good idea to support fsrad.

yes supporting fsrad is a good idea. But for now, lmtools is more than enough for me.
I tested to load the sample map with the lmts loader made by jox and it work perfectly.
And I must say that the quality is great. Test it yourself fullscreen with quality settings set to high with a high resolution... It's already very good...

Maybe it's not perfect, because normals are not supported so terrains would look bad, and the alpha support normals but not shadows...
But it's enough for me for now.
Thanks everybody.

Let's wait for the holydays so lord trancos can finish the alpha... or later there will be support for fsrad...
anyway I can continue my work on my game because there is now a free alternative to bsp as I wanted.

anyway my maps won't look very good because I'm not an artist (It's only an hobby for me and I'm not professional... )

THANKS!

Guest · Post by **Guest** » Sat Jul 31, 2004 4:54 pm

You will not believe me, but... while I was writing my OBJ to ENT converter I noticed that something was wrong...

Not, it wasn't that ENT didn't have normals... was something worst.... ENT file format doesn't have texture coordinates!!!!!!!!

... i need to think about this ...

gest_vermeer · Post by **gest_vermeer** » Sat Jul 31, 2004 6:17 pm

Are u sure..??

woah..

Fussel · Post by **Fussel** » Sat Jul 31, 2004 6:17 pm

perhaps adding support for b3d files would be a better solution?..slimshady can read x and 3ds files and you can place the lights in slimshady very easy..and the quality seems to be ok

guest_vermeer · Post by **guest_vermeer** » Sat Jul 31, 2004 6:21 pm

Big load more packages more supporting x files than b3d files...

Fussel · Post by **Fussel** » Sat Jul 31, 2004 7:16 pm

sure, but not for free or not with lightmap calculation, so instead of writing difficult im-exporters for fsrad to use this, it would be easier to add b3d support for irrlicht

vermeer · Post by **vermeer** » Sat Jul 31, 2004 8:59 pm

hehe, you'll still need a lightmap software to generate it, b3d format supports 2 uv channels, like x, but does not do anything else...anyway, nor x or b3d are taking part in this. Is just they are adapting FSRAD and LMTOOLS to export their lightmaos to Irrlicht.

B3d is a format, not a lightmap generator.

Fussel · Post by **Fussel** » Sat Jul 31, 2004 9:54 pm

yes i know..but there are lightmap generators that put out b3d files and lightmaps, so instead to have a lot of convertig for fsrad you could use for ex. slimshady to import the level in x oder 3ds format..place lights, generate the lightap and the b3d file and load them into irrlicht

nitroman · Post by **nitroman** » Sun Aug 01, 2004 1:48 am

Why use slimshady when LMtools give better results and already works with Irrlicht?

Irrlicht Engine

free compiler with lightmaps?

Lord Trancos

Lord Trancos

Lord Trancos