Saving Genesis expressions
Keep us posted as to how you like it.
Will do. I have concerns that I'm going to have to manually specify every required parameter dial, and if so, how arduous that will be, but hopefully looking at Netherworks' comment, there may be a simple way to do so.
@Netherworks Hey Nether - just to save me ages of reading, is there a non zero filter? I tried using (neg) and (pos) and it picked up dials outside the selected body part.
When I go to save a pose file, none of my filtered parts are preselected. Is there a quick way to transfer the filtered list to the save list?
Non-zero filter: use (val)
If you want only parmeters and morphs use (val), (dial)
No, filtered parts are not pre-selected but... If you select them in the dials list then go to write dial pose and right click the left side, there is an entry "Select Dials selected in Dial List" and that should checkmark them.
Keep in mind that when you get everything selected and you might be interested in doing this more than once on the same figure, you can create a Pose Preset that can be used later to select what you had checked before.
@Netherworks That sounds exactly the ticket - thanks Nether!
@matb Okay, really liking some of the design features in this program Nether, but I'm hitting two repeated problems with the Genesis male figure:
I select the head then use the parm and vis filters to select only parameter dials
Reset all dials to zero to create a reset pose
Save that set for later use
Open write pose and transfer dials
Receive following error
"Traceback (most recent call last):
File "D:\Poser\Poser 11\Runtime\Python\poserScripts\Netherworks\Dial Manager 2015_nwsdialmanager2015.py", line 1061, in NWS_Click
AttributeError: 'NoneType' object has no attribute 'InternalName'"
Select smaller subset (expression dials only - receive no error)
Dial eyes closed to 1
save pose file
reset expression by undoing
apply pose file
Eyes "double closed" ie eyelid is closed too far
Apply "broken" reset pose. Pose resets fine.
Netherworks last edited by Netherworks
2 is likely because there is internal wiring that it can't figure out, so you'd have to isolate the one dial that is doing both eyes closed and dial that to 1 and try saving the pose. If it still does it, there is something internal in the figure that is mucking it up and there isn't a resolution. Try to save with "Resolve Value Operations and Adjust Pose" unchecked.
1 I'm not really sure, again there are most certainly something odd going on in there if it is governed by DSON for Poser.
I don't have DSON for Poser installed. Which version of Genesis is this? If version 1 or 2, have you tried to instead just export the cr2 out of DAZ Studio and see if writing expressions works that way
Thanks Nether - ever helpful! It's genesis 1. I haven't even moved onto 2 or 3 which I suspect are goimg to be considerably more problematic.
As for importing as CR2, I was trying to kee things as vanilla as possible because I want to produce commercial files and I don't want something that would be unreliable for other users. Would importing as a CR2 cause any such problems in your experience?
I'll try to look at this soon and see if there's any relief, I just want to be realistic that there are some tricky thing in there with the DSON Poser.
I don't think there would be any difference in the internal names whether exported as a cr2 from DS or loaded in Poser via DSON. I'm still a solid Poser user but I'll be working more in DS so I'll see if there are any differences.
I have installed the old genesis 1 package, Poser Genesis and the DSON.
Yeah, the rigging is working against us here, big time.
- Many, many dials are double-rigged. This might be an issue in itself. When Dial Manager reads the dials to write a pose, with the first option checked it normally should be able to resolve what is connected to what but it could be a "double child connection". Example is Eyes Closed drives a secondary dial and that secondary dial drives another secondary dial. So it doesn't see the second secondary dial driving the primary dial.
- Another big issue is that even though there are 2 secondary dials affecting a primary dial, both secondary dials have the same exact "friendly" name, which should be illegal. So, for eyes closed, we have Eyes Closed, Eyes Closed Left, Eyes Closed Left and 2 right ones with the same external name. This doesn't make a lot of sense to me because 2 of those dials are hidden so it shouldn't matter what the external name is because the user won't see it normally anyways.
- Regardless, the above is throwing off the Pose writing because it reads External Names and matches them that way. So, even if you only include visible dials, its going to try and select the invisible ones causing the same problem.
- The error issue when everything is selected is some kind of odd actor or object in the DSON system that breaks the script but I already fixed that, maybe, locally. I'm not sure what is causing it.
I have a screen shot where you can get an idea of the issue. See the highlighted section where there are two sets of completely identical external names.
Netherworks last edited by Netherworks
I think I can resolve this.
The best way to just fix the whole thing is to have an option to exclude hidden dials (see the 2nd checked option, this is on by default). These are not dialed by the user anyways.
I tried to get it to better resolve the connections but some of the dials in Genesis 1 read as looping back to themselves.
Genesis 2 is wired much differently and doesn't seem to have the issues that Genesis 1 has.
It also, by default, excludes a lot of internal wiring junk that DSON writes into the cr2 and that we don't need into a Pose file like DSON controller information. It has nothing to do with applying a pose. I may exclude the "EndPnt" type body parts from showing up as well. They are hidden bones that are extraneous. Why they are there? Probably some kind of construct when going from a single figure rigging system to a temporary cr2 which is what DSON writes when you load something.
I'm also adding an option to write the version number of the Pose as some places require this. Before it would just write version 6.
This is going to take some study by me to understand your answers, but I greatly appreciate you looking into it. I did try to export the CR2s from DAZ Studio, but this has lead to additional problems - namely that Genesis male is recognised in Poser but NOT in DS!!! This means that when I want to export with textures (or install additional Genesis stuff) the program doesn't detect the original Genesis package. It's a while since I installed Genesis in Poser, so this is a tediously time consuming diversion that I didn't need before trying to resolve a "simple" pose solving issue. I went to daz to find out precisely what I had bought, or needed to buy to install the basic genesis package, typing in "Genesis" and it simply will not tell me the progam dependencies. It tells you that the Genesis starter bundle NEEDS Genesis, but not how to acquire it. I assume that it maybe came free with DS. None of which is your problem, but just letting you know why I really would rather not go down the CR2 export option...
Don't worry about it. I tend to "think out loud". I think I can sort it out.
@Netherworks I'm happy to hear your thoughts - it informs my future debugging - but it's only this year that I've started really tinkering under the hood in this area, so some of this is new to me. So are you saying that there are nested dependent drivers?
And I thought that naming multiple parts the same was a cardinal sin with Poser figures?
@Netherworks Thank you for your new version of the program. It works perfectly. Super customer service!
You're welcome. I'm going to run a few more tests before releasing an update.
The issue is partly my fault but there are complications. The complication is that when you dial a master parameter, python sees all numbers that aren't zero as being dialed as well. So, if you have a driver that drives two other dials and you have them at 1, python sees them all as being 1. That is the cause of the double-up. It does try to resolve the connections but it isn't going deep enough to get them.
One way to avoid the double connections is to prevent it from writing values for hidden parameters, which is one option that I've added. You don't need to write the hidden parameters anyways if they are driven by something else.