DzSkinBinding question

Seven193

How can I programmatically change these values for a figure's skin binding?

​


 Binding (Skinning)"
 Weight Mapping Mode: General   (general,triax,blended triaxGeneral)
 General Weight Mode: Linear    (linear,dual quaternion)
   Scale Weight Mode: Binding   (binding,scale maps)

I found an old post mentioning these lines:
  skinBinding->setBindingMode( DzSkinBinding::General );
  skinBinding->setScaleMode( DzSkinBinding::BindingMaps );

https://www.daz3d.com/forums/discussion/58162/dzbone-and-weight-maps-handling-in-the-sdk

But, there are no such functions in the DS 4.5+ SDK.

Seven193

You see, when DzSkinBinding is created, it defaults to Triax mapping mode and Scale Maps.  I want to use General Weights mapping mode and Linear.   DzBoneBinding has methods to set both scaleWeights and generalWeights, but apparently these weight map arrays are ignored until the appropriate mapping mode is selected.

So, how to get the skin binding to use General Weights instead of Triax scaleWeights?

Seven193

Why are these two functions only available through scripting, and not the C++ interface?

void DzSkinBinding::setScaleMode(int)
void DzSkinBinding::setBindingMode(int)

They are kind of important when working with weights.

I did some searching, and I noticed dzfbximporter.dll uses these two functions.  This is a C++ compiled plugin, correct?
So, how are these two functions available to the FBX importer, and not the C++ SDK?
I have the feeling we're being short-changed.
 

Richard Haseltine

Seven193 said:

Why are these two functions only available through scripting, and not the C++ interface?

void DzSkinBinding::setScaleMode(int)
void DzSkinBinding::setBindingMode(int)

They are kind of important when working with weights.

I did some searching, and I noticed dzfbximporter.dll uses these two functions.  This is a C++ compiled plugin, correct?
So, how are these two functions available to the FBX importer, and not the C++ SDK?
I have the feeling we're being short-handed.

I'm not sure what "short handed" even means, but of course daz is free to have internal information which it keeps to itself. However, it is also expanding and modifying the SDK (abd script development kit) to support additional features, as noted in the change log, but these features are not rollwed out in official releases 9and may well be subject to change as they ar refined, quite possibly from the experience of using them in the Daz own-brand plug-ins and so on. People hated it when almost every release of Daz Studio required plug-ins to be updated and recompiled - it hasn't been necesary since the mid-poin of the Daz Studio 2 cycle, but people who experienced it still complain about Daz Studio needing plug-ins to be updated.

As long as you understand that you are using mutable, not yet finalised features that may be different or absent in the final build that brings a new SDK (Daz Studio 5) then I am told there are ways to use the information in the change log http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log to use QMetaObject if the class is moc'd to access the new features

TheMysteryIsThePoint

Richard Haseltine said:

I'm not sure what "short handed" even means, but of course daz is free to have internal information which it keeps to itself.

 

As long as we draw a distinction between what Daz is free to do, and what they are free to do and is tremendously frustrating and annoying for third party developers who are just trying to understand how the SDK that Daz has provided works in order to implement functionality that they need.

With all the tremendously cool functionality I've seen people implement in plugins, I can sincerely say that I do not understand why Daz does not see sufficient value in properly and officially supporting third party developers with a kind of Developer Program. I would pay dearly for such a thing if it freed me from these kinds of obstacles. Heck, make me a profit center, I don't care at this point :) If I can give money to Autodesk, a company I despise, I can give money to Daz, a company for which I have a great deal of affection.

 

Richard Haseltine

TheMysteryIsThePoint said:

Richard Haseltine said:

I'm not sure what "short handed" even means, but of course daz is free to have internal information which it keeps to itself.

 

As long as we draw a distinction between what Daz is free to do, and what they are free to do and is tremendously frustrating and annoying for third party developers who are just trying to understand how the SDK that Daz has provided works in order to implement functionality that they need.

With all the tremendously cool functionality I've seen people implement in plugins, I can sincerely say that I do not understand why Daz does not see sufficient value in properly and officially supporting third party developers with a kind of Developer Program. I would pay dearly for such a thing if it freed me from these kinds of obstacles. Heck, make me a profit center, I don't care at this point :) If I can give money to Autodesk, a company I despise, I can give money to Daz, a company for which I have a great deal of affection.

As I pointed out above, releasing new SDK versions at frequent intervals would not be an unmixed blessing for users, at least, and developing plug-ins against a potentially unstable (because still a WIP) SDK would not be an unmixed blessing for developers.

Seven193

Richard Haseltine said:

As long as you understand that you are using mutable, not yet finalised features that may be different or absent in the final build that brings a new SDK (Daz Studio 5) then I am told there are ways to use the information in the change log http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log to use QMetaObject if the class is moc'd to access the new features

This is news to me. If there's an example of how to access an unlisted class member function through the C++ interface, then I would definitely like to see it.

TheMysteryIsThePoint

Seven193 said:

Richard Haseltine said:

As long as you understand that you are using mutable, not yet finalised features that may be different or absent in the final build that brings a new SDK (Daz Studio 5) then I am told there are ways to use the information in the change log http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log to use QMetaObject if the class is moc'd to access the new features

This is news to me. If there's an example of how to access an unlisted class member function through the C++ interface, then I would definitely like to see it.

I think Richard is referring to Qt's system of making slots available via the moc compiler. If so, the calls you need will not be part of any compile time interface, but rather accessible through QMetaObject::invokeMethod().

The bad news is that, in true Daz form, there is probably zero documentation on any of that.

But the good news is that Qt's moc compiler and QObject provide runtime introspection, so I think you could find out everything you need even without the header files.

 

Richard Haseltine

TheMysteryIsThePoint said:

Seven193 said:

Richard Haseltine said:

As long as you understand that you are using mutable, not yet finalised features that may be different or absent in the final build that brings a new SDK (Daz Studio 5) then I am told there are ways to use the information in the change log http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log to use QMetaObject if the class is moc'd to access the new features

This is news to me. If there's an example of how to access an unlisted class member function through the C++ interface, then I would definitely like to see it.

I think Richard is referring to Qt's system of making slots available via the moc compiler. If so, the calls you need will not be part of any compile time interface, but rather accessible through QMetaObject::invokeMethod().

The bad news is that, in true Daz form, there is probably zero documentation on any of that.

As I said, these are "mutable, not yet finalised features that may be different or absent in the final build that brings a new SDK (Daz Studio 5)" - of course there is no documentation, and using this method is not-recommended and on-your-own-head-be-it, but it is there as an option if the developer is willing to take the chance. When the finalised SDK is released I am sure there will be documentation, even if it falls short of what you wish for.

But the good news is that Qt's moc compiler and QObject provide runtime introspection, so I think you could find out everything you need even without the header files.

Seven193

Thanks, this actually worked for me.

 

QMetaObject::invokeMethod( (QObject *)skinBinding, "setBindingMode", Qt::DirectConnection,                           Q_ARG(int, 0));QMetaObject::invokeMethod( (QObject *)skinBinding, "setScaleMode", Qt::DirectConnection,                           Q_ARG(int, 1));

 

Seven193

Why stop there, when you can dump them all.

 const QMetaObject* metaObject = (QMetaObject *)skinBinding->metaObject(); QStringList signatures; QStringList types; for(int i = metaObject->methodOffset(); i < metaObject->methodCount(); i++) {    signatures << QString::fromLatin1(metaObject->method(i).signatures());    types << QString::fromLatin1(metaObject->method(i).typeName()); }

 

TheMysteryIsThePoint

Seven193 said:

Thanks, this actually worked for me.

 

QMetaObject::invokeMethod( (QObject *)skinBinding, "setBindingMode", Qt::DirectConnection,                           Q_ARG(int, 0));QMetaObject::invokeMethod( (QObject *)skinBinding, "setScaleMode", Qt::DirectConnection,                           Q_ARG(int, 1));

Glad it worked. If you don't mind my asking, you seem to be working on something cool. Anything you can mention?

TheMysteryIsThePoint

Richard Haseltine said:

TheMysteryIsThePoint said:

Seven193 said:

Richard Haseltine said:

As long as you understand that you are using mutable, not yet finalised features that may be different or absent in the final build that brings a new SDK (Daz Studio 5) then I am told there are ways to use the information in the change log http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log to use QMetaObject if the class is moc'd to access the new features

This is news to me. If there's an example of how to access an unlisted class member function through the C++ interface, then I would definitely like to see it.

I think Richard is referring to Qt's system of making slots available via the moc compiler. If so, the calls you need will not be part of any compile time interface, but rather accessible through QMetaObject::invokeMethod().

The bad news is that, in true Daz form, there is probably zero documentation on any of that.

As I said, these are "mutable, not yet finalised features that may be different or absent in the final build that brings a new SDK (Daz Studio 5)" - of course there is no documentation, and using this method is not-recommended and on-your-own-head-be-it, but it is there as an option if the developer is willing to take the chance. When the finalised SDK is released I am sure there will be documentation, even if it falls short of what you wish for.

Yes, Richard, I am sure that is why it is not documented.

Richard Haseltine

TheMysteryIsThePoint said:

Richard Haseltine said:

TheMysteryIsThePoint said:

Seven193 said:

Richard Haseltine said:

As long as you understand that you are using mutable, not yet finalised features that may be different or absent in the final build that brings a new SDK (Daz Studio 5) then I am told there are ways to use the information in the change log http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log to use QMetaObject if the class is moc'd to access the new features

This is news to me. If there's an example of how to access an unlisted class member function through the C++ interface, then I would definitely like to see it.

I think Richard is referring to Qt's system of making slots available via the moc compiler. If so, the calls you need will not be part of any compile time interface, but rather accessible through QMetaObject::invokeMethod().

The bad news is that, in true Daz form, there is probably zero documentation on any of that.

As I said, these are "mutable, not yet finalised features that may be different or absent in the final build that brings a new SDK (Daz Studio 5)" - of course there is no documentation, and using this method is not-recommended and on-your-own-head-be-it, but it is there as an option if the developer is willing to take the chance. When the finalised SDK is released I am sure there will be documentation, even if it falls short of what you wish for.

Yes, Richard, I am sure that is why it is not documented.

So why take digs at the documentation? Doing that is not helping you to make your case, or secure off-the-clock help.

Seven193

TheMysteryIsThePoint said:

Glad it worked. If you don't mind my asking, you seem to be working on something cool. Anything you can mention?

This is just my own personal project that I'm working on by myself in my free time.  There are still a lot of small issues I need to figure out, so I have nothing to promote right now.