free compiler with lightmaps?

[Guest]

couldn't a renderer like yafray be modified to be used as lightmapper? that would be cool because because quality would be nice (global illumination,...)!

i don't know much about raytracing or yafray's internals but wouldn't the only difference be shooting rays from the light map pixels instead of the camera plane?

[Guest]

I've updated my converters package.

www.geocities.com/dxlab/tmp/obj2ent_preview.html

Now it includes a OCT2LMTS converter and some enhacements/bugfixes on OBJ2OCT.

[Guest]

I've modified FSRad in order to add support for texture coordinates to ENT files. I'll release that and my converters next weekend

[cmoibenlepro]

I've modified FSRad in order to add support for texture coordinates to ENT files. I'll release that and my converters next weekend

COOL!
I'm counting the seconds before next week-end... lol

[vermeer]

woah

[nitroman]

Now it includes a OCT2LMTS

does it means that it is possible to create a lightmap with fsrad, then convert the map to lmts format and open it in an irrlicht scene using jox loader?

[jox]

Hi there! I'm back to business. Seems a lot has happend meanwhile!

@Lord Trancos: Great work so far! Very cool!

So OBJ is the source format now? How do you get the lights into FSRad then? Will it be (emissive) objects? Will it be be contained in a seperate file? How's the workflow?

Again, really nice work, keep it up!

ps: there's a little naming mistake in obj2ent_preview.zip: the folder names of 'oct2lmts' are called 'obj2lmts'...

[Guest]

nitroman, the answer should be "yes".
but bettwer if you wait for the next release.

jox;

So OBJ is the source format now?
yes.

How do you get the lights into FSRad then?
OBJ + Text file ---> converted to -----> OCT / ENT / ANT (ANT is the ENT format modified by me)

Will it be (emissive) objects?
Yep. The ENT (and ANT) files allow you to specify the emissive of each material, but..... WARNING: the texture does not make any job here.

Will it be be contained in a seperate file?
Yep. Like I explained above.

How's the workflow?

1st.
Modeler ----> OBJ
Notepad ----> TXT (yes.... we would need some scripts/plugins in our modelers to avoid using notepad)

2nd
OBJ+TXT ----> to -----> OCT / ENT / ANT

3rd
FSRad ---> OCT

4th (optional)
OCT ---> LMTS

[Guest]

Some days ago I emailed Paul Nettle (FSRad creator) if ENT files support UV coordinates.

He answered me today, and says that yes:

ENT files do support textures. For example, look at GeomDB::readENT() and
look for these three lines:

geom::Point2 t0 = p.tex[0];
geom::Point2 t1 = p.tex[1];
geom::Point2 t2 = p.tex[2];

well... i'm just a newbie on VC, and he is the creator of FSRad, but I still believe that maybe ENT files support UV coords, but FSRad doesn't load and use them. In the above example I don't see the variables t0, t1 and t2 being used later on that function.

So, it would be nice if another code takes a look to FSRad and tell us, what he/she thinks about.

Anyways, my FSRad is already done and will be released next week-end.

[Guest]

when i said "my FSRad" i mean "my FSRad MOD"

[nitroman]

Anyways, my FSRad is already done and will be released next week-end.

great news!

BTW, is there a way to use jpeg textures (instead of big tga) with lmts? It would be better for small games development (smaller texture size=less bandwidth to distibute your game/maps).
Of course I know there won't be alpha with jpeg but I don't care... I use tga could only for textures that need alpha (like windows).

[nitroman]

*sorry I typed too fast*

I mean:
I could use tga only for textures that need alpha (like windows).

[jox]

but I still believe that maybe ENT files support UV coords, but FSRad doesn't load and use them. In the above example I don't see the variables t0, t1 and t2 being used later on that function.

So, it would be nice if another code takes a look to FSRad and tell us, what he/she thinks about.

On the first glance I agree with that. They're not used. In the readASE() function it looks different:

Code: Select all

	poly.texuv() += t0;
	poly.texuv() += t1;
	poly.texuv() += t2;

Maybe he just forgot those lines in the readENT() function...

[Guest]

As promised:
http://www.geocities.com/dxlab/tmp/fsrad.html



Feedback would be appreciated.

[jox]

Very cool, thank you! Feedback will come!