jitteryness? does this happen when you do NOT play any animations on the character,too?
cause animations can, under some circumstances appear jittery. so it might not even have to do with terrain or movement at all.
My real FPS with BlockSize at 32 and LOD set to 100 is 100 FPS on the Roaming Ralph where I just added my map(512x512), and changed ralph’s run speed. The 100 FPS is “while” he is running.
Yes, the animation is almost what it seems like, but the problem is that like I said, I have him running at the same speed in the one roaming ralph I just mentioned above. So, I’m not sure why the animation would be in the problem in one and not the other.
Another possibility, I think, is in the movement code - are you accounting for the time between updates when you calculate the distance to move your character?
For example, if you were moving your character n units in a given direction, which more resembles your code, this
pos = pos + n*diror this
pos = pos + n*dt*dirwhere pos is the initial position, n is the number of units to move, dir is the direction in which to move, and dt is the time since the last update?
(Note that the above is a generalisation; the important element, I think, is the presence or non-presence of the “dt” element.)
I took out the “dt” and that fixed the animation problem. 
But if I leave the “updateTask” updating every 2 seconds, I seem to get a “slight” jerk right then if I’m moving. If I’m standing still, it’s fine but if you were in combat or moving alot, you’d definitely notice it. Even as I get the slight jerk, my fps is above 100 at least though “when” it’s not jerking. If I’m moving and it “jerks”(updates), I see the fps hit like 30-40. Any ideas? =o
the more often you run the update task ,. the less much stuff gets updated per run.
you can try to run it each frame. or every 0,1 second or so.if jerkyness increasses.
well i think your problem was not resolved so you might still be suffering from the terrain beein re-generated entirely.
is there any chance you asign the terrain-heighfield image to the geomipterrain each frame or something like that?? i mean. geomipterrain runs terrain of your sizes even on my 8 years old notebook which barely has hardwareacceleated grafics at all. so there MUST be something wrong.
Wait, you took the “dt” out and it fixed the problem? That seems very odd to me - I would think that it ought to be there… o_0
Would you mind posting your original movement code (that is, including the dt), the code in which dt is originally assigned for a given update, and checking for any places in which dt might be changed between initial assignment and the movement code, please?
I just noticed, I had taken out the ‘dt’ for the wrong movement, somehow the animation jitteryness got fixed, unknownst to me.
I’ve looked all through the code though, and can’t find any spot about the terrain update() re-rendering the whole thing, etc.
Once again, here is my current setup:
self.terrain.setHeightfield(Filename("heightmap2.png"))
# Set terrain properties
self.terrain.setMinLevel(0)
self.terrain.setBlockSize(64)
self.terrain.setFactor(100)
self.terrain.setFocalPoint(base.camera)
# Store the root NodePath for convenience
self.terrainRoot = self.terrain.getRoot()
self.terrainRoot.setTexture(loader.loadTexture("terrainmap2.png")) # Texture
self.terrainRoot.setPos(0,0,0)
self.terrainRoot.reparentTo(render)
self.terrainRoot.setSz(50)
self.terrain.generate()Also, my camera is back to going under the ground again because I got rid of the collision method to try to use the getElevation. This is my current camera code:
base.camera.setZ(self.parent.terrainRoot, self.parent.terrain.getElevation(self.actor.getX(self.parent.terrainRoot), self.actor.getY(self.parent.terrainRoot)))
base.camera.setZ(base.camera.getZ() + 2.0)Testing the camera’s Z value is less then the terrain’s elevation doesn’t seem to work either.
Heheh, that happens, I think. 
Well, that it’s working is good, I daresay. 
Well, it appears that you’re getting the elevation at the actor’s position, not the camera’s…
I know, I’m simply using that to get my camera to be 2.0 above the actor’s Z. That didn’t include the logic I also tried to use to get the camera to be above the terrain always, because it never even partially worked. @_@;
Fair enough, although why do you not just get the actor’s z-value, instead of calling getElevation?
As to keeping the camera above the ground, I would think that you should, after doing the above-mentioned, call getElevation, using the camera’s position, and if it’s higher than the previous value, set the camera’s z-value to the elevation value.
I think this is what you mean, and I’ve already tried this if so, and it doesn’t work:
base.camera.setZ(self.actor.getZ() + 2.0)
cam_elv = self.parent.terrain.getElevation(base.camera.getX(), base.camera.getY())
if base.camera.getZ() < cam_elv:
base.camera.setZ(cam_elv)Maybe I’m doing it wrong though. It’s late here, makes it hard to think. xD
Hmm… That’s odd - that is indeed pretty much what I meant.
What does it do, if anything, and do you have anything affecting the camera after that code?
[edit] It’s late here, too, and I’m short on sleep to boot, so I may well be missing something myself. ^^;
self.floater.setPos(self.actor.getPos())
self.floater.setZ(self.actor.getZ() + 2.0)
base.camera.lookAt(self.floater)That’s everything I have after the camera code.
My camera seems to be set to the right height for the character, and always “monitor” him correctly. It’s just when I go down a hill or something, the camera just goes right through the hill instead of being set to the elevation of the hill instead. =x
Maybe we’ll figure it out tomorrow. xD
Wouldn’t you need to set the camera to stop a little higher than the hill? If it goes all the way down to the same elevation as the hill, you’ll be embedded within the ground, which will look the same as if you were below it.
David
I’ve even tried this:
base.camera.setZ(cam_elv + 12.0)And it stills goes through the hill.
Hmm… Does its elevation alter at all? If so, in response to what?
You forgot one very important thing: the elevation is in the 0 - 1 range. You need to multiply it by the vertical scale of the terrain to get the right results. Like:
cam_elv *= self.parent.terrain.getRoot().getSz(render)Okay, so now I’ve got:
base.camera.setZ(self.actor.getZ() + 2.0)
cam_elv = self.parent.terrain.getElevation(base.camera.getX(), base.camera.getY())
cam_elv *= self.parent.terrain.getRoot().getSz(render)
if base.camera.getZ() < cam_elv:
base.camera.setZ(cam_elv + 2.0)Which seems to work, in a way…
It corrects my camera’s Z when it goes under the ground like it should, but for a split second I see under the ground before it bounces me back out to the position I want to be at(above the ground).
Hmm, then you should update the Z right after the position of the avatar updates, without waiting a frame in between.
Well, I have my actor and my camera in their own classes so they have their own “move()” function that gets added to the taskMgr. How do I make sure that happens, or does it “have” to be that way for me to solve this problem? I think that’s what you mean, right? =x
I could possibly make one “move()” outside the classes that calls both, that gets added to the taskMgr so they run sync’d, or?
Trying to keep everything Object Oriented as I’m learning.