thanks for the example! looks simple at a first glance...

but i guess the vertices aren't exactly the same as in the mdl7 file? for example they get doubled at uv-seams? but what if the light map uvs have totally different seams? wouldn't that require to create a completely new vertex buffer with vertex doubling taking into account both uv-maps?

...
bad news about the rendering kernel...

The lightmap must use the same vertices as the model. You can have different sets of UV coordinates, but you can not have different sets of vertices. Thus, you need anyway to read the mesh in the first place before you can create the lightmap for it.

The vertex buffer already contains doubled vertices when the model has seams.

hm... this makes it a bit difficult...

Quote:

---

The vertex buffer already contains doubled vertices when the model has seams.

---

yes, but only for the first uv-map. the point of light map uvs is that they are different and can have different seams though and then the required doubled vertices aren't there.

would it be possible with the sdk to create my own mesh buffers (for example write a collada model loader dll and not use mdl7 at all)?

and what about the other question? could models get affected by a model light map below them somehow (without implementing your own c_trace which can return the needed information)?

Would anyone know how to further develop that lightmapping code...? Perhaps it might still work, if indeed it allows for 2 uv unwraps per a model. Unfortunatly, I don't know enough about shader code to peice the rest together. Thanks.

i don't have any experience with d3d vertex buffers but from my understanding it only could be done flawlessly if it were possible to write your own mesh loader (best for a format which supports two uv-sets so that you don't have to do hacks like using two different versions of a mdl7 file).

just replacing the uvs like in jcl's example isn't enough. you could load a light map uv-set but it still had to use uv-patches with the seams at the same place in the topology as the other uv-map (don't know how to explain it better). this isn't very useful...

i could be wrong though.

it also would be nice if models could react to the brightness below them just like with bsp light maps but probably this currently wouldn't easily work either.

Quote:

---

you could load different light map uvs but they had to use the same uv-patches (-> the seams at the same place in the topology - don't know how to explain it better) as the other uv-map.

---

Considering how lightbaking works(creates lightmap on a new non-tiling unwrap of the model), this sounds rather useless(unless i'm not understanding things)... perhaps JCL would know of an alternative? How had the old games(Donkeykong64, ect.) do their lighting on models? there must be a simple solution, as these games were released almost 10 years ago, long before shaders. Lighting is an essential part of the scene, and per-pixel lighting is not the answer using 3dgs right now(much to slow beyond smaller rooms). Considering A7 won't be released for a while, it looks like were left out in the blue.

@Ventilator: A lightmap does not need its own "seams". Any place in the UV mesh corresponds to a XYZ value to calculate the lighting for, so as long as UV mesh parts don't intersect, the content of the lightmap is completely defined by the XYZ values of its UV coordinates.

Most lightmappers first unwrap the UV mesh, then apply a linear transformation (u' = a*u + b) to the UV coordinates to map them into the lightmap space, and last add an uv offset to ambiguous mesh parts (same UV but different XYZ). I don't know of a lightmapper that would create a completely independent UV set, but this is theoretically possible.

For importing an already-existing lightmap that does not contain duplicated vertices, you just need to go through all uv values that are not already set, and then set them to the uv values of the next vertex in the mesh that has the same xyz coordinates.

Hope this makes sense.

@William: This sort of discussion leads to nothing. If you really want to write a lightmapper or a lightmap importer, I think you need first some understanding of meshes, UV coordinates, DirectX, vertex formats etc. Otherwise I can see that you feel "left out in the blue", but can't help it.

i think i see how a light map doesn't absolutely need its own "seams". (so were my clumsy previous posts kind of right? the light map uvs couldn't have its own "seams"?)

Quote:

---

I don't know of a lightmapper that would create a completely independent UV set, but this is theoretically possible.

---

i guess most of us don't think of some light mapper done specifically for games but programs like 3dsmax, maya, lightwave, modo,... it would be quite cumbersome there to make sure that the light map uvs behave right. to get light map uvs you usually just would want to create an automatic atlas mapping or something like that and not spend a lot of time with manually tweaking anything to follow any rules.