PartDesign Body - Mehrere Teile technisch unmöglich?

[roerich_64]

Das sind alles einfache Teile.

Ja, und????

Nur weil es für dich scheinbar einfache Teile sind, brauchst du hier nicht so rumzutönen!
Denn du weißt nicht, was wir mit so scheinbar einfachen Teilen alles machen...

Ja, Wilfried. Das war wieder mal voll daneben.

VG
Walter

[freecad-heini-1]

Das gehört in der Form nicht hierher. Ich habe Dir eine PN geschrieben.

[usbhub]

Nachdem sich Wilfried und Walter hoffentlich wieder geeinigt haben, nochmal zurück zur Frage:

Mir geht nicht um den Sinn oder Unsinn der Beschränkung, sondern um die technische Ursache. Ist es eine absichtliche Beschränkung, die man relativ leicht entfernen könnte oder ist es by-design so?

[chrisb]

realthunder arbeitet an einer Lösung, daher gehe ich davon aus, dass es technisch machbar, aber nicht trivial ist. Früher ging das manchmal, d.h. ein erstes Aufpolstern funktionierte beim Hinzufügen weiterer Features verschwand dann aber manchmal ein Teil wieder. Inzwischen ist es konsistent: es geht einfach nicht.

[roerich_64]

Hi,

Hmm bin der Meinung, das bevor etwas in dieser Richtung geändert wird,
sollte das Problem 'TopoNaming' angegangen werden, denn was einem tagtäglich damit alles so um die Ohren fliegt...

Das fängt schon alleine beim Sketcher an, wenn man Sketches auf Sketche referenzieren will...

VG
Walter

[chrisb]

Diese beiden Probleme sind von ihrer Komplexität her überhaupt nicht vergleichbar. Und dass das Toponaming seit Jahren auf der GröPaz-Skala (größtes Problem aller Zeiten) ganz oben steht, ist auch klar.

Ich erhoffe mir zwar einige Verbesserungen, aber die Erwartungen dürfen auch nicht überzogen sein. Mir ist nicht klar, ob es das Topologische Namensproblem überhaupt gibt. Mit geeigneten Heuristiken wird es sicherlich eine deutliche Verbesserung geben, aber es kann aus prinzipiellen Überlegungen heraus nicht in allen Fällen das herauskommen, was irgendein Nutzer erwartet hat.

[chrisb]

Hier mal ein Beispiel das nicht gehen wird:
Stell Dir vor Du hast einen Würfel. An der oberen Seite ist ein kleiner Würfel angeheftet. Es könnte ein Haus mit Flachdach und einem Schornstein werden.

Snip macro screenshot-3962f4.png (3.37 KiB) Viewed 754 times

Jetzt ändere ich das Dach zu einem Satteldach. Was momentan dabei herauskommt ist sicherlich für niemanden richtig ...

Snip macro screenshot-2da123.png (3.21 KiB) Viewed 754 times

... aber wie soll ein Programm entscheiden, auf welcher der beiden Flächen der Schornstein jetzt sitzen soll? Ich will ihn auf jeden Fall auf der anderen Seite haben, egal wo er ist!

[roerich_64]

Hmm, Chris.

Bin nicht der Meinung, das man das 'Schornstein auf den Satteldach' -Beispiel in den Karton mit 'topological Naming' oder dem der 'Bodys' werfen sollte, da 'Dach' und 'Schornstein' in meinen Augen verschiedene Baugruppen sind...

Beispiel:
- Ein glattes,quadratisches Blech mit Bohrungen deren Abstände an dem Grundblech referenziert wurden.
- Man fügt zwei Kanten eine Aufkantung hinzu.

Und man entdeckt, das in dem Grundblech eine Bohrung fehlt. Fügt man die dem Blech hinzu... -> peng
Die Abkantungen sind 'durch den Wind'...

und das sind nur ein paar Schritte innerhalb eines Bodys...

Ein Blech in der Fertigung heute wird meistens per Laser geschnitten und dann gekantet.

Ich weiß, es gibt meistens ein 'Workaround' und ich wende diese auch an.

Und: das toponaming Problem ist vorhanden. Denn wie sonst hängt eine Aufkantung nach dem Einfügen eines Loches in dem Basisblech auf einmal an eine andere Kante?

[freecad-heini-1]

Realthunders Topo Naming Lösung ist deutlich besser als gar keine Lösung, auch wenn sie noch nicht an Creo heran reicht. Das wäre ein großer Fortschritt für Freecad. Hoffentlich kommt das mit Freecad 0.20.

Ich möchte nochmal auf die Ein-Solid-Regel zurück kommen. Auch die hat Realthunder in seiner Branch aufgehoben. Sie beschränkt Konstrukteure in ihrer gestalterischen Freiheit. Das braucht kein Mensch, außer Konstrukteure, die einfache Teile konstruieren, für die ein Tinkercad ausreichend wäre.

Nehmen wir dieses Beispiel, eine Ansaugbrücke:

ansaugbruecke.png (53.2 KiB) Viewed 720 times

Gegeben sind die drei Anschlussflansche, den Rest muss der Produktentwickler erst noch entwickeln.

Am Ende soll es so aussehen:

D.h. es wird einmal ein zusammenhängender Solid.

Warum nimmt man den Konstrukteuren die Möglichkeit so zu arbeiten, dass man zuerst mit den gegebenen Geometrien beginnt und dann den Rest entwickelt? Für mich ist die Ein-Solid-Regel eine unnötige Beschränkung.

[chrisb]

Bin nicht der Meinung, das man das 'Schornstein auf den Satteldach' -Beispiel in den Karton mit 'topological Naming' oder dem der 'Bodys' werfen sollte, da 'Dach' und 'Schornstein' in meinen Augen verschiedene Baugruppen sind...

Das ist aber ein recht trauriger Einwand; darum ging es doch überhaupt nicht! Häuser haben auch Fenster und Türen, aber darum ging es auch nicht. Es ging auch nicht um ein weiteres Beispiel bei dem das Toponaming zuschlägt, davon habe ich hunderte gesehen! Es ging darum, dass es Fälle gibt, die sich nicht automatisch lösen lassen. In keinem System.

Stell Dir also einfach ein Modellhaus vor, bei dem der Schornstein am Dach dran sein soll. Oder stell Dir statt des Polsters eine Tasche für den Ausschnitt des Schornsteins vor. Oder stell Dir einfach nichts weiter vor sondern nimm es als zwei Features und weiter nichts.