• Create Account

Member Since 10 Dec 2011
Offline Last Active May 01 2014 07:44 PM

### In Topic: Problems with Normal Mapping

17 April 2014 - 06:18 PM

Almost immediately after posting, I found a solution; however, I don't understand why I works.

I changed the line:

```normalMap = normalMap * 2 - 1; // Normalize to [-1, 1]
```

To

`normalMap.xy = normalMap.xy * 2 - 1; // Normalize to [-1, 1]`

So that the z value would stay in the range [0,1]. Now it looks like this:

If someone knows why that change worked and if it while cause problems later, I would be grateful for the insight.

### In Topic: Problems with Normal Mapping

17 April 2014 - 06:08 PM

Thank you for the replies.

Inverting the g channel first was definitely an issue. It led me to realising my light positions z-values were also too small, so I increased those and adjusted the falloff.

Now I have something much closer to my goal, but there is one more issue. Now I have a problem where only normals that are facing almost directly ahead seem to get lit:

I tried encircling one of the spots that isn't lighting, and it didn't change:

Then I tried moving the z- value of the light around and got a confusing result. If the z-value is very small (the background is effectively at z = 0), then some of the spots that were dark becomes lit to the up and right of the light while the normals facing the screen become darker in that area.

I'd be grateful for any ideas or suggestions.

### In Topic: Direction Vector not working correctly

03 September 2012 - 06:48 PM

I think I understand your problem. Try normalizing the direction vector and multiplying it by the desired speed.

[source lang="csharp"]Vector2 direction = target - position;direction.normalize( );missleVelocity = missle_speed * direction[/source]

### In Topic: Can someone PLEASE test my game?

03 September 2012 - 06:29 PM

Edit: Opps, forgot to check the date.

### In Topic: Generating Large Maps Using Libnoise (Limits?)

03 September 2012 - 06:22 PM

I'm looking at the sample code's file "complexplanet.cpp". Here's some code around line 128
[source lang="cpp"] // Southernmost coordinate of elevation grid. const double SOUTH_COORD = -90; // Northernmost coordinate of elevation grid. const double NORTH_COORD = 90; // Westernmost coordinate of elevation grid. const double WEST_COORD = -180; // Easternmost coordinate of elevation grid. const double EAST_COORD = 180; // Width of elevation grid, in points. const int GRID_WIDTH = 4096; // Height of elevation grid, in points. const int GRID_HEIGHT = 2048;[/source]

Then around line 1843

[source lang="cpp"] planet.SetBounds (SOUTH_COORD, NORTH_COORD, WEST_COORD, EAST_COORD); planet.SetDestSize (GRID_WIDTH, GRID_HEIGHT);[/source]

Here is the 4096 by 2048 height map the site uses for the terrain sample pictures:
http://libnoise.sour...ages/planet.jpg

So it's only about twice as large as what you found as your maximum, the sample just looks like it needs a much larger map because of the way Terragen renders it. Still, it seems you don't have as much memory as they expect people running the sample to have. Your main options are:
1. Find a way to make due with fewer points.
2. Get more memory. Note, this option will make the minumum system requirements for your game higher.
3. Make multiple smaller height maps and save them to disk, probably after compressing. Then, make your program try to anticipate which ones will be needed soon so it can decompress and load them before they need to be show.

PARTNERS