Im Allplan Connect Forum tauschen sich Anwender aus, geben wertvolle Tipps oder beraten sich bei ganz konkreten Aufgabenstellungen − auch international.
Und damit wirklich keine Frage unbeantwortet bleibt, unterstützen die Mitarbeiter des Technischen Supports ebenfalls aktiv das Forum.
Melden Sie sich jetzt an und diskutieren Sie mit!
Hallo liebes Forum,
ich wollte mich kurz erkundigen ob es im Allplan 2020 eine Möglichkeit gibt die Fensteroberflächen in der Animation verschiedenfarbig darzustellen, um eine realistischen Effekt in der Visualisierung zu erzielen?
Dh. Aluschale (Außen), Holz oder Kunststoffrahmen (Innen).
Wäre toll wenn mir jemand helfen könnte.
LG
Daniel
..ach ja, un die Scheibe in der Tiefe positionieren funktioniert übrigens genauso:
Um die Scheibe eine unsichtbaren (Breite 0) Rahmen mit der Glasdicke (2 cm) anordnen, Ausrichtung = vorn,
und dann der Scheibe noch eine Dicke geben.
Kleine Verbesserung:
Wenn man bei de Prositionierungs-Rahmen als Breite nicht 0 cm verwendet, sonderen eine kleinen Wert z.B. 5 mm,
dann passt sich das "Doppel-Fenster" auch an nichtrechteckige Öffnungen an.
dazu müsste man das smart part umscripten.
nicht ganz easy, aber sehr wünschenswert, da gebe ich dir recht.
neben der zweischaligkeit der Rahmenelemente, würde ich mir wünschen, das man die Lage der Glasebene (mit und ohne Dicke) regulieren kann.
Vielleicht probiere ich es mal - wollte ich eh schon mal machen - , aber ohne Erfolgsgarantie, denn das Fenstersmart-Part ist sehr sehr komplex und es ist schwierig überhaupt die richtige Stelle im script zu finden. Vielleicht sollte man mal die Fensterbank und Sonnenschutz separieren, um den code für das FenstersmartPart übersichtlicher zu halten. Zur Auswertung ist es eh besser, das sind seperate Smart-Parts.
eine einfachere schon fertige lösung wäre es, das Fassadentool für zweischalige Fenster zu nehmen. Das sollte gehen.
Einzige Einschränkung: Du kannst dort direkt keine Glasfläche ohne Dicke nehmen, welche aber teilweise bei den Öffnungsflügel-Macros eine Nulldicke hat. "Mal mit, mal ohne" stört bei Renderings. Für gute Renderings sollte das Glas überall eine Dicke haben, oder auch keine.
czyborra klingbeil architekturwerkstatt - http://www.cka.berlin
Man sollte es immer so modellieren, wie es auch gebaut wird.
Und da ist ein Holz-Alu-Fenster eigentlich ein Holzfenster, mit äußerer Alu-Verkleidung.
Der Trick besteht jetzt darin, die Verkleidung als 2. Fenster zu modellieren, und vor das eigentliche Holzfenster zu platzieren.
So geht man vor:
1. Leibungselement der Öffnung mit einer Tiefen von Holzfenster + Alu-Verkleidung definieren (z.B. 7 + 2 = 9 cm)
2. Holzfenster erzeugen, den 1. Rahmen mit Tiefe 9 cm, aber allseitig mit Breite 0 cm erstellen
Dieser damit unsichtbare Rahmen dient nur als "Positionierunge-Element" für den darin enthaltenen 2. Rahmen mit 7 cm Tiefe
(s. Rahmen_2.png) Ausrichtung = hinten
In diesem Rahmen dann wie gewohnt Flügel erstellen.
3. Verkleidung als neues Fensterin dieselbe Öffnung einfügen, wieder 1. Rahmen mit Tiefe 9 cm, aber allseitig mit Breite 0 cm erstellen
2. Rahmen hingegen mit Tiefe der Verkleidung (2 cm) und Ausrichtung Vorn (s. Rahmen_3.png)
In diesem Rahmen noch einen Rahmen für die Verkleidung des Flügels erstellen, Glasscheibe ausschalten
Fertig ist das Holz-Alu-Fenster.
..hier noch das Teilbild zum kopieren.
..ach ja, un die Scheibe in der Tiefe positionieren funktioniert übrigens genauso:
Um die Scheibe eine unsichtbaren (Breite 0) Rahmen mit der Glasdicke (2 cm) anordnen, Ausrichtung = vorn,
und dann der Scheibe noch eine Dicke geben.
Kleine Verbesserung:
Wenn man bei de Prositionierungs-Rahmen als Breite nicht 0 cm verwendet, sonderen eine kleinen Wert z.B. 5 mm,
dann passt sich das "Doppel-Fenster" auch an nichtrechteckige Öffnungen an.
Hallo,
interessanter Trick,
vielleicht wird es aber bei zu ändernden Fensteraufteilungen etwas umständlich zu händeln mit mehreren smartparts für eigentlich die gleichen Infos. Es gefällt mir nicht, wenn die gleiche Information zweimal eingegeben werden muss, weil die Objekte nicht klug miteinander verknüpft sind.
ich habe das fenster-smartpart mal mit der Möglichkeit einer zweischaligkeit und der Positionierung der Glasebene ergänzt.
Die polygonalen Öffnungen habe ich jetzt noch außen vor gelassen, sollte aber auch nicht weiter anders sein.
Wichtig fande ich, dass die Deckschale der Öffnungsflügel wie bei Unilux auch außen bündig sein kann.
Interessieren würde mich, mit wie viele Linien Skript die gleiche Funktion des Fenstersmartparts als Pythonpart nachgebaut werden könnte. Die Hälfte? ein Zehntel? ein Hundertstel? noch viel weniger?
In Pythonparts kann man auf Makros zugreifen, auf die Smartparts leider nicht. Weiß jemand, ob es beabsichtigt ist, das bald zuzulassen?
Beste Grüße in die Runde marek
czyborra klingbeil architekturwerkstatt - http://www.cka.berlin
"Respekt wer's selber macht!" würde man bei Obi sagen :-)
Tolle Nummer, das ist!
Zu Deinen Fragen:
1. Nachbau in Python
Ich fürchte, die Zeilen Script werden in Python nicht weniger sein!
Man vergisst leicht, das beim Aufruf jeder einzelnen Funktion im SmartPart-Script hunderte Zeilen C++-Code mit
Validierung, Fallunterscheidung und den Basis-API-Aufrufen ausgeführt werden.
Mit der Python-API bekommt man lediglich die nativen Basis-API-Funktionen nach Python gewrappt.
Beispiel:
Die einfachste Funktion BOX durchläuft beim Ausführen ca. 450 Zeilen C++-Code!
Darin sind Fallunterscheidung für negative oder Null-Abmessungen, der gesamte Transformation-Stack und das
Cutting sowie Gruppen-Bildung enthalten. Schliesslich muss man aus dem Ergebnis-Polyhedron noch einen ModelElement mit
Stift, Strich, Farbe Layer und Oberfläche erzeugen.
Das ganze muss man logischerweise im Python auch machen. Aber dort gibt es keine Funktion BOX!
Die müsste man sich erst mal schreiben, und dann noch die Transformationen implementieren!
Ich glaube nicht, das man dabei mit weniger Code auskommt.
Bei der GUI bekommt man dann noch weitere Probleme.
Die Palette des SmartParts ist komplett gescripted, bei PythonParts wird lediglich eine XML statisch interpretiert!
Eine GUI mit Aktions- und Zustands-Steuerungen wie beim SmartPart-Fenster sind mit Python-Parts gar nicht möglich!
Man sollte auch bedenken, dass Python 20-100 mal langsamer ist als C++!
Und: Ein PythonPart lässt sich nicht in eine Öffnung einsetzen, und reagiert nicht auf die Größen- und Formänderung der Öffnung!
Das alles lädt nicht gerade ein zu einem Versuch "PythonPart-Fenster".
Aber bitte, wer's ausprobieren möchte. Besonders viel Spass hat man auch mit der ausführlichen PythonParts-Dokumentation!
2. Zugriff auf Makros
Zitat "In Pythonparts kann man auf Makros zugreifen.." Wie ist das gemeint? Ein anderes Makro aus der Datenbank einlesen?
Soviel ich weiss, kann man das aus einem PythonPart heraus nicht!
Mit einer benutzdefinierten Eingabefunktion kann man sicher mit Python irgendwelche Objekte aus der Datenbank lesen,
aber was will man damit anfangen? Es gibt tatsächlich einen ElementsSelectService, der alle Elemente der Datenbank liest.
Aber es fehlen Wrapper für all die anderen Objekt-Typen wie Stützen, Decke, Räume usw.
In Visual-Script gibt es immerhin einen Wand-Node! (Aber ein Fenster würde ich jetzt nicht in Visual-Scripting versuchen!)
Aber ich geb Dir Recht, für ein Fenster-Element könnte es durchaus interessant sein, zu erfahren, welche anderen Makros noch in der Öffnung eingebaut sind. Dazu braucht es Funktionen, um aus dem Fenster in die Öffnung zu kommen, um von da aus auf alle untergeordneten Elemente zuzugreifen. Aber um eine Abhängigkeit zu generieren, muss man ja das andere Element komplett kennen, und den betreffenden Parameter auslesen können. Beispiel: Aufsatzrolladen - Die höhe des Kastens muss man erst mal aus dem Element herauslesen, bevor man das Fenster in der Höhe um diesen Wert reduzieren kann! Das Element könnte ein SmartPart sein, oder ein PythonPart oder ein Visual-Script oder auch ein gutes altes selbst definiertes Makro! Wie soll man an den betreffenden Parameter herankommen, wenn es dafür keine Schnittstelle gibt?
Man sieht, das Abhängigkeiten und Wechselwirkungen in einer Script-Umgebung gar nicht so einfach zu handeln sind!
Für SmartParts glaube ich nicht (mehr), das so etwas eingebaut wird!
Da hat sich ja in den letzten Jahren nich so viel getan...
In Pythonparts kann man auf Makros zugreifen, auf die Smartparts leider nicht. Weiß jemand, ob es beabsichtigt ist, das bald zuzulassen?
It's hard to say... Today, PythonParts can not be used as opening. So...
The language is quite different. I don't think we can get halfway there. In most cases, it is rather longer...
The macros integrated in PythonParts are managed as if the PythonPart transported the macro to place it. The result is a PythonPart containing the macro. The macro can be modified independently of the PythonPart but the PythonPart cannot modify the macro.
In short, it is not very flexible and efficient...
I don't think SmartParts will receive this type of development or even other major improvements...
_______________
Es ist schwer zu sagen ... Heute kann PythonParts nicht als Öffnung verwendet werden. So...
Die Sprache ist ganz anders. Ich glaube nicht, dass wir auf halbem Weg dorthin kommen können. In den meisten Fällen ist es eher länger...
Die in PythonParts integrierten Makros werden so verwaltet, als ob PythonPart das Makro transportiert hätte, um es zu platzieren. Das Ergebnis ist ein PythonPart, das das Makro enthält. Das Makro kann unabhängig vom PythonPart geändert werden, aber das PythonPart kann das Makro nicht ändern.
Kurz gesagt, es ist nicht sehr flexibel und effizient...
Ich glaube nicht, dass SmartParts diese Art von Entwicklung oder sogar andere wichtige Verbesserungen erhalten wird...
Edit: while I was translating my answer, Jörg (Nemo) was faster and explained the inner workings well...
Danke, Jörg und Bertrand, für eure Erklärungen.
Interessant zu hören, was da alles hintersteckt.
Etwas unglücklich bin ich, dass es nicht eine Lösung gibt, die zum einen schon gut und nutzerfreundlich funktioniert und auf deren Zukunftsfähigkeit man aber auch Vertrauen kann(zb. die vernachlässigte Smartpart-script). Ich finde es generell sehr schade, dass so fantastisch tolle Ansätze wie smart-Part-script oder auch der Fassadenmodellierer nicht weiterentwickelt werden. Ansätze werden nicht zuende entwickelt, nicht kontinuierlich weiterentwicklelt. Ein großes Potential wird da bei Allplan einfach nicht ausgeschöpft. Schade.
Stattdessen kommen neue vielversprechende Möglichkeiten (Python), aber kann man darauf vertrauen, dass diese nicht auch wieder ab den erfolgreichen Verkaufsvideos fallengelasssen werden? Meiner Meinung nach läuft man mit so einer Strategie den anderen nur hinterher und schafft nicht wirklich Vertrauen. Soll man dann in das Erlernen des Pythonpart-Skripten überhaupt investieren?
Ja, noch bekommt man kein (Fenster-)Loch in eine Pythonpart-Wand, auch nicht per bool-operation, vielleicht nur über den Trick die Geometrie der einzelnen Wandschichten herauszulesen und dann zu boolen. Also über sehr umständliche Wege nur und dann ist wohl auch keine Wand mehr. Ermitteln kann man die schichtweisen Wandöffnungs-Polhydrone bestehender Wände schon, aber man wird in Python wohl bisher noch keine dynamische Verknüpfung an eine Allplan Fensteröffnung hinbekommen. Im dynamischen Verknüpfen (zB an die Ebenen) ist Python noch nicht sehr zuverlässig.
Immerhin wird eine Python-Wand nach dem Auflösen eine richtige native Allplanwand.
Wir wollen mal die Hoffnung nicht aufgeben und uns in langer Geduld üben.
Bei smartpart-Wänden kann man zwar Öffnungen einfügen und Fenstersmartparts per PARAMETERS einsetzen, aber diese werden nach dem Auflösen zu dummen 3d-Körpern.
Sorry, den thread der zweischaligen Fenster habe ich wohl etwas in der Thematik gesprengt.
Beste Grüße und viel Erfolg mit den zweischaligen Fenstern
marek
PS: "aus Python auf Makros zugreifen"..bei den examples unter libraryelements wird gezeigt wie ein smartsymbol (makro) aus einem zu wählenden Pfad platziert wird. Aber ob es verändert, verzerrt usw werden kann, habe ich nicht geprüft.
czyborra klingbeil architekturwerkstatt - http://www.cka.berlin
I tested and you get a PythonPart including the macro. If you click on the PythonPart, the both are selected and you can make modifications.
You can change the global dimensions of the macro, its placement, the global format (color, pen...). That's all (but it could be what we want). To keep this as a PythonPart, you need to add at least one element (line, cube, etc.).
You get also the macro as an independant object in the drawing. Then, you can modifiy the macro by yourself, as usual.
So, you cannot use this to make a "nice" configurator based on several macros. The result is like you put several macros on the drawing, not only one.
