Thoughts on Rhino 3D

[Marbelup]

I have been using Rhino 3D software for about 2 months now, initially an evaluation copy of Rhino 4 and, currently a 90-day evaluation copy of Rhino 5.

 

The conclusion which I have reached over the last week, unfortunately, is that Rhino (at least on a 32-bit PC) is not capable of complex 3D models such as a fully-detailed diesel loco body. It is good for small parts and would probably be OK for a wagon or similar, provided the detail is not too complex.

 

I successfully used Rhino 4 to model about 10% of the loco I am working on, and had some test prints done. Having spent about 4 weeks completing the remainder of the detailed modelling using the new Rhino 5, I have run into major problems with the final stages of "unioning" all the parts together and producing an STL file, as Rhino come up with "out of memory" errors. I can't see any way around the memory problems, other than buying a 64-bit PC with lots of memory. Rhino 5 includes a 64-bit version which can make use of larger memory for complex models, so maybe that is the way to go. I should have the opportunity to test Rhino on a 64-bit PC before going ahead with a purchase.

 

I could try to simplify parts of my model, which I really don't want to do, as I have put a lot of time into the smaller details.

 

I have found that Rhino is quite fussy with the "boolean union" operation which is necessary to join all the parts together to produce a single 3D object. Sections of the model which look fine on the screen, just won't "union" together and I have had to redraw some parts. For instance, a curved grille on the loco roof composed of 0.2 mm wide rounded bars would not union, no matter what. I eventually redrew it by starting with a curved, solid surface, and drawing an array of boxes, which I then subtracted from the surface to get a "waffle" appearance. This method at least guaranteed that I would end up with a single object for the grille, as I was just subtracting the bits I didn't need.

 

It certainly helps with the union operation if overlays on a surface are embedded slightly, rather than just contacting the surface. Rhino doesn't like things that just touch each other. I have got into the habit of extruding overlay details "both sides" of the original surface, so that they are positively embedded. This also solves the unpredictability with direction of the extrude operation, as it never seems to go in the direction I want if I extrude one side only.

 

I also had some problems with Rhino deciding that the main body "polysurface" of the loco was "bad" after unioning additional parts on. It is not supposed to do that, they say they that a "bad" object resulting from normal Rhino operations represents a bug, but I have had it happen a several times. Usually, by the time I discovered the bad object status, I had gone through several stages of unioning various parts onto the main body, so I couldn't tell which part caused the problem. I have now found it is possible to set an option (CheckNewObjects) so that a pop-up appears immediately if an operation creates a "bad" object. At least that allows the option of undoing and adding one part at a time to figure out what is causing it to go bad.

 

About half way through the detailed design, the file size for my project started to grow to 30-40MB, so I thought I would learn how to use "blocks" for repetitive objects, which was certainly helpful in keeping the file size reasonable. However, there was a nasty trick waiting for me when I got to the "unioning" stage, as "block instances" can't be unioned. The block instance must be "exploded" first, which is easy enough to do, but the advantage of smaller file size is lost. However, I have concluded it is still worth using blocks to keep the file size under control during the design stages, then explode the blocks, which can be done en masse by selecting all block instances, prior to unioning. You are supposed to define a meaningful reference point for each block as it is created to allow positioning of new instances later, but I found it easier just to use the origin (w0,0,0) as the reference point for all blocks, and copy the object to other locations as needed. Provided you copy an existing instance of the block, the reference points is immaterial.

 

Overall, the design part of this project has gone pretty well, and I was expecting some issues and rework with the final unioning stage, I wasn't expecting to run into a brick wall with the out of memory problems. At this stage, I certainly can't recommend Rhino for complex model railway 3D design. I will post an update on how the 64-bit version goes.

[Marbelup]

Update: Some tests on a 64-bit PC with 8GB RAM confirm that the increased memory will handle the complexity of my model including preparation of the STL file. The issues with the "fussiness" of the Boolean union operation and other annoyances remain. In the long run, I will need to consider a new PC.

[Gt.Shefford]

Hi Marblup, You have my sympathies; Rhino can be a testing programme to use for 3d work especially if you are chasing open loops in the surface mesh.

My understanding is that NURBS surface modelers rely very heavily on the graphics card (from memory those in the uni computers cost more than the computer itself) rather than the main processor

