---

Hallo Community,

ich habe folgendes Problem in ACAD 2004, das ständig eine Menge Folgearbeit auslöst:
Es werden Schnittpunkte nicht angezeigt.
Eine Untersuchung - im Eigenschaftsfenster - der Elemente zeigt auf, daß für die Z-Koordinate weit hinter dem Komma eine Zahl existiert.
Man kann nun diese Koordinaten - für das Element und eventuell "ALLE" auf 0 zwingen; dennoch ist das Problem nicht grundsätzlich gelöst.
>Aus welchem Grund immer< tauchen immer wieder Z-Koordinaten auf, die man wegen der begrenzten Kommaanzeige nicht gleich sieht; Schnittpunkte existieren aber nicht. Kann man eine Einstellung vornehmen, die das Problem begebt ?

[Diese Nachricht wurde von And. am 04. Sep. 2005 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,
ich bin mir nun nicht ganz sicher, worin du das eigentliche Problem siehst. Du hast Objekte mit einem z-Wert ungleich 0, die aber 0 haben sollen. Also hat irgendjemand mal unsauber gearbeitet. Z.B. mal ein Objekt aus einer anderen Zeichnung kopiert und dann mit Objektfang weitergearbeitet kopiert den Fehler dann auch auf andere Objekte.
Also sehe ich nur zwei Lösungsansätze:
1. Objekte, die auf 0 liegen sollen auch auf 0 zeichen
2. Objektfangeinstellung "angenommener Schnittpunkt" nutzen

------------------

gruß
CADdog,
the dog formerly known as TR

AutoCAD spricht mit einem, aber viele hören nicht zu.

[Diese Nachricht wurde von CADdog am 04. Sep. 2005 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Das Problem besteht im Kern darin, daß AutoCad für die Z-Werte "0" anzeigt, und dennoch Schnittpunkte nicht gefunden werden. Bzw. müßte man LUPREC auf 8 setzen ? - "angenommener Schnittpunkt" ist keine echte Lösung, sondern verdrängt das Problem nur - "symptomatische Therapie". Unternimmt man dann BKS-Änderungen, kann es sich mitunter drastisch verschärfen. -
Die Frage ist, existiert irgendwo ein TOOL, das innerhalb einer Hierarchie geschachtelter Blöcke alles auf 0 setzt ? "plätten" u.a. war nicht erfolgreich.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Es liegt *sehr* wahrscheinlich nicht daran, dass da mal jemand unsauber gearbeitet hat - es liegt einfach in der Natur der Sache: Fließkommazahlen haben nun mal eine begrenzte Genauigkeit. Die Wurzel aus 4 ist zwei, aber die Wurzel aus 2 ist 1.41... mit einer *unendlichen* Anzahl von Stellen hinterm Komma - eine Irrationalzahl. Klar, dass ein Rechner das ganz genau berechnen will, dann auch *unendlich* lange dafür braucht. In der Praxis wird also abgeschnitten, da der Datentyp Double eben nur 64 Bit breit ist - nicht unendliche viele Bit!

Das kann man weder demjenigen vorwerfen, der gezeichnet hat, noch AutoCAD. Natürlich könnte AutoCAD anders damit umgehen, z.B. wie Corel Draw!: Was auf dem Bildschirm ein paar Pixel voneinander entfernt ist, ist eben das selbe - basta. Dafür kann man eben bei Draw! auch nur ziemlich begrenzt reinzooomen. Natürlich hat eine Linie von 0,0,0 nach 1,0,0 erstmal beide Z-Koordinaten auf exakt 0. Aber bestimmte Operationen können das ändern, wenn (intern) trigonometrische Verfahren angewendet werden. Jede Drehung usw. bewirkt da eine Fehler-Akkumulation.

Der Vorschlag "angenommener Schnittpunkt" bringt da gar nix. Zwei Linien (von 0,0,0 nach 1,1,000001 und 1,0,0 nach 0,1,00001) schneiden sich nicht. Wäre Z exakt 0, oder wären die beiden Z-Koordinaten gleich, dann wäre der Schnittpunkt .5,.5,<Z-Abw./2> - aber er ist es nicht, und da die beiden Linien auch nicht in einer Ebene liegen, kann es auch niemals einen Schnittpunkt in der Verlängerung geben.

Ein Tool kenne ich auch nicht. Die Tools, die ich kenne, sind immer recht grob gestrickt, gehen *immer* von der irrigen Annahme aus, dass OKS==BKS *) und können auch mal eine Zeichnung zerstören. Auch der alte Trick, mal eben alles von 0,0,0 nach 0,0,100000 zu schieben und wieder zurück, hat keinen Einfluss auf Objekte, deren OKS!=BKS und auch keinen auf Blöcke - ob die jetzt verschachtelt sind oder nicht, spielt übrigens keine Rolle.

*) So ziemlich alle Tools gehen z.B. davon aus, dass eine Linie mit den GCs (10 0 0 0) und (11 1 1 0) im WKS wirklich von 0,0,0 nach 1,1,0 verläuft. Das stimmt oft, aber nicht immer - es kann sein, dass sie im WKS von 0,0,0 nach -1,0,-1 verläuft, das hängt vom OKS (GC 210) ab. Ein Tool "plättet" also u.U. versehentlich den X- oder Y-Wert, orthogonale Linien werden also evtl. auf Null-Länge gestutzt.

Gruß, Axel Strube-Zettler

------------------
Meine AutoLisp-Seiten Mein Angriff auf dein Zwerchfell Mein Lexikon der Fotografie Mein gereimtes Gesülze

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Danke mapcar,

die Erörterung war sehr informativ !

Wenn auch die zuletzt stehende Erklärung mit den GCs nicht unbedingt auf den ersten Blick zu dechiffrieren ist.
Aber SO WHAT; bleibt letztendlich nur:
! an AutoCad zu apellieren, hier etwas zu unternehmen !
Es zeigt sich, daß der "Elementeeinsatz" quantitativ und bezüglich Arbeitstempo exponentiell steigt, und die Situation, daß unerwünschte 3D-Koordinaten entstehen, alle User vermehrt betreffen wird.
Speziell bei mehrfach geschachtelten Blöcken sind Reparaturen praktikabel nicht mehr durchführbar.
Man denke zB. an einen "3D-verqueren" Herd, der in einem Block "Küche" im "Grundriss A" im "Bauteil Ost" usw. liegt, und Störungen hervorruft.
Dabei wollte man grundsätzlich nur 2D zeichnen.
Den versierten AutoCad-Programmierern sollte es doch leicht gelingen, ein Tool bereitzustellen, welches alle Elemente zumindest bis zu einer gewissen Tiefe von Blockverschachtelungen "plättet". Das derzeitige Stabilisierungswerkzeug in ACAD 2006 (in den Optionen) ist hier nur ein erster, nicht weit genug führender Schritt.

Beste Grüße, And.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP