CAD Software mit .Net + GDI+

  • C#
  • .NET (FX) 4.5–4.8

Es gibt 33 Antworten in diesem Thema. Der letzte Beitrag () ist von Niko Ortner.

    .NET Code ist ​Managed Code, C++ ist Unmanaged Code. ​Managed Code ist langsamer als Unmanaged Code. CAD-Anwendungen müssen ​flüssig und stabil laufen. Klar kann man simple CAD-Anwendungen in .NET machen, ich meinte nur große CAD-Anwendungen.
    Vollzitat entfernt. ~Trade
    Do Until Nothing IsNot Nothing
    Console.WriteLine("Viel Spaß dabei, mit diesen Code deine Zeit zu verschwenden, und zwar für immer!")
    Loop

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Trade“ ()

    ​Kilobyte schrieb:

    Ja, aber Unity ist eine Game-Engine, keine Anwendungs-Engine.
    Ich hab ja auch nicht gesagt, dass der TE Unity für seine CAD-Software verwenden soll.
    Im Zweifel kann man immer DirectX (SharpDX) direkt hernehmen und sich alle Funktionen, die man benötigt, selber basteln. Wenn man weiß, was man tut, ist das sowieso die effizienteste Methode.

    ​Kilobyte schrieb:

    .NET Code ist ​Managed Code, C++ ist Unmanaged Code.

    Weißt du auch was dieser Satz bedeutet? Ein CAD ist nicht zwangsläufig ein Programm, das den letzten Tropfen CPU Leistung raus quetscht. Wenn du dich auf Rendering beziehst, so läuft dies in den exakt gleichen Routinen ab wie in jedem anderen C++ Programm. Das heißt, das Rendering ist genauso hoch optimiert wie überall. Und alles andere ist selten soo performancekritisch als, dass es darauf ankommt. Und nur nebenbei bemerkt ist C++ auch nicht der Garant für Performance. Bsp. manche Klassen C++ Standardbibliotheken sind auch nicht sonderlich performant implementiert und sind sogar langsamer als .NET Implementierungen. So schneidet .NET in manchen Benchmarks sogar besser ab. Klar ist .NET im allgemeinen langsamer, aber glaube nicht, dass du damit das x Fache an Performance raus holst.


    Opensource Audio-Bibliothek auf github: KLICK, im Showroom oder auf NuGet.
    Von der Performance her könntest du sogar in Java ein CAD-Programm schreiben, denn die Objekte müssen ja nur berechnet werden. Gerendert wird ja sowieso auf der GPU, und die Berechnungen wird der Prozessor ja hoffentlich noch schaffen. Und falls nicht kann man im Notfall immer noch auf OpenCL / ComputeShader o.ä. zurückgreifen...
    Jo, da könnt ihr glaub noch bis nächstes Jahr über ungelegte Eier debattieren.
    Niemand von euch wird eine CAD-Anwendung schreiben, weil das ist einfach zu anspruchsvoll.
    Ich zumindest hab nicht den Ansatz einer Idee, in welcher Form man beliebige dreidimensionale Körper modelliert, dass man die darstellen, zoomen/drehen/bewegen, zusammenfügen, bemassen und abspeichern kann.
    Und das ist nur eines der Probleme.
    CAD-Anwendungen können glaub nur von hochqualifizierten Experten-Teams geschrieben werden, über Monate und Jahre hinweg, in Vollzeit.

    ​Kilobyte schrieb:

    .NET Code ist ​Managed Code, C++ ist Unmanaged Code. Managed Code ist langsamer als Unmanaged Code
    Das ist nicht richtig. Tatsächlich kann ein .NET-Programm sogar schneller sein, als ein äquivalentes C++-Programm. Und zwar aus dem Grund, dass die .NET-Laufzeitumgebung den IL-Code vor der Ausführung in nativen Code übersetzt, und zwar optimiert auf die aktuelle Plattform.

    ​Kilobyte schrieb:

    CAD-Anwendungen müssen ​flüssig und stabil laufen
    Eben - da bist du mit .NET besser dran. Schon allein aus dem Grund, dass du in C++ sehr einfach Stabilitätsprobleme einbauen kannst. In .NET ist es doch schwieriger, die Stabilität nachhaltig zu stören.

    ErfinderDesRades schrieb:

    Niemand von euch wird eine CAD-Anwendung schreiben, weil das ist einfach zu anspruchsvoll
    Och, so kompliziert ist das gar nicht. Klar, man muss einiges an Denkleistung in die Datenhaltung investieren, aber das ist hinterher auch nur ein Datenmodell, wie jedes andere auch.

    ErfinderDesRades schrieb:

    Ich zumindest hab nicht den Ansatz einer Idee, in welcher Form man beliebige dreidimensionale Körper modelliert, dass man die darstellen, zoomen/drehen/bewegen, zusammenfügen, bemassen und abspeichern kann.
    Die Modellierung läuft, nach meinem Kenntnisstand über NURBS. Dann muss man nur noch Kontrollpunkte verschieben und die veränderten Bereiche neu in Dreiecke (zur Darstellung) überführen. Zoomen, drehen, bewegen lässt sich in der Darstellung einfach durch Matrizen implementieren. Im Backing setzt du halt einfach die entsprechenden Parameter. Fürs Zusammenfügen habe ich jetzt auf die schnelle tatsächlich keine Idee, lösbar ist das aber trotzdem. Das ist ja nur etwas Mathe, außerdem haben das andere auch hinbekommen. Bemaßen ist dann auch einfach über NURBS möglich. Durch Senden eines Strahl in Klickrichtung kann man bspw. den Start- und Endpunkt bestimmen. Dann beschränkt sich das Problem nur noch auf das Lösen von Gleichungen. Das Abspeichern ist, wenn ein Datenmodell vorhanden ist, auch kein Problem. Man hat Objekte, die bestimmte Parameter besitzen (z. B. Position, Drehung, Kontrollpunkte). Die kann man dann einfach wegschreiben.

    Ja, ein CAD zu entwickeln ist wahrscheinlich die Königsdisziplin, aber unmöglich ist das auch nicht. Das ist ja schließlich auch nur ein Programm.
    Mit freundlichen Grüßen,
    Thunderbolt
    @thefiloe Ich hab ja auch nicht gesagt, das alle .NET Anwendungen so langsam sind. Ich meinte auch damit, dass C++ die beste Programmiersprache für CAD-Anwendungen ist, weil man da natürlich mehr machen kann.

    ​@Thunderbolt Ja, da hast du recht.
    Do Until Nothing IsNot Nothing
    Console.WriteLine("Viel Spaß dabei, mit diesen Code deine Zeit zu verschwenden, und zwar für immer!")
    Loop

    ​Kilobyte schrieb:

    weil man da natürlich mehr machen kann.

    Du kannst a) mehr gravierende Fehler machen und b) vieles kannst du nur mit dem x-fachen Aufwand machen. Aber ja, wenn du alles richtig machst und genug Ressourcen einplanst, kannst du wahrscheinlich mehr machen.


    Opensource Audio-Bibliothek auf github: KLICK, im Showroom oder auf NuGet.
    C++ kann sprachlich natürlich deutlich mehr (architektonisch wenn man so will), dass interessiert eine Anwendung aber nicht. Ein CAD-Programm tuckert in .Net genauso fluffig. Abgesehen davon sind so native COM Zugriffe und C APIs immer eklig und man kommt nicht drumrum.
    @'Kilobyte'
    Du scheinst ziemlich überzeugt davon zu sein, dass .NET für CAD-Anwendungen ungeeignet ist. Kannst Du das auch mit empirischen Daten belegen?
    Ich bin der Meinung, das geht sogar ganz gut. Und meine empirischen Daten sind folgende:

    Ich habe ein paar alte SolidWorks-Modelle zu XAML exportiert. (Muss man sich mal auf der Zunge zergehen lassen: SolidWorks kann von Haus aus zu XAML-Dateien exportieren. Krass!)
    Den Inhalt (ein Viewport3D-Objekt mit Kamera und ModelVisual3D-Objekten) kann man einfach in eine leere WPF-Anwendung kopieren, oder wie ich es gemacht habe, per XamlReader zur Laufzeit laden:

    Sieht doch gut aus. Die Kamera lässt sich (mit der richtigen Mathematik) flüssig verschieben. Wäre auch komisch, wenns da schon ruckeln würde. WPF rendert auf der Grafikkarte und bei so kleinen Modellen darf da nichts ruckeln!

    Im Gegenteil: Ruckeln fängt's erst bei extrem krassen Situationen an. Ich hab hier so eine OBJ-Datei herumliegen, die ein Modell eines kleinen Raumschiffs/Düsenjets beinhaltet. Es besteht aus 1708 Vertices und 2286 Dreieckigen Flächen. Das hab ich hier 1000 Mal in unterschiedlichen Positionen und Rotationen einen Viewport geworfen:

    Die Kamera läuft immer noch flüssig. Bei 2000 Raumschiffen merkt man langsam, dass die Framerate sinkt. Also das müssen schon ziemlich große Modelle sein, dass man da an die Grenzen stößt.
    Die Projektmappe habe ich übrigens gezippt und angehängt. Probier's aus.

    Und um der Sache noch einen draufzusetzen: Ich weiß nicht mehr wo ich diese ganzen Demoprojekte her habe, aber irgendwo habe ich ein Archiv mit einigen Projekten zu 3D in WPF gefunden. Darunter ist ein nettes Programm, in dem man diverse Dinge auf einem "Bildschirm" anzeigen kann, der im 3-dimensionalen Raum schwebt. Man kann auf den Bildschirm klicken, dann wippt er so hin und her. Und man kann diverse Videoeffekte drüber legen.

    Läuft ebenfalls einwandfrei.

    Also rendern ist in .NET gar kein Problem! Der Rest ist Mathematik und ein anständiges Datenmodell. Und das geht sowohl in .NET, als auch in C++. Vielleicht holst Du bei komplexen Berechnungen wie diesen hier etwas mehr Performance raus und die Berechnung dauert nur 190 ms anstelle von 200 ms:

    Das ist ein kreisförmiger Schnitt durch einen Körper.

    Aber hier ist es wichtiger, dass man ein robustes Datenmodell hat, das möglichst einfach zu verwenden ist, und dass der Code, den man schreibt, einigermaßen gut lesbar und verständlich ist. Optimierung ist da eher zweitrangig und wahrscheinlich auch gar nicht nötig. Denn Optimierung geht meistens auf Kosten der Lesbarkeit.
    Ich gehe hier sogar so weit, zu sagen, dass man ein solches Datenmodell in .NET verständlicher und logischer hinbekommt, als in C++, denn C++ ist kompliziert! (Siehe dazu die Videos von Jonathan Blow.)

    Also bitte: Warum nochmal soll .NET nicht gut für CAD-Anwendungen geeignet sein?
    Dateien
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Niko Ortner schrieb:

    Ich hab hier so eine OBJ-Datei herumliegen, die ein Modell eines kleinen Raumschiffs/Düsenjets beinhaltet
    Für mich sieht das ziemlich stark nach nem A-Wing aus StarWars aus warum die Bescheidenheit? :P

    Niko Ortner schrieb:

    Es besteht aus 1708 Vertices und 2286 Dreieckigen Flächen.

    Niko Ortner schrieb:

    Bei 2000 Raumschiffen merkt man langsam, dass die Framerate sinkt.

    ​das wären über 4 Millionen Dreiecke, was, so glaube ich zumindest, nach wie vor mehr ist, als eine durchschnittliche Spielszene in AAA Titeln. schön zuwissen, dass man so viel Power hinter 'ner Gui hat :D

    EaranMaleasi schrieb:

    warum die Bescheidenheit?

    Ich kenn mich mit StarWars nicht aus und ich weiß auch nicht mehr, wo ich die Datei her hab ;)
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils