I am trying to export the default toon character to Torque. I am brand new to Houdini, so don't know what I am doing most of the time. I have been through a lot of tutorials and still am having trouble.
I have the latest Houdini 10.0.430. I start a new project and get the default Toon.
I then go to the out panel and create a new Torque node.
I fill it out per the tutorial that I watched and Render it. I get these errors in the dump.html file:
Adding mesh of size 2 to object “proxy_upperarm”.
Adding node “proxy_forearm2” with parent “start01” to subtree rooted on node “base01”.
Attaching object to node.
Adding object named “proxy_forearm”.
Adding mesh of size 2 to object “proxy_forearm”.
Adding node “proxy_upperarm2” with parent “start01” to subtree rooted on node “base01”.
Attaching object to node.
Adding mesh of size 2 to object “proxy_upperarm”.
Found two meshes named “proxy_upperarm” of size 2.
Warnings:
No warnings.
Errors:
Error #40:Found two meshes named “proxy_upperarm” of size 2.
Toon Character Torque Export Problem
44301 67 1- tpitman
- Member
- 82 posts
- Joined: Nov. 2009
- Offline
- edward
- Member
- 7899 posts
- Joined: July 2005
- Offline
- tpitman
- Member
- 82 posts
- Joined: Nov. 2009
- Offline
- edward
- Member
- 7899 posts
- Joined: July 2005
- Offline
3D Buzz has some old character rigging tutorials done in Houdini 5.5:
http://www.3dbuzz.com/vbforum/sv_houdini.php [3dbuzz.com]
The tools have moved around a bit but the process should be roughly the same.
http://www.3dbuzz.com/vbforum/sv_houdini.php [3dbuzz.com]
The tools have moved around a bit but the process should be roughly the same.
- tpitman
- Member
- 82 posts
- Joined: Nov. 2009
- Offline
- edward
- Member
- 7899 posts
- Joined: July 2005
- Offline
- DrFrankenRex
- Member
- 69 posts
- Joined: March 2008
- Offline
Yes, the autoRig tools will work. You will get slightly odd results, they work; but the resulting hierarchy in the DTS shape will not be a true ‘skeleton’. All the nodes are unchained from each branch and all children to a single node. This results in a DTS shape that must use DSQ files produced with this setup, as you get node transform data in the animations as well, and those transforms are used to create a ‘psuedoHierarchy’ to locate the nodes where they belong with their vertex/weight data.
It will take working the ROP to get the right geometry exporting with the right rig. As long as you keep the DSQ's made with this rig with the same DTS, it should work. However, opening the DTS shape elsewhere, and working with it, will not be doable…., and who needs that?!
Good luck!
It will take working the ROP to get the right geometry exporting with the right rig. As long as you keep the DSQ's made with this rig with the same DTS, it should work. However, opening the DTS shape elsewhere, and working with it, will not be doable…., and who needs that?!
Good luck!
- tpitman
- Member
- 82 posts
- Joined: Nov. 2009
- Offline
I did find a tutorial that shows animating a tube shape and exporting it to a DTS and showing it in ShowTool Pro. In the same tutorial the author imports an FBX Kork model with a dance animation and exports it to DTS and plays the dance animation in ShowTool Pro.
In both cases they didn't use a DSQ. Is that because it was set up differently than an auto rig? If so, what is the difference? Can someone point me to a tutorial that shows how to rig a model the same way as the Kork model using IK and everything? I hate to just do it the way the tube was animated because it didn't have any IK and would be a pain to pose because it is a humanoid I am working on.
The tutorial I am referring to is the one on the sidefx site found here:
http://www.sidefx.com/index.php?option=com_content&task=view&id=991&Itemid=258 [sidefx.com]
In both cases they didn't use a DSQ. Is that because it was set up differently than an auto rig? If so, what is the difference? Can someone point me to a tutorial that shows how to rig a model the same way as the Kork model using IK and everything? I hate to just do it the way the tube was animated because it didn't have any IK and would be a pain to pose because it is a humanoid I am working on.
The tutorial I am referring to is the one on the sidefx site found here:
http://www.sidefx.com/index.php?option=com_content&task=view&id=991&Itemid=258 [sidefx.com]
- rafal
- Staff
- 1455 posts
- Joined: July 2005
- Offline
Not sure if this helps you and you may have already seen this, but there is some info about rigging in the documentation in Help > Houdini Help or on-line:
http://www.sidefx.com/docs/houdini10.0/character/ [sidefx.com]
especially about IK:
http://www.sidefx.com/docs/houdini10.0/character/drawbones [sidefx.com]
http://www.sidefx.com/docs/houdini10.0/character/ [sidefx.com]
especially about IK:
http://www.sidefx.com/docs/houdini10.0/character/drawbones [sidefx.com]
- tpitman
- Member
- 82 posts
- Joined: Nov. 2009
- Offline
- tpitman
- Member
- 82 posts
- Joined: Nov. 2009
- Offline
I found a way to get part of the way to what I need.
I started a whole new character from an FBX skin only. I then added the auto rig for biped and followed the Houdini tutorial for rigging the quadraped.
When I got to the end of the tutorial what I had was a rigged character with a simple animation.
When I went to export it to Torque I got similar errors to what I have described before. Errors about having duplicate bones.
As I looked into it I realized what the problem is. The problem is that the torque exporter doesn't take into account the hierarchy. For example there is a left_arm/joint_shoulder. There is also a right_arm/joint_shoulder. Well, the torque exporter sees them both as joint_shoulder and craps out because there are 2 objects with the same name.
So one solution is to dive into the left and right nodes and change the names of every joint under them to have a _l or _r or something like that in the name.
Once you do this you can export without errors. I assume the same would be true of the toon character.
So now the new problem: If you try to save this you get an error on Windows Vista or 7 because you don't have write permissions on the default older that those items OTLs are stored in.
Any suggestions to fix that?
The second problem is that even though my skin animates in Houdini and the bones animate in the torque output, the skin doesn't animate in the torque output. Is this because I chose to use muscles instead of bones?
Can I easily fix that without having to go through the whole weight painting again?
I started a whole new character from an FBX skin only. I then added the auto rig for biped and followed the Houdini tutorial for rigging the quadraped.
When I got to the end of the tutorial what I had was a rigged character with a simple animation.
When I went to export it to Torque I got similar errors to what I have described before. Errors about having duplicate bones.
As I looked into it I realized what the problem is. The problem is that the torque exporter doesn't take into account the hierarchy. For example there is a left_arm/joint_shoulder. There is also a right_arm/joint_shoulder. Well, the torque exporter sees them both as joint_shoulder and craps out because there are 2 objects with the same name.
So one solution is to dive into the left and right nodes and change the names of every joint under them to have a _l or _r or something like that in the name.
Once you do this you can export without errors. I assume the same would be true of the toon character.
So now the new problem: If you try to save this you get an error on Windows Vista or 7 because you don't have write permissions on the default older that those items OTLs are stored in.
Any suggestions to fix that?
The second problem is that even though my skin animates in Houdini and the bones animate in the torque output, the skin doesn't animate in the torque output. Is this because I chose to use muscles instead of bones?
Can I easily fix that without having to go through the whole weight painting again?
- rafal
- Staff
- 1455 posts
- Joined: July 2005
- Offline
You should not need to edit the assets that come with Houdini. But if you find that you really need to, you could make a copy of the original HDA and give it a new operator type name. The new HDA will be editable and savable and you can use that HDA in your work.
You can make a copy of HDAs in OTL Manager window by right clicking on the HDA and choosing Copy. Give your new HDA a new name and label and specify the OTL file where you want to save it. The OTL file should be in the OTL searchable path so that Houdini can find it and pick it up on startup. The default “Save to Library” path is probably the best, but you may want to change the OTL file name from OPcustom.otl to MyRigs.otl or something like that.
Operator Manager and copying:
http://www.sidefx.com/docs/houdini10.0/ref/windows/optypemanager [sidefx.com]
OTL search paths:
http://www.sidefx.com/docs/houdini10.0/assets/install [sidefx.com]
HDA in general:
http://www.sidefx.com/docs/houdini10.0/assets/ [sidefx.com]
However, the shelf tools will still instantiate the original HDA nodes. So you may need to use own shelf tools. Another (cumbersome) workaround is to use the original shelf tools but then change the type of the instantiated nodes by Right-Clicking on them and choosing Change Type.. then browsing and using your own copies of the HDA you made above.
I am not sure about the fix for the second problem though.
You can make a copy of HDAs in OTL Manager window by right clicking on the HDA and choosing Copy. Give your new HDA a new name and label and specify the OTL file where you want to save it. The OTL file should be in the OTL searchable path so that Houdini can find it and pick it up on startup. The default “Save to Library” path is probably the best, but you may want to change the OTL file name from OPcustom.otl to MyRigs.otl or something like that.
Operator Manager and copying:
http://www.sidefx.com/docs/houdini10.0/ref/windows/optypemanager [sidefx.com]
OTL search paths:
http://www.sidefx.com/docs/houdini10.0/assets/install [sidefx.com]
HDA in general:
http://www.sidefx.com/docs/houdini10.0/assets/ [sidefx.com]
However, the shelf tools will still instantiate the original HDA nodes. So you may need to use own shelf tools. Another (cumbersome) workaround is to use the original shelf tools but then change the type of the instantiated nodes by Right-Clicking on them and choosing Change Type.. then browsing and using your own copies of the HDA you made above.
I am not sure about the fix for the second problem though.
- tpitman
- Member
- 82 posts
- Joined: Nov. 2009
- Offline
The only reason I need to make my own version is because the Torque export doesn't use the hierarchy when it exports so you get 2 over all the arm and leg joints in the output and that doesn't work for Torque.
for example you get joint_shoulder for the left arm and joint_should for the right arm.
Thanks for the info. I will have to see about making my own versions of those.
Any idea how to modify the auto rig scripts as well to use my new ones?
for example you get joint_shoulder for the left arm and joint_should for the right arm.
Thanks for the info. I will have to see about making my own versions of those.
Any idea how to modify the auto rig scripts as well to use my new ones?
- rafal
- Staff
- 1455 posts
- Joined: July 2005
- Offline
Well, if you want to avoid tinkering with scripts, you can save your own HDAs with the same operator type name as the originals. Then, they will override the original definitions when Houdini loads them, and Houdini will use yours throughout the session. Just make sure they show up as green in Window > Operator Type Manager. If not right-click on your version of the HDA and choose “Use this definition”. You can tinker with configuration tab to get Houdini to automatically choose your definitions as default ones.
But, if you want to have both original and your own autorig tools available in the same Houdini session, then you will need to dive in the scripts. I am not too familiar with autorigs and their scripts, but here are some hints.
The autorig scripts are in $HFS/houdini/python2.x/autorig/ directory. In Window > Hscript Textport type “echo $HFS” to find out what your HFS is. Most of the functions will work fine with your HDAs without any tweaking. But there may be some naming conventions that you may need to follow, like for example, rigtoolutils.py seems to have “auto_rig_*” as pattern for operator type name for some action.
The shelf tools invoke these scripts when you press the shelf tool button (eg “Create Auto Rig”). To see that, right click on the shelf button, choose Edit Tool and then inspect the code in the Script tab.
You can make a copy of such a tool and then change the code to suit your own rig name. In the Tool Editor dialog, in the Options tab, change the name and label of the tool (from ‘object_biped_auto_rig’ to ‘object_biped_auto_rig_v2’ and label to “My Biped Auto Rig”). The shelf tool name should follow a convention where first word ‘object_’ is the name of the network type and is followed by the operator name ‘biped_auto_rig_v2’ if your own rig name is ‘biped_auto_rig_v2’. Now you can click accept and your own version of the shelf tool will replace the original one on that shelf. You can still add the original tool back to the shelf (though you need to restart Houdini, for some reason), by right-clicking on the tab and choosing “Edit Tab” and then searching out and selecting the “object_biped_autor_rig” tool from the list on the Tools tab.
Here is more on shelf tools:
http://www.sidefx.com/docs/houdini10.0/shelf [sidefx.com]
and an in-depth doc:
http://www.sidefx.com/index.php?option=com_content&task=view&id=966&Itemid=305 [sidefx.com]
You can then see which scripts (in $HFS/houdini/python2.x) are called from the shelf tools that you are using, and then you may try to copy, edit and use own scripts.
But, if you want to have both original and your own autorig tools available in the same Houdini session, then you will need to dive in the scripts. I am not too familiar with autorigs and their scripts, but here are some hints.
The autorig scripts are in $HFS/houdini/python2.x/autorig/ directory. In Window > Hscript Textport type “echo $HFS” to find out what your HFS is. Most of the functions will work fine with your HDAs without any tweaking. But there may be some naming conventions that you may need to follow, like for example, rigtoolutils.py seems to have “auto_rig_*” as pattern for operator type name for some action.
The shelf tools invoke these scripts when you press the shelf tool button (eg “Create Auto Rig”). To see that, right click on the shelf button, choose Edit Tool and then inspect the code in the Script tab.
You can make a copy of such a tool and then change the code to suit your own rig name. In the Tool Editor dialog, in the Options tab, change the name and label of the tool (from ‘object_biped_auto_rig’ to ‘object_biped_auto_rig_v2’ and label to “My Biped Auto Rig”). The shelf tool name should follow a convention where first word ‘object_’ is the name of the network type and is followed by the operator name ‘biped_auto_rig_v2’ if your own rig name is ‘biped_auto_rig_v2’. Now you can click accept and your own version of the shelf tool will replace the original one on that shelf. You can still add the original tool back to the shelf (though you need to restart Houdini, for some reason), by right-clicking on the tab and choosing “Edit Tab” and then searching out and selecting the “object_biped_autor_rig” tool from the list on the Tools tab.
Here is more on shelf tools:
http://www.sidefx.com/docs/houdini10.0/shelf [sidefx.com]
and an in-depth doc:
http://www.sidefx.com/index.php?option=com_content&task=view&id=966&Itemid=305 [sidefx.com]
You can then see which scripts (in $HFS/houdini/python2.x) are called from the shelf tools that you are using, and then you may try to copy, edit and use own scripts.
- tpitman
- Member
- 82 posts
- Joined: Nov. 2009
- Offline
This is great information. I hope to be able to make the changes I need.
Maybe a better way to go, rather than changing the auto rig script and type libraries, would be to change the Torque export script. I have 2 questions about that:
1. Where would I find this script? It is not on the shelf. I create this OUT node by hitting while showing the OUT “area?” In the lower right panel of Houdini. then I type Torque and it puts a Torque output node there. So I need to know what this thing is and how to change it.
2. Basically if my hierarchy has left_arm/joint_shoulder and right_arm/joint_shoulder in it this output script currently tries to output 2 joint_shoulder nodes when really I need them to be left_arm_joint_shoulder and right_arm_joint_shoulder.
Maybe a better way to go, rather than changing the auto rig script and type libraries, would be to change the Torque export script. I have 2 questions about that:
1. Where would I find this script? It is not on the shelf. I create this OUT node by hitting while showing the OUT “area?” In the lower right panel of Houdini. then I type Torque and it puts a Torque output node there. So I need to know what this thing is and how to change it.
2. Basically if my hierarchy has left_arm/joint_shoulder and right_arm/joint_shoulder in it this output script currently tries to output 2 joint_shoulder nodes when really I need them to be left_arm_joint_shoulder and right_arm_joint_shoulder.
- rafal
- Staff
- 1455 posts
- Joined: July 2005
- Offline
The Torque output (render) node is implemented in C++. It is not an HDA or a script, so you won't be able to modify it.
To find out that that's the case, you can do a bit of a detective work:
- the TAB menu entries in the network pane are shelf tools (though represented as a menu rather than buttons)
- to inspect the tool code, you first need to place it on the shelf. So Right Click on some shelf tab and choose “Edit tab”. Then in the Tools, scroll down to find Torque (driver_torque). Select it and then click Accept. The Torque tool should appear on the shelf.
- Right click on the Torque shelf tool button and choose “Edit Tool”, and then in the Script tab notice that the generic instantiating call is made with the operator type named ‘torque’. You could deduce that by looking at the shelf tool since this tool follows the standard naming convention net-type_op-type, where net-type is ‘driver’ and op-type is ‘torque’.
- now, go to Window > Operator Type Manager, and type “torque” in the filter field. You will see that the “Driver/torque” shows under “Internally Defined Operators”. The HDAs show up under “Operator Type Libraries”.
So, the torque node is defined internally (ie, in C++), and shipped as a library (probably in $HFS/houdini/dso).
So, in short, I don't think you will be able to do things you describe in 1)
As for the problem described in 2), I am not too familiar with Torque, but perhaps you can write a script that processes the exported file, and somehow renames joint_shoulder to either left_arm_joint_shoulder and right_arm_joint_shoulder, based on some heuristics.
To find out that that's the case, you can do a bit of a detective work:
- the TAB menu entries in the network pane are shelf tools (though represented as a menu rather than buttons)
- to inspect the tool code, you first need to place it on the shelf. So Right Click on some shelf tab and choose “Edit tab”. Then in the Tools, scroll down to find Torque (driver_torque). Select it and then click Accept. The Torque tool should appear on the shelf.
- Right click on the Torque shelf tool button and choose “Edit Tool”, and then in the Script tab notice that the generic instantiating call is made with the operator type named ‘torque’. You could deduce that by looking at the shelf tool since this tool follows the standard naming convention net-type_op-type, where net-type is ‘driver’ and op-type is ‘torque’.
- now, go to Window > Operator Type Manager, and type “torque” in the filter field. You will see that the “Driver/torque” shows under “Internally Defined Operators”. The HDAs show up under “Operator Type Libraries”.
So, the torque node is defined internally (ie, in C++), and shipped as a library (probably in $HFS/houdini/dso).
So, in short, I don't think you will be able to do things you describe in 1)
As for the problem described in 2), I am not too familiar with Torque, but perhaps you can write a script that processes the exported file, and somehow renames joint_shoulder to either left_arm_joint_shoulder and right_arm_joint_shoulder, based on some heuristics.
- tpitman
- Member
- 82 posts
- Joined: Nov. 2009
- Offline
I actually did discover the torque DLL thing myself as well. Thanks for the input on that. I am learning a ton from everyone's postings.
I started poking around in the auto rig scripts. It seems like there should be a way for me to make the renaming happen when the nodes are created. I haven't figured it out yet, though.
The on thing I noticed that is that there is not a left arm and right arm object. There is just an arm object. Then in the higher up object (auto rig, I think) there is a left arm folder and right arm folder that point point to the arm object.
What I am trying to figure out is if there is a way to modify the script that generates this stuff and do the renaming there.
If that doesn't work then maybe all I need to do is copy the arm object to a left and right version of it and then modify the main object to point to each of them instead of to the same one.
I started poking around in the auto rig scripts. It seems like there should be a way for me to make the renaming happen when the nodes are created. I haven't figured it out yet, though.
The on thing I noticed that is that there is not a left arm and right arm object. There is just an arm object. Then in the higher up object (auto rig, I think) there is a left arm folder and right arm folder that point point to the arm object.
What I am trying to figure out is if there is a way to modify the script that generates this stuff and do the renaming there.
If that doesn't work then maybe all I need to do is copy the arm object to a left and right version of it and then modify the main object to point to each of them instead of to the same one.
- rafal
- Staff
- 1455 posts
- Joined: July 2005
- Offline
Indeed, left_arm and right_arm nodes are two instances of the same HDA definition (animation_rig_biped_arm). HDAs are usually networks of nodes theselves, that's why you can dive into them (you call them folders) to reveal their contents, although you cannot edit this contents in locked (synced) HDA nodes.
Even if you modified the HDA definition, it would be equally applied to both left_arm and right_arm when these two are created. There is no conditional execution that can selectively change node names. Btw, you usually modify the HDA contents definition by unlocking an HDA instance node, making some changes, and saving the definition based on the modified instance node (ie, “template”, or “example” as I informally called it).
But, even though two locked nodes cannot differ in their contents, this is not true for unlocked nodes. This is extremely hacky, but here is what you can do to rename the nodes:
- right click on the toon character node and choose Allow Editing of Contents
- dive inside and do the same for left_arm and right_arm
Now, left_arm and right_arm are “decoupled” from their original definition and you can edit their contents.
- dive inside left_arm and rename the node you want
- do the same with righ_arm
- now when you export with Torque, the exported file should have the new names
- you can choose File > Save to save your .hip file with your edits. The HDA definition of animation_rig_biped_arm is not altered. Your changes live only in the current session (ie, .hip file).
At this point, if you right click on left_arm (or right_arm) and choose Match Current Definition, your edits to the left (or right) arm will be erased and the node is going to be reverted to the original definition o animation_rig_biped_arm.
If you were to choose “Save Operator Type”, Houdini would try to update the definition of animation_rig_biped_arm, and all locked (synced) nodes of this asset would look exactly as the left_arm (or right_arm) “template” node. You probably don't want to do that, and it would not actually quite work even if you tried because the HDA definition of animation_rig_biped_arm is in a read-only file, so saving would not work. But, you could conceivably save it to another file. Still, it would be of no help to the problem you are trying to solve, because if you saved the HDA in the image of, say, left_arm, the next time you instantiated the biped rig, both left_arm and right_arm would contain your changes, which you probably want to apply only to the left_arm.
P.S.
Btw, if you are curious about the contents sections of the HDA and the actual script that builds the contents of an HDA node, you can use hotl command line utility to decompose the otl file into a file directory hierarchy that resembles the structure of the HDA definition:
http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=9978 [sidefx.com]
It seems like there should be a way for me to make the renaming happen when the nodes are createdWhen instantiating an HDA, the contents nodes are created by “sourcing” a contents section of the HDA definition. The contents section replicates the network that was used for saving the given HDA definition (ie, when you do RMB > Save Opertor type on an unlocked node, which becomes an “example” or a frozen “template” for the HDA definition).
What I am trying to figure out is if there is a way to modify the script that generates this stuff and do the renaming there.Unfortunately, you cannot really tweak the “sourcing” and thus cannot rename the contents nodes. That's because, the contents nodes of a locked HDA node must always match the HDA definition (which includes the content node names).
Even if you modified the HDA definition, it would be equally applied to both left_arm and right_arm when these two are created. There is no conditional execution that can selectively change node names. Btw, you usually modify the HDA contents definition by unlocking an HDA instance node, making some changes, and saving the definition based on the modified instance node (ie, “template”, or “example” as I informally called it).
But, even though two locked nodes cannot differ in their contents, this is not true for unlocked nodes. This is extremely hacky, but here is what you can do to rename the nodes:
- right click on the toon character node and choose Allow Editing of Contents
- dive inside and do the same for left_arm and right_arm
Now, left_arm and right_arm are “decoupled” from their original definition and you can edit their contents.
- dive inside left_arm and rename the node you want
- do the same with righ_arm
- now when you export with Torque, the exported file should have the new names
- you can choose File > Save to save your .hip file with your edits. The HDA definition of animation_rig_biped_arm is not altered. Your changes live only in the current session (ie, .hip file).
At this point, if you right click on left_arm (or right_arm) and choose Match Current Definition, your edits to the left (or right) arm will be erased and the node is going to be reverted to the original definition o animation_rig_biped_arm.
If you were to choose “Save Operator Type”, Houdini would try to update the definition of animation_rig_biped_arm, and all locked (synced) nodes of this asset would look exactly as the left_arm (or right_arm) “template” node. You probably don't want to do that, and it would not actually quite work even if you tried because the HDA definition of animation_rig_biped_arm is in a read-only file, so saving would not work. But, you could conceivably save it to another file. Still, it would be of no help to the problem you are trying to solve, because if you saved the HDA in the image of, say, left_arm, the next time you instantiated the biped rig, both left_arm and right_arm would contain your changes, which you probably want to apply only to the left_arm.
P.S.
Btw, if you are curious about the contents sections of the HDA and the actual script that builds the contents of an HDA node, you can use hotl command line utility to decompose the otl file into a file directory hierarchy that resembles the structure of the HDA definition:
http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=9978 [sidefx.com]
- tpitman
- Member
- 82 posts
- Joined: Nov. 2009
- Offline
I also proposed another possible solution that I didn't see you address. Maybe you did address it in a round about way that I didn't get, though.
My other option would be could I make a 2 copies of the generic arm node and call them left_arm and right_arm and then make a copy of the auto rig node and change it so that the left_arm network pointed to the new left_arm node and the same for the right arm?
My other option would be could I make a 2 copies of the generic arm node and call them left_arm and right_arm and then make a copy of the auto rig node and change it so that the left_arm network pointed to the new left_arm node and the same for the right arm?
- derrick
- Staff
- 332 posts
- Joined: July 2005
- Offline
tpitman
As I looked into it I realized what the problem is. The problem is that the torque exporter doesn't take into account the hierarchy. For example there is a left_arm/joint_shoulder. There is also a right_arm/joint_shoulder. Well, the torque exporter sees them both as joint_shoulder and craps out because there are 2 objects with the same name.
Tomorrow's build of Houdini (10.0.478) should no longer have this problem.
-
- Quick Links