Tiptoeing through the (c) minefield...

[Robynsveil]

First, a freebie for folks who want to play in Blender with Poser-posed figures. It's called Poser Figure Shader. This script will use the textures you use most on your favourite figure in Poser, and paints those textures - along with a rudimentary skin shader - onto your [export-from-Poser] -> [import-into-Blender] V4, Dawn or Mariko. I'm planning on adding support for Antonia, MyMichelle, Scarlet and Pauline (as well as the guys, of course)...

... but I thought I'd touch on a rather sensitive subject first: fair-use and copyright.

I know nothing. (can you hear Schultz, here?)
Simple question, therefore:
-- does exporting an obj from Poser, to import and render in other software constitute some sort of wrong-doing?

Second question:
-- would anyone be interested in testing this script for me?

If the first question is [Y], V4 (WM) is as far as I'll go with this script, although I'll definitely include support for Antonia. Not sure anyone still uses Antonia much, mind you. Still, she's open-source, so wouldn't present a problem for the script.

So, yeah, just curious.

 

[English Bob]

-- does exporting an obj from Poser, to import and render in other software constitute some sort of wrong-doing?

This is what happens when you render in any third-party renderer, such as LuxRender via Reality, POV-Ray via PoseRay, Vue, Bryce, Octane and others although I don't have experience of all of those. The export isn't usually OBJ, but the principle is the same; a mesh is being transferred between two applications. Effectively, this happens if you render in Poser using the queue manager, or even in a separate process! It isn't wrong as long as it's you doing the exporting and rendering.

What would be wrong, of course, is exporting a mesh for someone else to render; but you knew that.

(edited for clarity)

 

[Robynsveil]

Thank you, English Bob. Much respect for an icon of Poserverse: your perspective on things Poser-ish I hold in high esteem.

And not just because you're an icon: what you say makes sense.

So, I shall carry on. After all, what this script does is simply make easier the whole giving all those material zones some colour. The same script could be used for any shader-painting work.

Tried the script on my little Mac, and it promptly spat the dummy during the "tick the enable" effort: can't seem to find a file right next to it. I vaguely remember running into this issue in Linux... can't remember how I sorted it. The exact error reads:
ImportError: No module named 'make_shaders'

The offending line is 49 in the __init__.py:
from make_shaders.make_shaders import buildShader

The whole code in that region reads:

# 'borrowed' from Antonioya - elegant solution!

if "bpy" in locals():
    import imp

    imp.reload(figure_defs)
    imp.reload(make_shaders)
    print("make_shaders: Reloaded multifiles")
else:
    from . import figure_defs
    from . import make_shaders
    print("make_shaders: Imported multifiles")

""" thanks to batFINGER: the import bpy needs to come _after_ the 'if bpy in
    locals()', and for the import statements from modules """
from make_shaders.make_shaders import buildShader
from make_shaders.figure_defs import matZones
import csv
import sys
import os
import bpy

The file that generated this error actually lives in /Users/Moi/Library/Application Support/Blender 2.77/scripts/addons/psrFigureShader-master/ ... how awkward. In Linux, that file is installed to /home/Moi/.config/blender/2.77/scripts/addons/ ... i.e., locally, not somewhere hard to get to. One of the things I did really like about the Mac initially was its similarity to Linux. Well, here's one place Mac could learn from Linux.

Oh well, will need to rattle someone's cage over at BlenderArtists.org... they generally have a decent approach to nutting out issues like this.

 

[Robynsveil]

Oh, and feel free to have a look at the code - and have a chuckle while you're at it. My abilities with logical loops is, to put it gently, not particularly gifted. I enjoy coding, but lack a certain je-ne sais-quoi...

 

[Gadget Girl]

So this is not an area of python I know that well, but there is one thing that seems to be confusing me, and may be where you are off.

else:
    from . import figure_defs
    from . import make_shaders
    print("make_shaders: Imported multifiles")

I'm not sure how you can have

from .

doesn't there need to be some sort of variable/file name there instead of just the .? I assume you are trying to use the current directory as the place you are trying to import from. I know in the terminal on a mac, that would be a / not a .

So maybe that's the issue?

However, if you are trying to access the current directory, I think that's where python looks for stuff by default. I say, think, because importing files in this way is like I said one thing my python is still very shaky on. While searching for a "from . " syntax, I did stumble across this page which at least had some helpful theory behind how this works in python A Python Import Tutorial for Beginners | Codementor

But again I'm not 100% sure that's what you need, although since you are trying to get multiple environments to work (i.e. Mac, Linux) it may help.

 

[Robynsveil]

