Nibbels hat geschrieben:... Ich wundere mich nur, warum ein Programm ein derart eckiges Konstrukt exportieren würde - ausser man zwingt es dazu.

Für SketchUp kann man sich denken warum : als es geschaffen wurde war es egal und STLs wurden erst viel später per PlugIn exportiert.
Sehr spät hat man entdeckt, dass ja gerade Architektur-Studenten gerne mal ihre Modelle lieber per 3D-Druck fabrizieren als mit Leim und Pappe.

Aber danke für den Hinweis, dass sich andere Programme damit noch schwerer tun - aus welchem Grund auch immer.
http://www.rf1000.de/viewtopic.php?f=6& ... it=onshape hatte übrigens auch schon zu Tage gefördert, dass man z.B. bei OneShape keine STLs hochladen konnte.
Da fragt man sich doch, warum unfertige Programme zu früh das Licht der Öffentlichkeit suchen, oder?

p.s. : https://1drv.ms/i/s!AhY4t4UjuOcbzz4eWjZXqOZ5l_eY zeigt einen "Kreis" aus (besser gesagt, es ist ein Polygon aus 1079 geraden Linien, weil ich ein Segment gelöscht hatte, um etwas zu demonstrieren) Segmenten in SketchUp. Man möchte nicht glauben, wie sich Softwareentwickler manchmal sträuben, Fehler überhaupt erst einzusehen: https://www.sketchup-forum.de/Thread-ge ... t=workmate

Nur wie gesagt: Google hatte SketchUp nur dafür geschaffen, was heute GoogleEarthPro auf seine Weise liefert : http://goisern-sketchup.npage.de/neuigkeiten.html

Hallo hal4822,

Bezüglich OnShape und STLs:

hal4822 hat geschrieben:Aber danke für den Hinweis, dass sich andere Programme damit noch schwerer tun - aus welchem Grund auch immer.
viewtopic.php?f=6&t=780&hilit=onshape hatte übrigens auch schon zu Tage gefördert, dass man z.B. bei OneShape keine STLs hochladen konnte.

Scheinbar hat sich nach meinem Post doch einiges getan. Im OnShape Blog fand ich diesen Eintrag. Da wird behauptet, dass mittels App der STL Import doch möglich sein sollte.

hal4822 hat geschrieben:Da fragt man sich doch, warum unfertige Programme zu früh das Licht der Öffentlichkeit suchen, oder?

Viele gute CAD Programme unterstützen einen STL Import nicht oder nur halbherzig. Das hat wenig damit zu tun, dass ein Programm unausgereift wäre. Ich stelle mir eher vor, es könnte darum gehen, konsequent zu sein: Man entwickelt ein Programm, dass mathematisch exakt auf hundert-tausendstel Millimeter genau arbeitet, oder noch genauer, und nebenbei noch Daten wie Spezifische Dichte, E-Modul, usw. mitführt, und damit alles nachvollziehbar und berechenbar wird. Und dann sollte man ein Flächengebilde importieren, dass mathematisch nur angenähert ist und keinerlei Hintergrundinformationen enthält, wie etwa Maße, Konstruktionsbedingungen (z.B. 'tangential'), Kreismittelpunkt, Achs- oder Punkteabstand. Da müssen dem Puristen die Haare ja förmlich zu Berge stehen.

Zugegeben, beim Reverse-Engineering kann so ein Vorgehen, das Importieren einer STL, von Vorteil sein. Das habe ich auch schon praktiziert. Aber ein gewisses Verständnis für die fehlende oder stiefmütterliche Behandlung des Dateiformats kann ich aufbringen.

mjh11

rf1k_mjh11 hat geschrieben:... Da müssen dem Puristen die Haare ja förmlich zu Berge stehen.

mjh11

Wie oft ein Programm nur deshalb nicht "vollkommen" ist, weil ein Patentinhaber keine Lizenz erteilt für ein Unterprogramm, das weiß der Himmel. Schon die Gebühren für einen bestimmten "Fortschritts-Balken" sollen enorm gewesen sein.

Mit "unfertig" meine ich am Beispiel des damaligen Onshape, dass die doch gewusst haben müssen, dass das meistverwendete Format im 3D-Druck STL heißt. Sollte in diesem Fall wirklich die Kostenfrage eine Rolle gespielt haben ?

Bei SketchUp bin ich übrigens jetzt auf den Import von *.obj statt *.stl umgestiegen, weil es bei sehr großen Dateien weit schneller ist.
http://goisern-sketchup.npage.de/neuigkeiten.html - diese Neuigkeit gibt´s hier zuerst zu lesen: den STL-Import habe ich nach mehreren Tagen doch abgebrochen.

