Forum: Poser 11 / Poser Pro 11 OFFICIAL Technical


Subject: Having issues with GoZ integration with regards to SubD

JAG opened this issue on Nov 10, 2019 · 61 posts


caisson posted Tue, 26 November 2019 at 7:22 PM

JAG, I’m not accusing you of being misleading, but you raise several issues that you consider may be related. My position is that having more appreciation of what goes on inside Poser might explain why I see them as very separate things.

First, on DAZ. I believe you, I thought that was the deal back when they started the whole HD thing, and I don’t care. DAZ is a company that sells content and gives away the software to use it, so from a business POV it would make no sense to freely release a tool like that. Plus of course they have the right to do whatever they like with their software.

Poser has a different business model, selling the software rather than being dependant on content. (The sale to Rendo is still so new there has only been a very limited point release, so I’ll make my judgement based on SM ownership.) There would be no sense in adding GoZ, advertising it as a feature, and then crippling it.

This issue in Poser is a bug, which is what I care about.

Next, exporting the subD mesh and then import as a morph target. Several things to say here. First, Poser’s subD (to be more accurate, Pixar’s OpenSubDiv or OSD, as the algorithm that Poser is using is their tech) is stable if and only if the topology of the base mesh remains fixed. When OSD kicks in it creates a brand new mesh, and as Nerd says it gets re-evaluated many times. If the algorithm thinks that the topology has changed it will change the subD mesh it creates. It’s not stable in the sense that it is created once and that’s it, there is a lot more fluidity under the hood. Nerd says that if the mesh that OSD creates is baked it screws up the rigging, so that is not an option.

The other thing to be aware of is that Poser chops geometry into separate pieces internally depending on the groups; this is the way that Poser was designed to work from the first version some 20-odd years ago. That always carried through into exporting, resulting in different vertex counts between an exported figure and the original obj file. (As an aside, the way that the GoZ bridge works and the way that exporting geometry from Poser works are different. IIRC colorcurvature's PML stripped out a lot of figure info - groups particularly - on export and then rebuilt it on import which was why there was so much calculation going on; GoZ does something along those lines i.e. sending more limited data than obj export - I think.) That behaviour has been changed recently for the base mesh which is a big step forward, but there is obviously some reason why it doesn’t work for the subD mesh. Maybe it’s got something to with OSD, or maybe it’s the geo chopping thing, or maybe it’s something different.

I’m as sure I can be that it’s not the same as the bug being discussed in this thread though.

The really positive stuff is that this thread has, collectively, done more to identify and reproduce this bug with multi-resolution morphs in Poser than before. You cannot squish a bug unless you can see it. Nerd, aka Charles Taylor, is very much Poser dev team, so the right person is aware of it and I’m keeping my fingers crossed.

I want this bug fixed as multi-res morphs are important IMO and it would be good to see them working reliably for all users.

----------------------------------------

Not approved by Scarfolk Council. For more information please reread. Or visit my local shop.