Submit Your Poser Suggestions to Smith Micro

• From Poser Python Manual:

Get a list of vertex normals. Each normal is a vertex object.

Poser Python Vertex Objects do have a set methode.

``````nrmls = actor.Geometry().Normals()
nrmls[0].SetX(1.0)
nrmls[0].SetY(1.0)
nrmls[0].SetZ(1.0)
``````

• @ibr_remote Set Methode seems not to work for normales. Setting new values for normales does change the Python object, but re-reading the normal list returns the old values.
Set[X|Y|Z] works fine for vertices. Seems to be a bug.
Sorry.

• Just a tongue-in-cheek and probably redundant reminder to @ibr_remote and @adp that vertices in Poser can have exactly one normal, only. So single sided object like möbius strips and klein bottles can never have correct normals for all vertices. The best you can do is choose "Normals Forward" options whenever you see them, for such objects, unless you give them actual thickness.

There's another caveat regarding normals in Poser, too. If the normals are absent from the OBJ definition (as they may be), Poser will derive them from the winding order of facets (right-hand-rule: fingers follow winding order and thumb points along normal), so normals get inextricably linked with facets, which flows into Poser's Grouping Tool, which allows one to reverse the normals on a per facet basis (which poser does by inverting the winding order of chosen facets, preventing you from reversing a single vertex normal by itself. Poser also, confusingly, gives the word "welding" two different meanings: merging adjacent pairs of vertices within a threshold distance into a single vertex, and unifying the normals of a pair of "welded" vertices split between two adjacent body parts (which may have been derived from a single vertex in the OBJ geometry, but shared by two body parts).

• Not certain if requested already and explained why cannot have it, but here goes:

Add bloom filter for rendering stills and/or animation.

• Just an idea. Why not a "GoBlend"? Works like GoZ, only with Blender. Lots of Poser folk use Blender anyway.

• @masterstroke ABSOLUTELY!!! I would love to have such a link!

• You would think that something so simple, but essential would have already have been built into Poser by now, but How about adding a cloth naturalizer for both Cloth Physics and the Cloth Sims? Truth is, that a lot of Poser's setting can and should be automatic functions within the program. For the Hair room, the settings for Straight, curly, or even nappy hair should be built in. Press the button for the correct settings and then apply. Same thing for the Cloth Room and Bullet Physics. Denim, rubber, silk, nylon and satin should all have settings built in. No one says you can't still customize them, but they should have a common starting point.

• @masterstroke I remember others talking about this connection several years ago ... and the answer at the time was because of Blender's open source ... constant change made this practically impossible ... but I think there was a "stabilization" that might make this more possible now.

• @boni
Hi all.

Unfortunately, and YES =>I filed an enhancement report to SMS for a "GoBlender" a couple of years ago already.

See? Why not.

• There are lots (thousands) of exiting add-ons for Blender 2.79.
• Blender 2.8 is such a big internal change that each and every add-on has to be re-written or be doomed in history.

Same as for Miss Grey Blob from a competing company, SMS and Poser can not depend on other figures, softwares or companies.

Best regards all. Tony

• Miss Grey Blob

Is that really necessary?
You might not like that figure but there are plenty of people that do.

• I was reviewing my humanoid animation options for Poser-friendly content last evening. I tried manually creating dance sequences using key-frames and steps learned from Dance Rush Stardom arcade system. I realise that a lot of BVH-related software is about 10 years old, now, and quite a number of stand-alones have slowly gone the way of the dinosaurs. Existing plug-n-play BVHs don't really work with various humanoid rigs because the bones and bone-naming conventions vary. Also, not all plug-n-play BVHs work correctly, even if bone-naming is friendly to Poser convention bone rigs. I can't even talk about Daz Studio character rigs because they're like a user-facing black box. I would love to be able to drag joints and have the figure physically accurately moved, as in Design Doll posing, or MikuMikuDance, or Vroid, or Bot3DEditor. Granted these are for anime-style chracters, but the underlying concepts of humanoid figure animation surely can be developed for a Poser-friendly system.

• @eclark1849 I wish to have a Shadow Capture facility in Cycles Surface Nodes regime, just like the facility available in Blender3D Cycles, effective from Blender3D version 2.79. It can be used with the layers in the Material Room for shadow only effects on planes, similar to the function only available currently for Poser Surface Nodes.

• @ibr_remote I think the solution would be a full-blown Cycles render engine within Poser. Make it so it can be updated easily when Blender gets updated. That would solve so many issues with SF. Could still have FF and SF in there but those of us that dig the Cycles thing could do that.

• @ghostship But then you'll run into"Poserthink" people who believe everything in Poser has to be backward compatible. Frankly, I believe that Poser's belief in backwards compatibility is holding us back.

• @eclark1849 That's why I say leave in FF and Superfly. Backward compatibility while looking to the future. From what the devs have said so far about SF is that it can't be easily updated so, fine, leave it and add the full blown cycles and make it so dev maintenance is minimal to update.

• As much as I want so much to have some things that are available in Cycles for Poser - micromesh displacement, I'm STARING at you -, I don't think having a built-in port to send to Cycles would help vendors. We'd have to worry about compatibility with Firefly, Superfly AND Blender, and keeping in mind that most users stay in the comfortable zone of the program's basics (just look at how many people won't even use Superfly as it is, or won't touch dynamics), we could have a hard time trying to troubleshoot things with buyers not finding their way around Cycles.

Mind you, I'm not complaining about wanting to stay in the comfortable zone - wanting what's easy and sweet is perfectly valid. We can't all be tinkerers LOL

• @eclark1849 I absolutely agree with this, it's the reason Poser is lacking and falling behind so hard right now.

@eclark1849 That's why I say leave in FF and Superfly. Backward compatibility while looking to the future. From what the devs have said so far about SF is that it can't be easily updated so, fine, leave it and add the full blown cycles and make it so dev maintenance is minimal to update.

The problem with that is feature bloat, you end up having three render engines that require resources that SM probably doesn't have.

While I do agree that they need to fully integrate cycles proper, I don't think keeping the hybrid mish mosh mess they gave us with SF is needed. It should either be full cycles integration or get out of it completely and use IRAY/LUX/Octane or something else that will get constant updates and upgrades. Though from what I understand, SF is close enough to full Cycles that the transition between the two nodes systems shouldn't be too daunting and having to redo shaders for compatibility should be a small payoff for what's been developed for Cycles lately.

Right now, what we have with SF is an outdated hybrid rendering system that lacks many of the features people really want and ZERO support for current rendering hardware. Anyone who buys a modern computer or modern graphics card is screwed over because SF doesn't support Turing at all and it probably never will. That is extremely stupid, absolutely frustrating for those of us who are looking to upgrade and showed an incredible lack of future proofing on SM's part. The lack of any communication from SM is also something that's really pissing me off.

• I wonder how many are willing to pay higher prices for a yet 3rd render engine on vendor products.

I, for one, have no intention of adding yet another render engine to my products at the same price. Nor will I "go back and fix" all those Superfly textures for free.

Honestly, this is crazy talk. Vendors are losing our shirts now on product pricing and we're supposed to do all this at the same price point? I think not.

• I wonder how many are willing to pay higher prices for a yet 3rd render engine on vendor products.

I, for one, have no intention of adding yet another render engine to my products at the same price. Nor will I "go back and fix" all those Superfly textures for free.

Honestly, this is crazy talk. Vendors are losing our shirts now on product pricing and we're supposed to do all this at the same price point? I think not.

It's not crazy talk, SF is a dead end. If it were ever somehow updated, it would need to be cannibalized and redone anyway to avoid being stuck again.

And if Cycles was fully implemented there's a plethora of free cycles shaders/nodes that are better than many vendor supplied materials that can cover anything you think of. So you wouldn't have to "go back and fix" everything because the majority of SF users are already versed in Poser and know what they're doing. The people that don't are the ones that are still using FF and can't tell the difference between SF and FF in the first place.

• I have a mac and I use poser 11 pro which is supposedly 64 bit, but i got the future incompatibility message last night. so really worried about updating to the next OS.![alt text](!