[Plugin] Import von 2. UVMap / Import of 2nd UVMap

honestly I don't know exactly!
I caught some bits and pieces from JCL and some more technical oriented people!

as far as they say it is possible to access and modify the data within the mesh of a model using a plugin!

it is possible! it just isn't as simple as it first seems.

i guess someone with a lot of direct3d experience could do such a plugin in 2 or 3 days but these people are rare here on the forum and probably wouldn't like to work for ~5€/hour. i think i would be able to do it too but it would take me 2 or 3 weeks full time because i would have to read a lot and experiment a lot so it isn't worth it for me.

Depends on the payment
I'd join Andreas jobs offer because I'm in need of a second uv set as well.

I think the community would greatly benefit of such a plugin and the author would be able to sell more than one copy!

Perhaps people who are interested in such a plugin can offer additional payment. At some point it will be enough to attract some direct3d/c++ guru to code the thing!

My initial offer is 150 Euro.

(make an offer to be added to this price, the programmer will receive the sum of all offers)

+30

=180€

+30

=210€

+30 = 240 €

you guys should explain exactely what and how you plan to work with this plugin, and what external tools you plan to use.
show an example of what could be done with a second uvmap, then more people would probably join paying for this.
but for the average noob it is not clear what one could do with this.

make it clear for everyone please.

I would also contribute something towards the production of this tool. Lightmaps on non-BSP entities are my dream come true.

Though is this necessary with the new ABT tree scene manager system and arbitrary level geometry? I am still not entirely clear on what the difference would be.

I guess perhaps if the MDL's are dynamic entities that move around, though then the lightmapping would not really change with the movement??

Here is an explanation:

The goal is something like that (or more complicated):


I made this scene only with models and rendered the light and shadows in Lightwave. After that I created a fixed function effect (some kind of a shader) to blend the shadows with the color textures.

You can find the 3dgs-scene here:
http://www.firma-geppert.de/Gamedev/Images/shadowmap.zip

But this is complicated. Every object needs an specific material and you cannot tile textures.

The goal of the second uv-set is:
1) you can use the first texture with texture-tiling. So you can use a wood-texture for the chairs and you can map the top and bottom sides of the seat-plate to the same texture space. You can create very detailled color uv-mapping.

2) the shadow map gets another uv-map. Here is no tiling / no repetitions. So it can contain the shadows for every surface of the object. It has not a very high resolution but that is okay for shadows.

I hope this makes it a bit more clear.

Export two Models from your Modeler. The first Model with the uv-map you need for the colormap. The second model with the uv-map you need for the lightmap.

Open the second model in MED. In the Skineditor go to Export->SkinMapping. Then you have your second uv-map available in a text-file.

What you need? The posibility to import this text-file as second uvmap in the first model.

Franks explanation of the goal of this hole thing is very good!
This plugin would make things a lot easier!

Here is another example how the plugin will be used or what it can do:


the light-mapped scene in the second screenshot is achieved by creating a second model with the lightmap UV coordinates and the lightmap texture, placing it in the excact location of the texture model and using a shader to blend both models together... it is awfully complicated and any game programmer will kill you the for doing this in the same way this method kills the performance!

With the plugin it will simply be: one model with 2 uv maps + texture + light map.

concerning the approach of actually saving the second UV map my idea is the same as Wichts:
You have a second copy of the model imported to MED which uses the Lightmap-UVs and you use the export function to export the UV coords to a file! now you can use the plugin to append this second set of UV coordinates to the first model.

I think ventilators idea is not that bad!
The models with lightmaps would most likely be used to replace level geometry, therefore the models won't need to have animations or bones! A own model format therefore only has to include mesh and UV coordinates, skins can be loaded from external sources!

I would make it an even 250 Euros!
Ventilator, willing to give it a try?

direct3d meshes don't work like the mdl7 format. the reason the mesh gets affected is because uvs get stored with a vertex in the vertex struct and not separately. in a modeling program a vertex can have several different uvs if it is at an uv-seam. in the direct3d vertex buffer such vertices have to be stored multiple times so that each uv is there. this duplication will affect the triangle indices of course.

so you have to write an algorithm which finds out which vertices have to be duplicated and then generate the proper vertex and triangle lists. if i did this in python like i talked about in my previous post this wouldn't be the hard part anymore.

