GLOB_CONTEXT and 3D Documents

[owen]

Does anyone know how 3D Documents work in relation to the GLOB-CONTEXT query?

Taken from the AC13 GDL Reference Guide:

"GLOB_CONTEXT context of appearance

1-library part editor, 2-floor plan, 3-3D view, 4-section/elevation, 5-settings dialog, 6-list, 7 - detail drawing, 8 - layout, 22 - editing feedback mode from the floor plan, 23 - editing feedback mode from a 3Dview, 24 - editing feedback mode from a section/elevation, 28 - editing feedback mode from a layout, 43 - generating as an operator from a 3D view, 44 - generating as an operator from a section/elevation, 46 - generating as an operator from a list"

My understanding of this is there is no dedicated context for 3D Documents .. so they should come under a general 3D View?

However this doesn't seem to be the case.

I have an IF GLOB_CONTEXT<>3 statement to hide 3D Lines in the 3D Window (which works) however when i create a 3D Document from that view I get the lines.

See attached image (3D Doc on left) - the 3D Lines representing the framing and spandrel behind the glass in curtain wall panels should not be visible (i have turned transparency of the glass off for clarity)

cheers,

owen

[owen]

Think I have answered my own question.

I tried an IF GLOB_CONTEXT=4 and the lines are visible .. so it seems the 3D Document is classed as a '4-Section/Elevation'.

Next question for GS .. why??

I think the name 3D Document makes it pretty clear to which of the '3-3D View' and '4-Section/Elevation' options it should relate.

[ztaskai]

Hi Owen,

That was decided on purpose. There is no way to add a new GLOB_CONTEXT value since there can be old GDL scripts out there which list all possible values (they know of) in IF statements. We'd ruin these scripts by adding a new value and this would break the ever-compatibility of GDL. So we had to find the best possible match in the existing options. Having the 3DD a documenting window, we chose section.

You can distinguish between section/elevation and 3DD, though. We introduced a new APPLICATION_QUERY into ArchiCAD:

n = APPLICATION_QUERY ("document_feature", "view_direction", type)

For more details look into Appendix B of Basic Library Documentation.

Regs,

[owen]

thanks for the pointer Zsolt

understand the reasoning behind the lack of a dedicated 3D Doc value in GLOB_CONTEXT .. although it does make you wonder at what point backward compatibility becomes a hindrance to progress. I think needing to upgrade a family of objects every few versions to take account of new and/or retired/adjusted commands is not an unreasonable expectation.

another topic but perhaps if we had a better object coding environment it (updating many objects) would not be such a chore (i'm guessing you guys at GS don't create and manage all your objects via the AC object editing interface?)

[Barry Kelly]

ztaskai wrote:
That was decided on purpose. There is no way to add a new GLOB_CONTEXT value since there can be old GDL scripts out there which list all possible values (they know of) in IF statements. We'd ruin these scripts by adding a new value and this would break the ever-compatibility of GDL. So we had to find the best possible match in the existing options.

That never stopped you guys before.
Back in version 12 GLOB_USER became useless in 3D scripts - worked fine up till then.

http://archicad-talk.graphisoft.com/viewtopic.php?p=147228&highlight=globuser#147228

And in nearly every version the WALL_SKINS_PARAMS has changed from 6 values in version 7 to 12 in version 8 then 13 in version 10, 14 in 11, 15 in 12 and now 16 in 13 and 14.
And the WALL_SKINS_NUMBER jumped from 8 to 127 in version 11.

I'm not saying this is a bad thing but like Owen says backwards compatibility can be a hindrance.

So long as we are told about the changes we can fix our scripts to suit.
I use the same parts regardless of the Archicad version and just script in -if GDL version is "x" then do this , if "y" do that and if "z" do something else.
Now I know what is happening it is easy to adjust my objects to work in any version.

Barry.

[ztaskai]

owen wrote:
another topic but perhaps if we had a better object coding environment it (updating many objects) would not be such a chore (i'm guessing you guys at GS don't create and manage all your objects via the AC object editing interface?)

You are right with both points.

First, the coding environment is remarkably outdated. On top of that, I can't even promise that it will get much better soon. At feature developments, the features serving more users keep winning... I just hope we can add some small patches for the most painful parts in the next few versions.

Second, we mostly work in XML format with commercial code/text editors and use LP_XMLConverter intensively. Naturally, we use the AC libpart editor for modeling-heavy job -- so we share the pain:)

Regs,

[ztaskai]

owen wrote:
... although it does make you wonder at what point backward compatibility becomes a hindrance to progress. I think needing to upgrade a family of objects every few versions to take account of new and/or retired/adjusted commands is not an unreasonable expectation.

Barry wrote:
I'm not saying this is a bad thing but like Owen says backwards compatibility can be a hindrance.
So long as we are told about the changes we can fix our scripts to suit.

I'm glad to hear actual user feedback on this matter. And I'm glad that you, library developers, don't feel bad about necessary updates. But I'm more concerned about end users. They don't understand GDL error messages and they might not even know where some objects came from. They just conclude that their libraries (they probably payed for) stop working in the new ArchiCAD version (they certainly payed for). ArchiCAD would have to provide a very sophisticated library migration process to even consider killing or changing old GDL features. At least these are my fears about compatibility...

Barry wrote:

ztaskai wrote:
... We'd ruin these scripts by adding a new value and this would break the ever-compatibility of GDL.

That never stopped you guys before. :shock:
Back in version 12 GLOB_USER became useless in 3D scripts - worked fine up till then.

That's a bit different issue for us than the rest of the compatibility issues. On the other side I can see that it's pretty much the same for you. The thing is that in multithreaded 3D (and 2D) generation there is no efficient way for synchronizing the generation of different objects. This reason reaches far beyond GDL. The lesson of the story for me is that Graphisoft failed to communicate the supported usage of user globals (which is passing values between macro callers and called macros) and there was no way for you to know about the whole issue. Until your objects stopped working... That's exactly the kind of situation we want to avoid.

Barry wrote:
And in nearly every version the WALL_SKINS_PARAMS has changed from 6 values in version 7 to 12 in version 8 then 13 in version 10, 14 in 11, 15 in 12 and now 16 in 13 and 14.
And the WALL_SKINS_NUMBER jumped from 8 to 127 in version 11.

Neither of these changes affects any scripts incompatibly. Increasing the size of an array won't break scripts that refer to the lower indices. It's a good example though. When we optimized WALL_SKINS_PARAMS in AC14 so that it occupies the necessary size only, we payed extra attention to the fact that 8 rows always have to be filled as legacy scripts may refer to row 6 even when there are only 2 skins (assuming it's values to be 0). All in all, we are compatible with this one.

Best regards,