Archicad C++ API
About Archicad add-on development using the C++ API.
SOLVED!

Misleading info from ModelerAPI::Model::GetElementCount(). Possible bug.

Anonymous
Not applicable
While parsing the scene, I'm getting misleading info from
ModelerAPI::Model::GetElementCount()
about element count in the scene.

If there is 1 column in the scene, I get info there are 2 elements in the scene ColumnElement and ColumnSegmentElement.

It makes no sense to me. It's intended?

Should I bypass the newly added enums in order to parse the geometry correctly? Are those just some helpers?
Thanks for the reply.
A.
1 ACCEPTED SOLUTION

Accepted Solutions
Solution
Anonymous
Not applicable
@Ralph: Parsing scene geometry. The final step of this process is decomposing polygons into a set of convex polygons and converting them to triangles.
To start the building process we need num of elements in the scene. For AC <=22 it was ok, because ModelerAPI::Model::GetElementCount() was returning relevant number => 1 column = 1 element.
In AC 23 however, we can rely on this num no longer.
My first approach was to select which enum values are relevant but it was the wrong way. Then my next idea was to obtain num of GetMeshBodyCount() or GetTessellatedBodyCount(). But it was also wrong because for example, ColumnElement was returning it has a Body, but the body had no polys.

My recent working solution is to get to go one step deeper meaning I'm looking if mesh body has polygons MeshBody::GetPolygonCount() -> if yes -> it's ok to build...

View solution in original post

7 REPLIES 7
Laszlo Nagy
Community Admin
Community Admin
I am not a developer, so I won't be able to answer coding questions.
However, since ARCHICAD 23, Columns and Beam may be composed of Segments.
So I believe ColumnElement will return the total number of Columns, while ColumnSegmentElement will return the total number of Segments within all those Columns.
This probably also means that ColumnSegmentElement is always equal to or greater than ColumnElement since there is always at least 1 Segment in 1 Column.

Example: You have 1 Column with 1 Segment in it, 1 Column with 2 Segments in it, and 1 Column with 3 Segments in it. In this case ColumnElement should be 3, while ColumnSegmentElement should be 6.

I hope if I write totally wrong things here, a developer will correct me when they read this.
Loving Archicad since 1995 - Find Archicad Tips at x.com/laszlonagy
AMD Ryzen9 5900X CPU, 64 GB RAM 3600 MHz, Nvidia GTX 1060 6GB, 500 GB NVMe SSD
2x28" (2560x1440), Windows 10 PRO ENG, Ac20-Ac27
Ralph Wessel
Mentor
Laszlo is correct. Beams and columns are now assemblies like the curtain wall or stair elements. An assembly is comprised of a parent element and any number of child component elements ("segments" for beams and columns). When you migrate a column or beam element from AC22 to AC23, it becomes 2 elements: a parent and 1 child segment.

This presents a number of complications for developers and users, particularly when there is an important distinction between the the assembly as a whole or a component in the assembly. Consider a modeless palette that interacts with selected elements. Typically the user can only select the parent assembly - but what if the user wants to interact with one of the child elements? Assemblies support an "edit" mode, where the individual parts can be selected an interacted with, but only for a single assembly. And worse, if a beam/column has only a single segment (which is typically the case) you can't enter 'edit' mode at all, and therefore it is impossible to engage with the segment through a modeless palette.

The problem is compounded by the fact that the parent and child elements have separate meta-data, e.g. ID, classification, properties etc. A beam/column migrated from AC22 to AC23 migrates the meta-data into the parent assembly but not into the child segment. So, for example, if you have a database coupling records on the basis of ID and extracting data related to materials or surfaces, this completely breaks down because the child segments with the required data haven't inherited the meta-data values of the parent. And there is no easy way for the user to inspect this because modeless interaction with the child segment isn't possible. We could work around this by assuming the selection means the child, but this will break in future if they start creating multi-segment beams/columns.

This is causing a headache for some of our largest customer and we're still working with them to devise an appropriate response. I hope your requirements prove to be much simpler!
Ralph Wessel BArch
Anonymous
Not applicable
Thank you for your response, Laszlo, Ralph. It makes sense from the user perspective, however, I somehow feel there is something wrong 'under the hood' and this code will be refactored in some way sooner or later. Looks like Ralph can confirm. Luckily, it's not a big issue for us, we just bypass the newly added elements as they seem are having no geometry representation in the scene so we can't parse them.
Anonymous
Not applicable
Sorry, I was wrong. The ColumnElement is the one that has no geom. info, not the ColumnSegmentElement
Anonymous
Not applicable
And digging deeper, it's still not so straightforward...From the geometry parsing perspective, DoorElement is ok but WindowElement is not.
Ralph Wessel
Mentor
What process are you aiming to implement?
Ralph Wessel BArch
Solution
Anonymous
Not applicable
@Ralph: Parsing scene geometry. The final step of this process is decomposing polygons into a set of convex polygons and converting them to triangles.
To start the building process we need num of elements in the scene. For AC <=22 it was ok, because ModelerAPI::Model::GetElementCount() was returning relevant number => 1 column = 1 element.
In AC 23 however, we can rely on this num no longer.
My first approach was to select which enum values are relevant but it was the wrong way. Then my next idea was to obtain num of GetMeshBodyCount() or GetTessellatedBodyCount(). But it was also wrong because for example, ColumnElement was returning it has a Body, but the body had no polys.

My recent working solution is to get to go one step deeper meaning I'm looking if mesh body has polygons MeshBody::GetPolygonCount() -> if yes -> it's ok to build...

Didn't find the answer?

Check other topics in this Forum

Back to Forum

Read the latest accepted solutions!

Accepted Solutions

Start a new conversation!