An attempt to model a ship hull in software.....

[Egilman]

11 hours ago, Rick Lutowski said:

When Egilman opened this thread he said:

The point of this thread is to open up the subject of hull building in common solid modeling 3-D design software... (and to sharpen my skills and hopefully everyone elses)

 

Recently much of the discussion has drifted to 3d printing, largely at my instigation I'm afraid, but the thread topic is larger than that.  So, would anyone object if I were change focus a bit and write a few posts about some of the different ways I've seen ship hulls modeled in software over the years, which seems closer to the original intent of the thread.  I'll then circle back to 3d printing since I still have a number of questions about it besides transparency. Anyone object to a temporary shift in focus?

I don't mind, but I was thinking more along the lines of software that is already out there, I'm not aimed specifically at 3D print modeling yet, just the easiest software to use to accurately represent a hull and somewhat of the steps to get there...

 

As long as we can get back to that when the learning curve is flattening on Rhino, I don't mind at all...

[Egilman]

10 hours ago, Kevin-the-lubber said:

Egilmans call, as the OP. Digression never bothers me too much as you often learn something interesting along the way.

Amen brother....

[Kevin-the-lubber]

2 hours ago, Egilman said:

Someone could do a little experiment

It's on the to-do list. I didn't realise they polish them. I did wonder whether they are cast from a 3D mould as I couldn't see any layer lines. They are very clear but the diffraction (?) means they aren't exactly see-through, in fact in that respect the panes I made months back were better as they were dead flat and only frosted on one side.

[Rick Lutowski]

5 hours ago, Egilman said:

I don't mind, but I was thinking more along the lines of software that is already out there, I'm not aimed specifically at 3D print modeling yet, just the easiest software to use to accurately represent a hull and somewhat of the steps to get there...

 

Exactly what I had in mind.  Before getting into specific CAD packages though, it's worth reviewing the different approached to digitally modeling objects in general.  There are only a few.

 

First, there are two types of 3d objects that can be modeled -- surface and solids.  Different approaches are used for each.

 

For solids, there are two approaches:  CSG, and curve sweeping.

 

In his initial post, Egilman referred to hull building in common solid modeling 3d design software.  By "common solid modeling" I'm guessing he was actually referring to CSG, or Constructive Solid Geometry.  CSG creates complex solids by applying boolean mathematical operations -- such as 'union', 'difference', and 'intersection' -- to 3d solid primitives such as cubes and spheres.  This can result in the types of complex shapes you might create using a set of tinker-toys or leggos.

 

Curve sweeping creates 3d solid objects by starting with line in 3d space, then sweeping it through space, usually along a circular or elliptical path.  This ca result in shapes such as a (solid) submarine pressure hull.

 

If your are building a plank and frame model, the solid modeling techniques could be useful for creating some of the discrete parts.  But if you want to model a hull either as a large single entity, or as collection of larger assemblies -- such as main hull, aft skeg, and bulbous bow -- then surface modeling will likely meet your needs better. This is why pretty much every naval architecture CAD tool I'm aware of uses surface modeling rather than solid modeling.

 

There are as many variations on surface modeling as their are surface modeling CAD tools, but they all define surfaces by combining two entities:

1. A collection of points, and

2. An interpolation method.

 

In fact, naval architects have been designing hulls for centuries using the above two entities.  I assume all of you are familiar with ship hull lines drawings, and the associated table of offsets.  The table of offsets are the points.  The lines drawings were created by drawing curves through the points.  The body plan curves were drawn with a set of wooden or plastic ships curves, which resembled French curves in shape but were specialized for naval architecture.  The waterline and buttock plans were drawn with flexible wooden or plastic splines bent into the desired curved shape and held down with lead weights. The architect then traced the curved line onto the drawing by running a pencil along the edge of the bent spline.  So where does the interpolation method come in?  Well, beam theory predicts that the shape of the bent spline will always be cubic! (or sometimes parabolic, which is a subset of cubic).  The ships curves used for the body plan differed from French curves in that the ships curves were cubic too.  Thus, for centuries before the advent of computers, cubic interpolation has been used to design and build ship hulls.

 

Will take a beak now.  In the next post I'll take a look at some ways collections of points and interpolation methods have been used to define hull surface shapes using computers.

 

 

 

[Kevin-the-lubber]

This is interesting though some of it goes over my head right now. However I'm a firm believer that, if you understand why 'it' does something this or that way, the software in this instance, you're halfway to fixing the problem of why it sometimes doesn't do that. You're also halfway there to exploiting the full potential of the tool. So please carry on, chair pulled up.

 

I read 'offsets' a fair bit in this and other threads; to me, an offset is one line or edge offset from another. So what are the points offset from, as described?

 

