[help] grey lightmap from mapsplitter

Vorl

21-10-2006 09:02:10

Hi all,

I would like to use plsm2 in my project, but I'm stuck with it since 3 weeks. I have read all the wiki, browsed the forum etc

I just install the the plsm2 (sdk), compile and run mapsplitter after having defined a valid resource.cfg. I do not change anything else. Then, for hf129_3, I get a grey lightmap. When I used the demo on the results, there is so no lightning. It is normal ?? Am I missing something ?

Mapsplitter report nothing particular in the log file. I have of course spent hours to try various options in the .gen.cfg file but it doesnt change anything.

This is the lightmap I obtain:



Vorl

Vorl

21-10-2006 15:14:38

I have finally progressed this afternoon by steping throught the code of the mapsplitter in debug mode. It seems that (sunx, suny, sunz) is the direction from the sun and not toward the sun. The confusion comes from the fact that all .gen.cfg files in plsm2 have a positiv suny. That should be negativ, shouldnt it ? With a negativ value I now have a better lightmap. It seems also that ScaleZ must be 100.0f to work properly (?)
I have now plenty of other problems (for example I dont understand why the base map does not receive shadows even with "LitBaseMap=yes" etc.) but I will look into the code again.

Vorl

Vorl

21-10-2006 15:57:19

For the problem of litbasemap=yes, I found the following:

In MapSplatter.cpp, line 135, BaseMap is created as an RGB image
In MapMergeModulater.cpp, line 100, the BaseMap is expected to be RGBA and so an exception is raised when I tried to generate a litbasemap.

Is it normal ? If not, what side sould be changed ?

Vorl

Vorl

22-10-2006 09:31:04

I'm a little speaking with myself :) , but just for information :
I have simply changed "mMergeModulater->ModulateGrayAndRgbaInRgba" to "mMergeModulater->ModulateGrayAndRgbInRgb" in MapUtil.cpp:783 and it seems to work now.
Second problem solved ! Switching to the next one... :)

Vorl

22-10-2006 09:58:14

I go on describing my problems in case it would be usefull for someoneelse:
I had still strange lightmap. I found that
1) In mapLighter.cpp (lines 84 and 203), the direction of light is modify by the scale vector
2) the x and z components of the scale vector are modified by the paging size in OgrePagingLandScapeOptions.cpp:590
As a consequence, the resulting light direction was near horizontal.
I have remove the operations with the scale in 1) and the result is now much better. But I still need a small z component for the sun vector. For example, I get good results with
Sunx=0.5f
Suny=-0.025f
Sunz=0.5f

Vorl

22-10-2006 13:19:39

Actually, the above solution is incomplete, as I got an inverted lightmap.

After some tests I see that in MapLighter::CalcMapShadow(), the light direction is initialized with "LightDirection = sun.normalisedCopy()" and in MapLighter::CalcMapLight() with "Vector3 LightDirection (sun.normalisedCopy() * -1.0f);".

In my opinion, they should be initialized in the same way. It works better for me if so (I just removed "* -1.0f").

Vorl

22-10-2006 14:34:05

A last remark on the mapsplitter (I'm going to try to load my terrain with the plugin now): In the template.gen.cfg file,

ColorMapGenerated=no
LitColorMapGenerated=no

should be replaced by

ColorMapGenerate=no
LitColorMapGenerate=no

As it is configured like this in the code.

tuan kuranes

24-10-2006 10:34:38

Thanks a lot.
I added all your fixes in CVS .

Vorl

24-10-2006 17:00:06

Don't know if this can be helpfull, but I have also modified the way the shadow and the result of the dot product with the normal are merged in MapLighter::CalcMapLight(...):

/* Calculate illumination model (ambient plus diffuse) */
const float s = (1.0f - scaleShadow * ShadowMap[index_pixel] / 4.);

/* Get the dot product with the light source direction */
const Vector3 normal = mapUtil->getNormalAt (i, j);
float d = LightDirection.dotProduct(normal) / 2. + 0.5;

changes are " / 4." and "/ 2. + 0.5"

I found the result much better because it allows the shadows to be modulated and less dark. At the end I got the following result :

kungfoomasta

24-10-2006 17:36:29

Thanks a lot.
I added all your fixes in CVS .


The TerrainGenerator app should be changed to reflect these options also, right? The main fix is the labels, since I use those for the option names in the generated cfg files. It would be better to just globally replace the two names.

KungFooMasta

tuan kuranes

25-10-2006 12:34:21

Changes in CVS now. (in TerrainGenerator too.)

@Vorl : Did you try dynamic lightmapping ?

it's in "PagingLandScapeTexture::computeLightMap ()". It use generated horizonmap + normal maps to achieve realtime computation.

Vorl

25-10-2006 14:21:42

Not yet.
I have just tried InstantBaseShadowed mode (not sure if it is related to your question) but with VertexCompression=off I have a static light and with VertexCompression=on I have a black terrain. But I simply don't know how to use this feature (are we suppose to call PagingLandScapeTexture::computeLightMap () at each frame ? do we need to define the move of the sun somewhere ? etc.). As I have other more critical problems to solve (cf. post concerning the shadows), I will for now stay with static lights.

tuan kuranes

25-10-2006 16:13:07

InstantBaseShadowed is the mode.

The demo shipped with PLSM2 does have a sun that rotates, and demonstrate the dynamic lightmapping in HF map, if you want to have a try.
(using vertexcompression makes it uses InstantBaseShadowed instead of InstantBaseShadowedDecompress which is dynamically lightmapped using shaders pixel shaders V2.0)
cf. post concerning the shadows
I'm on it.

Vorl

25-10-2006 16:46:00

The demo shipped with Ogre does have a sun that rotates, and demonstrate the dynamic lightmapping in HF map, if you want to have a try.
I will try

I'm on it.
Great ! :D