I just came in from the cold with regards to Poser Pro 11. Up until last week I was still using Poser Pro Game Dev 2014. I loved it. It no longer works now. I'll frown and move along.

In my previous and wonderful version of Poser, I could GoZ with no problems whatsoever. Click, morph tweak in Zbrush, click and my figure is back and morphed successfully. Of course you could only export the figure in zero sub/base resolution. Now Poser Pro 11 allows export to Zbrush with the higher resolutions and you can bake your morphs and this is great. I love that. But...

I use Genesis 3 in Poser. I never had any issues with her in PPGameDev2014 doing this. But now in PP11, I can get her into Zbrush one time and get an awesome morph accomplished at zero, 1, 2, or 3 subdivision levels and bake down the morph and save her. All is great. Wonderful. But if I try sending her to GoZ a subsequent time to tweak something or smooth something, when the morph comes back it goes wonky. Sometimes it's only a single polygon that shoots off into random positions and sometimes whole figures blow. Why does it work once but then never again? Also why is it every single time that I send a figure out, it renames it and makes it a new tool in Zbrush. Previous version did not do this.

I have tried GoZ with both bake and no-bake, materials and body parts. Doesn't matter. Higher poly settings are messed up after the first run. I once brought a morph back and named it the same as the first morph (which of course replaced the first morph) and that actually worked, but I've lost my original morph and so that's bunk. I've even had some of this happen using nothing but zero/base resolution setting. What the heck did they do here?

Any help or suggestions appreciated - but PLEASE READ MY ENTIRE POST before you post a reply. I don't mean to be a so-and-so here, but I hate when people suggest things I've already tried. It's redundant and a waste of everyone's time. So please read before replying. Thanks.

ADDENDUM: This same problem occurs with La Femme base figure in PP11 as well. I have noted that it occurs less when you export baked/material settings. It will not explode as badly. I got six separate morphs on the LF figure. I then saved the file as a Pz3 and reopened it. From that point forward the figure would not morph without exploding. So does it have something to do with saving the file as Pz3? I am suspicious now that the bake-down option is what's blowing it up. Meaning this is a serious bug and it affects any figure at all and not just DAZ figures. Again, is anyone else experiencing this? Bondware? It does no good to have a feature that is un-usable.Apparently the Pz3 save is also causing issues with the existing file. The figure will of course reopen perfectly in the shape it was saved, but attempts to morph it after that explode. The SubD is great if you guys can get it to work more than once. Any help or advice (or a bug fix) would be nice!

It is possible to change Game Dev into plain old PP 2014. The serial number controls the call home feature. (the instructions are in this forum, somewhere). This is only helpful if GoZ works with PP 2014.

I can also submit this as a bug to the Dev Crew, but submission does not guarantee a quick fix!

ADDENDUM 2: Upon further tinkering, I've realized that the subdivision in Poser does not accurately repeat itself. What does that mean? If a figure is set to zero and you export it from Poser with the correct options checked, you can re-import said object as a full body morph for your figure. If you set the figure to "1" on subdivision and attempt this however, the exported Object file will get an error saying "wrong number of vertices" if you try to re-import it as a morph target. Meaning Poser is apparently not import/exporting the figure in a stable fashion. One time it's got 1,000,000 polys...later it's 1,000,001 polys. The subdivision is not maintaining a stable polygon count. This, I think, could be the cause of the Zbrush issue as well. And if you can't morph outside of Poser, then the subdivision option is just about completely useless. Does anyone know if this is a known and reported bug? Anybody? I hear crickets chirping.

ADDENDUM 3: The file > export > Zbrush option - which allows you to supposedly save your entire scene or specific parts of your scene in a GoZ format just completely freaking crashes Poser altogether. I've tried this with every figure including LaFemme. No matter what the settings, it crashes just after asking for you to name the file. If that's not a bug I don't know what to call it. The export at Zbrush option does not work at all. I'm running Win7 Professional with a Geforce Nvidia card. Not sure that's really the problem, but I know somebody is going to ask as thought it is. This option was not in Poser Pro Game Dev, so I'm not sure on this new feature. It just doesn't work. Period. At least for me. The standard GoZ transfer bridge still works fine like in Game Dev, but the aforementioned issues are present. I have noted that at zero settings on subdivision, the figures seem to be more stable - so as I said previously, whatever is going on with the bridge is subD related. This export-Zbrush thing is just toast though...mostly burnt, dysfunctional toast.

Ya'know it just occurred to me that DAZ locked the GoZ feature up in Studio to prevent anyone from making HD morphs except for the in-house vendors. Is this what has been done now with Poser? Is the feature limited and the export intentionally locked like DAZ Studio to prevent this? As terrible as that might sound, it would certainly explain a lot about this new feature. Just wondering? Thoughts from anyone with Bondware????? Jenn? Nerd?

Not a limited feature, there's a bug biting you.

TL;DR

The GoZ feature isn't locked out for HD morphs. It was used to create the HD morph packs for LaFemme. But, yes there's a bug lurking in there someplace. I've had it blow up HD morphs. Save well save often and never overwrite the last save. Keep tormenting. The no-repeatability nature of subD is a design limitation of Pixar Sub Division. The sub divided mash is created on the fly and even the most minuscule change in the source geometry will change the winding order and/or vertex count in the SubD mesh. That's why there isn't a OBJ to HD mesh import. It just wouldn't work.

It's been my experience that If I do one morph at a time and save between each morph I can "usually" get through without issues. The problems seem to occur when you work with multiple morphs or repeat edit the same one. If you need to re-edit save and reload before reworking the morphs. And again always save the original in case it messes up and you don't notice it..

nerd posted at 5:09PM Mon, 11 November 2019 - #4369798

Not a limited feature, there's a bug biting you.

TL;DR

The GoZ feature isn't locked out for HD morphs. It was used to create the HD morph packs for LaFemme. But, yes there's a bug lurking in there someplace. I've had it blow up HD morphs. Save well save often and never overwrite the last save. Keep tormenting. The no-repeatability nature of subD is a design limitation of Pixar Sub Division. The sub divided mash is created on the fly and even the most minuscule change in the source geometry will change the winding order and/or vertex count in the SubD mesh. That's why there isn't a OBJ to HD mesh import. It just wouldn't work.

It's been my experience that If I do one morph at a time and save between each morph I can "usually" get through without issues. The problems seem to occur when you work with multiple morphs or repeat edit the same one. If you need to re-edit save and reload before reworking the morphs. And again always save the original in case it messes up and you don't notice it..

Thanks for the input on this one. I knew it was either a bug or something. I've tried the save and reopen and it actually makes my problem worse. Literally the only fix I get is to overwrite the name of the first morph. Now just on a side note, in Poser if you switch your Gen3+ figure back to original skinning where Poser's subD doesn't work and you turn on the DSON SubD Mesh resolution options for the figure you can go up as high as you want, and bridge back and forth to Zbrush with no problems whatsoever. So whatever format that DAZ is using for the subD works beautifully. The only problem of course is that Poser doesn't let you bake down anything not in Unimesh format. So you can ever save the HD details you create with the DAZ figures like that. But getting back and forth with no explosions is possible. I'm assuming they didn't use the Pixar format?

