With many thanks to jancory for testing, instructions are below for those who want to make their own update: 

Open the .py file in an editor (I use Notepad++) and:

- put brackets around the arguments of the print commands.

- in the includes at the top of the script change wx.lib.hyperlink to wx.lib.agw.hyperlink

- dlg.center no longer has a 'direction' keyword. For me it worked to leave that out, just call dlg.Center() without any arguments  (line 382)

- fileDialog styles now have 'FD_' prepended to their names. wx.OPEN has become wx.FD_OPEN, etc. (line 380)

- strings have become different beasts and they are to be handled differently in binary write. I have no idea why Phil resorted to file writing, but the SaveLinesToFile method works after a revision as detailed in the below:

def SaveLinesToFile(lines, filepath):

    fd = open(filepath, 'wb')
    s = "\n".join(lines)       #P13 Was: s=string.join(lines, '\n')
    fd.write(str.encode(s))    #P13 encoded string for binary write
    fd.close()  

And: Some of Phil's scripts tried to write to the folder where the script is, and of course if you put it in the 'old' location under ProgramFiles that will not work because file writing is now protected. 

I ran my version from an arbitrary folder and it worked. Best install under the 'new regime' of python files in library folders to prevent acces right errors.

Even if rights allow, the job of updating a script is difficult to plan or schedule. You do not know until you start whether the job is easy or tedious. A wide range of programming styles, was applied and some appear even obfuscated by design.

Then, it is not just the Python version. Also changes in OS environment and Poser organisation are to be catered for. Writing user data in the Program Files folder are a big NONO now. The capabilities of Poser have enhanced greatly over time and a lot of the hoops that had to be carefully jumped at the time are now not needed anymore, or the functions are provided natively in Poser.

No surprise there's little interest to do an update job.

It took a few simple steps to make it run under P13.

I am sure Phil would not have objected me uploading but I do not want today's inquisition on my back.

Drop me a sitemail when you're interested and i'll send you the instructions.  

Nevertrumper posted at 4:07 AM Sat, 27 January 2024 - #4480808

AI still has difficulties with hands. The model on the right has a left hand on her right arm. At least all hands are messed up.

Sometimes 3 legs. 

Artificial Ignorance 

ChromeStar posted at 4:46 PM Fri, 26 January 2024 - #4480802.

...

But mostly I wonder, are you going to get the same face consistently? A lot of the examples here are famous people, so maybe those, but I suspect if you feed it three different renders of the same character you are going to get three different characters out. That's limiting.

It could be there are tools to restrict to a particular face, but I have not found/mastered that yet. 

Warning: AI imagery! 

Following the original post of this thread I too played around a bit with Krea. Loads of fun! I took old renders and enhanced them, and made new with choice of figures and let Krea enhancer have a go on the result. Guess who's the stunning lass on the left!, outshining (spoiler ahead) her far far offspring on the right. 

Also ran into the limitations.  The material is too much trained on  'watch the birdie' photos.  As an illustration see the 'vanitas' image below. Left is original, Right is 'enhanced'. The prompt was: A woman with dark hair and blue eyes stares at a skull she holds in her right hand. I used 'stare' on purpose here to make the prompt stronger.
The changed direction of the eyes simply ruins the image.

Sometimes though the 'interpretation' Krea gives is refreshing. 

(Edit: Added nudity tag for the half nipple. You probably would not have noted it without the tag, LOL)

If I understand it correctly you want to merge the independent objects into one. Poser was never designed to do such operations. It was, and rightly so, considered that 3D programs like Blender are better suited for the task. Problem with those however is they come with a steep investment, if not financial then in learning effort. 

A quick route to merge props without resorting to 3D programs is to export your separate props to a .obj file. On reload you willt have all selected components in a single prop.

in a new scene.  

uv domain mapping (vertices and polygons) usually comes, in the .obj file as one set with the xyz domain mapping. Same holds for uv domain mapping.

There is, in Poser, currently no method to combine or swap out uv maps. If you have a separate mapping for the uv domain, but with consistent, or at least mapped, order of the polygons as in the xyz domain mapping you could write a small script to combine them, either in memory or in a .obj file. 

If you want to pursue this your main tool there would be the below method in the geometry type:

AddGeneralMesh(...)

Add a general mesh to existing geometry.  Arguments are numerical python arrays specifying polygons, sets, and vertices, as well as optionally texture-polygons, texture-sets, and texture-vertices.  (See Numerical Python documentation for more details).
<NoneType> AddGeneralMesh(<IntType nx2 Numeric.Array> polygons, <IntType nx1 Numeric.Array> sets, <FloatType nx3 Numeric.Array> vertices,
 {<IntType nx2 Numeric.Array> texPolygons, <IntType nx1 Numeric.Array> texSets, <FloatType nx3 Numeric.Array> texVertices})

polygons, sets and vertices can be obtained from the xyz  geometry using the proper methods. The optional input parameters texPolygons, texSets, texVertices would have to come from your custom uv definition. This could be a normal .obj based input. A polgon (facet) definition in a .obj requires vertex data. You can do with just 4 vertices repeated for every polygon.

The origin of the ball mesh geometry may not be in the center of the ball.

In fact, the two are totally unrelated.

Correction 2: The width of your screen was probably 746 pixels. Poser just uses the width. Cannot say about height.

Forget that last line for now. I just looked and it was not where I suspected it was. If I still have it it is dug somewhere very very deep.

Why is it not a representation of camera space?

You are using 4 points effectively located on the X0Y plane and a camera looking down the Z axis. 

Let's call the three elements in the tuple returned by the method as u, v, w.

The range you get for the u coordinates is: 630-116 = 514 for the camera position z = 2. Using the same methodology for the other example positions you find 258  for z=4 and 128 for z=8. Note the figures halve when distance doubles.

If you re-do the math for the v coordinates in the first example you find a v-range of 672-158 = 514. For the other camera positions you will also find the same ranges as you found for the u-coordinate.  You thus have the 4 points arranged in a square. 

If you look at the averages, you will find that the avarages of the ranges, representing the center of the square is consistently located at u = 373, v = 415. You do not report the film (image) surface when you did the test, could it be it was sized 746x 830 pixels?

Then for the w=output: The same scaling effect is used there: a point located twice the distance gives half the signal strength. Obviously any input very close to the camera xyz would be division by zero, return an infinite number, so something will be/should have been caught and buffered there. To get a physical meaning you can scale based on some test points, simple Pythagoras.

I must have a matrix based method laying around somewhere. Let me know if you are interested.      

I still would like to see a version of the Render Queue that runs on a minimal footprint (console?) Linux or a small GUI version like Peppermint. I have a 10 year old Core i7 system that is due to retire from active duty somewhere in the coming months. 

If the mud is off and OS is minimal size, it may still be useful as a mini farm.

Well, it IS a world to camera space. Just the z is scaled different from x and y. Plotted it will look like a height map. You may need to ban negative input and use log(z) for practical applications though.

DeeceyArt posted at 2:43 PM Wed, 27 December 2023 - #4479660

Ah yeah, I see. When generating texture sets in Substance Painter, the wear and tear effects are generated from the normal maps, or by comparing a high res mesh to a low res mesh.

In the latter, all of the detail is sculpted into the high res mesh and then the normal, cavity, and roughness maps are generated by the differences. It's the cavity maps that control where the wear and tear appears, but the cavity maps typically aren't distributed, they are only used internally by Substance Painter. The diffuse, roughness, and normal maps are used to create the final fabric, which will respond correctly to light positions.