(I’ve removed a little bit, to make it simpler to read.)
I realize that I can condense the physics nodes down into one single node, but first things first: why can’t I see either of them? I can still alter their positions, and the camera follows them just fine…
There’s nothing about an ActorNode that makes its geometry invisible. Are you sure that the node is, in fact, in front of the camera?
You can issue the command nodePath.showBounds() to draw a green sphere around the bounding volume of a node’s contents; this may help to locate your geometry. Try issuing this command on the actorNode itself, for instance.
I discovered late, late last night that the problem actually seems to be the ForceNode that I’m putting into the Scene Graph. It must be throwing my models to some extremely large negative Z coordinate, and it must be doing that long before I can ever move to the edge of my map in order to see below my terrain geometry.
Is there any documentation on the friction coeficient? It’s “undocumented” in the reference guide. Does it apply to all collisions while they’re touching?
Thanks, by the way, for the showBounds() idea. Doing that made me realize the my ActorNodes were in fact long gone
Looking at the code, it appears to degrade the moving object’s velocity during the frames that the collision is detected. The dynamicFrictionCoef is applied when the object is moving faster than its almostStationarySpeed, while its staticFrictionCoef is applied when it is moving slower than this (presumably, staticFrictionCoef will be 0.9 or higher, to make the object stop completely).
Well, I was going to say that the PhysicsCollisionHandler was complaining about “CollisionHandlerPush not knowing about nodePath suchandsuch”, but setting each of those three variables seems to have solved that.
However, my models are still gone… which doesn’t make much sense, to be honest. I set a dummy sphere above the head of where the model should be, and it shows up just fine, and when I move about, everything acts like normal, except that the models aren’t there… here’s a little screenshot to help illustrate (click to enlarge):
My camera is positioned relative to the model’s location, so… I’m led to believe that the model is there, but I can’t see it still.
nothing, really… It’s not hidden, so showing it doesn’t really have any effect. In fact, there isn’t a single “.hide()” or “.show()” line in my entire code, minus some commented-out collisionRay stuff.
Well, the reason that I asked was because collision geometry, at least, is by default hidden, and shown with, well, show(). It occurred to me that it might be worth a shot to try to explicitly show() your geometry, just in case it’s being (whether by design or erroneously) hidden behind the scenes.
(Your response isn’t entirely clear to me on whether you’ve tried such an explicit showing; if you have, then fair enough, if not, then why not give it a shot, placing the call after the physics application, of course.)
sorry— yes, I have tried doing various “.show()” commands on different nodes. The ActorNode, the geometryNode, the CollisionNode… to no avail.
The CollisionNodes themselves were children to the geometry, so even if it was trying to hide things, it would have only been the children of my geometry that was being hidden.
Ultimately, it’s got something to do with this ForceNode. I can’t seem to tweak it to ever allow my geometry to be seen. Positioning seems to be correct, but nothing is visible. Even if it were trying to set-and-reset the positions of the objects, while trying to accelerate my nodes downward at VBase3(0,0,-9.81) at the same time, I ought to see the flicker back and forth. But nothing. I zoom the camera out and I simply don’t see them.
Well. If the ForceNode is indeed taking them far away, you would see that in actor.getPos() or actor.getTransform(). Is that indeed the case?
You would not see the objects flicker back-and-forth if, within the span of one frame, you were setting the actorNode to its correct position and then the ForceNode immediately moved it to the wrong position. The only position that matters is the final position each object has in the frame at the time the igloop task runs–no matter how many times it moves before that, you won’t see it there, not even for a flicker.
Try parenting the camera to your ForceNode. Then your camera will be falling along with it. At least you’ll be convinced that that’s indeed what is happening.
I’ll try parenting the camera to the ActorNode, as suggested…
yup, he’s falling for some reason. He gets farther each frame…
My calls to ‘myNodePath.getPos()’ are decievingly giving me the values I want because I forgot that I zero-out the Z coordinate when calculating where the camera should be. “.getPos()” itself shows the falling, however, when I calculate the position for the camera, I ignore the Z.
Perhaps I don’t understand how to set those Coefficient variables to decent values? I find them a little confusing, since I’d expect those friction values to be on the ActorNodes rather than the Handler itself. You know… varying frictional values instead of a single global friction for all surfaces for all objects.
What kind of units are those coeficients in? I haven’t the foggiest idea. The Reference only says “float”
a float is nothing more than a number with a comma. like
1.32541
or
425.12
in contrast to integers which are “full” numbers such as 1 53 31892 and so on.
if it wants an float you can pass pretty much everything execpt for PI or stuff like that
I understand the “float” part, but I mean actual units… are we talking metric here? What kind of units is “setAlmostStationarySpeed” supposed to be in? m/s? f/s? pixels? (haha, i know it’s not in pixels). I don’t know what kind of measurements it wants.
I’m assuming metric, since that’s what the “.setmass()” method uses.
But I still feel funny simply putting a “.5” in there. I feel a little blind, like I don’t really know what it’s talking about.
The setAlmostStationarySpeed units are the same units as the rest of the physics system: “units” per second, where a “unit” is the units of your scene. If you have modeled your scene so that the top of your human’s head is at z = 6 when his feet are at z = 0, then your units are feet. If, however, the top of the human’s head is at z = 2, then your units are meters, and so on. Whatever you call a unit, that’s the same unit used by the physics system. Spatial units are arbitary. (Time units are not arbitrary, and are generally seconds throughout Panda.)
For the coefficients, this should be a number between 0.0 and 1.0, where 0 is no friction at all and 1 means no motion is possible. If you set these to numbers outside of this range, very strange things might happen.
Try turning off the gravity at first, just to get a handle of scale here. If the thing falls with gravity = 0, you’ve got bigger problems. Once you’ve got it floating in space with no gravity, try turning on just a teensy bit of gravity to see if it falls slowly. If it still falls too fast, turn down the gravity until it falls slowly. And so on.
It shouldn’t be too hard to isolate the property that’s causing your objects to fall quickly out of view.
I’ve already played with the gravity amount-- and I can get the ForceNode to sink my models more slowly (or not at all, as suggested), but the issue still remains that I can’t seem to make them actually collide with the ground.
This whole thing seems a little shakey. I’ve gotten the models to at least somewhat stop on surfaces, sometimes. It’s really sporatic. And at best, the highest point of their models cling to the surface. For example, a box sinks underground, but stops when it’s top is parallel with the surface that I wish to stand on. And when I move toward sloped terrain, the model goes nuts and slips beneath the terrain and down into oblivion Sometimes on those same slopes, I sit on them perfectly, slowly sliding according to the frictionCoefficients, but once I move back to flat terrain, I sink to the previous state.
I realize that the engine would be ideal for easy setup of movement and gravity, among other things, but this is kind of a turn-off to the system. I already had some velocity/acceleration equations at work, and figured that I could transition to the physics engine in order to tackle some ‘jump’ forces for the characters, but I can’t even make them stand up.
I’m sure that the engine works, since it made it into the Panda code, but a good solid sample program would be fantastic if it were shipped with panda, like the other samples.
I’ll keep working away at it, but let it be known that I’m heavily tempted to just return to my own calculations rather than using this physics engine for my movements.
If you successfully reach the other end of your voyage of discovery with a good solid sample program, would you be willing to contribute it to the distribution?
So, it appears to be some interaction with collisions and physics. Interesting. What happens if you set the friction coefficients both to zero, to get friction out of the picture?
(sorry for the long post. it’s important, really )
For sure-- I’m definitely interested in making this work, and if I can figure it out I’ll be sure to try to make the contribution.
I just left town for a day or so, but once I get back, I’ll be sure to try some more test cases. I do remember that a low DynamicFrictionCoef was making me slip around when moving (as expected), but I’m having a hard time trying to figure out what to set the AlmostStationarySpeed to.
A question: I understand that this physics engine can do velocity/aceleration/deceleration calculations by itself, given the setting of the ActorNode’s mass (via .setMass()) and these friction coefficients. The hard part for me to conceptualize is this:
If I’ve got a my ActorNode in position—say—0,0,0, and I want to move forward along the Y-axis, I can push my “arrow_up” key, but I don’t understand how to move my model to properly to allow the physics engine to take care of certain things. In theory, should I just have to apply my own veloctiy vector to the object’s postion, and then the engine will take care of the rest? That just seems like it would create a suddent jump of position, followed by some nice deleceration given by the friction numbers.
This may not be a very ‘explored’ front, but in theory at least, how is the engine designed to handle this movement? As of currenly, I’ve been creating a velocity vector, and then applying it in pieces across many frames to create the aceleration/deceleration. I doubt that my system is going to perfectly integrate with the physics engine, since I’d be making panda do double-duty on the whole movement thing.
Thanks for all of the posts so far. Despite whatever frustrations I’ve experienced, I know that it’s all in the name of experience.
Sometimes on those same slopes, I sit on them perfectly, slowly sliding according to the frictionCoefficients, but once I move back to flat terrain, I sink to the previous state.