Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
for the 4x4 primitive plane, 5 rows of vertices , each row is 5-vertices long
in the case of the 64x64 cylinder / tube it's 65 rings, each ring is made of 64 vertices
----
it's those rows and those rings that will be acting as rubber bands pressed against the wrapped character
the bodycon dress for Aiko3 was made that way
Okay, that makes sense.
And that outfit looks cute too.
for the 4x4 primitive plane, 5 rows of vertices , each row is 5-vertices long
in the case of the 64x64 cylinder / tube it's 65 rings, each ring is made of 64 vertices
----
it's those rows and those rings that will be acting as rubber bands pressed against the wrapped character
the bodycon dress for Aiko3 was made that way
sweet - did you make that - using this ?
i made the initial dress shell using a script like that yes
i also re-generated the dress for the different Aiko3 morphs
the presently published script only pushes the dress onto the body
but the next version pulls it back as if it was elastic fabric
the part of the program that analyses the tube or sheet of cloth is written
so you'll be able to use your own sheet or tubes, not just standardized ones issued by me
So we couldn't use any old mesh, before? That's what I did wrong!
:P
actually this version A allowed the use of any mesh
example of things that could go wrong
- the mcjCollider plugin is not installed
- the mcjCollider node is not installed properly : to collide against a figure, select the figure's root node before creating the mcjCollider
- if you load a scene containing a saved mcjCollider, the collider is no longer operational -- delete the mcjCollider node create a new one
- the tube exceeds the collision area, so there's no collisions a all for one or more rings of the tube
- the tube's "normals" ( which tell us what is the inside of the tube and what is the outside ) are inside-out : use the checkbox titled
also, with this version, if you attempt to wrap 2 legs for example, the cloth between the legs will most likely not be draped like a skirt.
this version of the script is better suited to shrink tubes against 1 leg, 1 arm, a torso, a neck, a head, it's not suited to make skirts
We appreciate everybody being thoughtful about this topic and carefully considering whether this is a violation of the DAZ EULA.
Just to clarify.... this is clearly a "derived" work. The question is not whether the topology of the original figure is used... there is in this case a new mesh.. the Intellectual Property that is being derived from is the shape of the original figure.
With that said, it is understood that almost ALL clothing made for a figure necessarily uses the shape. So using the shape is not necessarily against the EULA because there is a clause in the EULA that allows it. However, there are some caveats.
The applicable part of the Eula is:
Terms of Use. User may (i) access, use, copy and modify the Content in the creation and presentation of animations and renderings, and (ii) incorporate two dimensional images (including two dimensional images that simulate motion of three dimensional objects) derived from the Content in other works and publish, market, distribute, transfer, sell or sublicense such combined works; provided that User may not in any case: (a) separately publish, market, distribute, transfer, sell or sublicense any Content or any part thereof; or (b) publish, market, distribute, transfer, sell or sublicense renderings, animations, software applications, data or any other product from which any Content, or any part thereof, or any substantially similar version of the Content can be separately exported, or extracted into any re-distributable form or format. Subject to the foregoing limitations, and the rights, if any, of third parties in or to the objects represented by the Content, User may copy, distribute, and/or sell User’s animations and 2-D renderings derived from the Content. All other rights with respect to the Content and their use are reserved by DAZ and its PAs.
Notwithstanding the foregoing, DAZ wishes to encourage user expansion of the catalog of Content available to users. Therefore, User may also access, use, copy, and modify the Content stored on such computers in the creation of one or more derived or additional works provided that:
any derived or additional works are designed to require or encourage the use of Content available through the online DAZ store either by (i) requiring the use of such Content to function, or (ii) allowing only limited function when not used in conjunction with Content from the online DAZ store; and
upon receipt of a written request from DAZ, User will immediately cease any and all distribution of the derived works User has created from the Content licensed from DAZ, if DAZ has determined, at its sole discretion, that (i) the derived work is substantially similar to or is a clone of existing Content; or (ii) the derived work fails to require the use of Content available through the online DAZ store.
So the bottom line is that whether someone were to wrap the figure programmatically or by placing and adjusting the poly's manually the resulting work is by definition a "derived" work because it must necessarily conform to the original shape. That is not necessarily bad. DAZ encourages that because it fosters the sale of the original figure AND if it is sold on the DAZ store, DAZ AND the PA benefit through the sale of the content to the customer.
DAZ does reserve the right to require the cessation of distribution if it determines "at its sole discretion" that it does not meet the requirements allowed for derivative works.
In summary:
It IS a derivative work
It IS allowed (if it meets applicable requirements)
The tool used to create the mesh is not in question and does not fall under the EULA because the EULA would only apply to the resultant derivative mesh/figure.
Hope that helps.
thanks i added a note pointing to this post in the thread's top post
actually this version A allowed the use of any mesh
example of things that could go wrong
... edit ...
if you attempt to wrap 2 legs for example, the cloth between the legs will most likely not be draped like a skirt.
I also had been trying the script with my own mesh ... and I love that description, "politically well put". hehehe ....
as you may know, the mcjCollider can be applied to more than 1 object
so probably ( not tested ) one could do things like wrap something on top of ( character + underwear )
figure 1 - ponder ponder ponder :)
for the cube shape i guess there's not enough information to detemine what is a face and what is a hole
so i'll either outlaw cube-tubes
or treat them separately ... pick the first edge owned by 2 faces
---
figure 2 : when i convert the face-based mesh into a network map, i also count the number of faces each vertex is implicated in
oops i think that's not it yet ... uh .... maybe it is ... yeah it is ( it's not the number of caces a vertex is implicated in, it's the number of faces a network synapse is implicated in ( ok it's not a synapse it's a link to another vertex )
Nice Nice Nice!! :-)
Thanks again, as usual you provide very great tools to help enhance DAZ Studio. Thanks for sharing and continue on your quest to making the community a vibrant place to visit.
thinking about releasing a version ( maybe beta ) before the day ends
note that the version with "spandex" effect will only accept standard tubes and planes
by standard i mean a tube made of any number of rings of any length, but all rings are the same length
in the case of planes, all columns and all rows have the same length
as long as these rules are respected the tubes and planes can have any weird shape
--
figure 1 hyperstrappy shoes made with the help of mcjShrinkWrapB
figure 2 the hyperstrappy shoes are not really complete - also shown here the Blender Cycles BSDF Anisotropic shader on the pole
figure3 interpolating
figure 4 - the portion of the program that repopulates a decimated ring ( i.e. a ring from which were removed vertices because the mcjCollider could not collide the to-be-wrapped object )
figure 5 - the shrink phase now can interpolate positions of vertices when the mcjCollider misses the subjects
Oh this is getting better and better ... looking forward to giving it a whirl! :-)
thanks for your patience Patience :)
i thought i could release it today, i made progress but it's not really ready
well there's still a little chance i'll post a text version tonight ! :)
--
figure 1 : case when the shrink tube exceds the object to be wrapped, the tube gets tied at the center of the tube ring
fig 2 : the new shrink ( does not include the convex-hull processing yet )
fig 3 : for non-standard shrinkable meshes - dangling vertices repositionned based on nearest network neighbor
fig 4 - for standard shrink tubes, interpolating dangling vertices based on neighboring vertices on the ring
Oh not to rush ... just when it's ready, I look forward to trying it out.
shrink wrapping was somewhat improved for non-standard tubes
but still, getting good results means building custom tubes that are basically pre-shrunk
so i'm thinking about ways to automatically pre-shrink tubes and/or make the mcjCollider use more 'intelligent'
--
an example of an issue: an mcjCollider ray, meant to shrink a tube around the toes misses the target, shoots between toes and the collision happens on Aiko5's hips
Good progress. IF anyone can figure this out it's you, that's for sure! :-)
This would be caused by the normals of the tube/shrinkwrap/quicksuit not lining up perpendicular to the targeted mesh. How about a depth-to-mesh dial, such that if the collider does not find an appropriate shrink-target within , the wrap is shrunk only to and stops there? Or alternately (not mutually exclusively), the script checks in a 30-45º cone from the initial ray direction when it misses at and collides toward the nearest eligible mesh within range. If none is found, it then shrinks to the on the original azimuth, and carries on to the next vertex.
Then again, this might be so time-consuming that it would be more efficient as a plug-in expanded from the mcjCollider algorithm....
for now the solution which didn't work too bad , goes like this:
after shrinking vertices that could be positioned using collisions, ( lets call them glued )
the dangling vertices are moved to the location of the nearest glued vertex
---
but that's a post-processing solution,
a pre-processing solution could detect roughly the bounds of the wrapped object, then shoot the collider rays in the center of that area, instead of shooting them perpendicular to the surface of the wrapper - or they could be shooting toward the center of the wrapper ring
( standard tubes being tubes made of a collection of equal-vertex-count rings )
i'll probably give the option of using the default method which works fine most times, and the other slower methods for tricky cases
ah ha - i was using cheap single-face-based normals ... and it degrades the results so i'll fix that pronto
nah ... they are quality normals ... i think
so i have to find another fix
---
maybe this -- when the collider misses the target completely, aim at the same facet as the nearest neighbor which had a successful shot
I guess there is no way to put some sort of a collision script in there to keep things from overlapping like that??
if we're dealing with a "standard" tube, ( one made of equal-length rings )
and the "spandex" ( convex hull ) effect is used, then the overlaps/folds will be taken out
---
another way would be to direct all collider rays at the center of the shrink ring, this way we avoid (most?) folds
---
Figure 1 -- i implemented the "centroid" method, all the collider rays go from the periphery of the shrinkable rings toward the center of the ring
, which is what you'd get with a perfectly circular tube. We don't get any folds/overlaps, the only drawback is we cant use the shape of the tube to influence the placement of the vertices.
Figure 2 - using a more detailed shrink tube and a displacement map, 3Delight render
My question to you at this point of your brilliance is...
Can you make a script (that after you take 2 tubes for the arms, 2 tubes for the legs and one tube for the torso and one tube for the neck and use your script on them) can pull in and align and weld the points or vertices to make one solid bodysuit??
well i could but it's faster to do it "manually" i mean for me it would be :)
think is i want to find time to make new Youtube Videos, like my North-By-Northwest in the Bobverse project which gathers dust since 2008
in some cases, collider rays would shoot right through the cracks between faces of the object being shrinkwrapped
for example when wrapping a 8x8 xylinder around an 8x8 cylinder
imcjShrinkWrapB will shoot a second collider ray mis-aligned by a tiny angle like 0.001 degrees
that's enough to take care of the issue
maybe someday this will be incorporated in mcjColleder
shrink wrapping test using a primitive-plane
looks a bit spiderman'y but don't worry Amy wasn't harmed nor scared
---
one issue i may address is: the script pushes the cloth onto the figure, then pulls it back toward the location it was "thrown from"
but in many cases it would be better to pull it away perpendicular to the surface of the figure/object being wrapped
It's too bad you can't get the verts to even themselves out even if it pulls the squares edges up and inwards, esp with that sort of position.
the next step, the big new feature -- convex-hull , which is like a 2D spandex will do something like that