CSG or curve sweeping (which I assume translates to solid modelling or surface modelling): in what way does it make a material difference? What and why does one do X whereas the other does Y? I know I can model a hull in F360, because I've already modelled the equivalent shapes. From googling, I understand it's CSG, as are all the other common CAD's I know of (Rhino, Solidworks, SolidEdge, Freecad and of course my old friend TinkerCad). It's a bit clunky, the more precise you want the shape, the more profiles through points (offsets?) you need to draw and loft through and the more you'll want to throw your computer out of the window. But it's do-able. If I'm only ever going to model 2 or 3 hulls in my lifetime (probably an over-estimate as I'm a slow worker), would I still be better off using surface modelling?

 

I'm not even going to ask about cubic interpolation - I looked it up on wikiversity, that was enough to get me swiftly back to fettling bits of plastic!

[Rick Lutowski]

Just now, Kevin-the-lubber said:

I read 'offsets' a fair bit in this and other threads; to me, an offset is one line or edge offset from another. So what are the points offset from, as described?

 

CSG or curve sweeping (which I assume translates to solid modelling or surface modelling): in what way does it make a material difference? What and why does one do X whereas the other does Y? I know I can model a hull in F360, because I've already modelled the equivalent shapes. From googling, I understand it's CSG, as are all the other common CAD's I know of (Rhino, Solidworks, SolidEdge, Freecad and of course my old friend TinkerCad). It's a bit clunky, the more precise you want the shape, the more profiles through points (offsets?) you need to draw and loft through and the more you'll want to throw your computer out of the window. But it's do-able. If I'm only ever going to model 2 or 3 hulls in my lifetime (probably an over-estimate as I'm a slow worker), would I still be better off using surface modelling?

 

An "offset" is the distance of a point on the hull from the centerline.  All 3d points are defined by 3 coordinates, which are the distances of the point from each of the 3 axis.  In a lines drawing, all the points used to define the hull are taken at discrete distances from the bow (a section or "station") and above the baseline (a "waterline").  The stations and waterlines form a table, with stations across the top and waterlines along the side of the table.  The distances from the center line (the "offset" of each point) are entered into the cells of the table.  Hence, "table of offsets."

 

                         Table of Offsets

                              Stations

Waterlines      1   2   3   4   5   6   7   8   9  10

2'              x   x   x   x   x   x   x   x   x   x

4'              x   x   x   x   x   x   x   x   x   x

8'              x   x   x   x   x   x   x   x   x   x

10'             x   x   x   x   x   x   x   x   x   x

15'             x   x   x   x   x   x   x   x   x   x

20'             x   x   x   x   x   x   x   x   x   x

x = offset (distance from centerline)

 

This was common ship design practice prior to computers. Even the earliest ship design software quickly deviated from the restrictive "table of offsets" approach for point definition, which was designed for easy manual hull definition.  Because blueprints for old ships often contain a lines drawing and table of offsets, it is useful for ship modelers to understand the approach.

 

CAD programs like the ones you mentioned are very powerful generic geometry definition programs, and many of them have both solid and surface modeling capability, as you mentioned.  This allows the user to pick whichever approach works best for what they are doing.  Whether to use surface or solid modeling depends on factors such as the exact support your tool of choice provides for each approach and, more importantly, the type of model you want to build.  If you are building a small, exterior-only display model, solid modeling may be just fine.  If you are building a large model containing both exterior and interior structures, or any model you want to float in water, then surface modeling is the logical choice.  If you are building a model from lots of small parts, the choice of solid versus surface may differ for different types type of parts.  If you want a simpler to learn and use program that supports only one approach, I would pick a surface modeling tool rather than a solid modeling tool since ship hulls more closely approximate surfaces than solids.

 

This is a good time to mention that I have never used any of the commercial CAD programs.  When I worked for the Navy, they had their own software for ship design, plus most of the current CAD software did not exist then.  So I know how the Navy modeled hulls, and probably still does, but not how any of the dozens of commercial programs available now might do it.   I'm anticipating some of you, who have used some of these commercial tools, will provide that insight -- which I think was the original point of this thread.  My goal with these posts is to provide background into surface modeling techniques in general, which can then provide a consistent basis, or 'language', for reporting how the tools you have used work.  Reporting your experiences in a consistent way should permit easier comparison. 

 

For my part, I will describe how an important Navy software program models a hull, and also how CM Creator does, and try to use the consistent reporting language and see how that goes.

[Kevin-the-lubber]

Thanks, the table of offsets is well worth knowing about, makes sense now. I guess until I find time to try Rhino I won’t understand the benefits of surface over solid from a user perspective but hopefully I’ll get there soon enough.

[Rick Lutowski]

Surface modeling, as mentioned before, consists of picking a set of points that lie on the hull, and an interpolation method. 

 

Interpolation method

 

