HI,

ich bin grad dabei mir sowas wie n Modeleditor zu bauen. Und da hat man ja normalerweiße 4 verschiedene Ansichen: die 3 Ebenen und einmal 3D.
Dazu hab ich mir mit TCustomControl ein Panel gebaut, wo ich drauf Rendern kann. Aber das wechseln zwichen den Contexten dauert zu lange. Ich hab dann nur noch ca. 40 FPS (wenn ich nur einen Context hab bin ich bei 1400!!!). Gibts vlt noch ne andere Methode wie man das machen kann, oder kann man meine verbessern? So sieht das RenderPanel aus: MfG Bergmann.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

Die Frage wurde schon einige male gestellt ( unter anderem von mir selbst ), eine Ideale Lösunge gab es bisher jedoch nicht.

1. Lösung:
Mehrere RenderContexte erzeugen und auf verschiedene Handler zeichnen, allerdings nur dann, wenn eine Interaktion oder Veränderung durchgeführt wurde. Es ist ja nicht so, das man in einem ModelEditor (abgesehen von den Animationen ) durchgehend ein aktualisiertes Bild braucht, von daher stören die niedrigen Framerates durch en Wechsel nicht so gewaltig.

2. Lösung:
Man erzeugt einen Rendercontext und unterteilt den Viewport mittels glScissor in 4 kleine Viewports und rendert die verschiedenen Ansichten in die so erstellten Bereiche. Diese Methode braucht keinen wechsel zwischen den RenderContexten und kann deshalb auch ohne weiteres in Echtzeit gerendert werden.

3. Lösung:
Man rendert jede Ansicht in eine eigene Textur und zeichnet diese dann per GlOrtho als Quad auf einen großen Viewport, allerdings ist es dann etwas komplizierter ohne optische Einbußen die Viewportgrößen zu ändern, außerdem sollte man hierbei aufpassen mit FBO-wechsel, falls man FBO benutzt, da auch diese etwas teurer sind.

_________________
Klar Soweit?

Wie du schon festgestellt hast, sind Contextwechsel auf jeden Fall zu vermeiden (eben weil unendlich langsam).
Ich denke mal der Befehl, den du suchst, heißt glViewport - damit kannst du den aktuellen "Zeichenbereich" in
Fensterkoordinaten (also Pixel) angeben.

Edit: Ich habe dir noch schnell einen Beispielcode gebastelt. Folgender Code rendert je ein Quad in 4 400x300 "Unterfenster" in einem
800x600-Fenster (die Einstellung der Projektionsmatrix spielt hier keine Rolle! - es geht wirklich nur um Fensterkoordinaten):

Wie meine 2 Vorredner es schon vermutet haben, die Lösung des Problems ist glViewport und glScissor.
In Professionellen Programmen, wie Blender oder 3D Studio Max wird dies so geregelt. Bei Blender wird die komplette gui über OpenGL gerendert also das ganze fenster ist ein OpenGL Context. Bei 3DS Max wurde es früher über ein Context geregelt, welcher durch glViewport nach dem zeichnen der GUI über die entsprechende Flähe gezeichnet wurde. Selbst wenn man mehrere Contexte nimmt, dann muss man die ressourcen zwischen diesen Sharen, die States müssen vom User extra verwaltet werden und da kommt dann noch ne menge mehr Aufwand durch weitere Probleme mit Threads, sync und Performance.
Es gilt also "one render context to rule all viewports".

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich Unke ja nur ungern. Aber vielleicht liegt der drastische Geschwindigkeitseinbruch auch nur einfach daran, dass ActivateRenderingContext die Pointer sämtlicher ihm bekannter OpenGL Methoden laden möchte. Also sofern der dritte Parameter true. Ja dort gibt es einen dritten Parameter. Der ist per Default allerdings True. Wird der auf False gesetzt, dann werden die Methoden nicht mehr geladen und es findet "nur" ein Kontextwechsel statt. Nicht nur. Denn die verfügbaren Erweiterungen werden trotzdem noch überprüft.

Es darf aber nicht pauschal False übergeben werden. Mindestens 1 Mal MUSS True (oder nichts) übergeben werden. Da die Funktionspointer sonst nie geladen würden.

Nichts desto trotz ist ein Kontextwechsel recht teuer und mitunter umständlich. Allerdings wenn man mit verteilten Fenstern arbeitet die sich nur bei Bedarf neu zeichnen, dann ist das wohl eher vernachlässigbar. Da geht es es dann aber eh nicht um das maximum an FPS. Hatte ich schon mal für ein Programm mit 3 Fenstern gemacht und das hat sich nicht Träge angefühlt. Für so etwas wie einen Modelloader aber bietet sich eine unterteilte Ansicht aber förmlich an. Also der Weg mit glViewport.

