STERNontwerp
-
Posts
70 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Articles
Marionette
Store
Posts posted by STERNontwerp
-
-
deconstruct - reconstruct
Now I'm trying something else using the contour node: get a 3D object, deconstruct using 'contour' and reconstruct using the contours in a 'loft surface' node. (Some loss of information is to be expected. Later on I hope to use this to distort an object.)
But something strange is happening which might shed some light on the 'shell' node going the wrong way. The first countour is off. This wrong result is not dependant on the 3D-object, nor on the input in the 'contour' node (delta/point/dir)...
See the attachment
-
I tried to use the 'grid bbox offset' and 'Get ZatXY v001' nodes and noticed some strange behaviour. On a cube it gives wrong results, especially with a small 'int' of 2.
And on a loft-surface as shown in the jpg the hemispheres are sometimes under and sometimes above the surface (see shade).
Have you noticed this and maybe already solved it?
Thanks for sharing!
Ernst van der Vecht
-
Yep, that's it.
-
So if I would add an index at (1,0,0) that wouldn't change the shape, but would change the outcome of Get Center?
-
Sorry for the irritation, but are you sure it's fixed. Doesn't work here. Although I see the '#Revised by MFarrell 03/11/16' in the Shell node, nothing seems to have changed.
-
As the dutch could say: 'Maybe I've put too much hay on my pitchfork'.
The 2D-center I understand, the middle of the bounding box. The improved gravity-center I understand too. But what is the center of the 'get center' node?
I hope you can answer question 3 in the future. Thanks, almost weekend for me.
-
hello frog,
Yes, the problem seems to be the 'shell' mode. The problem is not dependable on the beginning point or the delta. But it is easier to see with a thickness of f.i. 100.
I get left/right: lrrrrlrrlllrlrllrllr, it seems random but reproducable. I don't know python, so I can't look into the shell node.
Ernst
-
As can be seen in the file, the contour or shell node has an error. The endresult should be evenly divided.
For now I solved it by manually moving the parts to the right place, but that isn't an ideal solution. It seems to be a Marionette error.
Ernst van der Vecht
-
Hi Marissa & Nic,
1: I thought did the same by 'convert to 3D poly's','get center','locus'. But that doesn't give the same result, I don't understand that.
2: Neither does 'extrude','get gravity center','locus' get the same result???
3: What would be good is to be able to find the largest circle that would fit in a poly and getting the center of that circle.
But I don't know how to solve this.
-
Dear Sarah,
Thanks for your comment.
I cleaned it up and made it work better. Here's the result.
Ernst van der Vecht
-
Hi Allen,
I think you are referring to the -100 with the MUL-node. It's the distance between the balusturs of the fence. +100 wil go right and probably won't be visible because it makes a fence that's a duplicate of the fence to the right. (The F-balusters are placed according to the Fibonacci-sequence)
You are right to name the offset. That is the problem. Do you know why the NAME node gives the offset if I use 1 NAME-node with 2 connections, but not if I use 2 seperate but identical NAME-nodes?
I've tried splitting it up after the LIST EXPLODE node, but that didn't help.
I can make a workaround, but I rather have a good solution.
Thanks for your comment.
Ernst van der Vecht, architect
-
Hi Allen,
I think you are referring to the -100 with the MUL-node. It's the distance between the balusturs of the fence. +100 wil go right and probably won't be visible because it makes a fence that's a duplicate of the fence to the right. (The F-balusters are placed according to the Fibonacci-sequence)
You are right to name the offset. That is the problem. Do you know why the NAME node gives the offset if I use 1 NAME-node with 2 connections, but not if I use 2 seperate but identical NAME-nodes?
I've tried splitting it up after the LIST EXPLODE node, but that didn't help.
I can make a workaround, but I rather have a good solution.
Thanks for your comment.
Ernst van der Vecht, architect
-
When I start a network with a NAME(object name "1") node and split it up it gives a different result from when I start two networks with 2 NAME(object name "1") nodes. Why?
(I've made a fence based on the Fibonacci-list, which works alright. And as a workaround for the MIRROR-node, I copied the network and made a negative version)
-
My plan isn't that well thought out yet, but when I ran into the difficulty of not seeing the object anymore I knew I wouldn't be able to present it to a future client that way. If a client without marionette-knowledge is to use the marionette-object, it has to be easy. And that means that he can put the object on any layer.
If the scale can be adapted, I would prefer a possibility to have it manually set (for instance as if it were a text object). This way a hierarchy between objects become possible.
Ernst van der Vecht
-
This does this men that my plan to put the wrapper in every room of the building (hence on the drawing layer itself) needs rethinking.
Thank you for your answer Jim,
Ernst van der Vecht
-
I created a wrapper, and later I changed the layer scale from 1:1 to 1:100. Now the wrapper has a representation of 9 x 18 mm, almost invisible.
Can I change the scale of the wrapper so that it stays visible on different scales?
Some handy Nodes and Wrapper for PointGrids
in Resource Share - Marionette
Posted
I used the new style wrapper and it works now. The thing was, with OpenGl on low resolution, some of the spheres disappeared... Maybe it has also something to do with drawing a 5000x1000 surface on a 1:1 scale. That way it can never be close to the origin.
Thanks.