I'll have to admit, @Gadget Girl, that this particular code was not original to me: I borrowed it from Antonioya (and gave credit). It appears to work well for him: he's the chap who developed that brilliant Archimesh addon, as well as a lot of other stuff. Just browsing his github site, I see he made changes to his 1.1.1 version specifically to address issues in OSX. Might need to see what he did.

 

[Gadget Girl]

I'll have to admit, @Gadget Girl, that this particular code was not original to me: I borrowed it from Antonioya (and gave credit). It appears to work well for him: he's the chap who developed that brilliant Archimesh addon, as well as a lot of other stuff. Just browsing his github site, I see he made changes to his 1.1.1 version specifically to address issues in OSX. Might need to see what he did.

I borrow code all the time, so no worries there. If you remember where you got it from and can find the OS X fix, that will probably be the easiest. It's possible that's a perfectly valid notation, I've just never seen it, and couldn't find anything on it, although it's hard to convince the search engine that I really do want to include that lonely . in my search.

 

[eclark1894]

I borrow code all the time, so no worries there. If you remember where you got it from and can find the OS X fix, that will probably be the easiest. It's possible that's a perfectly valid notation, I've just never seen it, and couldn't find anything on it, although it's hard to convince the search engine that I really do want to include that lonely . in my search.

Couldn't you express that as from _._ import figure-defs ?

 

[Robynsveil]

Thank you for being interested in this, @Gadget Girl and @eclark1894 ! I'm currently nutting out taxes (here in Oz, with business extensions, they're due this month) so I'm buried in VBA, a vastly inferior language to Python, but I am pretty close to sending my data to the accountant and can then devote more energy to this little utility (like, later this week). I've haunted StackOverflow quite a bit over the years, and this notation doesn't appear to come up in their search thingie either. Something exclusive to Antonioya? In answer to your suggestion, @eclark1894, I will try it, as well as looking at the points you make, @Gadget Girl regarding paths.

I'm going to delve deeper into how to optimise the whole import thing ("import foo from bar" vs "from bar import foo") and see if that makes a difference. Also, noticed that my little path strategy isn't all that bulletproof: need something a bit more flexible, or else OS-specific? All these gophers popping up...

 

[Robynsveil]

Spent the day revisiting this script, particularly to do better error-handling, but also to discover the problem with that import statement. I was, as it turns out, barking up the wrong tree, as is far too often the case when I work in Python.

Not Python's fault: mine.

So, here's the deal: to write a multi-file addon, such as this is, you need to save it into a folder which, when you install from zip, gets copied (with all your files as contents) into the addons folder for your Blender installation.
When you have a multi-file addon, the main file is always called __init__.py. It was in this file the offending code resided, near all the import statements. But it wasn't that strange but wonderful "import . from" that was generating the error, it was this:

from make_shaders.make_shaders import buildShader
from make_shaders.figure_defs import matZones

So, in that list of files for this addon, there's a make_shaders.py file and a figure_def.py file, which originally were in a folder called make_shaders! In that bit of above code, then, the folder name is to the left of the full-stop (period) and the name of the file to the right. This is indeed an interesting ... um... catechism? construct? referencing method?

Anyway, that's been solved, finally. It's actually mildly annoying when you forget HOW things that worked before, worked, so when you make a little change, suddenly things go pear-shaped and you're struggling to nut it all out.

Again.

You can, of course, be assured that that wee bit of code is now copiously documented so that I know exactly what is going on with that. {{{{{sigh}}}}}

ETA: so, this now installs in Linux and Windows, but only works in Linux. My goal is to get it to install and work in Mac, Linux and Windows. Colour me obsessed...

 

[Robynsveil]

Okay, I've got it working in Windows and Linux. YAY! Just Mac left to go.

Then, the next bit is to actually make it useful. As in: allow choice of texture files within the panel, amount of specularity, etc. At this point, it is the roughest of scripts... but it does fulfil its original purpose well: take what usually amounted about a half-hour of work to the click of a button.

 

[Gadget Girl]

Glad you finally figured it out. This makes me want to learn more Blender stuff, only because I learned a bunch of Python just to use in Poser and it would be nice to have another program to mess with it in, to get a better grasp on it. When you get this script done, sounds like it will be very useful.

 

[Miss B]

@Robynsveil Congrats on getting it this far. I look forward to seeing the finished script.

@Gadget Girl I've wanted to learn Python for a while now, but the site/organization where I took all my web related programming courses, doesn't offer Python. Not sure why, unless no one who knows it wants to teach it there.

Where did you do most of your learning? There are (literally) tons of Python books, but most seem too advanced for what I want, which is basically the Python syntax.

 

