FPCP display of beams is incorrect - cut is offset

[Anonymous]

Hello,
I did an experiment using the column, beam, roof, and wall tools
and came up with something that is, to me, quite strange.
Please see attachment. Why does the beam tool show the
FPCP cut in a different location than in the other three tools ?
The thickness off all elements is the same, one foot.
Note that the displacement is exactly the difference between
the length of the hypotenuse and the length of the opposite side
of a right triangle drawn in the manner shown in the attachment.

I think that the cut is shown correctly for three of the tools but
is incorrect for the beam tool. If I am missing something
please let me know.
Thank you,
Peter Devlin

[Karl Ottenstein]

Hi Peter,

I just confirmed this behavior in 12!

I was hoping it was a bug in 10 that had been fixed.

With just a column and a beam, I see the results that you do in plan. To confirm that we are not crazy, I created a 3D cutting plane and viewed the cut model in 3D - and the cuts are in exactly the same location.

I made a 3D Document of the top view of the cut model (having locked the 3D cutting plane at 4' to match the floor plan cut plane). Attached screenshot with the 3D document as the trace reference shows that the beam cut is indeed wrong.

Are we missing something obvious? Or have untold numbers of construction documents been sent out around the world with incorrect information, especially if the cut was dimensioned...?!

I'll submit sample file/etc to GS if somebody doesn't correct us shortly...

Cheers,
Karl

[Anonymous]

Hello Karl,
Thank you for checking this out in v 12 and doing more
experiments than I did. I was thinking that I had not understood
something obvious. To me, unless someone can explain why this
is correct, this is a serious issue. As you say "untold numbers of
construction documents been sent out around the world with incorrect information".
It is also puzzling to me how this error could occur because it seems
to me it cannot be a programing error since this sort of thing would
be calculated in the underlying fundamental math of the program.
Besides, why would it be calculated differently for one out three tools.
Thanks,
Peter Devlin

[Thomas Holm]

Nice catch, Peter!
I think this happens because the 2D plan view is still largely 'symbolic'. The cutplane is better shown in 12 than previously, but still not a true 3D cut, which is obvious if you for example do some SEOs - they won't show in the floor plan.

I guess the cutplane in 2D plan isn't generated from the 3D view, but instead calculated by some math which may be different for various element types. You have found a bug in the beam 2D plan representation.

Of course this should be a high priority fix. But to get the best solution, a true 3D cut for all elements alike, I guess we'll have to wait for a new and faster 3D kernel.

[Anonymous]

I just now found out something else about the beam tool.
It is the only one of the four tools that does not have
hotspots at the corners of the FPCP cut rectangle making
measuring it's position accurately almost imposable.
I cannot help having the thought that because of this "omission"
maybe GS knows about this issue and purposely did not
place hotspots so the cut rectangle could not be measured.
If so, I can only assume they are intending to fix this and install
the hotspots after they have fixed the tool.
Peter Devlin

[Anonymous]

Hello Thomas,
You wrote:
"I guess the cutplane in 2D plan isn't generated from the 3D view,
but instead calculated by some math which may be different for various element types."
Why would the math be different for different elements ? The trigonometry
is exactly the same for the same shape cut at the same place.
You wrote:
"a true 3D cut for all elements alike, I guess we'll have to wait for a new and faster 3D kernel."
Again, the trigonometry is the same whether there is a 3D representation
or not. I can make a library part that has only a 2D script which accurately
calculates the shape and position of a 3D cut using trigonometry
even though there is no 3D script.
Or maybe I am misunderstanding what you are saying.
Thanks,
Peter Devlin

[Thomas Holm]

OK I'll rephrase: I think currently the shown cutplane figure in 2D plan views is calculated using routines optimized for each element type. Of course the underlying math should be the same, but this could explain why we see an error for all beams but not other element types.

Of course the trigonometry should be the same. I guess the issue currently is speed. To generate this figure as fast as possible for the plan view, shortcuts are used - that's why it's 'symbolic'. Shortcuts make errors possible, and even likely in some situations. We accept them sometimes. This case is not acceptable.

To always generate and show a true 3D cutplane for everything in plan like you presently can do in the 3D view, we'll either have to wait longer for each redraw, or get a speedier 3D kernel, I think.

But until then, this beam representation error must be fixed ASAP.

Did I make myself clear this time?

[Anonymous]

Absolutely Thomas.
You did make yourself clear this time.
I did not understand that you were
talking about the consequences of
optimization. I wonder what it is
about beams in this context that
makes them have to be optimized
differently.
Thanks,
Peter Devlin

[Karl Ottenstein]

Peter wrote:
I just now found out something else about the beam tool.
It is the only one of the four tools that does not have
hotspots at the corners of the FPCP cut rectangle making
measuring it's position accurately almost impossible.

Another good catch, Peter!

Looking at the attached screenshot, with column and beam selected, there is a consistency about the column that is lacking in the beam.

A placed column has 5 hotspots. So, it kind of makes sense that a tilted one would have 5 hotspots at the base, cut and top (of projection).

A level beam has 2 hotspots - the ends. So, for consistency, I would expect hotspots on the 'ends' of the cut as shown by the red arrows.


Re: Thomas' observation. I agree with his thoughts. 2D is still somewhat symbolic in spite of the cut plane functionality. The fact that the beam 'cut' has one edge where the center of the cut belongs suggests a small bug when they computed the offset for placing the cut shape.... Speculation of course. I experimented some more - and it seems that the cut is offset 1/2 of it's lengthwise length.

Cheers,
Karl

[Anonymous]

Hello Karl,
You wrote:
" The fact that the beam 'cut' has one edge
where the center of the cut belongs"
I noticed this in your other image to and assumed it
was a coincidence caused by your choice of angle
because if you notice in my image the edge in
question is not lined up with the center of the
cut in the other elements but displaced 4 31/32"
instead of exactly half which in my case would
offset the edge 8 31/64". What angle were you using ?
Thanks,
Peter Devlin