Instead of copilot, or anything that more deeply embeds Shark CAD, or anything ViaCAD even more deeply into proprietary land of MS or any company external to Tim's creations, I wish the team would make their own internal AI GPT LLM engine from the available Open Source types, fully open.

And, absolutely, absolutely, Tim should not out users on a path that enables MS or any other company to generate real-time access into a CAD file. Even if MS made its own CAD app or bought out a CAD company or funded one, it has ZERO business trying to figure out what people are drawing. A line has to be drawn somewhere, and since nobody can tell the future, nobody has an inherent right to real-time glean a design or a document before its author presents it for general or public consumption.

(((So, I hope that the recent new and redoubled introduction of ***local, private, offline*** AI/GPT/LLMs is something Tim is keen to appreciate and will empower designers whose machines are never (knowingly nor intentionally put) online maintain privacy until the designer is ready to share. It is blazingly obvious that if any company can peek at or glean edits, they can build competing stuff, get patents ahead of the designer intent on but too poor to rapidly file for and obtain, a patent. A patent that is inevitably assigned should and must go to the rightful, factual creator of the matter, not to a party with greed, deep pockets, speed, and influence.)))

Then, train the LLM on things to help produce mathematically approximate curves to replace designer-made curves. The suggested curves would balance out badly-positioned control points such that the overall surface, plate, cone — whatever geometry mimics realworld, reproducible objects — can be a suggestion that most closely fits the designer's intent.

An interactive feedback loop should be possible, especially since there now are becoming available some non-vendor-lock-in AI/GPT/LLM products for which there may be zero excuse to avoid using, even if boards and investors of CAD and other are beholden to closed source offerings.


Deeper in the weeds...

Example: in almost all of my ship hull designs (real world lengths of 535 to 580 feet, or ~ 161m to 188m), I use control point splines to create a halfbreadth of the ship. Each spline has a length of about 20m, from keel or bottom centerline out to waterline beam, up to the gunwhale or top deck. (The stem and the transom splines will usually be a little longer and shorter, respectively.)

Each control point spline (more desirable that Interpolated Splines, for this work) has some 20 control points, whatever the number, a consistent use to keep the hull as visually smooth (faired) as possible.

(Since it took me YEARS to eventually realize my underlying ISO curves body was horrendously hideous — I literally caved in and almost was depressed because I was too dumb or idiotic to realize I had to appreciate the need to evaluate the utility of the ISO curves, and that doing that would have spared me the devastating ugliness of insulation, "hungry horse", and other circular chasing of problems)).

I explored and quickly avoided further exploration of interpolated splines because they are too "wild", untameable. The tiniest of movement in any tail wildly changes the flatness or radiusing in the hull.


Number of control/input/shaping curves and their control points:

Naval architects and drafters/CAD operators say "use as few curves as possible — ideally no more than 8-20 stations of curves...".

I for years (between 2008 and 2013) tried to go by that, and it led to pure pain for me since I'm not ever interested in creating curves that only represent just the between-peaks (forepeak and afterpeak) stations. I include the raked stem from prow to sonar dome, the sonar head/dome, its breadth, the sonar neck transition back to the ship's keel, and then the keel skeg. I abhor "surface patches", and nowadays, it seems even Rhino spares users of having to contemplate the myriad types of patches, since Grasshopper, Orca, Nemo, Swordfish, and others have bazillions of features to make ship hulls far easier, far faster, far more efficiently that in general/generic CAD.

Still, for those who can't afford, don't want to use, or feel intimidated by the mega-powerful plug-ins for Rhino, there still is something to be said for designing ships in general CAD. It's kind of like comparing letting robots do organ transplants for efficiency vs letting doctors do it for "practice". It's sort of like a writer writing from a list of brainstorming ideas generated by the writer who researched, vs the writer who asks a GPT engine to create a list of 20-50 topics.

There's even something to be said for doing one's own spell checking as much as possible, as a possible means of staging off premature dementia. At the very least, it's probably worse to lazily let an AI hallucinate embarrassing content than the author letting slip in some of his/her own run-on, typo, spelling, incomplete thoughs, or logical errors. It's far worse to lazily miss that an AI generated completely false references and the AI/GPT is too stupid to even search to see if the hallucinations have real-world names, dates, context, and relevance.

As intriguing and attractive as Rhino ship hull plug-ins (paid and free) are, I prefer to use SharkCAD as a form of therapy, introspection, and similar. I don't have deadlines that real-world engineering teams face.


Secrecy is painful...

