bi-directional link, the link is unidirectional (downflow only), because of the use of proxies.
Matrix transforms and persistent constraints: I don't think this is true. The parts can have mates to other parts that preserve geometric relationships like 'coincident' , 'aligned' etc. These are essentially bi-directional. GH's algorithmic approach does not do relationships in the same / flexible way. In GH, the 'relationship' has to be part of the generation method that dependent on the creation sequence. I.e. draw line 2 perpendicularly from the end of point of line 1. If you are thinking about parts or assemblies sharing, or referencing parameters as part of the regen process, this is also possible. iLogic does this, and adds scripting. So does Catia. Inventor/iLogic can also access Excel and have all the parameter processing done centrally, if required.
Consequently, scripting the placement of components is irrelevant in GH, unless you decide that each component needs to be contained in its own separate file.
I wouldn't be too hasty here. Yes, you are right about compartmentalisation. I think this needs to happen with GH, in order to deal with scalability/everyday interoperability requirements. Confining projects to one script is not sustainable. MCAD apps have been doing this for ages with 'Relational Modeling'.The Adaptive Components placement example illustrates that it is beneficial to be able to script some 'hints' that can be used on placement of the component. Say, if your component requires points as inputs, then its should be able to find the nearest points to the cursor as it moves around. I think Aish's D# / DesignScript demo'd this kind of behaviour a few years ago. Similarly, Modo Toolpipe reminds me how a lot of UI based transactions can be captured as scripts (macro recorder etc). Allowing this input to be mixed in and/or extended by GH I think will yield a lot of 'modeling efficiency' around the edges. This is a (mis)using GH as an user-programmable 'jig' for placing/manipulating 'dumb' elements in Rhino. It may even give the 'dumb elements' a bit more 'intelligence' by leaving behind embedded attributes, like links to particular construction planes etc.Even if we confine ourselves to scripting. GH is a visual or graphic programming interface. A lot of 'insert and connect' tasks can be done more easily using graphic methods. If we need to select certain vertices on a mesh as inputs for, say, a facade panel, its going to be quicker to do this 'graphically' (like the AC example), then ferreting out the relevant indices in the data tree et al. The 'facade panel' script would then have some coding to filter/prompt the user as to what inputs were acceptable, and so on.
This also brings up the point that generating components and assemblies in MCAD is not as straightforward. In iParts and iAssemblies, each configuration needs to be generated as a "child" (the individual file needs to be created for each child) before those children can be used elsewhere.
Not sure what you mean here. If the i-parts are built up using sketches /profiles or other more rudimentary features (like Revits' profile/face etc family templates) then reuse should be fairly straight forward. I suppose you could make it like GH scripting, if you cut and paste or include script snippets that generate the desired Inventor features.
One of the reasons why the distributed file approach makes perfect sense in MCAD, is that in industry you deal with a finite set of objects. Generative tools are usually not a requirement. Most mechanical engineers, product engineers and machinists would never have any use for that.
I don't think this is true. Look at the automotive body design apps, which are mostly Catia based. All of the body parts are pretty much 'generative' and generated from splines, in a procedural way, using very similar approaches to GH. Or sheet metal design. It's not always about configuration of off-the-shelf items like bolts. And, the constraints manager is available to arbitrate which bit of script fires first, and your mundane workaday associative dimensions etc can update without getting run over by the DAG(s) :-)
…
ned' as this is kind of unknown to me, which is why I wanted to look for a tool or script that might generate some geometry between the two. The fundamental principle is that the input meshes must retain 90+% of their original geometry (ie not deformed into an approximated wrapped shape) but be joined together by some sort of mesh geometry which acts as a link between the two shapes. The form for this could be highly abstract and doesn't need to conform to any parameters other than allowing the original meshes to be highly visible. I hope that makes sense, it may only be clear in my mind now that I have pursued it this far!With regards to the geometry wrapper, I found the example file that you sent us and attempted to plug in similar variables with my meshes, however the values returned by the geometry wrapper are constantly zero, no matter what I seem to change. I am currently plugging the mesh into a bounding box, which forms the box for both the geometry wrapper and iso surface and then inputting integers for the remaining parameters, though I'm not quite sure what actions these are performing. Would it help if I could send you my definition? I'm currently trying to internalise my meshes, though my rhino keeps crashing when I try! If you aren't able to follow any of the above let me know and I'll try and put together some simple diagrams that may explain it better.
Thanks,
Tom…
Added by Tom Jelley at 3:28pm on November 12, 2014
unique properties (color, UV map, vertex normal) the vertex is duplicated. So if you weld a mesh using the weld command with an angle tolerance of more than 90 degrees you're left with a box with 6 faces and 8 vertices.
It's quite a common way to describe meshes, Also the way your graphics card consumes meshes, so there's little CPU processing needed to process the meshes and feed them to the graphics card. If it's hard drive space you're worried about, there may be some compression possible. Apart from primitives, I don't know a geometry that do not represent a box by having four faces (including maya's polygons).
A mesh is considered closed when there are no naked edges. So for boxes this does not return false. I assume that internally spatial queries are used (or perhaps a check if the vertices are exactly the same)(see https://github.com/mcneel/rhinocommon/blob/master/dotnet/opennurbs/opennurbs_mesh.c )
Conclusion: If you want faces to show as having a (semi) creased edge, you'll have a vertex direction for each vertex.
However, if your goal is to make gears, I'd skip the whole part of creating meshes, and leverage Breps and extrusions to create the geometry, or using Extrusion (the geometry) might be a solution to create lightweight geometry, and forget about creating meshes yourself.
…
nt analysis - benchmarking >> bad condition of a face falsifies, resolution-dependence ...
B) if you use the karamba- or gh-mesher it still gives you bad results as your sphere has its nurbs-edge running through your cap. rotate the sphere 90° around x before and you are getting a nice mesh.
C) your supports are not defined just around its edge which i guess the benchmark would require?
D) you defined wood as the material, and there are some non-benchmark defaults for that i guess. also i am not sure but i think there have been some issues about the computability of shell element's materials with low shear modulus, and therefore the one of wood was raised. but you have to ask clemens for that.
nevertheless you can define your own material-properties with the resp. component
for me now, it calculates the first 5 buckling modes
good luck!
best
rob
…
rench "géométrie de raccordement" this geometry is different and unique to each pattern, and is highly dependent on the central geometry of the pattern, some non exhaustive rules imply that:
this geometry is usualy the extension of the central one
follow by the preceding rule the same angularity than the central geometry
the angles are dictated by the parent geometry shape, here you have an octogon, which means that the angles are either or both the ( subdivision usually) and multiplication of the PI/2.rad angle(90°, 45°, 22.5° and so on)
there is the notion of tiling, which also dictactes the axes of symmetry and possible combination of primary shapes , here you've got the (4,8,8) tiling, which goes along with what is called an octocagonal symmetry
What you've got here is the base geometry, that you could fill with a variety of rich ornaments, I suggest You look at Jule's bourgoin book : "Les éléments de l'art arabe : le trait des entrelacs " there you may find your pattern in a higher complexity and diversity, if you come to analyse them, you could figure out the logical relationships between the shapes , or what you're referring to "mathematical formula"
I think finding some patterns of reference is the best way to tacle even more complex shapes
If you want more insights at least about some academic works I will be pleased to share my humble gathering of knowledge
Good luck…
cussions.
The heart of the problem was a math domain error that was occurring in the function that calculates indoor air stratification, which is ironic as this was a simulation that did not have any indoor test points. This has now been fixed in the attached file and on the github.
The second issue was that the month was off by 1 when you connected up an HOY and this has also been fixed now.
https://github.com/mostaphaRoudsari/Honeybee/commit/d45ac37bc8b9db3f76aa5d9fcc00687394b9ef5d
My last comment is a suggestion to break up the ground top surface into several surfaces as this allows the temperature maps to account for spatial differences in ground temperature across the scene. This is what I do in this file here:
http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Outdoor_Microclimate_Map&slide=0&scale=1&offset=0,0
Thanks for getting down to the cause of issues like this one. It really makes these bugs much easier to fix. Between the both of you, I feel you can take credit for over 90% of the bug fixes in the community.
Great job, as always,
-Chris…
aybe cause this problems.
.
maybe we can rotate this vectors in a slight angle to produce smooth principal curvature lines.so i set a point to test my thought. and i put following codes into yours,but it did work to specific curve. it cannot apply to several curves.
can you give me some advice?
.
thanks a lot!
.
If (Not IsNothing(PrevDir)) Then
If (dir.IsParallelTo(PrevDir, 0.5 * Math.PI) < 0) Then
dir.Reverse()
End If
if (dir.IsPerpendicularTo(PrevDir,rAngle) then
dir.rotate( fAngle ,crv.Normal)
End If
End If
…
this:
Private Sub RunScript(ByVal pt1 As List(Of Point3d), ByVal pt2 As List(Of Point3d), ByRef A As Object)
Dim myLine As New Line
Dim arrLines As New List (Of Line)
For i As Integer = 0 To pt1.Count - 1
myLine = New Line (pt1(i), pt2(i))
arrLines.Add(myLine)
Next
A = arrLines
End Sub
I then get this error:
Error: Overload resolution failed because no accessible 'New' is most specific for these arguments: (line 90)
If I rewrite (and change the access to Items NOT List) to:
Private Sub RunScript(ByVal pt1 As Point3d, ByVal pt2 As Point3d, ByRef A As Object)
Dim myLine As New Line
myLine = New Line (pt1, pt2)
A = myLine
End Sub
..then it works pefectly!Is there a bug with accessing list items? Or have I been staring at the screen for too long and I'm missing something very obvious?!Thanks,Toby…
nal vector.(see pic 1)
Second: Holding an abstract mesh or surface with a 3D grid structure. Basically creating 90 degree vectors on an uneven surface coming out of the object, sort of like a cactus with a grid pattern. (see Pic 2)
Third: I think #1 answers this issue: when the lines hitting the rough surface go in two different grid directions, their intersecting points are too close together. Structurally these points can be united and the vectors would be reduced. Manually deleting these lines after being baked is currently the only option. It would be so cool if there was a mathematical arrangement that would connect points that are within a certain distance to one another. (see pic 3)
…
. since there are going to be multiple units facing different directions, each unit will be calculated differently based of their respective plane.
The following screenshots can explain the situation a little better
So Lets say the vector is pointing from the operating unit to the position of the sun, an the plane underneath is where I would like to measure the angle from
this second picture shows how each unit should function, so the measured angle doesn't exceed 90 degrees. what I did is zeroed the z value for the sun position to get a project vector. The problem with this solution is that it only works for XY planes, where I need to have a lot of planes that are specific for each unit and its orientation.
Help would be much appreciated…