I think smoothing is a good idea, but what you really want is not volume preservation, but coverage preservation. By that I mean the only important bit is not to create any new pokethroughs when smoothing. So one possible idea would be to check after each smoothing step whether any vertex has wandered inside the original convex hull for its ring, and if so, push it out again, probably along its normal or something.

That said, if you only need a small number of smoothing steps, volume preservation might come close enough, and is certainly easier to implement.

Just some unorganized thoughts of mine. Don't put too much weight on them.

Quote - I think smoothing is a good idea, but what you really want is not volume preservation, but coverage preservation. By that I mean the only important bit is not to create any new pokethroughs when smoothing. So one possible idea would be to check after each smoothing step whether any vertex has wandered inside the original convex hull for its ring, and if so, push it out again, probably along its normal or something.

That said, if you only need a small number of smoothing steps, volume preservation might come close enough, and is certainly easier to implement.

Just some unorganized thoughts of mine. Don't put too much weight on them.

Well, er.    When I say "volume preservation", I mean the "cheapie volume preservation" which I've applied in some of my earlier scripts.  Which actually comes closer to what you describe than actual, factual volume preservation, as I understand the idea.  :blushing:

Actually, if I restrict the smoothing process to sliding the vertices along the edges of the ring, the effort should hopefully help align the columns more effectively while preventing shrinkage.

Good input!  :thumbupboth:  Thanks, odf!

Quote -
Well, er.    When I say "volume preservation", I mean the "cheapie volume preservation" which I've applied in some of my earlier scripts.  Which actually comes closer to what you describe than actual, factual volume preservation, as I understand the idea.  :blushing:

Well, I guess I was thinking of an even more "cheapie" kind of volume preservation where one would just scale the result up after each smoothing step to compensate for the shrinkage. I should have remembered that you've already implemented much smarter smoothing methods before.

Quote - Well, I guess I was thinking of an even more "cheapie" kind of volume preservation where one would just scale the result up after each smoothing step to compensate for the shrinkage. I should have remembered that you've already implemented much smarter smoothing methods before.

Eh?    I think we're talking about the same basic thing, and I also get the sense that I may have offended with my last response.  My apologies.    What I've done before is move along the vertex normals by an amount determined by the distance the smoothed vertex has moved.  Are you suggesting actual scaling as in applying a scale matrix, or something?

It's a good idea.  :thumbupboth:  Thank you!  :laugh:

Quote - Are you suggesting actual scaling as in applying a scale matrix, or something?

No, I'm not suggesting that. I thought that's what you were planning to do, because I misunderstood what you were saying. Sorry about that! I think your idea is actually way better.

(And no offense taken whatsoever.)

Thats really cleaned up a couple of patches in the leg area. Excellent work Cage .

The head could perhaps be a bit better, there seems to be a slight bias toward the left. 

Excellent anyway. Good base for a cloth simulation.

Wow, that's a spectacular improvement. :thumbupboth:

Quote - Thats really cleaned up a couple of patches in the leg area. Excellent work Cage .

The head could perhaps be a bit better, there seems to be a slight bias toward the left. 

Excellent anyway. Good base for a cloth simulation.

Thank you.  :laugh:  I agree that it could still use some improvement, if that's possible.

The vertices for the rows are being re-ordered in a way that selects the pair of current row and next row vertices which will create a line which is the closest to the plane normal (relative vertical).  Apparently somewhere in the neck it's finding what it thinks is a better match in some area which doesn't help create a nice, straight line in the front.  You've got the bulges for the chin, nose, and ears running interference in the area, too.

I'll see if I can refine the results at all.

I've set up the smoothing to permit multiple passes, and that seems to be helping in the head and neck region, in my tests.

I think something that could really help would be setting the start location where the vertices will begin being placed around the contour of the convex hull.  If that can be controlled, then decent alignment can be established in a specific area of the mesh, say the front.  I have a couple of thoughts for this, but I haven't tested them yet.

Quote - Wow, that's a spectacular improvement.

The "coverage preservation" suggestion helps immensely.  The old smoothing process I was working on never returned results this good.  A very good idea, that!  :woot:

Quote - > Quote - Wow, that's a spectacular improvement.

The "coverage preservation" suggestion helps immensely.  The old smoothing process I was working on never returned results this good.  A very good idea, that!  :woot:

Awesome! Glad I could help.

Thats really good. You may be in a "diminishing returns" situation. Meaning it isnt worth the amount of work to make a slight improvement.  Those look much better than the first examples.

Quote - Thats really good. You may be in a "diminishing returns" situation. Meaning it isnt worth the amount of work to make a slight improvement.  Those look much better than the first examples.

