GDL
About building parametric objects with GDL.

GDL: GLOB_CUTPLANES_INFO[3] broken

DGSketcher
Legend

I have been doubting my sanity for months on this one, but finally found solid evidence using a standard OOTB AC Rafter object that GLOB_CUTPLANES_INFO[3] is broken. In an object, when setting the Show Projection : To Floor Plan Range option, anything more than one story down using the projected view will result in the floor plan displaying less than the expected range. The attached PLN file shows the problem.

 

I appreciate we can use the Absolute value as a lower range workaround, but we should also be able to rely on the Show Down To option as a fundamental system setting.

 

@Peter Baksa 

Apple iMac Intel i9 / macOS Sonoma / AC27UKI (most recent builds.. if they work)
11 REPLIES 11
DGSketcher
Legend

There is a pattern to the GLOB_CUTPLANES_INFO[3] returned values.

 

View down to...

The current story...

GCPI[3] = FPCP View Offset - Object Home Offset 

 

All additional stories below...

GCPI[3] = FPCP View Offset - Object Home Offset - Height of Story below - #Story(s) below + 1 

 

It's going to be a complex piece of GDL to decode those values to a simple Z offset given there are two unknown variables from the FPCP settings.

 

Apple iMac Intel i9 / macOS Sonoma / AC27UKI (most recent builds.. if they work)
DGSketcher
Legend

And just to add to the confusion, if in the file above the lowest story (F1) is changed so all the story heights are the same, the problem goes away, but changing any of the project story values gives unexpected display results.

Apple iMac Intel i9 / macOS Sonoma / AC27UKI (most recent builds.. if they work)
Peter Baksa
Graphisoft
Graphisoft

The object using it might be broken, I see nothing unexpected in the pure values of GLOB_CUTPLANES_INFO.

 

text2 0, 0, "home story " + str(GLOB_HSTORY_ELEV, 3, 2)
text2 0,-1, "current story " + str(GLOB_CSTORY_ELEV, 3, 2)
text2 0,-2, "elevation " + str(GLOB_ELEVATION, 3, 2)
text2 0,-3, "cutplane height " + str(GLOB_CUTPLANES_INFO[1], 3, 2)
text2 0,-4, "cutplane top " + str(GLOB_CUTPLANES_INFO[2], 3, 2)
text2 0,-5, "cutplane bottom " + str(GLOB_CUTPLANES_INFO[3], 3, 2)
text2 0,-6, "absolute display limit " + str(GLOB_CUTPLANES_INFO[4], 3, 2)

 

With show on all stories and Floorplan cutplane show up/down 2 stories this results in:

PeterBaksa_0-1681888749105.png

 

Péter Baksa
Software Engineer, Library as a Platform
Graphisoft SE, Budapest

Hi Peter,

 

Thank you for engaging on this issue, I think I can now resolve my display problems.

 

Your post has clarified what I believe for me is the root of the issue. If Cutplanes Top or Bottom, reference stories that don’t exist then a default story height of 1m is applied for each story. 

 

The other aspect which I tried to flag up in my earlier post & pln is the code, which is taken from RoofMaker_macro.gsm, to establish Cutplane Bottom, but doesn’t seem to work with Bottom limits lower than Symb_Pos_Z and leads to an incomplete rafter display?

 

 

gs_bottom_range_height = GLOB_CSTORY_ELEV - GLOB_HSTORY_ELEV + GLOB_CUTPLANES_INFO[3] 

 

 

The following would seem to give the correct values relative to Project Zero?

 

gs_bottom_range_height = Symb_Pos_Z + GLOB_CUTPLANES_INFO[3] 

 

 

I don’t know if this would help but you may wish to consider applying story range checks to the FPCP limits to prevent reference to non-existent stories e.g. you shouldn’t be able to set the Top Limit to more than one story above the top story and a Bottom Limit lower than the lowest story. The use of an arbitrary 1m for unused stories can lead to unexplained display results. Is that a fair assessment?

 

