Learning Poser Python...

[Ken1171]

Here's my first results. The script is make of 4 classes, but we only need to call one of them. What it does is defined by a text file that indicates what overlays are created over what MAT zones. The text file has only 4 lines, defining the figure, the list of MAT zones, and the list of overlay textures that go on each of those MAT zones. Of course, the script requires that these 2 lists must have the same number of items. Below is the definitions I have used for this example:
============
Figure: Dawn
MatZones: 3_Face, 3C_Body, 3C_Hip, 3B_Legs, 3A_Collars, 3A_Arms
OverlayMaps: Strips_head_Color.PNG, Strips_torso_Color.PNG, Strips_torso_Color.PNG, Strips_legs_Color.PNG, Strips_limbs_Color.PNG, Strips_limbs_Color.PNG
TexturesPath: Runtime\Textures\Ken1171\KittyOverlays
============

This example creates and inserts texture overlays over 6 MAT zones, and they apply over whatever textures the figure already has on stage. Below is the resulting "kitty stripes" over 3 different existent body textures on Dawn. By creating a new definitions text file, we can apply any overlay textures over any number of specific MAT zones, which also means it works with any figures.

I haven't learned how to create Python graphic interfaces yet, so this has to be ran from the Python Scripts menu in Poser. If we want to use a different definitions file, we need to edit the main script file, which only has 3 lines. See below. Just change "filename" from the 2nd line to the new text file name, and run it. Pretty simple. The effect applies to whatever figure is selected. This saves me a lot of manual labor.

=============
from Overlay_Loader import OverlayLoader
filename= 'def_DawnStripes.txt'
OverlayLoader(fileName, path).execute()
=============

I just need to adjust the code to also work with textures applied to the "alternative diffuse" channel, and it will be complete. ^______^

 

[phdubrov]

dev(elopment) mode - just make it on a fly, these parts are to enable edit of imported modules without Poser reload. Works only for pretty simple cases, there is a lot on Google about possible caveats. Probably could even make a Poser Python test suite this way.

AltDiffuse: if you aim for FF, yes, the only way is to apply the overlay to all Alt inputs. Some people use AltSpecular too.
In SF layers are the best way IMO, they can be more agnostic about the underlying shader structure.

 

[Ken1171]

dev(elopment) mode - just make it on a fly, these parts are to enable edit of imported modules without Poser reload. Works only for pretty simple cases, there is a lot on Google about possible caveats. Probably could even make a Poser Python test suite this way.

I still don't understand what this is. Is this a Poser Python special method, or a general Python thing? Do I have to call this method in every imported class that was been changed?

AltDiffuse: if you aim for FF, yes, the only way is to apply the overlay to all Alt inputs. Some people use AltSpecular too.

Actually, no. My overlays can be applied to either textures plugged into the regular diffuse color, or to the alternate diffuse channel. Some materials plug their textures to diffuse, and some to alternate diffuse, so my script has to cover both cases. I have finished that part and it now automatically detects which case it is, and inserts the overlay to the proper places. It works with both cases. Not sure why you believe overlays should only work with alternate diffuse. It works with both.

In SF layers are the best way IMO, they can be more agnostic about the underlying shader structure.

I prefer to avoid layers because they are not backwards compatible with Poser 9 and 10. I instead use regular shader nodes to create overlays, so it works in any Poser version. However, I still have no idea how to reach Superfly nodes with Python, so far my script only supports FF. I only know how to use the Physical Surface root node. I am not sure if this would work with the native Cycles Root node.

First I need to find out how to detect which root node is being used in Poser 11. This check can only be done in P11, so I also have to check the Poser version before doing that. I think it should be enough if the script supports just the Poser Surface and Physical Surface roots. At this point, NONE of the character materials in my Dawn runtime actually use native Cycles nodes, so it should be fine.

 

[phdubrov]

It's general Python. Reload is called on modules, del on instances.

Not sure why you believe overlays should only work with alternate diffuse.

Wrong wording on my part, I meant that overlays are the only way to go in FF render engine.

 

[Ken1171]

It's general Python. Reload is called on modules, del on instances.

Oh I see! I have to try that. Thanks for the hint!

Wrong wording on my part, I meant that overlays are the only way to go in FF render engine.

What do you mean? These same shader nodes overlays also work with SF Physical Surface. And even when used on Poser Surface, they render fine with SF as well. I do that quite often, since SMS made the FF shader nodes compatible with SF. In short, these texture overlays work in both FF and SF renders, no matter which root node was used. The same method also works with shader bricks in DAZ Studio, I have already done it. I am not sure why you believe they are particular to the FF engine?

 

