I suspected the same. To be more exact, I suspected that Gemini made this assumption based on the “Flowify Without Cuts” algorithm. Can this be the reason?
Provided that the geometry is deforming only in a “uniform” direction like the handrail in this example, or the walls in the thread that you linked.
In cases like the more “freeform” shapes that I showed in the video, it would have failed miserably without the “horizontal” loops.
Flowify is 100% right. Nobody in their right mind likes ngons with holes.
Thank you so much for your plugin.
For the kind of work that I do is a life-saver.
Completely off topic reply to a completely off topic comment
It’s just a tool.
In this case, used to evaluate 18 ruby files in about 18 seconds.
Apparently it went close enough, if the author himself only found a minimal discrepancy in the analysis (which by the way is correct in case of the flowify-no-cuts mode, which doesn’t slice the model).
Probably, if I’d gave the appropriate “context” in the prompt instead of just pasting the code and say “compare geometry handlig complexity in those 2 sketchup plugins”, it would have been 110% correct.
Don’t get me wrong, I’m by no means an AI enthusiast, I’m just trying to be objective.
I don’t know too much for Gemini (although I am really impressed by the politeness of these AI technology and their relevance in most cases).
As said, bending along a curve could be a little bit faster as in the example below, which takes around 70 s. Most of the time is taken by the method transform_by_vectorwhich takes 80% of the time.
There is a faster method, based on constructing all faces (via an Entity Builder). With the same railing and curve, it takes 23 s. However, you have to smooth the model manually at the end (doing it by API takes a long time, as there is no bulk method equivalent to the Soften edges tray panel).
That’s amazing. You should do the Sketchup version of 3dsMax “Path deform” modifier (maybe based on your real time preview such as Curviloft or FredoCorner)
As long as it preserves existing pre-triangulated quads, I would be 200% fine whit that.
Personally I already use 99% of the times Flowify/FredoScale without cuts/slicing.
I just want to deform stuff.
Such algorithm should be even faster isn’it?
Interesting results. I realize now that Flowify uses an inefficient intersect method (contrary to Gemini’s flattering analysis ) for these kinds of problems. At the time of its creation we were doing a lot of intersections where both intersection groups where very large (>10000 faces). Sketchup is intersecting in N^2, trying every face in one group against every face in the other which becomes incredibly slow as the number of faces grows. In this case you can speed up intersect enormously by finding intersecting pairs in a space hash and then intersect these pairs individually. So - this is what Flowify uses. However for slicing stuff only one of the intersection groups are complex (the railing) and the other is just a single face so the time complexity is N. In this case it’s much faster to let Sketchup handle the full intersection, the overhead of a space hash in Ruby becomes a drag. I guess this is reason your bender is dominated by transform_by_vectors and not intersect - your slicer is much more efficient that Flowify’s.
No illusion. Sketchup and the Ruby does not have this real-time capacity in general situations.
Well, softening and smoothing the edges is faster than I thought, around 1.5 seconds for the ~93.000 edges of the deformed railing, even if there is no bulk method equivalent to the Soften Edges Tray panel.
The bottleneck are still:
the intersections since you need to slice the object along the curve
the generation of the final geometry, whether via moving vertices or by recreating the full deformed geometry.
In the case of the railing example, it takes roughly 10 s for each step on my laptop.
And alternative methods in Ruby would be way longer….
In conclusion, difficult to beat 3dsMax Path Deform!
Actually, Flowify works in 3D, whereas bending along a curve is a 2D problem, requiring only intersection of mesh by planes, not by another mesh. Still, it takes time to cut the railing, even with a set of simple planes.
But, as you said, this is difficult to do better than the native method, except some hashing and caching.
So much intersting points raised from this conversation, is quite difficult to reply shortly to all of them!
As an avid user of your tools (and of course 3dsMax) for freeform modeling workflow, I’ll try to sumarize my thoughts on this as much as possible.
Of course path deformer (and 3dsMax itself) is meant to be way more interactive than Sketchup will ever be
and can do a lot more complex stuff
Path Deform paramethers and general logic are not only meant for realt time preview, but also (I would say mainly) for animation.
Not only it can deform and animate in real time really complex geometry, but also serves as a foundation for extremely complex animation rigs in which instead of animating every individual controller of the rig along a spline, you can strategically attach all the controllers in the rig to the raw geometry of a relatively simple mesh that you can then animate and deform along the spline, dragging and rotating the whole rig along it, exactly like I did in this example.
Final animation with full breakdown at this link AT THIS LINK
I’m not proposing anything like that, which definitely would be way beyond Sketchup interactivity capabilities and purpose.
What I’m talking about is just a preview mode similar to what you already use in Curviloft, FredoCorner, JointPushPull and such.. so that you can preview the final result on some sort of “ghost” preview geometry and adjust parameters such as path percentage, stretching, twisting, offset, whatever.. BEFORE committing the operation and creating actual geometry.
This would bypass the Sketchup geometry creation bottleneck altogether I guess. And would save tons of time to the user which would not have to wait forever while the final geometry is created multiple times until is happy with parameters.
I imagine that a similar preview mode could also be beneficial for Flowify.. say you want to move, rotate or scale the original geometry on the flat grid and preview some sort or ghost geoemetry on the target/curved surface before committing the geometry generation.
Please notice another key aspect that helps 3dsMax to keep Path Deform very responsive: there’s no slice happening whatsoever.
The “accuracy” of the result depends on the density of the orginal mesh (which is exactly what already happens in Flowify Whithout Cuts).
This is what I mean:
Althought the auto-slicing feature can be really powerful in case of objects such as the rail in the original example (and I use this kind of feature somethimes, both in Flowify and in FredoScale Bend/Twist tools) most of the time I don’t use it.
In more “advanced” models I never ever rely on the autoslicing, because it cause a complete mess in topology and texture mapping.
As long as mesh topology and UV mapping control is needed for complex modeling (and when I say complex I mean THIS complex), creating manually the subdivision needed for deformation and UV unwrapping is the key.
That’s why I always ask for the “quadface convention” to be preserved whenever possible (yes I’m the same guy who originally asked for quadface diagonals in the original Flowify plugin thread more than 10 years ago. That has to be mentioned as the faster user request satified in the whole history of software developent, I probably should have asked about UV preservation too ).
Althought I’m not a programmer, I recently began to mess with code using mainly Claude Sonnet and a bit of Gemini in order to create a few tools that are still missing in the whole SketchUp freeform/quads/subdivision/UV-mapping “ecosystem”.
A “golden rule” which I’ve found in years of quad modeling in Sketchup and which I’m trying to always follow, is to apply a preemptive triangulation using the opensource/MIT code from @tt_su Quadface Tools.
This allows to prevent Sketchup auto-folding, keep the mesh vertex-order stable in order to make further operation on mesh deformation, subdivisions and UV-mapping more reliable/predictable (and of course keep quads) as I explained more in detail HERE
Thats why as the very first step of all the script which I’m creating I’m appling (a slightly modified version in order to triangulate N-gons) of the code from Thomas “Triangulate” feature in QuadFace Tools. This not only allows to preserve quads, but also preserves the existing UVs from the orginal planar/not-triangulated face, which can then safely be cached and restored/reloaded after mesh deformation.
If you are interested in this method, I would be glad to invite both of you and of course also Thomas to “beta test” the plugin I’m creating, so that maybe you can see if this process can be improved and could also be beneficial/reused for your tools in order to keep quads and UVs always preserved across mesh deformations.
Of couse I believe that this converstion may be continued elsewhere, because we started from a basic user request, but then we diverged into some “slightly” more advanced topic.
The user duanekemp asked for it just one post after yours…I implemented UV-preservation later but never got around to release it. Another esoteric feature added was the ability to explicitly set normals which makes it possible to synch adjacent patches. Both features were used to make the planet below (which is a sphere with six sides).
Nevertheless, I may release a new version eventually. The fastest user request satisfied in the history of software development may be followed by the slowest…we’ll see. There is some work to be done cleaning up the code.
The f1-car in your link is mind blowing - may one ask why you use Sketchup for that?
Well.. I guess for the exact same reason why you create mind blowing highways wrapped around small wooded planets.. to have some fun and demonstrate that is perfectly possible
That kind of stuff is exactly what I was talking about in the video.. the more you add random slicing, the more that kind of problems arise (in particular with already hipoly geometry)
) for these kinds of problems. At the time of its creation we were doing a lot of intersections where both intersection groups where very large (>10000 faces). Sketchup is intersecting in N^2, trying every face in one group against every face in the other which becomes incredibly slow as the number of faces grows. In this case you can speed up intersect enormously by finding intersecting pairs in a space hash and then intersect these pairs individually. So - this is what Flowify uses. However for slicing stuff only one of the intersection groups are complex (the railing) and the other is just a single face so the time complexity is N. In this case it’s much faster to let Sketchup handle the full intersection, the overhead of a space hash in Ruby becomes a drag. I guess this is reason your bender is dominated by transform_by_vectors and not intersect - your slicer is much more efficient that Flowify’s.
