Das Wissen aller Anwender nutzen

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.

Es erwarten Sie:

  • Foren-Vielfalt aus CAD Architektur, CAD Ingenieurbau uvm.
  • Tipps von User für User
  • international: Deutsch, Englisch, Italienisch, Französisch und Tschechisch

Melden Sie sich jetzt an und diskutieren Sie mit!

Zur Registrierung

[Frage] BoxByPlane bei großen Bezugspolylinien wird nicht korrekt dargestellt/abgesetzt

Schlagworte:
  • Fassade
  • BoxByPlane
  • Allplan
  • 2023

Hallo zusammen,

für die Fassadengestalltung habe ich ein kleines VS geschrieben. Hierbei wird die Unter- und Oberkante über Polylinien abgegriffen. Dies funktioniert bei "kleinen" Fassaden wunderbar.

Wenn die Außenkanten größer werden, im Beispiel ca. 150m x 150m werden plötzlich nicht mehr alles Fassadenelemente an den ermittelten Punkten abgesetzt, sonder landen teilweise am Nullpunkt im Projekt. Getestet habe ich es auch mit einfachen Quadraten als Polylinien.

Hat jemand eine Idee, woran das liegen könnte?

Anhänge (3)

Typ: image/png
90-mal heruntergeladen
Größe: 333,82 KiB
Typ: image/png
55-mal heruntergeladen
Größe: 123,44 KiB
Typ: application/x-sqlite3
622-mal heruntergeladen
Größe: 132,00 KiB

Hilfreichste Antwort anzeigen Hilfreichste Antwort verbergen

Die Werte im Tooltip sind ein weiterer, allerdings ganz anderer Fehler!

Entscheiden ist, dass die Toleranz bei GetTangetVector einfach zu klein ist!
1.0e-08 mm Abstand zur Kurve "reicht" schon aus, damit kein Tangenten-Vector mehr ermittelt wird,
weil die Funktion "meint", dar Punkt ist nicht auf der Linie!

Die Funktion sollte mindestens bis zu einer Toleranz (der Koordinatenwerte) von 1.0e-03 mm den Punkt auf der Linie akzeptieren! Wir reden hier über eine "gerade Linie".
Ich kann mir nicht vorstellen, wie man eine Toleranz von 1.0e-09 mm bei einer echten Kurve, z.B. Spline oder BSpline erreichen soll!?

@Allplan
Das ist ein weiterer schwerer Fehler in Visual-Scripting, in der Python-API und auch in der NemAll_Geometry.DLL

Nächster Fehler in Visual-Scripting :In diesem Fall sollte der Node GetTangetVector einfach nichts zurückgeben,z.B. einen Null-Pointer (null, nullptr, None o.ä.) statt eines ungültigen Vectors!
Alle andere Visual-Scripting-Implementierungen (Grasshopper, Dynamo) machen das so!
Das bedeutet aber auch, dass jeder Eingang eines jeden Nodes mit einem solchen Null-Wert bzw. einer Liste aus diesen Null-Werten zurechtkommen muss!

Wenn man nämlich mit einem Vector3D(0,0,0) versucht, eine Plane3D zu erzeugen, kommt Allplan damit nicht zurecht. Das Script "stürzte" bei mir mehrfach ab!

..es gibt noch viel zu tun!

ClosestIntersectionPoint mit der oberen Polylinie scheint an der betroffenen Stelle nicht vorhanden zu sein! Sind diese Linien wirklich exakt übereinander? Ungenauigkeiten bekommen umso größeres Gewicht, je größer die Koordinatenwerte sind, d.h. je weiter das Ganze vom Nullpunkt weg ist.

Ich glaube mich auch zu erinnern, dass in der Geometrie-API die Ermittlung von einem Schnittpunkt einer horizontalen 3D-Linie mit einer vertikalen nicht zuverlässig funktioniert. Betraf allerdings eher Curven, also BSplines, Splines und Kreise. In meinen Plugins habe ich deshalb diese Funktion selbst neu geschrieben.