[phdubrov]

No, I meant that is only one way in FF and two ways in SF.

 

[Ken1171]

This one uses a simple multiply node to add the overlay map to each map zone, but I have used a different, more elaborated method to create the 70 combinations of war paint, skin textures and 2 kinds of dirt maps on my Zariyah Savage Warrior for Dawn. In that one, we can mix layers of overlays using shader nodes, and we can also control the overlay colors. The overlays were connected to Poser Surface, and also to Physical Surface, taking advantage of the nodes compatibility between FF and SF.

This makes at least 2 ways to do it Poser FF, and that's without using P11 layers, which make a 3rd way. When we have shader nodes, there is always another way.

 

[Ken1171]

Ok, I have figured out how to locate and edit the PhysicalSurface root node. Applying an overlay becomes a matter of considering 4 cases:

* Which root nodes exist in each MAT zone? Could be PoserSurface, PhysicalSurface, and also CyclesSurface. In this script I am considering the first two. I don't know how to build shaders with native Cycles nodes anyway. ;p

* If PoserSurface root exists, are the textures plugged into Diffuse_Color or Alternate_Diffuse? I check them out and handle both cases.

So now I suppose the script can handle any kind of materials present on the figure (FF or SF, Diffuse or AltDiffuse), except for native Cycles shaders, which I haven't seen around yet. The number of classes has grown to 5 now, which is still pretty good.

The next step is to learn how to build graphical interfaces with the wxPython API. This should allow us to choose from a list of overlay configuration profiles instead of having to edit the script text to type it in. I am a bit intimidated by this API, but it somehow reminds me of the old Adobe Flex MX API, which also worked with the same kind of HTML layout as mxPython seems to use.

Once I get the GUI part, the script will display a list of overlay profiles, and when you click on one of them, it creates and inserts the respective overlays into the existing figure materials. Should be a 1-click operation. The cool thing is that we can create different overlay profiles that do different things to the figure. It could something as simple as adding a tattoo to a specific MAT zone, or like in the example above, apply several overlays over several MAT zones. That's the idea.

 

[phdubrov]

If the script will only suggest a selection of existing profiles, and the list is relatively small, you can use much simpler poser.DialogSimple.AskMenu().

 

[Ken1171]

If the script will only suggest a selection of existing profiles, and the list is relatively small, you can use much simpler poser.DialogSimple.AskMenu().

YESSS, I was already looking into that option. The interface is rather ugly, but that would do the job. I have first checked Tkinter, and the interface looks dated. I was then going to look into wxPython API, but in the way I have discovered [in the Poser manual] that Poser lends some of its native interface elements, and that can be the simplest way to get this done.

But first, I need to learn how navigate through directory trees, and then collect a list of files from a certain folder. I have my Python book opened on the page that covers that, and I am about to do some testing to get the hang on it, the Python way.

 

[Miss B]

You know Ken, I remembered a little while ago, I have a PoserPython Methods Manual PDF file in my PP11 Documentation folder. Whether or not it came the PP11 installation, or whether I downloaded it from SM at a later date, or who knows where I got it from, but you should check to see if you have it, as it may very well help you. I haven't looked at it at all, because even though I have programming experience with several languages, I've never done any Python programming . . . yet . . . so not sure what differences there would be from Poser's Python and the general Python programming.

I did check to see if I had it in my Poser 9 installation, but I have no Documentation folder in my P9 installation, so it may not have been available back then.

 

[Ken1171]

This PDF comes with Poser 11, and I couldn't have reached where I am now without it, because it's the ONLY source for the Poser-specific codes that are required by the Poser API. For example, if I want to create a texture image shader node, that can only be done with the ID code listed in the PDF.

However, that PDF is just a list of codes and API methods and specifications. It doesn't teach anything about PoserPython programming, so you have to learn it somewhere else. I have purchased Phil Cook's tutorial for Poser 8, which I believe is the ONLY one available, but it's outdated since it used a Python 2.6 (I think), and Poser is now using 2.7, where the declarations and syntax have changed. Some of the code from his tutorial will not work, which is bad when we are trying to learn from it. A good example was the different declaration syntax between a function and a class method, which in Phil's tutorial looks the same, but that won't work in the current version. He also has a section showing the differences in variable scope, and that didn't work as well. The syntax has changed.

