ut no warnings in the GH environment.
So i checked the error file produced and i get the following 3 severe ones:
** Severe ** ThermostatSetpoint:DualSetpoint="SHOEBOX_HVAC DUAL SP CONTROL" invalid Heating Setpoint Temperature Schedule Name="C:\LADYBUG\EPCSVSCHEDULES\HEATINGSC.CSV" not found. ** Severe ** ThermostatSetpoint:DualSetpoint="SHOEBOX_HVAC DUAL SP CONTROL" invalid Cooling Setpoint Temperature Schedule Name="C:\LADYBUG\EPCSVSCHEDULES\COOLINGSC.CSV" not found. ** Severe ** GetStagedDualSetpoint: Errors with invalid names in ZoneControl:Thermostat:StagedDualSetpoint objects.
I looked in the idf file and i noticed that in the HVACTemplate:Thermostat section the heating/cooling schedule names are taken from the CSV files instead from the previously define Schedule:File section. As a result E+ doesn't recognize the schedules. See attached: Left correct definition, right wrong HB definition.
The fix is easy (i suppose), so, to let you know this small bug.
Thanks,
-A.…
ves me a polysrf with 4 srfs. why? I mean it should be one single srf, am I wrong?
Please see attached srf.jpg
2: Split the lofted srf with another bunch of crvs, gh gives me some invalid srfs, why?
invalid_srf.jpg
3: I have tried to pull the crv onto the srf, but, it gives me funny result, why?
Pull_crvs.jpg
4: The loft, I really want to keep a portion of the section to be exactly the same size, how can I achive that? FYI, I do not want to use "straight loft option" as it will loose the smooth transition.
Will attach the image and .gh in a minute.
Thank you for your help.
…
ad ... you are after a Del solver that could accept a Surface as "guide" (for instance your tube like facade, the roof etc etc). I'm not aware of a GH Method that does this.
Decomposing your facade into smaller pieces where an average (so to speak) Plane has(?) some meaning and then doing some script that "bridges" these collections ... it's a rather naive thinking for a variety of reasons the main being the need of "homogenous" random point distribution (as facades supposedly have). But this is also addressable ... thus could be Plan A.
3. Plan B is to use the best tool that GH has to offer for controlling meshes (Daniel's MeshMachine) and then do some script that "adds some random noise" to mesh pts.
For instance using N randomly distributed "attractors" that affect neighbors/groups of mesh pts etc etc. Plan B.A is ... well forget that it's too complicated.
This has the advantage of NOT taking measures as regards what happens to the facade edges (MUST contain pts as well: at least one point per triangle module should be in a given perimeter edge). On the other hand applying some Kangaroo driven "distortion" on that mesh potentially is the best answer.
3. Plan C: I have some stuff (not working quite correctly - yet - mind) that attempts to do that (nothing to do with GH available Methods) . I'll try to fix(?) the bugs and I'll post it here.…
, Engineer and Researcher from France with broad programming experience. He is the author of the City in 3D Rhinoceros plugin for creation of buildings according to geojson file and with real elevation. Guillaume already created a new component: "Address to Location". It enables getting latitude and longitude values for the given address:
2) Support of Bathymetry data: automatic creation of underwater (sea/river/lake floor) terrain. This feature is now available through new source_ input of the "Terrain generator" component. Here is an example of terrain of the Loihi underwater volcano, of the coast of Hawaii:
3) A new terrain source has been added: ALOS World 3D 30m. ALOS is a Japanese global terrain data. Gismo "Terrain Generator" component has been using SRTM 30m terrain data, which hasn't been global and was limited to -56 to +60 latitude range. With this addition, it is possible to switch between SRTM and ALOS World 3D 30m models with the use of source_ input.
4) 9 new components have been added:
"Address To Location" - finds latitude and longitude coordinates for the given address.
"XY To Location" - finds latitude and longitude coordinates for the given Rhino XY coordinates. "Location To XY" - vice versa from the previous component: finds Rhino XY coordinates for the given latitude longitude coordinates. "Z To Elevation" - finds elevation for particular Rhino point. "Rhino text to number" - convert numeric text from Rhino to grasshopper number. "Rhino unit to meters" - convert Rhino units to meters. "Deconstruct location" - deconstructs .epw location. "New Component Example" - this component explains how to make a new Gismo component, in case you are interested to make one. We welcome new developers, even if you contribute a single component to Gismo! "Support Gismo" - gives some suggestions on how to make Gismo better, how to improve it and support it.
5) Ladybug "Terrain Generator" component now supports all units, not only Meters. So any Gismo example file which uses this component, can now use Rhino units other than Meters as well. Thank you Antonello Di Nunzio for making this happen!!
Basically just forget about this yellow panel:
This panel is not valid anymore, so just use any unit you want.
6) A number of bugs have been fixed, reported in topics for the last couple of weeks. We would like to thank members in the community who invested their time in testing, finding these bugs and reporting them: Rafat Ahmed, Peter Zatko, Mathieu Venot, Abraham Yezioro, Rafael Alonso. Thank you guys!!! Apologies if we forgot to mention someone.
The version 0.0.2 can be downloaded from here:
https://github.com/stgeorges/gismo/zipball/master
And example files from here:
https://github.com/stgeorges/gismo/tree/master/examples
Any new suggestions, testing and bug reports are welcome!!…
Added by djordje to Gismo at 5:13pm on March 1, 2017
he process. The last one is there because fixing it would cause another problem, which we feel is more serious. Solutions may well be forthcoming in the future though.
1. Grasshopper curves and points are drawn more towards the camera than they really are. This is a conscious decision. Often Rhino geometry and Grasshopper geometry exist in the same place. If we would draw the Grasshopper preview in place, then there's no telling whether you'd see the Rhino curve or the Grasshopper curve. We feel it's important that you always see the Grasshopper curve on top. This is why we draw all curves and points slightly towards the camera. However we don't do this for meshes. This results in something akin to the image below. The eye represents the location of the viewport camera, the shaded box represents the actual location of the geometry and all the thick black lines represent the edges of the geometry moved towards the camera. As you can see, the red lines will be visible, even though they should be behind the shaded box. This effect can get very strong when the camera is close to some geometry relative to the size of the boundingbox of all geometry.
2. Wires behind the camera are sometimes visible. This is a bug I don't know how to solve. We'll get around to it eventually. When an object is behind the camera the display transform sometimes makes it visible in front of the camera in some weird inverted perspective mode.
3. Meshes are not z-sorted prior to display. This means that the order in which they are drawn is not back-to-front, but fairly arbitrary. This means that a transparent mesh may appear to punch a hole in the mesh behind it. If this is annoying you to no end, you can use Ctrl+F on the Grasshopper components that contain the meshes that are punching holes and then press F5 to recompute. The draw order should now be different. Of course sometimes it will only 'fix' it for a specific camera angle.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
ays erased. brb.
EDIT 3 : the solution for closed polylines (add the shift component) (for open polylines the earlier solution will work well)
EDIT 4 : to get solution working with both closed and open polylines, just use remove duplicate points component instead of shifting (kangaroo or some other plugins).
…
s because of a typo in line 216. It should be "range" instead of "orange"!
2. line 218 should be hour = range(stHour, endHour + 1) instead of hour = range(stHour, endHour + 1). Good catch!
3. That's what exactly centerPt input does. Just connect a new point3D to centerPt input.
Here is the fixed version: (Ladybug_SunPath.ghuser). It has the date of today but the same version. Simply delete the old sun-path and replace it with the new one. Thank you both!
Best,
Mostapha…
rto (who has pipes in mind).
(3) Some "minor" bugs fixed (what I was thinking? you tell me, he he)
(4) Added more options (from the almost ready V5): "Interactive" (so to speak) Scan mode is cool.
(5) Added ... er ... hmm ... a demo (fat) sardine as a mesh (quite unthinkable for me: I mean the mesh not the sardine).
(6) V5 can section serious things like this ultra chic Italian beauty (hope that you know what Baglietto means):
…
een them to be adiabatic (at first. See later on for an alternative).
The whole process is fine/clear up to the solveAdjacencies: The walls are defined as "outdoors" and "surface" for the boundary conditions. So far so good.
Now i get to the HB_makeAdiabaticByType, and some issues appear (See A in the file).
Setting the interiorWalls to True doesn't change the condition from"surface" to "adiabatic" (A1 in file).
Setting the walls set both internal and external, to adiabatic (A2 in file). Is this supposed to work like this? Why the just the internal doesn't make the change?
In addition to this i'll appreciate your advice in the following. Let's say that i want the internal walls to be divided in 2 parts each. One should be adiabatic and the other "air wall". How do you recommend to do this? Is the modeling in the file correct, or i must do surface by surface?Or using the Decompose Honeybee Zone ...?
How can i retain the air walls and still use the makeAdiabaticByType component?
Thanks for your help!!
-A.
…
Added history support.2) ptOffsetGridByHeightfield. The command was broken. This is now fixed.3) ptUnrollFaces - Added the "LabelSide" option to help place labels outside or inside the panel4) ptUnrollFaces - Added the "Explode" option to help unroll polysurfaces or joined faces as one continuous strip.PanelingTools for Grasshopper:5) Fixed a crash when input multiple mesh modules to ptMorph3DMean component. The component now works correctly with a list of input start and end modules.6) Fixed a bounding bug in ptMorph3DMean component.
Wishing you all a happy new year!
Rajaa IssaRobert McNeel & Associates…