3D - GCode Viewer

[DaCoda]

Ich bin nun inzwischen etwas weiter gekommen, nachdem ich auf extra 3D-Bibliotheken verzichte und es mit GDI optional mit GDI+ (Siehe im Abschnitt USES) selber mache.
Im Anhang ist mein erster "Prototyp" so als Testprogramm beigefügt, komplett mit 3 Test-NC-Dateien.

Es gibt aber noch Verbesserungsmöglichkeiten, Vereinfachungen usw.

vielleicht hat ja jemand Lust was dazu zu sagen, oder sogar Tips / Verbesserungen dazu.

DANKE!

[Rollo62]

Hallo DaCoda,
ich weiss jetzt nicht was Du vorher mit 3D Bibliotheken gemacht hast.

Es ist meiner Meinung nach eine gute Übung das Alles von Hand selber zu machen, mit Canvas in eine Paintbox malen,
aber ob es die effektivest Lösung ist, vage ich mal zu bezweifeln.

Ich würde statt Paintbox und Canvas lieber TImage32 nehmen, das kann so ziemlich viele zusätzliche Dinge,
Out-of-the-box, z.B. auch SVG, Layer und Skia sollten auch machbar sein.
https://angusj.com/image32/Docs/_Body.htm

Wie gesagt, wenn Du dich bewusst dazu entschieden hast, OK, aber moderner und flexibler wärst Du womöglich damit.

[DaCoda]

Hallo Rollo,
ok das schaue ich mir mal an. Noch bin ich nicht 100% festgelegt, ich teste gerade noch und "übe"
Später soll das ja in mein CNC-Programm integriert werden und das alte 2D-View darin ersetzen.

[Sinspin]

Uuuui, Du willst aus den 2D Schichten wieder 3D machen?

Wenn ich mir den Output von Cura ansehe, dann kann ich dir da nur viel Spass wünschen.
Ich verstehe schon warum das hinterher nur noch 2D angezeigt wird. Selbst Cura convertiert das hinterher nicht wieder in ein 3D Modell wenn man mal eine Datei damit aufmacht.

PS, Du kannst dir mal OctoPrint ansehen, da gibt es auch Möglichkeiten zur GCode Anzeige. Soweit ich weis aber auch nix was 3D anzeigt.

[DaCoda]

Hallo SinSpin,
das war mal ein Tip, hab das direkt ausprobiert mit der Angehängten NC-Datei...

Und siehe da, ich musste erst mal etwas Kaffee trinken

Dieser Weg ist wohl der nächste Holzweg. Ich muss das irgendwie mit GLScene oder Sonstwas machen. Nun bin ich wieder bei Null...

[Sinspin]

Manche Slicer kommentieren den GCode ja. So dass man in Cura oder im OctoPrint für jede Schicht anzeigen kann was gerade für ein Typ von Linie / Action verarbeitet wird. Das ist ja aber nicht Pflicht und hilft auch nicht beim übereinander legen.
Aber, Schicht für Schicht lässt sich ja identifizieren und Zeichnen.
Wenn man die Schichten übereinander legt kann man herausfinden wo sich Linien von einer zur nächsten Schicht sehr nahe kommen.
Das tritt innen auf wo einfach Material weg gefräßt wird (oder Füllmaterial gedruckt wird) Ich denke bei einer Fräße sind das schöne gerade Linien. Beim Drucker wird innen oft chaos angerichtet.

Ich denke nicht dass Du da irgendwas mit 3D Komponenten brauchst. Zeichne erstmal alle Schichten und lege sie übereinander wobei deine Zeichenfläche durchsichtig ist und weiter nach "oben" jeweils auch nach oben und links verschoben wird. Das ergibt 3D ohne eine 3D-Komponente.
Dann Spiele mit etwas mit den Abstand der Verschiebung zwischen den Schichten um den effekt zu sehen.


....Wobei, das ginge auch mit OGL, Rahmen die mit den Schichten als Textur bespannt sind.

[Kas Ob.]

The math looks of the projection sound and correct, didn't check line by line but one small mistake will not render correct, also it is fine and clean (impressive to be honest).

Now to the point about TPaintBox or not, i always like and prefer TPaintBox, it is the most lightweight control to draw for such use, the portability is ensured as you only handle its TCanvas, so moving the code to draw may on a TPanel is merely changing one line.

Suggestions :
1) Refactor this rendered into its own class, such class might accept a Canvas as input, or even better it will create own Canvas, of course you can use TBitmap but TBitmap suffer from some un-needed overhead handling, (too many API to OS DIB...etc), in general TCanvas is faster, by having its own class you can have something like folder view that generates thumbnails to browse folder of projects.
2) Separating the logic (in this case the rendered) from the form will allow you utilize threads for heavy projects, also will great enhance maintainability of the code.
3) When you refactor it you can have your own ViewPort (and its dimensions) similar to Direct2D or HTML rendered..., meaning you are free to work on UI to enhance mouse control the view like dragging by mouse right click and zoom by mouse wheel... , reset to center button ...
4) In general handling TFormatSettings is very slow, i mean really slow, because it is big structure that involves many system functions, replacing TFormatSettings.Invariant to be called once does enhance the performance.

Delphi-Quellcode:

..
  private
    FSegs: TList<TSegment>;
    XOffset: Integer;
    YOffset: Integer;
    FAngX, FAngY, FAngZ: Double;
    FScale: Double;
    FLastPos: TPoint;
    FRotating: Boolean;
    FInvariantFS: TFormatSettings;              // <---
    procedure LoadGCode(const AFile: string);
    function Project(const V: TVec3): TPoint;
    procedure AutoFit;
..
procedure TfrmGCodeViewer.FormCreate(Sender: TObject);
begin
  FInvariantFS := TFormatSettings.Invariant;
  DoubleBuffered := True;
..
  function ExtractFloat(tag: Char; const s: string; var v: Double): Boolean;
  var
    p, j: Integer;
    num: string;
    //FS: TFormatSettings;
  begin
..
    num := Copy(s, p, j - p);

    //FS := TFormatSettings.Invariant;
    v := StrToFloatDef(num, 0, FInvariantFS);
  end;

5) if you went a head and made it into own renderer class, then you can utilize background thread, use step cache for the last one or two render hence you can removing locking, while the main form can use timer and check for changes and render the last one, in other words remove locking, cache for the last 1 or 2 could be as simple as lock-free ring over 3 items.
6) With its own canvas to render, you can have simulation for the header NC header ( laser it be or drill...) like a red circle, in this case the renderer will utilize its own cache and save the small square to store the portion where is the header then replace the last one, this is very efficient when the ViewPort is not moving or adjusted, we only need to move a red circle and by caching the small square you skip the render in full, while the TPaintBox with timer at 100ms will have 10FPS for moving header, this was just an example.

[Sinspin]

Habe mir das ganze mal am lebenden Objekt agesehen. Das sieht doch von der Darstellung schon wirklich gut aus.
Die Rotation des Models sollte aber um seinen Mittelpunkt herum stattfinden. Den kannst du ja aus dem maxima der Koodinaten ausrechnen.