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