identische Objekte aber untersch. Δz-Werte

[wolfski]

Hallo,

hier passiert was komisches: Ich habe ein Objekt erstellt (extrudiertes Rechteck). Δz ist 10m. (in Info-Palette und Tabelle)

Ich kopiere das Objekt und boole eine kreisf. Öffnung rein. Δz ist 10m.

Ich kopiere das geboolte Objekt und rotiere es (in dem Fall um 15°). Δz ist 10m.

 

Ich kopiere das allererste extrudierte Rechteck und rotiere es um 15°. Δz ist 10m.

Erst NACH der Rotation boole ich dieselbe kreisf. Öffnung an derselben Stelle rein.

Δz ist nur jetzt 10,179m.

 

Mehrmals ausprobiert, immer dasselbe. In den Tabellen dasselbe. Finde ich extrem gefährlich. Wenn ich Objekte baue, Listen (Tabellen) erstelle und dann Objekte nach einer Rotation erändere (boole, schneiden …) zeigt mir die Tabelle ja total falsche Werte an.

Kennt das jemand? Ich hänge mein VW-Testdatei an.

 

Viele Grüße Wolfgang

 

VW-Problem Δz_01.vwx

 

 

[rocko]

Hab es gerade mit vwx2021 geöffnet und das nachgestellt und es verhält sich genauso.

komisch...

[halfcouple]

Das hängt damit zusammen, dass bei der 3.Methode innerhalb des Objekts eine Working Plane ( DE = Arbeitsebene ?) erstellt wird, von deren Ursprung aus gemessen wird. Bei den anderen Methoden wird vom Ursprung des Systems aus gemessen.

[wolfski]

Hallo halfcouple,

danke für Deine Erklärung. Aber auch damit ist es für mich nicht nachvollziehbar. Wenn VW xyz angibt, dann müssten das doch immer die äußeren Abmessungen sein. Und die sollten doch immer von einem Punkt zum anderen Punkt gemessen gleich bleiben. Besonders wenn die Länge des Objekts sich nicht ändert. Es verunsichert mich extrem, wenn ich sehe, dass VW ein und dasselbe Objekt mal so, mal anders beschreibt. Und mich interessieren ehrlich gesagt nur die äußeren Dimensionen und nicht ob VW intrn irgendwas anders sieht. Auf dieser Basis schließen sich ja u.U. viele andere Dinge an: Ich nenne hier nur mal Mengenberechnungen in Tabellen, die für Kalkulationen usw. benötigt werden.

Bei mir hat das jetzt zur Folge, dass ich alle Objekte mit nicht orthogonaler Ausrichtung mit allergrößtem Misstrauen betrachten werde. Und dann fängt man vlt. an, die Dinger noch alle selbst nachzumessen, um zu checken, ob VW hier die richtigen Angaben macht. Bei komplexen Konstruktionen/Tabellen (auch Gebäuden) ist das ja nicht gerade zuverlässig.

Gerade in Zeiten, wo alles auf Kalkulationen beruht und erst recht bei BIM - und das auch von den Herstellern ganz stark propagiert wird: Kann ich mich da auf die angezeigten Ergebnisse verlassen?

Oder anders herum: Wenn ich ein gekipptes Objekt bearbeiten möchte, muss ich es erst wieder senkrecht stellen, dann bearbeiten und dann wieder in die ursprgl. Lage zurückkippen, damit mir die Dimensionen richtig angezeigt werden. Was ist denn das für ein Krampf? Und das muss ich ja so machen, weil ich für meine korrekten Tabellenwerte ja gar keine andere Möglichkeit habe. Was nützt es mir, wenn ich weiß, dass die Angabe nicht stimmt, die Tabelle aber trotzdem mit den falschen Werten rechnet?

Sehe ich hier was falsch oder gibt es einen Workaround, den ich momentan nicht sehe?

[petitbonum]

Hallo Wolfski