now the hard part for me is all the direct3d buffer stuff since i have no experience with that and i find it a bit confusing. i will try to experiment a little in the next days.

...

the mdl7 format doesn't support a second uv-set.

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.

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

Sounds complicated! Perhaps you can JCLs input on the matter. According to him it should not be this difficult to achieve the function we all need.

it isn't simpler than i described it. i have discussed this with jcl (in a future forum thread from august). his very simple solution he always comes up with is useless with "real world" models and he admits that it is more complicated later in the thread.

Before I knew of the FBX importing/Arbitrary Geometry of 3dgs future, I looked into this a fair amount. I was always told mostly that it would require a new model format for 3dgs(and would cost a fair amount due to that).

Though, if someone manages to get this working, then I'm willing to chip in 150 euros. I'm using Max, and prolly have a similar max2mdl workflow as mabyenew. I'll probably end up using the new FBX importer(I'm waiting for JCL to first add the ability to place models in WED with it too) and WED lighting anyways, but more options never hurt. I think those with projects demanding realistic lighting would really find it useful though.

it was a stupid lite-c quirk. i am a bit further now. i also have some new ideas and if i didn't overlook anything i think i will be able to do it. probably i will need some help from jcl though once he is back.

some example mdl7 models would be helpful. once with normal uvs and once with light map uvs.

How is this gonna work for a 80-100 model scene? Is the user going to have to export 2 models for every model in the scene? Afterwards, would the code just be able to red the uvcoords thru a script? I think the workflow would be very hampered if you have to go into MED to get the uvcoordinates for every model... maybe have the models used for retrieving uv coords have a special tag in front of them, like "uv_chair.mdl". When the script runs it takes "chair.mdl" for the base, grabs the extra coords from a model with "uv_" in front of the original model name, then applies it. If the "uv_" model doesn't exist, then it just uses the original uv parameters for both texture 1 and 2.

I ask this question because workflow is one of the most important aspects of developing a game. The typical workflow I use for a level goes something like this:

Create scene in Max.

Export Scenes models into a folder with Max2MDL.

Export models positions via Max2GS.

Build in WED.

If one were to use a second uv set. Mabye like this:

Create scene in Max. Bake lighting into a separate Map Channel.

Export Scenes models into a folder with Max2MDL using map channel #1.

Export Scenes models into a folder meant to hold uv models only, only this time using map channel #2.

Export models positions via Max2GS.

Build in WED.

Let the script do the rest of the work, without having to use MED.

I'm not sure how mabyenew would go about this, i'm interested if theres anyway to speed up the changing everything to map channel #2 in max part?

using med uv-export like maybenew suggested wouldn't work anyway.

if everything works out i will create a c-script+python tool which reads the two model files and generates the txt file the plugin will require. so you could script your own batch job in any way you want.

before i continue i will probably have to wait for jcl though since i have some questions...

does anyone know if the directx9 sdk from summer 2004 will still be useable? i will have to switch from lite-c to c/c++ sooner or later.

the summer 2004 sdk worked! i have a monthly bandwidth limit and downloading 500mb packages can be kind of problematic.

i think i am almost done with the plugin part. i just have to know how to replace the mesh of an entity (any idea?) and some other small details i have to ask jcl next week.

supporting other formats would be more work (but maybe this can be done later). i think x supports two uv-sets and it could be loaded automatically but in my experience most x exporters are really crappy and i think this would lead to more trouble than it is worth.



my plugin will contain 2 simple functions:

export_mesh

this exports the mesh of an entity to a text file. the file directly contains the buffer contents direct3d needs.

import_mesh