I am used to Python 3, which is different from version 2.7 used in Poser. They have changed the syntax and sometimes I get stuck. When we search online, there is a lot of good material, but they never tell you what Python version was used.

I have now created a GUI for the script using Tkinter, and I am writing another class to collect the file listings from the folder, which was another challenge in Python. Now I am trying to put everything together.

 

[Miss B]

Ahhhh, so you have seen it. I find most "manuals" for software, or programming languages, are just that . . . they tell you what it "is", but not how to "use it". That's always disappointed me, and as you said, you have to go elsewhere to figure it out.

In most cases you can find tutorials for software, but it's hard finding tutorials for programming, unless you're taking an online course, and then it wouldn't necessarily be, as you've mentioned, for either the version you need, or the software you want to use it with.

 

[Ken1171]

I believe most online courses will only cover Python 3, but that's not what Poser uses. So far I could handle the differences, and I have been able to do what I wanted. I used to think it would be much more difficult than it actually is. I could break the ice in only 2 days, so it's not too bad. I just wish the Poser manual was a little more organized. With my books, the manual and PhilC's PDF tutorial, I have managed to get it going.

I only need to tweak the graphical interface a little more. Tkinter was created ages ago, and it wasn't meant to be used the way I do it. It's tedious but not difficult. For now I will settle with Tkinter for this simple interface, but I want to learn wxPython as well. It is newer and supposedly better. But one thing at a time.

 

[Miss B]

Well, I don't know how much you like YouTube tutorials, but I did a search and found this . . . which is only Part 1. Looks like there are at least 6 or 7 pieces to it.

Making Windows GUI with Python Part 1

 

[Ken1171]

Really cool, I definitely want to look into it soon. I already made my GUI in Tkinter, but I made it as a separate class, so it's easy to replace it with wx later on without changing or affecting any of the rest of the code.

So far this is what my tkinter GUI looks like. I have expanded the script to also be able to remove an overlay using the same or another compatible profile configuration file. For example, if one profile adds kitty stripes to body, and another adds only to the arms, if we remove using the arms profile, it preserves the rest of the body. This way a profile can be used to either add or remove overlays to different parts of the body. We can add overlays with one profile and remove with another one. This makes the script completely data-driven, where these text files tell it what to do and where.

I wish I had this when created my multi-layered overlays for Zariya. That was a lot of manual work.

 

[Miss B]

Glad I found a good video series for your project, and it sounds like you've got Tkinter working as you would expect it to.

 

[Ken1171]

Well, not exactly. I have only looked into tkinter for a day, and built a simple interface with it, but I need more than that. I need events to truly get it to work the way it should. I still haven't figured out how to handle events in Python yet, so the program is data-driven, but not event-driven. This has been a key problem, but it's just a matter of time.

My next script attempted to create a compound shader node in Poser, but the documentation has proven quite insufficient. Since the Poser manual is the only source, the programming went stale in no time. The manual just doesn't cover it. I can create a compound node, but there is no clue on how to group nodes into it, create the input and output interfaces, and so on.

My objective was to resolve an old problem. We can create complex compound nodes that resolve more complex issues with a simple black box approach, but Poser offers no way to save ONLY that node to the library, and then load it back in a different project without deleting everything else in the MAT zone. Python would allow me to insert one of those into any materials without destroying the existing shaders, so it could be integrated to work with them. Unfortunately the documentation leaves us to wonder how to handle compound nodes. For you to have an idea, there are only 2 occurrences of "compound node" in the manual, where both have a single line to describe it - as vague and generic as humanly possible. I will have to talk to someone from SMS if I want to proceed with this.

 

[phdubrov]

My objective was to resolve an old problem. We can create complex compound nodes that resolve more complex issues with a simple black box approach, but Poser offers no way to save ONLY that node to the library, and then load it back in a different project without deleting everything else in the MAT zone.

Poser offers. (Select - save only selected nodes, and use double check on load. Do it all the time.)
Poser Python not.

 

[Ken1171]

Very true, my friend - thank you! I forgot about these little icons. I was thinking on loading models, and didn't think that would also apply to materials. ^^

Is there a way to tell Python to load an existing saved MC6 or MT5 shader, so I can reuse shaders I have already created, instead of attempting to recreate them in code? In other words, what's the code to load an existing shader from the library using the "add to scene" (double check)? I know it can be done, because I have seen scripts from other people that have folders containing shader presets that are used by the script.