The purpose of the interpolation method is to determine any offset you may want to know that lies between the points that you picked.  The interpolation method itself is a mathematical formula that tells the computer how to "connect the dots" for the points you picked.

 

Say we pick 3 three consecutive points from a column (station) of the table of offsets.   What shape does it form, i.e., what is the shape of the hull station between those three points?  There are several possibilities.  Three points could define two straight line segments. Or they could define a circular arc. Or they could define a parabolic arc.  There are other possibilities too, but these are the the most common.  Which interpolation formula the computer actually uses depends on the set of interpolation methods the programmer chose, as well as the types of input you provided.  For example, if the hull is smoothly curved between the points, we'll say the computer uses a parabolic formula.  But if you told the computer that the middle point of the three is a hard break, such as the edge of the main deck or a chine, then it will use two straight line segments.

 

The most common interpolation methods for ship design are based on cubic interpolation, of which there are a lot of different mathematical variations.  Another common interpolation method is called NURBS (Non-Uniform Rational B-Splines), which is a more complex formulation that can connect points with circular, elliptical, or cubic curves depending on the input to the formula.  Cubic and circular/elliptical curve fitting is prevalent because that's the way ships and submarines have always been built, and continue to be.

 

Set of points

 

While the programmer picks the interpolation method(s), you as a user pick the set of input points that lie on the hull, as well as supplemental data such as which points represent hard breaks.  However, how you pick the input points (and any supplemental data) is also determined by the program.  You can't just throw any set of points that happen to lie on the hull at the computer because it will want them to have some structure or order. 

 

We have already seen one such structure -- the table of offsets, which requires the points to be defined at discrete distances from the bow (stations) and discrete distances above the baseline (waterlines).  Most programs are not this stringent and do not require the points to be measured at discrete waterlines, but many ship modeling programs do require that points define stations.  Often the stations must be flat (at discrete distances from the bow), but some programs allow the stations to be curved (the distances from the bow can vary at a given station). 

 

In addition to rules for how to measure the point distances (or "coordinates"), there also may be rules governing the number of points to select.  Some programs have limits on the number of stations that can be input, or the number of points per station.  Others don't.  Even if the program allows many or even unlimited points, there may be guidelines suggesting limiting the number of points.  Fewer points gives better performance because computation time increases with number of points.  And, while it may seem counter-intuitive, fewer points can sometimes result in a smoother, better looking hull because some the more complex interpolation methods can become overly-constrained by too many points, leading to undesirable bumps and wiggles in the curves computed between the input points.  Thus, determining the proper number of points to provide is often a matter of trial and error until you gain experience with the chosen program and get a "feel" for it.

 

The types and amount of supplemental data you need to provide varies a lot among different programs.  Sometimes this data takes the form of specific values used to tag special points, such as break points.  Sometimes the supplemental data is specified implicitly by the way the points are organized for input.  For example, if the hull has a hard chine, the points that lie on the chine might need to be input together to form a "control strake", where a strake is a longitudinal sequence of points, just as a station is a transverse sequence of points.

 

Summary and program reporting

 

A. Type of modeling -- solids, surfaces, or both?

B. Interpolation method -- what kind(s) does the program use?

C. Points:

  1. Structure or order -- how does the program want the points to be organized?

  2. Measurement -- do any groups of points need to be at discrete distances from an axis?

  3. Number -- are there restrictions on the number of points?

  4. Supplemental data -- what types of tags or constructs are used to identify points that have special properties or meanings?

D. Usage

  1. Ease of learning -- how long does it take to learn?  What kind of user documentation is provided?

  2. Ease of use -- what tasks or operations are easy?  Which are difficult or cumbersome?

  3. Performance -- how responsive is the program?  Do any tasks or operations make you wait too long?

E. Reliability

  1. Error response -- did the program give useful messages when you made a mistake?

  2. Malfunctions -- did the program ever crash or hang-up, requiring a restart?  If so, how much work did you lose?

F. Functionality

  1. Missing features -- what were you hoping it would do that it didn't, or didn't do well enough?

  2. Best features -- what tasks or operations met or exceeded expectations?

 

I will try reporting on a Navy program for modeling ship hulls, and then on CM Creator, using the above outline and we'll see how useful all of you find it.

 

[Egilman]

The theory behind discrete multi planar curve modeling have been around for centuries... the ticket is to understand the relation of the points to each other... Which can be done with any number of mathematical projection methods, the table of offsets is just one way of recording such datum in a linear fashion... Another is cartesian projection.... For example...

That is a cartesian projection of a table of offsets, it can be used to build a complete hull all you would need to know is the LBP and the distance between the stations... The angles and trigonometry allow you to draw the intervening stations anywhere along the hull... Quite the task though so it's not used for anything but mathematical calculations and the Mould loft builders work directly from the ToO...

 

