i am drawing areal time planet in c++ i and i am having problems on looking at the horizon: its seams to vanish. I think this is got to do with 32bit float errors. Is there a way to make the bounding volume unusualy large? or disable culling on my planet node all together? Tanks!
What about making the far clip very large?
no pro the clip happens when i am very close to the planet looking at the horizon. So the planet is bellow me very very close. and i see its side.
What about making the near clip very small?
Of course this would give you some Z-fighting.
yes my z buffer is set to where it will work best i cant change the clipping plaens. But the thing is getting clipped on he side not in front or far a way. I just need to tell panda to never cull this planetary object
I think you’re confusing culling and clipping. If Panda were culling the object, you wouldn’t see any part of it at all.
Clipping is performed by your graphics card, not by Panda, and you can’t avoid it. It will get clipped by the near plane and by the far plane. All you can do is move the planes as far apart as you like. The near plane can be as close to zero as you like (but not exactly zero), and the far plane can be as far away as you like. The farther apart they are, the more likely you are to have z-fighting in the middle, but other than that there are no restrictions.
Just for the record, you can disable Panda’s view frustum culling altogether with the config setting:
There are also ways to disable culling for any one particular object, instead of disabling it altogether. But it doesn’t sound like this is your problem.
yes that is exactly what i needed. But how to disable cull only on the planet node only?
also i get gross errors for BoundingSphere contained in cameras bounding volume (lens.getLens().makeBounds())
I assume its related to the cull problem.
I think i would have to write my own sphere in viewport checking function (that is probably 64 bit based) for this.
this is my code in case i made some obvious errors
lens = self.camera.node()
self.bv = lens.getLens().makeBounds()
… and later ( i reuse the bv) …
center = (v1+v2+v3)/3
rcenter = self.camera.getRelativePoint(render,Point3(center))
bs = BoundingSphere(Point3(rcenter), egs1)
if not self.bv.contains(bs):return
Tell me more about this problem. If Panda is not culling the object correctly, and turning off the culling solves a problem, then there is a bug in Panda. I would like to understand this problem so we can fix the bug in the future.
The zip contains the c++ library and python test.py program. ( if you are running ubuntu edgy you can just run it … if on a unixy like system it should compile with gcc … or i dont know.
It also contains newsys.py - a pure python implementation of the same algorithm but in this algorithm there is no mountains so its harder to see it but possible to get it to cull incorrectly.
You can use ‘e’ key to freeze algorithm and stop morphing terrain and just fly around this is how i can tell it culling not my algorithm. (that is the other problem manifests it self with the bounding tests during mophing)
Oh! You’re morphing the terrain. By that I assume you mean you are recomputing the vertices on the fly? Panda won’t automatically recompute the bounding volume for the vertices when you do this, since it’s a potentially expensive operation. This means your bounding volume is inaccurate, which explains why the culling is failing.
You can force Panda to recompute the bounding volume by calling:
Or, if you are confident the terrain will always be visible, it’s perfectly reasonable to set an OmniBoundingVolume on it and just leave it there, as shown in the post above.
I don’t understand what you’re referring to with the bounding sphere within the camera frustum test. There’s no 32-bit or 64-bit specific code in Panda’s bounding volume intersection tests.
yes drwr i know that panda does not recompute that on the fly that is why i create the “starting geom” about 4 times larger then the planet will be … a bo x with radius of 4 and the morphed planet has radius of one. Also i have tried the recompute the bounds and tight bounds before but no help … and yes OmniBoundingVolume is the best solution. But i still get errors on the lens bounding volume and the sphere.
I do apologize if I’ve been telling you things you already know–I’m not trying to insult your intelligence or your experience. I’m trying to do my best to understand the problem you’re describing and suggest solutions. I’m sorry if I misunderstand the problem sometimes–I know it’s difficult when you can’t draw me a picture.
If your node is getting culled incorrectly, but the OmniBoundingVolume solution works, then it follows there is a bounding volume error. It’s difficult for me to guess the exact nature of the error from what you’ve told me, but it’s got to be either (a) the bounding volume does not correctly enclose the geometry, or (b) Panda is incorrectly computing the bounding volume intersections for some reason.
It’s certainly possible that it’s (b), but I have to consider that unlikely, since Panda’s bounding volume intersection test is some of the oldest code in Panda, it’s fundamental to all of Panda’s view-frustum culling, and it seems to have been working fine for years. That leads me to suspect that (a) is the much more likely possibility.
There are all sorts of ways to get a bounding volume mismatch, especially if you are setting it by hand. Are you sure that you are setting the bounding volume correctly, and that you are setting it in the right place? For instance, if you’re computing an explicit bounding volume and setting it on the GeomNode, that doesn’t mean much, since the Geom still has its own bounding volume that will be tested for culling. (Unless you also call node.setFinal(True), which means to make this node’s bounding volume the final bounding volume tested at this node level and below.)
I’d love to be able to offer help on the other problem you’re referring to, but I’m afraid you haven’t told me enough to understand what the problem is.
"I do apologize if I’ve been … " - now you are just making fun of me!
David, you are great infinite source of panda knowledge - now if you hang around #panda3d freenode irc my life would be complete.
i was wrong its not (b) … i did many many test of very similar to my planet map but without it and no i cant get it to fail no matter how hard i try.
You win its (a) and i am happy doing OmniBoundingVolume because i am culling at the patch level for my planet (this is where the other errors come) and it must be my program again because my independent tests have shown no errors… and i have hunches why it might be wrong … i hope i solve this soon its driving me nuts!