nted" in space (at instance definition creation phase): indicates the obvious fact that if garbage in > garbage out (try it).
2. Load the GH thing. Task for you: Using Named Views locate the points of interest as described further and make a suitable view. That way you can navigate rather easily around (hope dies last).
3. Your attractors are controlled from here:
The slider in blue picks some attractor to play with. You can use this while the K2 is running.
4. Don't change anything here (think of it as a black box: who cares how it works? nobody actually):
5. Enable the other "black box": job done your real-life stuff is placed:
6. Enable the solver: your "real-life" things start to bounce around:
7. Go there are play with the slider. A different attractor yields an other solution:
8. With real-life things in place if you disable the C# ... they are instantly deleted and you are back in lines/points and the likes:
9. Either with instance definitions or Lines/points change ... er ... hmm ... these "simple" parameters and discover the truth out there:
10. Since these are a "few" and they affect the simulation with a variety of ways ... we need a "self calibrating" system: some mini big Brother that does the job for us. Kinda like applying safely the brakes when it rains (I hate ABS mind).
NOTE: the rod with springs requires some additional code ,more (that deals with NESTED instance definitions) in order to (b) bounce as a whole and at the same time (b) elongates or shrinks a bit.
More soon.
…
ng/702/30
EDIT: DK2 works, not with positional tracking yet (14/09/15)
Source is here:
https://github.com/provolot/RhinoRift
Steps:
1) Download these files (also attached below):
https://github.com/provolot/oculus-grasshopper/raw/master/oculus-grasshopper_v0.4.ghx
https://github.com/provolot/oculus-grasshopper/raw/master/OpenTrackRiftGrasshopperUDP.ini
https://github.com/provolot/oculus-grasshopper/raw/master/oculus-grasshopper-test_v0.1.3dm
2) Download OpenTrack - http://ananke.laggy.pk/opentrack/, and setup/install. Once installed, double-click to open.
3) In OpenTrack, load the 'OpenTrackRiftGrasshopperUDP.ini' profile. Click the 'Start' button and move your Rift around - make sure that it looks like the Yaw/Pitch/Roll data is being sent. TX/TY/TZ will all be 0, as Oculus doesn't have absolute positioning data.
4) In Rhino, open the test 3dm. You'll notice that there are two viewports - called 'LeftEye' and 'RightEye'. These have been placed to mimic where the screens should be for the Oculus Rift --- but only when Rhino is in fullscreen mode, with the command 'Fullscreen'. The placement needs to be tweaked, but should work.
If you want to use your own model, you can load your own .3dm file in Rhino, then you can right-click on the viewport name, and go to Viewport Layout > Read from File. If you then load my test file, Rhino should open my two viewports, sized correctly, onto your model.
The placement of these viewports need to be tweaked; if you find a better viewport layout, upload an empty Rhino file with your viewports, and we can share eye-layout 'templates'!
5) In Grasshopper, open the .ghx definition. Everything that is multiple-grouped is a value that can be changed. Two things here:
- IPD: Set this and convert it to the proper units for your model.
- Left/right viewport names. In this case, leave this as-is, since you're using my example file.
6) Turn on the Grasshopper Timer, if it isn't on already.
7) In the GH definition, toggle 'SyncEyes' to be True. Then, in the left viewport, try orbiting around with the mouse. The 'RightEye' viewport should move around as well, pretty much simultaneously.
8) In OpenTrack, click 'Start', then toggle 'ReadUDP' to be True. You should see the 'OpenTrackInfo' panel fill with data that's constantly changing.
9) Move around the landscape with your camera, and when you set on a starting view that's ideal, click the triangle of the Data Dam component to 'store' the data.
10) Finally, toggle 'OculusMove' to be true. If all works correctly, both viewports should move based on the Rift's movement.
Let me know if you have any problems!
Cheers,
Dan…
Added by Dan Taeyoung at 11:47pm on December 10, 2013
radiance parameters to get rid of blotching. To add another level of complexity to my problem, I am running simulations with a translucent material with the following properties: void trans testTrans
0
0
7 0.478 0.478 0.478 0.000 0.010 0.178 0.635
I have had no issues with the renderings when I use clear glazing, as seen on this image:
However the blotching-issue becomes very noticeable when I introduce translucent glazing into the scene:
For the two above cases I used the following parameters:
_av_ is set to 0
xScale is set to 2
_ab_ is set to 6
_dc_ is set to 0.5
_aa_ is set to 0.2
_ad_ is set to 2048
_st_ is set to 0.5
yScale is set to 2
_ps_ is set to 4
_ar_ is set to 64
_as_ is set to 2048
_ds_ is set to 0.25
_pt_ is set to 0.1
_dr_ is set to 1
_pj_ is set to 0.9
_dp_ is set to 256
_dt_ is set to 0.25
_lr_ is set to 6
_dj_ is set to 0.5
_lw_ is set to 0.01
I ran another test with increased Radiance parameters and got the following output:
with the following parameters:
_av_ is set to 0
xScale is set to 6
_ab_ is set to 6
_dc_ is set to 0.75
_aa_ is set to 0.1
_ad_ is set to 4096
_st_ is set to 0.15
yScale is set to 6
_ps_ is set to 2
_ar_ is set to 128
_as_ is set to 4096
_ds_ is set to 0.05
_pt_ is set to 0.05
_dr_ is set to 3
_pj_ is set to 0.9
_dp_ is set to 512
_dt_ is set to 0.15
_lr_ is set to 8
_dj_ is set to 0.7
_lw_ is set to 0.005
Although the second blotching case is much better than the first, it is still very bad for hours when the sun is lower in the sky. The above images are rendered for a clear sky at 18:00 in Germany in a West-facing room.
Sorry for the long post! Can someone help? Kind regards, Örn
…
re my serial port was disappearing all the time when using the Leonardo on my laptop. I could only upload a sketch if I held down the reset button and then released it during the upload process... when the code was uploaded the serial port would immediately disappear again... which means I couldn't load any code which actually sent any Serial communication (which is pretty critical for Firefly). So I showed the problem to David Mellis (one of the founders of the Arduino platform who is getting his PhD at MIT, and he was confounded too). So he put me in touch with one of the main developers of the Leonardo board/platform (Zach Eveland) and I've been working with him to see if we can figure out the problem. As far as I can tell, the issue is that the Arduino driver seems to be failing on Windows 7 64-bit machines (like my laptop). He said one or two people reported similar issues during the development, but that he stopped hearing from them, so he thought it was fixed. We've tried several different things, but it seems the driver is failing at a really low-level. He's ordered a hardware USB analyzer so he can track the hardware communication between the computer and the board... but he hasn't shipped it to me yet. I'm hoping to get it resolved soon. As far as I can tell, the Leonardo is supposed to work almost identically to the Uno (it's just cheaper because it only uses 1 microcontroller... which handles both USB communication and running the code... where as the Uno has two microcontrollers on board which makes it more expensive). So, any code that runs on the Uno should (theoretically) also run on the Leonardo. Other than the code which I added to pick up the board type and load different parts of the sketch (which was a pretty significant overhaul of the firmata)... I only added a few lines to check if the serial port was available before sending the data over to Grasshopper (which seems to be required (or recommended) when using the Leonardo board. I've tested the code using the Uno and Mega and it works great... but I haven't fully tested the Leonardo support because of my machine. Apparently, this issue has only affected laptops like mine (others seem to work fine). If you're interested in testing the new version let me know and I could send it to you. You'd probably have to revert back to 0.8.0066 until I release the next version because David changed a few menu UI functions so I don't think the old version will run correctly (at least I don't think so). Anyway, let me know if your interested.
-Andy…
I am not "expert" enough, I will try to share my opinion.
Judging by the look of the building the simplest way to do it would be using T-spline to create the basic massing (like you try to sculpt a piece of rock to get the silhouette of that building). playing and tweaking mesh is easier in TSPLINE rather than NURBS (in this particular shape). after you've got the basic model done, convert it to NURBS then you can start to use GH to get some complex detail done.
one more advantage is that TSPLINE has special addon for GrassHopper. you can combo them together to get a more unimaginable result.
that is how I would approach the design.
and if you have got extra time,you could rebuild the model from scratch in GH, to get a much "tidier" model. and if next time you do a real project, it is also important to have someone to work on "smart" model like BIM. otherwise the engineer would get a massive headache when he receive your 3D model.
May be this is not a popular opinion, but I think sometimes you don't have to force yourself to build everything entirely in GH. if you can build the basic geometry in rhino, then it is better. afterall GH main function is a modelling aid for rhino. sketching it first on a piece of paper would help to get a better understanding about the geometry you are after. and then you'd know what to do.
one more thing, regarding about one reply, I wanna say, there is a big difference between designers and 3d modeller. as an architect and a designer myself, when I am given a task to design a building, sometimes I dont know what the building is going to look like at the early stage of the design., I prefer a less technical method and keep it as "concept" as possible (as there are many other things we need to think at once, name it, functionality, spacial use, structure, cost, environmental impact,etc etc etc, even politics and government stuff :P)
learning C#/VB/ or other language sure will be a point plus for you. but as dominik nuessen have mentioned, a good understanding of geometry and how it relates to the parametric design is the key point here.
because a good building is born from countless of planning and discussion, do not be afraid to be "wild" during the early stage. remember, some of the greatest architect in the world came from people who are dare enough to connect their dream into the real world.
thats all :) sorry for my bad english :)
…
ython patching via Rhinocommon CreatePatch being 7 of those seconds.
Currently, to avoid failed splits to remove the backgrounds, due to super shallow areas in skinny features that kiss the construction plane, I'm plane cutting a small amount below that construction plane, then moving the result back up.
I'm not using a Patch starting surface, as you can play with in the normal Rhino command, since it just sort of squashes broad curved mounds in ugly fashion, or else pulls them down to make ugly doughnuts everywhere around the input curves.
Details on how to use the CreateSurface command of Rhinocommon, hassles solved, is discussed here, with great all hours help from Peter Fotiadis, and I also discovered some clues from Djordje via Google, where he was massaging points into proper format:
http://www.grasshopper3d.com/forum/topics/python-longer-version-of-rhino-geometry-createpatch-expected
The highest level CreatePatch command doesn't accept a normal Python list of objects in a variable like the two more simple versions of the same command does. You have to regather them into a Rhino container, which is really a .NET container. I still don't know yet how to upgrade the Python parallel patch component to input the whole panoply of objects you can patch over in Rhino because I don't know what container exists to hold them all that won't break the command.
The point of this overall script is to now be able to arrange lots of mere flat surfaces, surfaces because those can define holes versus borders easily, and create real 3D single surface NURBS geometry that can then be surface morphed (equivalent of Rhino Flow Along Surface) onto other 3D models.
…
Added by Nik Willmore at 1:04am on February 27, 2016
Permalink Reply by Manuel Rodriguez 6 hours ago
Delete
yes!perfect! It has been a good example! The only thing that I would like to change is, that, instead of deform that following the control points on the surface's perimeter, I would like to deform all, with points in the shapes (in the middle of the circle for example). It is because I want, for example, the biggest circle in point 2, and the smaller circle in point 7. So, is it possible to do?
Summing up, is do the same, but changing the control points, putting them on the shapes (circles) instead the perimeter.
Thank you very much Danny and Chris, you are being really useful for me!
Thanks! Manuel
…
do is to make a structural analysis of the model with Geomgym in GSA and use that gathered data to optimize the variables.
I already created the beams (with their profiles and material) and I started with creating the nodes. However, I constantly get an error when I try to open the model in GSA. GSA doesn't recognize all of the nodes I created in Grasshopper and connected to the 'create node' box from Geometry Gym.
What I need to do is find all of the intersection points of the horizontal beams, the vertical ring sections, the diagonals and the supporting beams. These supporting beams carry the weight of the actual (concrete) floor of the footbridge and the load from the floor of the footbridge needs to be loaded to the intersection of the 'supporting beams' with the 'vertical rings' (as point loads), so not with the diagonals. And I also need all points on the first and last ring section to make that nodes restraint as pins.
The division of the polygons in the vertical ring sections is recognized in GSA, but I can't figure out what is going wrong in the model. Below I added the file as I made it with the creation of the nodes included. I also added a file where the creating of the nodes isn't added.
The first added picture shows the error in GSA and the nodes GSA can't find have a red circle around it. It also says that GSA recognizes '7 structures'...
The second picture shows that the loading of forces is correctly recognized and also the pins in the first and last ring section are applied correctly. But GSA doesn't recognize the intersection points of the diagonals with the ring sections and the supporting beams...
All of the intersections between the beams need to be hinged connections, without restraints. The hinges where the forces are loaded into (z-direction) are the intersection points of the 'supporting beams' and the 'vertical ring sections'.
All of the hinges in the first and the last ring section are pinned (x,y,z restraint - xx,yy,zz not restraint).
Could anyone please help?
Thank you in advance!
…
ion, extract structural data, produce 2d drawings, and exchange data with other external software. Nemo also includes free tools to create parametric shapes, such as Naca profiles, hydrofoils, keels, rudders, blade propellers, and sail plans.
Born in 2018 as an academic research project at ENSTA Bretagne, Nemo grew up since, immersed in professional naval architecture practice with L2Onaval.
From 2021, Nemo is now available for purchase with commercial or educational licenses. Following license levels are provided to fit every needs depending of user activity :
Free (Designer)
Level 1 (Section + Hydrostatics + Visualization)
Level 1 + 2 (Section + Hydrostatics + Visualization + Resistance + Structure)
We can also help you make best use of our software, provide project guidance, establish specific workflow and create custom tools.
Requirements
Microsoft Windows 10 or Apple Mac OS 12 Monterey :
McNeel Rhinoceros 7 SR26
(Other Rhinoceros, Windows and Mac OS versions have not been tested but may work)
Additional info
Food4Rhino Download
Discourse Forum
Facebook Page
Linkedin Page
Nemo Website
Credits
Authors : Mathieu VENOT
Contributors : Paul POINET, Laurent DELRIEU
…