this imports such a text file, creates a new mesh from it and assigns it to an entity. (this functions isn't fully completed yet.)



the workflow will be like that:

there will be a tool which uses the plugin. it will export both model versions (model1/uv-set1, model2/uv-set2). then a python script will be started which merges the two files into one file which contains a mesh with both uv-sets.

in your game you just will have to use ent_create() with the normal model and then import_mesh() to load the mesh with both uv-sets.



i could also extend my blender exporter to export this format directly.

+20 = 260 €

Go, vent, go...!

The workflow seems intresting:

so basically,

create your level in Max,

export the models into a folder using your plugin,

export your level into WED.

Then, take your folder containing the duplicate models with different uv sets, load em into your python program, and it'll combine them.

Then in your action for every entity, have it reload the entity as the new combined mesh? Will import_mesh() read the file name of the model and do this last part automatically, or will we have to type in the mesh name for every instance of this function? Hopefully it's not the latter, cause then you'd have to create different actions or skills for every entity.

why not wait for the static mesh thing in a7? it's supposed to work with shadows...

Alot of us are planning to stick with A6, at least until we see a reason to upgrade.

Plus my 20 EUR too, 280 EUR if it isn't already in there Vent do you think it would be possible to integrate this into the obj_splitter tool you wrote? Then people could create entire levels in any 3D app that does obj, with lightmaps -- dreamy!

The workflow sounds very good!
Hope it works out well!

-95 = 195...
free money for everyone^^



Micha

P.S.sry! I couldn't resist! it's still at 280 euros...

bad news... with current engine versions it's not possible to replace the mesh of an entity. jcl said he would have to implement an ent_setmesh() function first. because of some statements in the future forum thread from last august i thought replacing the mesh would already work.

damn. That sucks...

I hope all your work has not been wasted though?

rats! thanks for trying, ventilator

the next beta will contain the needed function.

thank you ventilator for trying!

When will the next beta arrive anyways? I've been anxiously waiting for its release!

Yes. This indeed looks awesome!
Im working on some outdoor level fr my paintball game and i prefer to make the level with 3dmax and do all the lighning inside of it, so baking the lightning on the textures would be better to me than using lights in wed.

i hope this come to be developed.

i am almost there...

there just are two problems.

it only works in lite-c so far. the plugin version still crashes and i don't know why.

and in lite-c there seems to be some problem with materials so i can't display the light map. but i am 99% sure that the mesh loads correctly and both uv-maps are there.

<edit>

it works! i still have the two problems but i combined lite-c + c-script to get the material working in the meantime.





(it's my ugly test level.)

</edit>

Looks great !!!
I already feel like playing this level

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

YAY VENT!

Did u make and light that in Blender?

Einfach geil!
In english: You should know what "geil" means.

psyco is a just in time compiler for python which makes python a bit faster. i think you mean the cgkit library? cgkit doesn't support collada or fbx.

it would be great if there were a python wrapper for the fbx sdk somewhere but i didn't find one. i am no fan of c++ but maybe i will look into the c++ fbx sdk.

<edit> hm... i wonder if the ma stands for maya ascii here and if it really is maya ascii how well it works since i guess it's a pretty complicated format. seems to be new. </edit>

yaix! not bad, ventilator!

it was some problem with adll.lib. the plugin works now! i just would like to add some improvements like a binary mesh format instead of the ascii one and maybe i will reimplement the algorithm for mixing the meshes in c so that the python tool wouldn't be necessary anymore (but i am not sure yet if that would be worth it).

it means that the python tool won't be needed anymore.

i already have a mesh generation algorithm which works in c now. unfortunately it's brute force and quite slow (~15 seconds for a 20000 polygon mesh) but i don't think it's a big problem since the result can be saved. doing an optimized version in c would be too much work. in python there are data structures which make it easy to make a much faster version even with python being an interpreted language but using an external tool is a bit cumbersome. i think it's nicer to have everything in the plugin.



there will be 3 dll functions:

Code:

---

dllfunction ent_exportmesh(entity, filename);
dllfunction ent_importmesh(entity, filename);
dllfunction ent_loadseconduvset(entity1, entity2); // this part got done by the python tool previously

---

Code:

---

	// example 1
	
	// load model with texture uv-set
	e1 = ent_create("landscape.mdl", nullvector, 0);
	e1.material = mtl_lightmap;
	
	// load model with light map uv-set	
	e2 = ent_create("landscape_lm.mdl", nullvector, 0);
	
	// generate and assign a new mesh with both uv-sets
	ent_loadseconduvset(e1, e2);
	ent_remove(e2);
	
	// save mesh with both uv-sets for faster reuse
	ent_exportmesh(e1, "landscape_lm.mesh");
	
	
	
	ent_remove(e1);
	
	
	
	// example 2
	
	// if you already have the mesh file you can load it like that
	e1 = ent_create("landscape.mdl", nullvector, 0);
	e1.material = mtl_lightmap;
	ent_importmesh(e1, "landscape_lm.mesh");

---

wow, i am really impressed!

I am also excited.

Will this also work with shaders? I would like to re-create something like this:



or this:




I already tried something like that with the sphere plug-in:



The advantage of this method over sphere is: We could use a scene-management therefore it should be possible to create bigger worlds.

If I could blend a shadowmap over a scene with normal-mapping then it would be fantastic. We could even fake static lights with this method. Visuals as seen in games like Riddick, Doom3, Quake4 (and so on) could be possible.

If someone is willing to help me with scripting and shaders then we could make a little techdemo together.

I could easily adapt my normal-mapping shader to work with lightmaps.

The only problem would be "baking" the shadows for the models.


I'm planning on buying sphere soon...

Shadow-baking will be done in Lightwave. That is no problem. The problem is:

Blending 2 uv-sets over each other. The first one contains normal-mapping or parallax shader (with tileable textues) and the second one contains a lightmap (non-tileable). The lightmap can even contain colors to simulate static lights.

A simple multiplication of the lightmap should do the job. But it must take a different uv-map into consideration.

Maybe Ventilator already has a solution for that.

I tried around with Steempipes parallaxmapping shader a few days ago. I´ve got it working with levelgeometrie and blending the lightmap. What I wanted to say is, that it´s very easy to blend them together as far as the texturecoordinates are passed to the shader.

Slin

a solution for what?

you can apply materials and shaders and use the light map (or any other texture which uses the second uv-set) in any way you want. i am not sure though how well mixing per pixel lighting with a static light map works or how it looks like since i have never tried that.

@william: yes. it's like ent_morph().

...
there still is one problem. if ent_setmesh() gets used in my plugin then the engine crashes once it gets closed. i think either i do something wrong with compiling and linking or it's a problem on jcl's side.

and maybe i will try to make ent_loadseconduvset() faster. first i wanted to use c only so that it will also work with lite-c but i think by using some c++ stuff it could be much faster.

here is a beta version of the plugin: mesh.zip ~3.8mb
try it at your own risk!

it will only work with the latest a6/a7 beta!

ent_loadseconduvset() is so fast now that the import/export functions probably won't be needed anymore. i didn't test the new algorithm very thoroughly but it seems to work at a first glance.

my example model isn't that great. it has a poor light map resolution and seams at some areas.

the beta only works for meshes up to 2500 faces.

known issue: the engine will crash if you close it!

some screenshots of your tests would be nice!

Vent you are my hero!

I can't open the file up in WED tho, there is only the wmb.. is the wmp missing, or can I run it another way?

Thanks!
JPM

to start the example you have to run main.wdl from the script editor. if you press [0] you can fly around.

awesome it is just awesome!

screenshots a'comin

I hope I´ll have some time today to play around with it. I´ll give you feedback than.

the engine shutdown crash probably happens because the plugin and the engine didn't get compiled with the same directx sdk. i will find out which sdk the engine uses and try it with that one then.

i am looking forward to see some screenshots!

I get a crash in ent_loacseconduvset(e3, e4), each mesh has 1870 faces.. any ideas?

Code:

---

var video_mode = 8;

plugindir = ".";
dllfunction ent_exportmesh(entity, filename);
dllfunction ent_importmesh(entity, filename);
dllfunction ent_loadseconduvset(entity1, entity2);



//----------------------------------------------------------------------------- mtl_lightmap
bmap bmap_lightmap = "lightmap.dds";
bmap bmap_plantlightmap = "tower_lightmap.dds";

material mtl_lightmap
{
	skin1 = bmap_lightmap;
	
	effect=
	"
	texture mtlSkin1;
	texture entSkin1;

	technique t0
	{
		pass p0
		{
			Texture[0]=<mtlSkin1>;
			Texture[1]=<entSkin1>;
			
			// mix light map with dynamic lighting 
			TexCoordIndex[0] = 1;
			ColorArg1[0] = Texture;
			ColorOp[0] = AddSigned;
			ColorArg2[0] = Diffuse;
			
			// apply lighting to texture
			TexCoordIndex[1] = 0;
			ColorArg1[1] = Texture;
			ColorOp[1] = Modulate2x;
			ColorArg2[1] = Current;
		}
	}
	";
}


material mtl_plantlightmap
{
	skin1 = bmap_plantlightmap;
	
	effect=
	"
	texture mtlSkin1;
	texture entSkin1;

	technique t0
	{
		pass p0
		{
			Texture[0]=<mtlSkin1>;
			Texture[1]=<entSkin1>;
			
			// mix light map with dynamic lighting 
			TexCoordIndex[0] = 1;
			ColorArg1[0] = Texture;
			ColorOp[0] = AddSigned;
			ColorArg2[0] = Diffuse;
			
			// apply lighting to texture
			TexCoordIndex[1] = 0;
			ColorArg1[1] = Texture;
			ColorOp[1] = Modulate2x;
			ColorArg2[1] = Current;
		}
	}
	";
}


//----------------------------------------------------------------------------- main
entity* e1;
entity* e2;

entity* e3;
entity* e4;

function main()
{
	wait(3);
	level_load("empty.wmb");
	wait(1);
	
	vec_set(sky_color, vector(250, 175, 75));
	
	vec_set(sun_angle, vector(160, -35, 0));
	sun_light = 20;
	
	vec_set(camera.x, vector(300, 0, 200));
	camera.pan = 180;


	
//	// example 1
//	
	// load model with texture uv-set
	e1 = ent_create("landscape.mdl", nullvector, 0);
	e1.material = mtl_lightmap;
	
	// load model with light map uv-set	
	e2 = ent_create("landscape_lm.mdl", nullvector, 0);
	
	// generate and assign a new mesh with both uv-sets
	ent_loadseconduvset(e1, e2);
	ent_remove(e2);
	
	// save mesh with both uv-sets for faster reuse
	ent_exportmesh(e1, "landscape_lm.mesh");
	
	////////////////////////
	
	e3 = ent_create("plant.mdl", nullvector, 0);
	e3.material = mtl_plantlightmap;
	
	// load model with light map uv-set	
	e4 = ent_create("plant_lm.mdl", nullvector, 0);
	
	// generate and assign a new mesh with both uv-sets
	ent_loadseconduvset(e3, e4);
	ent_remove(e4);
	
	// save mesh with both uv-sets for faster reuse
	ent_exportmesh(e3, "plant_lm.mesh");

---

if a model pair causes a crash i would need it for investigation.

does anyone else have crashes? (except the one when closing the engine!)

(both models need the same amount of faces, the vertex positions have to be exactly the same and the corresponding faces must have the same vertex order. maybe i forgot some check to avoid a crash if one of these isn't the case.)

...
btw. you can comment out all export and import functions since they probably aren't needed anymore.

No crashes here, as I still haven't tried my own models.

Currently having trouble getting my 2 models out of max. For example, I've got 2 mapping channels, the first one with the normal UV, the second with another UV. But max2mdl seems to only export models with map channel #1. Perhaps I'm doing something wrong, as I'm very new when it comes to baking levels. If someones got a solution for it, please post(I think earlier it looked like Mabyenew had no problem exporting with this?).


Edit:

Got the mesh exports working! Turns out to export as a different map channel, you have to UVW Mapping modifier, and select your map channel there. This is very simple and quick.

Anyways, i'm getting the same error as Jetpackmonkey when I try to combine my 2 meshes thru script. Basically a problem with the "loadseconduvset", then after that error, there is one with the "ent_importmesh". After running, the model has it's normal tiling textures, but with a bunch of it's faces shaded black here and there.

Code:

---

  str_for_entfile(tempstring,my);
 //str_cpy(aemo2, tempstring);



 if(str_cmp(tempstring,"YY_MAINCLIFF.MDL") == 1)
 {

//	// example 1
//	
//	// load model with texture uv-set

//	// load model with light map uv-set	
	e2 = ent_create("l_maincliff.mdl", nullvector, 0);
//	
//	// generate and assign a new mesh with both uv-sets
	ent_loadseconduvset(my, e2);
	ent_remove(e2);
//	
//	// save mesh with both uv-sets for faster reuse
///	ent_exportmesh(e1, "landscape_lm.mesh");
//	
//	
//	
	//ent_remove(my);

// ent_importmesh(my, "l_maincliff.mesh");
}
 

---

how does the error message exactly look like?

are you sure you don't mix up my beta popups with crashes? i stupidly used the error() function for popups but if it is no error it says "(this is no error message!)" at the bottom.

there probably is something wrong though if you get black triangles and i would have to investigate that with your models.

My first screen with ventilator's mesh-plugin


Lightwave



A6-Engine

A dream comes true...
Looks like a night-shift for me.

hm... i did some tests with messing up the second model (moved some vertices around so that the correct triangles won't be found on the second model) and the algorithm seems to be quite forgiving. i didn't get any crashes. just the light map was wrong then on those triangles.

jetpack_monkey's test model worked for me and william's model seemed to work too but he forgot to send me the light map so i couldn't check if it displays correctly. he had overlapping areas in the light map uvs though which probably won't give good results.

jetpack_monkey's test model:

This only works with 6.6* [private-beta] right?

I can't wait to work with it, although I probably won't be able to since I don't have any way for generating the lightmaps...

just get blender, it can make them for you.

Yeah, my model works great. I was just at the end of a long day(sleepy...) when testing this and thought that I was doing something wrong.

Anyways, I want to make good on my offer of 150euros, so maybe share your Paypal so I(and the rest) can pay you, and get a dll without all the messages.

I've got blender, but I'm too busy+lazy to figure out how to use the damn thing...

One of these days I'll spend some time with it...

just go to the blender noob2pro tutorial and look for how to unwrap an object, then all you have to do is render a lightmap

Thanks, I'll check it out tomorrow. (It's 0:32, and I have work tomorrow )

here is a new beta version: mesh.zip ~2.8mb

now the plugin is compiled with the same directx sdk as the engine so the engine shouldn't crash anymore on shutdown.

@xxxguitar511: yes, it only works with the private beta at the moment since the plugin needs ent_setmesh(). it will work with the final a6 release and with a7.

I can't seem to fly around with this latest version, any thoughts?

maybe you pressed the wrong [0] key? you could also call _tog_mov(); in the main function.

any other feedback? does everything work?

Oh!! Sorry vent, I thought I got back to you via e-mail -- yeah! I can fly around with it now, works great

$$$ btw everyone who said they'd pitch in, don't back out of your promise now that vent has delivered the goods $$$


(my paypal thank you coming soon)

Me, I'm using the second version with Vista and have no problems, and no crash on closing acknex afterwards. The 2222 face model prevents me from re-building your demo mesh, though, but my own ones are under the limit and work well.

I apologize, I´ve used the old version.
It works without crash.

buh... i am glad it works. it could have been really nasty if this had been some strange vista problem.

here is a code snippet which cycles through all entities of a level and applies a light map if the "_lm" files exist for the entity. i haven't tested it yet. it's just an idea...

Code:

---

// example 3
function file_exists(filename)
{
	var filehandle;
	filehandle = file_open_read(filename); 
	if(filehandle)
	{
		file_close(filehandle);
		return(1);
	}
	else
	{
		return(0);	
	}
}

string tempstring1;
string tempstring2;
material* tempmaterial;
entity* tempentity;

function applylightmaps()
{
	you = ent_next(0);
 	while(you != 0)
	{
		str_for_entfile(tempstring1, you);
		str_trunc(tempstring1, 4);
		str_cpy(tempstring2, tempstring1);
		str_cat(tempstring1, "_lm.mdl");
		str_cat(tempstring2, "_lm.dds");
		
		if(file_exists(tempstring1) && file_exists(tempstring2))
		{
			you.skill100 = mtl_create(); // i guess they should be deleted again when changing the level
			tempmaterial = you.skill100;
			tempmaterial.effect = mtl_lightmap.effect;
			tempmaterial.skin1 = bmap_create(tempstring2); // i guess they should be deleted again when changing the level
			you.material = tempmaterial;
			
			tempentity = ent_create(tempstring1, nullvector, 0);
			ent_loadseconduvset(you, tempentity);
			ent_remove(tempentity);
		}
		
 		you = ent_next(you);
 	}
}

---

i thought some more about payment. it's kind of unfair if not everyone pays the same amount. i will just sell the plugin individually for 20€.

...
i also found out that vec_for_mesh()/vec_to_mesh() won't work anymore with a replaced mesh (but ent_vertices(), vec_for_vertex(),... still work). there is nothing i can do about it but i think it's no big issue since for a light mapped mesh modifications wouldn't make much sense anyway since the lighting got done for the unmodified mesh and wouldn't be correct anymore. if you absolutely need to modify the mesh you could do the modifications to both models before you use ent_loadseconduvset().

I enjoy every picture of the results of this tool!
I still don't wanna use the last beta, but I am amazed by your tool!
Great job!

A question came to my mind: what about the framerates?
Did anyone compare it to similar maps (although it is anyhow not comparable), maybe to a multitextured terrain?

Are the shown levels made of a single model?
What about different models with different lightmaps in the same level?

the frame rates are good. light mapping is cheap.

the example level is one model with about 20000 faces and it runs with about 400fps on my gf6600.

i think for performance it would be better to split the level into chunks with less than 5000 faces. it's no problem to use different models with different light maps.

Wonderful!

Does anybody have other landscapes or different moods
and lighting of the same landscape to show?
Just for fun! It looks so nice!

Isn't it awesome? Behold!! We must build a shrine to it!

Those frame rates are fantastic, and the automatic lm loading code is definitely a step towards making level creation without hardcoding it (!!!)

Heres another little snippet for applying lightmaps:

Code:

---

 

 str_for_entfile(tempstring,my);

  str_lwr(tempstring);
  str_cpy(lightstring,"z");
  str_cat(lightstring,tempstring);

  //load model with light map uv-set	
  e2 = ent_create(lightstring, nullvector, 0);

  //generate and assign a new mesh with both uv-sets
  ent_loadseconduvset(my, e2);
  ent_remove(e2);

 

---

Basically you can just save your models that contains lightmaps with a "z" in front of there original names. If you put this in your action, every entity with this action will load a lightmap. If you want to have only some entities with this action load them, then you can just specify that with a flag or skill.

I wish there was a way to morph the skin2 of an entity. It would make automatic lightmap texture assigning to your non-lightmap models skin2 possible.

I get a beta expired message.

Can you tell me about the stability of the plugin? What can cause crashes, are there things to pay special attention to?

Other than that I am ready to license the plugin

I created a fixed function effect that combines color texture, normal-map via dot3-bumpmapping and the lightmap coming from second uv-set. I am planning to create similar effects for metal, glass and reflection via cube-maps.

So I am also very interested in licensing to check that out.

mesh_plugin_demo.zip ~ 2.8mb

i have uploaded a time unlimited demo with a 777 polygon limit.

i don't think it will crash anymore.

things to know:
- the two models must have the same face count
- the vertices of the two models must be at exactly the same positions
- the triangles of the two models must have the same vertex order
(these three points usually are the case if you export them from the same application)
- you can't use vec_for_mesh/vec_to_mesh anymore with a replaced mesh
- it only works with the beta at the moment

if you want to license it already you can write me a pm.

(something else to know:
there seems to be a model loading bug in the recent betas.
http://www.coniserver.net/ubbthreads/showflat.php/Cat/0/Number/751735/an/0/page/0#Post751735
my plugin is only interested in the texture coordinates of the second model but because of this bug the second model needs some dummy texture. best assign the light map as external texture like in my example. this isn't a problem of my plugin though.)

so does this work without the beta yet?

So we just have to hope that an A6.6 will appear very soon.

by the way... 6.6 is out now!

testing it at the moment.
but my model is very.. VERY dark...
I don't know why.. any clue?

the brightness depends on the used material and on your light map.

i think with my example material every light map value above 128 brightens the texture and every value below 128 darkens the texture.

<edit> i checked your models and the reason was that they didn't have the same scale. the vertices must have exactly the same positions otherwise the triangles won't be found on the second model. if a triangle doesn't get found its texture coordinates of the second uv-set get set to 0. </edit>

ok, got it to work
here my test:
without 2nd uv map


with 2nd uv map:


nice

Can you recommend any [free] programs for generating lightmaps? I'm very interested in this, but I don't have any way of generating lightmaps (and I'm cheap - lol )

im telling you if you can just figure out how to import to blender, its simply a matter of clicking on button and you have it.

http://www.ambiera.com/irredit/
this could work too. has anyone tried it?

it doesnt export lightmaps, it is only used for irrlicht, people keep bringing up irredit, and irredit is not meant for any other engine than irrlicht.

no, i had a look... it can export collada format and the light map but getting this collada file into 3dgs could be a bit tricky.

Hi,
I'm having a little trouble using this plugin.
I have my mdl7 with the texture and the mdl7 with the second uvmap with the lightning map apliied. Im ready to go. I just dont know where to start. I donwloaded the plugin. Where do i place it? and how do i use it?

Sorry for the n00bish questions. lol

Put it in the acknex_plugins folder in your gamestudio folder. Then check out the demo files that came with it, I think that should have enough info for you.. or if they aren't in there, I'm pretty sure there is a link in this thread to it. It works very well!