Computer-Music.com contains articles and product reviews related to making music using computers and creating 3D computer animation in sync with music. Computer-Music.com is also the home page of  Donald S. Griffin, an experienced professional composer, sound effects designer and audio consultant with an emphasis on computer games,  video games and internet music and sound effects. For pricing and contract availability send email to: DGriffin (@) Computer-Music (.) com

Computer-Music.com  contains articles and product reviews related to making music using computers and creating 3D computer animation in sync with music.
Computer-Music.com is also the home page of  Donald S. Griffin, an experienced professional composer, sound effects designer and audio consultant with an emphasis on computer games,  video games and internet music and sound effects. For pricing and contract availability send email to: DGriffin (@) Computer-Music (.) com

Uneven Borders

Home ] Amorphium ] Bryce ] Carrara ] iSpace ] Rhino 3D ] trueSpace ]
Music Page Example ] Nuts&Rods ] Stones ] [ Uneven Borders ]

 

 

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.


Intended

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.


Result

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.


Intended b

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.


Result b

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.



Nuts & Bolts Border

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.

 

 

For questions or comments contact the webmaster at
(you will have to remove the parentheses and  spaces; sorry but spam is a problem)
 dgriffin (@) computer-music (.) com
Copyright 1996-2004 Donald S. Griffin - Computer Music Consulting. All rights reserved.
Revised: February 04, 2004.
Privacy Policy