Attention all modders (esp SAF_Biffa)

[Stridor]

Hi guys,

Whilst testing out the lighting system of the MM and how it all works in the game I discovered a semi-major problem with almost all of the games map models (and probably all of the vehicles and infantry as well but I haven't had a chance to test them out yet). It also applies to some of the new work done by great modders like SAF_Biffa and through no fault of their own.

In essence the engine supports positional lighting effects. You can take a given map and change the sun's position and diffuse and ambient light and get a whole new look to the same map. That's cool.

The problem is that unless the object has had its normals defined correctly in the .X file, then lighting system won't work. Now somehow Ben got this right for his models, however virtually all of the shipped models and so far all of Biffas models have had their normals "zeroed out" and so don't work for different lighting conditions. I include a SS below to show you what I mean. I have set the light source to be directly under the map (ie midnight) and the ambient + diffuse colors to black. This means that the map objects should be black. I went and fixed up the orchard trees as they were broken, but you can see the other stock trees are still being illuminated as well as Biffa's models.

I suspect what has happened is that the export normals option was turned OFF during export. Unlike other DX engines the PCK engine doesn't recalc model normals at load time so if the object has had its normals zeroed out then it won't get fixed by the engine.

The good news is that it is a straightforward fix.

What you need to do is to start MS3D. DirectX import the broken normal X file (the MS3D DX importer recalcs normals for you). Then rexport the new model via the DX JT exporter under the same name. Make sure the "exclude normals" option is cleared in the export dialog. That will fix the problem.

The only issue now is that someone will have to go through all the game models are re-import/export them again. I wonder who that would be?

I must say it really is worth it to get a much better lighting effect.

Now I don't know for sure but this same problem may effect some of the vehicles/men in the game as well.

If you want to test out your model to see if it is lighting compatibale just make a quick map in the MM, place your objects and then vary the light conditions. Your model should change lighting as appropriate.

Regards

S.

[Stridor]

I was thinking that if this gets fixed true night fighting might be interesting.

Why?

Because you will barely be able to see your own units on the map let alone the enemy, there will be lots of orders confusion and short engagement ranges to boot.

[benpark]

How in the heck are mine correct? There's a first time for everything.

I'll give a hand with the exporting. I'm getting a bit busy, but I can do them in the gaps.

I just looked at the export settings I have been using:

[Stridor]

Ben, those are the correct DX settings. If the Exclude Normals box is checked I think it stuffs it.

Here is an example series of SS showing the problem.

You can see that your wheat and the telephone poles work ok, the trees, craters and SAF_Biffa's haystack are incorrectly illuminated.

Regards

S.

[Stridor]

All this talk of changing lighting conditions had got me thinking about making a system for the MM where you can make dynamic changes to the skybox so that with the same skybox image you can change it to make it appear night or sunrise, sunset, etc.

Much like the image above.

Now that would be cool.

Before I did that I would want to be sure that the vehicles / men etc had their normals correctly exported. Perhaps that is something you could check on Ben? Simply make a map with different lighting conditions and then knock a demo scenario to see how they all look?

Regards

S.

[benpark]

Sure thing. Can I use the settings from the older version of the MM, or do I need the one you are using now?

[Stridor]

Thanks ben, you can use the older 0.9a MM just fine to test out the lighting. Try different light angles and diffuse (= directly lit surfaces) and ambient (= non directly lit surfaces) and see which units work and which don't.

[Mraah]

John,

I'm at work now ... can you please check the models I recentered?

I'm pretty sure the export setting was properly set but since it's a copy of the original then I'm curious if this changed at all.
Rob

EDIT NOTE : I can do all the scene models again since I have the MS3D model already from when I was making the MSZ.

[Mraah]

Stridor,

You know, I just realized ... I think you're on your own for the most part [:(]... We cann't fix the units without redoing the entire model (piece it together) and the animations without having Max or Polytrans.

Also, the buildings will need new bones ... not a problem but it may take longer with MS3D because I'm thinking Max and Poly can do it with just a few clicks ... hence another reason why it's worth the cost.

Let me know what you need done ... we can surely split the work.

And, finally ... if we do all this then Koios will have to mold their updates to your MM ... otherwise we'll have to do this all over again [&:].

Rob

[rickier65]

I"m not sure I totally understood evrything you said, but I think I did. In any event, I'm willing to help, but I dont have MS3D, or any of those other fancy modelling packages. But if there is something I can help with I"m willing.

Rick

[Erik Rutins]

Good find, Stridor - wish we'd noticed this before release, but it has great potential to improve the look of things now.

[benpark]

Good news and bad news. As far as the lighting effects go, infantry units have the effects applied to them. Bad news- vehicles do not. I can re-do some of the game's building models, but not the vehicles.

This obvious difference in lighting on the models is noticeable mainly when the map goes completely dark. Ambient lighting still is applied. Maybe for now, the amount of work necessary to deliver night fighting is too much and we should settle for dawn/dusk effects? We can gauge how dark we can make the setting to deliver a realistic looking trade-off.

One question regarding the density of color in the ambient lighting- can this be toned down? As is it obscures the ma color. If I choose "orange" to be the ambient color, the ground itself turns that tone, where a toggle would deliver just a percentage. 10% say would barely color the highlights, and give more of a suggestion of a time of day, rather than a Martian landscape.

[Mraah]

[:D] ... I'll have to to tweak the M4A2 ... looks like it's under a black light ...

Can you change the color of the light ... so it will offset the purple look ?

[benpark]

Don't worry about it, Rob. I just picked dark blue to look like "night". If tghe density of the color could be scaled back, it would certainly look better.

[Biffa]

Gawd!
 
I did notice that to see the textures on the models after exporting from 3DSM to MD3D I had to adjust the Emissive value, (well that's how I fixed it) this is obviously the problem. It does mean that you can only see a silhouette of your model so you have to turn it down then turn it up again before saving to .x.
 
I thought it would be ok and it was just a reset export glitch.
 
Damn annoying.
 
I hope to fix both the packs as soon as I have some spare time and then divide them again into summer/winter versions, hence 4 packs.

[Stridor]

Biffa,

I think what happened was that the normals got lost between 3DSM and MS3D or were accidently turned off during export.

You may have to recalc the normals by assigning smoothing groups (which you can do automatically)


Regards

S.

[Stridor]

Ben,

When you have the color box open in MM press the "Define Custom Colors" button. That will take you to a selection box where you choose from 16.7 million colors.

Regards

S.

[Stridor]

The latest build will have the color system be more flexible as well to help with this problem.

I will also introduce an way to tint lighten and darken skyboxes so that you will have a bigger range of skybox choices.

The MM is getting pretty good now [;)]

[Biffa]

Well I finally found some spare time to start on this and so far the following hasn't worked.
 
"What you need to do is to start MS3D. DirectX import the broken normal X file (the MS3D DX importer recalcs normals for you). Then rexport the new model via the DX JT exporter under the same name. Make sure the "exclude normals" option is cleared in the export dialog. That will fix the problem."
 
I'm using a work around testing it using the Map Scene Editor and just adjusting lighting which is pretty much the same as the date/time does on the MM I suspect, I still haven't had time to get to grips with the MM but I will.
 
Anyway the shot below show's the lighting problem, foreground building being my 'broken' one and the background being a Vanilla Barn. This is after I used various ways to fix the problem including using the sliders in MM and ofcourse the fix above but so far no joy.
 


 
I don't have a problem losing the bones (mount points) since I save at every stage when creating a model so I have the MS file as well as the X and 3DSM at various stages. I can simply  merge the MS with the X file once it is fixed and then delete the old model and material leaving the bones. Handy for when there is a problem like this. Exclude Normals was cleared since I followed the tut to the t.
 
Any more suggestions on how to sort this out?

[Stridor]

Biffa,

There are 2 issues.

1. The first is that your models didn't export with normals for some reason? This will cause a uniformly lit model regardless of light source direction. You should be able to recalc the normals with smoothing groups. I think that the directX importer for MS3D also recalcs normals for you. If you need to recalc them I can also provide the MS meshconvert utility.

2. The second issue has to do with how the lighting on your model (and indeed on many of the K models) has been defined.

In X there are four lighting properties for a material:

The diffuse color
The specular power (sharpness)
The specular color
The emmisive color

You can set all these in M3D if you want. By default (which is why ben's stuff worked ok) the values are:

diffuse = 0.8,0.8,0.8 (eg white at 80% power)
power = 0
specular = 0,0,0
emmisive = 0,0,0

Note you can check what values that have been exported if you export your DX files in txt (which all the modders have, K didn't [:@]) by searching for the material define like this (ben's model)

Code: Select all

                 Material Material01
                 {
                     0.800000;0.800000;0.800000;1.000000;;
                     0.000000;
                     0.000000;0.000000;0.000000;;
                     0.000000;0.000000;0.000000;;
 
                     TextureFileName
                     {
                         "GeGable2.dds";
                     }
                 }
 

They read from top to bottom as I have defined them above.

I *think* PCK ignores the power value and the specular value (which is a shame as you could get great "metal" like effect off the tanks - although that needs further testing), it uses the diffuse value in its main diffuse lighting and ambient lighting calcs on the model.

However it *does* apply emmisive. So Biffa lets take one of your models

Code: Select all

             Material bifhys1l
             {
                 0.584314;0.584314;0.584314;1.000000;;
                 12.800000;
                 0.898039;0.898039;0.898039;;
                 0.992157;0.992157;0.992157;;
 
                 TextureFileName
                 {
                     "bifhys1l.dds";
                 }
 

So you can see that this haystack will light up like a candle in the dark!

Emmisve lighting can do some neat effects with the engine (like tank lights on at night - no dynamic lighting however [:(]). The problem is that it has been applied inappropriately to all your models and virtually all the K models.

As has been obsereved you can't reimport this stuff to fix it becuase it breaks all the bones and animation! (ok for non-bone and non-animation stuff like trees and haystacks, etc)

I guess I could write a batch system which examines every X file and zeros out the emmisive values for all the textures, but what a huge job! It would also zero out the emmisives where you might want them (although it turns out in WAR emmisives are generally a bad thing, so the fact that some minor ones are missing is no big deal when compared to how badly it mangles the lighting effect)

I think personally the best solution is for K to change the code to zero out emmisives at model load time. That would be a sinch to fix in the code! In every instances emmisives are wrong in all these models so it wouldn't hurt!

For you biffa your fixes are easy. First fix your normals so that you can directionally light your models. Next fix the emmisve values. If you absolutely need to you can simply go into any txt editor and zero them out in the material define.

I hope this all helps

Regards

S.

P.S. If you get a chance could you test out what specular color effects do? If they work it would be a boon for tank art.
Also when you test these things on a test map ensure that the map light source power is *not* set to 255 (set it to 128) and give the light source a non-overhead (ie non 0,-1,0) vector so that you can see which faces are being lit.

Regards x 2

S.