Hmmh! Ich kann in Onshape sehr wohl STL´s importieren. Leider nützt das aber eigentlich rein gar nichts - zumindest mir nicht.
Die Daten sind da leider nicht verwendbar sondern eher als Eingefärbter Raum "Platzhalter" zu verstehen. Zumindest in meinem Fall.
Ich habe die Front einer NSU Quickly (erwähnte ich, glaub ich, schon) mit Scheinwerferaufnahme gescannt. Super. Leider kommt da dann
genau das Problem auf: Hohlkörper, der Bauchig ist. Ergo ist die innere Struktur der Scheinwerferaufnahme, ab ca. 1 cm tiefe, "zerfetzt".
Somit keine Druckbare Struktur. Ich habe die gescannte Punktwolke zwar als STL exportiert, aber in der Detail-Version wird es ein "Streifen
in die Luft" druck im Slicer. Wenn ich alle Löcher gefüllt abspeicher ist das Problem weg - Allerdings ein neues Problem da: Wie bekomme ich 600 g ABS sinnvoll nach dem Druck wieder abgetragen, ohne die Außenstruktur zu beschädigen, mir die Lungen zu verätzen oder den ein oder anderen Nervenzusammenbruch zu erleiden... Abgesehen von den ca. 36 h unnötiger Druckzeit...
Die Herangehensweise, den Scan mit kleiner Skalieren und Orginal sowie skaliertes von einem Block per boolsche Operationen auszuführen, klappt in CAD-Programmen gar nicht mit solchen Teilen. Bei Meshmixer oder MAYA oder Freecad schon eher, aber bei so komplexen Teilen ist auch das vorbei.
Also in Onshape importiert und die Außenkontur ausgerichtet und nachgezeichnet. Geht? Jaein. Arbeiten sieht anders aus! Allein das Ausrichten wird schon zu einer Geduldsprobe. Es sind ja keine exakten CAD-Daten, Es ist eine in Polygondreiecke konvertierte Punktwolke bestehend aus zigtausenden Polygonen, die mühsam Punkt für Punkt berechnet werden muß. Da bekommt man (bei dem Zylinder vermutlich noch nicht, aber sehr wohl bei komplexeren Teilen) sehr schnell die Grenzen aufgezeigt. Vernünftig arbeiten ist da nicht mehr... Ich mach es daher derzeit so, dass ich mir aus meinem Scan immer noch Profilstreifen exportiere und diese dann ins CAD importiere. Das ist schon zäh genug, aber wenigsten kann ich da beim drehen nur einen Tee kochen und nicht gleich Mittagessen und Abendessen...
Wenn ich mir die Probleme und die Auswirkungen anschaue, verstehe ich relativ schnell, warum da nicht konsequent dran gearbeitet wird. Ist einfach eine andere Welt, die mit CAD nicht viel gemein hat. Lizenzgebühren dürften da auch eine Rolle spielen, aber vermutlich auch der kosten- nutzen...
Bei Catia soll es recht gut funktionieren, aber bin ich bereit zigtausend für eine Lizenz, die dann auch nur für ein Jahr gilt, auszugeben?
Mir ist das too much, aber das muß jeder für sich abwägen.

Aber die Diskussion hat ja eigentlich auch nichts mehr mit dem dem Problem des unerkannten Zylinders an sich zu tun, oder? Was ich beobachten konnte, ist, dass Onshape "Wasserdichte" STL´s generiert (zumindest bisher). Bei Designcad und anderen ist das nicht der Fall und erfordert eine Nachbearbeitung selbiger um die Fehler zu korrigieren.

Gruß, Christian

Wenn man in Blender die Meshes zu reinen Dreiecken macht, kann man das Objekt in FreeCAD sauber importieren. Und nonmanifold sollte das Objekt auch nicht sein: Wenn man 5+Ecke oder sowas in der STL hat, klappt das eher nicht oder mit Löchern, wenn man das in FreeCAD lädt.
Anschließend kann man das 3Eck-Gebilde in FreeCAD von einem Mesh zu einem Part konvertieren.
Das habe ich als STEP exportiert.
Das in Onshape importiert.
Damit kann man wie gewohnt in Onshape arbeiten. Natürlich ist Ändern dann nicht so einfach.

LG

Digibike hat geschrieben:Hmmh! Ich kann in Onshape sehr wohl STL´s importieren.
Gruß, Christian

Wenn du richtig lesen würdest, dann wüsstest du auch, dass das jetzt jeder kann. Es war offensichtlich von dem ursprünglichen Onshape die Rede. Sollte auch am Datum des Threads erkennbar sein.

