Questioning about manuals ?

[Nader Belal]

Where is the place that I can propose the editing for manuals ?

For instance, right now, when revising COOR, COOR{2}, COOR{3} GDL commands, there was no mentioning that the these take effect after defining a specific body.

[Laszlo Nagy]

I hope I remember correctly or understand the description and illustration correctly, so here is how I think it works:

The V axis direction at a given point of the space curve path is defined by the line going from the previous point to the given point. So you set the V axes by defining the various points of the space curve path. This is the reason why the start of the geometry is at Point 2 of the space curve path, and the V axis at the starting point is defined by Point 1 and Point 2 of the space curve path (as indicated by 1 and 2 in the illustration). So, for example, the V axis at Point 4 is defined by the line going from Point 3 (previous point of space curve path) to Point 4 of the space curve path.

Since the W axis is always pointing upwards (in other words, it is parallel with the local Z axis), the V and W axes together define a vertical plane. And the U axis is the normal of the vertical plane defined by the vertical V-W plane. The consequence of locking the W axis direction to the local Z axis (a decision made by the developers) is that specifying points of the space path will automatically also define the V-W-Z axes at each point of the space path and you don't have to specify them individually for each point. That may be useful to know.

Now, here is the tricky part, which is something it took me a while to understand and think with. The manual says:

The cross-section polygon of the tube measured at the middle of the path segments is always equal to the base polygon (u1, w1, ..., un, wn).

So, you have your path, and then GDL takes the middle point of each segment and extrudes the profile along that segment, so it has the defined profile size AT THE MIDDLE POINT of the segment. This is contrary to what I supposed and what others may suppose, which is that the profile is measured in the bisector planes of segments, which is not the case.
This also means that the GDL Guide contains a discrepancy between the description of the command and the illustration. The illustration shows those dashed lines at bisector planes at each space path point, which can make you think that the profiles are generated in the bisector planes, when in fact they are generated in the perpendicular plane in the middle points of segments. So the illustration should be updated to reflect that, in my opinion.
I have simplified the script of example 1 of the GDL Guide so it contains fewer segments, and the below illustration shows that the dimensioned segment's width is 2 meters in the middle of the segment and not in the bisector plane at the beginning of the segment (where it is greater). This thing is actually important only in segments that are at an angle to the previous segment. (When a segment continues in the same direction, the profile will be the same at the beginning of the segment and the middle of the segment.)


The other thing I noticed is that when I copy-pasted the GDL script of example 1 into the GDL Editor and checked the result, I found that the geometry extends "inward" from the space path, not outward as suggested by the positive direction of the U axis in the illustration. Again, the illustration shows that the space path of the ramp is 8 meters wide, so if the U axis were pointing outward, the total width of the ramp would have to be 12 meters. Since it is 8 meters wide, it means that the U axis is pointing in the opposite direction to what is shown in the illustration.

Yet another thing I think adds some more to the confusion is the naming of the axes of the profile planes. In texture mapping, U and V axes are the equivalents of the X and Y axes (hence the name, U-V Mapping.) However, in the case of the TUBE command, the U and W axes are the axes defining the profile plane, not U and V. In the TUBE command, the V axis is the equivalent of the Z axis of the X-Y-Z system. So, this is another inconsistency with how I think it is supposed to be, which makes the whole thing harder to understand, but I guess it will not be changed.

[Anonymous]

Thanks Laszlo for clarifying this Tube concept. It took me lots of neurons to understand that by trial and error.
I also got the conclusion that the first and the last node of the path can be comprehended as the previous and the next node if you want to to join tubes. I usually put editable hotspots at their location to get mitered joins between tube objects.
To extend this TUBE understanding, the difference between TUBE and TUBEA is that the last generate the profile at the bisector of the curve. For me, this is an useless GDL command, as it distorts the profile along the path.
But I truly understand that a "perfect" TUBE geometry is very very trick to achieve. If not impossible.

[Nader Belal]

@lazlo

That is why we get funny shapes in the corners of small radii of sharp turns ...



I think I have got it how the developers made that function, and now I think I somehow fully understand it.

And if what I think is true, they made a struck of genius.

Now a question ....