I think you may be right.  The problems where small and large rings meet remain, so I'd like to find a way to fix that.  I have code which is inserting an extra row where sizes of neighboring rings vary greatly, but I've not yet tried inserting a new row from actual plane intersections.  That may or may not help fix the problem.

I think I can force the initial vertex placement along the hull contour to start in a specific part of the skin mesh.  This column would then be the straightest one in most situations, and it seems like it might be good to try to place that in the front and center of the skin.  The trouble being that this will also end up being the location of the UV seam.  So I thought I should ask for opinions on the idea.  Is it worth having straighter vertex columns in the front if the UV seam ends up there, as well?

Is it worth having straighter vertex columns in the front if the UV seam ends up there, as well?

My reaction is OMG NO !!!!!  but I am a bad painter of textures and I prefer no seams at all, or hidden at the back if there has to be one .  

I think you should consider making this a commercial product . 

I think it would be ideal if you could put a straight vertex column in the front center with an u-value of 0.5, while still keeping the UV seam at the back. Even if there's a seam it shouldn't be too bad, though, because it would (I assume) be at a constant u-value of 0 on one side and 1 on the other, making it very easy to actually paint textures as if the seam were at 0.5 and then swapping the left and right half of the texture map.

A maybe even better idea would be to have one fixed column of vertices at the front center and one at the back center and place the rest of the vertices in between those.

Quote - I think it would be ideal if you could put a straight vertex column in the front center with an u-value of 0.5, while still keeping the UV seam at the back. Even if there's a seam it shouldn't be too bad, though, because it would (I assume) be at a constant u-value of 0 on one side and 1 on the other, making it very easy to actually paint textures as if the seam were at 0.5 and then swapping the left and right half of the texture map.

A maybe even better idea would be to have one fixed column of vertices at the front center and one at the back center and place the rest of the vertices in between those.

That's a brilliant idea!  :woot:  If I can place forced vertex positions, then having them at front and back could help reduce any twisting problems.  :thumbupboth:

And that means the UV seam could just be placed at the back, so the front would end up at 0.5 u anyway.  Ha!  Wonderful!

This is what I like about open development projects.  I'd never think of that on my own.  Great idea!

If these controlled positions can be established, I think that might remove the need for the vertex reordering, which is slow.

Quote - Is it worth having straighter vertex columns in the front if the UV seam ends up there, as well?

My reaction is OMG NO !!!!!  but I am a bad painter of textures and I prefer no seams at all, or hidden at the back if there has to be one .  

I think you should consider making this a commercial product . 

I think odf had a better idea, so there wouldn't be any need to place the UV seam at the front.  Assuming I can force the vertex positions, and the results are as hoped, they can go at  the back.

I'm not sure a commercial product is really what I'm all about.  First, several versions have already been posted on the forum, meaning that the code is already free for anyone to use.  Any effort to restrict it would be difficult because of that.  Second, I'd make a really crummy merchant.  :lol:  I'm too flighty, shifting from one project or idea to another and losing all interest in what has gone before.  I've also disappeared from the community for months at a time, when working on other things.  And I tend to struggle with writing clear instructions.  I'd really hate dealing with a merchant like me.  :lol: Third, a free product honors everyone who gives and has given so freely of their own creations.  I remember the Poser community before there were any marketplaces or commercial products, outside of a limited range of DAZ items.  I've made such use of Antonia, Ockham's countless and wonderful scripts, and any number of great Free Stuff items that it just seems nice to try to give back a little bit, in the way that I'm able.  Finally, there's some borrowed code at the core of these scripts, most notably the convex hull code.  I wouldn't feel right about trying to sell that.

But thank you for thinking highly enough of the script to suggest the idea!  :thumbupboth:

Further tests also reveal some shortcomings of the current smoothing process.  It seems that vertices which are more off-center may have a tendency to fail the coverage preservation part of the process.  (See the attached image.)  This seems to be because I use the ring centers as part of that preservation, so I need a more robust approach.

So I'll be working on inserting the extra rows where needed, trying to control the seams, as discussed above, and trying to improve the smoothing.  Then I'll start on the caps for the geometry.  I'll try to fix the smoothing first, then release the current form of the script so you can all try it out.

  You seem to have made great strides with the wrapper script.  I hope you can implement odf's idea of one fixed column of vertices at the front center and one at  the back center.

Quote -   You seem to have made great strides with the wrapper script.  I hope you can implement odf's idea of one fixed column of vertices at the front center and one at  the back center.