Is there a fix in the works here? I mean my gosh this is like the greatest thing since Poser got conforming clothing way-back-in-the-day! Had I realized this feature was there I would have paid for my upgrade to 11! Can you guys/gals work on getting this thing fixed? It's like a vault of gold that we can't open. You're tormenting me because I can see but not use it. Ha, ha.

DAZ intentionally locks out their HD to Zbrush bridge features to prevent outside creation of HD morphs. They told me that directly. I was worried you guys were following suit with it. Glad to hear you're not. It might actually give you a leg up on DAZ if you can get it working consistently. Another feature is that I can't seem to view in subD without it exporting in subD. So everytime I go out to Z, I have to go turn SubD completely off. Having an option to send SubD as part of the Goz popup might be a good change. That way you don't forget and screw it up or have to toggle back and forth. I pose and tweak constantly, so it's not usual for my figures to undergo tens of changes in one sitting. Consistent and simple exchange between Z and Poser is just essential.

Thanks for posting on this one. My appreciation!

The save-and-reload method seems to preserve the figure's integrity about 4 out of 5 times. But if you pose the figure any at all and attempt a bridge to Z and back - blam! Blow apart. It's just a morph-tastrophe. It did help though. As long as you stay in zero position, it's better, but after four rounds, the fifth time I did it, I still got a random poly shooting off her hip for no reason. Posing and morphing? First time every time - they blow up. Hoping there's a fix in the pipeline for this. I will throw money at you if you can get this to work. I'm not joking. I've dreamed for the better part of a decade of having a higher resolution figure to work with and this thing starts out fantastic only to blow up in your face back in poser. I want to cry. Seriously. It's that saddening.

Tried this with several figures now with and without subd but can't replicate it. Seems i'm one of those that have it working as it should. Even the baking down works. I really feel with you on this one. I would go crazy if my Goz didn't work as it supposed to.

ghostman posted at 12:36AM Fri, 15 November 2019 - #4370191

Tried this with several figures now with and without subd but can't replicate it. Seems i'm one of those that have it working as it should. Even the baking down works. I really feel with you on this one. I would go crazy if my Goz didn't work as it supposed to.

Thanks but it's already confirmed as a known bug. It doesn't occur on the first time. You must make a GoZ morph, then send the figure back subsequently multiple times for new morphs, applying them all additionally to the first ones. It's especially terrible if you're trying to tweak a posed figure. In other words if you just work with a zero posed figure and make one morph, you're good to go. Pose that figure and try to export it for a secondary morph to smooth and you're screwed - poly-plosion! Sometimes only one poly that you won't even notice till you render or reposition - other times whole figures blows. It does it with every figure I tried and apparently I'm not the only one. Are you replicating what I'm saying here or just doing one singular morph in Z and calling it a success? This is a compounded problem and not an initial one.

If you are replicating it precisely, and having no problems, please answer the following questions:

1. What version of Poser are you running?
2. What version of Zbrush are you running?
3. What figures are you trying?
4. What level of SubD are you exporting with?
5. What computer type are you running on?
6. What language version of Poser are you running? English? French?

Keep in mind that it gets worse with higher levels. You must have PREVIEW subD turned on and set to a higher level. Try 2 or 3 to start with. 1 seems less buggy. 0 will not affect anything since you're not subdividing obviously.

Keep in mind that not everyone have to have bugs with certain features just because some people have it.

1 Latest P11 2 Always the latest version 3 Miki 1, 2, 3. V4. La Femme. Terai Yuki. 4 Level from 0 to 3 5 Win 10 Pro 6 English

Been doing this for a while and used the Goz ever since it was introduced so i know what i do . I send the figures back and forth all the time when morphing without restarting or having crashes.

ghostman posted at 7:08PM Fri, 15 November 2019 - #4370290

Keep in mind that not everyone have to have bugs with certain features just because some people have it.

1 Latest P11 2 Always the latest version 3 Miki 1, 2, 3. V4. La Femme. Terai Yuki. 4 Level from 0 to 3 5 Win 10 Pro 6 English

Been doing this for a while and used the Goz ever since it was introduced so i know what i do . I send the figures back and forth all the time when morphing without restarting or having crashes.

I was using La Femme too and she blows out on morph 2+ just like everyone else. So you never, ever have a blowout? Very odd. As I noted, even Nerd admitted having issues and that it's a known matter. I'm going to message him with your information and let him know. If you've got 100% success, you might have the key to fixing the bug. Everyone else (other forums in other places) has this exact issue. So you may be the only one who it works for. Ha, ha.

Thanks, JAG

JAG, do you have by any change External Binaries on in General Preferences on? If so, see if it makes any difference if you turn it off.

wimvdb posted at 2:29PM Mon, 18 November 2019 - #4370429

JAG, do you have by any change External Binaries on in General Preferences on? If so, see if it makes any difference if you turn it off.

External binaries I believe refers to the saving of Pz3 files, so I'm not sure if it would have any affect, but I'll try it today and see. Thanks!

I consulted the manual on this one, and I was correct. The EBMT is directly related to the saving of figures and is required for morph sharing features. It's part of the runtime and external Pz3 format and involves the always ominous PMD file pal. I have not had time to check this yet. I will try it with it turned off and see what happens. If this does have any effect - it shouldn't. That is not to say it won't. Ha, ha. The issue seems to be with the GoZ bridge itself and how Poser is not maintaining the same connective data. I have also noticed anytime that you use the bridge, Poser delivers it to GoZ as a completely new figure. In previous versions (10) it always returns the figure as the same figure to Z so long as you were working with the same figure in an open version of Poser. In other words if you saved your figure and opened a new file and then went back to the original one, Poser would reassign a new name to it. But you could go back and forth forever with the same file open and it would always recognize and retain the same name. Now it just acts like it can't send it back and forth and I'm wondering if this is a result of Poser changing the darn poly data every time you send it out. If so, this could be corrected I believe on Poser's end. Z only has what Poser sends it. And if it constantly changes the poly count on the HD figure as Nerd insinuated, then Z would perceive it as a different figure each time it bridges out-bound. And that's what's happening basically. Again though, I'll try the binaries and see. Who knows. If it works you will officially win the internet for the day. ha, ha.

I think I'm right in saying that the version of OpenSubDiv Poser uses was updated from v2 in P10 to v3 in P11, plus I believe the boundary rule was changed as well. Might account for the change in behaviour between the two.

@nerd, would there be any possibility of freezing the mesh temporarily? Like a button in the Properties that when active would lock the resolution at whatever the Preview level was set to, and convert the OSD surface to actual geometry until switched off?

