I am starting to wonder if I have some sort of mismatch between my GHA file and my Diva version, though I'm not sure that would cause these kinds of problems.
Incidentally, I tried creating a brand new file and I get the same results. I cannot save anything with DIVA components in them, they disappear every time. :(
Speaking of 2.0, do you happen to know when that will be released?
Thanks,
Marc
info: Plugin version: 0.8.0066 info: Plugin version: 0.8.0066 info: Object list read info: Plugin version: 0.8.0066 info: Object list read info: Plugin version: 0.8.0066 info: Object list read info: Plugin version: 0.8.0066 info: Object list read info: Plugin version: 0.8.0066 info: Object list read info: Plugin version: 0.8.0066 info: Object list read info: Plugin version: 0.8.0066 info: Object list read error: Component DIVA Daylight Analysis for GH {4ec4ef63-a2e3-4501-891c-dc1107bdd94d} failed to deserialize itself: Method not found: 'Boolean Grasshopper.Kernel.GH_ComponentParamServer.ReadParameterTypeData(GH_IO.Serialization.GH_IReader)'.
error: Component Material {842f969a-3d16-4b32-9aaf-d996bd25181a} failed to deserialize itself: Method not found: 'Boolean Grasshopper.Kernel.GH_ComponentParamServer.ReadParameterTypeData(GH_IO.Serialization.GH_IReader)'.
error: Component Construction Assembly {2f4beddf-fda7-4852-9820-c36101cd316d} failed to deserialize itself: Method not found: 'Boolean Grasshopper.Kernel.GH_ComponentParamServer.ReadParameterTypeData(GH_IO.Serialization.GH_IReader)'.
error: Component Fixed Shade {cc5c1712-3cb4-4e91-b322-ebc050a75c3f} failed to deserialize itself: Method not found: 'Boolean Grasshopper.Kernel.GH_ComponentParamServer.ReadParameterTypeData(GH_IO.Serialization.GH_IReader)'.
error: Component Read Saved Thermal Results {b71b827f-7e12-42a8-a44a-a9ebb1da1596} failed to deserialize itself: Method not found: 'Boolean Grasshopper.Kernel.GH_ComponentParamServer.ReadParameterTypeData(GH_IO.Serialization.GH_IReader)'.
error: Component Viper: Thermal Analysis for GH {8a8fd0f2-dcd8-4c3c-83dd-d74baf8dcaba} failed
…
Rhino core functionality with the least amount of overhead.
Steve started developing a .NET SDK a few years back which allowed languages such as C# and VB.NET to also write plug-ins for Rhino. The first iteration of this .NET SDK was called Rhino_DotNET and it was a 1:1 translation of the C++ SDK. Basically, every class and every method was wrapped automatically with a python script. Rhino_DotNET was a mixed-mode assembly, meaning it was both C++ and .NET at the same time. Although this sounds like an ideal way to bridge the gap between a native C++ SDK and .NET development languages, Steve eventually decided it was more trouble than it was worth.
The second iteration of the .NET SDK is called RhinoCommon and it is lovingly hand-crafted by the hard-working, indigenous people of Seattle (and, to a small extend Poprad). It is very different from Rhino_DotNET. All the classes and methods have been redesigned one by one to provide a more .NET experience. A lot of C++ code has been replicated in C# to reduce overhead in critical parts. It is no longer mixed-mode.
RhinoCommon consists of two dlls, one created using C++ the other using C#. The C++ dll (rh_common.dll) exposes the core C++ SDK functionality via a large collection of easily P/Invokable functions. The C# dll (RhinoCommon.dll) defines the .NET SDK as we see it.
So, yes; using RhinoCommon (and Rhino_DotNET) will be slower than using the core SDK directly. However the overhead is roughly the same for every function call which means that functions that take a long time to compute will have negligible overhead. An overhead of 2 nanoseconds on a function that itself takes 4 nanoseconds is quite severe while an overhead of 2 nanoseconds on a function that takes 12 milliseconds is not worth considering.
Finally, Grasshopper is a pure .NET plug-in and if you wish to write plugins to Grasshopper you will have to use a .NET development language.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
low falloff of exponent -4) inside a bone-shaped single surface brep (the same point edited 10X10 UV Rebuild modified sphere) with constrain to brep used, you practically get a geodesic dome along the surface and a nicely triangulated and thus terribly strong truss connecting to it inside:
Baking just the lines then lets you bulk them up using Cocoon marching cubes:
No more chaos there, just equilibrium and mild disorder as Kangaroo bounces things around before you stop its timer. You double click to reset it using the Boolean Toggle input, and right click activate the timer component to get it running.
I have to offset the original surface to avoid bumps on the shell when I include that as a force field object (metasurface). I could have filtered out any lines whose both ends fall on the surface, actually, for a less bulky result. I did have to Join the inner and outer mesh surfaces in Rhino, to formally make it a single mesh for a ClippingPlane to show it right:
I don't recall seeing anybody having done simple 3D trusses via Kangaroo repulsion, and a search was not fruitful, but it works! Since it's so uniform, my connectivity was just culling any lines not in a fairly narrow length range after Kangaroo considered full connectivity between each point and all the others.
The ideal connectivity will be six closest neighbors on the surface, and twelve closest neighbors in the interior, given that twelve spheres pack around one. This does give a heavier result, perhaps, and maybe not as springy.…
' group that fixes it. Unfortunately, the kludge fails with my other test surfaces so I added a switch between "Method #1" and "Method #2" - hence the group label "Kludge":
This got the holes to work on the 'right eye' surface but 'both eyes' fails for a different reason...
So I decided to see what happens with a mashup of this code with MANU's code to produce facets instead of holes:
It works! The "Smooth" holes produce a twisted lofting that looks a little weird - oh well.
The "Sharp" setting looks pretty good, though there are small differences using 'PtCloudCntr' instead of 'Area' to get the centroids...
This code (attached) is ~4 times faster when the point count is increased from 100 to 200 (~16 seconds vs. ~70 seconds):
Thanks again MANU. It's really difficult to write FAST code that handles all surfaces well.
P.S. Since MANU's code is randomly scaling down the "holes" for the facet surfaces, the 'Scale' slider in the yellow 'Controls' group can be set to 0.99 - 1.0 fails for "Sharp", though it works for "Smooth".…
Added by Joseph Oster at 11:47am on December 23, 2015
tten on the initial configuration): this makes the analysis a bit tricky. In Finite Element programs, this is usually solved by an iterative method (modified Riks method), which is unfortunately not implemented in Karamba. There are other form-finding techniques, used for gridshells:
Dynamic relaxation with kinetic or viscous damping. I used viscous damping and an implicit integration scheme (Bathe's method) for the form-finding of gridshells in this paper. For kinetic damping, you can look here. It was first used for beams by Sigrid Adriaenssens
You can also look at Sina Nabei's PhD on the form-finding of twisted beams, and also the thesis of Frederic Tayeb (in french) and some papers in the link far below.
The main question remains the mechanical you are using: beam model (with torsion and bending) or shell model? In terms of solver, Kangaroo2 is powerful (although you don't have access to real engineering values, like Young's modulus), but there is no beam element with 4 or 6 degrees of freedom/node... Likewise, I'm not sure that shell elements (with bending) are implemented within Kangaroo2.
If you look for references of research on deployable structures for shading, you can look at the research at ITKE, but also a joint research effort between Princeton and l'Ecole des Ponts ParisTech.
http://thinkshell.fr/deployable-structures/
http://thinkshell.fr/form-finding-of-twisted-beams/
I hope this helps you...
Romain…
as much as I can. What I have is a group of curves (Layer 01) which I'm trying to RUnion and then Fillet. I have put all the curves into one Curve component and then plugged it into the RUnion and I get nothing coming out of RUnion.
The blue outlines are pertaining to the whole and the red are me trying to trouble shoot... but, before I tried trouble shooting particular curves within the group, I tried to explode and join them... which helped with "most" of them but still gave me some funky stuff and left others out.
Getting back to the red outlines where I was trouble shooting... I was trying to single out certain curves that may be throwing everything out of wack.. well, the two curves circled in red in the first image above seemed to be doing it until I tried to RUnion them separately from the rest, which ended up working
I have also checked Planarity (if that's a word) and all are Planar... I also tried inputting the XY Plane into the RUnion... both of which did not give me any different results Finally, I have imported all of these curves from CAD... (I've had problems with curves imported from CAD in the past, does anyone know why that could be?) but I had redrawn the lines and used the ones I have redrawn in Layer 02 and this still doesn't seem to help.....
EDIT:I forgot to add that I am using Rhino 4 SR9 and GH 0.9.0014 I'm not a newbie and "thought" I knew GH fairly well..... any help would be much appreciated. Thanks,
Jason…
rea.
(GH screenshot, Excel screenshot, and various model space screenshots in jpg below)
organize%20by%20floor_v4_for_online_question.jpg
(GH definition) : organize%20by%20floor_v4.gh
The user controls the length of the floor plate with a slider while the width is taken from Excel as the largest width value among the rooms.
The rooms are prioritized sequentially. (e.g. 'A' is prioritized above 'B', 'B' is prioritized above 'C', etc.) This essentially means that is the floor plate gets to small to accommodate all room, the last room (in this case 'D') would be first to move to higher floors, then 'C', and then 'B' as necessary. 'A' would always remain on the first floor plate.
My thought process: Compare the added lengths of different room combinations that could potentially be adjacent to one another to the user determined floor plate length. Using dispatch components, create a 'flowchart' of If/Then scenarios that tests these comparisons and seek for a room configuration that minimizes room displacement. Once the definition knows what should move where, the rooms are moved using vertices that are put together from the room dimensions, as all movement is relative to the other spaces.
My problem: This definition is highly customized for the scenario of having only 4 rooms, but I would like to create a definition that performed a similar operation on any potential 'n' amount of rooms. The problem with that is that it would require the use of a varying amount of components, as increased number of rooms would need more length summations, length comparisons, and embedded dispatch paths. Is what I am trying to do possible? Can grasshopper create a varying number of components based on the list length of rooms?
Please help!! Thanks!! …
Added by Drew Brooks at 11:02am on January 22, 2014
ents (e.g. only fabric between 2 radial cable). But if I try to simulate a completely whole structure like picture below + if I trying to model a material that has more degree subdivision + adding diagonals (as resistance to shear deformation which causes the creases like Daniel Pikels example of tablecloth drop), then I have huge problem to deal with my hardware.
(I am using Intel Xeon 4 cores, 2.93GHz with 4GB RAM and running in Win7 in 64 bit but with Rhino 32 bit.)
(Roof geometry can be completely asymmetrical, so let’s assuming that we can’t array the resulting geometries!)
There are some discussions about how to increase the processing power of grasshopper:
http://www.grasshopper3d.com/forum/topics/is-there-a-plan-to-suppor...
http://www.grasshopper3d.com/forum/topics/performance-of-grasshopper?
http://www.grasshopper3d.com/forum/topics/grasshopper-cpu-optimization
As I know that the GH is single threaded, we could over clocking the CPU + give lot of RAM.
I am curious if Kangaroo and other Apps are following the same performance-rule (single thread) like Rhino/ G.H? And what would be the key-feature to increase the power of Rhino/GH/Kangaroo in order to process the case I mentioned before (completely retractable roof)?
- Which level of CPU? Or constraint of CPU over clocking when necessary and capacity of RAM)
- How fine tuning my PC for best performance? (Parallel computing, c-flex…)
- is GPU a matter? (E.g. in Animation standard: Nvidia CUDA Quadro 4000+)
Or probably just a suggestion of workstation ;-)
Sorry I am not expertise of computer technical…
Thanks!…
w elements (e.g. only fabric between 2 radial cable). But if I try to simulate a completely whole structure like picture below + if I trying to model a material that has more degree subdivision + adding diagonals (as resistance to shear deformation which causes the creases like your example of tablecloth drop), then I have huge problem to deal with my hardware.
(I am using Intel Xeon 4 cores, 2.93GHz with 4GB RAM and running in Win7 in 64 bit but with Rhino 32 bit.)
(Roof geometry can be completely asymmetrical, so let’s assuming that we can’t array the resulting geometries!)
There are some discussions about how to increase the processing power of grasshopper:
http://www.grasshopper3d.com/forum/topics/is-there-a-plan-to-support-multicore-in-the-future
http://www.grasshopper3d.com/forum/topics/performance-of-grasshopper?
http://www.grasshopper3d.com/forum/topics/grasshopper-cpu-optimization
As I read that the GH is single threaded, we could over clocking the CPU + give lot of RAM.
I am curious if Kangaroo and other Apps are following the same performance-rule (single thread) like Rhino/ G.H? And what would be the key-feature to increase the power of Rhino/GH/Kangaroo in order to process the case I mentioned before (completely retractable roof)?
- Which level of CPU? Or constraint of CPU over clocking when necessary and capacity of RAM)
- How fine tuning my PC for best performance? (Parallel computing, c-flex…)
- is GPU a matter? (E.g. in Animation standard: Nvidia CUDA Quadro 4000+)
Or probably just a suggestion of workstation ;-)
Sorry I am not expertise of computer technical…
Thanks!
…
Added by Jon to Kangaroo at 3:31am on June 27, 2014