shiplab / vesseljs Goto Github PK

xCentre, yCentre and zBase are inside the position object, not directly under the object state.

Include slide for changing fulfilled tank volume.

The lines (mooring and equipment lines), dynamical matrices (masses, damping and restoration), and the equipment I am inserting for epoch project are disconnected with any external JSON file, creating a lot of global variables like in the examples that succeeded my 6DOF calculation:
https://github.com/shiplab/vesseljs/blob/master/examples/Ship_in_Ocean_dynamical.html
https://github.com/shiplab/vesseljs/blob/master/examples/Ship_in_Ocean_dynamical_MooringWave.html
https://github.com/shiplab/vesseljs/blob/master/examples/Ship_in_Ocean_dynamical_MooringWave_Parametric.html

I have some solutions for how to organize better those information and I would like @hmgaspar , @EliasHasle , @icarofonseca , and all others in the project to identify the best solution based on the vesseljs main objective:

1. Insert the elements variables in the JSON of the ship and change the function loadShip to read those information. This solution could be applied to mooring lines or dynamical matrices, once they can be interpreted as part of the ship system information.
2. Create a function similar to loadShip to read the other elements. This solution could be applied if we interpreter the mooring as a different system from the ship and could prevent errors in loadShip.
3. Let elements in the own code, just transforming the global variable into smaller object oriented variables.

