LOCAL COORDINATE SYSTEMS

Hello everybody,

This is a suggestion rather than a question:

coming from a sketchup background I am used to working with local coordinates.

(to those of you familiar with sketchup, I mean that when you work within a group/component, whatever you design disciplines to its local - or internal- axes)

so my proposal is to create an element in GH that will place all entities within it in a local coordinate system.

COMPUTATION:

numeric values are unaffected
points, curves, vectors are translated (either to world coordinates or to another LC system if they enter it).
resulting geometries occur through the combination of both
transformations are defined by the LCS within which they reside.

INTERFACE:

No overlapping of LCS's
LCS rectangle cannot become smaller than the area of its residing entities
LCS rectangles always push outside entities when resized.Possibly accross the entire axis of the resizing (similar to alt+dragging but also to the up/down direction)

Although in my work I find myself frequently in need for such a system, It is difficult for me to create a clear example to explain the need for it, so for now I am throwing this out in case there are more people out there with the same approach and in the meanwhile I am preparing a clear example for why I thing this would be very helpful

essentially I think it would be useful because:

it is more 'object oriented' and closer to the way our brains (or at least mine) process forms
it would reduce the need for bulk use of components in order to translate local coordinates to global and vice versa
it would become more flexible to convert from one way of calculating something to another.

hope that makes sense, and I am waiting for your opinions!

Replies to This Discussion

Permalink Reply by Daniel González Abalde on September 27, 2016 at 8:32am

- It is not how the brain works or process forms but as is accustomed to think, and this depends on how the tools (as Sketchup or Grasshopper) habituate us.

- I do not find that so many components to translate coordinates, but it is clear that the less be better (as long as they do not obscure the understanding).

Permalink Reply by Aris Nikolopoulos on September 27, 2016 at 8:59am

thanks for the reply, I was searching for an elaborate example but this is perfect!

you could have the same result with just 4 components! (apart from the transformations, which i couldn't do because i have to 'draw' everything.
by applying a transformation once to the local plane everything in the local system updates automatically with minimal wires and components. (here it is just two boxes but it could be a complicated fractal form)

The problem I run into while creating an example was that when you feed a list or a tree of planes into the local system you have a single area representing a multitude of local systems which complicates the 'translation' of data flowing in and out of them. You end up having them reciprocal which complicates things.

but I am sure there can be a solution to that. (which I am currently looking for)

Permalink Reply by Daniel González Abalde on September 27, 2016 at 9:22am

Actually you only need one component to do that:

I just wanted to represent that you can have the transformation and its inverse and apply it to any object.

I always am in favor of bringing forward the interface, but I honestly do not think here worth the effort (which will be done by someone else). I had planned to use this strategy (use a container to capture components) to permute all parameters of a definition and automate the recording of results for the next version of Peacock, but this has the advantage that it works with the entire definition without manipulation in the middle of the solution, gh does not like that because (to my knowledge) has no mechanism to intervene in this way, so it requires changes under the hood. But hey, I'm no expert, maybe I'm wrong.

Permalink Reply by David Rutten on September 27, 2016 at 10:04am

Well this was going to be a GH2 thing at the earliest anyway, and yes this needs to be implemented at an absolutely fundamental level if done this way, because components need to know about what LCS region (if any) they are in and what LCS regions (if any) their sources are in. This is not something that can be added later or by a third party.

I asked Aris to start a new discussion after we ran out of space on this one. I shall refrain from posting my own misgivings here until a number of users have commented. Apparently it's bad form to criticise ideas during brain storm sessions :)

Permalink Reply by Aris Nikolopoulos on September 28, 2016 at 2:30am

I see what you are saying, and btw I am one of those guys with minimal (if any) programming skills, still I would like to ask u: even if you create a graphic element for LCS does it have to mean computation on a different base? it could be just an interface 'mask' for a transformation that is applied afterwards (I really hope what i said is not silly!)

as for the understanding of vectors, I would disagree completely, it's the other way round. local coordinates is a fundamental part of working with vectors and using just one reference system is rather a complication (as far as mathematics are concerned) than a simplification.

again, I'm in complete darkness about the program's architecture and I would have to take your word for it, but from a mathematical point of view, it goes deeper into the core of geometric principles and vector usage.

Permalink Reply by Aris Nikolopoulos on September 28, 2016 at 2:54am

you are not wrong at all on that!

actually this all started because I couldn't find a plane input for vectors and points.

Permalink Reply by Aris Nikolopoulos on September 28, 2016 at 3:52am

Grrrrr.....

I envy you :) !!!

Permalink Reply by Aris Nikolopoulos on September 28, 2016 at 3:39am

man!

this is exactly what I was missing!!!!

thank you very very much!!!

are these your own scripts?

Permalink Reply by David Rutten on September 28, 2016 at 5:14am

Let's not worry about performance at this stage. It's also clearly a feature you wouldn't have to use, so there's no reason it would confuse beginners, unless they are confronted with it against their will.

The problems I'd like to discuss here are how this would work as an interface concept. How does one define these regions? Can they overlap? Can they be nested? How is membership of these regions defined? How is geometry that belongs to a custom LCS previewed/baked? What happens when more than one plane is plugged into one of these LCS regions?

Permalink Reply by Aris Nikolopoulos on September 28, 2016 at 7:40am

Tom, you don't know how much you helped me with those 5 minutes! I already started working with them and up to now all the things I had in mind to do seem very feasible

(I even made some icons and kept them for -extensive- use)

I am only tempted to ask you if it is not a big bother to make for me the same components (point/vector) but each having both local and world coordinates as output.

I hope it doesn't sound too demanding, I will appreciate it very much!

Permalink Reply by Aris Nikolopoulos on September 28, 2016 at 2:57am

David, when this started you said

"Yes, but not by adding more inputs to all components."

I accepted that without questioning it but now Tom's response brought it back.

really, why shouldn't point and vector constructions have a plane input?

Permalink Reply by Michael Pryor on September 27, 2016 at 11:46am