Again, thank you for helping demystify the GCPI array.

 

Trevor

 

——————————————

 

Hopefully the following GLOB_CUTPLANES_INFO array definitions help expand on the GDL Manual for anyone else that is challenged by this subject:

 

[1] Cutplane Height = Cutting height from Current Story - Glob_Elevation

 

[2] Cutplane Top = Limit Offset + Sum of number of storey heights above including Home Story - Glob_ Elevation

 

[3] Cutplane Bottom = Limit Offset - Sum of storey heights below Home Storey  - Glob_Elevation

 

[4] Absolute Limit = Project Zero + Limit Offset - Glob_Elevation

 

All values are relative to origin of object.

Apple iMac Intel i9 / macOS Sonoma / AC27UKI (most recent builds.. if they work)
DGSketcher
Legend

@Peter Baksa 

So here’s my reasoning on why I considered GLOB_CUTPLANES_INFO[3] (GCPI) was/is broken. From one perspective it works exactly as designed, but from a perspective of anticipated values the results seem literally misplaced. 

 

The key point is the Floor Plan Cut Plane settings > Relative Floor Plan Range (RFPR) values when used with multi-story objects e.g. one that has its origin on one story but is viewed on another gives predictable but unexpected results with GCPI[3]. The user assumption is the RFPR values relate to the current story, in practice they are being determined from the Object origin.

 

As an example, setup a file containing three stories of 3m. If we place a rafter on the lowest (1st) story that spans the full height of the stories e.g. 9m, when the view point is one story up, +3m from the rafter origin, and the RFPR is set to one story down the resulting GCPI[3] value isn’t -3m e.g. the height of the story below the current story, it is -1m, which is a default height for an undefined story below the rafter origin. 

 

If we move to two stories up, +6m from the rafter origin, and the RFPR is set to two stories down the resulting GCPI[3] value isn’t -6m, it is -2m, which is the sum of the two default stories below the origin.  

 

A similar inverted situation occurs with the RFPR upper range limit.

 

All I am suggesting is it would be helpful in GDL to be able to read the current FPCP values or be provided with additional values that reflect the displacement from the current story to simplify correctly setting the clipping heights of a story sensitive object (like the rafter in my OP) when using irregular story heights. At present the upper & lower range values cannot be determined from the returned values of GCPI[2] & [3]. 

 

Whilst the idea of spanning a large number of stories may seem extreme, we are moving towards creating different floor zones according to discipline e.g. Structure, MEP, Finishes (blame Revit), so it is quite feasible to need to span four stories per level.

Apple iMac Intel i9 / macOS Sonoma / AC27UKI (most recent builds.. if they work)
Peter Baksa
Graphisoft
Graphisoft
REQUEST ("Story_info") gives information about existing stories, the extents of the building can be calculated with that and REQUEST ("Story").
 
Péter Baksa
Software Engineer, Library as a Platform
Graphisoft SE, Budapest
DGSketcher
Legend

@Peter Baksa Thank you. Agreed that is part of the answer to the problem, but it doesn't deliver a value for the fine tuning of the range "Offset" values available in the FPCP.

Apple iMac Intel i9 / macOS Sonoma / AC27UKI (most recent builds.. if they work)
Peter Baksa
Graphisoft
Graphisoft

The user assumption is the RFPR values relate to the current story, in practice they are being determined from the Object origin.

I see that can be an expectation. Objects work more like slabs than walls/beams in this context.

Yes, the currently available data is not enough to determine whether RFPR settings were given as offsets to current story or number of stories, so the behaviour of a beam can't be reproduced from GDL.

Péter Baksa
Software Engineer, Library as a Platform
Graphisoft SE, Budapest

Any chance of an "upgrade"? Perhaps a simple REQUEST ( "Floor Plan Cut Plane" ) to expose the current story settings?

Apple iMac Intel i9 / macOS Sonoma / AC27UKI (most recent builds.. if they work)