[Gadget Girl]

There are (literally) tons of Python books, but most seem too advanced for what I want, which is basically the Python syntax.

So the question would be if you have basic programming experience, which it sounds like you do. Honestly, I never found any great learning sites for python that I liked, because they mostly had me doing stuff I don't care about. Honestly, although it's not free, I would recommend PhilC's PhilC Designs: Home | Product Info | Python for Poser. He has a starting chapter that goes through all the basic syntax for Python, before he goes into Poser specifics. Actually, it goes to page 34 of the PDF, so it's pretty inclusive. So if you already know what an If/Else statement is it should be pretty easy to follow and understand. He's got lots of examples both of just generic code, and code to do specific things in Poser, and I at least learn best if I'm interested in the code I'm writing.

Also, since I go back and forth between a few languages all the time, I'm always re-looking up syntax stuff, so I don't know if I ever feel like I really know it.

Don't know if that helps.

 

[Miss B]

Oh that does help, and yes, I have my degree in Computer Information Systems and Programming, so I started programming back in the early 90s with GW Basic (on my old DOS based computer) and then 2 1/2 years of COBOL before I even got to the web related programming languages, so yes, I have a good foundation as far as that goes.

I've actually seen Phil's Python for Poser on his site before, but it's always good to get a recommend from someone who's actually used it. Thanks.

 

[English Bob]

... I would recommend PhilC's PhilC Designs: Home | Product Info | Python for Poser.

I'd second that recommendation, for the same reason. All the Python learning sources I've seen have been concerned with generalised stuff that I don't want to do; probably fine if I wanted to carve out a career in Python programming but not very interesting given that I just want to hack a few Poser scripts to do odd jobs.

 

[Robynsveil]

I just want to hack a few Poser scripts to do odd jobs

Pretty much how this script started out, but as scripts do, it's sort-of grown into a lifeform of its own. At this point, it works, but only if all the stars align (meaning: pretty much only the very basic error-checking). I'm trying to create something a bit more evolved, but partly because I *don't* have much real programming experience, running around in circles not getting anywhere.
First to note: the script runs in a panel - very, very rudimentary, at this point. You can read more about what it does and how it does it here.
The errors I currently check are these: two files need to be copied from where-ever they were unzipped to, to the images folder (image_list.csv) and to the folder containing the .blend that the script is being run from (path_list.csv). Each needs to be edited before it is run. (I'm hoping to allow the info these files contain to be edited in the panel itself, but at this point, one can just open and edit the csv files in a plain-text editor.)
So I'm using the

try:
    do something here that might fail
except:
    do this if it fails

Issues with try - except is if there are any syntax or logic issues in the statement, it'll just fail and keep the reason for the failure its little secret. Also, I'm not sure I can nest a try: except: within another. I'll be fiddling with this for a bit, I think.

 

[Robynsveil]

I forgot to say what the errors were that the script currently catches: 1) is the path_list.csv in with the .blend and 2) is the path statement regarding the images folder correct in path_list.csv .OR. is the image_list.csv file in the folder containing the images. There are actually more possibilities than I actually trap for (or can appropriately identify) just with these files, and only after those monkeys are back in their cage can we address any file name issues in image_list.csv.
One other issue that I haven't come up with a satisfactory solution to is the matter of displaying errors. Whilst there are a lot of user-scripts out there, the user is still sent to the console to determine what went pear-shaped if things didn't go as they should have. You would think someone would have developed a better user-interface-feedlack thingie by now...

 

[Miss B]

I'd second that recommendation, for the same reason. All the Python learning sources I've seen have been concerned with generalised stuff that I don't want to do; probably fine if I wanted to carve out a career in Python programming but not very interesting given that I just want to hack a few Poser scripts to do odd jobs.

Thanks for your recommend as well. I picked it up yesterday, but haven't had a chance to go through it, but from what you and GG have said, it sounds like just what I'm looking for.

 

[Robynsveil]

I'll stop boring people with my musings on what can only be described as a laughable effort at writing code now. Here's my closing observation on this mess I made: I've learned not to place anything but the simplest statements in a try: except, and also to not just do a gatling-gun except, but to trap for a specific type of error... in this case, a missing file (or miss-spelt file, or file-name / image_list mismatch) equates to an IOError. Which I'm doing now, correctly.
Also, cross-platform work brings character-encoding issues to surface... so there's that.

Anyway, I'll keep you all posted when the script reaches a better usability status - I mean, it's usable now, but there's still a fair bit of error-managing to sort out to make the thing a bit friendlier.