• 2-D / 3-D representation

    From GianLuigi Piacentini@21:1/5 to All on Sun Nov 7 12:51:48 2021
    Dear Fortraneers,

    I'am writing a geometry package somewhat oriented to CAD-CAM. It's a
    pet project, rewriting and hopefully extending what I did for work
    (sheet metal) some 30 years ago (in C, because C was on the "cool" side
    those days - and I do not have the sources).
    The point is that in surface/solid modeling 3-D is a must, whereas for
    sheet metal 2-D is all what is needed. So I started writing some code
    around separate types for 2d and 3d, say
    type Point_2d
    real :: x, y
    ..
    and
    type Point_3d
    real :: x, y, z
    ..
    Then, there are rational point (real :: x, y, w and real :: x, y, z, w)

    Now, I'm realizing I'm writing a lot of repetitive code for the 2
    separate types (or 4 when including rationals) - that should be tested, too.
    I would like to avoid this. Goal is to keep expressivity minimizing code.

    Other possibilities
    type, extends(Point_2d) :: Point_3d
    real z
    and similar extensions for 2d and 3d rationals
    or
    type Point
    real x, y, z with z always present, and may be set to a guard
    value, say zero, to warn that it's 2-d
    or
    type Point
    real :: coordinates(3) ! 1 is x, 2 is y 3 is z set to zero to mark 2d
    or
    type Point
    real, allocatable :: coordinates(:)
    with size(coordinates) discriminating between 2d and 3d (but what
    happens when there are 2d rationals and 3d "normal" - size is always 3)

    Mantyla in its text on solid modeling simply uses a dimension(4) array
    for vector/point coordinates.
    Piegl et al in their NURBS book use always 3d rationals with guard
    values to discriminate 2d and non-rational case.
    De Boor in its B-spline package stores curve control points in arrays,
    one for each coordinate, and similar approach is in the code
    accompanying the Farin's book.

    May be there are many other possibilities I do not see at this moment.

    Do you have suggestions in order to minimize code repetition ?

    Thanks in advance
    Gigi

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arjen Markus@21:1/5 to GianLuigi Piacentini on Sun Nov 7 04:38:46 2021
    On Sunday, November 7, 2021 at 12:51:51 PM UTC+1, GianLuigi Piacentini wrote:
    Dear Fortraneers,

    I'am writing a geometry package somewhat oriented to CAD-CAM. It's a
    pet project, rewriting and hopefully extending what I did for work
    (sheet metal) some 30 years ago (in C, because C was on the "cool" side those days - and I do not have the sources).
    The point is that in surface/solid modeling 3-D is a must, whereas for
    sheet metal 2-D is all what is needed. So I started writing some code
    around separate types for 2d and 3d, say
    type Point_2d
    real :: x, y
    ..
    and
    type Point_3d
    real :: x, y, z
    ..
    Then, there are rational point (real :: x, y, w and real :: x, y, z, w)

    Now, I'm realizing I'm writing a lot of repetitive code for the 2
    separate types (or 4 when including rationals) - that should be tested, too. I would like to avoid this. Goal is to keep expressivity minimizing code.

    Other possibilities
    type, extends(Point_2d) :: Point_3d
    real z
    and similar extensions for 2d and 3d rationals
    or
    type Point
    real x, y, z with z always present, and may be set to a guard
    value, say zero, to warn that it's 2-d
    or
    type Point
    real :: coordinates(3) ! 1 is x, 2 is y 3 is z set to zero to mark 2d
    or
    type Point
    real, allocatable :: coordinates(:)
    with size(coordinates) discriminating between 2d and 3d (but what
    happens when there are 2d rationals and 3d "normal" - size is always 3)

    Mantyla in its text on solid modeling simply uses a dimension(4) array
    for vector/point coordinates.
    Piegl et al in their NURBS book use always 3d rationals with guard
    values to discriminate 2d and non-rational case.
    De Boor in its B-spline package stores curve control points in arrays,
    one for each coordinate, and similar approach is in the code
    accompanying the Farin's book.

    May be there are many other possibilities I do not see at this moment.

    Do you have suggestions in order to minimize code repetition ?

    Thanks in advance
    Gigi
    Instead of a component coordinates(3) or an allocatable component, you may consider to use parametrised types. Then a len parameter can set the dimension.

    Alternatively, a four-dimensional space is often used to turn affine operations (rotation, reflection, translation) into a matrix operation. The fourth coordinate is set to 1, so that it plays a role in the translation part. For 2D applications you could
    set the third coordinate to 1 as well and let the entries in the transformation matrix follow an analoguous pattern.

    Just a few suggestions, mind you.

    Regards,

    Arjen

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From GianLuigi Piacentini@21:1/5 to Arjen Markus on Mon Nov 8 11:14:58 2021
    On 07/11/21 13:38, Arjen Markus wrote:
    On Sunday, November 7, 2021 at 12:51:51 PM UTC+1, GianLuigi Piacentini wrote:
    Dear Fortraneers,

    I'am writing a geometry package somewhat oriented to CAD-CAM. It's a
    pet project, rewriting and hopefully extending what I did for work
    (sheet metal) some 30 years ago (in C, because C was on the "cool" side
    those days - and I do not have the sources).
    The point is that in surface/solid modeling 3-D is a must, whereas for
    sheet metal 2-D is all what is needed. So I started writing some code
    around separate types for 2d and 3d, say
    type Point_2d
    real :: x, y
    ..
    and
    type Point_3d
    real :: x, y, z
    ..
    Then, there are rational point (real :: x, y, w and real :: x, y, z, w)

    Now, I'm realizing I'm writing a lot of repetitive code for the 2
    separate types (or 4 when including rationals) - that should be tested, too. >> I would like to avoid this. Goal is to keep expressivity minimizing code.

    ...
    Instead of a component coordinates(3) or an allocatable component, you may consider to use parametrised types. Then a len parameter can set the dimension.
    Could you please elaborate more on this subject ?
    My objective is to write and test less code is possible (so for example,
    write (and test) a single procedure instead of, may be "project_2d_point_onto_2d_line", and "project_3d_point_onto_3d_line").


    Alternatively, a four-dimensional space is often used to turn affine operations (rotation, reflection, translation) into a matrix operation. The fourth coordinate is set to 1, so that it plays a role in the translation part. For 2D applications you
    could set the third coordinate to 1 as well and let the entries in the transformation matrix follow an analoguous pattern.
    This "trick" is reported in any book on the subject, and is what I
    internally did when transforming entities.

    Just a few suggestions, mind you.

    Regards,

    Arjen

    Thanks
    Gigi

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)