Korrekte Türenmodellierung / -bemaßung

[Ata1]

Hallo zusammen,

Ich würde gerne anstatt den DACH Türen die Türen INT (libpack: Doors and Windows DACH + Doors and Windows) verwenden, da sie mMn in der Darstellungsvielfalt und in der korrekten Darstellung zwar immer noch nicht gut, aber besser sind (Glasrahmentür im Grundriss richtig dargestellt, mehr Optionen bei den Modelldarstellungen, ...)

Nun habe ich aber das Problem, dass sich diese nicht richtig bemaßen lässt auf RFB. Bei den DACH Türen gibt es die Möglichkeit Wandöffnung bis zur Wandunterkante zu generieren und dann über die Bemaßung Übergröße die richtige Höhe zu erhalten: 

Bei der Tür INT finde ich eine solche Einstellungsmöglichkeit leider nicht.

BIM All-Doors scheint momentan ebenso nicht auf RFB bemaßen zu können (laut GitHub ein Bug)

Hat hier jemand vielleicht einen Lösungsvorschlag oder muss ich einfach weiterhin die DACH Türen verwenden und mit den Fehlern und mangelnden Optionen leben?
Danke schonmal Vorab.

[snow]

Danke Frank für deine Rückmeldung!

An einen Spendenaufruf, damit diejenigen die das machen, auch dafür bezahlt werden könnten, hatte ich jetzt auch schon gedacht. 🌟

Das Objekt ist echt die einzige vernünftige Tür am (CAD-) Markt, die zumindest ich kenne. Neben vielem anderen mag ich das Objekt auch deswegen, weil es Türblatfalz und Tür-Drücker-Darstellung gibt.

Dass sich die Öffnungshöhe nicht bis zum Rohboden bemaßen lässt, schränkt die Vewendbarkeit jedoch wieder ganz schön ein...

Es wär' doch schön – wenn diese Wunderwerk schon überhaupt entstanden ist – diese Kleinigkeiten noch anzufügen. 😊

@BerndSchwarzenbacher 
Wenn sich so eine Team, wie von Frank vorgeschlagen gäbe – wärst du auch dabei?

[Ata1]

Bringt bei der Tür INT leider nichts...

[BerndSchwarzenbacher]

@snow freut mich, dass du da an mich denkst 🙂

Hatte eh schon länger vor mir die Tür mal anzuschauen. Aber hat noch nicht den richtigen Anlass gegeben. Wenn sich da ein Team mit Funding findet, bin ich gerne auch dabei 🙂

[Lukas Oelmueller]

So auf die schnelle komm ich ohne Scripting zu folgender Möglichkeit: 
Achtung: geht nur bei "eigener Höhe" nicht bei bis Wandunterkante!

1. Dieses Video zeigt dem Umweg der Etikettierung von IFC Eigenschaften 
https://youtu.be/g6EI0H9yt5c?si=O-rJamnEPPqB_0T3
2. Mappe den Wert GDL Wert "thresholdBottomOversize" zusammen mit der Höhe und einem "+" dazwischen in dem als Standard definiertem IFC Übersetzer
Beschrifte mit dem Etikett "Klassifizierung und Eigenschaften"

 

 

[snow]

Danke Lukas, für das aufzeigen der Möglichkeit, die relevante Höhe "irgendwie" in den Plan zu bekommen.

Das große Anliegen diesbezüglich ist aber weiterhin, dieses Maß, bis Wandunterkante in die normale Bemaßung zu bekommen 😉

Wie hoch schätzt ihr denn den Aufwand, das entsprechend in das Skript einzuarbeiten?
... dann  ließe sich der Finanzbedarf daraus ja ableiten.

@Hmooslechner 
Was sagst du denn dazu?
...hatte dich noch gar nicht gefragt, bisher...

[Frank Beister]

Ich hatte schon mal reingeschaut. Der kritische Part ist im Main-Objekt. Ein Unterprogrammaufruf um ca. Zeile 538 und der böse Stoff ab Zeile 1084. Es kann sein, dass der gewünschte Fangpunkt sowieso gesetzt wird, aber nicht auf der Höhe, die du brauchst. Wenn die Maße den Rohbaubezug richtig bekommen, könnte das evt. sogar ohne ein Ändern eines HOTSPOT funktionieren.
Da lässt sich kein Aufwand abschätzen. Die Gesamtabmessungen sind ein Knotenpunkt, wo viele Abhängigkeiten zusammenlaufen. Da kann man voraussichtlich nicht "einfach was ändern". V.a. nicht schnell. Es bräuchte wieder jemand, der sich mit in den Quellcode reinkniet. Vielleicht kann das auch Claude, aber sicher nicht in der freien Variante.   

[snow]

---

@Frank Beister  schrieb:

Es bräuchte wieder jemand, der sich mit in den Quellcode reinkniet.

---

Sieht sich dazu jemand von euch berufen?

(Hört doch mal genau hin… 😉)

[runxel]

Na gut, na gut.

Einer muss ja.

Ich habe das Repo mal geforkt und damit gegonnen, den Code von Frank zu entwirren und aufzubereiten (nicht falsch verstehen, fremder Code ist immer erst mal wüst und schwierig zu durchblicken; Franks Code ist aber sehr smart.). Ist auf meinem Github zu finden. Jetzt kann man auch als "Uneingeweihter" damit arbeiten, denn ich habe alles ins native HSF Format gebracht; man kann also den LPXML_Converter nun direkt damit füttern, ohne von externen Tools abhängig zu sein.

Einige kleine Fehler hab ich auch schon ausgemerzt (der Code, wie er aktuell ist, ist nur bedingt lauffähig. @Frank Beister , da werden einige Makros mit falschen bzw. nicht existenten Parametern aufgerufen).

Ich habe mich mal durch die GS-Makro-Abhängigkeiten gequält, um zu schauen, was sie da anstellen, dass die Bemaßung wie gewünscht funktioniert. Allerdings zunächst ohne Ergebnis, denn es ist egal, ob ein Hotspot tatsächlich dort gesetzt ist – das ist also eine falsche Fährte.

Für die fachlich Interessierten: Das Makro, in dem bei den GS-Türen die Hotspots auf die unterste Höhe des Türlochs gesetzt werden, ist das folgende:
GS Tür > GS Internal Door Functions CHE > WallholeStructure > WallholeCut.

Stattdessen ist es einfach der magische Parameter ac_wallhole_height der richtig befüllt sein muss.

Der wird allerdings an etlichen Stellen verwendet. Das wird etwas dauern, das zu entschärfen und alle Referenzen hier richtig auszutauschen.

Das ist, wie Frank ganz richtig gesagt, wahrscheinlich nicht mal eben so an einem Nachmittag gemacht.

[snow]

Wow!

Danke im Namen aller, schon mal für die Spätschicht!

(Ich hatte mir auch mal ein ganz einfaches Türobjekt gebastelt… da hatte ich auch mit der Höhenbemaßung zu tun… ist aber schon wieder ein paar Jahre her und ich kann mich an das alles nicht mehr so genau erinnern… und konnte die Konversationen dazu auch nicht mehr finden.… gut, dass die relevanten Dinge dazu hier genannt werden 👍)

[snow]

Würde vielleicht eine Kiste Wein helfen, damit es weitergehen kann? 😉