hello
my lines in this example are all over the place, how can i manipulate it to form little pyramids like in the example picture ?
things i tried that didnt work: proximity 2D, proximity 3D, delanuey connect, bullant connect poinsts.
any help is appreciated
[
trial_system.gh (146.9 KB)
Assuming a Surf subdiv (or using a Mesh) … for a given quad (or triangle) get the center, find the u/v coords for a pt prox to center, get the Normal (always via u/v values) - that’s unitized by default - and then multiply by some value.
So your point is: center + Normal * value.
If a W Truss (i.e. a double layred thing) is the desired output use connectivity in order to avoid dating the same girl twice (i.e. for connecting the “upper” layer pts: if this is a Mesh the FF Conn is used plus a bool [ , ] Array for the connections sampled).
can you see the internalized things in my uploaded gh file? is it working ?
I never use any kind of add-on. Thus:
Obviously you want to do a W Truss from the Mesh. Like:
Shown a solution using Faces as they are (quads AND triangles). Meaning that the triangulate option is disabled (and any further subdivision).
But as I said many times: if you are in the AEC market sector … things are not that simple (clash checks between 3d Truss members etc etc). Plus using Instance Definitions and this and that. Plus Planarity for the quads (assuming a rational envelope of some sort).
In any case a Mesh is rather way more suitable for that kind of stuff (faster [floats VS doubles] AND lot’s of exposed RC Conn Methods).
clash checks are done in the software that does the load calculations, however this shape is very difficult to work with so thats why im seeking help
also yes, that is what i want, is it possible to do without coding C#
I have no idea: I never use native components.
In fact dealing with this it’s not difficult at all … but the ways to “fix” - interactively/on the fly - potential clash issues (related to real-life stuff for sleeves, cones, tubes, bolts, envelope members etc etc) are way faaaaaar and beyond of what is achievable without code.
BTW: for real-life clash checks I mean this (a classic MERO TSK KK shown):
BTW: Clash checks become more and more “critical” if, say, you want variable W depth (so the axis angles become more “challenging/extreme”). Say something like this:
Solving all the above without Connectivity is kinda riding fast a Harley Davidson.
So in general AFTER defining a real-life System to use … you need an on the fly way to check clash, report failures and attempt to vary the nodes (if possible : otherwise go for another solution or System).
All that before the envelope joins the party.
we use a finite element program for clash issues, works on mesh priniciples, clash issues we have been dealing in our company for years, its not a problem. cones nodes etc are all built in. what we are not accustomed to is “strange” systems like above.
Well … given the Parametric mania (or nonsense - depending on your point of view) you should adapt the one way or the other.
BTW: Imagine a nurbs crv acting as a “central spine”. Then Imagine a “linear” Truss where Crv length/topology, sides, divisions, member dims, loads, cats and dogs are vars. Then Imagine secondary truss frames like fish bones (not shown) defined via a zillion params (mercy). Then Imagine tensile membrane pieces that may (or may not) occur in all the available positions. In other words: a fuzzy/ill defined %#%# situation that may - or may not - is solvable. Reds are the places where axis angles have clash issues.
Welcome to the Brave New Word (where life sucks).