Solid block modeling is unable to replicate the precision of this style of calculations... The conversion of this style to software representation is surface modeling based upon discrete curve bounding... In software the issues come from stitching the surfaces created from the curves together into a solid object....

 

Personally I'm exploring the current software that is capable of doing this and hopefully see which is most accomplished at it.... The average to typical 3D cad based software can do this but doesn't do it well... Solid modeling software can do it but also has problem realizing the finished solid body in some cases.... I think Rhino can do it as it is specifically aimed at ship building and the incorporation of nurbs modeling makes it very accurate.. but I'm still learning it so I'm reserving judgment till I know more...

 

The process of forming a discrete curved surface mathematically has been known for a very long time..... and to fully understand what we are trying to do here is is good to understand the history of it as well...

 

So from the basis of fully understanding what we are doing, bring it on...

 

 

[Rick Lutowski]

Occurred to me I forgot a couple of items in the reporting format: Cost and System Requirements.  Need to add them to the outline as Items G and H:

 

A. Type of modeling -- solids, surfaces, or both?

B. Interpolation method -- what kind(s) does the program use?

C. Points:

  1. Structure or order -- how does the program want the points to be organized?

  2. Measurement -- do any groups of points need to be at discrete distances from an axis?

  3. Number -- are there restrictions on the number of points?

  4. Supplemental data -- what types of tags or constructs are used to identify points that have special properties or meanings?

D. Usage

  1. Ease of learning -- how long does it take to learn?  What kind of user documentation is provided?

  2. Ease of use -- what tasks or operations are easy?  Which are difficult or cumbersome?

  3. Performance -- how responsive is the program?  Do any tasks or operations make you wait too long?

E. Reliability

  1. Error response -- did the program give useful messages when you made a mistake?

  2. Malfunctions -- did the program ever crash or hang-up, requiring a restart?  If so, how much work did you lose?

F. Functionality

  1. Missing features -- what were you hoping it would do that it didn't, or didn't do well enough?

  2. Best features -- what tasks or operations met or exceeded expectations?

G. Cost -- how much does the software vendor charge for the program?

H. System Requirements: What operating systems will it run on?  Are   special hardware requirements?

 

If anyone thinks of any other information that would be useful in a comparison, let us know.

 

[Rick Lutowski]

10 hours ago, Egilman said:

That is a cartesian projection of a table of offsets, it can be used to build a complete hull all you would need to know is the LBP and the distance between the stations... The angles and trigonometry allow you to draw the intervening stations anywhere along the hull... Quite the task though so it's not used for anything but mathematical calculations and the Mould loft builders work directly from the ToO...

 

Very interesting!  I've never seen that approach to computing intermediate station points before, but makes sense.  Reminds me of radio direction rangefinding.  The trig calculations have to be very precise for it to work well.  And, unless the station lines are fully described by math functions (which they rarely are), you still need an interpolation method to define the station shapes between the station points.  I think the biggest reason it's not used in practice is that points on intermediate stations become direct functions of three angles from the radial center points.  What CAD programs typically need is to compute points on intermediate stations as functions of distance from one of the three major axes, not as functions of radial angles from three points.

 

Clever idea, though.

[Egilman]

Well Rick I've oversimplified the explanation a bit.... The ToO is the easiest way to create a hull section in the real physical world... Hundreds of years of practice prove that, so the easiest way is to take what they do on a Mould Loft floor and translate it into software and there is software routines that do that already... Always room to reinvent the wheel so to speak... The image I posted comes from the booklet of stability for the USS Cyclops AC-4 1910... Cartesian projection is the easiest way to show what the hull profile is going to look like at various angles so they can predict the other important points of hull design center of moment, center of gravity and the like at various angles and weights.... The radial center points express hull loading levels... Once they have calculated the predicted results on hull stability, they run the physical tests on the completed hull to proof the design.... They usually only draw one of these and it is usually on the midsection because they are not easy to draw correctly... so although a hull can be constructed from one, it's not the easiest way to do it...

 

Point being a full set of hull lines are not really needed from an engineering perspective to build a hull in software, they just make it a lot easier.....

 

We as modelers are looking for software that can take simple 3 views, profiles and deck plans, and create a reasonably accurate model from them... Heck even the drawn hull lines are not absolutely accurate, any draughtsman knows that... Cause everything is drawn in scale and a pencil line on a drawing will equal the thickness of a steel bar or a wood trim strip on a real ship... (depending on drawing scale) In reverse, a ToO is usually created by a naval architect off his drawing of the hull shape to start with..... 

 

Hence practicality sets in, the hull shape is perfect in the designers mind, but the moment he puts it to paper error starts to creep in....

 

As far as software design goes to effectuate this, we will never reach absolute accuracy the best we will reach is an approximation.... it needs to be fast, it needs to be easy to use, and it needs to point out obvious errors... (and hopefully tell you what is causing the error)...

 

