supplied _values of _keys" notice.I tried running the "OSM 3D" component first with groundTerrain_ input. As I did not get the upper notice message, I closed down the whole Rhino so that I cut the waiting time. Then I tried running it without the groundTerrain_ input, and in some 15 minutes I got the following buildings:
I think I may understand what was causing the problem: when one takes large radii, it covers large areas, and with this area comes large number of information (keys and values). You can get hundreds of keys (or thousands). What can happen is that: these hundreds of keys, can exceed shapefile's capacity to story keys. So basically in case of radius 750 meters your "height" or "buildings:levels" keys somehow slipped beyond this allowable capacity. In case of 800 meters they were somehow allowed to enter (a bit bad term sorry) before the allowable capacity is reached. This depends on the number of keys named with letters which precede the "h" and "b".The best way to solve this issue is to know which data do you actually need, and use the "OSM Keys" component to generate the list of needed keys. In this way, only those keys that you need will be used, others will be disregarded.You do not even have to use the "OSM Keys" component if you know which specific keys you exactly need. Check the attached file below. I grouped the "OSM Keys" solution as "a" and a custom defined list of keys as "b".
2) The component running time might now be cut with picked "requiredKeys_" input I mentioned at the end the previous 1) part.
3) "OSM 3D" component's "randomHeightRange_" input is suppose to do exactly that: to randomly create 3d buildings (or 3d trees) when there are no valid "height" or "buildings:levels" tags.I have just changed one line the "OSM shapes" component code.I wonder if it would make any problem on your PC.Please let me know if LocationGrabber03_Gismo2.gh file works.…
Added by djordje to Gismo at 2:34pm on February 11, 2017
requiredKeys_ input of the "OSM Shapes" component. This is not the source of your problem though, but still I mentioned it in case you solve your issue, and afterwards want to use the "OSM Shapes" component.
The current (Win32Exception): WindowsError is the very same error message that you reported back in February.For some reason, your Windows is not allowing the Gismo "OSM Shapes" component to delete C:\MapWinGIS_installation_folder\gdal-data\osmconf.ini file.
You previously solved it by allowing the full access control to it, so I am not sure why it is not working now.Windows 10 seems to be the most overprotected operating system among other Windows versions, at least judging by the questions people asked so far.
Maybe you can try to turn off all the services which prevent users from changing certain files, like UAC or maybe even your antivirus?
Try this:
1) Close your Grasshopper and Rhino.2) Restart your PC3) When it boots up again, in your Start menu's search box type: "UAC". Click on it, and a new User Account Control Settings window will open. Set the bar on the left to "Never notify".4) Completely turn off your Antivirus.5) Check once again if your access control to the C:\MapWinGIS_installation_folder\gdal-data\osmconf.ini file is still set to the values you previously reported in this post.6) Right-click on "Rhino 5" icon and then choose: "Run as administrator".7) When Rhino boots up, run Grasshopper, and open the newest create_3dbuildings_trees_streets.gh file from here.If none of this helps, maybe you have some other application which deals with access to files on your system? Malware removal application or similar? Try turning it off too.…
Added by djordje to Gismo at 9:10am on April 3, 2017
t difficult to know how to modify your curves.
But if the curves are too weird or too different, it won't get much better. Remember you can still move control points while kangaroo is running.
The wrong of this method is that you don't have real control.
Setting deviation to 0 is usually not very useful unless your curves are almost good. With the wavy curves you sent me, I was happy with 2 (Deviation is something like a % of the curve length).
I much prefer the other method. Curves with few control points, you're able to define tangencies, you've got high degree continuity. With 4 to 5 cp, Galapagos will have a wide range of shapes to explore. With more cp you'll get smooth tuning. You can still take the relaxed surface as a base to draw such curves.
Other ways to increase developability.
First is obviously Sampling. This one is quite tricky. Higher sampling might result in either better or worse results. It's very cpu expensive too, because it involves a little more than (Sampling)² operations each time.
Second is the surface type. Usually Network surface is the best, and allows to join multiple planks with less sampling. It's more expensive too, and runs only with Rhino 5. Loft tight is a decent replacement.
The "Reverse curve list" button, and the multi planks mode when you input more than 2 curves.
But everything depends on your tolerances and that I can't answer.
There are still some bugs here and there, especially in the cusp filter part. Sorry about the unit of Gaussian curvature, I forgot to fix it. It's model units, so it should be [1/m²] in your case.
About the pc slowing, it's really vital to block timers all the time and turn phasma on and off when you must. I experienced some slowing today though, and I was worried, but it's normal now so it must have been Windows or some GUI thing...
Fred.…
but the order in which K gets changed is the same order that all of the other lists get changed.
For example (I'm not at a PC with Rhino/GH so I can't post an example directly) You want to order a cloud of points from the bottom up, i.e. by Z lowest to highest. Using the PComp component to decompose a point into its separate x, Y and Z components you can plug the Z output into K of the Sort Component. Sort will then re-order the Z values from lowest to highest, but the points you wish to order haven't be changed only a list of numbers. So you can plug the points into A and they will be reordered into the same lowest to highest order that the Z component was changed to.
Similarly if each of these points had a label that you wished to be attached to it at a latter point in the definition the list would no longer be in the same sequence. For instance if the original list was ordered in the X axis from 1 to 20 with one being the closest point to X = 0 and 20 being the furthest. Since you have rearranged the points, their labels are now 1 is the lowest and 20 is the highest, but we want them to remain the same as before with 1 being the closest to X=0. This is where the extra inputs on the Sort Component come in. Plug the list into B.
K is ordered smallest number to largest number
A is ordered lowest point to highest point
B is ordered so that 1 remains closest point to X=0 and 20 is furthest from X=0 …
ted_With_Honeybee.gh" file:
Warnings:
1. Honeybee cannot find RADIANCE folder on your system.
Make sure you have RADIANCE installed on your system.
You won't be able to run daylighting studies without RADIANCE.
A good place to install RADIANCE is c:\radiance
2. Honeybee cannot find EnergyPlusV7-2-0 folder on your system.
Make sure you have EnergyPlusV7-2-0 installed on your system.
You won't be able to run energy simulations without EnergyPlus.
A good place to install EnergyPlus is c:\EnergyPlusV7-2-0
Error:
1. Solution exception:Could not find a part of the path 'c:\ladybug\HoneybeeRadMaterials.mat'.
---------------------
I now reinstalled Radiance in the C:\Radiance folder and when dropping the Honeybee_Honeybee component on the canvas, I get the following:
Runtime error (DirectoryNotFoundException): Could not find a part of the path 'c:\ladybug\HoneybeeRadMaterials.mat'.Traceback: line 253, in __init__, "<string>" line 2200, in script
----------------------
[that is also the only error that I'm now getting when opening the 000 getting started file).
There is no c:\ladybug on my PC.
Note: In order to run the Radiance installer, I had to run as administrator. My user doesn't have write rights on the c-root folder (and no chance of getting that either... :)
Thanks,
wim
…
you post a screenshot of what the message coming from its readMe! output looks like?2) Close your Grasshopper and Rhino.3) Download "Revo Uninstaller Pro" from here. It is free for first 30 days, which is what we need.4) Right click on the RevoUninProSetup.exe and check if the file is blocked. If it is, unblock it.5) Run the RevoUninProSetup.exe file and install "Revo Uninstaller Pro".6) Uninstall "MapWinGIS" with "Revo Uninstaller Pro". It is important that "Revo Uninstaller Pro" deletes not only files from MapWinGIS installation folder, but also all other leftovers (as registry inputs). Here is a small tutorial on how to do that. Watch it from 6:10 till the end.7) Restart your PC8) When your Windows boots up, make sure that you are logged in as Administrator!9) In your Start menu's search box type: "UAC", which will find your User Account Control Settings. Click on it, and a new window will open. Set the bar on the left to "Never notify".10) Turn off your Windows Firewall.11) Then turn off your custom Firewall (in case you have another one, besides standard Windows Firewall).12) Completely turn off your Antivirus.13) Download again the MapWinGIS-only-v4.9.4.2-x64.exe.exe file from here.14) Right click on the MapWinGIS-only-v4.9.4.2-x64.exe file and see if it is blocked. If it is, unblock it.15) Right click on MapWinGIS-only-v4.9.4.2-x64.exe file and choose: "Run as"... Administrator.16) One the installation preparation steps start, choose "Full installation". Wait for the MapWinGIS installation to finish.17) Right-click on "Rhino 5" icon and then choose: "Run as administrator".18) Open the the ironpython_admin.gh file again, and again post a screenshot of the message coming from its readMe! output.19) Drop the "Gismo Gismo" component to Grasshopper canvas. Post a screenshot of the message coming out from its readMe! output.
So we will need in total three screenshots of the readMe! output messages.
Thank you once again for being patient, and sorry for the large number of steps.…
Added by djordje to Gismo at 1:52am on April 9, 2017
ed to develop a component that reads data from a Tracking Server we have built here in our lab, on top of VRPN Server. We developed a client library to communicate with this server and to read data from different devices through the server, making our life easier. The fact is that I need to update data received from a wiimote for example (at a regular time interval) and output this data to feed other components. Our first approach was to test the inclussion of that library into the context of Grasshopper and it worked, but just and only for the first time the component is created of course. Now the problem is to call this update function inside grasshopper multiple times and update the output. I'm new to grasshopper component coding so, it would be nice if I can get some response of an expereinced developer or at least somebody that have developed something like the example I'm exposing here. Some code is posted below to clarify what I'm saying.
...
using VRPNClassLib; //This is our class lib.namespace MyComp{ public class MyComp : GH_Component { private VRPNController controllerWiimote = new VRPNClassLib.VRPNController("WiiMote0@localhost"); private Wiimote wii = new Wiimote();
...
private double rotX, rotY, rotZ; public MyComp() : base("Al required params ok") { try { controllerWiimote.addDevice(wii); } catch (Exception e) { throw new Exception("No wii controller attached to the PC: -->" + e.Message); } }
...
protected override void RegisterOutputParams(GH_Component.GH_OutputParamManager pManager) { pManager.Register_DoubleParam("Pos X", "X", "Wiimote X"); pManager.Register_DoubleParam("Pos Y", "Y", "Wiimote Y"); pManager.Register_DoubleParam("Pos Z", "Z", "Wiimote Z"); } protected override void SolveInstance(IGH_DataAccess DA) {
// If execute MainLoop() here for the first time it works of course, but I need to continuously read data from wiimote, how do I do that
MainLoop(); DA.SetData(0,rotX); DA.SetData(1,rotY); DA.SetData(2,rotZ); }
protected void MainLoop() { controllerWiimote.UpdateData(); //this is the function that updates device data rotX = Math.Round(wii.getSensorRot1(),2); rotY = Math.Round(wii.getSensorRot2(),2); rotZ = Math.Round(wii.getSensorRot3(),2); }
public override Guid ComponentGuid { //Genere el GUID del componente get { return new Guid("8F9858D8-F18E-45f2-90EC-CC23523ACC4F"); } } ... }}
So any sugestions are welcome.
Cheers :)…
le of weeks. But if you are patient I think we will try to solve most of the issues.
For the TOF module, I find that no matter which inputs I provide, the optimalTilt is always 45 and the optimalAzimuth is always 180. I'm providing a weather file input and a north vector.
You are the second user who reported this which means that I was wrong in my assumption of setting a very low default value for the precision_ input, it should have been higher as more user friendly for beginners. Basically the TOF component results depend on the precision_ input. The best would be to set this value to 100, let your PC run the whole night, and in the morning you would get the most precise tilt and azimuth optimal angles. However, as some of us are using weaker PCs, and as sometimes the difference between results from precision_ = 100 and say precision_ = 30 is less than a degree, you can try using the precision_ = 30 for the start.
By default the precision_ is set to only 2. I will make sure this is increased in the next release of this component. Your topic definitively contributed to that!
Another thing I noticed is that "TOF" component does not support north_ inputs not equal to 0, in terms of graphical representation of results. It would probably take me some time to fix this. But the numerical results (which is what we need) are supported.
By looking at some other similar PV applications, I haven't seen the optimal tilt/azimuth graphical representation which supports change of north angle direction, so maybe this is not too much of an issue after all. The important thing is the numerical part, which is outputs correct results.
I'm then using the optimalTilt and optimalAzimuth outputs to supply the PV_SWH_SystemSize inputs for arrayTiltAngle and arrayAzimuthAngle - obviously this isn't actually doing anything useful at the moment as the outputs from the TOF are always 45 and 180.
It will make sence now, that you increase the upper precision_ input.
With the PV_SWH_SystemSize module, I'm having issues with the spacing it is providing between the rows of PV. I know it calculates this based on the sun position on a date based on the altitude of the location the weather file provides, but I think the spacing is far too large, especially for a rooftop array where the space is more like 1-2m normally. I'm trying to specify a summer date in the format the minimalSpacingDate output provides (15 NOV 15:00) so the calculated spacing is lower, but it just throws up an error whenever I do.
minimalSpacingPeriod_ input of the "PV SWH System Size" component accepts data from Ladybug "Analysis Period" component. But again, I apologize: as this is my mistake for not mentioning this in its docstring (that's the explanation you get when you hover your mouse over this input). I will make sure this gets added to the next release of "PV SWH System Size" component as well!
I also noticed a bug with "PV SWH System Size" component - at the moment the values it calculates are not correct if north_ input is not equal to 0. This is due to the component using another Ladybug developer's code which calculates sun position angles. For some reason this code does not support changing the north angle direction. I will contact the author to see how this can be solved.
So to be clear: it's not that all Ladybug Photovoltaics component do not support north_ inputs not equal to 0. It's that "PV SWH System Size" component currently does not due to the upper issue. And "Tilt and Orientation Factor (TOF)" component does not support for its graphical representation of results. I will see if at least the first one can be fixed.
Finally, it would be really useful to be able to get the PV_SWH_SystemSize component to actually produce the array it has created as Rhino geometry, so they can be viewed when rendered; is that possible? Also, is it possible to restrict the module so that it only creates rows with dimensions such that it fits within a surface you provide?
The PV_SWHsurface output of "PV SWH System Size" component contains Grasshopper geometry of all PV rows. Are you familiar with baking in Grasshopper?
I attached below an example of how to perform a shaded PV analysis. I rotated the whole context by 40 degrees so that the issue with "PV SWH System Size" component could be overlooked. When you determine your minimalSpacingPeriod_ input, we can internalize its "PV SWH System Size" output, rotate back your context and use "40" as a value for north_ input for all components.
Let me know if something was not clear, or if I replied vaguely to some of your questions.I apology in advance if it may take me a bit longer to answer to your next question. This spring period has really toughen my free time.…
content from the "bin" folder to the "c:\ladybug\terrain shading mask libraries 64-bit" folder:
So not the very bin folder, but its content.Just do this and the component will work.
Hi Abraham,
But just want to remind that Marios Tsiliakos developed a component for unblocking the LB_HB components and libraries (Unblock All and Unblock).
Thank you for the suggestion. I am aware of that component. I shared an article about it on my facebook account last year, at the time when it was released. It's a great component!There are still two issues with it: It edits the windows registry.I order for it to edit the windows registry it requires an account with administrator's rights.To unblock the file manually you do not need to have an account with administrator's rights.
BTW i installed the release-1800-x64-gdal-2-1-0-mapserver-7-0-1.zip without issues (just unblocking).
Yes, the GDAL 2.x.x and MapServer 7.x.x versions will also work. But I can not install them on my PC, therefor I can not provide support for them. The GDAL 1.x.x and MapServer 6.x.x are sufficient for what the component does.If you intend to seek support for any future issues, please install the latest GDAL 1.x.x and MapServer 6.x.x version as said by the component installation instructions.…
ing red flag.
1. Solution exception:name 'scriptcontext' is not defined
Reading the script, i think, maybe what i am after is not possible, using named views.
It outputs the named views resolutions, but whatever named view i select get maximized and also gets set to whatever selected active view i have in Rhino. This makes the order of the named views, in a 4 view layout, to rearrange which messes the setup i have.
Fiddling a bit with the script setting viewMaximized to False, does not maximize the selected viewport, but stops the auto update of the viewport size too. I guess this happens because since its not maximized it does not register to ActiveNamed view.
So if getting the named views resolutions, without having to click in each,without getting maximized and set to the current selected view is not possible i thought of the following.
What i tried was the example given in rhinocommon
from scriptcontext import doc activeViewport = doc.Views.ActiveView.ActiveViewportprint "{1},{2}".format( activeViewport.Size.Width, activeViewport.Size.Height)
and i used it with a timer, so that everytime i click in view,named or not, it gets the resolution. But for some reason my pc hates timer and makes my system luggy. I could work with the above script if somehow the timer, or any other method, was embedded in it, so that when i click in a view it updates the resolution. I have a feeling this is something easy to.
*edit timer also forces a redraw of objects in viewport (hence the lag?)
thank you again
best
alex…