Well I doubt i can compete with full commercial engines like A6 or Torque, even with good rendering.. its too much work I think.

Doing a collision system like A6 has would take at least a year on its own if not more. Physics would be hard, and networking? Phew.. not possible for me.

William explained my point very clear. Thanks. That is what I wanted to tell

And I see it the same way: We do not need all that when there will be static meshes (models and blocks) that get light-mapped with the help of a shadow-compiler. But the work-around could be another independent uv-set only for the shadow map and the option to blend both textures (colors and shadows) over each other.

Hmm, maybe I'm still not getting what you want, but I have the impression that you and William are very, very steadfast in explaining at length a demand for a second UV set, which is however a basic feature that any engine has.

I assume that you don't want to manually paint the lightmap in MED, so you just want to write an external program for importing a lightmap and its UV coordinates into a model at run time. This can be easily done:

1. Create a model with one or several tiled skin textures.
2. Use ent_mesh to get a mesh pointer of that model.
3. Get the vertex buffer. The vertex format is described under "Shaders".
4. Import your UV coordinates to tu2/tv2, and the shadow map to a material skin.
5. Render the model with an FF effect that blends the shadow map over the tiled texture.

Hope this helps - otherwise, I'm afraid, you have to explain your problem in more detail.

Static, lightmapped meshes will be a feature of the new rendering kernel that's currently in development.

Fantastic. Thank you for the response.

The new lightmapped meshes will save us alot of work and then we will not need this work-around anymore.

sounds interesting...

but can you get models affected by a custom light map below it just like with bsp light maps? (btw. it would be helpful also for other things if c_trace could return the hit triangle and the exact texture coordinates in this triangle.)

and a code snippet of how to work with the d3d mesh for that purpose would be nice. i don't think a ent_loadseconduvset(entity, filename) dll function would be very hard to do but i have a hard time navigating microsoft's documentation pages. is the vertex buffer all you need? wouldn't you also have to know something about the triangles?

This sounds intresting, but how would you go about implementing this? I guess I have similar questions as Ventilator pointed out...

btw - any idea when the lightmapping portion would be out in beta? less than 8 months? If so, i'd just leave all the levels that need lightmapping to be developed later. Otherwise would have to figure out how to get this second uv map technique working.

This is most exciting! So in this case the lightmaps would be externally generated from a 3D application, like Maya or Blender, right? It would be nice if player and NPC's were illuminated by the map in real time, but still it's no great loss compared to having no lightmap effect at all.

Since the lightmapping in the new kernel will be able to use normal static lights-- must the meshes surfaces be re-imported as octree instead?

Maybe the 2 UV solution would be more visually powerful, if you have better lighting controls in your 3D lightmapping application than the basic WED static lights, so you could use barn doors and scrims and create more complex directional lighting effects, use falloff distances, etc, than possible with wed static lights..

But which solution would run faster-- The fake workaround or the real deal ?

Well, I think lightmapping is the same speed either way, unless you mean calculations, but that doesn't really matter much to me. Your right that program(max, ect.) lightmapping offers a bit more abilities, but i'm sure placeing static lights in WED would be much much easier(especially if the textures of models show in the preview sometime soon + lighting) than baking it in your 3d program and exporting. For example, an average racetrack level from max(that I've developed) has around 40 individual meshs to export. To bake all this in max + exporting it all properly(plus the shader code, if indeed possible) takes up more time than it would to just do the lighting in WED and use that as a final product.

Hopefully theres an answer of when the WED version of lighting will be in beta... i'd like to try out the program version too, but unsure how to go about it(never programmed much shader code before, and dont know how to share texture coordinates from max-3dgs vertex format).

Thanks William, I get it now. Hm. Is there an ETA on the Beta-- will it make it under the gate before A7?

Bye

The new kernel is still far from finished - probably A7 - so the suggested lightmap importer would be the way to go.

Yes, you just need the vertex buffer, and just need to overwite the two floats u2/v2. This is the pseudocode:

Code:

---

LPD3DXMESH pMesh = (LPD3DXMESH) ent_mesh(entity);
BYTEPTR pVB;
pMesh->LockVertexBuffer(0,&pVB);
for (int i=0; i<numverts; i++)
{
  VERTEX_TLSHADED *v = ((VERTEX_TLSHADED*)pVB) + i; // see vertex format in "shader" 
  v->u2 = lightmap_u2[i];
  v->v2 = lightmap_v2[i];
}
pMesh->UnlockVertexBuffer();

---