Grasshopper

algorithmic modeling for Rhino

Making picture frames with custom profiles and randomly positioned reactangles

Hello forum,

Here is the thing, some area is populated with randomly generated rectangles that are sometimes rotated 90 degrees (this is important, keep that in mind, because it will cause a specific problem later) to fit more shapes that are otherwise won't fit in.

On the example below horizontal rectangle couldn't fit in but its rotated analog could and thus was placed in.

Later, when placed shapes are used to generate frames, because of this rotation, the position of the starting points changes and because of the approach I use to generate the frames some angle values are attached to the wrong corners, this brakes the frame shape and looks like this (on the left the frame of sick shape and on the right the frame of the healthy shape):

Again, this happens because the angle values are assigned to the specific corners (points) and previously rotated shapes get these all messed up:

Easy fix, don't rotate the shapes, problem is, I've already baked a good number of them for later use. I'd like to avoid regeneration because it takes a lot of time and without rotation I constrict the algorithm even more.

Better fix, use a different approach, this is where I'd like to hear suggestions and kicks in a right direction. Please take a look at my definition. It works but I have a feeling like giving an amputee a job of sweeping the floor.

Views: 1638

Attachments:

Replies to This Discussion

You are the very same Tim who recently declared faith to Darkness?

If so ... get this and enjoy (but did I've got the issue correctly? not sure since your Rhino file was/is unable to fit on Views (why? you tell me), your planes were at Planet Zorg and other mysterious thingies).

PS: The 4 profiles per frame Tree is present in order to give you some hint(s) for trying other ways to do the very same thing.

Attachments:

Hey, naaah, I'm more of a "no side" kind of guy))

What do you mean by unable to fit on Views? I showed only the problem area, there are other rectangles in the area around, you can only see two however. Can post more screenshots.

Did you have problems with the main plain component? I saw somewhere on the forum that people were having internalized data loss, is this the case?

I poked you component here and there but couldn't make it work, I guess I need to sleep it off. I think I know what outputs are giving me but don't know how it can be useful.

Zoom extends for instance displays an empty View.

...couldn't make it work...

Karma what else? anyway assuming that GH internalized correctly (not a given: very frequently GH is unable to internalize things - NOT in this case: your stuff arrived ... but it's "invisible") the frames and your profile ... using the V1 provided you should see this:

In plain English: randomly placed frames (Rectangle3d) AND the ugly profile placed in properly oriented planes ... etc etc.

Karma, indeed XD

Thanks Peter, but seriously, I have some wacky stuff happening here

Spare my brain, tell me what did I do wrong, I think I've connected the wrong wires, tried to check the code but nope, just nope XD.

OK, first things first:

1. Get this attached (load R file first) AND if it doesn't work > well ... what can I say man? go for some triple Vodka (always good to have Plan Z ready).

2. As I said your def (the stuff that makes, that is) is invisible here in Greece (due to Plan Z ?? hard to tell).

Attachments:

BTW: Out of curiosity: Did it worked in your side?

Hey man,

It seems that I'm not a lost case XD

I tried a different approach after I started this discussion and it seems we were heading the similar directions.

I tried to avoid using corner points (since they are causing so much trouble).

First attempt was to use mid. points of the rectangles' edges (like in your definition), but it didn't work out because apparently edges were also placed in a specific order (same with corner points)

So I looked for the area centroid of each rect., used it to build lines in -x/x and -y/y directions then oriented my profile onto them and...

then I felt like I'm trying to teach a monkey how to drive a car and rage quit the idea.

This looks like hell of a component:

But still doesn't do the magic, it asked me to tell you this:

1. Index was outside the bounds of the array. (line: 108)

If you are ok, I'll just attach full rhino and GH files if you wan't to check them out and know what was wrong after all.

Attachments:

OK,

1. Use ONLY the V2 provided (it works IN ALL cases unless you input some ultra stupid stuff). DO NOT gear this with your data (see 2). BTW: Of course it does the magic, he he.

2. Attach here a set of rectangles (ANY set) in ANY rotation/size etc AND a set of profiles (ANY profile) in a SEPARATE Rhino file: Sizes MUST comply with the ones used in V2 (i.e. stuff not in Planet Mars 1M miles from origin etc etc). Profiles MUST been oriented like the one in V2 (otherwise: Armageddon - I mean I could easily handle with any plane used for the profile ... but why bother?)

3. Describe ANY imaginable additional desire of yours with regard the frames. I mean ANY (just a small demo of the Dark Side). Like putting 3d solid  flowers at the corners or flying pigs or anything.

waiting for the frames (the rectangles, that is)

PS: This is a very simple implementation of the Dark Side (complexity 1 out of 100, so to speak).

Alrighty then,

I did't have specific sizes on my mind when were thinking about the frames, they just needed to look like normal life sized frames (some are large, some are normal, some are small)

Ok, about the desires. I noticed that profile was not aligned the way I wanted, (if you are talking about future implementation in GH component) it would be nice to be able to control the orientation and position of the profile to the frame (like justification in text).

At the time I thought I could try to figure it out by myself and not bother you with this. 

Here is what I mean:

Look at the flat back side of the frame (where they usually attach the canvas to the frame, it will be our plane.


Ok, now look at the profile, it has a "long" side and a "short" side, I wanted the long side to "lie" on top of the plane (canvas), not short. 

It will help avoid having weird frames with "deep" walls (some of the profiles have rather long sides compare to their short sides)

If it makes sense, then congratulations, you see the world in high res XD

Dark side is cool, it has its own drama going on

Attachments:

OK, allow me a couple of minutes for the V3

Sorry for the delay ... but ... it rains here in Greece and my Ducati doesn't start (AGAIN !!!): that's becoming a bit ridiculous.

On our topic:

1. Creating 1M frames with a surface modeller like Rhino IS NOT recommended at all (or buy a CRAY). There's ways to address this but we must spend some Skype time  (it's a bit complex to explain here what instance definitions do and why we should use them - obviously only via code). I don;t get the whole orientation puzzle of yours as well: your 1M frames are placed anyway ... so what's the fuss about? Or you mean: find if the frames "point inside" and orient the profiles properly/accordingly? (that's very easy).

BTW: Using different (each other) frames for that scale is like tuning a Harley Davidson: pointless to the max. Using SOME variants (say 5 -10) makes "some" sense and makes the instance part of the equation peanuts stuff.

2. Your stuff displays this blank screen (zoom extends: trying to see some profiles):

this means: no data of yours can been used: Karma - what else? Maybe some Rhino glitz that one.

3. Added a proper profile variant for the templates (see 5) - see option.

4. Frames MUST been sampled into some DataTree NOT groups or cats or dogs or some other stuff.

5. Added a make templates option (works ONLY if the templates are pink). Additionally there's the usual virus (SardineVirus) implemented (see WARNING - don't take risks, he he).

