bout angle since the exact same wires can suddenly start working fine later! Just adding new items to Rhino and then using undo to get back to your failing geometry will fix it sometimes?! Flipping the pair of curves' directions, either one or both, fixes it. It's just black box broken. It happens for really boring angles near 90 degrees.
Rotating the entire pair in space has no effect.
Rescaling the lines from their joint point has no effect.
Simply cutting and pasting the lines out of Rhino back in *sometimes* fixes it, so it's angle and something else that makes certain lines "toxic."
Duplicating the pair of failed lines via alt-dragging the Rhino gumball fails to fix it.
Running the "line-like curves" through a Line component to give "lines" doesn't fix it.
Re-creating the lines by extracting endpoints fails to fix it.
Each line, if separated from each other works fine.
Grafting makes each line into its own little cylinder minus a hub.
The error is the boilerplate "Object reference not set to an instance of an object."
Once the pair spontaneously starts working I cannot reproduce the error with that pair again, though sometimes Rhino undo will get me back to failing.
CAN ANYBODY REPRODUCE THIS WITH MY FILE? If so I can submit a bug report.
Exoskeleton is here: http://www.grasshopper3d.com/group/exoskeleton
Source code is here but it's for compiling, not something I can just test in a C# component out of the box:
https://github.com/davestasiuk/Exoskeleton2/commit/f63c4aa691a7f26b...
…
s is like flattening your data PARTIALLY - chopping an index off the end of the branch paths without obliterating the tree entirely. When working with one "set" of input data, a flatten works to get these lists to match up - but when working with multiple sets, we need to be careful to preserve the original branch indices that keep all four of your original regions separate. As a rule, whenever you're feeding two data trees into any component, they should have the same number of branches. (or one should have branches and the other should be a flat list, in other cases).
The rule of thumb I tend to teach is this:
In 90% of cases...
For lists, all your inputs should either have 1 item or N items. That is to say, if you're feeding 4 items into one input and 9 items into another, something is probably wrong.
For trees, all your inputs should have either 1 branch or M branches. That is to say, if you're feeding a tree w/ branches {0;0} to {0;3} into one input, and a tree w branches {0;0;0} to {0;3;8} into the other input, something is probably wrong.
Grasshopper essentially matches up branches first, then lists second. By "matching" I mean it processes them together. Simple example of the Line component - it will match the first branch of points in the A input to the first branch of points in the B input, creating lines between those points, then match the second branches, the third branches, etc. THEN, it applies the same logic to the level of the list (with a pair of matched branches {0;2}, match all the items in those branches to each other - first item in one branch to the first item in the other branch, etc.)
This is a tricky concept but it seems like you're already well on your way to understanding it from your definition - "PShift" is a critical tool in your path management arsenal. I hope this (overly long) response helps clear things up for you!
…
he TOF and TSRF indices. They show, how "distant" is your _PV_SWHsurface from the optimal _PV_SWHsurface surface in terms of tilt and azimuth angles.However, in your case we are not interested in TOF and TSRF indices. We would just like to know what are the _PV_SWHsurface optimal tilt and azimuth angles, regardless of the supplied _PV_SWHsurface.
So the circular surface supplied to the "TOF" component's _PV_SWHsurface input is irrelevant. It can be of any area, and any tilt/azimuth angle.The PV_SWHsurfacesArea output of the "PV SWH system size" component depends on a couple of factors:moduleActiveAreaPercent_ (leave it at 90%).
moduleEfficiency_,
systemSize_.Calculation of systemSize_ depends on your electricity demand, cost of the PV system, type of the object, country, local regulations etc. This is something that an engineer needs to determine.For example, in USA for a residential house in the Sunbelt, depending on finances, a household would try to cover 100% of its annual electricity needs with their PV system. Which means that the systemSize_ you chose needs to cover the annual electricity consumption. You can perform EnergyPlus simulation or use any other way to get the annual electricity consumption.
Ladybug "Photovoltaics Performance" component can calculate the optimal systemSize_ by given the annual electricity consumption.However the component is made to address fixed tilt and azimuth PV systems only.An approximate way to overcome this is to calculate the optimal systemSize_ for fixed tilt and azimuth PV system, and then multiply it with the "difference in %s" panel at the very right of the fixed_vs_tracker_PV2.gh file. Again, this is not what Ladybug "Photovoltaics Performance" component is made to do, but it will probably get you in a ball park.
Inputted 32 degrees for north_ direction is actually 328 degrees.This is due to Ladybug Photovoltaics being based on NREL model which uses clockwise angles convention. This convention is also most commonly used in solar radiation analysis.
Dubai weather data files are uploaded in here.
…
llowing for higher skyline and construction areas along public transportation corridors. Up until now, neighborhoods once characterized by two-story houses, gardens and ground- floor open shopfront programs, have been completely transformed by the introduction of fortressed monolithic residential and office towers, which lack any sort of urban street life.
The new master-plan, however, now requires buildings to have an open street façade to accommodate multiple programs. Led by tutors from UNStudio (www.unstudio.com), the AA Visiting School São Paulo will address the changes being prescribed by the new masterplan through the redefinition of the tower typology in the extending of the ground of street culture, green landscapes and ecological mediation along the vertical axis of these buildings. For this, the workshop will teach advanced digital design and fabrication techniques to explore a series of novel differentiating structural and environmental organizations in the redefinition of the São Paulo skyscraper.
For more information:
saopaulo.aaschool.ac.uk
Applications:
https://www.aaschool.ac.uk/STUDY/ONLINEAPPLICATION/visitingApplication.php?schoolID=303
For any queries, please email: brazilvisitingschool@aaschool.ac.uk.…
llowing for higher skyline and construction areas along public transportation corridors. Up until now, neighborhoods once characterized by two-story houses, gardens and ground- floor open shopfront programs, have been completely transformed by the introduction of fortressed monolithic residential and office towers, which lack any sort of urban street life.
The new master-plan, however, now requires buildings to have an open street façade to accommodate multiple programs. Led by tutors from UNStudio (www.unstudio.com), the AA Visiting School São Paulo will address the changes being prescribed by the new masterplan through the redefinition of the tower typology in the extending of the ground of street culture, green landscapes and ecological mediation along the vertical axis of these buildings. For this, the workshop will teach advanced digital design and fabrication techniques to explore a series of novel differentiating structural and environmental organizations in the redefinition of the São Paulo skyscraper.
For more information:
saopaulo.aaschool.ac.uk
Applications:
https://www.aaschool.ac.uk/STUDY/ONLINEAPPLICATION/visitingApplication.php?schoolID=303
For any queries, please email: brazilvisitingschool@aaschool.ac.uk.…
s levels of detail by subdividing a 6 sided cube mesh and projecting its vertices according to a referenced height map. This is one of the standard conventions for building full sizes planets. At the lowest level (0) the mesh planet is made of 6 pieces(each 32x32 resolution). The next level down (1) is made of 24 pieces... 6 divided by 4 = 24. Level (2) is 96 quads etc etc. The script will generate each quad at its sub-division level and compare edge vertices to neighboring quads. It will then make sure any shared vertices are in fact at the same projected vector. This ensures a planet quad with edge vertices that match.
The problems comes in texturing each quad.
If I build the quad as a nurb surface from points I can place the texture easily because each surface UV maps squarely to my texture map (which is also square).
If I build the quad as a mesh I cannot just apply the square texture to the mesh UVs. This is because when you unwrap the UVs from a mesh they will not unwrap like a nurb surface's UVs. Therefore to get the correct mapping I would have to manipulate each UV back to an evenly aligned array (which is 1024 points in a 32x32 resolution UV). Maya and blender have 'relax uv' and 'align UV' functions but they don't do the trick and manual corrections are out of the question. So why not skip the mesh method and use the nurb method?
I did this and there is a trade off. The nurb will accept the material texture I want with no other work on my end but when I export the object as an .obj rhino creates its own mesh to describe the nurb(with various unsatisfactory setting options). This works great up to a point because at some level the interpreted mesh will have vertices that do no match at the edges, ie .. creating visible seams in the mesh. The picture below is the nearly seamless planet at LOD(1) made of 24 quads, each with 32x32 vertice resolution and a 512x512 jpg texture running in Unity3d 5. It works but at close level there are seams. This will be resolved simply by having the next LOD(x) instantiate before getting close enough to see the seam but at core nerd level I want the seamless mesh.
So, I can make the seamless mesh but I can not realistically texture map it. I can also make the nurb surface from points and texture it at the expense of the edge vertices matching. I am at the split in the road but I want to have my cake and eat it too. Thoughts, comments, trolls...?
Thanks for reading =)
Footnote: For you pros I am not using seamless noise across the map I am using grasshopper to sew up my otherwise non perfect edges.
Other programs in the pipeline:
-WorldMachine 2
-Wilbur
-Photoshop
-Unity3d…
angel but when it comes to material behavior, stresses, surface tension i think that "our" tools are still no complex and powerful enough - and like i said i didn't really see the benefit in the work of my friend form the digital experiment.
so i think the question is is there a benefit from your digital experiment or do you rather stick to the physical experiment.
…
of 400 interlocked rings in a 20 X 20 grid.
V1 - A single 'suLoop' component doing 400 'SUnion' operations (20 X 20): 11.6 minutes
V2 - Two phases: 5 X 10 in phase one and 2 X 4 in phase 2, 58 'SUnions' total: ~88 seconds combined
V3 - Two phases: 4 X 5 in phase one and 4 X 5 in phase 2, 40 'SUnions' total: ~104 seconds combined
Again, these Profiler benchmarks don't reflect the whole picture, and might be affected by other things I was doing on the laptop while the code was running.…
Added by Joseph Oster at 12:29pm on March 23, 2017
,
and then I saw under Application that resources are managed by 'Icon and manifest'.
That can also be set as 'Resource file', but then a file path is required.
Is 'Icon and manifest' OK, or have I to set thing differently ?
Also, in the class code I inserted the following:
( I saw it mentioned here in the forum )
protected override Bitmap Icon { get { return Resources.colour; } }
( colour.png is the image file's name )
but VS gives me an error, saying:
Error 1 The name 'Resources' does not exist in the current context C:\Program Files\Rhinoceros 5 Evaluation\gh\plug-ins\ColourRhOb\Class1.cs 88 26 ColourRhOb
Did I miss a reference in the code ? Here they are:
using System;using System.Drawing;using System.Collections.Generic;using Grasshopper.Kernel;using Grasshopper.Kernel.Types;using Rhino;using Rhino.DocObjects;using Rhino.Geometry;
What am I doing wrong ?
Thanks
emilio
…