Open Source Marine Design Package Kickoff

Hi CWTeebs,

Sounds like a nice project you have in hands. Are thinking about leaving your code opensource or selling the plug-in?

Cheers
Ruy

 

Roskilde, as an example of what I mentioned on my previous post, this is an open-source project in development, by Greg Saul. It is focused on laser cut chairs
What can a chair do for boat design? inspiration can come from everywhere, just look at the videos
http://vimeo.com/7199198
http://vimeo.com/9488518
http://vimeo.com/7131980
http://www.sketchchair.cc/

Now think on a boat roughly sketched in seconds an then refined in full 3D while seeing his buttocks, waterlines and sections in 3D, real time, and checking his buoyancy, hydrostatics, mass distribution, stability, by using newtondynamics, reactor or any other physics engine.

Another interesting feature: this is a www.kickstarter.com financial project...

 

I would like to add, too, that Freeship/Hydronship can be very useful.

I would like to suggest that when it comes to hull modeling, the hull be faired and yet decomposable.

For example, some programs tout the advantages of using a single half-breadth surface or mesh or solid to represent the hull. That may be great for those interested in that. But, what I am interested in are:

1. modeling the hull to the point of acceptable hydros for the hull's intended purposes

2. "breaking" the hull at either the midplane of the transverse watertight bulkhead OR breaking the hull at a convenient location just fore and just abaft the transverse watertight bulkheads.

3. thickening the hull so that it is smooth and not ruined by the finesse and nuances of NURBS/et al when the underlying surface or curves are modified. The solid or surface should not crash the hull model or app, and the curves forming boundaries in the transverse bhds should programmatically and explicitly presume that a hull shape (maybe other than the sonar domes of combatants and the skegs/transoms of certain ship types) will not have too much curvature and definitely no pig-tailed kinks or twists allowed to form, wasting CPU time and producing stuff that might awe an abuser of controlled substances.

My approach to hull design that is that the same hull will be used in CAD. So, whether I'm jusing PolyCAD or Freeship, I want to form and fair the hull and install transverse bulkheads where I want or am limited by hydros/stability considerations, then subdivide the sideshell according to the boundaries of compartments, not just based on the maths under the software handling.

This approach makes it easy for me to know explicitly what compartment is contributing what amount of influences on the hull plating. So, if I want to stretch or truncate a compartment, I can see the effects in-model.

Also, some sort of longitudinal properties line indicating mass props, stability, and volume ratios overall and locally (in the case of compartment subdivision) might be useful, but that seems to be far in the future of your development since you're in the early stages.

I'm not a naval architect by any stretch of the imagination, but when designing combatants, I look at things somewhat differently from the academic and career methods used by true engineers. I suppose that the big, $10,000 per seat apps would provide what I want, or if they don't have it, they'd be happy to test-bed some firm and then plop it out at an additional $800 per licensed user in the install base even if only 10 out of 37 local users make use of that feature.

Unless it turns out to be some sort of "contamination" or non-clean-room risk, you might want to see this:

http://www.youtube.com/watch?v=0-mse...eature=related

Again, this kind of feature set is probably 10 years into the future of your activities unless 35 devs jump to your aid and each brings along 2 or 3 more devs, and everything has a sort of Linus Torvalds in each group reporting to one Top Dog Linus to keep all on track.

And, with good APIs, it should become possible to have more plug-ins potential than most of any of the other non-interactive apps (closed and open source) out there. Since I have weak focus and am only one person with no team behind me, I waste inordinate amounts of time tweaking a hull in Freeship only to find in the finer-grained ViaCAD/Shark that the model needs reworking. The real time waster is that ViaCAD and Freeship have no way to intercommunicate. Shaping a hull in Freeship would be fantastic if the nudging of control points drove ViaCAD (or any CAD app with the right API capabilities) to display ITS OWN view of what the user is doing. So, if I set constraints in a CAD app to keep the hull faired for CAD purposes, it feeds back into the apps like Freeship where granularity is less refined.

Then, If I need to add a few centimeters or a meter of beam or any depth change or draft change, the CAD app could feed into the Freeships out there so I can use they Freeship/Hydronship hydros suite to evaluate the apparent changes needed.

Technically, since my ships will not be built, my time waste is really my own fault for having weak fairing skills and for not thoroughly understanding the strengths and weaknesses and incompatibilities of line types, curves types, and surfaces vs mesh types.

Speaking of which, if a beautiful hull is shaped in Freeship, a CAD package should be able to see that mesh and just USE IT as a user-desired surface. It is thoroughly demoralizing to hear a dev say "that is not our forte to convert a mesh to a surface that our app can use -- you have to rebuild the surface..." and live with a bazillion facets to be stitched/forged back together. Most of my past 2.5 years of mucking about entailed fighting meshes, creating belatedly-wasteful/pointless end-run attempts.

