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 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.
There is a pattern to the GLOB_CUTPLANES_INFO returned values.
View down to...
The current story...
GCPI = FPCP View Offset - Object Home Offset
All additional stories below...
GCPI = 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.
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.
The object using it might be broken, I see nothing unexpected in the pure values of GLOB_CUTPLANES_INFO.
With show on all stories and Floorplan cutplane show up/down 2 stories this results in:
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
The following would seem to give the correct values relative to Project Zero?
gs_bottom_range_height = Symb_Pos_Z + GLOB_CUTPLANES_INFO
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.
Hopefully the following GLOB_CUTPLANES_INFO array definitions help expand on the GDL Manual for anyone else that is challenged by this subject:
 Cutplane Height = Cutting height from Current Story - Glob_Elevation
 Cutplane Top = Limit Offset + Sum of number of storey heights above including Home Story - Glob_ Elevation
 Cutplane Bottom = Limit Offset - Sum of storey heights below Home Storey - Glob_Elevation
 Absolute Limit = Project Zero + Limit Offset - Glob_Elevation
All values are relative to origin of object.
So here’s my reasoning on why I considered GLOB_CUTPLANES_INFO (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. 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 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 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 & .
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.
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.
Any chance of an "upgrade"? Perhaps a simple REQUEST ( "Floor Plan Cut Plane" ) to expose the current story settings?