Thanks, Les.  :laugh:  I hope I can make it work, too.  If the mesh can be adequately cleaned up for the skinner script, I think the basic process can be adapted to extrude along a user-defined path, rather than working from an existing geometry.  I need to think the idea through, mainly because it seems like it would require a moderately complex GUI, to be able to get all of the necessary extrusion path information from 2D inputs.  But the idea is feasible and if the results here can be cleaned up, it might be worth exploring.

Looking at the poke-through shown in the last image I posted, above, it's evident that most of this represents places where the vertices have deviated from important hull intersection points, allowing some vertices of the underlying geometry to poke through between polygons.  It looks like the hull path contours are being retained through the smoothing, except in a couple of cases where a hard edge has been lost or moved to an incorrect location by smoothing.  Which makes the problem a bit trickier to try to fix.  :sad:  I'll have to tinker a bot, and see what comes of it.  

I've deactivated the vertex-reordering, after having tested the smoothing without it.  The "bias" in the neck and head disappears if the reordering is off.  The smoothing alone seems to do a very good job of cleaning up the mesh.  The twisted polygons which have been a problem since the start are being fixed by the smoothing, so the results are pretty good.  Better than expected.

Next I'll be trying to force the seam positioning, as discussed above.

As can be seen, increasing the skin resolution can help prevent the polygon poke-through even more.  The test on the left has 30 columns and 100 rows.  the one on the right has 50 columns and 200 rows.

Note that this will currently only work if the plane finds no gaps in the geometries it's scanning.  If you have an open space between geometries, where the plane will find no intersection for any  number of row scans, one or more rows will be skipped and the vertex counts won't be the same.  I'll see if I can fix that in upcoming versions.

best regards,

Bopper.

Quote - This is really an amazing script. I managed to make a dynamic strapless dress within minuts. 
 What I was wondering: can the box be tapered?

The bounding box which is placed to select geometry to scan?

Apparently a taper dial can be added to a prop, IIRC.  Just tapering the box wouldn't have any particular effect on the behavior of the script, however.  The plane would have to be scaled incrementally to duplicate the tapering of the box.

What effect were you hoping to achieve, with any tapering?

Perhaps I have to made a visual, to explain what I mean. To make this dress, I had to rotate the box a little around the x-axis, to make a shape that I liked. But what I really wanted was a box that could be  shorter on the backside then on the front.( to make this dress at least).
To make a suggestion: I don't know how hard it is to realise, but it would be nice if the scanlines could follow a path, perhaps a box with some bending morphs.
But perhaps, I'm asking the impossible, what I see really pleases me: you can use these props as a dynamic object, but you can also use them as a base to use in other modeling programs to make  more complex clothing.

best regards,

Bopper.

That's not impossible at all.  There's some question in my mind about how to allow the user to define a path properly, but I've already been thinking about a script variant which might follow a user-defined path, although not exactly in the way you suggest. 

I'll have to think about the idea, but I like it.  :thumbupboth:  The main trouble is defining the path.  Since Poser 8 and Poser Pro 2010 have a bug which interferes with certain Tkinter GUI arrangements, some new approach will be needed to permit a path to be defined.  I'll start thinking about different possibilities.

This is a pretty fantastic script Cage. Great for clothes. Don't understand the technicalities of writing a script like this but I'm glad you do. :biggrin:  Thanks for this.

cheers.

Quote - ... it's easy to use this script to quickly create all sorts of odd entanglements.

I just love odd entanglements. Thanks for this.

Sorry I'm a bit late replying, but Eyjafjallajökull prolonged my holiday, and you were inconsiderate enough to post this just after I left - otherwise I could have played with it while I was away. :)

Quote - This is a pretty fantastic script Cage. Great for clothes. Don't understand the technicalities of writing a script like this but I'm glad you do.   Thanks for this.

Thank you.  :laugh:  I'm not always sure I do understand the technicalities as well as all that, but so far I seem to be able to figure out enough to keep going.  :lol:

Quote - I just love odd entanglements. Thanks for this.

Sorry I'm a bit late replying, but Eyjafjallajökull prolonged my holiday, and you were inconsiderate enough to post this just after I left - otherwise I could have played with it while I was away. :)

The original loop script is almost getting lost in the shuffle, as the thread has turned toward development issues with derivative scripts.  To make it easier to always be able to find the current versions of all three scripts with which the thread has been dealing (loop script, chain script, and skinner script), I've put up a new web page for them, linked in my forum signature. 

Mr. Looper and Friends

I hope these scrips can be of some use to you.  :laugh:

That would be volcanic interference with a traveling vacation?  Yeeps.  :scared:  Sorry about the date of posting for the thread.  It just sort of worked out that way.  :lol:

