Hat tip to @primorge for inspiring the thread title.

Subdivision morphs were among my favorite things after my return to Poser earlier this year. Sadly, it seems that at the moment the only two ways to make them are with the Poser Morph Tool or via ZBrush/GoZ. I'd like to be able to make subdivision morphs with any modeling software that can read and write OBJ files, so I'm working on some Python code to make that happen.

Here's the workflow I'm aiming at (a.k.a. my evil plan):

1) In Poser, load a figure, convert to unimesh, then export the whole figure as an OBJ at base resolution.

2) In the modeling software, import that file, subdivide and sculpt, then export as a new OBJ at the highest resolution.

3) Call the command line Python script I shall write with both OBJs to produce a PMD and accompanying PZ2 for a Poser morph injection pose.

4) Back in Poser, bring the figure to the desired subdivision level, apply the injection pose and rejoice.

I'm not entirely sure the PMD path covers all possible applications (e.g. can I inject post-transform morphs such as JCMs via PMDs?), but it should be a good start. I have no plans of writing an integrated morph loader in Poser Python, but I'd happily provide all the necessary geometry crunching code (even in Python 2.7 if desired).

So much for now. I'll be posting progress updates as I go. Let me know what you think.

You can inject post transform, translation, rotation, scaling (that's all I've tested) via pmd. I generally attach such transforms to an empty body master and it works every time. Doing so via create new master has given me injections with dead dials. To create an empty body master have the figure completely 0 (or use a zeroed dev version, even better) and Figure:Spawn Full Body Morph. Right click the resulting dial and delete morph. Untick only the dial in the Body, which will delete all the resulting empties, except for the Body dial, which were created during the spawn. The Spawn command creates a dial in all actors, including parented props (you'll have to individually delete the empties in Goal/Center of Mass, or simply exclude them from the inject). 

Nice! Thanks for confirming that it can be done with PMDs.

Apparently in Poser 12, I can just use 'Figure:Create Full Body Morph' to create that dial in the body and nothing else. Since I don't have Poser 11, I can't tell it that's a new feature.

Ha, I just spent an hour hunting down the weirdest "bug". Turns out that if I apply a morph to write out the result as an OBJ, I should either recompute the normals or delete them, so that when I test the output in Blender, it doesn't look like it applied the morph to the shoulders and legs, but not the abs. *headdeskemoji*

Don't mind me. On with your regularly scheduled program.

Apparently in Poser 12, I can just use 'Figure:Create Full Body Morph' to create that dial in the body and nothing else. Since I don't have Poser 11, I can't tell it that's a new feature.

Ha, I just spent an hour hunting down the weirdest "bug". Turns out that if I apply a morph to write out the result as an OBJ, I should either recompute the normals or delete them, so that when I test the output in Blender, it doesn't look like it applied the morph to the shoulders and legs, but not the abs. *headdeskemoji*

Don't mind me. On with your regularly scheduled program.

Most programs calculate normals on load. I don't think I've ever encountered an instance where deleting the vn lines from OBJ had any effect upon importing to various environments. It's my understanding there are certain instances where Poser recalculates normals on the fly during certain processes, or so I've heard. Can't remember the particulars but I think it involved solving some scene bug, and it was a workaround, perhaps discussed by Bagginsbill.

All I know is that when RDNA adapted Antonia, they removed the normal data from the OBJ because supposedly Poser does not use it and always recomputes the normals on load. I've never checked that myself, but I guess it can't hurt to leave the normals out and save about 30% of disk space for storing the file.

But Blender definitely uses what's in the file unless one recomputes the normals explicitly. That can be useful when one does elaborate mesh surgery and wants the normals to stay consistent, so it makes sense for a program like Blender to use them. For Poser, it's probably much less useful.

If you're really keen on seeing the effect, I can send you a demo file.

primorge posted at 3:33 PM Sat, 18 December 2021 - #4432073

odf posted at 11:37 PM Fri, 17 December 2021 - #4432043

Apparently in Poser 12, I can just use 'Figure:Create Full Body Morph' to create that dial in the body and nothing else. Since I don't have Poser 11, I can't tell it that's a new feature.

Oh really? Lol. Never tried that :D... it's in Poser 11. Actually, I can't say that I haven't tried that, there may be some reason that I'm not recalling why I don't use Create. I'll go back over it sometime. Right now it's a "if it ain't broke" scenario with only very minor inconvenience. Thanks for the heads up.

Incidentally, is there a way to get rid of the channel in GoalCenterOfMass? I can do all the body parts and CenterOfMass, but I don't see a way in Poser to access GoalCenterOfMass. Not really important, just curious. Could also just be a kink of Antonia's.

Hardcore in the midst of voxels in 3dcoat right now. I think my computer may melt. Dude, the retopo stuff in there truly is incredible. Anyway, I may be delayed in my 'V4/M4 Products Now' and 'Nova_Project' commitments this weekend as a consequence. I shouldn't put time of delivery statements in my posts.

Anyway.

Select GoalCenterOfMass in the Hierarchy Editor, you have to have Show Props ticked, that will bring it up in parameters. The dials will then be visible for the prop. Right Click the Parm. Delete Morph. I guess that's what you're asking...

I just checked, Antonia definitely has a GoalCenterOfMass accessible via Hierarchy Editor.

I shouldn't put time of delivery statements in my posts.

Good idea!

Select GoalCenterOfMass in the Hierarchy Editor, you have to have Show Props ticked, that will bring it up in parameters. The dials will then be visible for the prop. Right Click the Parm. Delete Morph. I guess that's what you're asking...

Looks like I'm getting close. I forgot that the deltas used a different coordinates system from the OBJs. The results are not quite correct yet in Poser, but there's a resemblance. Any day now...

primorge posted at 3:33 PM Sat, 18 December 2021 - #4432073

odf posted at 11:37 PM Fri, 17 December 2021 - #4432043

Apparently in Poser 12, I can just use 'Figure:Create Full Body Morph' to create that dial in the body and nothing else. Since I don't have Poser 11, I can't tell it that's a new feature.

Oh really? Lol. Never tried that :D... it's in Poser 11. Actually, I can't say that I haven't tried that, there may be some reason that I'm not recalling why I don't use Create. I'll go back over it sometime. Right now it's a "if it ain't broke" scenario with only very minor inconvenience. Thanks for the heads up.

Okay, I had a closer look. The "create..." command makes a valueParm, whereas "spawn..." makes a targetGeom.

Missed this part. So a valueParm is just a master dial, essentially the same thing as the Create New Master command, whereas targetGeom is a morph dial. So, PMD carries morph data and morph data associated dials... you might want to check whether using Create Full Body Morph (valueParm) will carry over to injections in various instances. As I've said previously Create New Master sometimes results in dead dial injections, from my experience. Especially when linking up non morph type controllers such as pose dials. Though nerd has said "just use Create New Master" I've had enough failed PMD injects for these types of things to just habitually use an empty Spawned master (targetGeom), which works through inject, for me, every time. Probably in the past I got burnt by create full body morph for controller dials via inject.

Oof!

So it turns out the coordinates for subdivision deltas are actually given with respect to the tangent space. The first coordinate is along the normal, the second seems to be the surface tangent that lies in the xz-plane, then the last coordinate is orthogonal to both. I'm assuming that makes it easier for the renderer to munch them up or something.

That's not the case for regular morph deltas, is it? They are just figure-space x, y, z, aren't they? It seems that I would have remembered if they were all fancy-like.

Also, is there maybe a parameter for telling Poser how to interpret deltas that I've forgotten about?

As I said, any day now...

The tangent space approach looks good, but I need to figure out the exact rules for the second and third coordinates. I'm going to have to do science to it (see illustration, curtesy of Dresden Codak), unless I can find a volunteer oracle, i.e. someone who knows the actual implementation and will tell me what it does.

Forgive my ignorance but would looking at Pixar OpenSubDiv stuff be of any use? Or have you been doing that all along? Or is it not relevant to the problem?

https://graphics.pixar.com/opensubdiv/docs/subdivision_surfaces.html

You might also want to peruse this... some of the info might be relevant now or down the road

https://www.renderosity.com/forums/threads/2939685

Thanks primorge, but I don't have the patience to read through walls of text on the off chance that I might find some pertinent information in there.

I did some experiments with a sphere and the same constant delta for each vertex in order to see what happens. It seems Poser uses different computations for the second and third coordinate depending on which octant the normal is in. Very strange! The best I've been able to do so far is to only use the component along the surface normal and ignore the other two. That produces very nice results, but it does not cover all the subd morphs one might want to make.

I'd say I give up at this point, but I know my brain won't let go of this, so I'll probably be coming back and trying more things.

To illustrate, here is the Poser high-res ball at subdivision level 2 with the exact same delta (0.0, 0.01, 0.0) applied to every vertex (at morph strength 2.88). Honestly, I don't think Pixar would be selling any movies if they wrote graphics code like that. Pretty sure it's original Poser.

It looks suspiciously as if they did something sensible and coherent for the vertices of the original mesh and then had some interpolation accident happen on the rest. There's a clear pattern there, so one should be able to reverse engineer what they did, but I'd need some strong motivation to attempt that kind of thing, like - I don't know - Alison Brie promising to teach me wrestling moves.

Thanks primorge, but I don't have the patience to read through walls of text on the off chance that I might find some pertinent information in there.

Sorry, that sounded like I didn't appreciate you digging up information for me. I do. Both links look like they could come in handy at some point, just - as far as I can tell at a quick glance - not right now. So once more with feeling: thanks!

It's true though that I tend to be quite impatient, have a short attention span and also to make it worse, bad memory. So unfortunately linking me to a long document may not always be as helpful as it sounds.

Poser, I want you to know that I'm not mad at you, just disappointed.

Seriously, that was a bit of a shock yesterday, but I think I'm over it. Let's see what we've got so far...

We can make subdivision deltas from a morphed OBJ file (plus the original subdivided OBJ) and stuff them into a PMD file, that Poser can then load as a functional full-body morph target. The proof is in the six pack, here a sloppy Blender sculpt of Antonia at subd level 2:

The limitation is that for the moment, we can only reliably produce deltas that move vertices along their normals (because lateral deltas make the mesh go crunch). That might not be as bad as it sounds if we can bake the lateral movements down into base level deltas. That has the potential of losing a little bit of accuracy and detail, but my feeling is that it will be good enough for a lot of actual morphs. There is the problem that going back between Poser and [insert external program used for morphing] might eventually create artifacts due to the accumulated information loss* as has happened (or possibly is still happening) with GoZ.

At any rate, I will look into baking down the deltas next, which means more experiments with balls and controlled deltas. In the meantime, I'll also look around for alternative ways to get morph data into Poser, e.g. a special parameters that might tell Poser to interpret the deltas differently, or something useful in the Poser Python API (although I do like to work with files and will probably only switch to working inside Poser as a last resort).

Anyway, if we don't see each other before then,

Merry Xmas from Subdivision Santa

* This reminds me of how when I was a wee Uni student, I used to misuse the library Xerox machines to make copies of copies of magazine photos because I was fascinated by how they changed from step to step. Unfortunately in this case I don't think we can expect results that are anywhere near as attractive.

Interesting: the effect of the lateral deltas gets much more consistent when I explicitly specify empty sets of deltas for all the preceding levels. There's still an undulating pattern in there that reminds me off one of the illustrations in the Pixar doc. So I reckon I'll deep dive into that next.

Pffft, now I can't reconstruct the problem from yesterday anymore. I'm always getting that undulating pattern. Fun times!

Poser go home, you're drunk.

The limitation is that for the moment, we can only reliably produce deltas that move vertices along their normals

We can do the same with a displacement map. No morph needed.

A wild guess: Is the data perhaps a normal map?

odf posted at 5:33 PM Mon, 20 December 2021 - #4432163

The limitation is that for the moment, we can only reliably produce deltas that move vertices along their normals

We can do the same with a displacement map. No morph needed.

adp001 posted at 6:21 AM Tue, 21 December 2021 - #4432191

A wild guess: Is the data perhaps a normal map?

It also seems that I've been thinking about this too much like a mathematician and not enough like a programmer. The erratic looking behavior I see when I apply the same delta to all vertices of a mesh makes a lot more sense when I assume that the coordinate directions are computed from the per-face data with as little effort as possible. For example, the morphed cube shown above would have to be perfectly symmetric if the actual vertex normals had been used for displacement. If face normals were used instead, the might explain the irregularity, because then the direction used depends on which face is chosen for each vertex.

Anyway, I'll be doing more experiments, and I'll also start a separate thread in this forum to ask about how subdivision deltas work exactly. Maybe we're lucky and someone in the know stumbles upon it.

PS: Come to think of it, maybe it would indeed be worthwhile if I tried to find some details on how the local coordinate directions are computed for displacement maps and such. There's a decent chance that the Poser developers borrowed some code or at least some ideas from those.

Morphs are downward compatible. This means that the standard morph data must be available. To make it a hires morph, I would take the pre morphed polygon and subdivide it further with "normal data". That should be good for any kind of subdivision.

Just an idea.

Asking someone would certainly not be a bad idea. Why don't you try to contact the programmers directly? Maybe through Nerd, he seems to be quite cooperative, if it brings something

If I understand correctly, a normal map would only encode a normal direction, not a displacement magnitude?

That's the idea for normal displacement without changing the actual geometry, yes. But at the end RGB colors are interpreted as XYZ coordinates.

I have no access to Poser at the moment. Otherwise I would try doing a standard morph, then add subdividing and push just one of the new vertices and look at the output data.

Wikipedia can tell anything about Normal maps: https://en.wikipedia.org/wiki/Normal_mapping

Morphs are downward compatible. This means that the standard morph data must be available. To make it a hires morph, I would take the pre morphed polygon and subdivide it further with "normal data". That should be good for any kind of subdivision.

Yes, that's my back-up plan. That's more or less what I meant by "baking down to the base resolution," which probably wasn't clear enough. I can of course do arbitrary displacements at base resolution, so that'll give me the basic shape. At higher resolutions I can do displacements along the normals more or less reliably. I say more or less because of course the normal is also just approximated in some way.

The problem with the tangent (and then also the bitangent) is that it can be any direction along the surface, so the programmer has a full 360 degrees to pick from, and which one is used is purely a matter of convention.

This is what my current test rig looks like:

I use two identical cube meshes out of Blender at subdivision level 1. One is unmorphed, the second one has three morphs M1, M2 and M3 with constant deltas in the first, second and third coordinate direction, respectively, for all the level 1 vertices. I'll call those directions n (for normal), u, and v, respectively. The base level vertices stay where they are.

It seems that for each level 1 vertex, either u or v follows one of the edge directions adjacent to that vertex. So far, though, I haven't figured out when u and when v is chosen, and which of the edges is used. The next step could be to export the morphed results and run a script on them that relates the displacement to the OBJ data in order to see if there's some discernable pattern (e.g. always move along the first/last edge the vertex appears in).

Okay, so the idea with the normal map was actually quite helpful. The u- and v-directions follow the texture u and v, which is quite nicely visualized by putting a tile pattern on lo-res Antonia, making a subd morph with a constant delta of either [0.0 0.01 0.0] (u-direction) or [0.0 0.0 0.01] (v-direction) and playing with the dials.

adp001 posted at 6:02 AM Tue, 21 December 2021 - #4432190

odf posted at 5:33 PM Mon, 20 December 2021 - #4432163

The limitation is that for the moment, we can only reliably produce deltas that move vertices along their normals

We can do the same with a displacement map. No morph needed.

I personally love using displacement maps. Unfortunately Superfly doesn't, which alienates a certain constituency.

Of course Cycles (or Superfly in Poser) can handle displacement maps. If you want to use displacements like Hires morphs, you have to set the same Sub-D level. That (maybe together with normal maps) is all that is needed.

Advantage: With displacement/normal maps one saves resources considerably. No need to carry around huge amounts of morph data in the figures or props. Whether you need them or not. This is different with displacement/normal maps: They only become active at render time. And only if the maps are activated.

That was the reason why I didn't try very hard to find out how hi-res morphs work in Poser. I don't need them.
Nice, if someone who knows comes over with the information. Then it can be incorporated where it for one or the other could make sense (those are not many anyway and it's getting less and less).

primorge posted at 2:39 PM Tue, 21 December 2021 - #4432204

adp001 posted at 6:02 AM Tue, 21 December 2021 - #4432190

odf posted at 5:33 PM Mon, 20 December 2021 - #4432163

The limitation is that for the moment, we can only reliably produce deltas that move vertices along their normals

We can do the same with a displacement map. No morph needed.

I personally love using displacement maps. Unfortunately Superfly doesn't, which alienates a certain constituency.

Of course Cycles (or Superfly in Poser) can handle displacement maps. If you want to use displacements like Hires morphs, you have to set the same Sub-D level. That (maybe together with normal maps) is all that is needed.

Advantage: With displacement/normal maps one saves resources considerably. No need to carry around huge amounts of morph data in the figures or props. Whether you need them or not. This is different with displacement/normal maps: They only become active at render time. And only if the maps are activated.

That was the reason why I didn't try very hard to find out how hi-res morphs work in Poser. I don't need them.
Nice, if someone who knows comes over with the information. Then it can be incorporated where it for one or the other could make sense (those are not many anyway and it's getting less and less).

I didn't understand most of those words, so...

The reason I'm so interested in hi-res morphs is that they would allow me to dial in local detail selectively, say some extra wrinkles to help with an expression or some veins on just a hand. Also they'd supposedly be able to fully participate in the Poser ERC circus. I agree that for full-body sculpts it probably makes more sense to bake the hi-res detail into displacement and/or normal maps (although I lack the personal experience, so that's just a guess).

Also I love me a challenge - until it starts looking too hard, then I hate me a challenge - until it starts looking doable again, then I love me a challenge. And so on, ad infinitum.

Hilarious condescension is actually a mandatory subject at German schools. One simply won't get a high school diploma without passing it.

Seriously though, there's one for the New Year's resolutions.

I personally love using displacement maps. Unfortunately Superfly doesn't, which alienates a certain constituency.

I've experimented with trying to get various displacement maps I've made in the past in Zbrush and Photoshop to work in conjunction with subdivision via the Physical Surface Root. It works, but it's not practical compared to Firefly render time displacement. The comparitive amount, for the resolution maps I have at least, of subdivision I'd need to use is just too much. Just doing it via Firefly is way more practical with better results IMO. So Poser displacement is another thing that I feel Firefly does better at the moment. I use 11, I doubt much has changed in 12 regarding.

Sorry. I'm not sold on Superfly... at all. For me it's a downgrade, just as Poser 12 would be a downgrade. Sigh. I don't give a hoot if it's "more real" it's all fake regardless, and there's established fake methods that produce results that are real enough for my art purposes besides. And much more quickly.

I'm a bit worried about Poser actually. But I'm drifting off topic and I don't have any beef with Poser; One of my favorite pastimes.

I should probably clarify a couple things that might be confusing in my wording ODF. I'll imagine you're not too familiar with the differences between Firefly and Superfly displacement. In Firefly the displacement happens via the polygons being extremely subdivided via triangulation during render, the detail of the displacement dependant on the map resolution.

Superfly on the other hand doesn't do this micropolygonal subdivision, you have to have subdivision active at a level that will accommodate the detail of the maps you're using. So if I were to sculpt and generate detail maps in Zbrush at say 6 levels of subdivision while sculpting I'd have to accommodate with a close level of "live" subdivision in Poser to capture the same level of detail as I'd need for the Superfly render to look right.

It's probably most practical in either instance to leave serious height displacement up to render displacement and fine details up to bump or normal. In either case. Firefly still wins. And subdivision morphs are definitely novel but half baked (no pun intended) at this time. As you pointed out, being able to mix and link to dependencies is the really interesting thing about HD morphs... but you still have to build your mesh with specific features in mind to be at all practical. 

I should probably clarify a couple things that might be confusing in my wording ODF. I'll imagine you're not too familiar with the differences between Firefly and Superfly displacement. In Firefly the displacement happens via the polygons being extremely subdivided via triangulation during render, the detail of the displacement dependant on the map resolution.

Superfly on the other hand doesn't do this micropolygonal subdivision, you have to have subdivision active at a level that will accommodate the detail of the maps you're using. So if I were to sculpt and generate detail maps in Zbrush at say 6 levels of subdivision while sculpting I'd have to accommodate with a close level of "live" subdivision in Poser to capture the same level of detail as I'd need for the Superfly render to look right.

So now I'm actually wondering what to work on first: the "baking down" of the displacement to the lower subdivision levels (all the way down to the base level) or the fixing of the lateral displacement in the higher levels.

The former seems to deliver more value right away because it would take care of all the low-frequency lateral displacement, which can be handled easily at the base level, and it would produce a morph that can be used at any desired subdivision level. Which I think is kind of crucial, because if we always rendered everything at the highest resolution, we could just as well use higher-res figures to start with.

The latter seems more like the icing on the cake (no pun intended). Depending on how close I can get to the actual u and v directions used inside Poser, I might potentially and with some luck get a bit more accuracy in the details relative to the original sculpt. Note the pile of qualifications there. But honestly, I have no good intuition as how important the higher frequency lateral displacement is in the "real" world. I suspect the answer, as so often, might be it depends.

Opinions?

Sorry to be "that" guy, but wouldn't an animated displacement texture be a more straightforward solution?

https://www.renderosity.com/forums/threads/2901601

So the problem is you want wrinkles to go along with a smile morph. (Or think how the soles of your feet wrinkle when you bend them. So far no Poser figure has yet solved that problem.)

So just ERC link a displacement map to the smile morph, and that's that.

It won't show in preview, but most people don't care about a "nice" preview, anyway.

(I'm one of the few who really, really LOVE a "nice" preview, so I'd more than happily see subdivision work properly in Poser without slowing my machine down to a crawl)

In my experience, subdivision makes the Morphbrush jerky and unresponsive very quickly, and you need quite a bit of it to create really convincing wrinkles.

I'm enjoying this thread, even if I don't understand ALL of it. ;-)

I think it should be a combination of basemorph (SubD-0) and displacement/normal map. The morph takes care of the vertex shifts mainly in X/Y and the displacement/normal map takes care of height and depth.  The intensity of the displacement map can be coupled to the morph. The result should be similar to a SubD morph.

Nevertheless, the problem remains that a high SubD value must be set for the entire mesh. The displacement is only effective with Superfly if a sufficient number of vertices is provided by SubD.

So the fact that Poser slows down with increasing detail remains even with this method.

Since real micropolygons are not feasible with PBR render engines, the Blender programmers have found an elegant solution to this problem in Cycles: They increase the SubD level depending on the distance to the camera (called adaptive subdivision). The result is simply impressive.

"Nevertheless, the problem remains that a high SubD value must be set for the entire mesh"

*

Wouldn't that be awesome if a subdivision area could be controlled by a map or a morph?

*

I recently tried a very crude "real world" solution to that problem:

I exported a subdivded torso and stitched the unsubdivided arms and head back on to create a "high res / low res hybrid mesh", as most detail "happens" in the torso area anyway. (Ribcage, shoulder blades, spine)

Unfortunately the UV-coordinates got messed up along the seams, so I abandoned the project.

Sorry to be "that" guy, but wouldn't an animated displacement texture be a more straightforward solution?

https://www.renderosity.com/forums/threads/2901601

So the problem is you want wrinkles to go along with a smile morph. (Or think how the soles of your feet wrinkle when you bend them. So far no Poser figure has yet solved that problem.)

So just ERC link a displacement map to the smile morph, and that's that.

Thanks for the link! I'd been wondering how to make dials for material room properties. It seems Poser is making that really easy these days.

It won't show in preview, but most people don't care about a "nice" preview, anyway.

(I'm one of the few who really, really LOVE a "nice" preview, so I'd more than happily see subdivision work properly in Poser without slowing my machine down to a crawl)

I hadn't thought of that, but being able to see the morph in preview and getting an idea of how it catches the light is another plus for subdivision morphs, which I do care about.

In my experience, subdivision makes the Morphbrush jerky and unresponsive very quickly, and you need quite a bit of it to create really convincing wrinkles.

That's exactly it. I think there's a sweet spot for subd morphs at one or two levels of subdivision where Poser can handle the polys nicely in preview and render and one gets just enough resolution out for some nice extra detail. BUT the Poser morph tool gets overwhelmed really quickly and it's just no fun making these morphs in Poser. The only other option I know of is ZBrush via GoZ, and I guess I'm not yet ready to commit to ZBrush, both money- and interface-wise. So I'd like to be able to just make subd morphs for Poser in any old 3d modeler like Blender or Wings3d or Mudbox or what have you. Hence this project.

I realize now that "wrinkles" was a poor choice of words on my part. I was thinking more about larger-scale skin folds that appear with a smile or frown. Those should be a good application for subd morphs. Fine wrinkles indeed not so much.

I'm enjoying this thread, even if I don't understand ALL of it. ;-)

But from a practical point of view, as long as Poser's subdivision doesn't run as effortlessly as it does in ZBrush, wouldn't it be better to use it only in a scenario where it is "less harmfull" to the user experience?

Like a said above, I think the user experience using subd morphs up to a certain level is actually quite good, and arguably better than displacement maps if one wants some degree of flexibility. The user experience creating them, not so much, and that's the part I'd like to try and improve.

Here's a little visual aid, or should I say aide? Antonia at subdivision level 2 with several morphs made with the Poser morph tool. Painful to make, put so nice to work with once I had them. The full images are in my gallery.