The subject is a heavy technical one though and the software designer is the genius that gets to resolve all the technical aspects into a format so relative idiots like me can use it....

 

Understanding it is the first step to mastering it...

[Kevin-the-lubber]

58 minutes ago, Egilman said:

it needs to be fast, it needs to be easy to use, and it needs to point out obvious errors... (and hopefully tell you what is causing the error)...

 That's what I'm after... probably wishful thinking.

[Rick Lutowski]

Just now, Egilman said:

Well Rick I've oversimplified the explanation a bit.... The ToO is the easiest way to create a hull section in the real physical world... Hundreds of years of practice prove that, so the easiest way is to take what they do on a Mould Loft floor and translate it into software and there is software routines that do that already... Always room to reinvent the wheel so to speak... The image I posted comes from the booklet of stability for the USS Cyclops AC-4 1910... Cartesian projection is the easiest way to show what the hull profile is going to look like at various angles so they can predict the other important points of hull design center of moment, center of gravity and the like at various angles and weights.... The radial center points express hull loading levels... Once they have calculated the predicted results on hull stability, they run the physical tests on the completed hull to proof the design.... They usually only draw one of these and it is usually on the midsection because they are not easy to draw correctly... so although a hull can be constructed from one, it's not the easiest way to do it...

 

Ha!   I misinterpreted your drawing -- and by so doing may have conceived a new interpolation method based on trig.  Pretty funny.

 

Just now, Egilman said:

We as modelers are looking for software that can take simple 3 views, profiles and deck plans, and create a reasonably accurate model from them...

 

I would expect any of the naval arch CAD tools can take data from the three lines drawing views and turn it into a beautiful digital description of the hull.  How much effort is required to get that data into the tool is one issue.  Creating the model is another. Should the tool 3d print it?  Or should it print templates for manual construction, as Kevin has suggested?   More to the point, can the tool print the model, or templates to build one?   Be interesting to find out what some of you learn.

[Egilman]

36 minutes ago, Rick Lutowski said:

More to the point, can the tool print the model, or templates to build one?   Be interesting to find out what some of you learn.

I'm assuming here that "Tool" as your using it is the software....

 

I can answer this one right now, no there is no 3D software capable of directly printing to a 3D printer, not even the slicers... All of them use the STL file for interfacing with slicer software... which outputs a machine readable file for the printer..... which to be honest is probably the next major inefficiency to be upgraded... I believe F360 had a slicer routine in it at one point or was directly interfacing with a slicer add in.... but it was removed... (and they have gone on to officially support a different file for transfer of 3D models as their default other than STL and OBJ, it is neither open source nor standardized, but F360 still will export in STL, you just have to specifically select it)

 

This is the next workflow bottleneck to be dealt with in 3D printing, and if Autodesk is looking at it, you know the others are as well...

[Rick Lutowski]

42 minutes ago, Egilman said:

 

I can answer this one right now, no there is no 3D software capable of directly printing to a 3D printer, not even the slicers... All of them use the STL file for interfacing with slicer software... which outputs a machine readable file for the printer..... which to be honest is probably the next major inefficiency to be upgraded... I believe F360 had a slicer routine in it at one point or was directly interfacing with a slicer add in.... but it was removed... (and they have gone on to officially support a different file for transfer of 3D models as their default other than STL and OBJ, it is neither open source nor standardized, but F360 still will export in STL, you just have to specifically select it)

 

 

Sounds like you want the slicer built into the CAD tool to avoid dealing directly with STL.  That would be convenient, but you still might want to save the STL so you can print it again later, or upload it so others can print your model too. 

 

Fusion360 demoting STL for their own proprietary file format tells me they think they can capture a big share of the 3d print market and lock those users in to their own products.  It's the old Microsoft proprietary format game that the big boys like to play, and autodesk is definitely the big boy in CAD.  My mantra is never use proprietary formats, no matter how many goodies they implement to entice you in.  Stay with the standards like STL and OBJ.  That gives you the portability and flexibility to use other vendors, which helps promote competition for the big boy.  Competition encourages innovation and reduces cost.

 

[Kevin-the-lubber]

Slicing from within the software would be a bonus for me, though not of much value as there’s nothing particularly ‘broken’ in that area. Slicing software, integrated or standalone, with a super-intelligent orientation and supports placement algorithm, now that’s worth having. I’ve been using Lychee a lot recently, over Chitubox, both have shortcomings. To be honest I don’t even know why or when it would be better to use anything other than STL, it seems to reproduce what I’ve modelled perfectly well. I get the odd non-manifold warning in Lychee but just ignore it as fixing the holes in mesh mixer sometimes destroys the entire part. 

 