Quote - The original loop script is almost getting lost in the shuffle, as the thread has turned toward development issues with derivative scripts.  To make it easier to always be able to find the current versions of all three scripts with which the thread has been dealing (loop script, chain script, and skinner script), I've put up a new web page for them, linked in my forum signature.

Good idea. Whilst I appreciate that the skinner is a very clever thing, my own interest at the moment is more with the chain maker and looper. Any progress on a script to pose the chain?

Quote - The original loop script is almost getting lost in the shuffle, as the thread has turned toward development issues with derivative scripts.

No kidding. It is a Cage thread, after all - and please don't take that as any form of criticism, quite the opposite. I love this stuff you're coming out with.

I roll my eyes when I see someone post to a thread they clearly haven't read, and here I am doing it myself. I read page 1 - ooh, looper script, want it - then skipped to the last page to register my thanks. I will endeavour to read the rest of the thread in due course. Until then:

:rolleyes: :rolleyes: :rolleyes:

Quote - I hope these scrips can be of some use to you.

I'm sure they will. A long time ago I actually requested something more-or-less identical to Mr. Looper on another forum, to which I am not allowed to link. :) Mr. Skinner looks interesting too, even though his name is reminiscent of a low-rent serial killer. :D

Quote - Sorry about the date of posting for the thread. It just sort of worked out that way.

Oh sure - you knew I was kidding, right? :lol:

The original looper script is heaven sent to the bondage peoples. 

The thread hasnt actually wandered very far , it just went from looper , to chains , to skinning
with some trips down catenery vs parabola  and "how the bleep do I do that in python" and a "what have bleep bleep done to python NOW! " 

I am playing with the skinner script and textures to try goo covered and webs. Giant spiders and man-eating plants.

Quote - Good idea. Whilst I appreciate that the skinner is a very clever thing, my own interest at the moment is more with the chain maker and looper. Any progress on a script to pose the chain?

I suppose I could clean up what I have and post it, but a Poser Python bug was discovered in versions 8+, which ruins the approach I'd hoped to use to be able to set the start and end points for the chain.  I have an example which will pose the chain, assuming the script will work in your version of Poser, but the posing won't be correct for the given start and end points.  Once the bug was discovered, I shifted to trying to clean up the skinning script before possibly getting lost in a long effort to resolve (what are still, for me) complex math issues, as well as GUI problems, with the chain-posing script.

I've not given up on the idea, and I still hope to be able to add it to the script set.  :laugh:

Quote - No kidding. It is a Cage thread, after all - and please don't take that as any form of criticism, quite the opposite. I love this stuff you're coming out with.

I roll my eyes when I see someone post to a thread they clearly haven't read, and here I am doing it myself. I read page 1 - ooh, looper script, want it - then skipped to the last page to register my thanks. I will endeavour to read the rest of the thread in due course. Until then:

...

I'm sure they will. A long time ago I actually requested something more-or-less identical to Mr. Looper on another forum, to which I am not allowed to link. :) Mr. Skinner looks interesting too, even though his name is reminiscent of a low-rent serial killer. :D
...

Oh sure - you knew I was kidding, right?

I do tend to wander a bit, from one idea to the next, as I try to explore all the possibilities which occur to me.    And others have suggestions, which often lead in wonderful and unexpected directions.  :thumbupboth:

I'm glad you told me why you're rolling your eyes, because that smiley tends to worry me.  :lol:  No problems, with coming into the thread with only partial information.  The thread wanders and I'm not sure how many people (possibly not myself) understand where it's been and/or where it's going.  :lol:  That's okay.  The Looper script, itself, changed a great deal from the version on page one, however.  Perhaps most notably, recent versions can now intersect effectively with edges, and I believe the new approach is faster than the initial one.

I had been requesting something like the loop script for two or three years, myself.  I know I bugged at least three people about making one.  :lol:  It's a relief to actually have it now, although I haven't used it much yet, myself.

The loop script was almost named "Mr. Roper".  :blink:  That would have been a Three's Company reference, you see.  "Mr. Looper" is a Sesame Street reference, from the days when the Mr. Hooper character was part of the cast.  "Mr. Skinner" is a Simpsons reference.  Sadly, I couldn't come up with a goofy TV name for the chain script.  :lol:  Suggestions are welcome.

Quote - The original looper script is heaven sent to the bondage peoples. 

The thread hasnt actually wandered very far , it just went from looper , to chains , to skinning
with some trips down catenery vs parabola  and "how the bleep do I do that in python" and a "what have bleep bleep done to python NOW! " 

I am playing with the skinner script and textures to try goo covered and webs. Giant spiders and man-eating plants.