Doing that in secret and struggling to not tip off the forum (I didn't want to be "beat/en to the punch" (pun not intended, but belatedly liked as if intended) with my own design activity led to enormous and unnecessary internal strife. I eventually did reveal some of what I was doing — I began sharing more of the images of my hulls. In some instances, I inadvertently overshared, possible giving away something unique. So, I cut back for a long while.


Back to the curves/splines...

Each semi-station spline has compound curvature. The splines have interesting properties, it seems, depending on how one chooses to mirror the hull.

One can mirror the surface made from the initial, halfbreadth curves in my case, always from starboard, and bow at screen left, stern at screen right, and mirror the starboard half towards myself/designer (as I eschew what appears to be the traditional stern left, bow right, mirror the math from body closest to the designer to away from the designer...)

One can do what I now since ~ 2016(?, IIRC) do: link-mirror the curves. But, SharkCAD refuses to allow by-station collection/pick-up of pairs of curves successively added to the lasso or hand-picked selection to be temporarily stored in memory as longitudinal additions, then build the hull.

Restated, I can't pick each starboard-port pair at say, Station 1, then Station 2, then Station 3, to completion. And, an error dialogue appears if the selections are let go too early or in ways not expected by the app.

Clarification: "All wires must be either all open or all closed for..." occurs because there is a gap (curve flaring upward and outward) at the stem and when building the surface from mirrored curves, the foremost curve-pair is actually connected at the bottom, via either link-mirroring or by something I did. (I need to revisit exactly why... )

Worse, often, if not always, SharkCAD doesn't prioritize the surface-build longitudinally, or from an origin out along the known, defined, or ought-to-be-presumed axis. So, I've had numerous times when Shark internally orders the curves randomly, and instead of a hull, I get a crazy, self-intersecting, moebius-like body that has the potential to crash the app depending on whether the bad geometry is deleted or put through "undo".

Again, operating in fiendish solitude, it took me months to wisen up to the capability to rebuild the parent and the linked-mirrorred curves as one piece. I think I subconsciously found it an anathema because I was looking at:

— ~ 30+ stations of splines;

— ~ 12-20 control points per spline, halfbreadth;

— mirrored curves resulting in 30 * 12 to 20 * 2 control points needing individual, attentive touching.


That touching was a mind numbing, tedious, soul-draining activity, not like drawing a monster or a figurine, or a cloud, or such and divining inspiration. The hull is largely symmetrical, aside from custom differences such as anchor pockets, hawsepipes, utility access ports, etc. If drawn as if someone may want to examine it for "design to production" standards, it may be better to draw the hull to constraints than in freeform — unless a constraints engine binds the freeform to the bounds preset in the intent for the model.

I found that even one solitary control point being a fraction of a millimeter off generated slightly observable unevenness — and that was before I resumed wearing desperately-needed eyeglasses.




By chance, I copied the hull surface and pasted it. It was in a session in which I had already turned back on the "show points" feature. That feature infuriatingly NEVER STICKS and I'm perpetually forced to remember to turn it back on each session. It feels like torture that this setting never "sticks". After pasting the surface (halfbreadth and whole-hull), I found I could access these points somewhat the way one can access the control points of a mesh. However, my hull surfaces have so many underlying control points that the pasted surface has 10s of thousands of accessible points. That's far far too much work content to be expected from a human. But, an AI that watches the user/designer a few weeks would learn to build an algorithm to aid the designer hand off to the AI the mundane corrective work content.

The hull surface mirrored by creation of halfbreadth curves and then made into a surface which is mirrorred and joined (for downstream stitching to try to make a solid) revealed my underlying curves had poor tangencies, which were creating cleavages in the keel. I could adjust the control points easily enough, but it still is a lot of work content. The work content was/is necessary to massage the hull into being able to be stitched, with the least tolerance required.

However, the hull surface made from rebuilt link-mirrored curves turns out to be visually smoother. Something about it gripped me, and there was no going back to using mirrored surfaces. It's almost like the feeling of choosing between cheap plastic and robust steel, visual and tactile.

Amazingly, even the sonar head and keel skeg geometry seem far superior visually.

However, working the sonar head and keep skeg to be one piece (and not the add-on stuff I saw in DTMB/RINA/DTIC/NPGS papers showing meshes that either seemed to imply that it wasn't a limitation imposed by the CAD apps of between 1980-2010, but instead was a conscious choice to have flexibility in selection of optional sonar head and bow stem meshes) was incredibly painstakingly a game of cat chasing its tail.

The keel skeg had the worst upward/skyward cleavaging. I now can generate (by hand, eye point-nudging) a keep sleg that is inches narrow, not 12-20 inches, but maybe 4 inches in breadth. Real skegs might be around 23-36 inches wide.

Still, there are three places where I threw in the towel due to the exhaustion incurrred in adding even more control point splines to remove wild curvature caused by "weightiness" of throw due to proximity of the control points when they are VERY close to each other:

— junction/convergence of the sonar to hull keel transition (a convex or up-curvature of maybe 6 inches, with a run/length of maybe 24-40 inches);

— similar juncture/convergence aft of the keel skeg to the keel before the transom;

— uneven flare and apparent radius flow issues, since SharkCAD (and ViadCAD Pro) can't auto-fair curves they way a human might imply to be completed.

Interpolated splines don't lessen the pain.



If Tim and Company can put up with proprietary strictures (strictures, not structures) in AI/GPT/LLM code and licensing, they could likely divert that money to hiring one or two coders who can build an "intent" engine that can auto-fair curves based on pairs of them or a whole collection of them.

I tried a suggestion (from years ago, maybe 10 hears ago) of over-building the hull, then using a curved surface as a cutting reference. But, that means impeccable alignment is needed to not mess up the stem-top-deck junction. Too high, the ship is too long, and apparent length overall markers have to be repositioned. Too low, and the hull is too short, and the control points have to be messaged to correct the foreshortening. Done just right, the hull can indeed have better sheer. I generally don't include camber, so I dodge the issue of trying to make a top deck with camber.


I can add even more between-stations curves to suppress the up-curvatures in the sonar and keel skeg. But, doing that is how I went from 8 to 10 curves out to 15, out to 20+, out to 30-32 curves.

Sometimes, I found that due to precision settings, points I thought were precisely three or 4 or 5 digits were not truncated to those. If I increased the precision to the 16 or so max digits or decimals, I could then realize why my hull would show slightly visible undulations in the starboard vs the port-side surfaces.

Link-mirrorred curves are great — unless your eye demands more in the context of making hulls in generic CAD apps. Perhaps if SharkCAD had add-ons/plug-ins with features such as those in Grasshopper, Orca, Nemo, Swordfish, and Notilus (I doubt will happen since doing so might encroach on the company doing the Aropack features stuff), an enormous amount of tedium could be wiped out for users. But, Tim probably wouldn't get the required ROI to justify embarking on opening up APIs for users to create a store for SharkCAD add-ons or add-ins or plug-ins.

I ditched using meshes because:

— any "wrapping" of surfaces by meshes won't wrap my hulls;

— I find building a hull from meshes no a monster-sculpling operation;

— I haven't figured out gripper "mesh symmetry" in the context of making a ship hull;

— converting my control point surfaces to meshes generates control points and vertices that exceed the program or perhaps restrictive license limit of mesh tris or vertices allowed to be reconverted back to an editable surface or any kind of surface;

— even if the mesh could be reconverted to a surface, it's too much circular effort for me;

— I realized, back around maybe 2011, that surfaces and meshes can't intersect, trim against, or otherwise be useful in a mixed context. Plus, I couldn't then (and probably can't now/today, even) collect mass properties such as mass, volume, and centers of gravity. That put in me AN INSTANT and complete rejection of meshes.

Similarly, the copy-paste-exposed surface control points geometry has its limitations since a vast multitude of vertices can emerge. Incorrect selection and movement can irretrievably tangle the points. A few episodes of that and questionable "undos" made me abandon a file rather than save it.


Additional observations of using mirrored and link-mirrorred curves (which may apply to most CAD apps, depending on the Spatial or other graphics engines/kernels they use):

— non-link-mirrored: the hull can be closed at the stem, and once a transom is added, can be watertight at the waterline; otherwise watertight if the hull-top-deck geometry is acceptable to the CAD engine;

— link-mirrorred, NOT one-for-two-replacement curves (the starboard and port splines are effectively two pieces, with the symmetrical half retaining associated points mirrored): hull can be watertight as above;

— link-mirrored, one-for-two replacement, as in I manually create a new set of splines to be one piece per each two pieces. This defeats some aspects of using link mirrored curves downstream, since any revisions to the hull mean more work. But, the hull surface creation seems to be better. It's probably a function of how the internal algorithm handles the surface.

That and the precision digits means I had to manually create straight curves (lines) originating from the parent curves and touching what I thought was the initial, correct mirrored point. Then, if by intent or by mistake I moved a parent or any opposite curve, I could find the errantly displaced point and snap it back to where it should be. But, that is only good if the parent and displacement indicator curves are kept related.

An AI/GPT/LLM could monitor for that and save the user/CAD operator an immeasurable amount of time.

Edited by user Sunday, November 24, 2024 1:06:48 PM(UTC)  | Reason: Horrendous typos, spelling, incomplete thoughts, other errors...