topic Re: 3D script error - pgon status in GDL

3D script error - pgon status

Richard Molnar — Fri, 25 Apr 2025 09:28:12 GMT

Hi All,

We recently switched from AC26 to AC28 and kept getting error messages in the Report window. We learnt that it was caused by the objects we created over the years in older versions, so we decided to resave the objects we are using. I thought that selecting the object's subtype or saving the raw model as a new object would solve the problem, but it did not.

For some unknown reason, AC28 finds an error in the 3D script. It is not an error that prevents it from creating the 3D model, but it annoys me regardless. Especially because this was not highlighted as an error in the previous (AC20-AC26) versions.

When a morph in the model turns into 3D scripts, the status number becomes big. Below you can find an example:

pgon 4, 136, 4098, ! #136 PolyId=0

-373, -374, -395, -394

material materialAttribute_3

At least that is the only thing that jumps out from the script's lines found as errors. I don't know the reason.

Is this a bug in AC28?
Any suggestions on how to fix this would be greatly appreciated.

I considered recreating the object using tools other than morph, but there are some parts of the object that are easier to make with morph tool.

Operating system used: Windows 10

Betreff: 3D script error - pgon status

runxel — Fri, 25 Apr 2025 14:44:41 GMT

I am not aware on any changes in AC28 here in this regard, but the status bit is indeed extraordinarily high.

If you save a Morph as an object in AC28, does this happen too?

Maybe it was a bug in former versions and only now the GDL interpreter has started to become a bit more tight in what it flags? 🤔

Also, can you share the exact error message?

Betreff: 3D script error - pgon status

Richard Molnar — Tue, 29 Apr 2025 21:54:02 GMT

Hi Runxel,

The original file was created in AC22, which I always reopened in the newer versions over the years. So I did the same and opened the file I was previously working on in AC26. The screenshot was made from an object created in AC28 from a morph. Strangely, not all morphs get this, but the more morphs are in an object's original form, the more of these are present in the 3D script. Couldn't find the reason why this is happening.

Regarding the error messages, this is from the Report window after opening an object in the 3D window:

Number of processor cores : 8 ---------------------------------------------------------------------- Document name : Object creator AC28 (28-03-2025) Processed : 0 walls 1 objects 0 columns 0 beams Start time : 29/04/2025 09:11:00 End time : 29/04/2025 09:11:00 Elapsed time : 0 seconds ---------------------------------------------------------------------- at line 5462 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 5690 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 5736 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 5908 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 5952 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 7062 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 8380 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 8542 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 8565 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 8763 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 8781 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 8994 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 9012 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 9225 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 9243 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 9464 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 9488 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 10718 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 10810 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) at line 11261 in the 3D script of file DRIVE UNIT V2.0.gsm. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2) There are several problems with this file. You can cancel the operation with Ctrl/Command - period. (MC_OPERATIVE | 2DD44C07-7743-40DD-9ACB-7493DE86D3A2)

And this is the error message that appears when running the Check script command in the 3D script window:

And the line from the script that the first error message referred to:
pgon 4, 136, 4098, ! #136 PolyId=0

Strange. Maybe it is to do with the file origin being from AC22?
When I have time, I will test this theory.

Re: 3D script error - pgon status

Piotr Dobrowolski — Fri, 23 May 2025 08:00:50 GMT

Sometimes it may come from the incompatibility between the pgon and normals...(good in 1:1- but not good when streched for example)

it may be corrected by changing every second parameter of pgon to "0":

pgon 4, 0, 4098, ! #136 PolyId=0

-373, -374, -395, -394

and then after the all pgons:

body -1

normals are not needed in such case BTW and they will be calculated

When I do the objects out of the morph, I always do that with also clearing up the coords of vertices to 0.000X for speed optimization.

Re: 3D script error - pgon status

Richard Molnar — Mon, 26 May 2025 09:09:01 GMT

Dear Piotr,

Thank you for the advice. What worked for me was to change the very high number by matching it with the previous pgon's (usually the number is 2).

After this change, there were no errors, and the model looked as it should. I will know in the long run if this was a solution, but for the moment, it works. I just hoped that there would be a simpler solution that required less work. 😊🖖

Re: 3D script error - pgon status

Piotr Dobrowolski — Mon, 26 May 2025 14:10:28 GMT

How to the pgon vect number edit the easy way:

1.copy the pgons section to the proper programmers editor (sublime or vs code) - or try to do it in monaco inside AC

2.search for "pgon" and find all

3.in sublime: hold ctrl and click right arrow twice...

4.Backspace as many characters to delete the highest number o pgon

5.type "0"

6. delete vect section

7.add "body -1" after pgon section

Re: 3D script error - pgon status

ArchiTecht — Fri, 30 May 2025 18:13:19 GMT

I am having this same exact issue. It seems to happen whenever ArchiCad auto-scripts the pgon command with the 4,000 status code. It still does thin with objects generated in 28. Not sure why this generates an error, but would like to know what best to replace the error-inducing status code with.

Heather

AC 28

Windows 10

Re: 3D script error - pgon status

ArchiTecht — Fri, 30 May 2025 18:34:02 GMT

Hi Piotr, I would like to better understand how to clean up objects generated from morphs. Could you explain what normals are and why they are not needed? Where exactly are we meant to add "body-1" in to the pgon script?

Appreciate your help,

Heather

AC 28

Windows 10

Re: 3D script error - pgon status

Piotr Dobrowolski — Mon, 02 Jun 2025 17:22:56 GMT

Ok here goes the explanation:

the original 3d script just placed a cube morph - I removed the unneeded groups and translation of the origin:

