Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
"Drag Rotate" manipulator with animation from -15 to 15 degrees gives false "must have 1 axis" error #360
So, I've been trying to make a simple air conditioner slider, but its rot animation goes from -15º to 15º on the Z axis. The error I'd initially get was:
Drag Rotate manipulator attached to Mesh.11094 can only rotate around 1 axis
Very misleading error message. I tried removing the X and Y animations altogether, leaving only the Z, assuming that it might have been because of floating point variations. Still got the error.
It wasn't until I tried setting frame 1 to 0º, and frame 2 to 30º, offsetting the mesh by 15º, that I understood that the export script insists on it being configured this way. This should be made clearer in the error message.
Also, when I tried to replicate the issue, to write up this report, I changed frame 1 to some random number, so that I could reproduce the error message in the log, in order to copy and paste it for this report.
What happened, though, was that I got a Python error pop-up window, but nothing in the export log. The file didn't export.
It's these types of things with the new manipulators and new materials that give me the sense of "Death by a thousand paper cuts", where I spend insane amounts of time trying to track down why something won't export. It's additionally unsettling that sometimes the log will be misleading, and sometimes outright randomly non-functional.
Sorry to hear that you've been given misleading error messages. I'm confused about a couple of things, having a .blend file of this manipulator would help a lot in debugging it.
I think I can see how you've modeled this manipulator, but the exporter shouldn't be caring about this part of the animation. If you had set frame 1 to -15 degrees and frame 2 to 15 degrees it should export (assuming other things are correct too.) Editing the mesh so the animation can start at 0 degrees isn't our intended workflow. So, have I got it wrong (again a .blend file of just the manipulator would help here), was the feature not explained well, or is there a bug?
I'm very curious to see that Python error pop-up window. That means that the Python code crashed as opposed to cancelling the export cleanly.
If it seems like an insane amount of time, then it probably isn't a good use of your time. I can't tell you how to spend your working hours, but I recommend that you make a small .blend file and file a bug report with it attached before you reach that level of frustration. Take advantage of the fact that debugging, maintaining, and documenting this addon is my job instead of taking on those duties yourself. The testing phase of development is an asymmetric relationship: if I'm not doing the VAST majority of debugging a problem, then something is wrong with the relationship with our users.
OK, here's a test file. It shows two identical manipulators, the only difference being that one has an offset rotation. If you hide it, you can export the other one. Trying to export the one that's called "HideMeAndExportWorks", you'll get an error message.
Also, if you take the RIGHT manipulator (the one that should export without a problem), and change the initial rotation animation value to 1 instead of 0, and keyframe that, you get a Python error pop-up window, but no log error, when you try to export it.
The problem with creating test files and hunting down these issues is that, like in this case, it sometimes takes a while to realize that it isn't even exporting... then it takes a while to narrow down what the offending component is. Then, when you write up an error report, you have the sense that it won't even be looked at unless it's formulated in such a way that it registers as a legitimate / serious problem. Then, often you find that you're the only one with the issue, and later discover that it's because of something super silly, that has nothing to do with the actual bug. Until you've got the problem distilled to its actual parameters, a lot of time is spent on all these factors. Not exactly much that can be done about it. Other than maybe hoping for these types of things to be tested more thoroughly before being implemented in a release version of the XP2B script in the first place.
I tried moving the keyframes around, so the animation would start at 1 and finish at 2, 0->1, 0->24 (random choice), 6->30 (random choices), and they all exported fine. I'm not sure what the issue with the keyframes was, but, if you find it again please file a new bug and we'll conquer it there. I'm renaming this to better reflect the issue