Wait GGX is in the list twice?  ... Oh good grief. WHYYYY did Cycles feel the need to rename all the shading methods for Cycles 4.1

Just for clarity what changed was the default shading methods on some of the Cycles native nodes. The ones affecting EZSkin were the GlossBSDF and SubsurfaceScatterBSSDF. The change to Gloss will remain because it makes the default the same on WIndows and Mac. The change to SSS was unintended fallout. The default will be returned to it's original (Burley) in the next SR.

Again this is only the default values when the shaders are added to a material. This change won't affect existing scenes or library materials.

... Also are you rendering on networked computers or just the local computer.

One thing that would be really cool for those that knows enough the Material room to be more or less at ease: the possibility to set a node as global.
Which means that we could add not only a new node from the actual library, with fresh (default) values but one that is already setup anywhere in the currently opened Poser project.
Changing anything in a globally defined node reflects the change everywhere.
Trivial examples:

- a cloth that have quite a few parts (changing any parameters in one shot)
- the same multipart cloth: controlling the transparency to make it disappear in a video, while progressively replacing it by another one
- controlling PICK-based environments (texture, color, or whatever)
- many old characters are multi-parts, so that globally defined bitmap nodes could be used to update twins or triplets in one shot

AI absolutely has not been shut down for the future of Poser. We're looking at ways to give Poser users AI tools that align with Poser's core principals. That is making 3D art more accessible. I will not comment on any of the AI technologies we've investigated other to say that it's all vaporware at this point. There are AI tools that provide non-infringing results.We will not include any tool that just rips off other artists work, your work.

In fact Poser already includes an AI driven tool. The denoising feature of SuperFly is AI powered. https://www.openimagedenoise.org/ That's AI that doesn't infringe on anything. There's lots of other tools that can make Poser more Poser-like and not be systematic plagiarism.

This is probably the combination you're looking for. Uncheck Mip Maps. Then increase the texture resolution to the size of your largest texture map.

Mush:

Crispy:

Another possibility is the texture filtering in the material room.

Set the filtering to "Crisp" or "None". Setting to none can cause moires to appear in repetitive patterns. 

 Yes creating a morph and then adding dependencies to add on jaw rotations to the morph will work. If you need help setting up dependencies let me know.

Don't get too excited yet. It's still not right. There's a artifact in the shading. Look at the inside of the "o" that shadow is 0,0,0 black. It shouldn't be. This got past smoke testing and beta. We're still working on it.

If you plug a displacement map directly into the Physical Root that will give simple displacement. If you're using the Cycles Root. There will need to be a VectorDisplacement or (vanilla) Displacement between the image and the root input.

Yes it must be a morph. It has to be a targetGeom, not a valueParm or a rotation. ValueParm is a master dial that runs other morphs but isn't it's self a morph.

If you have the last update for P12 you have the new Rhubarb talk engine. P13 has had it for the last several builds.

Talk designer can only control morphs in the head of the figure. You will need a phoneme morph for each of the Rhubarb visemes. There are 8 required morphs.

First here's the support site for the engine that Poser uses. https://github.com/DanielSWolf/rhubarb-lip-sync

The way Rhubarb names the visemes is suuuuuuper confusing. The shapes are named A-H ... BUT  ... "A" is the Mouth P shape. So A is P. B is Th. C is A is Eee. Only when you get to D do you finally find mouthA. Confused yet? I know I was. Fortunately their website has pictures for each of the shapes.

Also Rhubarb is only 8 visemes so it's way easier to setup the morphs. You don't need the 20 plus required for the old system.

The heart of your map file will look something like this:

    <Rhubarb phoneme="A" morph="MouthP" />
    <Rhubarb phoneme="B" morph="MouthTH" />
    <Rhubarb phoneme="C" morph="MouthE" />
    <Rhubarb phoneme="D" morph="MouthA" />
    <Rhubarb phoneme="E" morph="MouthO" />
    <Rhubarb phoneme="F" morph="MouthU" />
    <Rhubarb phoneme="G" morph="MouthF" />
    <Rhubarb phoneme="H" morph="TongueL" />
    <Rhubarb phoneme="X" morph="" />

"X" is the no morph resting state.

You can save your sanity by just using these same morph names as lHomme2 and just copying his VisemeMap XML

P.S. I got so confused by the goofy naming when making LH2 I had to add comments to his XML file to preserve my sanity. I believe they are still in the release version.

There's not a problem having P12 and P13 on the same system. They can even run at the same time if your computer has the power to run both. Nothing has changed in P12 since the Talk Designer update earlier this year. P12 will not be receiving any further updates.

If you need P12 working. The first thing to try is clearing the Poser 12 Preferences.

This will completely remove your user preferences for Poser. You'll need to reconnect any linked runtimes you use.

• Make sure Poser is not running.
• Open a File Explorer window. [WIn] + E
• in the Location bar at the top of File Explorer type:
• %AppData%\Poser\
• Look for a folder inside the Poser folder named "12"
• Right click the 12 folder and Rename it to "12 Backup"

Restart Poser and see if this fixes it. If this works it's safe to delete the "12 Backup" folder.

The displacement as implemented in the physical node was behaving weird ... wrong ... uspidebackwards? It's really hard to explain. Let's go with "Busted". It was actually  using the vector displace which is (evidently) supposed to be weird. At least it's the same kind of weird in Blender's implementation of Cycles. It makes the displacement all go in one direction instead of along the surface normal. So it does something, but it's definitely not what Poser users are expecting. The vanilla Displacement node is what you're expecting displacement to do.

The Displacement input on the Physical node now has a Displacement node built into it so it should behave more sensibly. If you are working with the Cycles root you should Put a Displacement node inline between the Displacement texture map and the root input.

The big bug after the small bug fix ?!! I was really skeptical installing the latest update after the announcements that the cache will be removed and that it actually had the purpose to speed up render times not having to reload the textures every time.

The decision of removal sounded a little like " If you are not happy with what you get then we just remove it with the consequence of slower rendering reactions " 

In another thread it is also mentioned that the Cache does not work and textures need to be reloaded for every render test ! This sure can cause a heavy load.

That's correct they won't show up if the Figure's skinning is unimesh. I'm pretty sure that was a deliberate change. I's been like that since Poser Unimesh skinning was first introduced in Poser 11.

The IK goals showing for Poser Traditional skinning was a "bug" but when it was reported somebody <.< said, "Hey don't fix that, it's a useful bug!"

Interesting how Poser features so often grow out of useful bugs. :-)

@Blackbonner So the 3D Path thing. That was added by the "B" team at SM. After Smith Micro canned the entire graphics department they tried to develop Poser for a while using the cheapest coders they could find on earth. The 3D path was one of those. It was 99% useless as they implemented it. If you wanted to track something in a straight line it could work. Of course, you don't need a 3D path to do that. Just one of many things the "B" team did to Poser while SM was wringing cash out of the Graphics division to bail out the divisions that were bleeding red ink.

@Versum The texture cache is/was intended to keep textures in memory between renders. So it you re-rendered there was a pretty noticeable improvement in the pre-render times. The stuff that goes on before the progress bar even starts moving. But there's so may ways that was breaking stuff we removed the feature for now. It caused too much trouble in other places.