As promised I did try turning off the external binaries and as I suspected, it did absolutely nothing in regard to the issue with Z. Caisson, you're absolutely right that the subD changed between 10 and 11 versions. In 10 the subD was only a smoothing element, but apparently Smith tried to one-up DAZ by changing the subD with version 11 to actually create a higher resolution version of your base mesh. The problem is, they dropped the ball horribly. As mentioned, Poser is sending out corrupted info (somehow) each time you subsequently bridge the figure to Z. The first time you're fine...bridge and attempt to add a second morph and polys start 'plod'in! The more times you cross over the more it explodes until the figure is garbage. DAZ studio does not have this issue. The SubD range is limited, but 1, 2, 3, 4 and so on, always, always go back and forth with identical data to Z and back. This exploding poly issue is just ridiculous. Basically at this point the one really awesome improvement between 10 and 11 doesn't work and is basically good for nothing more than smoothing a base figure - same as 10. I've really just about given up on it at this point. It's broken and it's not going to ever work without a bug fix. As for your question to Nerd, the button you're hypothetically talking about is the preview/render sliders. Whatever it is set to is supposed to be locking the geometry at that level and freezing it. When it goes to Z it is solid geometry just like a DAZ figure. It's just getting messed up upon return. The figure can be exported as an OBJ from Z without any issue and it's smooth and correct, but send it back to Poser and it's messed up. You also can't get it back into Poser as an Object morph target. This means the figure bridging outbound to Z is not identical to what Poser has in the viewport and as a result, is causing a corruption of the geometry when it comes back I think. Essentially the problem is Poser, not Z.

@JAG - nope, I think Nerd is saying that as OSD calculates on the fly the geometry is not locked, so OSD looks at it on each import from GoZ and if it determines that the topology has changed it will calculate a new mesh surface which could screw up the morph.

I've done some testing this evening; the most repeatable is this one. I took AndyP11 into ZB at subD 1 via GoZ and wrote Hello World on his chest using the Clay Buildup brush, then returned to Poser via GoZ and applied the morph at 1. Then I exported the mesh from ZB as an OBJ, imported that to Poser. Using Front Camera I switched visibility between them and took a screenshot of each to check and everything appears to line up ok. Repeated the process with the first morph active and ran the Clay Buildup brush over the lettering again to make a more extreme morph, also exported the obj from ZB. This time there were clear differences in the vertex positions between the second GoZ morph and the OBJ export - not enough to blow up the mesh on this occasion, but those differences would accumulate quickly.

Could be something to do with Poser. Could be something to do with the GoZ bridge. Could be something to do with OSD. I did find an interesting thing in the docs - scroll down to the end of Subdivision Compatibility and there is this - "The improved accuracy of OpenSubdiv 3.0 can reach a magnitude that will not go undetected. Whether or not this can lead to visual artifacts is unclear." No idea if it's relevant :D

There is a bug report in GIT (no. 316); I've added my findings to it.

@Ghostman - do you use Clay Buildup to create morphs with? are there any non-obvious things to avoid in ZB for making Poser morphs? I'm wondering about workflow too.

PS. This is a screenshot of the obj and morphed mesh for Andy; they should be an exact match ...

Caisson:

That poly slide effect is exactly what's happening...it's like the polys get misaligned some how. You can actually re-position them in Zbrush to fix them, but of course upon return, you get all new ones blowing apart. So yep, you're right I think this is definitely what's happening. It's not like it's adding or subtracting polys - just instead it's moving them around with some shooting off into the wild blue. The higher resolution you set the figure to, the more blast you get. The base figure works perfectly without any trouble, but when you apply the HD/subD, that's when the glitch kicks in. So I will guess Z is not what's misaligning. I've also exported the figures out of Z in OBJ format and found no crazy polys - what you see is what you get - so the explosion is happening during the return to Poser. I will note that if you have DSON installed and are using DAZ figures with their version of SubD mesh resolution applied, while you cannot bake the morphs, you can up the resolution and bridge the figure to Zbrush. Of course you end up with two distinct versions of the figure - one low and one high resolution which can be annoying, but you can morph all day long and send it back to Poser with absolutely no exploding geometry effect. So it's not Z I'm quite certain. It's Poser and the new subD system in version 11+. It it were Z then I would think the DSON figures would be misaligning as well and they don't. Only when you rely on Poser's subD feature does it screw up. You know I've tried import/export features to get around the GoZ bridge to create a morph target for the figures and I can't get Poser to create FBM in this manner. I can line up the polys just like you did and it still doesn't seem to like the HD. I can do it all day long with the base figure. But switch to HD levels and it won't work. This is a similar issue with DAZstudio. But in their case they blocked it intentionally to prevent creation of HD morphs that were redistributable (since they charge $40 a piece for such items.) I had one of their vendor management people admit this to me and tell me that only the vendors got the key/bridge to make HD morphs in studio. This was one reason I just assumed Smith/Bondware might be doing this intentionally but Nerd says no. So I'm bewildered that a bug this giant exists and all we get is a note that it might cause problems - good luck! If DAZ can subD and it works (and in Poser no less) then what is the problem with fixing this? I don't know. I'm just so darn frustrated with it at this point. This would be the coolest thing since apple pie if it just worked. I would pay for an upgrade or bug fix just to get this done. That's how much I want it working. If we could create reliably and without issue, HD morphs for any figure and bake them down and save them ---- man...I'd jump for joy. And it's here...it just doesn't work. I'm with you on the OSD - but why would you ever use a system that doesn't lock? Unless it's intentional? Knowing that it doesn't lock seems to indicate to me that it's obviously going to have repetition issues. It just makes no sense. My other question is why does it lock or match on the first morph but gets off on the next? If it can match/lock once, what's going on in subsequent passes? This is by far the strangest glitch I've encountered in 20 years of using Poser. (Yeah, I'm that old...)

Thanks for the testing and input. Any ideas on how to work around this? Perhaps a import/export morph target? Maybe I'm just not doing it right. If you have any suggestions, I'm all ears and most appreciative.

JAG

The point with OSD is that the speed, mesh compatibility and accuracy improved a lot from version 2 to version 3. Poser was updated to the new v3, and had the boundary rule change, because it gives better results with meshes that have not been designed for subD, including all the legacy content. The problem with morphing at higher resolutions seems to be an unintended side effect. The topology that OSD generates is the same as long as the base topology is fixed, so I would guess that there must be a point when morphing a mesh using GoZ where it decides that the topology has changed, and it would seem that OSD v3 is more sensitive than v2. I am guessing though, I will check on the GIT report in a few days and see if it has gone to the dev team.

Right now I would say that workflow is the most important thing as I don't believe that this is something that only affects some installations - I'm hoping Ghostman might chip in with advice/info.

I will try to spend some time to spend on this over the next few days.

Speaking from a point of extreme ignorance, if the model coming back into Poser was invalid (eg vertex count) would not we get a "import prop" prompt? I've always assumed a morph is a series of deltas applied to the base mesh rather than an actual mesh in the scene, if this is the case are we talking about the calculations of these deltas going wrong? I've not been able to reproduce the error to test this idea but have only been using basic disp brushes like snake hook, will try with brushes mentioned above.

