ine (to greatness):
1. If I was you I'll use boundaries derived from offsetting inwards the inner/outer terrain loops where distance = top cone radius + something (better safe than sorry).
2. That way the "perimeter" chopped cones would be intact cones.
3. Additionally I would use the C# provided in some previous def that does controlled random points (no point with a min distance to any other > a given value [in plain English: top cone radius + something]) and avoid the intersection part as well. This speeds up the whole process and makes it far more logical with regard the structural approach: there's no reason to use "columns" that "overlap".
4. I'll provide a virus placement C# that works with DataTrees of points instead of making them internally using a BrepFace (that's the easiest of things). That way you can control the points properly and use the C# once (as an option) ONLY for putting viruses around using any branch you want.
5. "Columns"/cones derived from, say, 2 separate def sectors (why?) MUST been handled within a single DataTree where branch 0 contains the cones related with viruses and branch 1 (or more) contains the others
But what actually has Daniel to do with all these? If you have a vault in mind ... why bother with stupid cones et all? (Daniel does this for you). Provide some sketch related with the final goal. Or you maybe intend to feed K1/2 with stiffer springs (from cones) and less stiff ones (from top) - if so DON'T join the breps. …
I am not knowledgeable about google maps nor google maps api, but from what I read the two components will definitely show a bit different results due to different topography sources.If it is judging by this 2010 article, your Terrain Generator component offers much higher precisions for USA. Precision goes up to a couple of meters, which is amazing!!On the global scale it offers either SRTM 1 or 3 arc-second data or 30 arc-second GLOBE data. Again this is from the mentioned article, I couldn't find this information by searching the Google Maps website.Terrain Generator 2 component always uses SRTM 1 arc-second data from opentopography.org, and it is limited to 60 degrees north and does not have data for Antarctica. It does not come with satellite image either which is another very convenient feature that you have!I couldn't find information about the allowed radius provided by the Google maps api free account. I limited the "radius_" input to 100 000 meters, even though opentopography.org provides more than that (I successfully downloaded 300 000, but Rhino 5 was not able to create a topography on my PC from such a large amount of data).Even though I couldn't compare the results from two components, by looking at your upper example_LB_terrain_generator.gh definition: set the "I" input of "Surface from points" component to True. In this way the surface will be interpolated through points, which is what we want.
Again thank you for the permission, and I look forward seeing those high precision topography that Google maps offers!!…
lues are of any use from a display perspective as some IES files tend to have upwards of a 1000 numbers. That is why the candela values are visualized in the Rhino viewport.
2. Did you check out the (relatively) new Honeybee_IES Project component? It does produce a Bill of Quantity and also allows an export to Excel. I have explained this here: http://www.grasshopper3d.com/xn/detail/2985220:Comment:1474434
3. Eulumdat to IES is an easy fix. I wasn't aware that anybody had tested this using Eulumdat files. I will add this feature when I update the code next time.
4. Can you describe this simulation? The time taken by the simulation itself should not be that long because Radiance ( the calculation engine) has optimization algorithms to tackle multiple sources. My comment about multiple sources had more to do with Rhino than HB itself.
5. What do you mean by material design ? As in textures for surfaces?
Now, with regards to future work, we don't have a road-map of sorts at present as personally I am not quite sure about what might be useful to people who work exclusively with electric lighting. Most of the (vocal) users of Honeybee tend to be interested in Daylighting and that is where our development efforts have centered over the past year. You can read more about it here and here.
If there is some sort of consensus-based opinion from lighting designers on what would be useful we will look into adding new features.…
g a single design and you wish the others to be updated to that view also? There's a trade off here as we would need an extra button on the viewport (that we're trying to keep uncluttered as best we can)... I think it wouldn't be too bad. I'll put it on the enhancement list on git.
2) One of the best things about meshes in wpf is the simplicity... one of the worst things is lack of vertex shading which is a real pain. Getting into OpenGL, DirectX, etc. is not going to happen with the spare time I currently have, but what you suggest is quite a nice compromise (i.e. one colour per mesh). I'm still hoping I can figure a method to get vertex shading with wpf (stackoverflow shows others with similar struggles!), although it looks very tricky. We are looking into it!
3) It is, and yes this is a big problem when the mapping between genotype and phenotype is indirect (for example, the gh definition contains a random component or something). You can compare on the phenotype as you suggest, but this takes computational effort, such as some form of shape analysis. One hope is to compare genotype and phenotype 'solution' spaces (and thus give a measure of directness). On the TODO list!
4) Hmmm, not thought of that one. Good idea, a kind of import design into population. Thanks! That could work nicely.
5) Current idea is to maybe save a population history file, which would as you suggest act like a state manager of sorts. The data structure is quite complex in order to future proof the history approach, but we think we have a nice way of doing it and will be in the next release.
Thanks again for your feedback Chris, its much appreciated.
Best wishes,
John.
PS: What is that mesh shape you have there? Curious.
…
cooling energy" variable tangled with other output variables in one line in the idf file:
1. current code of line 2314 andd 2315:
2. current output variable section in the idf file:
3. revised code with the "\n" new line symbol added:
4. correct IDF file with the cooling loads outpu variable in a separate line:
5. cooling loads can now be correctly calculated and read:
Please kindly verify if this is the source of issue, and if this is the case, I'd appreciate if the current runEP component can be updated.
Thanks.
- Ji.
…
face:
3. However, the readEPSrfResult component cannot recognize this variable:
4. Nevertheless, for unknown strange reason, I'm unable to reproduce the above warning for this test file later, and it seems that this variable can be read by the readEPSrfResult component, for now....
5. I got the same warning in other GH file I'm testing which included the surface irradiance as output variable. So, I'm not sure why the warning is not consistent across different files ...
Appreciate if you can kindly advise.
…
have some spare time please fill in my 3D Printing Open Survey - If you could make almost anything, what would it be ? Updated results are publicly available after completing questionnaire (Please press "Wyślij" - Send button and "Wyniki ankiety" - Results button at the end). This survey will be used to evaluate demand for 3d printing services globally. It consist of 30 questions about: - open-source 3d printers - future of additive manufacturing - 3d printing services - ecology in 3d printing - copyright issues and 3d printing Three example questions: 2. Which of the following 3d printing applications is the most interesting? * - Things personalization - Printing food - Attempts to print structures resembles in functioning living tissues or blood vessels - Creating impossible or difficult to create by using conventional technology things - Printing rooms or buildings on earth/moon - Printing chemical compounds (for example drugs) - Using in renewable energy sources - Printing parts and/or mechanical vehicles 3 . Have you ever heard about cheap DIY 3D Printers (for example RepRap, PrintrBot, MakiBox A6) ? * DIY - Do It Yourself - Yes - No 4 . When 3D Printers will become one of the typical household appliances ? * - After 5 years - After 10 years - After 15 years - After 20 years or later - Never - I don't know Feel free to ask questions!…
nt document units is in MetersConversion to Meters will be applied = 1.000[1 of 8] Writing simulation parameters...Can't find ddy file next to the EPW.Extreme values from the weather file design will be used instead.[2 of 8] No context surfaces...[3 of 8] Writing geometry...[4 of 8] Writing Electric Load Center - Generator specifications ...[5 of 8] Writing materials and constructions...Runtime error (KeyNotFoundException): honeybee_ExtraConstrPropsTraceback: line 2152, in main, "<string>" line 2364, in script
In order to solve it, I followed the topic below:
http://www.grasshopper3d.com/group/ladybug/forum/topic/show?id=2985220%3ATopic%3A1601436&xg_source=msg
In my case I only ran into further troubles with IDF file and some message about missing ControlProgram in Objects.
I am uploading the gh file for you to see. PLS help me, I ran out of ideas.…
(http://www.food4rhino.com/app/quelea-agent-based-design-grasshopper) take like 40 seconds when the toggle activates to go from one end of the ramp to another.
With proximity 3d i'm analyzing each instance the agents are closer than x units. In picture 3 we can see that in 212 instances the agent are closer than those x units.
Finally all the genes that controll the ramps are connected to the G of octopus component and one of the conflicting objectives connected to the O of octopus component is the number of instance quelea agents get close.
So the thing I need is to iterate the ramps controling the genes with octopus but activating the boolean toggle (quelea run) each time the ramps are modified so the agents take 40 seconds to perambulate the environment, analyze the instance they get close and let octopus iterate again searching for a optimized environment.
…
stand everything so far but I will nevertheless try to give some feedback and then extend this list once oi gained more knowledge about it.
1) It would be nice if you could set and save a view vector for all models at the same time. that would make the comparison a lot easier because every model has different interesting views
2) Color could be helpful i think. Would it be possible to read the mesh vertex color values? If that not straight forward maybe the component could have another input which takes a list of colors for each mesh you input in the geometry input.
3) Is the closeness of two outcomes only computed by the closeness of the genes? Sometimes you have very ruff parameter spaces where a little shift in the genes can make quite big changes in the outcome. Would it be possible to compute closeness or similarity of two outcomes based on the outcome itself? For example compare the resulting meshes to each other?
4) It would be also great if you could replace a certain outcome with a solution that you manually generated by altering the sliders. That would be also a way to influence the direction.
5) I see that you are still working on the history. It would be great if one could use biomorpher as well to store you favorite versions of a definition. Something like a more advanced version of the state manager where you can also see the states and crossbreed them easily.
Best, Chris
…