Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
On 23/03/2016 at 14:01, xxxxxxxx wrote:
User Information: Cinema 4D Version: R15 Platform: Language(s) : C++ ;
--------- I have a question regarding the way I'm supposed to read the length of a bone when using Melange. Do I have to read the value from the "Tweights" tag of the mesh using the "JointRestState" struct? Also, is this value "To child" or "From parent"? Is there a way to convert?
On 24/03/2016 at 07:49, xxxxxxxx wrote:
Hi,
you should be able to read the length from the joint directly. Like so:
GeData d; if (op->GetParameter(ID_CA_JOINT_OBJECT_LENGTH, d)) printf("\n - CAJointObjectData Length = %f\n", d.GetFloat());
On 24/03/2016 at 08:56, xxxxxxxx wrote:
Yes, I tried that, and I only get 0 values.
BTW, for my joint objects, when I do:
op->GetType();
I'm always getting 5100, which is Opolygon, instead of Ojoint. Of course this BaseObjects came from the Execute specific for Ojoint in my code:
class AlienJointObjectData : public JointObjectData { INSTANCEOF(AlienJointObjectData, JointObjectData) public: virtual Bool Execute(); };
Is this a bug? Could it be related to the 0 values I'm getting for bone length?
On 26/03/2016 at 11:39, xxxxxxxx wrote:
Are you sure you're returning the JointObjectData from AllocAlienObjectData() for Ojoint and not Opolygon? And return true from JoinObjectData::Execute()?
On 26/03/2016 at 14:29, xxxxxxxx wrote:
Yes, and yes.
NodeData *AllocAlienObjectData(Int32 id, Bool &known) { (...)some other code here(...) NodeData *m_data = nullptr; switch (id) { case Ojoint: m_data = NewObj(AlienJointObjectData); break; } return m_data; }
The id here ir the right one, but then when the Execute is called, the node type is the wrong one:
Bool AlienJointObjectData::Execute() { BaseObject *bo = (BaseObject* )GetNode(); std::string name = bo->GetName().GetCStringCopy(); int type = bo->GetType(); (...) some other code (...) return true; }
On 01/04/2016 at 06:39, xxxxxxxx wrote:
sorry, it took me so long to answer. Finally I had time to test it. Here it seems to work out of the box. I used the commandline example code included in the Melange archive (by the way I used the latest Melange version 16.008_156273 for my tests). I simply added the code from my first post to AlienCAJointObjectData::Execute(). It worked right out of the box and printed the length of the joints. Checking the type in there, worked like charm as well, op->GetType() correctly delivered Ojoint. So I'm actually not quite sure, what's going wrong on your end. I'd recommend to check with the commandline example as I did and then compare your implementation against it.
On 01/04/2016 at 08:05, xxxxxxxx wrote:
Hello again,
So I just tested it with the command line example, and I get the same problem, joints detected as polygon objects and length 0. So I assume this was a bug already fixed in the latest versions. I'm using 15.0_131581, I guess I have to update the libs.
Thanks!
EDIT: aside from the SDK issue, I had this on my BaseObject *AlienRootObject::AllocObject(Int32 id)
case Opluginpolygon: baseobject = BaseObject::Alloc(Opolygon); break;
I have no Idea why this was there, and why it makes the Ojoint become a Opolygon.
On 06/04/2016 at 09:18, xxxxxxxx wrote:
I did check our changelists and didn't find anything regarding the length of joints. Did you make any progress?
On 22/04/2016 at 08:47, xxxxxxxx wrote:
Hey,
Yes, it's working now after removing the line: case Opluginpolygon: baseobject = BaseObject::Alloc(Opolygon); break;
from: BaseObject *AlienRootObject::AllocObject(Int32 id)
I have no clue why I had this line there, but now it's fixed.
There's something strange though, I have a simple model with a few bones created in 3DSMax, I saved it to FBX, imported it in Cinema4D and then saved it again in C4D format. When I read the bone length from the FBX file, I get values 7 times higher than the values from the C4D file. Everything else is the same, normals, vertices and so on. I checked both files in txt format, and confirmed that the lengths are different 7 times lower for C4D.