Fusion will nicht fusionieren

[microelly2]

Nochmal zu dem scharnier

ich hab das jetzt mal ohne tangentialübergang gebaut
erst ein quadrat -> quader
dann kreis -> zylinder und dann kreis -> Loch
sketches schrittweise aufgestapelt
das geht auch

die fusion ist bei mir diesmal fehlerfrei

[SIG]

Hallo.

Na da haben die Programmierer aber noch Arbeit!
Es funktioniert, wenn
1. das Sketch der Lochplatte an die Achse gezeichnet und dann das entstandene Pad verschoben wird, UND
2. die fusionierten Kegel (Fusion von Senker1_1 und Senker1_2 und Senkerweg1) nacheinander subtrahiert werden.
!?! Hallo Programmierer! Das ist ein einfaches Teil! So geht das doch nicht!

Warum steigt das Programm aus, wenn zwei simple Teile miteinander fusioniert werden oder das Sketch der Platte nicht an der Achse liegt? Wem nützt der Programmieraufwand, wenn hier nicht ordentlich programmiert und verifiziert wird?
Ich will keinem zu nahe treten, aber was nicht geht das geht einfach nicht. Da geb ich lieber einen 4-stelligen Betrag aus für ein Programm was auch ein effizientes Tool ist, weil es das einfach sein muß!
Wenn das nicht besser wird sehe ich absolut schwarz für FreeCAD.

Und da war danoch Menü / Werkzeuge / Bildinhalt speichern:
Wenn ein Punkt im Namen steckt wird nicht gespeichert.
Gebe ich ".gif" am Ende mit an funktioniert es.
Da wundere ich mich schon ein bischen...

Mal nebenbei:
Was ich auch nicht verstehe ist, daß in Dateien die zig Nullen als Nachkommastellen geschrieben werden.
Gleiches gilt für die zig #,99999999 oder #,#99999999.

irgendwann treten wir auf die Bremse beim Auto und es passiert nix.
Wie haben wir es eigenlich zum Mond geschafft?
Entschuldigung, aber das mußte ich mal loswerden.

[shoogen]

!?! Hallo Programmierer! Das ist ein einfaches Teil! So geht das doch nicht!

Hallo SIG.
Machs doch besser.

Wie haben wir es eigenlich zum Mond geschafft?

Dadurch konstruktive Kritik, durch Gemecker und Schwarzsehen anzureichern bestimmt nicht.

[shoogen]

Was ich auch nicht verstehe ist, daß in Dateien die zig Nullen als Nachkommastellen geschrieben werden.

Es handelt sich um Gleitkommazahlen, die im Binärsystem verarbeitet werden. Die sind nicht schön im Zehnersystem darzustellen. Und man sollte sie keinesfalls runden.
Ich würde die viel lieber als hexfloats (im XML) speichern. Das macht die für Menschen zwar nahezu unlesbar, aber es führt jedem vor Augen, dass es sich um eine Gleitkommazahl handelt.

Code: Select all

> float.fromhex('0x1.fffffffffffffp-1')
0.9999999999999999
> 0.66666.hex()
'0x1.555475a31a4bep-1'

EDIT: Der Trick bei Gleitkommazahlen ist es die "schönste" Darstellung im Zehnersystem zu ermitteln, die unter Anwendung der Umwandlungsregeln von IEEE754 wieder die Ursrprüngliche Gleitkommazahl (im Binärsystem) wiederherstellt.
Ich hab bei meinem exportDRAWEXE.py Project damit experiementiert, zu erkennen, wenn eine Zahl im Dezimalsystem gerundet worden ist.
Mein Fazit: Das lohnt alles nicht und schafft nur neue Fehlerquellen. Einfach 20 Dezimalstellen ausgeben. Die Zahl der signifikaten Stellen nachzuhalten, bleibt dem Ingeniuer überlassen

[SIG]

Hallo,

natürlich mach ich's besser, aber in anderen Dingen. ;-D
(Nicht gleich auf den Schlips getreten fühlen!)

Ich sehe es durchaus als konstruktive Kritik an, hier meine Erfahrungen aus Sicht eines Anwenders kund zu tun, auch wenn's weh tut. Kritik ist der Antrieb für Verbesserungen. Natürlich weiß ich auch nicht alles, aber wenn doch ein so einfaches Teil mit einfachsten boolschen Operationen schon nicht funktioniert ist das nunmal inaktzeptabel. Was implementiert ist muß funktionieren! Gerade weil FreeCAD noch im Entwicklungsstadium ist und Programmierer daran arbeiten investiere ich doch mein teuerstes Gut: Meine Zeit!
Also nicht gleich in die Luft gehen (Suche HB-Männchen als Video...).

Also das mit den Gleitkommazahlen ist mir ja schon ein Dorn im Auge; Dir (shoogen) ja offensichtlich auch.
Wenn ich mal rechne komme ich bei 2E64 auf 1,844674407371E019, also 19 Nachkommastellen das dürfte ja an Genauigkeit reichen, aber eben nur real. Wenn z. B. von 32 Bit auf 64 und irgendwann mal auf 128 Bit umgestellt wird ist die "Rundungslösung" genauer. - Programmierer haben es eben auch nicht leicht.

Nur damit ich nicht mißverstanden werde: Ich halte von dem Ansatz und dem Konzept von FreeCAD sehr viel, aber wie gesagt habe ich (leider) auch den Eindruck, daß hier mal Kritik angebracht ist. Wenn ich hier falsch liege kann mir gerne jemand erklären wieso boolsche Operationen nicht funktionieren.

[shoogen]

Wenn ich hier falsch liege kann mir gerne jemand erklären wieso boolsche Operationen nicht funktionieren.

Gerade bei Booleans hat unser Modelierkern Schwächen. Aber kaum jemand von uns hier hat das Know-how oder die Zeit zur Entwicklung von OpenCASCADE Technology beizutragen. Und die Boolschen Operationen wurden in den letzten Jahren merklich verbessert.
Es macht für uns aber keinen Sinn irgendwelche Details zu testen, die wir eh nicht beheben können. Für mich ist die Konsequenz einfach: FreeCAD ist noch nicht bereit für die Version 1.0. Aber deswegen können wir nicht aufhören Versionen rauszugeben.
Bei Problemen mit Booleans ist daher die erste Frage ob es ein Bug in FreeCAD ist, oder ob sich das Problem ausserhalb von FreeCAD (nur mit OCCT) reproduzieren läßt. Im ersten Fall sollte ein Ticket in unseren Bugtracker angelegt werden.
Im letzterem Fall im Bugtracker von OCCT.

Ja, man kann Baum- und Kombo-Ansicht gleichzeitig aktivieren. Kann man aber auch sein lassen.
FreeCAD sollte (ausser bei Points, Meshes und den Szenengraph) mit doppelter Genauigkeit (64-bit) arbeiten. Die Zahlen der Dezimalstellen in den Spinboxen muss man dann eventuell eröhen.
Vierfach genaue Gleitkommazahlen lösen das Problem nicht. Stattdessen brauche ich für diese mindestens 35 Dezimalstellen.
Neben der numersichen Genauigkeit die Gleitkommaoperationen, gibt es Übrigens auch Genauigkeiten für das Model.
Die Position im Raum oder die Rotation zu runden, ist eine großartige Möglichkeit sich sein Model subtil kaputt zu machen.
Die Boolschen operationen entscheiden dann nicht stabil auf Berührung oder Überscheidung und liefern ein Fehlerhaftes Ergebnis. (Beispiel: http://tracker.dev.opencascade.org/view.php?id=24678)