Ein anderes Problem könnte beim Node DivisionPoints "lauern".
Auch hier gab es Ungenauigkeiten bei der Ermittlung. D.h. der ermittelte "Division-Point" besteht einen anschliessenden Test IsPointOnLine nicht! Auch das habe ich schon mal als Fehler gemeldet.(s div_points1.png und div_points2.png)

...müßte man mal testen, woran es nun wirklich liegt.

Anhänge (2)

Typ: image/png
30-mal heruntergeladen
Größe: 54,42 KiB
Typ: image/png
14-mal heruntergeladen
Größe: 31,33 KiB

Danke Nemo für die Rückmeldung.

Ja, in den Tests mit größeren Außenmaßen ist es einfach nur ein Quadrat der Polylinie und eine Kopie dieser, die 20m in z-Richtung verschoben ist...

Und in dem Screenshot ist auch ersichtlich, das die Punkte auf der oberen Polylinie gefunden werden.

Dann kommt ja nur noch GetTangentVector in Frage!
Wenn die Werte nämlich 0,0,0 sind, also ein ungültiger Vector zurückgegeben wird, scheitert auch
die Generierung der Ebene (Plane3DByVector) und die erhält die Standardwerte Point3D(0,0,0),Vector3D(0,0,1). Dann wird die Box am Nullpunkt erzeugt.

Den FEhler konnte ich aber nur nachvollziehen, wenn die Anzahl der Segement über 200 ist, und die Polylinie bzw. ein Segement dieser über 100 m lang ist. (s. fassade1.png)

Ich habe mal eine Überwachung am Ausgang eingefügt, und siehe da, ab Punkt 65
scheitert die Ermittlung der Tangente an diesem Punkt. (s.fassade2.png)
Warum? Das müßtest Du Allplan fragen...

Anhänge (2)

Typ: image/png
21-mal heruntergeladen
Größe: 62,91 KiB
Typ: image/png
21-mal heruntergeladen
Größe: 201,95 KiB

Ich habe weiter "geforscht", und folgende Bedingung herausgefunden:

Die Polylinie muss mehr als ein Segment haben
Dieses (erste) Segment muss >= 100 m lang sein.

Ich habe immer noch DivisionPoints im Verdacht, in diesem Fall ungenaue Punkte zu erzeugen.
Und an diesem ungenauen Punkt (der nicht mehr auf der Polylinie liegt) scheitert dann die Tangenten-Ermittlung. Es scheint so zu sein, dass der InputPoint für GetTangent überhaupt keinen Abstand von der Linie haben darf, also exakt auf der Kurve liegen muss. Ein Abstand von 1.0e-08 mm(!) ist scheinbar schon zu gross...

Anhänge (3)

Typ: image/png
32-mal heruntergeladen
Größe: 133,28 KiB
Typ: image/png
30-mal heruntergeladen
Größe: 157,63 KiB
Typ: image/png
32-mal heruntergeladen
Größe: 180,69 KiB

Die Anzahl der Abschnitte durch DivisionPoints macht irgendwie keinen unterschied. Egal ob 10 oder 300.

Mich irritiert, dass trotzdem alle Punkte "unten" mittels DivisionPoints erzeugt werden und auch alle Punkte "oben" durch ClosestIntersectionPoint ermittelt werden und als Vorschauobjekt angezeigt werden.

Auch bei Kantenlängen kleiner 100m fehlern Elemente. Im Teilbild sind diese enthalten.

Anhänge (3)

Typ: application/zip
617-mal heruntergeladen
Größe: 196,77 KiB
Typ: image/png
18-mal heruntergeladen
Größe: 197,37 KiB
Typ: image/png
18-mal heruntergeladen
Größe: 189,57 KiB

