(1) I have been exporting small sections of a larger model into Maya from Rhino as FBX. In Maya I rotate and scale the models (-90 in X, Scale XYZ 0.001). The Named Views are being saved, but do not have a successful import into the Maya model. They do not appear as in Rhino, and the problem is not solved by scaling or rotating the cameras.
(2) If I try going the other direction, the cameras exported from Maya as FBX are also not aligning with the model in Rhino as they are in Maya.. I will do my best to post some images of the problem and hope you can help.
error !!
This is what the named views look like
here I am trying to the other way with a good view from Maya
strange placement..
This is the best result I can achieve, after I scale the camera by 1000
Any Advice???
Thanks, Robert.
…
TB of RAM. I think I'm going to start a GoFundMe campaign to buy one for myself :)
2- The server's cost is about $13 an hour. I get free access to supercomputer through my university and xsede.org because I earned an NSF Honorable mention last March, however, the supercomputers available through both resources are a little complicated for me to use, as opposed to the one available from amazon that has Microsoft server 2012 already installed.
3- I wanted to run 400 annual glare simulations for 400 different views.
4- I tried a to perform annual glare simulation for one view on my Dell XPS that has Intel Core i7-6700HQ processor and 16GB of system memory. The simulation took 2 hours to complete. Radiance parameter ab was set to 6.
5- I wanted to obtain the batch file for each view so I can run them on the server. So I used the fly component to run all 400 simulations and closed the cmd windows, that wasn't bad ( for me at least) because I asked my son to this job for me, he was just glad to help me :)
6- I created one batch file using this cmd command:
dir /s /b *.bat > runall.bat
This created a file with the path to each .bat file. I edited this file in Notepad++ to include the word "start" at the beginning of each line. This was done using the "find and replace" dialogue box.
7- I split my newly created batch file into 3 batch files, each one has about 130 file names and " start" before the file names.
8- installed radiance on my server
9- Ran the first batch file on the server, this started 130 cmd windows performing my simulations, CPU usage was anywhere between 90% to 100% and about 105 GB of RAMs were used.
10. It took about 5 hours to complete all 130 simulations, I expected to run all in 2 hours but can't complain because this would've taken about 260 hours to run on my laptop. After the simulations done I ran the second and then the third batch files ( total of about 15 hours).
11. I got 400 valid dgb files. Couldn't be happier!
…
he time to work with it.
the project is about facade strips which turns along height. the top angle is
parallel to the facade and the bottom is max. 90 degrees twisted, but the strips
should turn diffrently to achieve more dinamic look.
first i have tried to achieve this by calculating distance between the rotation angle from points of the grid and a single point.
then i have tried to ad some more effecting points and used the distance to the divided surface (the circles are just to control the area of effection):
i manually lofted it.
the result is a bit annoying becouse the points that effect the angle are always visible:
i have triend to solve this by drawing a line and divided it to recieve points along the bottom of the geometry. the result is not working properly:
Anyway,
there must be a better/smoother way to achieve this. i would like to effect the twist of the surfaces by distance to a spline, but im just lost. can you help me please?
the problems im encountering:
0- distance spline to grid to effect the angle
1- list of x/y coordinates and angle of rotation for each point of the grid
2- export points to excel
3- lofting lines in one direction only (x1, x2, x3...)
4- reduce the list data to 2 decimal (0,00)
5- maybe angle from radian to degrees
thx…
ort and export from the images below and also from the HELP file of DB in attachments (Page 71: Importing Geometric Data; Page 78-80: Import 3 - D CAD Data). In their HELP file, they mention about "import geometric data".
However, regarding the input of schedules, loads, constructions and etc., DB normally uses "Component " and "Template" (Page 29: Templates And Components; Page 591: Templates; Page 533: Components). "Templates" are databases of typical generic data, including Activity templates, Construction templates, Glazing templates, Facade templates, HVAC templates, Location Templates, and etc. "Component " are databases of individual data items (e.g. a construction type, material, window pane).
Both "Component " and "Template" are allowed to be imported and exported by using "Import / Export library data" command (.ddf format - DB Database File; Page 734: Import Components/Templates, Export Components/Templates). DB also allows us to build up our own libraries of templates and components (Page 731: Library Management; Page 733: Template Library Management).
In order to import both geometric information and other information related to schedules, loads, constructions and etc. from GH to BD, we supposed the following two ways:
1. GH(HB+GB) --> gbXML (both geometric and "Component " and "Template" information) --> DB
This is the way we most prefer. We did see information related to schedules, loads, constructions encoded in the gbXML file generated by GB, but still do not know the reason why DB did not take this information (I also mentioned this in Q6 within the gh file). We assume this might because the gbXML file we create encodes the schedules based on a different template / schema than the one DB expects. We also post this question to the DB forum for help.
(http://www.designbuilder.co.uk/component/option,com_forum/Itemid,25/page,viewtopic/p,13755/#13755)
2. GH(HB+GB) --> gbXML (geometric information only) + .ddf ("Component " and "Template" information only) --> DB
If the first way doesn't work and DB only takes geometric information from the gbXML, then we might think of the other way - generating the .ddf files from GH(HB+GB) to pass the schedule, load and construction information to DB.
I was wondering if it is feasible for HB and GB to have this function? And what is your suggestion to achieve this?
In addition, we notice that DB can export XML files (not gbXML), so we are trying to figure out if DB also accepts / reads the XML file. If so, we might be able to convert the gbXML (with both geometric and schedule information) to XML. What do you think about that?
Thank you again for all your help!
Best,
Ding
DB import
DB export
Template libraries
Component libraries
…
y using the Honeybee_Update Honeybee component.
The video below (best viewed in full-screen mode) provides an idea of what these components are capable of being used for:
The video below shows how these components can be used in an existing Honeybee project (for additional links please open this video in youtube):
I have uploaded two examples as Hydra files that show how these components can be used for grid-point and image-based simulations:
Example1 : Grid Point Calculations
Example2: Image based simulation
Finally, a more esoteric application is demonstrated in this video:
These components are still in the beta-testing stage. Some of the limitations of the components are:
1. Only Type C photometry IES files are supported at present.
2. Rhino is likely to get sluggish if there are too many luminaires (i.e. light fixtures) present in a scene.
3. Due to the spectral limitations of the ray-tracing software (RADIANCE), simulations involving color mixing might not be physically realizable.
Additional details about photometric and spectral calculations are probably an overkill for this forum. However, I'd be glad to answer any related questions. Please report any bugs or request new features either on this forum or on Github.
Mostapha, Leland Curtis, Reinhardt Swart and Dr. Richard Mistrick provided valuable inputs during the development of these components.
Thanks,
Sarith
Update 16th January 2017:
An example with some new components and bug fixes since the initial release announcement can be found here
…
Introduzione a Grasshopper", il primo manuale su Grasshopper.
.
I corsi PLUG IT nascono dalla volontà di promuovere le nuove tecnologie digitali di supporto alla progettazione e condividere il know-how maturato attraverso ricerca, collaborazione con i più importanti studi di architettura e pubblicazioni internazionali.
.
Verranno introdotte le nozioni base di Grasshopper approfondendo le metodologie della progettazione parametrica e le tecniche di modellazione algoritmica per la generazione di forme complesse. Il corso è rivolto a studenti e professionisti con esperienza minima nella modellazione 3D e si articolerà in lezioni teoriche ed esercitazioni.
. Argomenti trattati:
- Introduzione alla progettazione parametrica: teoria, esempi, casi studio - Grasshopper: concetti base, logica algoritmica, interfaccia grafica - Nozioni fondamentali: componenti, connessioni, data flow
- Funzioni matematiche e logiche, serie, gestione dei dati - Analisi e definizione di curve e superfici
- Definizione di griglie e pattern complessi - Trasformazioni geometriche, paneling - Attrattori, image sampler
- Data tree: gestione di dati complessi - Digital fabrication: teoria ed esempi - Nesting: scomposizione di oggetti tridimensionali in sezioni piane per macchine CNC
.
Verrà rilasciato un attestato finale.
.
Ulteriori info e programma completo su: www.arturotedeschi.com e su www.edizionilepenseur.it…
te some cut sheets, but not to optmize material, rather define some cut lines. Everything that I am cutting is made of planar wood elements, but there are very specific geometries (mostly straight lines) and I have to put tolerances and radiasas at the corners in order to cut on the cnc mill. Spending time to figure out how to automate is necessary, but I am stuck!
One thing the definition is doing is taking my brep modeled components in rhino and makking them into 2d close curves and laying them side by side. It works...not ideal as its not layed out in a sheet, but that is not the most important part.
Another particular problem is that you will see some notches in the curves, which other pieces will slip into, so different slots need different specific offsets (making them larger) as a toelrance to allow for material play. This I don't even know how to set up so maybe it will just have to wait.
THE MAIN QUESTION, and super important would be, LIFESAVER:
At all 'inward' corners...which I think will always mean concave corners (most are 90 degrees, but are within to sides, instead of a corner sticking out). I'm sure its obviousy, but the reason being the outward corners a circular dril bit can cut, but inward ones need an arc profile extended beyond where the corner of the other piece will fit into. The drill bit i am using is 6mm, so 6mm diamters arcs is what i'm working with.
I have managed to put such an arc at every vertices of each cut piece. The problem being some stick outward isntead of cutting into the piece. So each one needs to be orieneted correctly. Ideally they would also only draw into inward corners, but I can always delete them out. I think maybe I am missing a more logical mathematical way of defining?
For these geometries it is not very important which side the half circle arc in on in the inward corners, but I also have some geometries that I will have to control where the circles face according to the rest of the cut piece.
The cutouts in the middle of the pieces that are curves do not need such corners obviously.
The picture is an example drawn
I hope this isn't too specific and long. in general though automating fabrication, and controling pracitcal math and orientation problems like this is itnersting to me!
THANKS…
perienced with grasshopper, but so far I've managed to combine the following:
Giulio Piacentino's "Catenary arch from height" script
Pirouz Nourian's "Mobius" script (Obtained from a friend)
End Result:
Here's where I'm stuck: I want the mobius twist to revolve around the midpoint of the arch, but the script uses the input values to determine the endpoints, resulting in a weird sinuous shape when viewed from above. Also, the secondary end points (generated by the mobius script, determining the width of the surface) are generated by default along the z axis, resulting in an arch that only touches the "ground" at two points. I attempted to work around this issue by trying to force the zHeight parameter to correspond with the y axis (thus rotating the arch 90 degrees so it would lay "flat"), but the script interprets the third point as a value and not as an actual point to bisect. I thought this might be an issue with the C# component that I obtained from Giulio Piacentino's script, so I attempted to tinker around with the source code. Unfortunately, I'm not fluent in C# so I only managed to mess everything up (I've since recovered the code from the cache). Anybody got some ideas? -BC …
onsidered period.
Even if the end of July for the mediterranean climate is not the best period to perform an adaptive comfort analysis (it's just a pretest to define a LB model) I want to refine the Adaptive comfort Chart (AC) by changing the external air temperature data imported from the .epw file with that of monitored data as reported here below:
Where the monitored ext air temperature are in this form (green panel below):
I have used the comfortPar component to set the following parameters:
Adaptive chart as defined by EN 15251
90% of occupants comfortable
the prevailing outdoor temperature from a weighted running mean of the last week
fully conditioned space (even if it is not properly in line with AC as already discussed)
The question is this: the AC component could correctly apply the code below if there is only a list of external temperature data for a restricted period (without indication about the limits of this period) and not for an entire year?
else: #Calculate a running mean temperature. alpha = 0.8 divisor = 1 + alpha + math.pow(alpha,2) + math.pow(alpha,3) + math.pow(alpha,4) + math.pow(alpha,5) dividend = (sum(_prevailingOutdoorTemp[-24:-1] + [_prevailingOutdoorTemp[-1]])/24) + (alpha*(sum(_prevailingOutdoorTemp[-48:-24])/24)) + (math.pow(alpha,2)*(sum(_prevailingOutdoorTemp[-72:-48])/24)) + (math.pow(alpha,3)*(sum(_prevailingOutdoorTemp[-96:-72])/24)) + (math.pow(alpha,4)*(sum(_prevailingOutdoorTemp[-120:-96])/24)) + (math.pow(alpha,5)*(sum(_prevailingOutdoorTemp[-144:-120])/24)) startingTemp = dividend/divisor if startingTemp < 10: coldTimes.append(0) outdoorTemp = _prevailingOutdoorTemp[7:] startingMean = sum(outdoorTemp[:24])/24 dailyRunMeans = [startingTemp] dailyMeans = [startingMean] prevailTemp.extend(duplicateData([startingTemp], 24)) startHour = 24
…
thing that MicroStation does (or doesn't). The eternal debate between us is that they focus to the so called BIM aspect of things (and obviously on interoperability matters - that said IFC2*4 is" implemented" in certain Bentley verticals like BA and others) whilst I'm after assembly/component puzzles (and on that matter ... MS ...hmm... to put it politely is not exactly CATIA and/or NX, he he).
On the other hand this paranoid obsession with Level/Layer driven CAD (I hate it) defines a red thick line between CAD and MCAD - because the most intelligent importer can't emulate the way that Siemens NX/CATIA classifies objects - and without control power means nothing.
On the other hand Microstation V9 (...soon) has interesting scripting capabilities (think Modo rather Generative Components) ... meaning that Grasshopper could work there in a rather nice way. I think that I must talk for that to Ray (he recently ditched the ancient legacy MS render engine in favor for the Luxology/Nexus engine). Ray still is negative to buy Act3D mind (hope that you know the mother of visual scripting - the Quest3D VR thing).
On the other hand - within the broad AEC aspect - things these days are different (especially in fast developing countries the likes of UAE, Saudi Arabia, certain ex USSR "democracies" etc etc). Studies are outsourced even at Preliminary Design stage to various sub-contractors (they undertake the Study completion per discipline as well). This means that N separate groups doing M aspects of the whole ... meaning entropy^(N*M) - that's chaos in plain English.
With this in mind I'm quite (a lot) skeptical about the practical meaning of the whole exchange thing in AEC - at least with regard the countries mentioned (not to mention that several portions of a modern AEC thing are made via MCAD apps - chaos^chaos.
I'll back with more focused issues on that matter.
But the big question is: Grasshopper of Generative Components? Well...let's talk serious SS bikes instead: think a Ducati 1198 and a BMW S1000RR (I have them both): which is "best"? The thing is that not always the best bunny is the fasted bunny and not always the fasted bunny is the best bunny.
Cheers,
Peter
…