things that are broken in AC23

[SenecaDesignLLC]

linking railing to roof nodes by association removes posts. this is so stupid
columns only show center node if that is selected as the structural point.

how the H*ll do they mess up the basic things that should not be changed??? Im so un impressed with this version. they are luck there isnt something better yet. there will be if they dont pull their heads out of ......

really they should give us all our money back for this release. this is BS

oh and its by far slower than v22. which ive now reverted back too

step it up graphisoft you set expectations now meet them.

modumate is coming for you. they basically have me at this point. pending pricing and if i can unload these licenses im stuck with.

[Ghaleb Khadra]

Dear All,

Thank you for your responses on the Interface text issue and for providing the Graphics Card being used.

Thanks to that information, we could find out what the cause is.

Unfortunately, this issue is not from ARCHICAD's side. We say unfortunately, because if it was from ARCHICAD's side, then we could address it directly. However, the reason behind this behaviour is twofold:

a. Apple is discontinuing support for OpenGL on macOS .
b. AMD Graphics Card's drivers struggle with OpenGL.

The above 2 issues are exacerbating each other unluckily. However, AMD is working on this continuously and hopefully with each update, they address compatibility issues with OpenGL more and more.

This is affecting some users who are on Mac and using AMD Graphics Card because OpenGL is used in ARCHICAD heavily as some of you know, even on the interface level.
This does not mean GRAPHISOFT is doing nothing about it. We are working on transitioning to Metal, OpenGL's replacement for macOS in the future.

We completely understand that this is a major inconvenience, and there is a possible workaround to avoid this however, it comes at a small performance cost.

Disabling the 2D Drawing Hardware Acceleration option should make the issue subside, but the cost is navigation and display performance.
This option can be found under: Options -> Work Environment -> Advanced Redraw Options...
We sincerely hope we were able to at least bring some clarity into this topic.

Once more, we're very sorry for the inconveniences you are experiencing, but we are very thankful that you constantly keep posting these issues as it helps us greatly in improving and keeping this knowledge available to everyone!

Sincerest regards,
Ghaleb

[DGSketcher]

I just tried to do a wall analysis, opening, heights, areas etc. Several of the standard parameters available to the schedule are not being calculated and reporting zero values e.g. Number of holes, minimum heights etc. This was done with a single wall 2m long x 4.5m high containing a 1m x 1m Hole and trimmed by a roof pivoting from 2m up at 45 degrees. One wall is cropped W99C and the other trimmed W99T

Contrary to the information here... https://helpcenter.graphisoft.com/user-guide/65410/ the "Maximum height of the Wall" is reported based on "Trim to roof" but the Minimum is reported incorrectly for single skin walls and as zero for composite or complex walls. Why the requirement for cropping to get accurate values still exists in general parametric design baffles me!

The Gross volume & Gross surface areas of the trimmed wall are reporting incorrectly, apparently based on being trimmed at the upper face of the roof. The Net values are correct. I have checked and the top of the wall is trimmed to the roof soffit based on PBCs.

I would like to do basic take offs for my client but these results aren't reassuring.

[Ghaleb Khadra]

DGSketcher wrote:
I just tried to do a wall analysis, opening, heights, areas etc. Several of the standard parameters available to the schedule are not being calculated and reporting zero values e.g. Number of holes, minimum heights etc. This was done with a single wall 2m long x 4.5m high containing a 1m x 1m Hole and trimmed by a roof pivoting from 2m up at 45 degrees. One wall is cropped W99C and the other trimmed W99T

Contrary to the information here... https://helpcenter.graphisoft.com/user-guide/65410/ the "Maximum height of the Wall" is reported based on "Trim to roof" but the Minimum is reported incorrectly for single skin walls and as zero for composite or complex walls. Why the requirement for cropping to get accurate values still exists in general parametric design baffles me!

The Gross volume & Gross surface areas of the trimmed wall are reporting incorrectly, apparently based on being trimmed at the upper face of the roof. The Net values are correct. I have checked and the top of the wall is trimmed to the roof soffit based on PBCs.

I would like to do basic take offs for my client but these results aren't reassuring.

Greetings,

I am very sorry about the issue you are facing with the Schedules. I would love to help out and take a look at this issue if that's okay with you, and take proper action to address it.

However, to ensure that we are having the exact same conditions, I would kindly ask of you to send me - in a PM - the file itself where you face these issues in. I will conduct tests in-house and investigate this matter to the fullest extents in order to determine why this is happening!

I'm looking forward to hearing back from you.

Kind regards,
Ghaleb

[Ghaleb Khadra]

DGSketcher wrote:
I just tried to do a wall analysis, opening, heights, areas etc. Several of the standard parameters available to the schedule are not being calculated and reporting zero values e.g. Number of holes, minimum heights etc. This was done with a single wall 2m long x 4.5m high containing a 1m x 1m Hole and trimmed by a roof pivoting from 2m up at 45 degrees. One wall is cropped W99C and the other trimmed W99T

