ahm... just to your info: this is exactly what the static mesh support in a7 is supposed to do. so if you wait some months, you#ll get it with a7.

the greatest disadvantage would be that the shadows are only baked, move the chair in franks example and the scene will look odd. so this metod would only be good for an unchanging lighting situation in combination with immovable objects. rather limited, if you ask me.

I think external modelling applications will always do a better job at lighting a scene than WED. For example WED shadows don't have realistic penumbrae.

Quote:

---

the greatest disadvantage would be that the shadows are only baked, move the chair in franks example and the scene will look odd. so this metod would only be good for an unchanging lighting situation in combination with immovable objects. rather limited, if you ask me.

---

The same goes for the upcoming static mesh support, exept that static meshes truely CAN'T be moved.

Ok everyone! Good news!

I dived into D3D and it's really not all that hard

I have found a way to do this and maybe I can release a rough plugin as soon as tomorow. A touched up version should be done at the end of the next weekend. I have exams next week, so I can't work on this during the week..

What I've got now:
A plugin that can copy the normal UV Map to the second UV map. I can test this with two small shaders that use either TEXCOORD0 or TEXCOORD1 for texture lookup. When I launch my app, the warlock looks normal with the TEXCOORD0 shader, and messed up with the TEXCOORD1 shader. If I call my plugin function, the TEXCOORD1 shader will look correct (because the TEXCOORD0 was copied there).

So the only thing left to do is write a function that can read in the UV coord, instead of copying the first UV.. I hope the skin points exported by 'export skin mapping' in MED are in the right order, or I will have to come up with something clever..

@Ventilator: the vertex format used by 3DGS already has 3(!) texture coords per vertex, thus no need to duplicate vertices.

EDIT: could someone (frank?) send me a model with 2 UV maps and a shadow map? You could send one .mdl with a normal diffuse texture and the normal skin mapping, and another one with the shadowmap and different UV mapping. My email is taco dot cohen at gmail dot com.

Thanks for looking into that!

brilliant! Very exciting news, Taco

I knew it couldn't be that easy or someone would have done it !

So I understand the core of the problem now: a vertex can have multiple skin points, even on a single UVmap. Ofcourse..

I wonder, though.. If you where to edit the mesh, breaking vertices everywhere, wouldn't that affect the shading? When a vertex (in 3D space, not on the UV) is duplicated its normal cannot be interpolated and you will get 'flat shading'. Maybe this just isn't a problem when all the lighting is in the skin anyway?

I looked in the sampledll and it uses d3dx9.h not d3d9.h. This file is included in the directX SDK, which you can download from microsoft. The code I have so far (quick and dirty without much error handling):
Code:

---

DLLFUNC var assignUV(ENTITY* ent)
{
   if (!ent) return 0;
   
   LPD3DXMESH entMesh = (LPD3DXMESH)ent_mesh(ent, 0);
   int numVertices = _INT(ent_vertices(ent));
   
   VERTEX* pVerts = NULL;
   entMesh->LockVertexBuffer(0, reinterpret_cast<void**> (&pVerts));

   for(int i = 0; i < numVertices; i++)
   {
      //pVerts[i].tu2 = pVerts[i].tu1;  // Copy v1 to v2
      //pVerts[i].tv2 = pVerts[i].tv1;
      //pVerts[i].tu1 = 0.0f;
      //pVerts[i].tv1 = 0.0f;

      pVerts[i].tu2 = 0.0f;  // alternative: empty v2 (seems to contain v1 usually)
      pVerts[i].tv2 = 0.0f;
      
   }

   entMesh->UnlockVertexBuffer();
   return _VAR(1);
   
}

---

pVerts is just a pointer, so using [] translates to pointer arithmetic. It's the same as &(pVerts + i), it moves the pointer ahead i * sizeof(VERTEX) each time (sorry if you knew this, I have no idea of your C++ skill but I thought this was pretty smart ).

the vertex struct also contains the normal. the normals of broken vertices could all point in the same direction so shading shouldn't get affected. but there are cases when the normals get recalculated (ent_fixnormals(),...) and i am not sure how this could get handled. maybe there is some other additional buffer which contains information about which broken vertices should be handled as a single vertex.

thanks for posting your example! i think i understand how arrays and pointers relate to each other but a reminder is always good since i still sometimes make mistakes with it.

my example from yesterday looks similar. not sure what's wrong with it but i will experiment...