I tend to use Rhino either for producing 3d visualizations via flamingo/penguin, or taking AutoCAD drawings for parts to be laser cut and checking the fit virtually and making any corrections (see the 08-16 tamper thread http://www.rmweb.co.uk/community/index.php?/topic/65012-plasser-08-16-tamper/ )

 

Jonathan

[Mark]

I have been using Rhino 3D software for about 2 months now, initially an evaluation copy of Rhino 4 and, currently a 90-day evaluation copy of Rhino 5.

 

The conclusion which I have reached over the last week, unfortunately, is that Rhino (at least on a 32-bit PC) is not capable of complex 3D models such as a fully-detailed diesel loco body. It is good for small parts and would probably be OK for a wagon or similar, provided the detail is not too complex.

 

I successfully used Rhino 4 to model about 10% of the loco I am working on, and had some test prints done. Having spent about 4 weeks completing the remainder of the detailed modelling using the new Rhino 5, I have run into major problems with the final stages of "unioning" all the parts together and producing an STL file, as Rhino come up with "out of memory" errors. I can't see any way around the memory problems, other than buying a 64-bit PC with lots of memory. Rhino 5 includes a 64-bit version which can make use of larger memory for complex models, so maybe that is the way to go. I should have the opportunity to test Rhino on a 64-bit PC before going ahead with a purchase.

 

I could try to simplify parts of my model, which I really don't want to do, as I have put a lot of time into the smaller details.

 

I have found that Rhino is quite fussy with the "boolean union" operation which is necessary to join all the parts together to produce a single 3D object. Sections of the model which look fine on the screen, just won't "union" together and I have had to redraw some parts. For instance, a curved grille on the loco roof composed of 0.2 mm wide rounded bars would not union, no matter what. I eventually redrew it by starting with a curved, solid surface, and drawing an array of boxes, which I then subtracted from the surface to get a "waffle" appearance. This method at least guaranteed that I would end up with a single object for the grille, as I was just subtracting the bits I didn't need.

 

It certainly helps with the union operation if overlays on a surface are embedded slightly, rather than just contacting the surface. Rhino doesn't like things that just touch each other. I have got into the habit of extruding overlay details "both sides" of the original surface, so that they are positively embedded. This also solves the unpredictability with direction of the extrude operation, as it never seems to go in the direction I want if I extrude one side only.

 

I also had some problems with Rhino deciding that the main body "polysurface" of the loco was "bad" after unioning additional parts on. It is not supposed to do that, they say they that a "bad" object resulting from normal Rhino operations represents a bug, but I have had it happen a several times. Usually, by the time I discovered the bad object status, I had gone through several stages of unioning various parts onto the main body, so I couldn't tell which part caused the problem. I have now found it is possible to set an option (CheckNewObjects) so that a pop-up appears immediately if an operation creates a "bad" object. At least that allows the option of undoing and adding one part at a time to figure out what is causing it to go bad.

 

About half way through the detailed design, the file size for my project started to grow to 30-40MB, so I thought I would learn how to use "blocks" for repetitive objects, which was certainly helpful in keeping the file size reasonable. However, there was a nasty trick waiting for me when I got to the "unioning" stage, as "block instances" can't be unioned. The block instance must be "exploded" first, which is easy enough to do, but the advantage of smaller file size is lost. However, I have concluded it is still worth using blocks to keep the file size under control during the design stages, then explode the blocks, which can be done en masse by selecting all block instances, prior to unioning. You are supposed to define a meaningful reference point for each block as it is created to allow positioning of new instances later, but I found it easier just to use the origin (w0,0,0) as the reference point for all blocks, and copy the object to other locations as needed. Provided you copy an existing instance of the block, the reference points is immaterial.

 

Overall, the design part of this project has gone pretty well, and I was expecting some issues and rework with the final unioning stage, I wasn't expecting to run into a brick wall with the out of memory problems. At this stage, I certainly can't recommend Rhino for complex model railway 3D design. I will post an update on how the 64-bit version goes.

I have used Rhino 3D since 2004 without any serious issues. I managed to create a full 3D solid model of the Western reasonably well and was able to use this file to generate an STL file for a prototype. Unfortunately there were issues with the stereo lithography that resulted in the model being 2mm longer than the cadds file, plus the resolution of the rapid prototype.

 

As a result I invested in Rhino Cam to generate CAM files to use on a CNC milling machine. I do all my own bits this way now and it works very well. If you look at the thread on the 14xx using the High Level Chassis, there are some images of the axle box and leaf springs, which I did the master for using this process.

 

Regards

 

Mark Humphrys

[Marbelup]

Hello Mark

 

Thanks for your feedback.  

 

I am using Rhino 5 which does seem to be more demanding of the CPU, although it can work with more memory on a 64-bit PC to allow for more complex models.

 

I think a major factor in my problems is that the 3D model for the complete diesel loco body is, by necessity, very complex.  I am currently working on the bogie sidefames and that is going well as the detail is less complex than the body.  Having said that, I haven't got to the unioning and STL stages yet.

 

My loco body has just been made by i.materialise (in Prime Grey) and should arrive this week.