It seems to me that some devs of huge apps PREFER the state of affairs in which their apps inherently cannot exploit or facilitate someone else's imported or exported surfaces or solids. It seems to me that if 5 or 10 devs around the world spent about 2 months together, a viable approach could be in hand. But, most of them would have competing employers who may not want that -- especially if jobs are at stake.

As for coping with hull boundaries and making CAD simpler to interact with, some built-in library of successful (proprietary libary that many modeling basins and CFD shops will NOT want nor be allowed (per clients) to share) or reasonable (from academic sources and models evaluated in Hydronship and other tools) library may be useful for keeping modules constrained to relatives or parents that will not allow the user to be too bogged down.

My ideal world of tools would include API interactivity between:

Freeship/Hydronship (for the hydros, powering, turning calcs, etc; free or donation ware; Victor T. gave me a LOT to learn about my models and enabled me to appreciate more and more)
PolyCAD (hull fairing, rapid prototype shaping of hulls; free, and seems to be a labor of love by Marcus Bole)
PunchViaCAD/Shark (for the 3D hull modeling from surfaces, and obtaining relative CGs, moments, etc; based on pure CAD (not sharing, xrefs, layers, etc), I dare say that ViaCAD is better than ACAD for detail work on ship designs, but ACAD is too entrenched in the markets, and ViaCAD is not being tuned to ship designers other than the users exploiting ViaCAD Pro/Shark that way)

And, possibly

CAFE (seems like an interesting hull development program, and it seemingly has a lot going for it)
CENIT (pretty interesting, but I imagine the costs are well outside of my range -- still, i need to look for the pricing, and whether or not it can scale up to 170meter length vessels.)




End of my rant.

But, I hope you make some great contributions!

BTW, check out the Hydronship or Delftship sites and download the user-supplied hull models. Many should be reasonable baselines from yachts to feeder ships to frigates. Testing some of them out in Hydronship may at least fast track understanding of the way the program could suggest fore/mid/aft changes to facilitate eking out that last .25 knot of speed or some desired moment or inclination angle.

If Victor, Marcus, and a few others whose employers or sponsors have no problem with helping you, other devs may jump in, too. It would be great to see what can be achieved.

Depending on how things go, I might use my Linux setup (with QT4, windows, Lotus Approach, etc) to prototype a MySQL or Postgres-suitable database to track compartments, manage weight, and for tagging distribution of stowed items. I did such a thing for personal use in 2003 for two of my combatants, and it became fun to use my Lotus Approach database to gain insights into weight distribution and placement of fuel, stores, and more in my as-drawn models. However, some companies may try to claim that their work (post-2003) may be threatened or infringed upon. In any case, no one would design a ship without tracking weight, ballast, consumables, fire fighting gear, and more. So, any spread sheet or Bill of Materials adapted to a database is prudent, necessary, and logical.

 

An example of something great to know:

http://www.youtube.com/watch?v=Viu-jvqTrN8&feature=related

This applies in Delftship and Freeship/Hydronship.

In PolyCAD, depending on the tools the user uses, this may be handled in other ways. But, often, in any of these three apps and probably a slew of others, once the hull is modified, any further changes may not contain the originating steps. Without a parts history and modeling memory of things, this work process could cost lots of time if the original drafter passed it on to a new drafter or other drafter with no knowledge of what drove the product design to a given point. OTOH, it may be irrelevant so long as the hull is closed and watertight, developable, and meets Class regs. Then again, some designers not under time constraints might easily spend over an hour because tools are still somewhat "primitive" in the grand scheme of all the "corporate" body of disparate knowledge out there but not captured well enough as an interchangeable library (maybe except manufacturers who freely distribute proxy models and detail models of their pumps, motors, doors, railings, engines, and numerous other items...).

But quite tedious when the model has to be stretched, widened, or otherwise modified, necessitating adjustments to the transom. A program with a huge or capable library would likely help automate this to spare the users of guessing the diameter, adjusting onset/termination of the shape, and so on.

Don't get me wrong. I do understand that many programs just have inherent limitations because it is hugely expensive to go after that last 15 to 5 percent of power that 99 percent of the users will not often use nor pay for. But, in the case of a sailboat in that video, if the owner's requirements or expectations did not meet those of a Classification Society or Coast Guard review, the designer (whomever it is) may have to spend lots of time tweaking things for the Society, the drafters, and the moulders/shop workers -- depending on whether the craft or vessel are exotic.