I don't think that any lightmapper today requires that you manually tweak the UV values. All lightmappers calculate their uv values themselves.

i think we miss each other's point...





the first uv map is for the textures (one projection from the front and one projection from the side). the second uv map is for the light map (an automatic atlas mapping done in modo).

could the light map uvs be loaded into the vertex buffer without problems or not?

Sure. The only requirement is that both uv maps use the same XYZ positions, which is the case in your above image.

The example is not good, though. Your texture uv map is missing the back and right side, and the lightmap contains gaps between the squares, thus using unnecessary extra vertices. If the lightmap does not contain more vertices than the texture, you can import it straight into the mesh. Otherwise you need to increase the vertex buffer by duplicating vertices, as in the the above case. You must then generate a new mesh that would be a little slower to render.

If you want to write a lightmap importer, you can contact me by email when you encounter a detail problem - for instance, how to replace the mesh of a model. I'll help you. It should not be very difficult.

the projection of the back and right side is overlapping with the front and left side which sometimes makes sense but it just was a quickly done example... in my opinion there seldom will be the same amount of vertices in both maps and that's what i wanted to point out!

how would a new mesh get generated? (that's what i meant all the time in my above posts with having to do "a complete mesh loader" instead of only having to add the second uvs to the already existing vertices!)

i guess this would also involve generating a new index buffer?

...
at least i wasn't talking total nonsense - i just didn't explain it in a good enough way.

Yes. When increasing the vertex buffer, you also need to modify the index buffer.

It would make matters easier when your texture mapping would map all parts of the model without overlaps. This way the light mapping does not need extra duplicated vertices. The lightmaps I've seen so far contained less vertices than the texture map, and also did not contain the gaps and separated parts of your above example.

In such a case it would probably be easier to create the mesh from the lightmap, and import the texture uv afterwards - not vice versa.

what most of use would like to do is using tools like 3dsmax, maya, modo,... they are no game specific light mappers. their automatic uv-unwrapping algorithms most likely are quite generic and not optimized for this purpose (but their advanced renderers are great for baking lighting into textures). with all the freedoms these tools allow in texturing, i think for doing a robust importer you better shouldn't expect the uvs coming out of there to behave in a certain way.

maybe you could post a screenshot of how the 3dgs light mapper packs uvs?

...
i don't know yet when/if i would try to do such a light map importer.
- i currently don't have much time
- i would have to do some reading about these d3d buffers
- the %$"§$% visual c++ express doesn't come with win32 support out of the box
- downloading the needed huge sdks is stupid with my monthly bandwith limit

...but thanks for your offer to help!

...
would it be a lot of work for you to change c_trace so that it also could return the brightness of imported model light maps? in case we use model light maps it of course also would be nice if entities could react to them.

Hi,

If anyone could pull it off, I bet it would be you Ventilator, though it does look like a huge chunk of work. The idea of using trace to get the lightmap value is a very good idea, this could be a great workaround to the reaction to brighness issue.

I noticed this thread here http://www.coniserver.net/ubbthreads/sho...;vc=#Post679930.

How is this different from what is being discussed here?

Seems lightmaps are feature flavour of the month. As you can see, I've been searching for a shader that will blend a lightmap if the UVs are the same until the engine has better capabilities for this.

It will have to be done for the new scene management anyway, so I expect we will see it eventually. Sooner rather than later would be good.

To that end, here are two models exported from GILE[s]. One mapped with the lightmap and the other with the texture. Perhaps this will help?



Render from GILE[s] with lightmap applied



separate models in MED, one with the texture applied and the other with the lightmap.

The models: download

thanks for the gile[s] example! interesting...

it is a dedicated game light mapper and its uv map doesn't really look different to the automatic atlas mapping of tools like modo or maya. there also are gaps. i don't think the gaps are a disadvantage. i could imagine that there would be more light map artifacts at some areas if there were no gaps.

The gaps are essential, especially if the texture is low definition. The reason is the pixels will overlap the borders. It depends how you created your model, though. Also, higher end apps allow more options. Lightwave lets you adjust the size of the gap and whether the texture should continue around edges or not.

GILE[s] makes the task a bit easier because that is what it is designed for.

Will that be useful for making a lightmaping plugin?