Calculator revisited

[simsmj]

In an earlier thread, I made a calculator in response to an image created by Egg, (a keyboard). It was a bit rushed, and looked awful (mainly due to colour, but the original calculator it was based on really is that colour!). I always wanted to redo that image, and I finally got around to it.

Mike

http://www.simsmj.pwp.blueyonder.co.uk/weesig.gif
Just chugging away...
Mike Sims

[simsmj]

In an earlier thread, I made a calculator in response to an image created by Egg, (a keyboard). It was a bit rushed, and looked awful (mainly due to colour, but the original calculator it was based on really is that colour!). I always wanted to redo that image, and I finally got around to it.

Mike

http://www.simsmj.pwp.blueyonder.co.uk/weesig.gif
Just chugging away...
Mike Sims

[simsmj]

I have had this in mind for a while, too. I've been unable to think of a way to represent glass for this, in X3D, but in another larger version of the clock I did try adding white transparencies on some of the frames in XaraX, which seemed partially successful.

Front and back are different animations blended together, same technique as the calculator.

Mike

http://www.simsmj.pwp.blueyonder.co.uk/weesig.gif
Just chugging away...
Mike Sims

[Egg Bramhill]

You must have spent considerable time stitching the 2 animations together. XaraX's bug re background colour is a major set back when producing these stitched animations.
Regards
Egg

[simsmj]

It was easier than I thought it would be, especially the clock, as there were no frames showing both front and back at the same time, unlike the calculator, so it was just a matter of selecting the right frames in each animation and deleting the rest, and then cropping. But the calculator had some frames that were a composite, left half from one anim, right half from the other anim. Even though the body used the same shape in both anims, with the same extrusion and bevel, the two halves didn't quite marry up, as one half was slightly smaller than the other. I think this was due to the "sizing" pixels that allow each object to maintain size and position relative to other objects in X3D being different in each animation. They end up looking like elaborate spindles, and if they are identical in both anims, all is fine, but if one anim drops a large extruded object, or a bulky bevel, the spindles can change size, affecting the bounding box that X3D fits into a frame. A workaround would be to have a null object containing only the pixels, and giving them the largest extrusion and bulkiest bevel settings of the animation set, so that those pixels alone set the bounding box size.

Mike

Could you elaborate on the background bug, please? I don't think I met it, but I did find a bug in Xara3D.

http://www.simsmj.pwp.blueyonder.co.uk/weesig.gif
Just chugging away...
Mike Sims