PGMM bug?

Scripting Issues
1

When I run this code I get strange random stuff on the bottom row of the heightmap.
The png is completely black and 257x257 (the png doesn’t seem to be the problem)

If I take out the code to display the yugo model the heightmap suddenly appears as it should.
If I replace the yugo with another model from the internet I get a similar effect. (though not the same, the problem seems worse the more complex the model)
If I replace the yugo with one of the built in objects such as the panda the heightmap is normal.

I would love to get this to work so please tell me if you know if there is a workaround or if I need to start looking at the PGMM code?

I mentioned the problem on irc the other day as _mega but couldn’t define it well enough.

from direct.directbase import DirectStart
from pandac.PandaModules import Filename,Point2, TextureStage
from libpgmm import PGMM
p1 = loader.loadModel("obj/yugo/yugo")
p1.setScale(10.5,10.5,10.5)
p1.setPos(100.0, 300.0, 0.0)
p1.reparentTo(render)
tmp=PGMM("myTerrain")
tmp.setSz(100)
tmp.setBlockSize(64)
tmp.setFactor(100)
tmp.setMinLevel(1)
tmp.setHeightfield(Filename("map/out/out0x0.png"))
tmp.generate()
tmp.reparentTo(render)
run()

oh yeah, the problem also disappears if I place the terrain loading before the model loading, but I can’t do that in the project I’m doing.

2

Can I have your heightmap PNG? I will take a look at it then.

What version of PGMM are you using, by the way? The latest release?

3

Here is the PNG
I’m using the latest .dll you posted on the forum and panda 1.4.2

vesen.hydra.is/spjald/uploads/ok … out0x0.png

4

Thanks! I’ll take a look at it very soon.

5

I saw that weird thing too, but only once, I guess it was coincident, the last bottom row’s vertices got elevated randomly, like niagara fall. The common case was it didn’t elevated at all (0).
Seems there is offset in memory address read, so instead of reading the last image row, it reads somewhere else, like your model’s data, but not in other app’s teritory, so no segfault.
It could be neighborlee’s scrambled compiler, I compiled the latest from SVN myself and it’s very fine.
Try this : libpgmm.dll

6

Thanks!
I already suspected such a thing but I didnt have very much time yet to test it, since my current PGMM build is very messy and segfaults. But thanks for solving the problem.
I think it wasn’t a compiler problem though. I remember I solved such a thing some time ago and committed it to SVN.