Moral: I can't think any > can you?.

Attachments:

OK, I have good and bad news:

Good news:

1. If you want to address this as an Engineer (meaning: Effectively) you have 2 options: the Impossible and my way. Period.

2. Why? Because you have 14+K frames (and God knows how many in the next case) that's why (other than the colossal amount of time (for no reason) required for creating them ... try to bake them and measure the file size).

3 .Most non pros believe that the thing that matters the most in engineering is the geometry. Nothing could be further from the truth. Is about the 5% (complex real-life cases etc etc - but this one is very simple geometry wise and not that simple with regard  the whole "ideal" AND effective strategy required).

4. So I've included in this Rhino file attached a small portion of your frames as input for the second C#: CAREFULLY study what it does and most importantly why: it gives you the clear indication about why you should attack this on an assembly/component basis by using instance definitions INSTEAD of recreating 14++ K "solids". The difference in performance is COLOSSAL, not to mention the baked Rhino file size.

5. Using instances is IMPOSSIBLE whiteout code (as is the case in 99% or real-life engineering tasks).

6. Geometry was never an issue on that one (is the 5% max of the whole puzzle no matter requirements you may have).

Bad news:

1. Zoom extends  doesn't work after importing your data (maybe a NVidia Quadro K4200 driver issue - who knows?): use saved views stored.

So ...the choice is yours, best, Lord of Darkness

Attachments:

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service