You could still keep them separate, though, by taking advantage of the task “priority”. When you add each task to the taskMgr, you can specify priority = 0 or any number you like (0 is the default).
Each task is executed in the order of increasing priority, and igloop (the task that renders the frame) is created with priority 50. So, just make sure that the task that moves the camera has a priority greater than the task that moves the avatar, but less than 50.
Just to make sure it wasn’t switching from one to the other really fast and that caused me to see it. This code only changes the Z once it knows what it should be.
Do you think it could be because I have my terrain.update() commented out for now, since I’m still struggling with it?
Sorry for all the problems, I seem to have a lot of them. x_x;
There’s no possibility of accidentally rendering a frame in between Python statements within the same task. The frame will not render until the igloop task is run, so it doesn’t matter how many times you adjust the Z value before then–only the final value that it holds at the time igloop runs is that one that matters.
I suggest putting print statements within your task(s) to help see what’s going on. For instance, you can print the camera’s XYZ position at the end of your adjust-elevation task. Be sure you print its net position, which is the one that really matters. For instance, print:
camera.getPos(render)
and not just:
camera.getPos()
since, like any other node, the camera inherits its position from its parent, and the camera’s getPos() is just relative to that parent’s position. But the actual position of the camera in the world is determined by the whole chain of parents, whatever they are.
You can also run the task manager one frame at a time, to help see what’s going on, by running:
taskMgr.step()
instead of:
taskMgr.run()
Each call to step() runs each task once, in the priority order.
I changed my code to the above, just for debugging purposes. Here is the output, while the camera is under the ground:
Before 17.2991847992
After 17.2991847992
test1: 17.2991847992
test2: 0.345983684063
test3: 0.349932143267
Am I suppose to be rendering my camera to self.parent.terrainRoot or to “render”? Also, ralph should be rendered to the same one(which ever camera is suppose to use), correct?
I took a Roaming Ralph example and made some basic terrain, move, and “updateTask” changes. So, not a whole lot changed, and I am getting the camera under the ground effect, as well as the terrain.update() problem. This way I can truly show all there is to my problem. I’ve ran this code on two different PC’s with two different OS’s(Windows and Linux). I just happen to use two different PC’s for developing and both give me the same result of problems. I also included my terrainmap and heightmap just in case. I rely on the Roaming Ralph models to be in your Panda directory(or for you to copy them to the Ralph folder I posted). =x
Which checks to see if your camera is under the ground. But you forgot to do anything about it if it is! All you do is print some output, and then leave it where it was. You should set it to the ground’s elevation, or actually a bit higher. I found that 0.1 was high enough, given the scale of your model. I changed this condition to:
which solves the problem nicely. (Note that it’s not terribly efficient. We end up calling terrain.getElevation() twice, which is silly. And it’s faster to call pos = base.camera.getPos(render) than to call getX(render) and getY(render) separately. Furthermore, since base.camera is directly a child of render, we can omit (render) from the getPos() call, which is much faster still.)
As to the delay in the terrain updates, well, I see that too. It takes several seconds to update. I suspect the terrain parameters are not well-chosen, but I know nothing about GeoMipTerrain, so I’ll leave that diagnosis to someone more capable.
The code I uploaded didnt have the set because I wasnt sure how to do it. I tried a bunch of different ways and just couldn’t get it right, I knew that had to be my logic.
The terrain issue is what I am really stumped on, because to me it doesnt look like a logic issue or me calling the wrong commands, but I could be wrong. Maybe, it’s like you say, I’m setting something wrong for the terrain. >_<
You can also use Task.again if you created the task using doMethodLater.
Here’s also a theory which might make the avatar go below the terrain:
The update call makes sure the terrain always is the highest quality at the focal point (usually the camera). If you set minLevel to a value higher than zero, the quality will be slightly less at the focal point itself. No big deal if you barely see the difference and the renderer wastes on superfluous polygons anyways. What actually could be a problem there is that the getElevation call plain reads from the heightmap file and thus returns the height value as it would have the highest quality.
Here’s an image to describe a bit: (LOD2 is the lower-quality terrain that one actually sees in the scene, LOD0 is the highest-quality terrain, which the getElevation call uses)
[size=75](image by ThomasEgi)[/size]
As you see, if the LOD2 terrain differs too much from LOD0, the avatar would be seen going through the terrain. The blue image shows that on a steep slope, it could be even more noticable if the avatar has animations.
There are a few things what could be causing this:
Invalid focal point. Mostly, you’d want to set this either at the camera or the avatar.
Forgot to call update(), which I see is also your case since you forgot to return Task.cont.
Too high setMinLevel. If the minimum level is higher the LOD2 in the image will differ more from LOD0.
@drwr, it takes less than milliseconds to update the terrain in my game. Most likely, you were using a heightmap with a non-power-of-two-plus-one size, and/or chose the wrong terrain settings.
@pro-rsoft: If the update task is working for you with my heightmap and terrainmap, please post what you did to get it to work because drwr is having the same problems since he is running that zipped up file that I am which contains both my heightfield map and my terrain map. The task.again works in the fact that it updates the terrain again, but hold down the run key and see how much it messes up the whole game by sending it to a complete stop…
Before I move onto ralph going under the ground, I need my terrain updating. If it’s not, then when I move outside the focal point, I would except the calculations to be incorrect, etc. Either way, first I need my terrain to be updating correctly.
It’s the same one as before, so remember to add the dummy.cont or dummy.again No reason for me to post all the files for just that change. Hope we can figure this out x_x;
I noticed the lag too, but this was because the terrain settings you chose were not entirely optimized.
I changed the MinLevel to 1, the BlockSize to 32 and reduced the Factor to 60. After that, it ran smooth here. Average 500 fps. If you still experience a small lag on older gpu’s, you should even tweak the settings to be more optimized.
I’m not seeing ralph going into the terrain at all, by the way – just the camera, or is that the problem?
I’ll have to try that when I get home since the computer I’m at now is a business workstation and so I have to set Min to 1, BlockSize to 32, and Factor to less than 20 just to get it to not have much lag.
Yeah, but a factor less than 40 means terrible popping will be visible. Keep it around the 50, maybe more if needed, if there’s a lag you might want to slightly increase the MinLevel, try to set it to 2. I don’t recommend setting it to much more than that, perhaps 3 if its really needed.
… since I can’t reproduce the lag here anymore now I tweaked the settings a little bit I can’t help you much more with tweaking it further, sorry.
[size=84]EDIT: I’m seeing the GeoMipTerrain seems to be a bit hard to tweak. A better system using near/far values will be introduced in Panda3D 1.6.0, to make tweaking a little bit easier. Here’s the blueprint if interested: blueprints.launchpad.net/panda3 … -lod-addon[/size]
That’s okay. I’ll use my home PC as my “Top Quality” basis when I get home and then work from there by trying my friends PC’s, then their “Family” PC’s, etc and keep doing that. Basically from best quality to worst and figure out an “Average” or something. As long as I know that’s the issue, then it’s just a matter of tweaking. Thanks for all the help, I know you guys are busy.
i had a close look at your map and the geomipterrain sources. there is a bug in geomipterrain which can cause the terrain under your feed to be lower-quality thus causing the in-ground-problem. it usualy occurs when setFactor is set to a low value and chunksize is fairly large.
bugreport was commited with fix attached. so it should be fixed in upcomming versions (not 1.5.3 since its already too late)
along with the hopefully new lod-setting system it should make things much more comfortable and consistent. with predictable results.
PS: @pro-rsoft you know i’m not able to write c++ code. so i guess i cant take the task of implementing the new lod-setting stuff. instead i’ll make some drafts on a new flatten system which really intends to boost performance this time.
