The Global Archicad Community

Stay informed. Get help. Share your knowledge.

Topics specific to the scripting and development of Library Parts and Libraries using Param-O or the Geometric Description Language – GDL. (Example: How do you use “REQUEST” GDL commands?)

Moderators: ejrolon, Barry Kelly, Karl Ottenstein, LaszloNagy, Gordana Radonic, nbalogh, gkmethy, mnguyen, rmasaki, Akos Somorjai, Peter Baksa, Csilla Mai

User avatar
By LaszloNagy
#318817
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.)

TUBE.png
TUBE.png (43.83 KiB) Viewed 425 times

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.
User avatar
By Braza
#318831
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.
User avatar
By Moonlight
#318838
@lazlo

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

:idea: :idea: :idea: :idea: :idea: :idea: :idea: :idea: :idea:

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 ????
User avatar
By Moonlight
#318842
@lazlo

In the context of your explanation for the "Tube" function ... How was the need to create Gravity Object related to your explanation ?
User avatar
By LaszloNagy
#318905
Moonlight wrote: Wed Nov 11, 2020 11:08 am
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.
User avatar
By LaszloNagy
#318906
Moonlight wrote: Wed Nov 11, 2020 1:30 pm @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?
User avatar
By LaszloNagy
#318908
Braza wrote: Wed Nov 11, 2020 10:33 am 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.
User avatar
By Moonlight
#318929
LaszloNagy wrote: Thu Nov 12, 2020 8:08 pm
Moonlight wrote: Wed Nov 11, 2020 1:30 pm @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.

User avatar
By Peter Baksa
#319058
Moonlight wrote: Fri Nov 13, 2020 11:18 am
Moonlight wrote: Wed Nov 11, 2020 1:30 pm
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).
User avatar
By Peter Baksa
#319059
LaszloNagy wrote: Wed Nov 11, 2020 7:55 am 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.
  • 1
  • 4
  • 5
  • 6
  • 7
  • 8