ironsoul posted at 7:39PM Thu, 21 November 2019 - #4370848

Speaking from a point of extreme ignorance, if the model coming back into Poser was invalid (eg vertex count) would not we get a "import prop" prompt? I've always assumed a morph is a series of deltas applied to the base mesh rather than an actual mesh in the scene, if this is the case are we talking about the calculations of these deltas going wrong? I've not been able to reproduce the error to test this idea but have only been using basic disp brushes like snake hook, will try with brushes mentioned above.

Ironsoul,

It doesn't matter what z-brush you use from my end - it always jacks it up after the first morph. I think you're right though if the vertexes did not match, it would give the import notice. For instance if you take your base figure (0 resolution) in Z and up the poly count in Z, then delete the lower levels and try to go back to Poser, you've changed the poly count / vertex data and you'll get that import prop notice. So you're absolutely right on that. So the vertex remains the same as would the poly count. You get your morph on the figure but random polys get out of alignment and shoot off away from the figure (like an explosion). But aside from the random polys that blow away from the figure, the Z morph will appear. So again, you're absolutely right about this. Damn good point! I had not really thought about that. So the vertex count isn't changing. The location data for each vertex must be getting skewed? So Poser isn't reading the return data correctly? Well I was right then...it's Poser. If Z were shooting those polys off, the exported OBJ from Z would display the same explosive effect but if you export it, it does not. The exported OBJ looks just like the figure does in Zbrush. We only get skewed poly locations once it's handed off to Poser to apply to the original figure. And for some reason it only does it after subsequent morphs. I've noticed I can create MORPH 1 and apply it with no problem. If I send the figure out with MORPH 1 applied to Z again, it comes back blowing up. If I turn MORPH 1 off and send again to Z, most of the time when I come back, the new MORPH 2 will not explode. But when you pose and tweak, you have to build each morph atop the other. I don't really know how the topology gets skewed if it works once. It's weird. But thanks for putting this up...it makes sense and good thinking! Much appreciated!

caisson posted at 7:46PM Thu, 21 November 2019 - #4370814

The point with OSD is that the speed, mesh compatibility and accuracy improved a lot from version 2 to version 3. Poser was updated to the new v3, and had the boundary rule change, because it gives better results with meshes that have not been designed for subD, including all the legacy content. The problem with morphing at higher resolutions seems to be an unintended side effect. The topology that OSD generates is the same as long as the base topology is fixed, so I would guess that there must be a point when morphing a mesh using GoZ where it decides that the topology has changed, and it would seem that OSD v3 is more sensitive than v2. I am guessing though, I will check on the GIT report in a few days and see if it has gone to the dev team.

Right now I would say that workflow is the most important thing as I don't believe that this is something that only affects some installations - I'm hoping Ghostman might chip in with advice/info.

I will try to spend some time to spend on this over the next few days.

Thank you and please keep us in the loop here on the post about any developments. Also please read Ironsoul's point posted today. Ironsoul makes a good and relevant point I think.

