While looking for something else today (a “turn to” function, as opposed to a “set rotation” function), I discovered that Panda has a class called “ControlManager”, and a set of classes that end in “Walker” (although there are also two “Pilots”), listed under “controls” in the manual’s class reference.
It looks as though these are user control (or perhaps AI control) classes for characters of various types, or in various situations (such as swimming in the case of the “SwimWalker”)… but unfortunately they seem to be undocumented, aside from the usual “Undocumented function” entries for their methods.
A search of both the manual and this forum has turned up nothing that I noticed.
Does anyone know anything about these classes, and if so, what?
What I was looking for was a means to have an object turn towards another over time. For my current purposes I’m only working with 2D rotations.
I have some C++ code that I could easily-enough port; I just want to avoid doing too much mathematics in Python, from what I’ve gathered of the speed of doing so, and I don’t want to duplicate functionality, perhaps more efficient functionality, already provided elsewhere.
It looks as though “lookAt” sets the object’s rotation, rather than having it change over time.
Thank you for that - I’m downloading it, and intend to have a look at it.
For example, let’s say I have the player moving from one point to another, with an enemy trying to turn to face him. As the player moves, the enemy’s target position changes; I don’t want it to turn all the way to an old target before starting to turn towards a new one…
Do you keep resetting the interval as the object’s desired target point changes?
[edit]
Chombee, I’ve taken a look at your steering plugin, and it looks quite good.
If I understand correctly (and I’ll admit that I’m perhaps not at my best tonight), you use vector mathematics to affect a character’s velocity, and then set the character’s heading according to that.
In my case, I intend to allow outside forces to act on the creatures, which would complicate the implementation of a system such as yours a little, but perhaps not overmuch. Instead of keeping a single velocity vector, I could keep two: one for the character’s “personal” velocity - that is, its velocity as applied by itself (to which a maximum length is applied) - and another for velocity produced by outside forces. Only the former would determine the creature’s heading value.
I could perhaps zero the “personal” velocity when the creature is in the air, or, perhaps better, whenever the “external” velocity has a length above a certain value.
Hmm… It does seem to me to make restricting rotation rate a little less simple, but it shouldn’t be difficult, I don’t believe…
Something like that, yeah. The theory is well explained here: red3d.com/cwr/steer/
Shouldn’t be too hard, have a vector for each force acting on the object, one of those forces is the object’s own drive, and combine all the vectors each frame to decide in which direction it moves.
You can just clamp the maximum length of the vector or something like that.
Heh, I think that that’s the article that I looked at the last time that I looked into implementing steering behaviour.
I think that I understand the relevant basics, at least; I was more interested here in how you were altering your characters’ model orientation, although the behaviour itself is rather interesting too.
I think that having two vectors, one for creature-born velocity, and one for eternally-imposed velocity, should call for fewer vectors to be stored in the worst case. Both could be involved in final movement, but only the “personal” velocity value determines the creature’s direction.
Well, simple clamping would produce varying degrees of turn for varying angles, but the same elapsed time, I think. That said, it might work… And if it doesn’t look as I’d like, I think that I should be able to use trigonometry to calculate a vector length that limits the rotation appropriately, although I suspect that there might be problems with certain circumstances.
I could also restrict the steering vector to be ninety degrees to the forward vector, and of a certain length or less (before multiplication by time), limiting the creature’s ability to make sharp turns. A separate braking force could be applied when the creature is to be slowed.
[edit]
In the end, I went with a port of my C++ code. I found that keeping two separate velocity vectors made implementing friction more difficult, unfortunately, and when I sat down to think about implementing the use of a steering vector to determine the actor’s heading, I came to think that doing so could allow either some undesirably quick turns or problems with the character not looking in the right direction.
My solution has become to tackle the problem from the other end. I determine the least turn to look towards the target, and turn towards it, all the way if within limits, and partway otherwise, as described previously. I then have the character move about by walking forwards (or, theoretically, backwards or sideways), as opposed to thrusting in any direction.
A slightly more complex friction model seems to have allowed me to abandon my velocity maximum, allowing both reasonable speeds for characters and potentially-greater external forces, although I haven’t fully tested it yet.
I have yet to get on to reading that Panda source code, but hope to do so soon! ^^;
Well, I’ve finally gotten around to looking at the ControlManager class and some of its attendant files (such as the Walkers already mentioned).
It appears as though I was correct: These look like player-avatar control systems. Specifically, ControlManager seems to store and, well, manage a set of control systems. The various Walkers and Pilots appear to be the control systems themselves. In the words given at the top of “PhysicsWalker.py”:
I’m not sure of how complete the system is. For example, the file “PhysicsRoller.py” contains only the following line, followed by two empty lines:
“”“PhysicsRoller is for wheels, soccer balls, billiard balls, and other things that roll.”“”
In fact, the comment at the top of the TwoDWalker class notes that “This class is still work in progress”.
Based on one or two mentions in one or two files, I would guess that these were created to handle avatar control in Disney’s games. I’ve seen mention, for example, of the words “toon” and “toontown”. Similarly, I wonder whether the ShipPilot classes weren’t created for the Pirates of the Caribbean game.
I haven’t tried to use any of these myself thus far, but they look as though they might be useful.
I found the files in question in direct\src\controls, so I would guess that the appropriate importations for a project would be from direct.controls.
that’s mostly disney stuff and some of these classes are unfortunately outdated. here you can look up the last changes.
that line means that the module expects a PRC option called want-avatar-physics-indicator (which should have a boolean value), but it can’t find the config manager, which you may import from ShowBase, for example.
best thing you can do with unofficial/undocumented modules is look up some handy code and rewrite it to your needs without all the garbage you don’t need (like such prc switches).