There’s a flip side to competition you know. It can also drive corner-cutting and spin. F360 is a case in point, you’ll find no end of threads about very long-standing deficiencies that Autocad clearly have no intention of fixing because there’s nothing in it for them and they seem to only have one or two people on the community support side for the entire world. But they’ll still tell you it’s the bees knees of CAD.

 

Of all the criteria you listed Rick, I think I’d like good error handling most of all. All of the other things are of course very important but the nature of this game is trial and error and you really don’t want the F360 experience where, if it even gave decent error messages, it would usually say this: “You’ve tried to do something I don’t know how to handle. I’m thinking on it. I don’t know how long this will take. Longer than you want, that’s for sure. I might give up in 5 minutes, I might never give up, either way, you can’t do anything more while I’m thinking, so go and find something else to do and check back periodically. By the way, I’m sorry if I destroy your file while I’m doing this. Stuff happens.” I wrote simple software, of sorts, myself many years ago and probably put more effort into the error handling routines than anything else.

[Egilman]

6 hours ago, Rick Lutowski said:

 

 

Sounds like you want the slicer built into the CAD tool to avoid dealing directly with STL.  That would be convenient, but you still might want to save the STL so you can print it again later, or upload it so others can print your model too. 

 

Fusion360 demoting STL for their own proprietary file format tells me they think they can capture a big share of the 3d print market and lock those users in to their own products.  It's the old Microsoft proprietary format game that the big boys like to play, and autodesk is definitely the big boy in CAD.  My mantra is never use proprietary formats, no matter how many goodies they implement to entice you in.  Stay with the standards like STL and OBJ.  That gives you the portability and flexibility to use other vendors, which helps promote competition for the big boy.  Competition encourages innovation and reduces cost.

 

I primarily use Lychee, and it has the ability to save the STL file, project file and machine code file... (the file you give to the printer) I save all three.... To me, I would make the saving to STL and Machine code automatic, with the slicer project file optional... The ability to send the machine file directly to the printer isn't probably going to come around for a while, it's going to require the printer manufacturers to see the worth of making their printers USB capable... right now with the workflow of 3D printing using a Stick to transfer the file to the printer is the best way....

 

I believe that Autodesk sees F360 as a lead in to future Inventor users leaving it basically for the hobbyist.. (I can't believe they charge people for a "Pro" license for F360! given it's current buggy state) Proprietary is always bad for universal fit for exactly the reasons you explain.. It locks you into one system... Baselines should be universal...

[Egilman]

39 minutes ago, Kevin-the-lubber said:

I get the odd non-manifold warning in Lychee but just ignore it as fixing the holes in mesh mixer sometimes destroys the entire part. 

 

There’s a flip side to competition you know. It can also drive corner-cutting and spin. F360 is a case in point, you’ll find no end of threads about very long-standing deficiencies that Autocad clearly have no intention of fixing because there’s nothing in it for them and they seem to only have one or two people on the community support side for the entire world. But they’ll still tell you it’s the bees knees of CAD.

Using Rhino will end the non-manifold issues, a huge plus for me, it already has routines for testing manifoldness and will show you where the holes are.... every time I do some work on a project the last thing I do if I'm at the solid model stage is check for manifold before I save... Just that one feature alone elevates it above the rest.... especially when you are knitting compound curved surfaces into a solid, IMHO.... This is something Solidworks an otherwise excellent program, can't do...

 

I agree Kevin...

The next thing I would like is error reporting, at least tell me why I can't do what I'm trying to do, save me the time and frustration of having to deduce why myself... "Crap Happens" is NOT an answer...

[Kevin-the-lubber]

Just as soon as I hit the 'final print' stage with this stern model, I'll start learning Rhino. I can save the print file and chitubox file in Chitubox, but not the STL. Lychee is great for mirroring supports and it's also easier to see their placement, but it's awful for mirroring parts and any major re-orientating on the build plate after adding supports i.e. to get the most objects done in one print. So, todays bright idea will be to build the supports in Lychee, then export the STL, mirror and reorganise in Chitubox. 

 

And even as I write that I have a doh! moment and realise I could do the same in Lychee; do the supports, export as STL, reimport and mirror/arrange.

[Rick Lutowski]

8 hours ago, Kevin-the-lubber said:

There’s a flip side to competition you know. It can also drive corner-cutting and spin. F360 is a case in point, you’ll find no end of threads about very long-standing deficiencies that Autocad clearly have no intention of fixing because there’s nothing in it for them and they seem to only have one or two people on the community support side for the entire world. But they’ll still tell you it’s the bees knees of CAD.

 

This is a big advantage of open source programs like freeCAD and CM Creator.  If the user community really wants something badly enough, any user can get the source and contribute that feature themselves.  The users are not totally dependent on a vendor, whose interests may or may not coincide with theirs.  This approach has worked very well for Linux, and has helped make it the dominant O/S in the world.  (Yes, Windows still controls 80% of the desktop, down from 95%+, but Linux powers the Android smartphone and half the internet server market, which together dwarf the desktop market.)

 

MSW modelers can take their future into their own hands by ditching the proprietary products and becoming familiar with what freeCAD and CM Creator can do for you.  Based on the freeCAD web site, I think you will find that freeCAD gives you roughly the same surface and solid capability as Rhino or Fusion360 since they all support NURBS for surface modeling and some form of CSG for solid modeling.  If your model consists only of exterior surfaces, or will be built of lots of smaller solid parts, freeCAD should work just fine.  If you want your model to include lots of interior decks and bulkheads, you will find that nothing out there at any price equals CM Creator; it is unique (so unique that you may find some of its characteristics shocking).

 

At some point, I would anticipate freeCAD and CM Creator working together in some manner. Perhaps freeCAD for exterior modeling and CM Creator for interior modeling.  Or CM Creator for concept design and freeCAD for later stage design.  Both are possible because the two have key infrastructure in common.  They both use similar, open-source licensing.  They are both supported on Windows, Mac, and Linux.  And they both use similar programming languages:  C++ and Python for freeCAD, and Java for CM Creator.  (Java has its roots in C++, and Python has its roots in Java).

 

But before any such synergy can happen, the CAD community needs to become aware of CM Creator.  At the moment, hardly anyone -- not even the search engines -- are aware of its existence.  Readers of this thread are among the very few that know that CM Creator exists.

 

9 hours ago, Egilman said:

The next thing I would like is error reporting, at least tell me why I can't do what I'm trying to do, save me the time and frustration of having to deduce why myself... "Crap Happens" is NOT an answer...

 

CM Creator should be very good in this regard, for three reasons. 

 

First, Java has some of the best error handling of any major programming language. 

 

Second, CM Creator leverages Java's error handling by implementing GUI (graphical user interface) facilities for reporting error details to the user, who can then use the info to fix the problem for user errors, or pass the info to the developers for program problems. 

 

Third, CM Creator takes Java's 'tooltip' feature (which pops up a short message when the mouse hovers over a control) and extends it to pop up the entire help page for the control.  This not only helps new users learn to use the program more quickly, but can often help you figure out why an error occurred.  I'm not aware of any other program that implements user help in this very convenient manner.  I call it JIT (just-in-time) help.

 

10 hours ago, Kevin-the-lubber said:

you really don’t want the F360 experience where, if it even gave decent error messages, it would usually say this: “You’ve tried to do something I don’t know how to handle. I’m thinking on it. I don’t know how long this will take. Longer than you want, that’s for sure. I might give up in 5 minutes, I might never give up, either way, you can’t do anything more while I’m thinking, so go and find something else to do and check back periodically. By the way, I’m sorry if I destroy your file while I’m doing this.

 

Those programmers need to be fired.

 

 

[Rick Lutowski]

OK, I promised you a report on a couple of CAD tools for hull modeling that I'm familiar with.  The first is a Navy program called SHCP (Ship Hull Characteristics Program).

 

SHCP has been the Navy's stability program since the late 1960s. It was developed in Fortran II for very early computers that were limited to 32K words of memory, accepted input on punched cards, sent numerical output to a line printer, and graphical output to a pen plotter. Its users had no access to interactive graphics hardware, which was very expensive at the time, so the program was not designed for interactive operation; it was strictly a batch-mode program.

 

 A. Type of modeling

The hull and appendages are modeled with surfaces. Damaged compartments are defined by up to 6 axes-orthogonal decks and bulkheads per compartment. A limited number of more-complex compartment shapes can be defined using offsets.

 

B. Interpolation method

Parabolic for curved surfaces; linear for flat surfaces.

 

C. Points:

  1. Structure or order

Points are organized by stations. The vertical coordinate of successive points of a station must increase.

 

  2. Measurement

All stations are planar and perpendicular to the longitudinal axis.  That is, all points on the station are the same distance from the forward perpendicular (FP). Negative station numbers (stations forward of the FP) are allowed.

 

  3. Number

Points per station are limited to 29, and must be odd. Number of stations is limited to 41, and also must be odd.  The odd number requirement is an artifact of parabolic interpolation coupled with a desire for high performance. The size limits can be changed by changing a few declaration statements and recompiling the program.

 

Number of damaged compartments supported has increased over time and is now over 900 (a result of greatly increased memory capacity on modern computers). The user specifies each compartment individually with multiple input records per compartment. For ships with complex compartmentation, preparing compartment input can be time-consuming.

 

The following is a typical hullform (without compartments) created for SHCP.

