|
Here are two experiments using borders I created for iSpace using a reverse
orientation. Although the frames fit perfectly in Rhino and the component pieces
assembled correctly the results surprised and disappointed me because of the way
iSpace apparently resizes the pieces unevenly according to its expectations of
the outside dimensions of the pieces. However I think I have shown in these
following iSpace renders that they frame components were perfectly viable if
they had only been resized proportionately. As near as I can tell iSpace is
ASSUMING that all corner pieces have exactly the same width as the long pieces.
If this is not found to be true then iSpace resizes the corner pieces
disproportionately to force it to be true. This causes the corner pieces in my
example to become way smaller then they were intended causing them not to neatly
fit with the long pieces. The only reason I can see for this resizing logic is
the assumption that the user will always want the long pieces to full the full
width of the cell. I had hoped that iSpace would look for the piece with the
largest width in any particular direction and use that as the maximum size with
which to resize all of the pieces to fit any given situation. If this had been
the case I see no reason that ANY kind of border should not work fine. If there
is some compelling reason for the current iSpace logic then maybe a subsequent
.01 version update could include an option for frame sizing logic or something
like that. I hope you can see looking at my examples that there are lots of cool
frames that could be made if there was more flexibility in the frame component
sizing logic.
This shows the border I was expecting. Since iSpace did not produce this
result I had to force the issue by copying the individual frame components into
each cell as objects and resize them manually.
This shows the border iSpace produced. Notice the tiny corner pieces. This
became necessary when iSpace decided that the long pieces needed to be the ones
that set the width of the corner cells. If it was allowed for them to only fill
a portion of the width of their long cells then they could be narrow enough to
nicely fit with the corner pieces I designed.
This shows how I intended and expected an inside border to look. This is how
it should look when you have a 3x3 grid of cells and select all but the center,
select this particular border, then eliminate the border pieces along the
outside edge. I intentionally made the clam shell type corners the size you see.
Notice how they still meet the long pieces fairly precisely though I had to
manually size them actually as separate objects to make it look this way.
This shows how iSpace forced the larger clam shell corners to become very
small to match the width of the long pieces since it seems to force the width of
the long pieces to become the width of the corner cells rather than allowing the
long pieces not to have to fill the full width of their long cells.
I am HOPING there is no reason iSpace can not be enhanced to allow enough
flexibility to allow these kind of variable dimension frame designs. If so I
think a lot more could be achieved by users using this time saving tool.
Comments and suggestions are welcome at the email address below.
In pursuit of my suggestion that borders contain the same max dimensions in
the long pieces as the cells I decided to create a new border in Rhino which
has corner pieces that full the full width and depth of the cell at at least
one point on each side. Later I realized they were symmetrical in every
direction so I made them both the convex and concave pieces. However for the
long pieces I started with the pair of rods and, almost too late, realized
that iSpace would fatten the rods to make them wider to fill the cell so I
copied a corner piece, added the same bevels to the opposite site of it,
turned it on edge, cut off the back part with a Boolean, then laid it in place
to fill the width of the cell. This way the cells will not resize. When I
brought the pieces into iSpace it insisted in my selecting exactly 1 (no more,
no less) piece for each side so I had to go back and group the pieces of each
side in tS and try again. This worked HOWEVER. It may have been the reason I
started seeing multiple, overlapping border creation widgets. It was very
confusing so I tried to assign each new piece to the widget that appeared to
have the most dark sections already. I stopped when all pieces of the object
were white telling me they had already been selected. I was going to try to
first Boolean union the three pieces together but the Boolean did not work and
I didn't want to mess around with it any more. Strangely the first border I
saved had the right and bottom side pieces ALL SCREWED UP (for emphasis) like
they were totally rearranged at a face by face level and reassembled wrong. I
did the whole border creation procedure again and this time the border was
okay. I guess there was some corruption associated with the multiple border
creation widgets or something. Maybe this is related to why, much later I was
not able to reload the file I had created. Its a good thing I had already done
the renders. I had a heck of a time designing a hover button from Donald S.
Griffin in three colors. Then when it rendered it didn't change colors. I
don't know why. Maybe related to the corruption again. I discovered I could
not reload the page when I tried to go back and assign a URL which I had
neglected to do before. But I doubt lack of a URL would cause the button
to not even hover.
| 