free compiler with lightmaps?

[vermeer]

some small adition.

VRML 2.0.
(supported by BOTH wings and blender.yet two know if any of this is exporting lights. Also supported by Max, natively, or was so in the past.)

VRML 2 specs:
http://vag.vrml.org/
http://webspace.sgi.com/moving-worlds/


It supports lights.Now it will depend on which apps export lights in it, and well.


from here, seems it does not support area lights

but yes spot, omni directional (paralell, infinite...the sun )

but...in the good side...it supports -seems so- exporting:

"Point Lights
Figure 20.1
The rays from a point light radiate out from it in all directions.
Directional Lights
Figure 20.2
The rayes from a directional light all project in the same direction..
Spotlights
Figure 20.3
The rays from a spotlight radiate within a strictly defined area.
Coloring Lights
Ambient Light
Light Attenuation
Multiple Lights
The Headlight
Shadows
Lighting Flat Shapes"


VRML 2 is ascii
some examples of its code, in relation to lighting!

http://www.cg.tuwien.ac.at/studentwork/ ... vrml6.html

[vermeer]

YAY.

wings vrml 2.0 export does not export lights, but...

Blender does! Look. (extract from the vrml file)

As u see, Blender = power.

Has quite a number of light types, and many settings for lights.

I think is more powerful for scenery than Wings, but also harder to learn. being Anim8or slightly easier than Wings.

And anyway, as vrml support is done in wings, you could add what's needed to export lights field...hmm...now...or yes, but is included in main distribution, and ...well, you could maybe do a modification of that part...I don't know...
See it complex. Maybe for now it'd be Blender.

From VRML 2.0 file...

NavigationInfo {
headlight FALSE
avatarSize [0.25, 1.75, 0.75]
} # NavigationInfo

DEF Lamp_004 DirectionalLight {
ambientIntensity 0.2
intensity 0.666666666667
direction -0.9961 -0.0343 0.0818
} # DirectionalLight

DEF Lamp_003 DirectionalLight {
ambientIntensity 0.2
intensity 0.666666666667
direction -0.9824 -0.023 0.1854
} # DirectionalLight

DEF Lamp_002 SpotLight {
radius 18.4775906502
intensity 0.666666666667
beamWidth 0.392699081699 # lamp.spotSize 45.0
cutOffAngle 0.388772090882 # lamp.spotBlend 0.15000000596
direction -0.147 -0.989 -0.003 # lamp.RotX=-4.314 RotY=-12.738 RotZ=91.961
location -0.499 8.679 0.377
} # SpotLight

DEF Lamp_001 DirectionalLight {
ambientIntensity 0.2
intensity 0.666666666667
direction -0.9956 -0.0886 0.0319
} # DirectionalLight

DEF Lamp PointLight {
ambientIntensity 0.2
intensity 0.666666666667
location 0.0 7.0 10.0
radius 29.9999828339
} # PointLight

DEF Camera Viewpoint {
description "Camera"
orientation -1.01 1.54 0.48 1.11
position 6.28 5.87 5.00
} # Viewpoint




Hm..vrml 2.0 : camera, light, animation support...starting to think is a good format for scenery... If it supported two uv channels it would be simply perfect.

[vermeer]

http://www.vrmlsite.com/

specs
http://www.arch.soton.ac.uk/Manuals/VRM ... index.html

[vermeer]

http://hendrix.imm.dtu.dk/staff/fnielse ... esRef.html

[Guest]

As already was said in this thread, the two pairs of texture coordinates are only needed once you have the lightmaps, so there is no need for them (i think).

About the lights, i think that there is also no need to place them in the same file that the geometry,

Most of powerful 3D editors will allow you to build a script or plugin that would allow you to export light info to a file.

So, if we want lightmaps we only need ways to convert from our favourites 3D modelers (not just one) to the file formats used by the lightmapers.

Once the model is lightmaped it will be in a format like OCT or LMTS that aren't standards, but are quite simple.

[vermeer]

I said one for avoding you all work...


but hey, if can be done with Anim8or(windows only,less light types, just easier), Blender , Wings , great.

[nitroman]

Most of powerful 3D editors will allow you to build a script or plugin that would allow you to export light info to a file.

So, if we want lightmaps we only need ways to convert from our favourites 3D modelers (not just one) to the file formats used by the lightmapers.

Once the model is lightmaped it will be in a format like OCT or LMTS that aren't standards, but are quite simple.

I agree.
We need to choose what lightmapper we want to use.

