MultiSurf & Rhino terminology, comparison & transitions??

Discussion in 'Software' started by DCockey, Apr 6, 2012.

  1. DCockey
    Joined: Oct 2009
    Posts: 5,229
    Likes: 634, Points: 113, Legacy Rep: 1485
    Location: Midcoast Maine

    DCockey Senior Member

    Did the problem with the Rhino geometry first manifest itself in WAMIT or other software?

    Two different issues.

    1) What you see which depends in large part on the refinement of the display mesh used to generate the shaded/rendered images. The display discretizes the surface using quadralateral panels with straight edges, and gaps can appear between these discretized straight edges.

    Note that in Rhino the display mesh has absolutely no impact on the geometry calculations.

    2) Accuracy of the geometry. A common place for this to be an issue is intersections of two surfaces. In general the intersection of two surfaces can, but not always, result in a mathematically more complex curve than the surfaces, and may not have an analytical form.

    Based on what I know Rhino and MultiSurf use different approaches to determining the curve. Rhino determines a parametric spline curve in x,y,z space which is "close enough" to the intersection, and "close enough" depends on the tolerance settings. In principal the curve can be determined to any desired level of accuracy by increasing the number of spans in the curve. In reality the precision of the computer arithmatic will impose limits. My understanding (perhaps incorrect) is that Rhino does iterate in determining the parametric curve.

    MultiSurf apparently determines a pair of parametric curves in the u,v spaces of each surface, and the coordinates of points on the curve in x,y,x space are then determined using the parametric curves in u,v space. I believe this by itself does not always provide an "exact" curve. The MultiSurf approach should be considerably more computationally intensive than the Rhino approach unless other approximations are used as described for the MultiSurf "fast" mode. The u,v space curves should be able to be determined to any desired level of accuracy by increasing the number of spans in the curve. In reality the precision of the computer arithmatic will impose limits.

    It is very easy to wrongly assume that apparent gaps due to the display mesh are problems with the geometry. I've done it numerous times myself.
     
  2. CWTeebs
    Joined: Apr 2011
    Posts: 232
    Likes: 15, Points: 0, Legacy Rep: 171
    Location: Maine

    CWTeebs AnomalyGenerator

    Hi Mr. Cockey,

    I never said it was manifest 'in WAMIT.' That's just where I got the explanation from.

    Also, I would not say that the appearance and underlying geometry representation are seperable, in fact, that may be the best way to explain the explanation I was given. To do raster graphics, no matter how complex the surface, at some level the surface is "evaluated" and broken down into digestible straight lines. The appearance of gaps is only possible if there has been no tolerance setting applied to that location on the surface. In the NURBs description it's possible to have tight tolerance settings at knot locations, but still be possible to "evaluate" the surface at field points other than those in which the tolerance was "applied." Note I'm well aware that the graphics pipeline is typically different from any given geometry engine, it's just a useful example and precursor to the actual explanation:

    The difference is that Multisurf's "accurate" mode eliminates the possibility of having a description of a surface that allows for the evaluation of the surface, *at any possible location*, by recursively calculating said error to minimize the residuals at *every* field point, not just where the basis functions are defined.

    To that end, the description posted earlier from the WAMIT manual is supported, as are Mr. Ad Hoc's initial replies.

    Informally, I was also told it's rather rare that MSurf's accurate mode is absolutely necessary, that most of the time modifying Rhino's tolerance settings should do the trick.

    Your next question likely will be to inquire as to what my geometry consists of that resulted in this condition, and my answer is twofold:

    1-) I can't strictly prove that Rhino could never work for my geometry, but the traditional steps I employed (changing tolerance settings) didn't yield results

    and

    2-) The geometry is legitimately complex to loft through, it's part of an oil containment system that transitions from a simple prismatic cross section to a transom that has asymmetric protrusions connected to a double notch articulation. It sort of looks like somebody did an aerospace engineering structural integrity test by shooting a cow out of an air cannon at a jacuzzi.

    You may be better serviced by contacting sales directly, although I hope this has been at least a somewhat fruitful discussion.

    CWTeebs
     
    2 people like this.
  3. DCockey
    Joined: Oct 2009
    Posts: 5,229
    Likes: 634, Points: 113, Legacy Rep: 1485
    Location: Midcoast Maine

    DCockey Senior Member

    I never claimed you did. Just asked a question out of curiosity. :)

    In Rhino at least the appearance and underlying geometry are separable. The surface is "evaluated" and broken down into digestible straight lines after the underlying geometry is calculated. The display mesh size and structure are independent of the underlying geometry mathematical structure and depend on the display mesh settings, not the tolerances used for the underlying geometry. Display mesh nodes in general do not coincide with "knots" etc.

    In Rhino it is entirely possible to have gaps in the display due to the discretization for display purposes which do not exist in the underlying geometry. The size of those apparent gaps is reduced as the display mesh is refined. Rhino calculates the underlying geometry, then determines the display mesh when needed. If the display mesh settings are changed the display mesh is updated without affecting the underlying geometry.

    Of course if there are gaps in the underlying geometry in Rhino they will be visible and will not be reduced by refinement of the display mesh.

    Other software may work differently.

    It's also possible to also apply the tolerance in between knot locations with a NURBS representation, which is my understanding of what Rhino does. From http://wiki.mcneel.com/rhino/faqtolerances :
    For example, the Intersect command creates a curve at the intersection of two surfaces. The curve is guaranteed to lie, within the absolute tolerance, on each of the two surfaces.
    Note that it's the curve, not just the "knots" ofthe curve, which are within the tolerance.

    Again, other software may work differently.

    I have no doubts that the description from the WAMIT manual, which is also in MultiSurf manuals, is an accurate description of how MultiSurf, but not Rhino, works.

    My understanding is that Rhino's standard (and only mode) is to iteratively solve for the curve/surface which falls within the tolerances along the entire curve / on the entire surface, not just at "knots" or similar.

    Other "NURBS" software may be different.

    I assume you also tried refining the display mesh settings in the Mesh sub-menu in DocumentProperties.

    If you changed the tolerance settings (not display mesh settings) in Rhino after creating the geometry there won't be any improvement. Rhino doesn't go back and recalculate existing underlying geometry when the tolerance settings are changed.

    Sounds like very interesting geometry. I've appreciated this discussion. It prompted me to learn more about how MultiSurf works. ;)

    I'm still interested in any comparisons anyone might have of the terminology MultiSurf (AeroHydro) and Rhino use to describe similar or the same features and geometry.
     
    Last edited: Apr 9, 2012
    1 person likes this.

  4. MikeJohns
    Joined: Aug 2004
    Posts: 3,192
    Likes: 208, Points: 63, Legacy Rep: 2054
    Location: Australia

    MikeJohns Senior Member


    An initial setting of units and tolerances is essential. Do it before you start the drawing. I'd be very interested too in supposed inaccuracies, It should be easy enough to demonstrate with say an ovoid ( egg shape). I suspect a lot of these comments come from attempting to exchange models between packages.

    There are many issues wrt accuracy. There is too much generalisation to say a numerical representation is accurate or inaccurate without any specific detail. Relative accuracy is the requirement not absolute accuracy.

    [Edit Added]
    Designers need to understand that accuracy of procedures such as intersects or projections of lines onto surfaces is determined by the tolerance.
    The numerical methods used by all these packages are subject to error regardless of the package, there will never be absolute accuracy unless you work symbolically.
    The accuracy of any geometry will be refined until the values are just within the set tolerance. If you are already working with a compromised imported surface exchanged from another package you cannot make the geometry more accurate. The same holds if you generated a surface with a coarse tolerance and expect an accurate projection by setting a fine tolerance later.
     
    1 person likes this.
Loading...
Forum posts represent the experience, opinion, and view of individual users. Boat Design Net does not necessarily endorse nor share the view of each individual post.
When making potentially dangerous or financial decisions, always employ and consult appropriate professionals. Your circumstances or experience may be different.