algorithmic modeling for Rhino

Search Results - 双色球2017137杀号10码-『8TBH·COM』五行与双色球号码最新--2023年3月20日5时8分56秒.H5c2a3.1jpbjndlp-gov-hk

Comment on: Group 'FabCafe Tokyo': 思った感じになりません。 balls の代わりにplanarカーブを直接入れてみましたがエラーが出ます。ファンクションにしてみたところ、forループので作った数値が反映されていません。ファンクションのインスタンス？を出力していないと思い上記のようにしましたがエラーが出てしまいます。以上の事から自分の認識が正しいのかよくわからなくなりました・・・ python自体の深いところをわかっているわけではないので余計こんがらがりました。そこで、for b in ballsはどのような条件または使い方であれば使えるのでしょうか？そして、上記のように別のオブジェクトに対しての使い方はどのようにすればできるのでしょうか？２：同じファンクション内のdist = rs.Distance(self.pos,b.pos)についてですがこの文章も　for b in balls によってｂはBallのインスタンスであると定義？されたためb.posがｂの位置であると分かるのでしょうか？ pythonは定義しなくても動いてしまうのでどのような時に使えるのか文章見ただけではよくわかりません・・・大変細かいことかもしれませんが、よりpythonをしっかりと理解するためにも、どなたかわかる方ご教授いただけると幸いです。…; Added by Inu to FabCafe Tokyo at 9:48am on March 1, 2015