Sobald man ein weiteren Context auf einem weiterem Fenster erstellt ist das unkritisch, da man keinen Contextswitch macht, welcher auf meinem System z.B. knapp über 100ms braucht.
Im gleichen Fenster ist es allerdings der Wahnsinn, da ich so noch maximal 9FPS erreichen kann..

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Sofern man auf FPS aus ist. Allerdings eins würd mich da noch näher interessieren. Meinst du mit gleichem Fenster auch wirklich den gleichen DC? Das frage ich deswegen, da ein Panel bereits unter Windows ein eigenes Fenster ist und entsprechend einen eigenen DC besitzt. In der VCL wären die nach wie vor im selben Thread. Normal sind die Kontexe auch Threadabhängig. Bzw pro Thread kann nur ein Kontext gebunden sein. Wenn du aber meinst, dass es ewig dauert, wenn ein RC an einen anderen DC gepackt werden soll, dann kann ich das Technisch sogar verstehen, dass es sehr lange dauert. Allerdings ist es wohl sehr häufig eben auch schon so, dass dort dann mit Panels etc gearbeitet wird. Ich würd das nur gerne sehr genau wissen wollen.

Ich kann dir leider nicht sagen wie es mit VCL aussieht, ich benutze eigene Klassen, die X11 und Windows API binden und hab daher keine Panels oder derartiges vom Fenstersystem.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Na ja. Ein Panel ist eigentlich nichts weiter als ein ganz normales Fenster was mit CreateWindow erstellt wird. Also unter Windows. Aber ich denke, dann werde ich selber irgendwann mal nen Test starten. Trotzdem danke.

Hey,

hab grad ma 2 Fenter mit je einem RenderContext gemacht. Es ist nicht schneller und auch nich langsamer aber den ContextSwitch brauch ich trotzdem...

Nur mit dem Viewport arbeiten hab ich auch erst vor gehabt, aber wenn ich das auf 4 verschiedene Fenster mach, die ich dann einzelln verschieben kann is das für den User denk ich ma einfacher. Ma sehen wie ich das mach. Ich hab ja noch ca. 200 FPS die reichen ja für einen Editor locker aus. Aber für User mit schlechteren PCs würde sich die Viewport methode besser anbieten. Denn mit nem Editor der nur 9 FPS hat kann man glaub ich nich wirklich arbeiten!

MfG & ZThx Bergmann.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

Nicht wenn es ein WYSWYG Editor ist, ich würde mich an das klassische Editorschema halten.

Bastel dir doch eine Panel basierende Viewport Komponente, pack dort eine Viewport Matrix hinein.
Dann noch eine interne Funktion zum Updaten des Viewport und der Projektionsmatrix, um beim Resize event aufgerufen zu werden, sowie eine Öffentliche Funktion zum Fokusieren des Viewport.
Wenn du den Viewport Fokusiert, wird glViewport mit den Fensterkoordinaten gefüttert und die Projektionsmatrix des Viewport in OpenGL geladen(glLoadMatrix).

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hey,

was is ein WYSWYG Editor?! oO

hab jetzt alles über ein RenderContext gemacht. Aber bisl anders als du beschrieben hast: Ich hab 2 Panels. Die trennen die Form einma horizontal und vertikal, so das ich 4 Bereiche hab. Dann hab ich n Array, welches die Viewport-Daten speichert (je 4mal). Wenn ich jetzt die Panels verschiebe, oder die Fenstergröße veränder, werden die Grenzen der Viewports neu berechnet.
Ich finde ich hab n ganz passablen Editor hin bekommen. Bei der Selektion der Vertics hatte ich meine Schwierigkeiten, aber das geht jetzt auch. Hab sogar noch locker 700FPS, ich denk ma das reicht ^^

Mfg & Thx Bergmann.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

Uh ich hab das I vergessen WYSIWYG, What you see is what you get.
Dabei arbeitest du in einem Editor und ein oder mehrere Fenster zeigen dir ein Live Bild aus der Engine Umgebung.

Blender wäre z.b ein normaler Editor aber mit der Erweiterung, die ich mal vor einiger Zeit für Blender geschrieben habe, kann man eine Engine in Blender integrieren und es wird ein WYSIWYG Editor draus.
http://karmarama.linuxprofessionals.org/upload/blenderinterface17.PNG
Mitlerweile gibt es eine Netzwerkschnitstelle, womit man die Engine nicht embedded machen muss und es entsprechend viel Arbeit spart ein entsprechendes Plugin zu schreiben.

Unreal Engine Editor ist auch einer.
http://img.unrealed.de/UE3-UnrealEditorCreationTools1.jpg

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hey,

dann is mein Editor auch ein WYSIWYG-Editor...

MfG Bergmann

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.