setHPR issue

I’m coding a simple script where a little farm tractor spins its weels and do nothing else. Since i’m a lazy monkey, i’m trying to achieve this with the setHPR in this way:

def spinwheels(task):
	angledegrees = task.time * 40.0
	wheel0.setHpr(0, angledegrees, 0)
	wheel1.setHpr(0, angledegrees, 0)
	wheel2.setHpr(0, angledegrees, 0)
	wheel3.setHpr(0, angledegrees, 0)

	return Task.cont


taskMgr.add(spinwheels, "spinwheels")



I’ve Blended my tractor (well, more than a tractor is a big cube with 4 thin cubes, but this isn’t the point) with the wheels that have been created using a single mesh duplicated 3 times and then moved and rotated around a center pivot.
The problem is that while I see in pview a fine tractor (sorta of) with all the wheels righ in place, when I use it in my script, looks like the wheels that I have rotated have lost their rotation, but not the movement though, and spin in their original position with just the movement applied on.
That’s it.

I’m not completely sure I’m following the problem, but it is true that you will need to set a local origin for each wheel so that the axis is the local origin. Depending on your modeling package, you may also need to take some steps to ensure that this local origin is preserved through the model conversion into Panda.

Also, you should use loader.loadModel() to load your model (rather than the Actor interface); and you should ensure that you are converting the model as an unanimated object–not as an animated character. This is because you are not using the animation package to spin the wheels, you are doing it by hand in Python code. So you want the model to be converted as an ordinary model, not an animated character with joints. (If you convert it as an animated character, Panda may optimize away nodes that you need to control.)

If you examine your egg file, you should not see a entry (this would indicate an animated character), but you should see a entry for each wheel (this indicates a local origin). You might also need to add:
{ 1 }
in the group entry for each wheel, next to the entry. This stands for Dynamic Coordinate System, and ensures that Panda will not optimize out the transform when it loads the model.


It is certainly fault of the Blender X exporter - by the way this is the best available around, home made from a contributor.
Well the situation for Blender is quite frustrating cos ALL the suitable Blender exporters (there are for dxf,lwo,wrl and even flt!) don’t match with Panda converters and I actually have no time and (above all) not enough skills for fix the x exporter. Maybe a day, if someone could tellme where to find some essential documentation about .x and .egg I will try to fix and perhaps improve it.

The egg syntax is fully documented in the Panda3D manual. You can find documentation on the .x syntax by searching; I have a link somewhere if you can’t find it through a search. There is also the “egg library”, C++ code that ships with Panda that can be used to generate an egg file. This is not as well documented in the manual, but the comments in the C++ code are fairly verbose and the code is fairly easy to read.


thanks a lot for the infos! asap I’ll give it a look