2024 Technology Preview Program:
Master powerful new features and shape the latest BIM-enabled innovations
2022-10-26
03:07 PM
- last edited on
2023-05-24
10:38 AM
by
Rubia Torres
Hi All,
Now in Archicad, most design and data are handled at the element level - assigning properties, using Graphic Overrides or setting renovation status are a few examples.
To express design intent and extract data at a more detailed level, the component or skin level requires further data and flexibility. We already visualise these skins, have Offset Modifiers for Profiles to create smart parametric extrusions, and Component/Surface Schedules to extract data.
We plan to further develop the component/skin level of elements and expand existing functionality in that area, so we are exploring more about what you need. Some questions:
As we progress in this area, your input will be invaluable to understand priorities and our direction moving forward. Thanks in advance.
2022-11-10 12:29 PM - edited 2022-11-10 12:31 PM
To sum this up in a simple description, I think we all would like to have:
1. extended modeling options within composite skins, their modifiers and profiles,
2. ability to assign data to individual composite and profile components,
3. ability to use assigned data for graphic display (renovation status, graphic overrides, etc.),
4. ability to access, structure and display all assigned data in schedules.
5. All this should be possible for horizontal, vertical and tilted zero-depth surfaces.
| Archicad 4.55 - 27
| HP Z840 | 2× E5-2643 v4 | 64 GB RAM | Quadro M5000 | Windows 10 Pro x64
| HP Z4 G4 | W-2245 | 64 GB RAM | RTX A4000 | Windows 11
2022-11-15 06:18 PM
A wish linked to the component question that can impact the modelling flexibility:
Actually, if you change a complex profile (of a wall for instance) , Archicad reset this profile (and modifiers) to the default value. It makes it difficult to change this complex profile in the project if the value are not the default one.
Can you give the possibility to change to a different complex profiles without losing our modifications (height, modifiers with the same name) ?
2022-11-28 06:18 PM - edited 2022-11-28 06:32 PM
Hi James, a few thoughts about renovation tools, composite skins and openings:
To me it would be very very useful to allow a composite skin to have a renovation status.
This way you can quickly add an insulation layer to an existing wall rather than creating a new wall, on a different layer with different layer number.. this tends to be complicated and creates conflicts.
Or quickly show that you are removing a ceiling (its skin being as downtaking the rest staying as existing) rather than drawing a slab and a ceiling, or adding a new floor to an existing slab.. I find that limiting the amount of elements drawn (sometime exactly the same on plan) is so useful.
It would seem to me a really good easy addition, those who prefer drawing several slabs on top of each other or several adjoining walls could still do it if they like it.
I'm not convinced of a workaround using complex profiles, although having the possibility to determine if an element in a complex profile is existing/to be demolished/new sounds like a good idea too.
Another thing concerning renovation tool is to make openings smarter with it.. if you put an existing opening as downtaking, then the "hole" disappears, (that's not like that in reality).
Then you need to battle with layer and priorities to show how you fill up the opening with new materials. You want to keep a smooth connection with the new filling though especially in elevation where you don't want to see the old opening line.. I guess if the external material was the same it shouldn't be a problem
2022-12-10 06:50 AM
Hello,
If it has not been said, it would help to be able to show a partial demolition of a wall composite such as removing the existing gypsum board or removing a facade's existing stucco. I don't know how complex this would be, but I have had many projects that require a partial demolition.
Thank you,
2023-11-30 03:22 PM
Thank you James for communicating with Graphisoft's users - most appreciated.
A wealth of excellent requests within this thread, some to a depth well beyond our use of ArchiCAD.
Having read through this whole thread in one go, it has me wondering whether there is still an argument for separate wall, floor, roof tools. Would there not be a programming & user benefit to have one tool that offers all the usability of each of these separate 'use cases', especially since building design is moving evermore in the direction of parametric input? Across the breadth of ArchiCAD's tools at least one will have a control element which is desirable in others: Tapered beams...apply programming to enable tapered slabs; 3D hot spot, spline, or edge manipulation of meshes...apply to walls to control edge profiles without SEO (sides, top, bottom); Morph manipulation...in all its flexibility...applied to either whole elements or selected components within a composite complex item; and so on...
It seems that each tool has limitations that have been overcome elsewhere within ArchiCAD, but one cannot use that other tool because it in turn lacks some of the functionality of the first tool...e.g.: roof tool cannot accept all windows & doors, roof tool cannot be used for a vertical element (roof @90º) but will do 89º, wall tool cannot be used for a horizontal element but will do 1º, wall at 30º pitch will accept all windows & doors yet a roof at the same pitch will not. Mesh has considerable flexibility for modelling a surface, and the morph a great deal more. Ideally this flexibility should be incorporated in all element modelling tools without converting them to morphs and losing all the control & flexibility built into the original tool.
Not sure I have been all that clear with my post, but I hope it makes at least some sense !
2023-11-30 06:33 PM
Your post clearly makes all the sense - I certainly hope anyone at GS reading the whole thread end up wondering the same.
2023-11-30 06:55 PM
I think your idea makes a lot of sense, but I think it would probably involve rebuilding most of Archicad from the ground up.
And if it was built from the ground up there could then be a lot more associativity between elements (e.g. a slap bounded by walls that expands when you move the wall or a WC mounted on a wall that moves with it in the same was as a door or window does).
But that probably goes way beyond the scope of this discussion...
2023-12-04 03:38 PM - edited 2023-12-04 10:18 PM
I feel he is correct that the Roof, Walls, Slabs each have their own limitations , when there could be one parametric object that has ALL the possibilities available to it. There should then be a next level which is the ability to assign a "function" to that parametric object, so that AC knows that it is a Roof, Slab or Wall etc. These objects would then have a relationship based on their assigned function. AC would know that it is a "roof" object and associated to the "wall" object in the correct manner etc etc.
The current method is to start with the assigned object , Roof, wall or slab and then try to customise it. This is backwards from what it should be, as described above.
2023-12-18 11:05 PM
In this regard you could also model a morph and also assign it as a roof, slab etc.
2023-12-04 06:31 PM
Some thoughts about tools and the many levels of classification in Archicad. We have different tools for different elements (walls, columns, beams, windows, doors, stairs, railings, etc.). Elements as such belong to these different groups of elements as we can easily select all columns with this tool active (or do many other things), which is great. But in many situations we use workarounds where one specific element, let's say a column, becomes something else - in my latest example I used a slanted round column for a tendon. Now for all such elements, which we all know can become many in every project, we have to use some classifications, which help us define this different use of a dedicated element tool. Mostly we all use the built-in Archicad classification system. Some of us go even further (BIM) and juggle around with the Classification Manager, IFC translators with Type & Property Mapping and IFC Project Manager. With all this different steps we have:
These many levels of classification should get simplified. The present modeling limits of each element tool should be removed. We are all used to dedicated tools, but one possible solution could be introducing the same modeling power behind each of this tools - like Morphs, but with added ability to keep this element within the original classification (or assign another classification, but on one uniform classification level). I know I could just ditch everything else and start using morphs, but I'd loose the funcionality other tools have to offer. I also know I can change every element into a morph, but I'd loose the dedicated tool functionality and can't reverse it.
Upgrading the modeling capabilities behind each tool could keep the workflow we all use alive, but it would give us much more modeling power. I also know that this added funcionality would present many questions and challenges in software development, but maybe it's worth considering, as many of this topic suggestions could be solved this way. Just an example - a composite slab, with a better modeling engine background, that has all the functionality the slab tool has to offer, but also allows modifying the geometry by each node of each composite layer, adding or deleting nodes, adding or deleting edges, adding edge- based modifiers, etc...
As for IFC translation and other classification systems - the present workflow is not the best of all times, but it does work. A huge problem here are the language dependent localisations, as most of them have their Archicad (and IFC) classification system translated. It's a good thing on a national level, but as soon as you want to collaborate on an international level, you have a big problem. Even this one can be solved, but it's not worth the effort. I kindly ask for a solution that would enable us to switch our localisation with every needed settings or just change all classification systems into a two level system with native language descriptions and a hard coded base so all such classification systems become language independent.
| Archicad 4.55 - 27
| HP Z840 | 2× E5-2643 v4 | 64 GB RAM | Quadro M5000 | Windows 10 Pro x64
| HP Z4 G4 | W-2245 | 64 GB RAM | RTX A4000 | Windows 11
2023-12-04 08:30 PM - edited 2023-12-04 08:43 PM
What makes it all fall apart for me and turn working in AC into a constant struggle against how I conceive buildings is the lack of generic information entities - the most fundamental concept of a building information model. Instead of leaving it up to the designer to define and structure the information model and decide how it should be represented, AC forces it's skeuomorphism on the designer limiting the information modelling to entities preconceived by the developers in a past very different from the fast approaching future.
There really need to be a separation of the information entity and it's geometric representation if AC is to remain relevant. The first thing I know when designing a building is that there will be a number of functional systems for creating space, providing services, and fitting out spaces. These systems in turn contain a number of technical systems or solutions such as foundation, slab, wall and roof constructions which in turn are made up components such as beams, columns, blocks, shells, plates, etc. There are different classification systems with different terminologies but this is pretty much boiler plate thinking. Despite GS pretending to be a industry leader and Huw wanting to "put the fun back into BIM" - AC requires extensive and exhausting effort from the user to keep every bit and piece together as the software doesn't even have the functionality to create, classify and assign properties to a group of elements.
2023-12-15 05:15 PM
Personally, i see the future of bim modelling in the capability of handling project components, in all design stages, because that's how it's happening in real life, we're stacking and assembling components to create building elements, and not the inverse.
2023-12-15 08:18 PM
2023-12-16 09:22 AM
Hi James, what a great post this is to read with all the intelligent replies given. I liked all the explanatory diagrams to help us understand things more clearly. Consulting with true expert users brings out much insight that will ultimately help all of us going forward.
I have a question regarding the timeframe and the degree of difficulty of the implementation of the concept of “Exploding Composites (Skins/Components) in 3D” in order to edit them. How hard would it be to start rolling this type of feature out to us all ?
It reminds me of the time in AC17 when they started assigning building materials to composite components. Now we are discussing the disconnecting of composite components from each other in order to edit them separately. That would definitely mean less use of CPM for simple structures.
Converting elements to morphs is a solution that many are employing but they would also like to reverse the process and be able to convert back to an element as well. I think without getting too complicated that would be enough to work on for now I hope ? The rest will eventually follow on in the logical process of development.
I like to break things down into pieces so I can understand them better and help others in the process. No pun intended !
2023-12-18 11:32 AM - edited 2023-12-18 11:33 AM
2023-12-18 11:43 AM - edited 2023-12-18 11:43 AM
renovation workflow menu
like this we can get also automated composite naming according to the skins ,
2023-12-18 11:48 AM
2024-02-14 08:41 AM - edited 2024-02-14 08:42 AM
Hi,
it would be nice to be able to modify with the GO the pen of a line which is in direct contact with a construction material in a composite
THANK YOU
2024-03-06 09:50 AM
This is a slab cut by walls, The same workflow for Roofs, Walls,
theese portions are detectable by zones , to extract zone wall / ceiling / floor finish ,
2024-06-13 10:50 AM
This project is still on development ??
When we expect an experimental approach??
2024-06-22 10:19 AM
My point of view :