das liegt daran, dass für Vectorworks ein Objekt dass Du mit boolschen Operationen bearbeitest nur noch die 3dimensionale Boundingbox als xyz-Werte anzeigen kann (schneide doch mal gedanklich überall nichtrechtwinklige scheiben oder besser prismen ab und überlege welche Maße Dir jetzt Vectorworks als x,y und z angeben soll und für welche längen die dann gelten. Das ganze funktioniert halt nur solange du rechwinklige Objekte parallel zu den xy und z achsen parallel hast sicher, bei allem anderen sollte man kritisch sein (weil je nach Konstruktionsmethode halt noch die Arbeitsebenen paralell gehalten werden) und so die Maße noch stimmen. Solange unserer Zeichnungen und 3D-Darstellungen Vereinfachungen der Realität darstellen werden wir damit leben müssen das uns die Computer auch nur vereinfachte Ergebnisse liefern. Es bleibt halt immer ein austarieren des Eingabeaufwandes und der Ergebnisse die wir daraus gewinnen können.

mfg

petitbonum

 

[halfcouple]

habe mir das gerade noch mal angesehen, solange die Objekte unterschiedlich erstellt werden kann man das ja noch so gerade eben nachvollziehen, spätestens aber wenn man die Objekte danach alle in Generic Solids (DE= Festkörper?)

umwandelt sollten sie die korrekte Höhe anzeigen, was nicht passiert.

Seltsamerweise wird die Höhe von Objekt C korrekt berechnet, wenn man es ungruppiert und dann wieder ein Sold Substraction (DE=Fekörper-Subtraktion?) erzeugt.

Scheint ein echter Bug zu sein.

Grundsätzlich ist es natürlich richtig, dass die Bounding Box nicht immer mit der geometrischen Form darin übereinstimmen muss.

Bearbeitet 11. Dezember 2020 von halfcouple

[wolfski]

@petitbonum: Deine Erklärung habe ich verstanden. Dann ist es also so: rechtwinklig stehendes Objekt kann man boolen und das ergibt dann die entspr. Bounding Box (mit korrekten Maßen). Wenn ich das Objekt dann neige, hat es immer noch die Bounding Box vom senkrecht stehenden Zustand und VW zeigt deswegen die korrekte Länge an. Wie mein Beispiel C.

Wenn ich das Objekt neige und dann in diesem Zustand boole, zeigt es die Bounding Box in diesem Zustand an und damit dann die nicht mehr korrekte Länge (ich beziehe mich mit Länge immer auf gemessene Strecke zw. 2 Eckpunkten der langen Kante).

Mein Problem ist ja die Tabellenauswertung. Mir wäre ja schon weitergeholfen, wenn ich dem Objekt einfach per überschreiben die korrekte Länge zuteilen kann, damit die Tabelle richtig rechnet.

Dann muss man das vlt. so machen, wie halfcouple gerade ausprobiert hat: Objekt ungruppieren und wieder zusammensetzen. Dann scheint da ja irgendwas mit den Bezügen (Bounding Box usw.) wieder „richtig“ zu werden.

Ist irgendwie komisch oder vlt. doch einfach nur ein Bug?

[herbieherb]

Ne ist kein Bug. Die Bounding-Box richtet sich nach dem internen Koordinatensystem des jeweiligen Objekts. Das interne Koordinatensystem wiederum richtet sich nach dem globalen Koordinatensystem zum Zeitpunkt der Erstellung des Objekts. Bei verschachtelten Solids kann es dadurch auch verschieden ausgerichtete Koordinatensysteme im innern verschachtelt haben. Darum auch das auf den ersten Blick überraschende Verhalten deines letzten Solids.

 

Das hört sich jetzt etwas kompliziert an, ist aber ein ganz einfacher Algorythmus. Die Funktionen Länge/Höhe etc. bezieht sich bei Objekten, welche diese Attribute nicht haben auf die Bounding-Box, welche am jeweilige Bezugssystem des Objekts ausgerichtet ist.

 

Hier zum Verständnis dein Bild mit eingezeichneter X-Richtung und zugehöriger Bounding-Box:

 

Wenn du das im Hinterkopf hast, kannst du auch kontrollieren, in welche Richtung die Tabellenfunktionen messen sollen. Wenn du ein Objekt vor Drehung in ein Symbol packst, kannst du später das Symbol drehen wie du willst, die Objekte darin bleiben in der Ursprungsrichtung, da in Bezug auf die Koordinaten im Symbolinnern orthagonal und also auch entsprechend Auslesbar. Solid-Booleans verhalten sich wie Symbole. Sie haben im Innern ebenfalls eigene Koordinatensysteme.

 

Manche Objekte haben eine tatsächliche xyz-Richtung. Zum Beispiel definiert sich ein Rechteck aus Länge/Höhe/Position/Drehung, weshalb die auch bei gedrehten Rechtecken die korrekte Höhe automatisch ausgeben können. Polygonen fehlen alle diese Attribute, weshalb sich die Formeln auf die Bounding-Box beshränken muss, selbst wenn das Polygon die Form eines Rechtecks hat.

Bearbeitet 11. Dezember 2020 von herbieherb

[wolfski]

Danke herbieherb! 

Dein Tipp, das ganze in ein Symbol zu packen, ist genau das was ich benötige. 

Bearbeitet 11. Dezember 2020 von wolfski

[halfcouple]

hmm.... wieder mal was dazugelernt !  

 

Danke @herbieherb