But I think that we should be able to use any modeler/3d editor that we want to.
To do that we have 2 possibilities:
-Create a plugin/script to export to the lightmapper format.
-create a converter between a standard format (like 3ds) and convert it to the lightmapper format.

the second possibility can look better because we can use any modeler in theory and we will be able to export it to the lightmapper.
But most modeller don't support completly a format but export only what they think is the more important (like geometry, textures, etc)
other things like lights usually don't worth the work for the modellers developpers...

also of course for lmtools the lights can be in a different file exported by the script. But I'm not sure if your can do the same thing with fsrad.

[vermeer]

the fact is I am finding no software exporting lights in 3ds...Not anim8or, not Blender (both I checked) ...hmmm...adn maybe wrong, but though can't read a 3ds, can check with my tools...i'd say wings 3ds exporter either export lights.

That is I'd discard *.3ds right now.

(open fx vrml does not export lights, only cameras(from animator module). its 3ds doesnt either as is only being exported from Designer module, which has not got lights.)

FSRAD already reads ASE. The pitty is finding an ASE exporter tool that allows u to build lights and it's free (being max the best one)

Prettty Polygon Editor have it, but from features list I suspect no light export, besides found the ui really hard to use...

VRML 2.0 format does support ase. Curiously, no lights exported yet from Wings 3d (but the format export is there) .My latest inclination is for blender VRML 2.0 native export, that export EVERY complex light from Blender, or Anim8or ascii native format *.an8.

The advantage of vrml 2 in blender, is, is a format widely used by many tools (max also: max users could use it too, specially if max exporter exports light, which could be.I have found several free vrml editors, but a bit poor the majority, being Blender much better)


So, I'd say finally...my 2 cents...my opinion..finally...Blender. Works the same in linux, Mac os, and windows. Is the most powerful one, and I can explain in a pargraph how to create lights in an scene, that only part is easy.

Adding some objects is way easy too. that is far from using Blender for every task.,Besides, people get familiar to it, and with its md2 and x export integrated plugins (well, md2 needs to be run from text editor, easy) ppl would start to familiarize with the character animator tool, too. One learning--> two functions for irrlicht. And it'd be in the open source, multiplatform field .

As you wish, I see it clear, though...till new info comes, of course


new info can be what I could understand from last post from trancos...that for him or Jox it'd be dumb easy to write a text file export using python from blender (anim8or is closed, you only can use the file it saves.)

BTW, if vrml2 does the job in blender...


I don't know, I'm not a coder. I'll shut now my big mouth.

[Guest]

This is the approach I think that would be the most flexible and powerful.

Get a simple and easy file format like OBJ or 3DS, plus more data on another file (generated by each modeler we want using a script or plug-in) and mix them to build an ENT file for FSRad (or a LMTS file )

This is what i made for LMTools.
A file with geometries (LMTS) and another one with lights and other data like lumel size, or if a subset doesn't want lightmaps.

Example (for FSRad).
- Get a OBJ or 3DS file from your modeler.
- Use a script or plug-in in your modeler (or the notepad ) to output more data (in text format) in another file (let's call it MOREDATA.TXT) that isn't in the OBJ/3DS file. Like lights and the list of polys that are emmiters.
- Use a tool we can make to mix OBJ/3DS data and the MOREDATA.TXT file to build a .ENT file.
- Then, use FSRad to build your lightmaps.

The good thing about this is that we only need one or two converters:
- 3DS + MOREDATA.TXT ---> to ENT
- OBJ + MOREDATA.TXT ---> to ENT

And a simple script or plug-in for each modeler, to output the MOREDATA.TXT file.

I think this will be the best.
In fact, if you want right now to use Blender to build a level and use LMTools to build the lightmaps you only need to export your blender data to 3DS or X file format (and them to LMTS using LMTools) and to write a script to tell blender to output your lights in a simple text file.

Quite easy, quite powerful.

[vermeer]

I see...

I'd leave out 3ds. It has a load of problems for the artist.
(wont list them again )

While those problems do not happen with X and OBJ.

x supports two uv channels. I know you are considering the lightmap tool will generate the second uv channel, but...It's good having exta ways.
also supports vertex colors.

In the other side, obj is a bit more standard than x. And supports smooth groups. While I think X only supports smooth shading with autosmooth value (which is usually enough) Obj respects quads, but engines use to deal with triangles, anyway. OBJ has only one uv channel, like 3ds.

well, we're in a point I'll sit down and watch. I can't code

[jox]

Sounds gooood!

Ok, unfortunately right now I'm a little stressed with (other) work and tomorrow I'll be out (of country) for about 10 days...

But I'm sure you'll keep it rollin'!

Maybe when I'm back I will concentrate on the FSRad->Irrlicht route. I've already made some research and stuff on the OCT format. Wait... I'm having a vision! I'm seeing a COCTFileLoader class!

Maybe you got some results by then as well.

I think 3DS/OBJ+TXT to ENT converters is a good idea. Another Idea would be to directly write loaders for FSRad. This would shorten the work flow a bit and make everything more elegant. But maybe it's easier to write a converter.

[Guest]

Looking at FSRad source code, and if I'm not wrong....
- ENT files doesn't have lights at all. (Materials are emissive, so no lights needed)
- OCT have just point lights (no spot, and no directional) that are converted to "patches". With ASE files the same is done.

So.... there is no need for lights if we want to use FSRad.... directional can be done with a light very far and bright, and spot can also be done if the light it's placed inside a cone (like in real world).

Altrough that,... for each light we need geometry....

What do you think about?

[nitroman]

Looking at FSRad source code, and if I'm not wrong....
- ENT files doesn't have lights at all. (Materials are emissive, so no lights needed)
- OCT have just point lights (no spot, and no directional) that are converted to "patches". With ASE files the same is done.

So.... there is no need for lights if we want to use FSRad.... directional can be done with a light very far and bright, and spot can also be done if the light it's placed inside a cone (like in real world).

Altrough that,... for each light we need geometry....

What do you think about?

It's a good thing to know.

[nitroman]

also does LMtools support area lights and emmisive materials?

maybe we don't really need to use fsrad.
It will just need to correct the bugs that Jox said he got during the generation of the lightmap.

[vermeer]

what we think? I think I was not wrong when I thought is always good to have two methods

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

Trancos, do you think fsrad allows spot lights but is just they didnt add all the stuff to the ent and oct formats? (I think I read those were more prototypes, not ended stuff...)


[ BTW, I'm happy I purcashed Giles... ...And in that matters...it'd be nice to know if it's now possible to load an x file with its standard 2 uv channels, and a lightmap assigned to it: that is, if any highend package user, or Giles user, can make lightmaps for irrlicht in the way are done in comercial games... I don't know in which state of the thing is that matter...if somebody knows, I'd be glad to know... ]

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..

Of course, radisosity is always better than othe rmethods (if used well) , but... I have not seen results with the alpha of yours, yet. (and I mean, used to its maximum posibilities )

The fact is that...as I see it...the most important part is the control over the lightmaps...If one can't easily put in the level a directional, spot or omni light to build the ambience wished...then it's better a non radiosity one...

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: ie: All reflects all, but always depending on existing lights, and every thing affects with it's color radiation to what is surrounding. Of course, this solutions are the most realistic. I have worked to make this for a comercial game, and using th ehigh end raytracers for this, the result is really life like, very different to what just is a lightmaps seen in a q3 bsp...

Anyway...if I had the time I'd open other thread and ask for someone test for me a lightmapped with giles *.x file...But got no time (I mean, I have it, but using in making a character, I mean when I'm not posting ) fo rwhat is making the level.

Seems however was a great idea to do the lmts alpha support. Fsrad...I don't know how can I guess more about what can it support "forcing" it a bit...

ANYWAY....i ahave always been afraid of this :

[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]

What's that? Is it that depends on baking vertex colors and that's why it needs so much hi res mesh? ...Does the lightmap can be asigned to the original low pol mesh without loosing accuracy on the uvs for lightmap?

Anyway, I'll know a bit better...reading at flipcode, readme, and the site, to guess things... :

Don't expect to view your radiosity results right away -- you'll either need to read/write the supported formats, or hack your own format into the source (no example data files are shipped with this alpha release.)
...
Update (v004) includes only one small change to the ASE file support. ASE file support is just temporary code and should not be expected to be production-quality. Write your own importer for production quality code.
...generate the original cornell box, but it takes me about 12 seconds on my 1Ghz P3
...
It's also a lightmap generator/packer; it will generate tightly packed lightmaps for an entire dataset and generate proper UV values for the lightmaps. In other words, you want lighting for your game, you just hand your geometry to this tool, and it spits out your lightmaps and UV values.
...
Geometry is stored in a clipping octree, and at each octree node, a clipping BSP tree is built. The BSP uses the a new generation technique that has proven to vastly improve the speed of building the BSP as well as great reduction in tree depth and splits. From this, we perform the radiosity process on the precise visible fragments of polygons.
....

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