vert{2} 0, -2.964210218823, 0, 1 ! #1 VertId=0 vert{2} 0, -2.964210218823, 1, 1 ! #2 VertId=0 vert{2} 0, 0, 0, 1 ! #3 VertId=0 vert{2} 0, 0, 1, 1 ! #4 VertId=0 vert{2} 2.207390588485, -2.964210218823, 0, 1 ! #5 VertId=0 vert{2} 2.207390588485, -2.964210218823, 1, 1 ! #6 VertId=0 vert{2} 2.207390588485, 0, 0, 1 ! #7 VertId=0 vert{2} 2.207390588485, 0, 1, 1 ! #8 VertId=0 pen penAttribute_1 edge 1, 3, 1, 2, 262144 ! #1 EdgeId=0 edge 1, 2, 2, 6, 262144 ! #2 EdgeId=0 edge 3, 4, 2, 5, 262144 ! #3 EdgeId=0 edge 5, 1, 1, 6, 262144 ! #4 EdgeId=0 edge 2, 6, 3, 6, 262144 ! #5 EdgeId=0 edge 3, 7, 1, 5, 262144 ! #6 EdgeId=0 edge 7, 5, 1, 4, 262144 ! #7 EdgeId=0 edge 5, 6, 4, 6, 262144 ! #8 EdgeId=0 edge 4, 2, 2, 3, 262144 ! #9 EdgeId=0 edge 6, 8, 3, 4, 262144 ! #10 EdgeId=0 edge 7, 8, 4, 5, 262144 ! #11 EdgeId=0 edge 8, 4, 3, 5, 262144 ! #12 EdgeId=0 vect 0, 0, -1 ! #1 vect -1, 0, 0 ! #2 vect 0, 0, 1 ! #3 vect 1, 0, 0 ! #4 vect 0, 1, 0 ! #5 vect 0, -1, 0 ! #6 material bms_buildingMatAttribute_1 pgon 4, 1, 2, ! #1 PolyId=0 1, 6, 7, 4 material bms_buildingMatAttribute_1 pgon 4, 2, 2, ! #2 PolyId=0 -1, 2, -9, -3 material bms_buildingMatAttribute_1 pgon 4, 3, 2, ! #3 PolyId=0 5, 10, 12, 9 material bms_buildingMatAttribute_1 pgon 4, 4, 2, ! #4 PolyId=0 -7, 11, -10, -8 material bms_buildingMatAttribute_1 pgon 4, 5, 2, ! #5 PolyId=0 3, -12, -11, -6 material bms_buildingMatAttribute_1 pgon 4, 6, 2, ! #6 PolyId=0 -2, -4, 8, -5 material bms_buildingMatAttribute_1 coor{3} 2, 0, -1.161344805609, -15.35081837882, 0, -0.1613448056087, -15.35081837882, 0, -1.161344805609, -14.35081837882, 0, -1.161344805609, -15.35081837882, 1 body 262179 material 0 body -1

now You can cleanup this by removing the vect section: if all the pgon commands second parameter is "0", and there is a body -1 command which in most cases is always there in saved morphs. I also clean up the coords in vert commands so the are no more decimals than 4 ( accuracy to 0.1mm). I also remove the material commands as in most cases it will be one color of the whole element, same for pen commands. In most cases I remove coor unless the bitmap mapping is important (it can be scripted later).

So the cleaned code goes like this:

vert{2} 0.0000, -2.9642, 0.0000, 1  !   #1   VertId=0
vert{2} 0.0000, -2.9642, 1.0000, 1  !   #2   VertId=0
vert{2} 0.0000, 0.0000, 0.0000, 1   !   #3   VertId=0
vert{2} 0.0000, 0.0000, 1.0000, 1   !   #4   VertId=0
vert{2} 2.2074, -2.9642, 0.0000, 1  !   #5   VertId=0
vert{2} 2.2074, -2.9642, 1.0000, 1  !   #6   VertId=0
vert{2} 2.2074, 0.0000, 0.0000, 1   !   #7   VertId=0
vert{2} 2.2074, 0.0000, 1.0000, 1   !   #8   VertId=0
edge       1,    3,    1,    2, 262144          !   #1   EdgeId=0
edge       1,    2,    2,    6, 262144          !   #2   EdgeId=0
edge       3,    4,    2,    5, 262144          !   #3   EdgeId=0
edge       5,    1,    1,    6, 262144          !   #4   EdgeId=0
edge       2,    6,    3,    6, 262144          !   #5   EdgeId=0
edge       3,    7,    1,    5, 262144          !   #6   EdgeId=0
edge       7,    5,    1,    4, 262144          !   #7   EdgeId=0
edge       5,    6,    4,    6, 262144          !   #8   EdgeId=0
edge       4,    2,    2,    3, 262144          !   #9   EdgeId=0
edge       6,    8,    3,    4, 262144          !   #10  EdgeId=0
edge       7,    8,    4,    5, 262144          !   #11  EdgeId=0
edge       8,    4,    3,    5, 262144          !   #12  EdgeId=0
pgon       4,    0,      2,                 !   #1   PolyId=0
           1,          6,          7,          4
pgon       4,    0,      2,                 !   #2   PolyId=0
          -1,          2,         -9,         -3
pgon       4,    0,      2,                 !   #3   PolyId=0
           5,         10,         12,          9
pgon       4,    0,      2,                 !   #4   PolyId=0
          -7,         11,        -10,         -8
pgon       4,    0,      2,                 !   #5   PolyId=0
           3,        -12,        -11,         -6
pgon       4,    0,      2,                 !   #6   PolyId=0
          -2,         -4,          8,         -5
    body    -1

🙂