Grasshopper

algorithmic modeling for Rhino

isotrim (large)surface- getting a untrimmed surface in the end

Ok ..I have a huge D.E.M surface out of which I want to parcel out a test patch. I also want this patch to be divided by a set unit. I able to write  a script for it, but due to the large number of sub-surfaces, the script crashes( specifically if the length of division is lowered below 50m). Is there any other way?

The thing is if you split the surface you get a trimmed surface, nd if you iso trim the surface, the whole patch  gets divided. Thus I wrote the script in a way that divides the whole surface and selects the cells that fall within the test patch curve. But now due to very high number of divisions, thus the script fails there.

Any help is much appreciated!

Best,

Aditya

Views: 2483

Attachments:

Replies to This Discussion

Any luck Peter??

Appears that insofar luck is MIA (advancing Alzheimer helps as well > who am I ? what's my name? how many cats have I? etc etc)  - but hope dies last.

Lets wait for the circuits to get charged again(hopefully soon). Anwyas, I adopted this C# script to do the same( CFD). But some fixing is required( some indenting error). Let me know what you think about this script- It does a super low resolution CFD.

Thanks in advance.

Attachments:

Restart from node 0 (depth of nesting etc etc).

Fluid dynamics C#. Fixing this (a very simple code) could be a piece of cake ... BUT: Who wrote that? What he smokes? (is it legal?)

Main > where are the variable values? what collection type is pp (obviously a Tree?), wo (List?) :

Additionally: What does the marked line above?

Additionally: Iterations Method is MIA

Length Method > double l0 = wlenDeep(t, .g ???????), what is .g? and if just "g" where is this declared?:

PlatCoE Method > you mean that you want a ccx event between a line and a curve? if so Curve x = line.ToNurbsCurve();:

Additionally: what returns the Method on error? (catch {})? The if clause related with coV should be inside try {}??

Hi Peter

Apology for replying so late was doing this(chk file):

is there a faster way to this?

Yes the c# script I sent you was incomplete. I have fixed a few errors, but I'am afraid that the script won't do much for my project. So I would explain to you what is it that I'am  wanting to do.

So I have this super hilly terrain, Which is susceptible to mass flows(water +earth), I want to place certain objects(perhaps circles or squares), and change there orientation in such a way that the flow gets diverted to a certain location( it would almost be a iterative process). In a nutshell I just want the flow lines that I create shows the new path the fuild would take or even get stopped, when it hits one or many of my clustered building(that I would keep iterating inside grasshopper.

I don't want to use kangaroo physics( it makes life hell, when run with Octopus).

Thanks in advance.

Best,

Mr A

Attachments:

Well ... indeed fluid dynamics and reservoirs have nothing in common (BTW: there's 2 Methods MIA from the C# > impossible to fix things without them).

Anyway ...  the Anemone thingy clearly illustrates the way to solve this (BTW: I don't have the latest 0.4 build since I never use Anemone for real-life stuff of mine).This approach is the typical one for similar problems (like the "matrix" like images on the other latest thread of yours > you are attempting to address this via some kind of terrain "tessellation" eh?).

Doing this entirely with code (and adding several stuff more since actually you are finally after usable "pockets"/reservoirs  of water) it could be rather very easy  ... but addressing firmware limitations with regard response time and the likes ... well ... that is another totally different animal.

My guess is that a "real-life" (???) solution via code it would require 150-200 (max) hours of writing. Real life means a lot of things more than "locating" potential "abstract" reservoirs. BTW: due to the nature of the problem some // processing is a must (+ proper task scheduler(s)) - and therefor ... well .. yes there's a waaaaay faster way to do this.

BTW: What has Kangaroo to offer here? It's just a matter of some "smart" recursive Methods (as we have already talked a couple of weeks ago).

BTW: If the general issue is to make useful/real-life (meaning yielding a reasonable investment break even point) water reservoirs ... then reservoirs are just the tip of the iceberg (less than 1% of the whole puzzle).

BTW: History of mankind is full of attempts that failed because the genius minds forgot to count the beans (the most recent 4++ billion Oops is the one related with the movable/floating paper plant (made in Japan) in Amazon > brilliant or just a convincing testimony to human stupidity/vanity?). 

RSS

About

Translate

Search

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service