ough the curve i use. as you can see in the image, i managed to make my chain units grow in one direction. I aim to finish with a definition which allows me to alter the growth rate according to attractors; points or curves. I have more than one question, so i will list them, and any ideas or help will be appreciated :)
now let me be more specific;
1(UNEVEN SCALING DEPENDING ON ATTRACTORS) - i can apply existing attractor based definitions (somehow) in other discussions, but the continuity of the chain breaks that way; they will be scaled depending to the attractors but i need to fix the chain manually. So my first problem is to find a method for gradual increasing and decreasing of chain units in multiple points on my curve. in the upside image, it is ok in growing on direction, but i want to achieve a result like in the image below.
2(CHAIN CREATION METHOD)-How i achieve these chains requires a manual input; either i must decide the total number of chain parts along the curve, or i specify the lengths etc. i tried to make an automation which calculates the distance between the two ends of a chain piece, and reduces some amount of it (in order to link two pieces of chain, the movement length amount should be less than the length of one chain piece for not to overlap in ends).
but when i do it, the first copy is moved the exact spot that i want from initial piece, but the rest are overlapping on end points, because my definition needs to re-calculate for each item that is going to be copied, but i found no way to fix it.
I have an idea about a definition which checks for intersections of breps and moves the intersecting items till they don't anymore, but in a wavy curve in all x,y,z dimensions; i am not able to automatize each movement direction for each piece of chain.
what i want to achieve is just creating a definition which only required inputs are a curve to define the path of the chain, and a brep that will replicate through the curve. (and if i would be able to add the uneven scaling feature from question 1, the other input should be attractors)
3(BONUS:ORIENTATION)-in this case of orienting the brep along a curve, there is a problem, because all frames are in the same orientation and it is not a realistic way of a chain to stay like that as in the image below;
as you can see, all chain parts are directed to same orientation. what i want to achieve is like in the image below, but i am not able to scale my chain parts like in question 1 and orient them as they should be in the same time, so i'm stuck here too.
I tried to explain everything in my mind in details to be as specific as possible, hope that this long post won't intimidate you. :) I added my study files. scaling chain ones are for question_1, the messed up definition for question 2 is also included. There are no specific definition files for question 3, all my oriented files have that problem.
thanks for any ideas, any help and for any efforts that you will make to enlighten me. …
our students could taste first hand the Apocalypse (and/or the brave new world and/or the animal farm - depending on your point of view, he he).
2. First ... make a break and spend some time to play with the def attached. Of course comes straight from the Dark Side (no components of any kind). But you know what? ... sooner or later your students they must obey to the Dark Side ... or they'll extinct (future galloping you know ... I mean in a few years from now anyone not speaking some programming language > Homo heidelbergensis ).
3. This thingy attached works in 2 modes: (a) design a(ny) pattern (in a "flat" Plane.WorldXY) or (b) apply a(ny) pattern (in any given surface List).
Start from here (diamond pattern, like the one used by you):
Apply random Z noise (other pattern used):
Or use surfaces (to make frames or their content among other things):
Note: Although this def attached MAY appear off-topic ... there's a reason (other than using any pattern you like) that I provide this to you : because that way we can totally control nodes, edges and "facets" and therefor extract any plane imaginable and therefor place/manage any imaginable profile.
Note: Of course using the make frames capability (and extruding these BrepFaces AT ONCE both sides) we could obtain "autonomous" [monocoque, so to speak] modular load bearing "panels" ready for assembly (instead of beams + nodes + plates + cats + dogs + why??) ... but this is not exactly what you've asked ... he he.
more soon…
l, you can find examples of parametric design using LB/HB, specifically the HB component pollinator workflows.
In these examples, a GH component (data recorder) is used to locally store either input parameters or output values of different model configurations and transmit them to pollinator. I can imagine, depending on how your facade is made parametric in GH, that you could save those input parameters (e.g. angle of surfaces or height of extrusion) and output variables for each iteration (e.g. annual shading).
This a search process through the design space. I do think that if you would set up the model as such, then it would be ok that the components in the PV workflow resetted after each iteration as the results would be saved. There is even a really good visualization platform Mostapha has shared to go along pollinator.
You can find examples of these workflows in the forum, simply search pollinator. I have one that I shared somewhere as well, although it was doing rudimentary things it would help.
This design space approach is a bit different than the optimization approach utilizing components like galapagos. It gives you an idea of the space of possible different desings and allows you to compare alternatives. Plus, it usually allows me to avoid all these issues of losing results between components in the workflo.
I also find it very handy and much more efficient than simply allowing a component optimize everything for me. However, it can ncrease almost exponantially (or is it geometrically, I am always bad at this) to the range and number of your input parameters. So, if each square on the wall has more than a couple of input values for a a few input parameters, I would expect this to take a long time. Thankfully, the components in the workflow will let you know exactly how many iterations.
If this method is interesting to you and you follow it I would suggest a few things to hasten the process like utilizing only the squared above and on the sides of the PV panel, since the others won't really affect shading, selecting just 2 or 3 characteristic angles for extrusions, and perhaps approximating energy production through annual shading numbers (since I imagine they have an almost linear relationship).
I do hope that I have understood what you want to do and the above information helps. I'm sure Djordje will give much better feedback on the specifics of the PV workflow. I will try and keep this page saved so that I can send over the example once I'm back at work mid of next week.
Good luck!
Kind regards,
Theodore.
…
serveral questions:the first thing is in c++ i have to implement more methods than in my c# test project.
they are:
int MyGhComponent::MasterParameterIndex::get(){ return 0;}void MyGhComponent::MasterParameterIndex::set(int index){ }bool MyGhComponent::IsValidMasterParameterIndex::get(){ return 1;}
i found no hint for the implementation of that interfaces. could someone tell me that is correct ?OK, it works, but is it well writen ? What is the MasterParameterIndex?
the second "bigger" problem is, i want to have an output of an pointlist.X y Z 1.2 1.3 1.12.1 5.2 9.2...
my first approch was to use a
void MyGhComponent::RegisterOutputParams(GH_Component::GH_OutputParamManager^ pManager){pManager->Register_PointParam("Coordinate", "XYZ", "Node-Coordinate");}
and
void MyGhComponent::SolveInstance(IGH_DataAccess^ DA){Collections::Generic::List<GH_IO::Types::GH_Point3D>^ pnt = gcnew Collections::Generic::List<GH_IO::Types::GH_Point3D>(); for (int i = 0; i < 10; i++) { GH_IO::Types::GH_Point3D^ point = gcnew GH_IO::Types::GH_Point3D(i, i, i); pnt->Add(i); } DA->SetDataList(3, pnt);}
but this exampel doesn't work...i wirte a small workaround and use the following
pManager->Register_DoubleParam("X-Koordinate", "X", "X"); pManager->Register_DoubleParam("Y-Koordinate", "Y", "Y"); pManager->Register_DoubleParam("Z-Koordinate", "Z", "Z"); Collections::Generic::List<double>^ pntx= gcnew Collections::Generic::List<double>(); Collections::Generic::List<double>^ pnty= gcnew Collections::Generic::List<double>(); Collections::Generic::List<double>^ pntz= gcnew Collections::Generic::List<double>(); ... add .. ect.
this workaround do the job, but i want a better soulution. and i know somewhere out there sould be a better solution. i want to use 3D Points directly in GH without list conversation.
so somebody a familiar with c++ / cli ? and could give me some tipps or a soulution ?
the first thing is: what is the right RegisterOutputParams ?
and witch data type is the right ? Point3d doesn't work. so i try GH_IO::Types::GH_Point3D and Rhino::Geometry::Point3d ...
br Friedrich…
cribes a set of machine movements in X, Y and Z (Z being Pen Up and Pen Down) directions. It very closely related to G-code in this way - just slightly more simple than G-code overall.
For tool selection you use the Select Pen - SPx - command, x is the number of the pen you are using. As I'm using a vinyl cutter without a pen/tool changer I just use SP1 in the file header/ini of the cutter.
Without knowing the full spec of your machine it is hard to say for certain BUT all of my experience with CNC machines - of all sizes and spec levels - the actual control files are pretty much the same. Very simple text based HPGL or G-code text files run all motion control - even on things like 7 axis robot arms etc. For plotting I'd expect you'd be able to get a usable HPGL/PLT file without a lot of work - its just a matter of matching the file to what the machine is expecting.
To answer your question about getting the file to the printer its maybe best to explain it this way: there are two parts to this project1/ Create the correctly formatted text/hpgl/plt file ready to send to the printer2/ Send the file to printer
For part 1/ the procedure is:
Select the curves you want to printConvert the curves into a set of pointsFormat these points into HPGL Save this HPGL as a text file
For 2/ we need a way to stream the text file to a printer port
To do this I've used an old dos command line technique that allows allow you to 'copy' a text file to a printer LPT or COM port:
copy /b c:\spool\ini.plt LPT1
Type the above into a DOS command line and it will send a text file called ini.plt to the printer on LPT1 port. As you'll see in my attached code I use os.system calls in my python code to send files when needed.
So your original code was doing some strange things with the conversion from curves to points. Lines/Polylines were OK - with the code just using the line end points. For curves and polycurves the code code was exploding these into segments and then dividing into set of points. However this led to two issues: - curves that started off as closed polycurves would end up being plotted as open curve segments - which is not very good for a cut file and not very smooth for a plot file.- the division of the curves to points was by distance - and if this wasn't an exact division of the length of the curve the end point would not match up with the next line - again not ideal for a cutting file which needs to be a closed curve.
To solve the above I changed to using rs.ConvertCurveToPolyline - with the tolerance set to match the HPGL resolution of 0.025mm - this converts all curves needed to plot to polylines, leaves everything closed and ends points line up perfectly.
I had one other problem with my setup - I ran into a file size/curve number/plotting points upper limit. A small number of curves would cut/plot fine, however at a certain number in one file the print driver would throw an error and the plotter would not even start plotting the file. I could not work out where is the system this limit was being imposed. The current working version of my code is attached - it gets around this file size limit by creating a separate print file for each curve required and sending them to the plotter in sequence. Not as completely tidy as I'd like as it flashes up a cmd window on every loop - but plots/cuts are perfect.
The final 'nice touch' for the project is I've created a custom tool bar button to run the script - all I have to do to cut a file is hit the button on the tool bar, select the curves and hit enter = SO EASY!
I've attached my latest code, a sample HPGL file to plot a rectangle, and a screen shot of setting up the custom toolbar button.
Cheers
DK…
ails.
Some word about the mesh... (see Image_01)
I took a flat 4 points NURBS surface as imput (very easy, it defines the total area of my pavilion) and some points (that defines the contact with the ground).
Then I extracted a grid of points from the NURBS (Surface_Util_Divide surface) and compared 'em with the contol points, in order to associate to each grid's point its own attractor (Vector_Point_Closest Point).
Than I moved the points down. I used the distance from each point to its attractor (inverted) as amplitude for the vector of the movement, in order to say: the nearer you are to the control point, the more intense your movement will be. During this operation I've passed the distances' data list into a graph mapper (Params_Special_Graph Mapper), in order to regulate in a very intuitive and interactive way the shaping of my canopy.
At the end of the process I asked GH for a simple Delaunay mesh (Mesh_Triangulation_Delaunay Mesh). It's a very cool command, I believe!!!
Ok, now some word about the component, it's design and it's repetition/adaptation to the mesh...
(see Image_02)
I took the mesh and extracted components on first and faces's information on second. Then I selected and separated the vertexes (1°, 2°, 3°) of each triangular face into threee well defined list.
Then I re-created the triangles' edges. Please pay attention because it's not the same if you use output information from Delaunay components, because here we need a justapposition of edges where triangles touches each others.
After this work I joined the edges and found their centroid. At the same time I found the mid point of each edge.
Now the component... (see Image_03)
It' a little bit longer to describe: I'll try to be synthetic.
Substantially it is a loft from a curve to a point, repeated three times for each triangle (Surface_Freeform_Extrude Point). The point is an elevation of the centroid of the triangle (you can choose if the exstrusion has a single height or it's related to an attractor. In my case it was fixed). The curve is combination of things. There's an arch, which starts on the edge (there's an offset from the corner) end terminates on the same edge (on the other side, obviously). While it's generation the arch passes through a third point which belong to another segment. This last connects the mid point of the original edge (base triangle) with the centroid. The result is a kind of polyline, with two segments and an arch. If you go back to the image of the component that I posted probably you'll understand what I'm saying better than with the definition.
The posit…
rk and I will just clarify some of the details. I will also note that I do not know what the shadings output of the decomposeByType component is supposed to do as Mostapha put it there a long time ago and I was not sure what his intentions were. Going down a list of clarification points:
1) You are right that you should either connect up the shade breps to the EPContext component or just plug the HBObjwShades into the RunSimulation component (never do both). However, connecting the breps to the EPContext component is greatly undesirable for two reasons: It will make the simulation run much longer and the energyPlus calculation will not account for the surface temperatures of the blinds (it will assume they are the same temperature as the outdoor air, which is very wrong in a lot of cases). When you connect up the HBObjwShades to run the simulation, EnergyPlus will understand the blinds as abstract objects defined only by a numeric parameterization and not as actual geometry. This enables the calculation to run fast and is also enough of a description that E+ can calculate the temperature of the blinds, thereby accounting for the heat that can be re-radiated from the blinds to the indoors when they get hot in the sun. This more desirable way of running the blinds was how I imagined the component being run most of the time and I mostly included the shadeBreps so that you have a visual of what you are simulating.
2) When you use the more desirable HBObjWShades to approximate your blinds, you should use the blindsSchedule input in order to tell E+ when the shades are pulled (this is instead of the transShcedule on the EPContext component).
3) The zoneData inputs on the EPWindowShade component are meant to help in an entirely different workflow, which evaluates shade benefit based on energy simulation results. I apologize if it seems confusing to have two major uses of the component in one but we have so many Honeybee components right now and I did not want to make 2 separate ones when they seemed so similar. See this example file to see how to do energy shade benefit (https://app.box.com/s/oi64zoj5u1slz494grzhgmdkx7yie9jo).
Ok. I think that clears up everything that I know. Now to the part that I do not. As I said, Mostapha put in the shadings input there a long time ago and I do not know what his intentions were. Abraham, as you know, I am about to do a major revision of the EPWindowShade component to make it compatible with OpenStudio, include drapes/generic shades in addition to blinds, and I also should figure out how to do electrochromic glazing. I can easily include all of the visualized shades as output from the decomposeByType component when I do this. However, I do not want to interfere with other intentions Mostapha had when he put the input in. If he could confirm that this was in-line with his vision for the shadings output, I will implement it soon.
-Chris
…
Accidentally that was very close to some project that I have in mind (using solely C# and not components). On first sight I thought that that could be very easy ... only to discover that's not.
This definition is an over simplified version of the other mentioned (only a C# is maintained that does "preparation" work and some sort of naive "topology" checks: the yellow spheres are used as visual aids to the incompatible struts/R values combos).
You can control the 3 options available from that portion:
In a nutshell ... the Exo W behaves with an odd way (at least in my opinion). In order to get the gist of the issue stick to that portion of the def and forget the rest:
This portion of the def attempts to create an usual Exo mesh using a Line list (cleaned and user controlled as regard the min length) derived from exploded mini voronoi (i.e. brep edges). OK, I can understand the red Exo since due to the nature of voronoi breps there's more than possible the presence of small "struts" that may yield non manifold topologies.
But ... the thing is that Exo W is also red in the other mode (non Voronoi) where struts are quite big and no potential "engulfed" situations may occur:
And when the 2d Gate mode is set to Envelope ... there's cases (R values) where Exo W works as expected and cases that it doesn't.
Anyway ... if anyone has any bright idea, drop a world
best, Peter
…
s: [Mesh Brep] which used the Rhino mesher, [Mesh Surface] which create a rectangular grid of mesh faces on a single surface and [Simple Mesh] which attempts to represent each face in a Brep using a single Tri or Quad and accuracy be damned. Let's focus on the easy ones first...
[Simple Mesh] is a first attempt at providing a completely reductionist meshing engine. It was born out of a skype discussion I had with Brian James one night during the weekly Seattle RMA developer meeting. It only handles very simple cases at the moment so it's probably not all that useful, but it's there anyway just in case. If this mesher cannot handle a certain Brep face because it's too complicated it will use the native Rhino mesher for that face.
The purpose of [Mesh Surface] is to provide a single surface mesh that isn't distorted by the underlying parameterization of a surface. My approach for this actually turned out to be really slow, which is why the [Q] input is set to false by default. This mesher was never designed to take trims into account, however you get a single option [H] to control how trims interact with the mesh.
[Mesh Brep] merely channels the native Rhino mesher. You can supply meshing settings that look a little bit like the meshing settings that Rhino itself exposes. With these settings you can control how seams in breps are handled, how much the mesh is allowed to deviate from the underlying geometry, how many quads you want etc. This is the most customizable option, but even here it's totally possible you can't get what you want. For example, there is no way to enforce a mesh that contains only quads. As soon as seams are stitched or whenever trims are present, you're going to get triangles along the edges of meshes.
--
David Rutten
david@mcneel.com…