Say I have a complicated mesh (multiple curves, bulges, etc.) and I want to apply a UV grid across the surface equally. Is this possible? If not, and you have to apply a grid to individual mesh/surfaces how can one “link” the grids so they line up?
Two more questions if y’all would be so kind:
Can you simulate a fea anaylsis (material deformation as a function of pressure) and how can this be done? Can you do it through kangaroo/Bongo? Say you used a third party internet based platform, can you extract this information and input into grasshopper as a list of numbers or something along those lines?
Imagine a tissue [a tri/quad mesh] that falls into your mesh. Using K2 (a Physics Engine in fact) you can drape that to the target object (up to a point: avoid neg slope stuff etc etc). If this is OK with your goal (i.e. an one side result) … it’s easy. If on the other hand you want to wrap a solid object [mesh/brep] … well … that’s another animal (but you can approximate things [a quad mesh from a subdivided BBox mesh pulls to the object whilst is relaxed … etc etc] via a variety of ways none of them is very easy to explain with few words).
With regard real-life FEA … well … I would suggest to use some real-life MCAD app.
Okay, so projecting a rectangular uv grid is the same method, kind of? How would this differ? Whats the advantage of using a physics engine?
Leaving aside the negative slope(s) on the target object (that’s a big deal: imagine using a Grand Canyon type of topology) … projecting yields a very ugly result IF the object has decent slopes (like projecting something into Everest: big mesh edges on the areas with the big slope etc etc). A PE could deal with the mesh vertices (springs on edges, angles, even plastic anchors etc etc) in order to relax the mesh and get something that - more or less - has far far more “uniform” looks (“equal” edges/ face angles/etc within the limits of possible).
So if the “draped”/“wraped” mesh has some further usage … the more is relaxed (should I say “equalized” ?) the more you can do some rational things with that: for instance creating a W truss that engulfs the object etc etc.
That said any PE is kinda a loaded gun: there’s always the possibility to shoot your own feet if you don’t know what are you doing (in cases like this people always blame the gun).
Anyway here’s a demo on K2 drape using a rope instead of a surface in order to get the gist of the whole thing. The blue spheres are in fact doing the drape job: a force (-Z) combined with S-M collisions meaning that the target object MUST be dense and the spheres … er … hmm … big enough (or just right) :
Woah Cool! Still this looks like a nightmare. Another way I was think was this.
- Turn poly-surface into mesh
- Map mesh with a color map, with the colors corresponding to the slope of the surface.
- flatten the poly surface and populate it with points with the density of points roughly matching the corresponding slope color.
- Project points back onto surface.
Now here is a new question: Say I have a poly surface with a series of points on it and I want to create a rough approximation of a grid with the points, how would I do this? I e the UV boxes will never be perfect, but will always be rough Rhombus’s that approximate a gridlike network of curves. Can this be done?
In general the only impossible thing is to start my Panigale if it rains.
On the other thing: you are heading south (no girls, no Vodka) instead of north (plenty of both): instead of using the proper thing you are after the 100% wrong thing.
Anyway (in the Name of Bad Science) post a demo case and we’ll see what fruits may come out of that. Hurry because the C# just-for-fun-season ends the next-next w/e > Formula1 (forza Lewis) and MotoGP (forza Vale) start > adios amigos up to next November.
God, there has to be a way? I dont understand how people apply patterns accross polysurfaces? Is it just not done? Ugh!
Indeed there is: named Kangaroo2. Maybe this w/e I’ll do a demo: how to strangle an object with a mesh until death from asphyxia occurs (no mercy).
Enter Lila (the wife, aka: The Merciless). She said: your interest on that case is because you are a good Samaritan? I said: well … all things are relative. She said: In fact I can do that. I said: using diagonals on quads or clamp angles? She said: only time could tell (she’s after diagonals: not good enough).
Insofar: from any brep/mesh as target object > make the proper strangle mesh (blue), compute the max inscribed Radius (for each face on the target object), compute the ideal R value for the SphereCollide IGoal … then do this (and that) and send stuff to K2:
Early stages K2 results: the blue becomes yellow:
I said : silly girl > told you to use clamp angles (and BTW: 500 milliseconds for a simple job like this? do it in 50 max as follows: blah, blah, blah).
Moral: hope dies last.
Update: times have improved (500>100ms) BUT under some undefined (yet) situations this &&@#@$ CollidePointMesh IGoal :
yields an instant Rhino crash with no log file. Never seen this happening (and we have more than 1K++ C# defs that do real-life production ready K2 things). That’s why I hate computers: 30-- minutes to write a C# and 30++ days to debug the damn thing.
The freaky thing is that when using K2 components as a test (but this is NOT the way to go) for doing “almost” what Lila’s C# does … everything works OK: is it Karma? is it a Sign from the Outer Space? is it an Omen?
Moral: I hate computers (and Windows and .NET and .NOT and .Whatever).
IGoal replaced (with SolidPoint: very costly timewise). Elapsed times on the up (BAD) … results are good (but no cigar). Quad control shape via diagonals is not the ideal approach (clamp angles is).
Dude Dope! Care to share? I’d love to give that a try. I suppose I see the logic, “squeeze the grid” relative to the shape within.
Second C# needs some(?) “tweeks” here and there. If done I’ll post it. Or … if other things occur in the practice (meaning an unkown ETA) I’ll post a solution with K2 components (skipping the 2nd C#).
What I mean? Well … as Lila noticed I have an interest on that because it could be an alternative to some C# (strictly internal) stuff that get a mixed tri/quad mesh and do a quad one (that’s not a very easy thing, mind). The final goal is to use any blob, do an engulfing quad mesh and then do a W truss out of it (I have several C#'s that do that anyway). So the quality of the quad Faces (how “close” to a rectangle are) is critical otherwise the truss would look like #%^#%#.
So … imagine a K2 “wrap” task like this one that requires an “ideal” balance between a lot of parameters: Springs from edges, Springs from diagonals (or angles), Pull to target mesh, SolidPoint stuff and these Sphere Collisions. Enter a wrong value and results may become ugly/stupid. What to do? Well … the first thing is to achieve the minimum Elapsed time and the second is an “auto calibration” ability that could optimize the result.
If the Elapsed time goes to Mars (say: more than 150 ms for the complexity of things that I have in mind) then the whole approach stops from being a parametric fun thingy and becomes a parametric torture thingy: a good enough reason to cancel the project and go for some other.
Mars is between 4 and 20 light-minutes away from Earth…
nah never. 2-3 minutes while the 3 minutes is kind of a never happening max.
but what do i know its not that i would know any police ticketing the light for ludicrous highway speeds
Yikes! this IS the solution then > just install GH (use R5 for safety) inside Enterprise at warp mode (toggle Warp == true) > according to the theory of irrelevant relativity > 20 LM == 120 ms (for the fellas inside the starship, 100 years for the rest).
There we go!
No more need to worry about Formula1 (forza Lewis) and MotoGP (forza Vale)…
Until the 2nd C# yields some real-life times/results get the pasta version … but it can guide you to hell or heaven depending on the values used (and is slow as well : 2 of the most expensive IGoals used do the same job [ closest point on mesh] … meaning that we shoot both feets with one go).