Ansonsten gilt: wem nicht zu raten ist, dem ist auch nicht zu helfen. Selbstverständlich verstehe ich, wenn jemand 3500 € zum Fenster für einen Scanner rausgeworfen hat, dass derjenige dann auch die vom Hersteller versprochenen Erfolge haben will

ganz wie du meinst...

Digibike hat geschrieben:ganz wie du meinst...

mjh11 begrüßte schon einige Posts (#12) vor mir diese Funktionserweiterung in OnShape. Auch nicht sinnerfassend gelesen ?

p.s.: Damit ich jetzt nicht verdächtigt werde hier gratis Werbung für Agisoft PhotoScan zu machen: es gibt andere Software, die das vielleicht auch kann (z.B. "123 catch" von AutoCAD, das aber inzwischen wohl in TinkerCAD integriert wurde).

Steht ja jedem frei hier darüber zu berichten - selbstverständlich auch wenn es nur Misserfolge sind. Ich finde meine Erfolge halt interessanter.

http://www.tecnetinc.com/Onshape%20-%20 ... Over!.html sollte vielleicht auch zu denken geben. So verlockend es sicher ab einer gewissen Dateigröße ist, auf die Leistung von Großrechnern zugreifen zu können - warum sollten die das auf Dauer gratis machen?

rf1k_mjh11 hat geschrieben:... Aber ein gewisses Verständnis für die fehlende oder stiefmütterliche Behandlung des Dateiformats kann ich aufbringen.

mjh11

https://service.netfabb.com/service.php ist garnicht so stiefmütterlich. Den Begriff "nicht wasserdicht" und seine Variationen kennt wohl jeder schon. Leider ist es nicht immer das gewünschte Ergebnis, wenn man eins der diversen Reparatur-Programme nutzt. Wo eines scheitert kann ein anderes ein brauchbares Ergebnis liefern - man muss es halt ausprobieren. Leider akzeptiert der netfabb-Online-Reparaturdienst nur Dateien bis 100 Megabyte. Das sind aber schon eine Menge Polygone ! Anbei ein per GoogleEarthPro und PhotoScan und vom genannten Dienst recht schnell druckbar gemachtes STL von der Festung HohenSalzburg - ursprünglich ca. 37 Mb groß und jetzt natürlich etwas größer.

Deshalb hier also nur ein Bild, aber bei Interesse kann ich das Ding ja via ONE-Drive oder DropBox hier zur Verfügung stellen. Vor einiger Zeit klagte hier mal wer darüber, dass sein teuer erworbenes Automodell nicht druckbar sei. Das war für den MeshMixer ein leichtes Spiel, dem Auto eine Innenhaut zu geben und es so "wasserdicht" bzw. es zu einem "Volumenkörper" zu machen:

Völlig klar, wenn so eine Autoreparatur "das kann" was sie tun soll und nicht das Ergebnis in einer Art und Weise verfälscht wie ich das überhaupt nicht wollte: OK.

Aber in der Vergangenheit war das zumindest bei meinen Problemen nicht immer mit Erfolg gekrönt.
Viel hängt tatsächlich von der Quelle der STL ab.
Wenn ich zwei Objekte ineinandergeschoben als STL exportiere ist einfach nicht in jedem Fall klar, ob der Nutzer innen die Schnittmenge als Loch haben will oder aufgefüllt. Manchmal klappt das ganz gut, ein anderes mal nicht. Und wenn einmal ein Programm drübergelaufen ist, das keine 5-Eck-Flächen versteht, hat man ein völlig zerlöchertes Modell. Wenn das dann versucht per Automatik Löcher zu schließen landet man völlig im Chaos. Ich hatte mal ein wunderschönes Modell und am Ende war überhaupt nichts mehr so wie ich es geplant hatte.

Mich nervt sowas!

Darum schaue ich mir heute in den Fällen nur noch das Netz in Blender an, lasse das Modell in echte Dreiecke zerlegen und stopfe per Suche die verbliebenen Löcher genau so wie ich es haben will.

Nun ...
Zu dem Burg-Modell:
Ich finds schon cool, dass man sowas selbst per Bilder und Drohne scannen kann. Aber ich wäre als Kind mit der Detailtreue der Burg überhaupt nicht zufrieden gewesen. Als Abbildung der Landschaft evtl. cool, wenn oben ne Fläche wäre, die man selbst mit Lego bebauen könnte, aber:

- Keine echten Zinnen
- Keine gute Abbildung der Fenster und Schießscharten
- Burgtore vermutlich verschlammt
- Zum Zinnsoldaten reinstellen völlig ungeeignet


LG