Well, I mean, I've veered away from the etish-fay, 'Rotica-oriented stuff myself, as using Poser, for me, has increasingly become a matter of struggling with bad joints (prior to Antonia and - can't wait - Brad) and developing PPy scripts.  But.  The implementation of the loop script that you cite was part of my initial thought on the matter, way back when, as revealed by how much I struggled to create UV mapping which would work for the rope textures which shipped with Have's (wonderful and, sadly, withdrawn) Eroko and Tuyuko figures.  :lol:  :blushing:

I guess a Cage thread has inevitable digressions into "how the bleep do I do that in python" and "what have bleep bleep done to python NOW! " :lol:  Par for the course.

Quote - Whilst I appreciate that the skinner is a very clever thing, my own interest at the moment is more with the chain maker and looper.

Missed my chance to edit the earlier post, when I realized I'd failed to reply to this part.  (Sorry, Les.  )

Do you have any further ideas or suggestions for the loop and chain scripts?  There are some internal changes I can make to the loop script, but aside from that I don't have any immediate development ideas for either script.  It might be good for me to be able to think about something other than re-organizing the skin vertices, now and then.  :lol:

I've managed to force the vertex placement for each row to start at the back of the ring, as discussed previously, but currently the results aren't very promising.  It works, it places the UV seam at the back, rather than the side, but it actually creates more alignment problems than it solves, so far, and even the smoothed results are worse than those in the current version.  So I need to keep tinkering with the idea and see if I can refine it somehow, before releasing it.

Just a quick heads up for users of the chain maker. D3D has a handy "Chain-Pose" py script.

Quote - Just a quick heads up for users of the chain maker. D3D has a handy "Chain-Pose" py script.

Ooh!  Good find, Les!  :woot:  I didn't even know that script existed.  Man, I'm out of touch.  :lol:

Sorry to have gone silent.  I started looking into possible alternate mesh-structuring methods for the skinning script, and got a bit lost.  I didn't quite get what I wanted, alas.

Instead, I ended up with metaballs.  :lol:

I'll clean up and organize the script a bit, then post it, hopefully later today.

Whoa! Now I'm interested. Somebody wanted a shower prop. Your metaballs look like water droplets. If we can create multiple streams of these from a shower head (or whatever) and have them arc down that would be cool. If they can hit a figure and be blocked (like a shadow) or bounced (like a reflection) even cooler.

That looks pretty cool Cage.  Could be used for various liquids, or rocks.  

Quote - Whoa! Now I'm interested. Somebody wanted a shower prop. Your metaballs look like water droplets. If we can create multiple streams of these from a shower head (or whatever) and have them arc down that would be cool. If they can hit a figure and be blocked (like a shadow) or bounced (like a reflection) even cooler.

Well, I have been operating from the idea of trying to reproduce the effect of the old Weird Juice Drops freebie script.  If that was going to be updated, it probably would have happened some time since the release of Poser 7, when it broke.  The Weird Juice package apparently extended to handling fluid dynamics to some extent.

I have no idea how to proceed, with fluid dynamics, however.  The physics of it is way beyond me.  :lol:  I could probably handle finding the locations for the metaball influence points and moving them around, but I'm not sure how to do the dynamics.

There's also the problem of animating a metaball surface.  Poser doesn't allow geometries to be updated on a per-frame basis, minus any awkward tricks like geometry-switching (which I'm not sure PoserPython could set up).  So even if the dynamics could be worked out, I have no idea how the metaball surface could be animated. 

I'm not sure whether the Weird Juice package had a workaround of some kind for the Poser geometry limitation.

If anyone has any pointers on fluid dynamics, I'll see what can be worked out, anyway.

Quote - That looks pretty cool Cage.  Could be used for various liquids, or rocks.  

Thanks, phantom3d!  :laugh:

Rocks will be a good idea, if I can clean up the UV mapping a bit.  My spherical mapping attempt isn't quite what I'd like it to be.  :lol:  Right now I suspect the rock surface wouldn't texture very well.  :sad:

Attached Link: http://www.renderosity.com/mod/forumpro/showthread.php?message_id=2622055&ebot_calc_page#message_2622055

Oh yes it does!

Well at least the internal renderer does, I don't know if the external version of Firefly honours the Python callback required to do the geometry change (I have a strong suspicion that it doesn't, but haven't tried it).

To get a taste of the issues involved with fluid dynamics, play with the stuff in Blender.

Well, I went silent too, but that was because I was busy playing with Mr. Looper. :-) And I don't have nearly as much to show for my silence as you do for yours.

However I did think of a possible application for the loop making script - or more likely a loop-making script. I'll be in touch when I've had a bit more of a think about it.