0 bend strength, relative hinge strength of 353 for the torsion and stiffness 1000 for all springs except from the connection springs. Any idea of what this might be?
I am thinking about going back to having hinge resistance in the changing diagonals only - as before, but keeping the mesh as it is now.…
which I understand analyses only 2 octave bands (500 Hz and 2 kHz) instead of the 8 bands (for which the STI component requires background noise.)
Or have I misunderstood this metric and the three values mean something else?
For reference / a minimal definition I have the open office example (gha and 3dm attached) which includes 20 receivers and the sti results show three values for each (see the image).
Thanks in advance Roly…
omponent of ladybug "The user object could not be created as the base type is missing" ... I am attaching an image of the message below. Please, I have windows 8 and there is nothing wrong with my Rhino 5?
Maybe I missed something when I installed the add-on ?
Regards
Ayman…
ning the simulation looks great(see figure 1). However, I find some question(see figure 2), the red wire frame on the right should be symmetry like the physical lamp, but it has a extend distance now.
I should like to keep the wire frame structure with same length after simulation.
maybe I miss some setting in Kangaroo, can any one fix it? thanks in advance.
I put this ghx file under the attach.
…
eds 14 sec to calculate, wich is really long.
Here is my script, where ddf is the list of list, and elts a list of Point3d.
For i = 0 To elts.Count - 1 For j = 0 To ddf.Count - 1 If elts(i).From = ddf(j)(0) And elts(i).To = ddf(j)(1) Then tabElts(i, 2) = ddf(j)(2) ddf.RemoveAt(j) Exit For End If Next Next
If I decompose my list of list into a list of point3d and a list of integers, the calculation time drastically decrease (0.27 sec), even if the number of loops is 2.5 times higher (724 500).
I would prefer to use the first script, as it uses less loops, but it is too slow (my test concerns a mesh with 441 points, but I am going to use this for much bigger meshes). I don't understand why. Is it to be known that the use of list of list of different types of objects is very time consumer ? Did I make a mistake in my script ?
Thanks for your help…
sible fitness for each component have the same value.
Let's say you have your three components as mentioned before, A, B and C. A is to be minimized, B is to be maximized and C is to be optimised at 15. Furthermore, the possible values of A can vary somewhere between 10 and 500, B can vary between 0.1 and 0.8 and C can be anywhere roughly in between 5 and 60.
So the best possible fitness will be {A=10, B=0.8, C=15} and the worst possible fitness will be {A=500, B=0.1, C=60}.
In table form:
A {min = 10; max = 500; range = 490; target = 10}
B {min = 0.1; max = 0.8; range = 0.7; target = 0.8}
C {min = 5; max = 60; range = 55; target = 15}
The range value is the important here because it tells you the 'strength' of the variable in the total fitness. Typically you aim to make all variables roughly equally strong. Which means our fitness function needs to have weighting factors, so that the components of the fitness function are all {0.0, 1.0}. The old function (without weighting) looked like this:
f = -A + B - Abs(C - 15)
The new function might look like this:
f = -((A-10) / 490) + ((B-0.1) / 0.7) - Abs((C-15) / 55)
The 'rules' could be summarised roughly as follows I suppose:
The sign in front of each variable indicates whether we want to maximize (+), minimize (-) or optimize (-) the variable.
If a variable is to be optimized, then the fitness is defined as Abs(x - c), where x is the variable, and c is the target value. (I.e. optimization equals minimization of the difference between the variable and the target, hence the minus-symbol).
Variables need to be 'centered' at zero (or any other constant numeric, but zero is easiest), so subtract the lowest possible value it can have from the variable.
Variables need to be normalised to the (0~1) domain (or any other constant domain, but 0~1 is easiest), so divide the centered variable by the domain range.
Assuming the fitness progression is linear (which is not a given at all), the fitness ranges before normalisation looked like this:
and the normalisation weighting factors pull them towards each other.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 5:58am on August 14, 2011
too small for an Int32.
According to Zuzanna:
I have tried the newest version and I have encountered an issue with Network Distance Calculator. When I connect Attraction Points the component reports an error. It says that "value is too big or too small for Int32 value". What does it mean?
solved it. I had some lines which did not connect to the middle of other lines.
She managed to solve the problem, but I don't understand the nature of it. I know that all the lines must be split into segments and connect to each other's endpoints, but what's wrong?
(also, there is a flat mesh, I assume if you don't have terrain geometry, component won't work, is that correct?)
…
and created the panels with no problem.
the problem starts after baking the panels, when I want to unite them into a single closed polysurface with boolean union. it just won't work...
things I've tried so far:
1) increasing the unit tolerance (to ridiculous levels): it helped but only a little, just some of the panels would unite. (also, I recreated the morph target after changing the tolerances and recomputed in gh in case that might make a difference)
2)merge all faces for each of the panels solids (btw all the panels are legit closed polysurfaces, no problem there...
I don't know if there is something that has to do with paneling tools or the boolean operation in Rhino...
any suggestions?…
here has been some interesting discussion related to LEDAS and Solvespace in the past, but I don't know if there have been any further developments with that (?)
In the meantime I decided to have a go with Galapagos.
(It is trying to match the position of the yellow object to the blue one.)
I think it's an interesting test, but not really practical.
(It's very slow, sometimes gets stuck, the solutions are only approximate, and it's only for static solutions not actual toolpaths).
Perhaps it's possible to get it to converge quicker - I haven't really got the hang of tweaking the different Galapagos settings yet. Here's the file if anyone's interested.
robot_.3dm
robot_.ghx…
Added by Daniel Piker at 7:38pm on September 5, 2010
almost 60 seconds to compute, 50x50 points x 35 samples each x 3 rectangles = more than a quarter million curve|curve intersections), but at least not fossilised dog slow.
The inputs of the component are:
P = Plane in which to shoot the isovist sample rays, plane origin equals sample point
N = Number of rays per sample point
R = Maximum radius of sample rays. Any obstacles beyond the radius are ignored
O = List of obstacles (curves only). They will not be projected onto the sample plane, so you can have curves that are only partially 'active'.
Outputs:
P = Point at end of ray (at distance R from sample point) or point at closest obstacle along ray view direction.
D = Distance from sample point to P
H = Boolean indicating whether the ray hit an obstacle or not
--
David Rutten
david@mcneel.com
Poprad, Slovakia
…