The Global ARCHICAD Community

Stay informed. Get help. Share your knowledge.

Everything about GDL - Doors/Windows/Objects/Stairs etc. (Example: I created an object that prints an error message in 3D all the time, please help!)

Moderators: Barry Kelly, Karl Ottenstein, LaszloNagy, ejrolon, gkmethy, Gergely Feher

Improve Xform by adding support for parameters/variable arrays

Yes, absolutely.
1
100%
Meh!!
No votes
0%
Nop.
No votes
0%
#302663
Hi there,

I would like to suggest that Xform should undergo an improvement by adding support for input parameters/variable arrays, just like other GDL functions such as values{2}

Xform:
Is a 3D transformation matrix stack that with it you can move, rotate, scale, shear, tilt any object all at the same time.
It's syntax is as follows (see GDL Guide):
XFORM newx_x, newy_x, newz_x, offset_x,
newx_y, newy_y, newz_y, offset_y,
newx_z, newy_z, newz_z, offset_z

And as you can see it needs 12 parameters/variable inputs and that is a lot

But if you specify for instance
Xform{2} paramArray

were paramArray can have the full stack then you only need it once, and with Compatibility of localized libraries the possibilities of improving GDL object parametricity will increase substantially
#302674
@Piotr

I know that trick, and the other one using parameter buffer, but try to follow my logic.

Any GDL object is already loaded to the memory will all it's data (including parameters), so why I have to load a second time the same values and data in memory just to make xform funtions, KNOWNING that their is some GDL functions such as values{2} that accepts array variables and parameters !!!

By the way, did you read the section of the link that I have posted ???
#302715
There are "problems" with discussing the obvious...
I am of course PRO...

I remember discussion regarding the commands related with NURBS...when the answer was that those commands were not supposed to be "human operated" ;P... I think the answer regarding Xform would be the same... :(

Piotr

PS I do not use xform much, I rather split the tranformations - becuase it is way easier to find what is not working...(either code...or the commands like some do not after mul*)
#302735
@Piotr

Well to be honest, I understand why Nurbs are not supposed to be human operated, since that the amount of settings that any GDL scriptor is quiet high in comparison to that of the rest of GDL functions, but I understand your point of view and I totally support it, besides I have never doubted you being a pro.

Splitting the transformations into various steps is cool, but their were cases that I have seen that using xform was much better, but I managed to harness that beast to a great extense point.

Anyway, I believe that GDL for what it was intended to be, and what it can project in the future have good future, and that's why I'm calling for improvements ... just like the thread I once created asking for improvements to the GDL Reference manual, you basically you will see the same issues repeated by many people in the past years.