Data matching is a problem without a clean solution. It occurs when a component has access to differently sized inputs. Imagine a component which creates line segments between points. It will have…
This is the actual reason I'm going through all this. I want to develop an algorithm that can be applied consistently and produce good results.
Here is a a little background. I'm working on my master's thesis in structural analysis. My thesis is on seismic behaviour of a roman temple in Portugal. I will be using a method of analysis suitable for block structures called the discrete element method. I am using a commercial code called 3DEC for this.
Now in order to the analysis I need to construct a 3D block model of my structure. I received a 3D scan of the entire structure (in *.wrl) format and spent a week trying to clean it up and slice it into the blocks that make up the structure. Now I want to use the scanned geometry of the blocks and describe a simplified prism around each that will represent the block in my analysis. I've attached a file with one of the columns in the temple. I think (at least with my tests so far) that it is representative of the all the blocks I'm dealing with.
Now my criteria for creation of the blocks:
I would like the contact area between the blocks to be as close as possible to the actual drum contact area,
I would like to get the volume of the blocks to be as close as possible (secondary to the contact area) to the volume of the actual drums in order to insure that the weight distribution in the structure is as close to reality as possible,
I would like the shape of the contact area to be as close to reality as possible
I order to satisfy all these requirements, I've done the following in my grasshopper file:
I take a section at the top and bottom of each of the drum meshes. I use this to extract the contact outline at the top and bottom of the drum. This is sometimes problematic and requires me to clean up the model and remove features that interfere.
Next I take each surface and try to fit a minimum circle around it. I try to do this because in my mind this is the best possible way to find the actual centre of the drum when there is cut outs and deterioration. This works well as long as more than half of the contact surface is still in its circular shape (third block from bottom in the example file doesn't satisfy this requirement and thus causes problems).
Knowing the centre, I use an algorithm I created in VB to search for one of the flutes on the contact profile. My ideas is that if I can find one of the flutes, I can then find the others by just going around at 30 degrees (there are 12 flutes) and find the location of all the flutes. In the VB code I've tried to explain my algorithm so I won't explain it here. I also think this algorithm is needlessly complicated and stupid as I'll explain later.
Once I've got one of the flutes, I just find the intersection of a line with at every 30 degrees with the outline curve.
Having all (12) points around the perimeter, I use an loop to scale the shape around the centre of the circle I found in step 1 to get the area within a tolerance value of the actual contact area (satisfying requirement 1). I was using HoopSnake before, but it required resetting every time so I decided to write my own thing.
I then connect the points on both top and bottom to get a solid block.
Now the problems are as follows:
Sometimes the algorithm doesn't find the best location as the starting point. As I said an important thing is that the circle is tangent to the flutes and that is true only if the column profile is larger than a half-circle.
The software I use requires convex blocks. I've tried to remedy this by using convex hull component before step 5 to insure the surfaces are convex.
I'm having issues sometimes with the alignment of top and bottom points. I think I just need to implement a component that sorts the points around a single basis so that there is no twisting.
I've been experimenting with convex hull as a general approach for defining the corner points, but I'm having problem take the convex hull curve and breaking it into a 12 sided polygon, preserving as much as possible the location of the flutes and the general shape of the contact surface.
I'm really sorry about the long post and complicated question. I hope someone can give some pointers on what I could try. I understand that this is not an easy question and that it is more a question of doing something rather than asking about grasshopper itself. My goal is to have an algorithm that I can explain as a general method for others to use in the future when dealing with these structures. This is only a small minor part of my thesis (the analysis is what is important) but it is taking a lot of time to figure out.
If you have any other questions, I would be more than happy to provide a better explanation. In the file I have created a region with all my input parameters. You can choose a different mesh from that point and change various settings. I hope that is self-explanatory.
Thanks for all your help,
Ali
BTW: I'm really sorry for the poor way I've done this stuff so far. I'm not a programmer and apart from some small macros in Excel I don't know much about this stuff. To add to that, I've just started with Rhino and Grasshopper about five days ago after almost pulling out all my hair trying to do this with AutoCAD!…
h, and using the BScale and BDistance are creating havoc somehow too. I've simplified first, and used the Kangaroo Frames component along with setting internal iterations, to make MeshMachine act like a normal component, along with releasing the FixC and FixV. The FixV didn't make any sense anyway. I've also set Pull to 0 to speed it up during testing, since much less calculation is involved to just let the meshes collapse, prevented from disappearing altogether by using a mere 15 iterations.
Also, your breps are open so that allows much more chaos and then collapse, though they did manage to close themselves too at times. Here is closed breps with a full 45 iterations:
So now that it's working, lets re-Fix the curves, and the problem arises that there is an extra seam line that is getting fixed too, running along the cylinder, stopping the mesh from pulling tight under tension wherever a vertex happens to be near that line:
So lets grab only the naked edge curves instead:
And what happens if we lose the end caps, now that we don't have an extra line skewing the result?:
There is no real curvature differences since it's not a curvy brep so the Adapt at full 1 setting has little to do. Now what does the BScale and BDist do? Nothing! Why? Your scale is out of whack, 99 mm high cylinders but only a falloff maximum of about 5, so let's make the falloff be 25 instead, but I must restore the end caps or the meshes collapse away for some reason and freezes Rhino for a minute or so the first time I try it:
It's a start.
If I intersect the cylinders, nothing changes, since they are being treated as separate runs. MeshMachine outputs a sequence of two outputs though, due to Frames being set to a bare minimum of 2 needed to get it to work, so I filter out the original run, which is just the unmodified initial mesh it creates.
The lesson so far is that closed meshes are much less prone to collapse and glitches leading to screw ups.
A Boolean union of the cylinders is when it gets funner, here show with and without the fixed curves that seem to define boundaries too where really there are just polysurface edges:
…
owing a tutorial is easy and adapting the idea of it again - it's not a fuss - i guess my skills are at 1 - since I can not yet stand alone! However I am very determined to nail this program to the ground and be at a 9 by Easter - of course that means a lot of work and hours testing - but I am young and ambitions!
I am a revit user and I just switched over (from the dark rigid side) to rhino because of a simple math problem which has to do with variations and combinations.
I am investigating the form factor for my thesis.
Form factor= building envelope (the area of the facade+the area of the roof+the area of the footprint)/the total area of the floors.
I have started by defining a specific set of parameters such as height, number of floors, maximum total floor area so I can compare the results.
Therefore the floating number will be the facade area - which in the end, considering the height is a constant - ends up being just the length of a certain shape - circle, square, triangle ...
I have done the calculation through excel after extracting from revit but only on simple shapes as follow(the following examples are my own analyzing work):
My problem is: I need a way to get all possible shapes that meet the criteria i put in - which at the moment will be defined by square meters of a floor- that is why galapagos comes in - I need it to make all possible combinations that can be computed that meet the criteria - so then the user(myself or who ever else want to use it) can make an informed choice. I am not looking for a square - circle, sphere or anything I can manually create by just using basic geometry, I am looking for all the possible combination that equal the same area.
(plan view)
After i can solve it for one level - i will constrain that all the levels add up have specific total area - so if a level get's bigger in size another one gets smaller. Again run it through Galapagos and get all possible outcomes (like the sections below)
I am aiming to get an outcome from which you have options to pick out of -> a design process not a specific shape.
You are thinking too complex - not that it's a bad thing - but I am looking for something more simplistic than that. I need a shape - windows and panels are for later use in my process and at this early stage completely irrelevant - and that will be another percentage math problem rather than aesthetics. I just need shapes to morph based on input parameters.
I hope this was an interesting read for you and I really appreciate your patience with me.…
ntación en distintos procesos del Diseño. Se abordaran los conceptos basicos y la metodologia para abordar problemas de diseño a traves del desarrollo de Herramientas Algorítmicas mediante un proceso de programacion visual.
Como nuestras herramientas de trabajo se utilizara Rhinoceros+Grasshopper+Wea verBird
Instructor: Leonardo Nuevo Arenas[Complex Geometry]
Fechas: 5 y 6 de Noviembre 2011
Lugar: Sebastian Bach 5411, Col. La Estancia, Zapopan Jalisco.http://g.co/maps/nc7g6
Cupo: Limitado a 10 plazas
Costo:
Profesionistas: $3,300.00
Estudiantes: $2,800.00
Fecha limite de pago: Viernes 28 de Octubre
Importante:
Los participantes deberán traer su propia Laptop con todo el software y actualizaciones (originales o versiones de demostración oficiales) previamente instaladas. (Se fijara una fecha unos días antes para revisar que todos los equipos estén en orden y listos para trabajar). Si planeas venir de fuera de la ciudad contactanos y te pondremos en contacto con otras personas que también vayan a hacerlo para en caso de desearlo puedan compartir su lugar de estancia.
Contacto:
Complex Geometry
Leo[33 3956 9209]
[nuarle@msn.com]
FARA.Architectural Lab
Aye[33 1050 3482]
[ayeritza.fara@gmail.com]
Para hacer tu pago via deposito o transferencia electronica:
Banamex
No. Cta. 6035264
Sucursal. 0644
CLABE interbancaria: 002671064460352648
Beneficiario: Leonardo Nuevo Arenas
Al hacer el movimiento bancario favor de enviarnos el comprobante (scanner del boucher o captura de pantalla de la transferencia) a los correos de contacto que aparecen mas arriba.
http://cgeometry.blogspot.com/…
ences, so not terribly important in the end. After all, it's not really worth going through a lot of trouble to get a 15% speed increase; 15% faster than slow is still pretty slow.
Also processor speed has pretty much peaked these past few years, there have been no more significant increases lately. Instead, manufacturers have started putting more cores on motherboards, which is something GH unfortunately cannot take advantage of.
Multi-threading (very high on the list for GH2) brings with it a promise of full core utilisation (minus the inevitable overhead for aggregating computed results), but there are some problems that may end up being significant. Here's a non-exhaustive list:
It's not possible to modify the UI from a non-UI thread. This is probably not that big a deal for Grasshopper components, especially since we can make methods such a Rhino.RhinoApp.WriteLine() thread safe.
Not all methods used by component code are necessarily thread safe. There used to be a lot of stuff in the Rhino SDK that simply wouldn't work correct or would crash if the same method was run more than once simultaneously. Rhino core team has been working hard to remedy this problem, and I'm confident we can fix any problems that still come up, though it may take some time. If components rely on other code libraries then the problem may not be solvable at all. So we need to make sure multi-threading is an optional property of components.
There's overhead involved in multi-threading, it's especially difficult to get a good performance gain when dealing with lots of very fast operations. The overhead in these cases can actually make stuff perform slower.
There's the question on what level should multi-threading be implemented. Obviously the lower the better, but that means a lot of extra work, complicated patterns of responsibilities and a lot of communications between different developers.
There's the question on how the interface should behave during solutions now. If all the computation is happening in a thread, the interface can stay 'live'. So what should it look like if a solution takes -say- 5 seconds to complete? Should you be able to see the waves of data streaming through the network, turning components and wires grey and orange like strobe lights? What happens if you modify a slider during a solution? Simple answer is to abort the current solution and start a new one with the new slider value. But as you slowly drag the slider from left to right, you end up computing 400 partial solution and never getting to a final answer, even though you could have computed 2 full solutions in the same time and given better feedback. Does the preview geometry in the Rhino viewports flicker in and out of existence as solutions cascade through the network?
…
y stages of design, mainly due to the large uncertainties that exist in these phases. Optimisation in the early phases may be helpful, but it does not provide the designers with more information on "where to go from here". Once the designer changes a parameter to suit a client requirement, legal requirement or other, the optimised result may very well be thrown out due to the parameter being changed having such a large effect.
I am hosting several workshops and focus groups in the next month (one for students at Victoria University of Wellington, one for architect practitioners and one for engineering practitioners) to teach the basics of Honeybee and Ladybug within Rhino as NZ is very new to any form of distributed modelling methods (using visual language programmes such as grasshopper and dynamo to communicate between design tools and building simulation program tools). In the focus groups, I am not focusing on the tool of Honeybee so much as I am asking the industry its opinions on the feasibility and wishes of developments such as Honeybee.
I find that many informal interviews I have been having have pointed to the question: Would you rather want to know the optimised concept or the most significant design parameters which you should be wary of at the early stages of design?
I am amazed at the capabilities of Honeybee because it has been such a pain to remodel anything for E+ and Radiance in the past. I particularly love the ability to generate hundreds of idfs with varying parameters within 10min, without having to set up some form of macro to do it. The visualisations of Honeybee are awesome! To say the very least. But as someone who is interested in doing a sensitivity analysis, say with Thermal Autonomy, I feel like there is a lacking element to analysis from an engineer and research/academic stand point.
The way I have set up my files actually create 300+ idfs with all the various different parameters. The parameter ranges only vary from a low, typical and high setting for power densities, WWR, schedules and insulation. These have all been drawn from a large 5 year project where we monitored commercial buildings here in NZ to gain a better understanding of data for purposes like this. I then run them in parallel as batch files and re-insert the data back into Honeybee.
What I am playing around with at the moment though is that, due to the fact that the TA component require so many additional components to then analyse the data in that form, and also that it does not simply give a numerical value in % for the space's performance, I need to re-evaluate the csv that it produces for further analysis.
I have only just begun to try doing some form of sensitivity analysis within Honeybee itself, but I was curious if there were already plugins within grasshopper which may already allow some form of sensitivity analysis.…
of them. If they were already suggested and deemed impossible, i apologize.First, it would be really cool to have a right-click menu item for any geometry retaining module, that does the following: bakes the geometry, then disconnects all inherited data from the module, and assigns the baked version as locally defined. This is a one-time only thing, of course - it would be cool because if you have a "step-definition", that is, you have clear bottlenecks in your dataflow, and at some point you become satisfied with what you have so far, and only need to manually tweak some stuff to move on, you can discard the "already solved part of your definition. It's just a sort of "casting in stone" of partial results, that helps especially with simple work-defs or helper-defs. You could also call it something kickass like "manual override" or "emergency/hand b(r)ake".Second, if you have a component that outputs to a lot of others, and you want to change it with something else, you usually have to painstakingly reconnect all those wires, and if it doesn't work out, you do it right back or undo until you fingers bleed. Just as there is an extract parameter upstream for locally defined values, a downstream "extend parameter" with one rightclick menu item would make switching between various components easier.
Third, maybe a hot-key that you press and then click on a wire, which creates a "data" component at that point, splitting the wire and effectively allowing you to hijack it.
Lastly, maybe this is a stupid question, but what happened to the "clusters"? I mean i know they ended abruptly because of technical difficulties, but collapsing a group to a single component like that was totally awesome.Oh, and a minor bug repor from the v7.053 - it's not important, but mildly annoying: when you have an embedded graft, flatten, reparam or expression into a plug, the component extends to the left with the nifty little icons, and that looks very nice, but the wires still go in the old place, so at first glance i always think the wires are plugged in wrong. Is it possible to move the plug along with the component icon edge, or at least make those little indicators smaller, so that the error is minimized?
Thanks for your time,Hope i was pertinent
Andrei I.ps: the lolcat component is adorable, but i do believe that overall worldwide grasshopper productivity has dropped by various increments of those 20 sec it takes for it to refresh. Sadly accustomed with the feeling of guilt associated to watching around 50 lolpics refresh, I suggest that every 5 refreshes or so, you get a "stop looking at this and get back to work" message. It is at least a good way to derogate responsibility for tempting people to watch kitty-pics all day. :D…