So if I understand the issue - (and there's a good chance I do not) - a 3D model is essentially a collection of data coordinates for specific vertex points in three dimensional space. So when Poser sends my figure to Zbrush, it is sending it a long series of vertex positions/coordinates (sort of like connect-the-dots) from which Zbrush then maps out and reassembles my model. I can then morph it (move the vertexes around) and send a new series of coordinates back to Poser for Poser to reassemble in the exact same fashion. The new coordinate locations now represent a morph target or new set of locations for the existing vertexes in my model. If the vertex count is not identical, Poser cannot create a morph target and will import the wrong-vertex data as an object file only.

Straight out of the Poser manual, page 810, it says that the order of the vertex coordinates must match or the of course Poser can't replicate the model form properly and so when we import a FBM from an external source in Poser, we have an option called ATTEMPT VERTEX ORDER CORRECTION in case our external source didn't quite arrange the points in the right order.

So is it possible, that Poser is not realigning the vertex information correctly when receiving it from Zbrush? As Caisson pointed out, there is a tiny bit of misalignment with the incoming data and it can and certainly does get worse with subsequent iterations on the same misalignment. So this is why one morph doesn't explode as badly as a second or third additional morph does. The more we morph the HD figure, the further out of alignment the polys/vertexes get. Zbrush doesn't misalign or get the vertexes out of order on it's own. Poser 10 can go and come without the slightest issue. A zero-subD figure can go and come without problems in Poser 11. Only with the HD applied in Poser 11 are we getting a problem. So then Poser 11 is simply not reading or aligning the points correctly when receiving the new coordinates from Zbrush. We know from Ironsoul's point that if the vertex and polygon counts were getting off then Poser couldn't form a morph target at all and would only import the data as an OBJECT file. So there's no changing vertex or polycount here at all. This is a simple arrangement issue. Poser sends Coordinates A out to Zbrush and when Z sends it back, Poser isn't aligning it properly. It's not the GoZ app, as it works fine with Poser 10 and with base resolution figures in Poser 11. So the issue comes with the HD option. Poser is not able to realign vertex data from its own HD alterations.

So this is the problem I think. Anyone agree or disagree? Any ideas on solutions here? Do we need a realignment option applied for GoZ bridge like we do with FBM import? Could this be all that's wrong?

Maybe I've over-simplified the problem, but sometimes breaking it down to stupid-simple makes finding a solution...simpler.

Having re-read my own post, I should clarify that Zbrush is not getting the vertexes out of order. It sort of sounded like I might have been insinuating that. My suggestion on the alignment option for the GoZ bridge was only meant as analogy. The problem remains with the vertexes not going to the correct points in 3D space. Poser isn't reading it's own model's returning coordinates correctly. So it's not that the vertex that is messed up is in the wrong order - it's just not in the spatial location it is supposed to be in. In other words, if vertex number #24521 is supposed to be at X=5 Y=3 Z=12, for some reason it's being randomly put at X=5 Y=5 Z=50 and thus shooting off where it's not supposed to be. The re-position starts out being slight but then jumps dramatically with subsequent iterations of the transfer back and forth to Z. Ironically if you send the exploded model back to Z, Z will replicate it perfectly meaning the data isn't getting off going to Z but during the return. But since Z can export a perfect OBJ version of the figure, it's not Z's data that is wrong, but Poser's reading of it. Why the error is random, I don't know. Generally would call that a "bug" or "glitch" I guess. Why vertex #24521 shoots off to the wrong spot while the next 5000 vertexes do not is just weird.

Just wanted to clarify that argument since I mentioned the vertex order correction option. I was just referencing it, not directly saying the vertexes are getting out of order, though I suppose it's possible that Poser is assigning the wrong data to the wrong poly - but we're not talking about a shift of a position but rather a completely wrong location. In other words, Vertex A isn't moving to Vertex Z's position. Vertex A (being the misaligned one) is shooting out to an wild point is 3D space. And it's not always Vertex A that goes haywire. It's random.

I need aspirin.

I was thinking we could use the python api to do before and after comparison and get some insight at a vertex level but my version of poser decided to phone home last night so no way to take that further at the moment. What would be useful is to understand when a subdiv occurs. I understand Nerds comment about repeatability being a problem, assume this becomes important at higher divs otherwise HD morphs would be unreliable. I always thought the sudiv only occurred when the preview slider was changed or when rendering, if that's the case the subdiv mesh would not be changed by by a Goz - that doesn't seem to be the case reading above. One additional thought how does poser handle vertex welds? If its by proximity or some other on the fly method could this getting broken - just trying to think why an extra vertex would appear.

The subD is happening "in the pipe" The base mash is always being processed before it renders, even in preview. If the mesh gets baked at any point it actually changes the behavior of the mesh in joints. And not in a good way.

Vertexes are welded in the base before the subD. That shouldn't be affected.

That comparison mesh is a little disturbing. The only thing I can think of that makes even a grain of sense is the inherent inaccuracy of floating point operations. And that may explain the exploding mesh too. The inaccuracy adds up and at some point cause the resultant mesh to be malformed in someway. Perhaps 2 vertexes converge.

That also makes it really hard to reproduce but if it is actually the cause increasing the precision of that calculation may help. Basically add a couple of relevant digits to the math like was done to all the posing in 11 to combat "left side asymmetry" in figures.

P.S. Exploding HD Morphs isn't exclusive to GoZ. It can happen with the built in morphing tools too. I'm hoping they are the same bug manifesting differently.

nerd posted at 4:52PM Fri, 22 November 2019 - #4370992

P.S. Exploding HD Morphs isn't exclusive to GoZ. It can happen with the built in morphing tools too. I'm hoping they are the same bug manifesting differently.

Nerd, Thanks for commenting again on this topic. Ghostman contacted me today and noted that on his/her system, DSON is not installed. I do have DSON installed on my system. This is one of the odd items that would make a difference between the two setups. Ghostman has no issues. I do. Could the DSON plugin be causing issues? Keep in mind the SubD for DAZ figures (Gen3 and 8) still works in Poser. In fact, you can convert a clothing in Studio that's from Poser and resave it and take it back to Poser and it will have SubD options (mesh size) in the parameters. So as Ghostman points out, DSON is a long shot but it does have something to do with SubD. Wanted to mention that. If anyone else is NOT HAVING THE EXPLODING ISSUE...and you don't have DSON installed - definitely please sound out here in the board and let us know. Sometimes plugins fight each other and if DSON is our culprit, it will certainly help to know.

Just to clarify, we're not getting "extra" vertexes. The vertex(es) that explode come from a specific place on the mesh. You can literally move these points back to the proper location in zbrush. Of course when you send it back, all new ones explode so it's redundant. But the point being; it's not adding meshes - it's just randomly shifting the vertex point's location for some reason. And it will do it without repetition. In other words, you can use the same figure, send it to Z, tap out a little morph and send it back. Boom, exploding vertexes. Turn off the new morph and send it back in the same form it was originally and repeat the exact same morph and send it back and completely different vertexes will shoot out. (I repeat the morph by simply renaming the Zbrush tool in Zbrush to match the second export). So it's totally random.

As Nerd pointed out, the movement of vertexes is real and odd. If anyone has any input, don't be embarrassed to shout out. Thanks for everyone's input so far.

I think the exploding mesh might be due to the original mesh being to low poly in the region you are trying to morph. I've been noticing this with Tweety's Low Polygon girl. Trying to add some morphs with her subdivided and using the morph brush. When I see an explosion I dial back down the sub-d and see there isn't really enough vertice points on the original mesh in the area and the brush is trying to grab different points.

@Nerd @Ghostman

I updated issue #316 in GIT with comparison GIF's, scene file and my step by step to reproduce. Could you see if you can get the same results?

@Nerd - thanks for the clarifcation. Regarding floating point precision, all code is now fully 64bit? Old 32bit code will have the wrong stack width so I'd expect the effect to be more catastrophic but just a thought.

bwldrd posted at 2:54PM Sat, 23 November 2019 - #4371038

I think the exploding mesh might be due to the original mesh being to low poly in the region you are trying to morph. I've been noticing this with Tweety's Low Polygon girl. Trying to add some morphs with her subdivided and using the morph brush. When I see an explosion I dial back down the sub-d and see there isn't really enough vertice points on the original mesh in the area and the brush is trying to grab different points.

That really shouldn't be an issue. I've been working with using Gen3 and Victoria 4 in Zbrush using the GoZ bridge for years now and you can up their count inside Zbrush however high you want and Z will always send it back fine. Of course it's Z calculating the level transition. The other problem I see with that idea is that Poser is making an actual higher definition version of your figure now in version 11 (not just a render effect but you can actually export the high-poly form) - so the vertex number on the figure morphed in Z remains the same on the figure back in Poser. Now if you made your morph on a version of the figure set to subD=3 and then you pull the lever down to =2 then Poser might do what you're saying as you no longer have the same number of polys/vertexes. But that's not what we're talking about. If I send it out to Z at 3 and bring it back, it's blowing up at 3. No vertex change.

Sorry. thanks for the idea on that but I don't think that's relevant to what's going on. I appreciate the input however. If you think of anything else, don't hesitate to post it. The only dumb idea is the one never mentioned.

The following steps reliably produce an exploding morph when I try them. I'm using 11.2 and ZB 2019. Fresh 11.2 install, no DSON.

1. Load La Femme and changed preview sub-div to 3.
2. Loaded pose Poser 11 Content->Univeral Poses->Action>Comic Book->Hero Action 1
3. Goz to ZB (Bake Morph + Material options selected)
4. Select the Inflat brush (Intensity 48, draw size 8)
5. Rotate view so viewing the back of the figure. Draw a continuous line from the back of the head, down the neck, to the left shoulder and down to the left heel.
6. Goz back to Poser and create new morph M1
7. Changed morph to 1
   I can normally see a vertex out of alignment at this point but may be necessary to repeat.

FYI As an experiement I used the Poser copy morph command to copy an exploding morph onto a new La Femme figure (not subject to Goz process) and that also had the explode problem but to a much lesser effect.

This issue seems to be repeatable when the same vertices are morphed more than once, so Nerd's observation that lack of precision in Poser's math could cause errors to accumulate until the morph fails would make sense.

This is the box primitive with Preview subD at level 2, GoZ to create a morph twice. Where the same vertices have been morphed there are some major differences in the vertex positions on the second morph in Poser compared to Zbrush.

Thanks for the additional input everyone! We've got moving vertex points for sure. I'd expect that if Poser were dropping down from subD to base or lower subD levels. So like if the morph is made at SubD=3 and I reduce the model figure to 2...I'd expect Poser to have trouble compensating for where to put a vertex. Taking away vertexes (polys) would create this very exact problem if the program doesn't know how to correct for it - but when we're staying on the exact same subdivision level it really shouldn't be happening at all. The movement is just a problem that grows more serious as you work. It's killing those of us who use Zbrush repeatedly during our work-flow. We're all having to go back to PP2014 in order to use Z without problem. That or you have to turn your subD off every time you use the bridge. And the turn it back on coming back. If they fix one thing between 11.2 and 11.3 I hope this is it. Can you imagine using this if it worked? I would giggle aloud if I could just up the rez on a figure and keep my morphs. Here's hoping the bigwigs are paying attention to this post and our reports.

Well as Ironsoul proved, it's not the DSON plugin that is causing any issue, but now I'm looking at something between 11.1 and 11.2 - not yet verified, but if it's a version difference it might explain why some folks using "11" don't seem to have this issue and others do. I'm going to take a look at the "update/fixes" list between 11.1 and 11.2 again and see if I might note anything they tweaked that might have thrown a wrench into the mix. If anyone else has any thoughts, please hit us with them.

Curiously another point I would like to bring up that relates to this matter:

If I export in OBJ format, a base figure from Poser 11.2, I can then re-import the model as an FBM full morph target for that base figure with no problem. However, if I up the figure to a higher SubD level and repeat, Poser always tells me the vertexes do not match when I try to re-import as a morph target. The same happens if you try to swing a figure from Zbrush around as an OBJ (not going through GoZ) to Poser. Yet from a physical (pseudo) standpoint, if the version of the figure in Zbrush (having gotten there via the GoZ bridge) does not match the vertexes with the original figure in Poser, then a successful return morph via the GoZ bridge would not be possible. But yet it is. Mind you our vertexes are strangely moving around obviously but the point is, the vertex count has to match or it won't work. Now I mention this because this is the exact same thing in DAZ Studio. And while I know it's been somewhat officially denied, DAZ for a fact, intentionally sabotages their own HD import/export options to prevent outsiders from being able to make HD morphs for their Gen3-8 figures. They have some sort of key-plugin for their vendors which allows them to get successful morphs. I have an email from the vendor manager that states it to me quite plainly in addition to telling me I could only get the key for myself if I was approved as a vendor and signed an agreement of some nature regarding it. And so our glitch here just seems to me to be very, very coincidentally similar to what DAZ did/does. You can HD morph somewhat, but any ability to save or preserve the HD version doesn't work even when it physically should. It could just be coincidence, but it's one helluva one if it is. I'm waiting for responses on the people with 11.1 to verify whether the issue occurred with the previous version. What we know at this point:

1. It's not the figure you use.
2. It's not the GoZ bridge.
3. It's not Zbrush.
4. It's not the DSON plugin.
5. It only affects figures that have been subdivided using Poser's SubD. (Figures subdivided using DAZ mesh features do not do it even in PP11.2)
6. We can't even export the SubD figure and make our own morph target using Poser.
7. Attempts to copy (figure to figure) in Poser, a previously made SubD morph are not working well and have glitches.

This is starting to form a bit of a pattern to me. If you have 11.0 or 11.1 and it's still functioning, please test the GoZ with subD for us and let us know if you have this glitch. I think this information might be the final piece to the problem.

Thanks to everyone!

The DAZ Studio thing is a total red herring. Sorry, but it is.

I'll state the issue I'm seeing as clearly as I can: if you repeatedly morph the same vertices of any mesh with at least one level of subdivision in a single session they will begin to show errors in their positions which will rapidly cause the morph to fail.

I have tried saving the scene file, then closing and reopening both Poser and Zbrush, loading the scene and repeating the same morph as in the examples I've posted, and it seems to work, the vertices behave as they should.

So this can be worked around - and I believe it is different workflows that explain why some users aren't getting this problem.

@JAG - Poser breaks grouped meshes into pieces internally as part of the rigging process (binding or skinning) - this has been the case since Poser 1.0. It means that before the GoZ bridge you would have to use the original obj file to make morph targets, and reverse deformations were not possible. (Well, colorcurvature did write PML in 2012 to address that lack.) Anyway, point being that exported obj files from Poser always used to have different vertex counts from the original obj, and the fact that it appears that base res exports can be now be used as morph targets is impressive. I am completely unsurprised that subD mesh exports fail though, for the reasons given, and it doesn't seem possible to create morph targets from posed figures, so reverse deformations still need GoZ. So I'm saying I would expect the GoZ mesh transfer of a subD mesh and the obj export of that mesh to have different vertex counts.

No conspiracy required ;)

