Representing weights

You can represent weights of as-yet-undetailed items in Tools/Weight Schedule. Create points with weight attributes to stand in for the missing items; for example, a point named 'ballast' with a unit weight of 4800-kg to represent a ballast casting. Place it where you expect the center of gravity of the ballast to be. It will be included in the weight schedule and combined with other weights. Later, when you've created geometry for the ballast and assigned it unit weights, you can delete the point, or change its unit weight to 0.
If the model has symmetry, be sure to make this point Symmetry Exempt, or you keel could be twice as heavy and might sink the boat when you open Hydro.

Creating a sketch plane in MultiSurf

In the image at the left the aft two master curves are in frames which allow them to be set at different angles by editing the Roll, Pitch, or Yaw angles of the Frame.

The points have their Dragging constraint set so they can only be dragged in the Y or Z direction, effectively locking them into the YZ plane of the frame.The procedure below gives you some steps to complete this construction.

Create a Frame from three points or a Roll/Pitch/Yaw Frame from one point and use this as a "sketching plane".
Put points in the frame and be sure to make the Frame the parent of the points. The points should be located in the x-y, x-z, or y-z planes of the frame. Depending on the plane in which the points are located, make the appropriate dragging constraint for all the points. This way the points can not be dragged off that plane with the mouse. Most kinds of curves will lie in a plane when all their control points do (Arcs, BCurves, CCurves, Lines, FCurves...)
You can hide the construction entities when the curve is done.

Labels: MultiSurf Tips

We are undergoing an improvement on how components are used and handled in the MultiSurf model. Here are some comments Reinhard Siegel offered upon seeing the development effort and he also adds valuable tips on how he manages components now. I have interspersed some tips of my own in his text.

> When I look through my library of components, there are hatches, doors,
windows, winches, blocks, fairleads, traveller, mast, boom, rigging wires,
stanchions, etc. Their common property is: an assembly of objects, that
depend on one single base point. Thus when loaded into a model, the only
parent for the component is a point entity (insertion point ip_xxx).
Dragging that ip moves all the entities that were in the component "xxx". To
access those entities conveniently I make entity lists:

> 1) an entity list "View_xxx", that holds the final, presentable objects to
show
2) an entity list "Edit_xxx" with "handles" or "grips", that allow
modification: winch meridian shape, stanchion height and diameter, hatch,
window, door dimensions etc.

RP - This entity list is a convenient way to form the content of a custom Real Values Dialog (RVD) for editing the component. The Entity List above should contain only Variables or Formulas so it will yield a RVD when the Entity List is selected.









> So by the "View_xxx" entity list the component can easily selected via the
Entity manager for hide, show or save actions (for example a Pov-Ray file).
Selecting the point "ip_xxx" and all its children is the road to remove the
entities created via component from the model.
>
> Of course, entity lists like "View_xxx" and "Edit_xxx" are not restricted to
objects created in a model via Component Load. I use them extensively to tie
a group of things together for fast selection - show, hide, save.

So far to my practice. And I must admit, it has been working fine for me.

Reinhard has seen the Development version and is commenting on same...
>
> And now there is a Component heading in the EM. Can it be an improvement?
Can it help to make the construction of a model easier to understand, easier
to edit? Similar to procedures and modules in a program code?




When experimenting with the component "entity" I thought: this smaller tree
of only the contributing entities is good - less objects, all in one part of
the tree, thus more clearness, easier to understand, easier to adopt to
specific requests.
>
> 
So I agree with your proposal to list component entities only under its
component heading. I much agree with your idea to indicate the parents of
the component (display in red). I strongly suggest to make them inactive,
that is, selectable, but not further expandable. So the user has a clear
indication of their function - the link between the group of entities and
the main model body.
>
> When talking to users about components, it soon comes to the question: can I
show/hide them with a click? They have in mind a subset of the entities in
the component, the presentable or final entities. They consider the
component merely as an assembly of finished surfaces, that needs to be shown
or hidden.

RP - Yes, this development build will be available for for inspection very soon.
>
> If we look at a component as a separate entity, could it have (beside its
other properties) the property "Visible Entities"?  Then Show/ Hide could
refer to this list.

 
> So far for now. I do hope, this lines are of help to you and the MultiSurf
development team. Much progress.

With kind regards,

Reinhard