ength is applied to particle b, and the same vector multiplied by -2*BendStrength is applied to a and c
Hope that helps. I was thinking of changing this input slightly for the next Kangaroo release, because I realize it can be a pain if you want bending stiffness of a curve to be independent of the number of points used, but I'll make sure to clarify any changes when I do update this.
…
an that HashCodes well ... since they are "unique" per item (even if this - for the one reason or the other - is created at the same location with that) I barely can see how one can use them in order to get rid if "equal" items (Lines in this occasion).
On the other hand ... well ... using HashSets sampling the Line center and testing length and direction ... well ... this works but why bother? > if you are not doing business with code (thus you need this "check" internally) > use the Kangaroo1 component.
That said the topic of "equality" is rather huge and most people are confusing a lot of things on that matter: for instance a point not equal to another ... well ... that's rather simple but a brep "not equal" with some else ... this is not that easy (if it's solvable).…
tract subsets, be sure you always perform the same actions on a list of increasing numbers. So, before you start to manipulate a list of 100 points, create a list of 100 integers (0, 1, 2, ..., 99) and make sure it gets mutilated in the exact same way as the pointlist.
Then, when all your points are modified, bring them all into the same list again and sort that list using the integer array as keys. This ought to put them back into the right order.
2) Reverse Engineering: since you know all your points are along well defined curves (lines in your case), you could project them all onto a line that spans the entire model. This will give you a list of curve parameters (floating point numbers). You can then sort your points once again, but this time using the parameters as keys. (See image: by sorting all the points using the curve parameters, you get the order in which they appear from left to right)
2b) If you need to do this thing on points which are in a grid (i.e. 2D sorting), you have to project onto a surface so you get uv parameters for every point. Then vastly multiply only the u (or only the v) values, since you want to give rows (or columns) a higher weighting. Finally add u and v together and this will give you another list of floating point numbers which can be used as a keys array in a sort operation.…
.0001, the functionality is been put into dedicated components (see this post for further details).
Different branches are always combined using Longest List logic. I'm unhappy about this as well, I need to give more control over how different branches are combined, but I haven't figured out yet how to expose such functionality without it being utterly incomprehensible to 99% of the users.
If you want to ignore the data inside the fourth branch, you'll need to remove that branch before the data goes into the Line component. It's easy to remove a specific branch, somewhat trickier to make this removal dependant on variables elsewhere in the network.
You can use the Split Tree component to achieve this either way. Using a fixed mask (like in the image below) may be sufficient.
The !3 means that any branch is allowed except when it has a 3 in that location. The [0-2] means that only branches which have a number in between and including 0 and 2 will be allowed.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
d" floor side).
Rails are obviously defined with slope adjustments at start/end: Imagine a rail ramp curve made via, say, 20 control points: at start p0 is not moved, p1 is moved half the step .... p19 is moved half the step*17 and p20 is moved the full distance. Thus we have what is called "slope adjustment" in our trade.
a myriad of options controls where the spaghetti starts (curve.PoitAt(userControllableT)) what is the continuity mode (sequential or steady[shown]) and what type of profile is used for the sweep.
…
that ... blah, blah) but each of those cores will be running at lower speeds because of the thermal restrictions.
For instance, a dual core may have base clock speeds of 3.5 GHz for each processor while a quad core processor may only run at 3.0GHz. Focusing to single core (on each of them) the dual core processor will be able to about fourteen percent faster than on the quad core. Thus, if you have a program/app that is only single threaded (99% of what's available for AEC puproses to be honest), the dual core processor is actually better. Then again, if you have something that can (?) use (??) all (???) four processors such as the notorious Nexus rendering engine (Modo/Microstation/AECOSim), then the quad core processor will actually be about seventy percent faster than that dual core processor.
But no AEC engineer worth his name cares about rendering stuff, he he.
AMD and Intel have introduced technologies that can dynamically increase the speed of a processor core to help offset these differences between the dual and quad/octa core products. For instance, Intel may have the quad core processor with a base clock speed be 3.0GHz but when only a single processor core is in use at full load, that processor core will be boosted up to 3.4GHz. This would then make the quad core processor just three percent slower than a dual core processor that runs at 3.5GHz.
In general and theoretically, a multiple core processor is a "better" choice but that does not necessarily mean that you will better overall performance.…
switch this talking off-line if you are interested to know the real reasons in depth.
What is the pro way? Well ... imagine objects (blobs et all) that are placed in 3d space by some per object policy whilst their "property" (bend,repulse) is user controlled on a per object basis. Then imagine variants of all that spaghetti yielded (the rays, that is) stored in parameters in order to do the obvious : take control of all your previous attempts (replace, remove, swap, reset etc etc).
Get a 10-- minute thingy (straight out of my head: NO checks OF ANY kind performed [bugs possible], just a grid that shoots rays and a single blob (a sphere) that does the job). Not even a decent random policy is applied in order to have some nice looking rays (not to mention their directions).
Now ... imagine any collection of breps distorting the ray chaos: i.e. a ray meets a blob > is distorted (or not) > then meets another > ... > blah, blah (plus some policy for killing rays heading to Sahara instead of Vienna - but that's elementary).
This requires at least 2 hours of coding to do it properly (+ the variants "management" C#).
But ... well ... it could be a good real-life case when Solaronix "sponge" type of U/V collectors could be available (rather soon) > I'll do it > the future > the glory > the cash > the polar bears.…