Tube have been a stable of GDL Reference Manual for a very long time, so why no body have updated it's literature with what you have just said ????

[Nader Belal]

@lazlo

In the context of your explanation for the "Tube" function ... How was the need to create Gravity Object related to your explanation ?

[Laszlo Nagy]

Moonlight wrote:

Now a question ....

Tube have been a stable of GDL Reference Manual for a very long time, so why no body have updated it's literature with what you have just said ????

I will inform them about this so they can update the Reference Guide.

[Laszlo Nagy]

Moonlight wrote:
@lazlo

In the context of your explanation for the "Tube" function ... How was the need to create Gravity Object related to your explanation?

I am afraid I do not follow. What is a Gravity object?

[Laszlo Nagy]

Braza wrote:
Thanks Laszlo for clarifying this Tube concept. It took me lots of neurons to understand that by trial and error.
I also got the conclusion that the first and the last node of the path can be comprehended as the previous and the next node if you want to to join tubes. I usually put editable hotspots at their location to get mitered joins between tube objects.
To extend this TUBE understanding, the difference between TUBE and TUBEA is that the last generate the profile at the bisector of the curve. For me, this is an useless GDL command, as it distorts the profile along the path.
But I truly understand that a "perfect" TUBE geometry is very very trick to achieve. If not impossible.

You are welcome.
Yes, it is a good idea to make those two additional nodes visible or editable in some way.

I think the other big difference between the TUBE and TUBEA commands is this:

The base polygon can be opened: in this case, the section polygons will be generated to reach the local x-y plane as in the case of REVOLVE surfaces.

This difference in behavior is what makes it possible to generate a geometry the section profile of which is not the same for every section. Just look at the TUBEA example in the GDL Reference Guide.
For example, you can create a road profile that is winding up and down, if you want. A bit like what you can achieve using Profile Parameters.

[Nader Belal]

LaszloNagy wrote:

Moonlight wrote:
@lazlo

In the context of your explanation for the "Tube" function ... How was the need to create Gravity Object related to your explanation?

I am afraid I do not follow. What is a Gravity object?

Sorry my bad, I meant "Gravity Tube"

Few years ago, I tried to make a parametric swimming pool ladder based on some norm or regulation ... and it happened that the side bars were made with "Tube" function, but by an unknown reason to me, the tube section started to turn around it's axe out of my control, as I have explain in this thread TUBE COMMAND PROBLEM to which I found some kind of similarity to what was commented in TUBE PROBLEMS

Side Note: This whole thread (almost all of it) is to update GDL Reference Manual.

[Peter Baksa]

Moonlight wrote:

Moonlight wrote:

In the context of your explanation for the "Tube" function ... How was the need to create Gravity Object related to your explanation?

Sorry my bad, I meant "Gravity Tube"

Few years ago, I tried to make a parametric swimming pool ladder based on some norm or regulation ... and it happened that the side bars were made with "Tube" function, but by an unknown reason to me, the tube section started to turn around it's axe out of my control, as I have explain in this thread TUBE COMMAND PROBLEM to which I found some kind of similarity to what was commented in TUBE PROBLEMS

gravity_tube was created to solve this uncontrollability issue. For vertical TUBE pieces VW isn't exactly defined, it could be any vertical plane. In this situation U is calculated from the W axis of the previous piece. This is very hard to follow if your space path is parametric. Therefore gravity_tube defines the U axis (origin of rotation) of the bisector planes with a vector (projecting the gravity vector onto the bisector plane).

[Peter Baksa]

LaszloNagy wrote:
Since the W axis is always pointing upwards (in other words, it is parallel with the local Z axis), the V and W axes together define a vertical plane. And the U axis is the normal of the vertical plane defined by the vertical V-W plane. The consequence of locking the W axis direction to the local Z axis (a decision made by the developers) is that specifying points of the space path will automatically also define the V-W-Z axes at each point of the space path and you don't have to specify them individually for each point. That may be useful to know.

Thank you for the explanation, a minor correction:
W isn't parallel with Z, it is perpendicular to V. Out of the many vectors that are perpendicular to V, W is the one whose z component is the largest. This means W points upwardsish, as if it could rotate freely around V, and had a helium baloon at its end. That's why for a vertical V this isn't an exact definition.