Comment on: Topic 'Terrain Generator : Invalid Brep': it seems that was this. Now all is working fine ! Glad that it worked! But I am still a bit worried. Gismo components only modify the gdal-data/osmconf.ini file and no other MapWinGIS file. So your MapWinGIS installation files should not be compromised. The fact that you did not get the "COM CLSID" error message when running the "Gismo Gismo" component suggests that MapWinGIS has been properly installed. So I wonder if the cause for the permanent "invalid shapes" warning has again something with the fact that your system is again not allowing the MapWinGIS to properly edit the osmconf.ini. Maybe this problem will appear again, and again, and reinstallation of MapWinGIS every time can be somewhat bothersome. - About the terrain generation, is it possible to have the texture from google or other provider mapped onto the terrain surface from gismo component ? (Same as using the ladybug terrain generator in fact). I try to used the image extracted by ladybug component and then applied it to the gismo terrain but the texture is rotated by 90°. The issue with the rotation can be solved by swapping/reversing the U,V directions of the terrain surface. A slightly more important issue is that terrain surface generated with Gismo "Terrain Generator" component might have a bit smaller radius than what the radius_ input required. This stems from the fact that the terrain data first needs to be downloaded in geographic coordinate system, and then projected. Some projecting issues may occur at the very edges of the projected terrain, so I had to slightly cut out the very edges of the terrain which results in the actual terrain diameters being slightly shorted in both directions. This means that if you apply the same satellite image from Ladybug "Terrain Generator" component to Gismo "Terrain Generator" component the results may not be the same.I attached below a python component which tries to solve this issue by extending the edges of Gismo "Terrain Generator" terrain, and then cutting them with the cuboid of the exact dimensions as the radius_ input. Have in mind that this extension of the original terrain at its edges is not a correct representation of the actual terrain in that location. But rather just an extension of the isoparameteric curve of the terrain surface. So basically: some 0 to 10% (0 to 10 percent of the width and length) of the terrain around all four edges is not the actual terrain for that location, but rather just its extension.The python component is located at the very right of the definition attached below. Also, if you would like to use the satellite images from Ladybug "Terrain Generator" component along with "OSM shapes", sometimes you may find slight differences in position of the shapes. This is due to openstreetmap data not being based on Google Maps (that's what Ladybug "Terrain Generator" component is using), but rather on Bing, MapQuest and a few others. - About the requiredKeys_ input of OSM shapes, I understand what you mean and your advice, but in most cases I use it, the component was working fine even without input. I think it's better to extract all tags, values and keys of the selected area, instead of searching for specific ones as I try to find all data related to what I want after, isn't it ? To check what keys are present on the area also. Ineed, you are correct.I though you were trying to only create a terrain, 3d buildings and maybe find some school or similar 3d building, for these two locations. The recommendation I mentioned previously is due to shapefiles having a limit (2044) to how many keys it can contain. This requires further testing of some big cities locations with maybe larger radii, which I haven't performed due to my poor PC configuration. But in theory, I imagine that it may happen that a downloaded .osm file may have more than 2044 keys. In that case shapefile will only record 2044 of them, and disregard the others. That was my point.But again 2044 is a lot of keys, and I haven't been checking much this in practice. For example, when I set the radius_ to 1000 meters, and use your "3 Rue de Bretonvilliers Paris" location I get around 350 something keys, which is way below the 2044.Another reason why one should use the requiredKeys_ input is to make the Gismo OSM components run quicker: for example, the upper mentioned 350 something keys will result in 350 values for each branch of the "OSM shapes" component's "values" output.Which means if you have 10 000 shapes, the "OSM shapes" component will have 10 000 branches with 350 items on each branch (values). This can make all Gismo OSM components very heavy, and significantly elongate the calculation process.With requiredKeys_ input you may end up with only a couple of tens of items per each branch.Sorry for the long reply.…; Added by djordje to Gismo at 8:57am on June 11, 2017

Event: Encodedfields Polymorphism . Advanced Digital Design Workshop: ne diverse digital design methodologies and the use of different tools such as Autodesk Maya, Rhinoceros and Grasshopper. Building up technical skills will provide the attendees with a solid platform from which to start rethinking and exploring innovative architectural ideas in collaboration with the team and the tutors. URBAN FIELDS Phase I In the first part of the workshop attendees will be looking at field conditions and how to generate and design such fields that can help structure a possible urban condition in Florence. We will be exploring dynamic systems, geometric systems and network theories to generate and design an abstract field condi- tion that extends the urban experience of the city onto the vertical dimensions of towers. Simple operations that would span variations from an initial state will give rise to high level of com- plexity. The goal of this exercise is to create a rich and diversified intel- ligible urban space that can be later on subjected to local inter- ventions and zooming in to locally enhance each design. AGENT - BODIES POLYMORPHISM Phase II The second part of the workshop will build upon first phase; par- ticipants will select one archetype (high rise tower) as a study model for further development. Besides engaging with multi agent algorithms design strategies, attendees will address strategic utilisation of structurally and environmentally generated morphologies to design coherent and highly differentiated tower exo-skeletons. Tutors will introduce agent-bodies polymorphism in order to explore the generation of structural aware and capable geom- etries through agent based formation of non-linear hierarchies and emergent patterns. These agent-bodies will operate in a complex spatial manner to form structure, partitions or enclo- sure and will operate across scales, creating a poly-scalar level of detail. Attendees will speculate how autonomous systems can cre- ate new structures and intelligent distribution of structural elements, about new collaborative strategies of construction and the performativity they will evoke (performance, effects, responsiveness, interaction). Fees Early registration (before 1st June) Students 390€ - Professionals 440€ Late registration (after 1st June) Students 490€ - Professionals 540€ More info and Applications https://www.ax-om.com/edu/polymorphism/ …; Added by Martina Rosati at 6:22am on April 20, 2018

Comment on: Topic 'DWG,DXF or 3DM to PLT and HPGL': both my plotter/cutter and wide format printer. I had been running the plotter from my main work laptop - a Win10 machine via the plotters USB port. As it turns out you can't get Win XP drivers for this USB connection so I needed another solution. I tried to use the plotters DB25 serial port connection using an old DB9 to DB25 modem cable I had in my collection = no luck the plotter wouldn't talk. A bit more research and it turns out these plotters need a 'null modem' cross over cable to operate. I found a pic of the correct wiring online and made up my own with some cable and connectors from the local electronics hobby shop. With this hooked up and using Hyperterminal I was able to fire some codes to the plotter directly and get a response back - winning! At this point I got my original code working with the 'net use' redirect from LPT1 to COM1. HOWEVER - being that the plotter was now on a COM port there are a few more interesting things you can do with it - one is being able to read the paper size/cut area from the printer. So what I needed to to was find a way to send and receive data to/from the plotter using the serial port. A bit of research into .NET's serial port interface and using a bunch of small pieces of test code I have manged to completely re-jig this driver. Upgrades include: - Direct Serial Port comms using Null Modem cable (a USB to serial adaptor + null modem should also work) - Plot area read from the plotter - a rectangle the size of the plot area is placed on a separate layer and coloured red - Testing to see if selected plotting curves are both closed and inside of the cutting area - with errors shown and exiting if they are not right. - After plot 'parking' of the plot head at the end of the cut items + an adjustable offset (currently requires manual resetting of origin on the plotter before for next cut) Great thing is it is now 100% running within Rhino Python - no DOS command line calls = no flashing up of the CMD wind. Also no temp files needed on the HDD and no limit to number of curves that can be plotted - tested with 200 or so with no issues. Overall very happy with whole project - have learnt a LOT about Python and .NET interfacing AND ended up with a very handy/useful tool. Cheers DK # This code is a WIP # It plots directly to a DGI Plotter# via the serial port import System.IO.Ports as Portsimport rhinoscriptsyntax as rsimport time #Some setup valuescom_port = 'COM1' #change to match plotter port baud_rate = 9600 #change to match plotter settingplotter_step = .025 #mmfinsh_offset = 10 #mm #Delete old cutting area and cut objectsif rs.IsLayer('Cutting Area'): rs.PurgeLayer('Cutting Area')if rs.IsLayer('Cutting Objects'): rs.PurgeLayer('Cut Objects') #Setup Serial PortMyport = Ports.SerialPort(com_port)Port_Write = Ports.SerialPort.WriteMyport.BaudRate = baud_rateMyport.ReadTimeout=5000 #5 secsMyport.Close()Myport.Open() #Setup PlotterPort_Write(Myport, 'PU;PA0,0;IN;\n')Port_Write(Myport, 'SP1;\n')Port_Write(Myport, 'PA;\n')time.sleep(2) #Read the Paper size from PlotterPort_Write(Myport, 'OH;') #HPGL read limits codetime.sleep(2) return1 = ''papersize = ''count = 0char_in_buffer = 0chars_in_buffer = Ports.SerialPort.BytesToRead.GetValue(Myport) if chars_in_buffer == 0: print 'Plotter not ready' Myport.Close() exit() while (count < chars_in_buffer): return1 = Myport.ReadChar() papersize = papersize + chr(return1) count = count + 1 papersize = papersize.split(",")rect1 = (float(papersize[2])*plotter_step)rect2 = (float(papersize[3])*plotter_step) print 'Cutting area = ' + str(rect1) + 'x' + str(rect2) #place cutting area curve on its own layer, make it red and lock itplane = rs.WorldXYPlane()cutting_area = rs.AddRectangle( plane, (rect1), (rect2))rs.AddLayer (name='Cutting Area', color=(255,0,0), visible=True, locked=True, parent=None)rs.ObjectLayer(cutting_area, 'Cutting Area') #get plotting objects allCurves = rs.GetObjects("Select curves to plot", rs.filter.curve) #test to see if these are closed curves - exit if not for curve in allCurves: test_closed = rs.IsCurveClosed(curve) if test_closed == 0: print "One or move of these curves are not closed" Myport.Close() exit() #test to see if these are inside cutting area - exit if not for curve in allCurves: test_inside = rs.PlanarClosedCurveContainment(curve, cutting_area) if test_inside==0 or test_inside==1: print "One or more of these curves are outside of cut area" Myport.Close() exit() #All ok - convert to points and send data to printer rs.AddLayer (name='Cut Objects', color=(0,255,0), visible=False, locked=True, parent=None) for curve in allCurves: Port_Write(Myport, 'PU;PA;SP1;\n') polyline = rs.ConvertCurveToPolyline(curve,angle_tolerance=5.0, tolerance=0.025, delete_input=False, min_edge_length=0, max_edge_length=0) points = rs.CurveEditPoints(polyline) rs.ObjectLayer(polyline, 'Cut Objects') # PU to the first point x = points[0][0] y = points[0][1] Port_Write(Myport, 'PU' + str(int(x / plotter_step)) + ',' + str(int(y / plotter_step)) + ';\n') # PD to every subsequent point i = 1 while i < len(points): x = points[i][0] y = points[i][1] Port_Write(Myport, 'PD' + str(int(x / plotter_step)) + ',' + str(int(y / plotter_step)) + ';\n') i += 1 Port_Write(Myport,'PU;\n') #find the far end of the cutbox = rs.BoundingBox(allCurves)far_end = str(box[1])far_end = far_end.split(",")far_end = far_end[0]far_end = float(far_end)/plotter_stepfar_end = (int(far_end))+ finsh_offsetfar_end = str(far_end)print (far_end) #return plotter home and close portPort_Write(Myport, 'PU;PA' + far_end + ',0;IN;\n')Port_Write(Myport, 'SP1;\n')Port_Write(Myport, 'PA;\n')Myport.Close()time.sleep(10)…; Added by David Kay at 4:50am on November 18, 2017