"meshed" i assume that meant converting Surfaces with MeshUV\DeMesh?, and from your screenshots thats a substantial number of vertices and therefore lines to draw, well worth it though from the results!, i agree with your answer to 3) that a more automatic solution is required,.
1) By mesh, I should have said produce a surface – then convert surface to mesh – followed by de-mesh to get access to vertices etc.
You can reduce the resolution of points if you need to, depending on your hardware. The more points you use the harder and it is to compute a solution, however the more points you use, the more accurate your interpolated surface. You need to find your own balance between speed and accuracy.
- ..thats great news, equalizing vertex numbers is exactly what i need to do since my Blend surface "keyframes" by nature will likely have unequal point counts. However, a) ..when using default Rhino surf's your intruiging def. starting to work for me only after i replaced you "custom" Domain(VB\Python?,let me know) with Deconstruct Domain. then it connected each surf's vertices but did Not produce an intermediate surface or points. b) ..when using my IDENTICAL Blend surf's in your def. with Deconstruct Domain and Merge comp's it then produced intermediate vertices,. see def. screenshots or i can send def's i you like,. I'll also produce the 2nd, Non-identical Blend surf keyframe to test in your def.
2) I am not sure what you mean by my ‘custom domain’ are you referring to the definition in my second post – or the post I sent for David to look at? Perhaps you can circle the component and upload a screenshot so I know what you are referring to? Your second screen shot appears to have worked OK
- .. agreed, 6) does or will your latest def. contain more automated, vertex correspondence, Ln creation?
3) No, I moved away from morphing surfaces and moved my solution to generating surfaces based on point data. This cut out the requirement for me to generate the surface to begin with and allows very automatic production of surfaces from data out of excel. Perhaps this would also be a good solution for you? You could:
Move your point data to excel, by exporting the x, y, z of your vertices for each surface.
Use excel as your information repository then write a definition to interpolate between your start and end points from excel.
This is basically what I have done now, as I have 1700 different ‘surface’ snap shots from the data I am working with.
- ..perhaps i missed something, but after using Brep > Join on my polysurface SDivide still saw it as subsurfaces instead of a single surface,.
4) Sorry, perhaps I should have tried that – I didn’t get as far as trying to subdivide. There should be a way to then re-create as one surface if it is necessary… I will try and find out when I have time.
How many sets of surfaces are you trying to merge through? It is also possible to morph from 1 to 2, 2 to 3, 3 to 4 …… x-1 to x by using a slider which calculates the range and picks the correct two surfaces to morph. If you need more info let me know and I will write something. - ..that sounds perfect, esp. since the sets of surfaces will be as nearly unlimited as the feature film they're modeled from. Yes, i'd love to learn more info\def's on this subject, thanks,..
Sounds to me like you might be better taking the excel read, interpolate route? If you have nearly unlimited surfaces, then they must be generated from some other data source yes?
Let me know your thoughts, if you would like to discuss anything I am happy to make myself available on skype at some stage to talk you through some of this stuff.
Cheers
Lyndon
EDIT: I have uploaded a video, which shows a surface generated using excel data - which basically loops between 'snapshots in time' to give you an idea of whether this would suit your needs.
https://www.youtube.com/watch?v=f9XAne9byQc&feature=youtu.be
…
e existing wires.
2) The capsule display is very similar to the first graph, but instead of drawing a line connecting relative y-values for each slider, each slider get's assigned a colour (from dark red to yellow) based on it's relative position. It allows you to see whether two genomes are similar or not without taking up too many y pixels.
3) This is a tricky one to explain. Every genome in a single species has the same 'dimensionality'. For example, if there are only two sliders you can say that the entire genome space for the species is 2-dimensional. For every possible combination of these two sliders, there is a fitness value (or a height) on this two dimensional plane. If your genome consists of 6 sliders, then we're talking about a 6-dimensional space.
As you probably know, distances between points are computed with the same formula, regardless of the dimensions of these points. Pythagoras' method works for all points with identical and integer dimensions. So even though I cannot display a 6-dimensional genome space on a two-dimensional computer screen, I can compute the distances between all the genomes in a species/generation. This then gives me a matrix with the distances from every genome to every other genome. I translate this distance matrix to a node-spring particle system and solve that system in two-dimensions, which ultimately results in the point-scatter graph you see on the screen.
The axes of this 2D representation of the ND distances are meaningless. The absolute position of the points inside this grid are governed partly by chance. However the relative positions are meaningful in that they convey which genomes are similar and which ones are different. Points which appear close together represent similar genomes, points which appear far apart represent different genomes.
Basically it becomes very simple to see the entire collection of genomes and get a feel for how varied the set is. You can often even see sub-species appear as distinct clusters of points.
4) For every generation, I display the fittest genome (upper boundary of yellow area), the worst genome (lower boundary of yellow area), average genome fitness (the thick red line) and the standard deviation of the fitness distribution in both directions (the orange area). Everything below the average is hatched.
Have you seen the Blog entry about galapagos?
--
David Rutten
david@mcneel.com
Seattle, WA…
Added by David Rutten at 1:37pm on November 26, 2010
ign to every location in the space is the result of the fall-off equation. F/D² in the Metaball componenty, where D is the distance from the point to the location you're measuring and F is the scaling factor:
3) You repeat this for all the points, giving you a collection of revolved hyperbola:
4) Add the elevations for all hyperbolas together, just a simple A+B+C process:
5) You intersect this final landscape with a horizontal plane. The elevation of this plane corresponds with the iso-surface value. If we do it for a bunch of planes, you get the following result:
6) The interior of each slice represents the metaball, or rather the boundary of each slice:
That is the theory anyway, in order to actually get a speedy result the algorithm approaches the problem from a very different angle, but the result should be the same shape.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Rhino plugins to work in the mac version. As I understand it, what is holding up the GH making it over (fully) to the mac version is its dependence on the graphics libraries for Windows. There is no easy direct translation here, so, this is still under development. There is info spotted around the forum, you just need to dig deep enough to find it, and see that there is development of GH for Mac, but still, we should not hold our breath as there are significant hurdles to overcome. These hurdles are just technical, and should have a solution. Below are some references that point to the graphics issue I am discussing as well as a list from David where he does state that he is working on the Mac version.
Another positive note is that in Rhino 6, GH will be along for the ride...meaning (as I understand it) that we will not need to download GH after installation, it will be part of the Rhino install. I think this is a positive note as it means that GH will be more associated with the default Rhino experience, an experience which should carry over to the Mac version.
So, to sum up:
1. GH for Mac will probably happen.
2. Seems all of the code that does not depend on the graphic part (the logic in the components, Rhinocommon) already works in the mac.
3. Other Rhino plugins are already making their way to the Mac.
4. GH is becoming part of the default Rhino experience, and should probably carry over to the Mac experience.
5. Don't hold your breath. When it will happen is not under anyone's control necessarily. The solution needs to be practical in order for it to be rolled out.
My $0.02.
References:
http://www.grasshopper3d.com/forum/topics/partial-developer-absence?commentId=2985220%3AComment%3A929795&xg_source=activity
http://www.grasshopper3d.com/forum/topics/grasshopper-for-mac-update?xg_source=activity…
th a graphic editor (GH) hosted in a CAD app that has primitive assembly/component capabilities and/or feature driven ops (Rhino). Did I've mentioned that Rhino is a surface modeler? (meaning the obvious).
3. Imagine a "seed" collection of assemblies related with various membrane components made in SW. Say: geometry (prior solid ops) and parameters (the feature driven part of the equation, in most of cases managed with some RDBMS). You should port these to GH (a variety of ways exist for that) and create the bare minimum of "solids" in GH as instance definitions. There's 2 main reasons to do that: (a) effectively communicating back on an assemply/component schema (via STEP) and ... (b) achieving manageable collections when in GH. These are critical for clash detection (when outlining some topology in GH, therefore NEVER work just with "curves") and "variation" control of some sort (up to a point). Of course for high class designs (where the devil hides in the details) this is NOT the best imaginable solution ... you'll need CATIA for such an integrated (all in one) procedure. On the other hand many could (wrongly) argue that CATIA is expensive (rather naive argument if a company has a certain turnover).
4. So, in general I would strongly suggest to use instance definitions of items in some sort of "intermediate state" of detail (an 100% undoable task without code) structured in such a way (classic assembly/component MCAD mentality blah, blah) that SW could take benefit of a possible modified "base topology" and proceed by finishing variations of the given assembly (feature driven stuff as usual).
5. Then export (STEP 214) back portions of the assemblies (and parameters used) to R/GH if and when this is required (for instance for BIM disciplines ... but Rhino is not a BIM app, nor it would ever be).
6. If you are familiar with code matters ... start thinking the whole puzzle that way, if not my advise is to find someone to design such a "procedure" (say an "app") using solely code, but this is not a task for the inexperienced by any means.
best, Peter…
release.
2. Of course, I agree the support is woeful for this at present. Find attached an example of trying to find a completely new definition for a target geometry. Using galapagos with these inputs help the machine get quite close. Obviously, its a combinatorial problem so bloat is an issue.
3. It's a great idea, and a thought I've had on the todo list. It's trickier than you think though due to the way you have to instantiate a component on the canvas. In addition, persistent data in the ingredient components that exists in the generated ones is possible.
4. Again, yes options for the inputs is a good idea and one I'm working on.
5. Indeed. Ideally, you should be able to put clusters in the ingredients. This is where things start to get very tricky without the help of David :) . If I can get user objects to work, then that's a step in the right direction. At present, you need to compile new components to get Embryo to include them.
6. Because it was the easiest to implement with the gene pools. Revising this to make it more efficient is a good idea, because at the moment it aint.
7. Good idea. I can include that in the options component.
Finally, just to say implementation in Grasshopper has its pros and cons, it's obviously not built for this kind of thing. In the future, I'd like to build an independent plug-in for Rhino that will handle GP better.
Anyway, thanks for having a go! I still intend to make the repository public.
As to what I do, I used to lead the Ramboll Computational Design team in London but we've all gone our separate ways now. I'm now a lecturer in Computational Design at the University of West of England (UWE) in the UK.
…
file. A TSpline made thing in fact.
2. This atroci ... er ... hmm ... I mean unspeakable beauty uses an exo-skeletal load bearing structure hence is THAT big (BTW: Apparently nobody knows what thermal bridge is nor thermal expansion nor vapor condensation ... but these are "minor" details these holly blob days, he he).
3. 2 means that some nodes of that "grid" MUST "meet" floors in order to support them and (hopefully) withstand some seismic forces. BTW: A Richter scale 9 (for an hour) is all what this building actually needs (that's acid "humor").
4. The "smarter" way to do this is to spread "some" (i.e a lot) random points (Note: David's algo yields "evenly-spaced-points" within the limits of the possible) on the guide blob (a polysurface in fact).
5. Then ... you need some algo that tests proximity AND "adjusts" the Z in order to have some node points "co-planar" (Z) with the floors.
6. Then you triangulate all that stuff (the points, that is) using some decent Ball Pivot Algorithm (NOT Delauney) and you get a triangulated mesh that "engulfs" the guide blob. If you want some quads (as shown) this is also possible.
7. So you have edges ... i.e poly lines (per mesh face) and if you offset them ... you have "drilling" profiles that you must use against a second guide "thickened" blob for creating a continuously smooth exo-skeletal LBS (as shown). Of course Rhino (being a surface modeller) could require years to do this solid difference opp (or an eternity).
8. Rounding the "lips" of that LBS Brep is out of question with Rhino or GH (but it can been done very easily using other apps). Then you must "split" the Brep (in modules? in nodes + "rodes"? you tell me) in order to make it in real-life (what about forgetting all that?, he he).
9. Then, there's the glazing thingy that is made via quads meaning planarity. This is achievable with Kangaroo2 but is a bit tricky.
Moral: WHAT a gigantic pile of worms is this thread of yours...
more soon.
…
rights to register the "mapwingis.ocx" file.Francesco, would you be patient just a tiny little bit, so that we could try something else? I would be grateful if you could.
1) Close Grasshopper and Rhino2) Run the Revo Uninstaller Pro and uninstall your MapWinGIS application along with removing all the leftovers from the registry.3) Restart your PC, and once it boots again, make sure that you are logged in as an Adminstrator.4) 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".5) Turn off your Antivirus, which ever it is.6) Download the 64 bit version of v4.9.4.2 MapWinGIS.7) Right click on downloaded MapWinGIS-only-v4.9.4.2-x64.exe file, and choose "Properties". If there is "Unblock" button click on it, and then click on "OK". If there is no "Unblock" button, just click on "OK".8) Left double click on MapWinGIS-only-v4.9.4.2-x64.exe file and install it to "C:\dev\MapWinGIS" folder. Choose "Full installation" during installation process!9) In your Start menu's search box type: "CMD". Once the "Command prompt" appears do not left click on it! Instead right click on it, and choose "Run as Administrator".10) A command prompt window will open. Type the following command:
"your_regsvr32_folder_path\regsvr32.exe" /u /s c:\dev\mapwingis\mapwingis.ocx
If command does not result in an error message, then type this one afterwards:
"your_regsvr32_folder_path\regsvr32.exe" /s c:\dev\mapwingis\mapwingis.ocx
11) If no error appeared again, then open your Rhino and Grasshopper and check what Gismo_Gismo component prints from its "readMe!" output.If errors appeared, it would be nice if you could post their screenshots.…
Added by djordje to Gismo at 5:46am on March 27, 2017
achieving some preliminarily/conceptual Academic solution that "may" qualify as "realistic". I have several defs that do similar stuff ... but this is an Academic forum and as you can understand a real-life solution would never appear here.
But let's forget the W task (truss out of relaxed mesh with depth, known as W in our trade). See for instance a step prior the "thickness".
General guideline:
1. Create a boundary (a BrepFace) and attempt to do some "reasonable" Mesh via Mesh Machine.
2. Mastermind a policy to manage anchors (naked and/or clothed vertices). This appears easy but is impossible without code IF you want to do it interactively.
3. Separate naked edges from clothed ones (as we do in real-life in tensile membranes etc etc) in order to apply different goal parameters.
4. Relax the mesh (K231 engine).
5. Either work with a "geodesic" structure (W = 0) or make a truss out of the mesh in 4. In either case decide the real-life system in use (say a Mero KK or some other).
6. Check clash truss members issues and interactively vary vertices in order to resolve them.
7. Create all the required connectivity Trees (VV, VE, EV).
8. Mastermind the skin solution (only for experienced pros: avoid at any cost that one).
My advice? Unless you are very determined ... well ... what about choosing an easier design task?
…
of similar/WOW buildings that failed (or leaked) including a very famous one.
2. You must use instance definitions for the truss parts (sleeves, cones, rods and the likes) otherwise the whole thing could become an unworkable nightmare.
3. You must address clash issues otherwise doing it is out of question. These affect the skin parts as well (but as I said: this is 100% pro territory).
4. Your structural analysis (in order to make any sense) must deal with real life components either commercially available or bespoke things designed for the specific project.
5. Wind/Seismic effects can cause skin component issues/failures/leaks as it happened ... well ... in a variety of contemporary famous buildings.
6. Vapor condensation yields (in most of similar cases) buildings that "rain from the inside" - nothing serious, mind: just have an umbrella ready.
…