Zitiert von: Nemo
Ich habe weiter "geforscht", und folgende Bedingung herausgefunden:
Die Polylinie muss mehr als ein Segment haben

Dieses (erste) Segment muss >= 100 m lang sein.
Ich habe immer noch DivisionPoints im Verdacht, in diesem Fall ungenaue Punkte zu erzeugen.

Und an diesem ungenauen Punkt (der nicht mehr auf der Polylinie liegt) scheitert dann die Tangenten-Ermittlung. Es scheint so zu sein, dass der InputPoint für GetTangent überhaupt keinen Abstand von der Linie haben darf, also exakt auf der Kurve liegen muss. Ein Abstand von 1.0e-08 mm(!) ist scheinbar schon zu gross...

Wenn du dir die Liste ein zweites mal anzeigen lässt, werden die Punkte, die du mit ??? markiert hast, wieder angezeigt?

Anhänge (3)

Typ: image/png
20-mal heruntergeladen
Größe: 454,55 KiB
Typ: image/png
18-mal heruntergeladen
Größe: 131,84 KiB
Typ: image/png
20-mal heruntergeladen
Größe: 130,07 KiB

Die Werte im Tooltip sind ein weiterer, allerdings ganz anderer Fehler!

Entscheiden ist, dass die Toleranz bei GetTangetVector einfach zu klein ist!
1.0e-08 mm Abstand zur Kurve "reicht" schon aus, damit kein Tangenten-Vector mehr ermittelt wird,
weil die Funktion "meint", dar Punkt ist nicht auf der Linie!

Die Funktion sollte mindestens bis zu einer Toleranz (der Koordinatenwerte) von 1.0e-03 mm den Punkt auf der Linie akzeptieren! Wir reden hier über eine "gerade Linie".
Ich kann mir nicht vorstellen, wie man eine Toleranz von 1.0e-09 mm bei einer echten Kurve, z.B. Spline oder BSpline erreichen soll!?

@Allplan
Das ist ein weiterer schwerer Fehler in Visual-Scripting, in der Python-API und auch in der NemAll_Geometry.DLL

Nächster Fehler in Visual-Scripting :In diesem Fall sollte der Node GetTangetVector einfach nichts zurückgeben,z.B. einen Null-Pointer (null, nullptr, None o.ä.) statt eines ungültigen Vectors!
Alle andere Visual-Scripting-Implementierungen (Grasshopper, Dynamo) machen das so!
Das bedeutet aber auch, dass jeder Eingang eines jeden Nodes mit einem solchen Null-Wert bzw. einer Liste aus diesen Null-Werten zurechtkommen muss!

Wenn man nämlich mit einem Vector3D(0,0,0) versucht, eine Plane3D zu erzeugen, kommt Allplan damit nicht zurecht. Das Script "stürzte" bei mir mehrfach ab!

..es gibt noch viel zu tun!

Danke für den Hinweis!

Mir ist aufgefallen, dass GetTangetVector bei splines nicht solche Probleme macht. Zum Spaß habe ich die Punkte in einen 3DSpline gewandelt, am spline die Tangente ermittelt und alle Fassadenelemente werden an der richtigen Stelle abgesetzt.

Mir ist bewusst, dass diese Lösung nicht optimal ist. Für den Moment reicht es aber aus.

Anhänge (2)

Typ: image/png
40-mal heruntergeladen
Größe: 95,26 KiB
Typ: image/png
27-mal heruntergeladen
Größe: 106,64 KiB

Zitiert von: Nemo
Das ist ein weiterer schwerer Fehler in Visual-Scripting, in der Python-API und auch in der NemAll_Geometry.DLL

Thanks Nemo for finding the issue. We also noticed that some geometry operations don't return an expected result. As Visual Scripting is based on the Python API, and it uses the NemAll_Geometry directly. We are not able to avoid any issues which are present there. But we are currently improving the node library, we will try to inform internal teams to address these issues step by step.

Product Owner API, Allplan GmbH