Contrary to the information here... https://helpcenter.graphisoft.com/user-guide/65410/ the "Maximum height of the Wall" is reported based on "Trim to roof" but the Minimum is reported incorrectly for single skin walls and as zero for composite or complex walls. Why the requirement for cropping to get accurate values still exists in general parametric design baffles me!

The Gross volume & Gross surface areas of the trimmed wall are reporting incorrectly, apparently based on being trimmed at the upper face of the roof. The Net values are correct. I have checked and the top of the wall is trimmed to the roof soffit based on PBCs.

I would like to do basic take offs for my client but these results aren't reassuring.

Hi again,

I have taken this issue to the development team and it turns out that the following are true:

1. The number of openings displaying 0 is not really a bug, because that specific Field within the Schedule refers to the Empty Openings (the Library GDL object under doors) and not to the openings created using the Opening Tool. If you wish to quantify the number of Openings created using the Opening Tool, then place use the Field "Number of Openings"
Nonetheless, I did try to place an Empty Opening in the wall, but it is still showing the quantity as 0 and that is indeed a bug. It was just a lucky catch, and for that, I sincerely thank you!

2. The Minimal Height issue was existing for a while, but that is not for a technical issue however, for a lack of a clear consensus on what should the minimal height really be. It turned out that many other users reported this to us however, every time the user understand or wishes the Minimal Height parameter something different. In this case, the Minimal Height showing on the Schedule is 1.5 m which is the height from the bottom of the Wall up until the bottom part of the Opening (window). That is what the schedule is showing because it is a lower value than the height of the wall at the end, which is 2 m. (1.5 < 2 and so ARCHICAD took this "1.5" value as the minimum height of the wall. I know if is confusing but, it's understandable that some users will disagree on this.

3. The values obtained incorrectly for the Gross and Net areas/volumes are technically correct, but the result is not correct because the Minimal Height value is incorrect. In other words, the algorithm and code runs correctly however, the extracted data from the Minimal Height parameter is causing the incorrect mathematical values.

Once we fix the Minimal Height issue, the others will consequently show the correct values. Furthermore, please allow me to point out that the main difference between Gross and Net is that the Gross values consider the element as whole. This means it excludes Openings, Doors, Windows, Recesses, Niches, Intersections... etc and the Net value is the result after including those other factors mentioned above.

I would appreciate it greatly if you were to share with me your opinion of what should the Minimal Height be defined as. Should it be the physical manifestation of the wall's geometry from the wall ends? Should it include/exclude Intersections? Should it be only what is visible of the element? When there is an Opening which makes the wall's minimum height theoretically lower than the wall end, which value should be considered?

I will share your opinion with the development team, so I would like to thank you in advance for your participation on this.

I added these issues into our database so that work on fixing them can start as soon as possible.
I'm eagerly awaiting your response.

Kind regards,
Ghaleb

[DGSketcher]

Hi Ghaleb, Thank you for the update it is appreciated.

With regards to the minimal wall height I was taking the simplistic view on a basic shape, in reality with the tools we now have available the wall could have a top of any profile. Personally I think the minimum height should be defined as the lowest point on the wall top profile above the base line but excluding vertical values which drop to the base line. This would allow a vertical step to be considered within the wall length but would exclude the wall ends unless the wall end tapered to zero e.g. anything less than 90 degrees. Anything equal to or greater than 90 degrees forming a concave (under) cut would be excluded. I would also exclude all openings in the assessment otherwise you will inevitably have door openings where the value could be zero. This is my humble opinion, no doubt others may have a more refined view...

[Anonymous]

openings should not be included in the Door & window schedules. So much wasted time editing out openings in the door & window schedules every time I open a new project can it be set up as default not to give it an ID?

[Eduardo Rolon]

Just add them as a condition in the Scheme

[Anonymous]

Ghaleb wrote:

This does not mean GRAPHISOFT is doing nothing about. We already began work on transitioning to Metal, OpenGL's replacement for macOS.

Hi Ghaleb,

Given that the next version of macos will not support opengl, is there any temporary forecast for that transition to metal? Will we see it in the next version of archicad 24?

Best regards

[Ghaleb Khadra]

Hi,

The current plan forecasts Metal to be available with ARCHICAD 24. As long as everything goes according to plan, we can expect it then hopefully

Thanks for your question by the way!

Kind regards,
Ghaleb

[Anonymous]

First it seemed all to be faster in AC23 but just starting and drawing in 2D in an empty project; now with a single-family house project and detailed planning it got very slow; I need to deliver plans and calculations ... this is a nightmare there must be a huge bug in the program as I use iMAC pro with highest configuration which is 128 GB Ram, Radeon Pro Vega 64 16GB VRAM

When there will be an update with resolving this issues? Or do we all need to wait one more year for AC24 to continue ?!? Should we go back to AC23?!? What is your suggestion?