Caisson,

I think I disagree about the DAZ point. The similarity of issues is very...odd...for lack of a more accurate term. I'm not wearing a tinfoil hat. I've not insinuated a conspiracy of any nature. For several years DAZ ignored requests for assistance on the inability to GoZ a Gen3/8 figure at HD levels back and forth to Studio. I was one of the ones being ignored or simply told I had a software/hardware issue with regard to it. Then one warm and sunny afternoon I got to talk with an actual DAZ vendor who created HD morphs for DAZ and he let it slip that they had a means to do it. I posed the question outright in the forum over there and while DAZ immediately pulled my post down, another member messaged me and told me the whole scoop on the special vendors-only bridge they had. I posed as a vendor and after a few back-and-forths the DAZ vendor rep I was talking with admitted not only that said special bridge existed but that they had it blocked for other users specifically so they could control figure morphs and protect the copyright on their figures. (AKA, we don't want anybody but us selling HD morphs.) That's not a conspiracy. I have emails from them stating it. Email them yourself and ask. So bringing up a known business tactic in regards to this issue is not a red herring - it's a legitimate concern and question. In fact the only similar situation like this is the DAZ matter. Things have remained professional in this thread thus far and I'd like to keep it that way. Please refrain from accusing me "misleading" (via reference to herrings) and conspiracies. I've done neither.

There is no work-around. Closing Poser and Zbrush does not fix the problem for me. And even if it did work, the question would be why? And what kind of a work-flow requires me to shut down both programs continually every time I want to tweak a figure? I did try it though and it did not work. The figure reopens with the the original first morph fine (as previously mentioned) but any subsequent attempt blows up.

The problem I'm really stuck on is why can't I simply export the HD figure's subdivided geometry out of Poser, and re-import it as an FBM? I can do that at base resolution. I cannot with anything 1 or higher on SubD? If poser can save the one morph at high resolution and bake it and reopen the figure later with that one morph intact, then it's working correctly. If it works once, why not twice? In other words, the point I'm making here is that bugs and glitches don't usually know how to count. If Poser's HD is stable and producing solid geometry then why won't it re-import its own OBJ as an FBM? I keep going around in circles and finding myself realizing just more and more how exactly this problem seems to be in relation to the DAZ limitations. Maybe I'm crazy. Maybe this bug is making me crazy. Maybe Bondware will fix it just so I'll shut up. Ha, ha.

Anyway thank you for the continued input and assistance. The work-around however does not seem to work for me though.

If this issue is being looked at by Bondware, could they please implement it at the obj level so that those of us that use Blender et al rather than ZBrush could also take advantage of HD Morphs, that would be great, a GoB would also be appreciated although I am quite happy to just use export / morph import.

TBH I'm surprised that even GoZ works with a posed figure rather than zeroed, I have colorcurvature's script (which is excellent BTW) but that has to do a lot of pre / post calculation to import a "posed" morph (although if we can now export a full figure and import an FBM that might be easier going forward as seams will no longer be an issue

AmethystPendant posted at 7:38PM Mon, 25 November 2019 - #4371214

If this issue is being looked at by Bondware, could they please implement it at the obj level so that those of us that use Blender et al rather than ZBrush could also take advantage of HD Morphs, that would be great, a GoB would also be appreciated although I am quite happy to just use export / morph import.

TBH I'm surprised that even GoZ works with a posed figure rather than zeroed, I have colorcurvature's script (which is excellent BTW) but that has to do a lot of pre / post calculation to import a "posed" morph (although if we can now export a full figure and import an FBM that might be easier going forward as seams will no longer be an issue

We've been able to go/return with posed figures using GoZ since it's first release. I feel your pain on the object export. If they'd just fix that tidbit it would make life better for everyone, wouldn't it? Zbrush is by far not the only program that could do morphs. I'm with you on that. You can however export base resolution - and maybe that's something - at least it's an improvement from the old days when even that didn't work.

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.

Caisson,

I just wanted to make a quick point on the business practices which you used to divert the matter away from DAZ. As you know DAZ and Smith Micro have been at each other's throats for years now over domination of the 3D hobby market. DAZ took the razor and blade approach whereby they give you software and then sell you overpriced content produced by third parties whom they suck up 40-75% of the profit from. It is, however, like it or not, a highly effective system that has made them extremely successful in recent years. In addition their attention to producing base figures that actually resemble a real human and aren't ugly as Frankenstein has also been to their benefit and the most effective blow they struck to Poser was when they made the Gen3+ series of figures inoperable in Poser (at least for a while). By making their HD functions only really work in Studio, they effectively kicked Poser users in the teeth. Since then most of us have figured ways around it using the DSON plugins, I mean why lose all Poser users, we've got money too, right? So we've got DSON these tdays to help us use DAZ content - but the damage is already done.

Now, I, like many, saw the writing on the wall many years back and I realized after Game Dev released that if Poser didn't kick it up a notch and do something extreme, DAZ would overtake them. I was so worried about it that I nagged Charles till he put me on the Beta team at Smith. The first thing I lodged protest over was that horrible base female figure they handed us to test. She was and still is horrid. Sure she does neato stuff, but she's still ugly and her anatomical proportions are so awful that it's almost pathetic in comparison to Genesis 3 and 8. I'm no DAZ fan, but I'm not going to pull punches on facts. A few tweaks to her overall anatomy would have improved her appearance and shape, but no one listened to me. I even made the changes and submitted them. I was ignored. I also warned that if Poser didn't do something new that was vastly ahead of Studio, that no one was going to shell out hundreds of dollars to upgrade. No one listened. I saw what horrors they unleashed on the Preview renderer and could not for the life of me figure out why the dev team was even screwing with it - much less making it worse. Eventually I quit the beta team over it all. I wasn't the only member to do so.

As I predicted, Poser released 11 with so many bugs and a horrible figure and it really warranted nothing worth upgrading for. Then when sales fell flat, Smith decided to just drop the program and kill it. In steps Bondware. Bondware snaps it up and quickly sets about pulling in the same team Smith had and reworks the whole shell of the software, redubs it 11.2 and forces all users to upgrade to it, including Game Dev users - replacing "license" with "lease" and now making users log in (online) every 7 days to reactivate the software.

So your comparison of what Bondware is doing or will do in relation to what Smith was doing is entirely off base. Smith screwed up and dropped the ball. Their business model did not work and nearly killed one of the longest running, most successful 3D programs in history. And I while I know the Smith administration is likely responsible for many of the horrible decisions made, I also hold the dev team responsible for much of it. They focused on revamping Poser when 2014 was mostly stable and functional and sold quite well. They should have built on the original system and improved it - not rebuilt it. The time wasted on that could have been used to create all new capabilities. I mean sure the new Runtime libraries had to be changed because of the Adobe base it used, but they turned around and used Chromium. Like that's not going to have problems later just like the Adobe Air did? Long story a little shorter, they didn't improve 11 enough to warrant a release and few people were impressed with what was advertised. Sales tanked and as warned by me and others, Poser nearly died as a result.

Now do you really think Bondware isn't aware of this? They know the Smith system failed. Do you think they bought Poser with the intent of repeating the same errors? No. Of course they didn't. So clearly, unless Bondware's bosses are idiots, they've got something up their sleeves with regard to making money off the program. I literally have an email from a Bondware rep where she admits bluntly that Bondware bought Poser to make a profit. Following Smith's lead will not do that. And since Bondware has made the moves already to delete the latest versions and force users to upgrade (forfeiting their "owned" licenses and forcing them to accept new "leases")...well that indicates to me a couple of things:

1. Smith was reliant on users voluntarily upgrading to new versions of Poser. So a new version had to make you want to throw money to get it or it failed and Smith suffered financially. So clearly Bondware will seek to get around that. How? By forcing users to upgrade. Wait, what? They've already done it once now. And by taking away the permanent license option and forcing users to renew their "lease" weekly, all they have to do is tell you to upgrade or they'll stop servicing your lease. They would never---oh, but they just did, didn't they? By adopting this system they now have everyone on a "lease" meaning they can discontinue your activation at any time and force you to take on new versions. They say it's all to prevent piracy, but is it? Read further...

2. Most software companies have now gone over to cloud subscriptions where you don't own your software but pay monthly to "use" it. It seems great because programs like Photoshop that once cost $1000 are now available for a few bucks a month. Yeah, more users can now afford to get it! This narrows down piracy of course, but the real bottom line is it brings in more customers and provides Adobe with a steady, endless, monthly income. But you "lease" photoshop now, rather than own it. See I own my suite from many years back and I'm still using it. To Adobe, I'm dead weight. They can't come up with anything new and cool enough to make me pay to upgrade, so at this point, the shift to subscription was their best avenue. I can almost guarantee you this is where Bondware is heading with Poser. That's why they took down the previous releases and forced the upgrade to their version with the lease option injected into it.

Bondware doesn't really possess the ability to do a lot with Poser until they've made some money off of it. And waiting years to develop a new version to make a profit (maybe) if it's impressive enough...really isn't an option, and so they are looking at different paths from Smith. And I will not be shocked one bit if in 2020, they release a new upgrade that will only be available via subscription and they force old users to upgrade to the service. Not shocked one bit.

Poser has been crushed by the collective stupidity of Smith Micro. DAZ is on top right now for the first time in decades. Poser will die. The only people with the money to really do something with it, didn't. Bondware is trying to save it because they view it as a cash-cow...the only question being how to milk said cow. They're not going to wait years to recoup on their investment. They didn't swap out "lease" in the EULA for no reason. A monthly subscription model will enable to make a monthly income from it which they can then turn around and use to cover the costs of the dev team and it will also make customers permanent monthly cash sources forever and remove the chance that anyone is operating with pirated copies. They killed every copy they could - including Game Dev. Prior versions didn't have the call in registration so they couldn't take them out. It's all a big picture but you have to back up to see it all.

So in the end, your argument that we should assume Bondware is working off of the Smith model is not only wrong, but an insult to Bondware in general. You're saying they'll follow an obviously failed system of development and sales. I don't like what Bondware is doing, but I don't think they're that stupid. I think they have a definite plan and they are implementing it. If it saves Poser, I'm happy. I'll pay monthly at some point if the software does what it's supposed to do. But until then I won't. But La Femme and crappy previewers and HD morphing that doesn't work...is not selling me on it. And I fear unless the Dev Team gets its act together, and rectifies all the known problems, even a subscription model is not going to be successful. No will pay monthly for software that doesn't work well. So no, Bondware is not following Smith's model. So to assume (on your part) that they would not proceed along similar routes of a successful system (aka, DAZ)...is pretty naive. Locking up features to control content works. It works well. Ask DAZ. And as the Bondware rep admitted to me, Bondware intends to make money with Poser. So don't assume things based on Smith's failed path.

So I stand by my point regarding similarities in issues. When the HD bug is fixed, I might admit my error and dance happily with joy in my heart. Never more have I hoped to be wrong. I truly do hope I'm wrong. But I'm suspicious this bug will not disappear and that more HD morphs for La Femme's figure will be forthcoming in the store. I wish to be proven wrong. I do.

The thing Charles and the gang need to realize is that they have to blow DAZ out of the water with one single shot. Whether it's with a new release or with monthly subscription release - however they proceed, they have to shock-and-awe them into oblivion. It can be done. The HD bug being fixed would be the first major shot. If people can take any figure into Poser, up the poly levels and maintain a solid figure that can be baked reliably it will be the end-all-do-all. DAZ sabotages their software to prevent this. Poser needs to free it up and rub it into DAZ's face. "Look what we can do over here! DAZ can't do that!" Sure it means sacrificing the ability to control the HD content - but then allowing an explosion of new content will make the newer Poser all that much more sought after. Remember DAZ uses razor and blade method. A reverse on that plan might also work. Drop a few bucks a month to get Poser and look at all the loads of content we have - whether in the store or as freebies. Bondware has to beat DAZ at their own damn game. It's going to hurt for a while, but in the end when the smoke clears, Poser will still be standing.

Other points that I hated (as a 24 year Poser fan and customer):

1. Superfly. It's horrible, it's slow, it sucks. I liked Firefly. I hate Iray in DAZ. It's slow, it's cumbersome and hard to set. Why would Smith emulate that? Make Firefly better or set up a better bridge to other render engines that are already out there. There's already a bridge for Octane (which is my favorite). It didn't even need much texture tweaking. Why not work to integrate something with Octane rather than building your own engine. That was dumb and wasteful.
2. Preview. I don't know what they did to it, but it simply does not display in a fashion that I can stand to look at. It won't render the lights right no matter what. It's not my graphics card or my system. 2014 and Game Dev displayed just fine. I have tested it on a Win10 system I have and it does just the same. Even Bagginsbill commented to me that [Smith] tinkered with and messed up the previewer. This needs to be fixed asap. If you can't fix it, put it back the way it was. Whatever supposed improvements were made with 11 stink. The old version was better.
3. Get an anatomically correct figure. I can't say this enough times. ANATOMICALLY ACCURATE. Please.
4. Stop cramming useless content at us. We don't want content - we want functionality and capability. A thousand dollars worth of free models doesn't help me if the software needed to use it sucks. You're putting fresh paint on an old car. It's window dressing.
5. Make weight mapping work using alphas (grayscale). Having to paint weight mapping to get the physics to work is ridiculous. Let me paint myself a working physics map and apply it to all my figures. Make the physics simulations more accurate. (I complained about this when I was a beta member and Charles agreed with me at one point.)
6. Work on a bridge to Photoshop whereby I can bridge a texture or figure into it for tweaking, painting, or fixes. A bridge into one of the other major 3D paint programs would also be great if not better. If Poser wants to survive, it must retrieve it's bearing as a professional or near-professional level program and it's failing currently. It's being laughed at once again in the pro-arena. The Bondware team needs to get in there and makes some deals with the other 3D software companies. If it can be done with Pixologic and Octane, it can be done elsewhere. Make it happen like your jobs depended on it.

This is of course just to start. Things that need to be done. There's a lot more that could be done. Personally I'd love to see MAX importation as well as some connectivity with Blender. FBX was a great development, but import/export could go further. Get ahead of Studio! Leave them crying in the street watching your tail-lights disappearing into the darkness of profit city. I want Poser to succeed. I want Bondware to enjoy the profits of their acquisition. Both can happen. And it will begin with a reliable fix on this HD problem and then when you do it - advertise the living crap out of it. If you show the HD happening, the users will come! I would pay for an upgrade just to get it. I'm an old user - I'm the guy you want to pull in and keep.

Sometimes facts are harsh and don't give a darn about feelings and opinions. While they may hurt, sometimes they simply need to be said. I've said them. I hope someone is listening and realizes that I have made valid points. I hope in the end, it helps.

You probably do not want my input here because it is not related to zbrush, but I have always used Silo pro to morph my figures, It will work only now sometimes with the blank La feme. If I try to take the head of the morphed model to tweak it, I will get error message, not the same number of vertexes. the same with a full body morph. When I export it out of silo it has exactly the same vertexes but load it into poser it does not.

What is the Preview level set to? It is set to 1 by default, which means you export the mesh with 1 level of subdivision. With Preview set to 0 you export the base mesh. There is more chance of it working with the base mesh, it definitely won't work with the subD mesh.

even set to zero it works and not works

Remain on topic please or I'll have the mods lock the post. This post has nothing to do with Silo. If you want to discuss Silo, start a new thread in the proper category.

I will apologize for my post as it was a little off topic, but then it was merely to show it happens in other programs when carried back into poser. Not like the lengthy ones about daz that has nothing to do about morphs being carried back into poser.

JAG posted at 8:28AM Fri, 13 December 2019 - #4371431

Caisson,

I just wanted to make a quick point on the business practices which you used to divert the matter away from DAZ...{entire unabridged novel War and Peace}...I hope someone is listening and realizes that I have made valid points. I hope in the end, it helps.

I agree with most of Caisson's observations. I think a subscription model is likely inevitable. How it's implemented will determine if it kills or saves Poser.

1. If you charge monthly for something your competition gives away for free you're probably going to be in trouble. DazStudio is free, if the new version of Poser is subscription based and prior versions are left along and not forced to deactivate, but the subscription model is constantly supported, gets new features that work well, people will willingly go to the subscription model for the better software and features and this will likely work.

2. I have been an avid Poser user since Poser 4 (I had purchased Poser 2 but hadn't used it much) but I think you're going to have to suffer through a period of "rebuilding" like sports team do where you're not a profit but building confidence for your software before you start making profits again. I think that a more lucrative strategy than trying to make a profit right off the bat in the face of Daz3D war against you.