(image from  https://stability-shcp.com/wp-content/uploads/2020/08/ThruView-CV34-sample-1024x499.png)

 

  4. Supplemental data

The last point of each station is indicated with a "88888" tag. The last point of the set of offsets is identified with a "99999" tag.  Breakpoints (abrupt changes in curvature) are flagged with a "77777" tag.

 

D. Usage

  1. Ease of learning

My copy of the original user manual describing the input data is only 23 pages. The program was thus fairly easy to learn. Over time the user manual has grown to nearly 400 pages, so the learning curve has increased, although not proportional to the user manual size since the modern manual is much more comprehensive than the original.

 

  2. Ease of use

Since SHCP operates in batch mode, ease of use is directly related to the effort of preparing the input files. Ease of input preparation has been improving over time with the development of various GUI (graphical user interface) utilities, as described below under Functionality.

 

  3. Performance

SHCP is very fast and extremely memory efficient -- as it had to be to fit the complex code and data needed for damaged stability calculations into a mere 32K words of memory. While these stringent hardware limitations are no longer relevant, I believe the program's legacy of speed and efficiency has been largely retained. This is primarily because its compact, highly memory-efficient core code is so hard to understand that few have attempted to tinker with it!

 

E. Reliability

  1. Error response

Error messages are sent to a line printer or, in later versions, to an output file. Messages are descriptive one-line sentences that summarize the nature of the error. A more detailed explanation of the error is given in the user manual.

 

  2. Malfunctions

The program has always been very reliable and rarely crashes when fed valid data.

 

F. Functionality

  1. Missing or problematic features

 

Interactive operation

Probably the most glaring deficiency is SHCP's lack of interactive operation, a result of being designed long ago for batch operation. Later, a GUI module was added to control its execution while running in batch mode. More recently, at least one third party vendor has produced GUI tools for preparing SHCP input files, and displaying its numerical and graphical output file data.

 

Station point restrictions

Because vertical coordinates of successive points of a station must increase, it has always been difficult to model hull features such as flat overhangs (vertical coordinates do not increase) or tunnel sterns (vertical coordinates decrease). The original developer recognized these issues and devised workarounds to handle such station shapes. I believe the same third party GUI vendor has incorporated some of these workarounds into their input preparation GUI.

 

The "runaway parabola" problem

 

A third issue is not strictly an SHCP problem, but can occur with any CAD tool or manual calculation that uses parabolic, cubic, or other interpolation methods besides linear. I call it the "runaway parabola" problem.

 

Especially in areas of near-horizontal slope such as the bottom of the ship, the points that comprise a station, if not taken carefully, can result in interpolations that deviate significantly from the intended station shape. A normal plot of the input points will not detect this since both pen plotters and graphics systems connect a string of points with straight lines, which may appear much closer to the intended station shape than the parabola (or cubic) computed by the interpolation formulas. The calculated stability results may look reasonable, but actually be for a hull shape that deviated more than just a little from the shape intended.

 

This problem was either discovered, or suspected and then confirmed, when SHCP's original developer wrote a utility to plot station shapes using many interpolated points in addition to the raw input points. It was then realized that this same problem had been affecting manual naval architecture calculations for centuries because the manual calculations also used parabolic formulas. However, with no computers or plotters to draw the actual parabolic shapes implied by the table of offsets, no one was aware of the problem.  With the advent of SHCP, the problem came to light.

 

  2. Best features

Having been in continuous use for over 50 years, SHCP is probably the most thoroughly tested ship stability program in existence. Its reliability, speed, efficiency, and accuracy (given correct input data) are arguably second to none.

 

G. Cost

SHCP is not for sale, but is typically provided free of charge to those working on Navy projects who have a need for it.  It has also been provided to some universities that teach naval architecture.

 

H. System Requirements

It should be possible to compile and run the core SHCP modules on any system with a Fortran compiler because its original developer used a subset of Fortran common to all compilers, and avoided all language extensions and proprietary syntax. The GUI utilities mentioned above are supported only on Windows.

 

 

[ShawnC]

On 10/20/2021 at 12:37 AM, Richard Dunn said:

Hi Egilman
I am happy to help as I do this for a living, I am a professional 3d modeller and specialise in boats and ship and architecture.
If you are using those programs because you know them , great but if not you are better off with rhino3d as it is used  by many Naval Architects because Nurbs modelling is the best way to do hulls and it has the ability to properly fair your lines.
happy to guide you just let me know the sort of detail you have, are you using a lines plan or trying to build from deck plans, or from nothing but profile and plan which is much harder if you want to be accurate

Hi Richard, 

I'm an Architect and a friend of mine asked me if I could help model the hull of a small yacht which he just bought. Would you be interested in taking a look and giving me a cost to do this as I use Revit which really is not great for complex geometry such as this. I have the orginal drawings which I have scanned (plan and some sections) and could supply these as DWG no problem. If you are interested can you let me know via email - shawnintheuk(at)gmail.com. Thanks!

[Richard Dunn]

Sure, I have emailed you.