BUG: DensityMap looks tilt/distorted

Hi!

First of all, let me say this is a great project! Simple, usefull and very nice results!

I have noticed a problem in the density map. I'm working on a scenario with some squared islands, and I want to cover them with grass. An approach is to use the density maps.
But, I got the grass in another places outside of islands, and with tilt shape.

I made many code checks, and in DensityMap::_getDensityAt_Unfiltered, I put a debug message printing x,z coords. and respective value. After, I ploted this data in GNUPlot, and...I get the same wrong shape!

Aparently, the problem is related to HardwarePixelBuffer and PixeBox copy operations.

Have anyone this problem? Could anyone help-me, please!

I'm using v1.05, and Linux.

Thanks!
Edgar.

How is it being warped? Rotated / skewed / wrong position? How severe is it? Are you sure it's not a problem with the image? I'll take a look at the code and see if I can spot anything wrong, but it would be really helpful if you could provide some code that demonstrates the problem.

Thanks for your reply!

I will prepare and post here a simple example with images to show the problem.

Edgar.

This is a simple example that shows the bug described in this topic.
You can get the zip file at:

www.cecm.usp.br/~edgar/bug.zip

It is based on Example4 with a little modification:

The configuration file is: terrain3.cfg
In the configuration file terrain3.cfg, it's configured to use 'bug.png' heightmap, and the maximum height is 10.
The 'bug.png' heightmap is very simple. It has only a few white circle shapes and a white asymetrical shape on the center. The rest of the image is black.

And I added this line of code in Example4.cpp, at the end of function World::load:

l->setDensityMap("bug.png");

When we run the application, we get a flat ground with flat top hills. It's Ok!
But, the grass is outside of the top of the hills, and they are not clustered in circle shapes, but in elliptic form.

Because I'm using the same map for the terrain and grass density, I expect to get the grass exactly on the top of the hills.

Could someone check this, please?

Thanks!

Edgar.

Hi!

Are there any evolution on correcting this bug? Someone has tested this? Plese, let me know if this problem occurs with other people.

Could someone help me, please? It isn't necessary to effectively correct the bug, but give me more information about the way I can correct it. I can review the code.

Thanks very much for any help.

Edgar.

Sorry about the delay (to you and everyone else) - I've been sick recently and everything has just recently got back to normal. Hopefully I'll have a solution for this soon!

Just an update: Thanks to your example I reproduced the problem, which interestingly only occurs in OpenGL - in DirectX the grass aligns flawlessly. Definitely a bug though. I'll update you as soon as I fix this.

Hi John!

Thanks for your help!

Yes, we are using only OpenGL. But yesterday, I have fixed the bug by this way:

In method
DensityMap::_getDensityAt_Unfiltered

Subtract the zindex from the xindex:

uint32 zindex = mapHeight * (z - mapBounds.top) / boundsHeight;
uint32 xindex = mapWidth * (x - mapBounds.left) / boundsWidth - zindex;

And in method
DensityMap::_getDensityAt_Bilinear

uint32 zIndex = zIndexFloat;
uint32 xIndex = xIndexFloat - zIndex;

Maybe, it helps you to fix the bug.

Edgar.

Thanks! This should definitely help. I hope to get this fully solved by this weekend (since I haven't had much time for PagedGeometry during the past week).

Hi John!

I have made a little mistake in DensityMap::_getDensityAt_Bilinear. I just noted it isn't correct, sorry. The grass covers only half of the scene. But I think this is easy to solve, now we know the way.

The unfiltered method looks Ok.

Edgar.

It looks like in OpenGL Ogre has a bug with PixelBox::getWidth() where it reports a width 1 unit larger than what it reports in DirectX mode for 1-byte greyscale images. I patched this, so try the latest version from SVN and let me know if it works - it seems to fix the problem in your example.

Hi John!

Unfortunately, it doesn't work. I'm getting the same wrong results.

I have got this version of Ogre:
https://svn.ogre3d.org/svnroot/ogre/branches/v1-6/
compiled and instaled.

Is this version correct?

Thanks,

Edgar.

Actually I have RC1 of 1.6. I'll install the latest version of Ogre and retest (although I'll be gone all day tomorrow so I may not be able to recompile ogre and test everything tonight).

Hi John!

Thanks for your help! I have corrected the bug in the methods DensityMap::_getDensityAt_Unfiltered and DensityMap::_getDensityAt_Bilinear.
For our requirements, it's now Ok. Don't worry about urgency in correcting this bug. But, since it's a Ogre Rendering System bug, it must be corrected in the Ogre, not in Paged Geometry. When you have news, please let me know. I will help you on tests.

Best regards,

Edgar.

Howdy,

JohnJ, it would appear that (at least on GL in Linux) your fix for GL actually breaks the density map (rows 'stair step' away from the x minimum bound in the reverse of the way they were with the original issue.)

I'm not sure if the original fix is windows-specific, but commenting out lines 134-6 and 160-2 in PropertyMaps.cpp makes things work for me.

I suspect that the original issue only manifests itself under certain vendor/GL library/OS combinations, perhaps put an #ifdef WIN32 around those lines? I don't have much access to a windows machine (and Ogre's OpenGL rendersystem crashes wine for me,) so I can't test this theory.

/S

PS: this is in PagedGeometry SVN from a few days ago
PPS: Ogre is Eihort, perhaps the original bug is a Shoggoth-specific issue?

I think you're right that this may have something to do with Shaggoth or maybe cross-platform issues, since I'm still unable to reproduce the issue after I "fixed" it.

I'm not sure if the original fix is windows-specific, but commenting out lines 134-6 and 160-2 in PropertyMaps.cpp makes things work for me.

I suspect that the original issue only manifests itself under certain vendor/GL library/OS combinations, perhaps put an #ifdef WIN32 around those lines? I don't have much access to a windows machine (and Ogre's OpenGL rendersystem crashes wine for me,) so I can't test this theory.
It almost sounds like it's a Windows bug since my patch fixed it in Windows but broke it in Linux? I don't know - this is confusing. It definitely seems that something's not right on Ogre's side since there are obviously "code-breaking" differences between platforms.