Add an object (hull and blocks) color, with html color and alpha/(transparency info, e.g. {"red", 0.5}

I am a Marine Rescue volunteer and we have a twin outboard vessel that does both towing astern and towing alongside. We often use the motors in ahead/astern (ie split controls) to manoeuvre in close quarters. I would like to use vessel.js to train helmsmen and I cant seem to find an example with separate controls for two motors. Is there already a model that I could use for this purpose If not, some hints on how to create the appropriate models would be appreciated

Our version of vessel is based on the version of THREE.js r86, consequently I noticed some issues about inporting a glb file throught this version and I had to use a newer version of THREE.js for it. Another problem I wish to report is Ship3D.js can not import STL throught the observable, just the version Ship3D_v2.js. Those excess of duplicated codes, the disclosere from the currently versions of THREE.js and the use of incompatible functions can make us losing some currently features in THREE.js. Summed to that we have the willing to modernize our code to adequate to ES6 as stated in #103 .

I am currently verifing this compatibility as shown in #128 and I manage to do some alterations in the main features we currently have to support this change:

• The Configurable_ocean2.js was created to substitute Configurable_ocean.js. The function ocean in this new version eliminate the THREE.Mirror dependency and is based in the Water.js instead of Mirror according to the example provided in webgl_shaders_ocean.html. We must as well compatibilize with the several versions of oceans as discussed in #129 to ensure no dependency;
• The skybox_from_example.js can be substituted by skybox_from_example_r118.js when using the r118 from three.js.

The bad pointing about adopting this changes is I am not completly aware how it can effect the dynamical oceans yet and the extra effort necessary to adequate the several examples we have in our main page. I raised this issue to question what we can make in front of it, but for me, keeping increasing the several duplicated snippets and libs will make our library harder and harder to use.

Product attributes structure.
Propeller has attrib., also input from the vessel, maybe from the environment.
Flowchart for DP positioning.

Not to be added to the code right now.

The error handling when file is not found tries to get e.file. Should instead be bo.file3D.

The current hull weight calculation is broken. Problems:

1. It uses at least two arbitrary calculation parameters that should be calculated from hull geometry: Cb_design and LWL_design. They could both be found by calling calculateAttributesAtDraft(Draft_design).
2. The example K value from the table gives output mass in tonnes, while everywhere else we are using kg. This can be solved by multiplying the K with 1000 in the input or in the calculation. Or by using tonnes everywhere else.
3. It is not mathematically correct to strip down the structural weight calculation by removing components of E, because the exponentiation E^1.36 cannot be simply decomposed as a sum of exponentiated terms (with the same exponent). I don't know how to solve this, except using another weight approximation method entirely.
   ( @MrEranwe )

I remember Henrique ( @hmgaspar ) mentioned a method where the hull is modelled as a rectangular beam with main dimensions derived from (identical to?) the main dimensions of the ship, and the weight is approximated by the weight of this beam after dimensioning according to some constraints. I think that is interesting. But we/I need more details of the method before it can be implemented.

Henrique also mentioned that there are "countless" other methods. I would prefer one that introduces as few parameters as possible.

I am also still interested in exploring how to model variable hull thickness. My proposed solution is to have an extra offset table for the inside of the hull, such that the difference (or the stored value) would be the transverse thickness. This is easy to do calculations on, including hull shell mass and cg. But it does not account for the weight of supporting structures. (Finding the appropriate thicknesses would be a separate problem, just like with hull shape in general.)

The mooring does not have a general function for inserting it. Therefore, it is being repeated over again in several codes:

In aditional, the defined functions are using global variables, preventing the js files to work as snippets, problem stated also in #100:

As a solution I will create a snippet InsertCatenary.js which will receive the starting and final points of the line, an object containing the geometry, materials and coefficients of the catenary, the number of division, and the scene. The function itself will be responsible for changing the 3D model according to the initial and final points and return the forces (If appliable).

The function will also calculate for the cases in which the Horizontal Force is known (eletrical cables and uni dimensional mooring) and the cases that it is unknown (6DOF arrangement). I will also make a Observable tutorial to standardize this procedure.

Three.js are moving towards more modern source code, and I am certain it would improve both readability and maintainability to do so with vessel.js too. A bundler like Rollup.js can be configured to transpile to backwards-compatible code. Dependencies can be included by using NPM.

Classes:
Converting to classes is mostly straightforward, and will greatly improve readability and aid conceptual distinctions. (I notice, for example, that InsertCatenary is referred to as a function, yet the prototype is modified, which indicates it should be used as a constructor.)

Here is a conversion pattern. From:

function Ship(L,B,T) {
    this.L = L;
    this.B = B;
    this.T = T;
}
Ship.prototype = Object.create(Object.prototype);
Object.assign(Ship.prototype, {
    mockDisplacement: function() {
        return this.L*this.B*this.T;
    }
});

function VeryLongShip(B,T) {
    Ship.call(this, 1000, B, T);
}
VeryLongShip.prototype = Object.create(Ship.prototype);

to:

class Ship {
    constructor(L,B,T) {
        this.L = L;
        this.B = B;
        this.T = T;
    }
    mockDisplacement() {
        return this.L*this.B*this.T;
    }
}

class VeryLongShip(B,T) extends Ship {
    constructor(B,T) {
        super(1000, B, T);
    }
}

Modules:
Have each source file import only what it needs from other modules (typically a superclass and classes that must be constructed), and export only what other modules need (typically a single class). A single file, for instance named Vessel.js, serves as an entry point that provides all the global references. See the three.js project for an example on how it is done on a larger scale.

Bundling:
Three.js uses Rollup.js for bundling. I may aid you a bit on that one, since I have recent experience with using it, as Henrique/@hmgaspar hopefully knows.

Dependencies:
Dependencies can be included in a more principled way by using NPM. NPM can even install from GitHub, if the repos contains a valid package.json (with a compliant collection of files). package.json can configure which version is desired of each dependency. I can aid you with this too.

I have improved some of the scripts that are used in vesseljs and released them separately in Node/NPM package format:
https://github.com/EliasHasle/map-view-controls (a precursor is used in the GA example)
https://github.com/EliasHasle/patch-interpolation (minor changes)
You could also consider https://github.com/EliasHasle/kwargs.js

You will benefit from my later improvements if you use NPM to import dependencies. Node.js includes npm.

pinging @ferrari212 @DiogoKramel @icarofonseca

Check http://dbb.ucl.im/, hullform data, and implement it as "first" guess.

Modify "Comparison" to Hydrostatics (draft is input)

Add "General Arrangement" with a table of Blocks
prop1 . prop2 . prop3 .
b1
b2
b3

Sum by hand and by software

Add "Whole Ship" Table, with ALL properties, draft and other calculations are output. Later in the future we will add slides to it.

I have accepted PR #165 into the dev branch. This PR includes @ferrari212´s work to implement ES6 modules and class patterns. However, these modifications require some adjustments before being merged into the Master branch:

• Modify scripts which are retrieving libraries from URLs (e.g., this one) and commit these libraries to the repo so the apps remain working in case the URL breaks down in the future.
• The transition to modules caused differences in scoping where (detailed on this page), where some methods which were previously "closures" became "modules". The tests Felipe wrote show the results is calculations are the same. It is worth confirming this behaviour remains in more complex examples with multiple vessels simulated at the same time (to get confidence the scope change is not interfering with anything).
• Once this is done, it is needed to define which examples and scripts will be migrated to the new module syntax, adjust the repo's folder structure, rewrite what is needed, and test each one.

One thing I learned recently: e-mail is where knowledge goes to die, probably even more for open source, so I'm extending the discussion about shipState here.

I am doing some things related to ship motion, state handling and updates on my thesis. I am going to briefly explain the pattern here, so we can discuss what is good and what can be improved. I'll use the state module WaveMotion as an example, though it applies to all the other state modules I wrote as well.

So:

A WaveMotion constructor receives as arguments a ship instance, a wave object if necessary and some additional parameter which are set to default values (gravity, water density and viscosity, for example). The wave object right now includes at least information about a single regular wave state and a version flag for it. In addition, it could contain a method to change the wave state along time (this method could possibly get as fancy as you are willing to make it, but right now it only changes the wave back and forth at every hour, for the sake of example).

A WaveMotion instance performs calculations with getters inherited from its prototype. There are getters for vertical motion response (heave, pitch), roll and bending moment. Motions are calculated only as amplitudes, not as time series. The results getters are very granular, so you don't need to calculate bending moment if all you want to know is the vertical motion. To avoid calculating the same getter over and over again, they include a memoized cache: they store results of last invoke with version flags for ship and wave state. When they are called again, they will verify if results are outdated, and only if so they will perform calculations again, if not, they will return stored results.

A state module also includes a writeResults method to write results to ship state, automatically increasing its state version counter. You can choose which are results are relevant in an array listing them, defined as a constructor property.

The caching and version control in ShipState is clumsy and incomplete. In hindsight, I judge it as a case of premature optimization and overcomplication.

Elias should document what is broken (maybe add it to blockCase_compare_json.html or create a new thing)

Simple box-like
3 blocks

To test Ship.JS calculations and in the future solve "Trim/List" problems.

Create ABC path with fuel consumption output:

Time Domain
Spatial Domain

What is INTERNAL and EXTERNAL input (internal = from our library; external from other parts)

Future this will be applied using our library.

In demos parameterized by ocean size, with controls.maxDistance = 0.5 * oSize;, nothing is lost by setting the camera far distance to 1.75*oSize. This can be done at construction:

camera = new THREE.PerspectiveCamera(26, window.innerWidth / window.innerHeight, 1, 1.75*oSize);

Improved depth resolution can help against z-fighting (flickering) that occurs when different distance values are rounded to the same depth.

Another cause of z-fighting is that distances to coplanar (or, less critical, intersecting) surfaces are in fact equal. I have just done an experiment with adding a random jitter within +-1 cm to the position coordinates of all objects in a ship, and it works against the z-fighting (when used together with the closer far plane). I will show you soon. See f538ce2

Similar example with blocks and weight as input, adding GZ curves.

This line causes the deck outline to be misaligned whenever the stations are unevenly spaced or the deck is not in full length. Simply setting x = stss[j] will give a better looking result, but causes some NaNs to propagate into the geometry and give error in the console on computation of bounding sphere (in Three.js).

This part of the 3D model generation code would anyway benefit from using a box geometry as base instead of a plane geometry, so that the deck can be modelled with one outline at the bottom and another at the top. I am not sure I have the time to do this.

The same considerations apply to bulkheads, which can be implemented in almost the same way, but using hull.getStation for trimming instead of hull.getWaterline.

Calculate Stability Curve for our Hull

The current hull is from a fishing boat. It does not fit very well.

I believe it is not too hard to just generate a hull shape that encloses the objects and satisfies a few constraints, such as symmetry, smoothness along sides (?), monotonic growth from ends to greatest width.

I just want us to keep it in mind, even though it is not of the highest priority yet.

Right now, a few useful functions are exposed through the object Vessel.f. If there are any other functions in the functions folder that you would like to use in your examples, we can expose each of them by making a tiny modification to makeBuild.py before building.

Should the vector operations be in Vessel.v, perhaps? Any other suggestions on how to do this without making a mess?

Done!

GM = KB + BM - KG

STL should be optional, but not mandatory for simple prismatic block. For a new block, if there is no STL, it should be simple to add and delete. Please check with Elias.

Simple API page with some descriptions and/or examples.

I want to propose a new organization for the project's online resources. It will be as follows:

• This repo will be used only for development of the Vessel.js build files.
• A second repo will host the Vessel.js website with all other library resources (examples, ship specifications, STL files, research papers).

Advantages as perceived by me:

• More organization in the resources: the examples folder in this repo is becoming crowded and will become heavier as we aim for more detailed STL models.
• Less entanglement in the development of examples: we will be able to carry development of the main library without being concerned whether it maintains supports to all the examples we developed so far. The examples will be stored in the second repo with the builds used to develop them by the time.
• Better support to the development of our website: the second repo can be used to host the Vessel.js website with GitHub's own "pages" feature, making the current server unnecessary, at least for now (see it in action here). It also provides version control (something our current solution Cyberduck does not, as far as I know) and supports assigning our custom domain (i.e., vesseljs.org) to the page hosted in the repo.

Additionally, @DiogoKramel and I have been working on a script that will allow users to download a .zip with the source files of an example. You can test a prototype here.

Add and object with info for scale and rotation, and make it optional for derivedObjects. These changes must be incorporated in the 3D.

Example "scale_rotation" = {0.5, 3, 1.7, 90, 0, 270}

Close 3D hulls in extremes (aft, fore, bottom).

Overtime, I built a project with vessels by downloading the zip file and pointing my project to vessel js source code. However, this has become ambiguous as deploying this projects online involves the addition of vessels source code.

Solution

• Create an npm package for Vessels
• Add CDN support for Vessels JavaScript

I have experience doing this, if it's okay with the team, I can work on this with my fork and update the readme on installation guide.

• Fix isNaN issues and other small bugs (check open issues like JSOn export)
• Commit all to master
• End caps and bottom caps (there is another open issue for that)
• Apply click and editor similar as Ulstein work.

Bulkhead just reaching half the Breadth of Ship in Ship3D_v2.

Currently checking the compatibility of our code I noticed a series of duplicated contents for creating the ocean in Regular_ocean_final.js, Regular_ocean.js and Configurable_ocean.js, a problem that happens often in other parts of our code as I stated in #101. As a result newer users can be unsure which of the snippets they can apply and the lack of documentation makes complex to understand the particularities of each method.

My suggestion is at least to merge the Regular_ocean_final.js and Regular_ocean.js into a single code because they have minor differences. Then make Configurable_ocean.js as an extention of Regular_ocean_final.js.

Let the user click an object, and show basic info of this object in the GUI control (id, l, b, d, file3D, colors)

In the future, it should also be possible to change position, state, stl file.