Quick summary: If you have some dynamic V4 headgear that has 'constrained' vertices in close proximity to her 'eyeBrow' body part actor (which is by default invisible) then those vertices will remain static in relation to world space when you run a simulation, irrespective of V4's movement. Unless you make the V4 'eyeBrow' body part actor visible when you run the simulation !?!

(same thread started at RDNA yesterday - http://forum.runtimedna.com/showthread.php?101714-Odd-Problem-With-Dynamic-Headwear-And-V4-eyeBrow-In-Poser-8 )

I've tried this with a specific prop in Poser 8, 9 and PoserPro2014 and they all seem to exhibit the same problem, with the same wayward vertices. I've also tried the same in Poser 6 - no such problem. So I suspect that this is a bug introduced into the Cloth Room at Poser 7 or 8 (I don't have 7 to test)

Has anybody else run into anything like this ? Can anybody explain why this happens ?

Here's a very simple step-by-step to reproduce the problem, with just V4.2 and a freebie dynamic scarf from ShareCG. I've reduced it to the simplest sequence with the fewest variable elements possible (which is why I'm not posing her, and why I'm using default settings for everything). rosemaryr has confirmed that she see's the same,so it's not just me.

For this test you need Victoria 4.2 and the 'Scarf 1' from Rosemaryr's 'Poser - V4 Peasants' Headscarves' at ShareCG http://www.sharecg.com/v/71365/relat...ts-Headscarves. I'm fairly sure it's not the prop itself, but haven't done any tests to confirm that assumption.

Open Poser Load V4.2 Select frame 30 and move V4's Body 12" to her left (i.e set xTran = 12.0, assuming your display units are inches) Select frame 1 again Load the 'Scarf 1' prop Go to the cloth room Select 'New Simulation' and use default settings. Select 'Clothify' and select the 'Scarf 1' prop. Select 'Collide Against', 'Add/Remove', select the root node for Victoria 4, and use default settings. Select 'Calculate Simulation'. Observe the simulation run - two patches of the cloth near V4's left and right temples seem to remain in their starting positions while the rest of the scarf moves as it should.

After observing the results of the wayward temple vertices simulation, click Clear Simulation. Slide the timeline back to frame 1. Go back to the Pose Room and put a check in the 'Visible' checkbox for the 'eyeBrow' actor of V4 Return to the Cloth Room and click 'Calculate Simulation'. Observe the results - it behaves correctly now.

Click Clear Simulation. Slide the timeline back to frame 1. Go back to the Pose Room and uncheck the 'Visible' checkbox for the 'eyeBrow' actor of V4 Return to the Cloth Room and click 'Calculate Simulation'. Observe the results - we have wayward vertices again.

TIA, Pete (and rosemaryr)

Hi ! In the collide against box, select only the part who are in interaction with the prop aka head neck torso and collars, you can also uncheck the eyebrow.

I had the same exact problem yesterday. After the simulation the scarf was all over the place. I just edited the stray vertices out of the constrained group, resimulated and everything worked fine. I saved the scarf again and simulates correctly now.

Anthanasius: confirmed - unchecking the eyebrow in the 'collide against' gets round the problem.

seeker: that seems to be another way round the problem. I think I moved the stray vertices into the soft decorated group and that worked. I think rosemary tried moving them into the dynamic group and that worked. And I guess that putting them in the hard decorated group would work too?

So we have a couple of ways around the problem.

But why does this happen at all? In Poser 8+ the eyebrow actor, even if it's invisible, is moving with V4. So any vertices that are constrained to the eyebrow, even if it's invisible, should surely be moving with it - like they do in Poser 6.

As far as I know in the older posers the invisible objects were completely ignored in the cloth simulation. It's only the newer ones that allow invisible objects to be draped on.

Hi!

I have one or two commercial products in the marketplace with dynamic headpieces, and I have been running into this problem on both V4 and M4 while creating. Not only right next to the eybrows, but further up on the forehead.

Unchecking eyebrow collision doesn't always fix the problem for me. But simulating, and then putting the stray vertices back into the default dynamic group always seems to fix the problem without any visible loss of quality. I find resaving it like this to be the best way for a commercial product, because that way the end user hopefully doesn't have to do anything on their end.

I have done some extensive testing on M4, and there I found that the problem appears when the Hip actor is rotated in certain directions in the end pose. Weird, isn't it?

I have never had this problem with Dawn, V5 or V6 so it has something to do with how the earlier figures are made.

My own products have all been tested and fixed of course, but you never know, things can turn upp with odd poses that wold not happen otherwise, So it is good for everyone to know about the fixes!

Interesting. I've never observed this, but then I usually uncheck collisions rigorously, and haven't sim'd that much headgear. But I also notice wayward vertices and crumpling and jaggies in many sims and simply smooth them away with either the smoothing morph brush or the tighten fit as a matter of course. If I can prevent some of that by making a tiny alteration before the sim, then it's worth experimenting on. Thanks for the thread.

Frequency -- Yes, it's good to know about this specific bug, because I suppose I may come across it at some point. And, indeed, I've never had an issue with any of your products (except the issue of not owning them all, yet.) :)

Frequency: Regarding "Unchecking eyebrow collision doesn't always fix the problem for me" - that's most interesting. Are the vertices in question exhibiting exactly the same problem as I mentioned in the OP (i.e. NOT moving AT ALL with respect to their original position), or are they moving incorrectly (i.e. getting the 'jaggies' {I love that phrase - a perfect description!} or shooting off into the distance).

I've already started a separate thread about Wayward Vertices Shooting Off Into The Distance because there are at least two, maybe more, distinct problems that I've so far come across with dynamic cloth.

@3dcheapskate: I will have to go back and test this a bit more to provide an accurate answer. Good thing that you guys are bringing this up! :)

@moriador: Thank you for your custom so far! I have a few in the Grab Bag today that you might not own so if you do shop today you might get lucky. ;)

My apologies to 'lucky' DS users concerning Poser only Grab Bag items... not much to do about that. But then I am sure there are DS only items in the draw as well.

Just got round to trying the test with something completely independent - in Blender I created an isosphere, shrunk wrap that to V4's head with a small gap, deleted all except for a sort of rough skullcap shape, created two mat zones 'front' and 'back', exported as an OBJ, imported into Poser, set 'front' mat as 'constrained' group and 'back mat zone as 'dynamic' group and ran the same test. Same results - with V4 eyebrow invisible by default I get stray vertices; if I make the V4 eyebrow invisible there's no stray vertices. Here's a screenshot comparing V4 initial and final position when I get the stray vertices, just to confirm that the stray vertices have not moved at all from their initial positions.

clotheyebrows.jpg

Also if I uncheck V4's eyebrow in the 'collide against' setting I get no stray vertices, regardless of whether the eyebrow is visible or not. So that's probably the most sensible solution - advise the end user to ensure that they UNcheck the V4 eyebrow in the 'collide against' settings.

P.S. seeker - my apologies, I omitted to reply to your comment that "As far as I know in the older posers the invisible objects were completely ignored in the cloth simulation. It's only the newer ones that allow invisible objects to be draped on." That could indeed explain why Poser 6 doesn't have the problem ! :)