Grow - Shortest Path spline overlap
#1
I have been testing the shortest path option and using the same settings in your facebook video, it works but i always end up with loads and loads of overlapping splines. this is killing my render times and i don't know how to get rid of them.


Attached Files Thumbnail(s)
       
  Reply
#2
Don’t send anything out of the operator and the paths won’t be duplicated (I believe this is noted in the docs). Alternatively, add a Spline Relax modifier to the resulting splines to reduce face overlap.
  Reply
#3
(09-05-2022, 10:57 PM)tyFlow Wrote: Don’t send anything out of the operator and the paths won’t be duplicated (I believe this is noted in the docs). Alternatively, add a Spline Relax modifier to the resulting splines to reduce face overlap.
That seems to have stopped the overlap, so thank you for that. But now i get lots of tapering going the wrong direction, some seem fine and others are thick at the ends. any idea? cheers


Attached Files Thumbnail(s)
   
  Reply
#4
I also notice you send a spline operator out of the grow operator. yet you say not to, is that right? trying to follow your video but getting mixed results
  Reply
#5
I didn't say not to...I was saying, if you don't send the particles out of the operator, it won't generate full paths for each particle...it'll merely set targets for particles. So you won't get the overlapping paths, you'll just get target assignments.



The algorithm is just using A* to traverse a graph towards the nearest target. So the radius setting generates neighbors for each particle (which connect to form the overall graph)...and the algorithm traverses neighbor-to-neighbor until the most optimal path towards the target object(s) is found. If you don't send particles out of the event, all the operator does is set targets on the particles. The target will point each particle to the next particle on its optimal, particle-to-particle path towards the target. If you do send particles out of the event, the operator will generate new particles for each particle's path. Since all paths traverse through particles, you'll get the overlapping...but by adding a Spline Relax modifier to splines generated by the flow, you'll sort of tug paths away from each other towards their endpoints, reducing the overlap and getting the effect in my original video.



As for the tapering when particles are not sent out....the tySpline object doesn't really know what direction any of the splines should be in...it just connects them together and picks a direction to taper in (by default, by sorting particles by ID). You can force a direction by sorting the surface-born particles by distance to the target object using the tyVertexOrder modifier.



Also I noticed the 'expand search if radius is too small' option isn't working properly in v1.011. That will be fixed in the next build...so for now you have to ensure that your supplied radius value is large enough so that particles have at least 1 neighbor within it.



Attached is a scene showing how to do the vertex ordering/tapering thing. One thing you'll notice when you open the file....a couple of the splines at the top left seem to have inverted tapering...but it's actually not inverted, the splines are just so long after welding that they stretch all the way around the sphere to the other side where the tapering ends at the exact opposite location on the sphere....I'm not actually sure how best to mitigate this at the moment...perhaps a new tapering mode could eventually be added to the tySplineMesher modifier - one that tells splines to taper towards/away from an object. I could see that being useful.

I've also enabled spline radius multiplication by length in the tySplineMesher modifier, so that tiny splines don't have a big radius which connects to the tapered ends of larger splines.


Attached Files
.max   shortestpath.max (Size: 828 KB / Downloads: 107)
  Reply
#6
(09-07-2022, 04:35 PM)tyFlow Wrote: I didn't say not to...I was saying, if you don't send the particles out of the operator, it won't generate full paths for each particle...it'll merely set targets for particles. So you won't get the overlapping paths, you'll just get target assignments.



The algorithm is just using A* to traverse a graph towards the nearest target. So the radius setting generates neighbors for each particle (which connect to form the overall graph)...and the algorithm traverses neighbor-to-neighbor until the most optimal path towards the target object(s) is found. If you don't send particles out of the event, all the operator does is set targets on the particles. The target will point each particle to the next particle on its optimal, particle-to-particle path towards the target. If you do send particles out of the event, the operator will generate new particles for each particle's path. Since all paths traverse through particles, you'll get the overlapping...but by adding a Spline Relax modifier to splines generated by the flow, you'll sort of tug paths away from each other towards their endpoints, reducing the overlap and getting the effect in my original video.



As for the tapering when particles are not sent out....the tySpline object doesn't really know what direction any of the splines should be in...it just connects them together and picks a direction to taper in (by default, by sorting particles by ID). You can force a direction by sorting the surface-born particles by distance to the target object using the tyVertexOrder modifier.



Also I noticed the 'expand search if radius is too small' option isn't working properly in v1.011. That will be fixed in the next build...so for now you have to ensure that your supplied radius value is large enough so that particles have at least 1 neighbor within it.



Attached is a scene showing how to do the vertex ordering/tapering thing. One thing you'll notice when you open the file....a couple of the splines at the top left seem to have inverted tapering...but it's actually not inverted, the splines are just so long after welding that they stretch all the way around the sphere to the other side where the tapering ends at the exact opposite location on the sphere....I'm not actually sure how best to mitigate this at the moment...perhaps a new tapering mode could eventually be added to the tySplineMesher modifier - one that tells splines to taper towards/away from an object. I could see that being useful.

I've also enabled spline radius multiplication by length in the tySplineMesher modifier, so that tiny splines don't have a big radius which connects to the tapered ends of larger splines.

Thank you for this really detailed explanation. really helps understand what's going on. I believe this should fix my problem. Thanks for your time!
  Reply


Forum Jump: