Tutorials

[Dryyden]

will there ever be any step-by-step tutorials? or a simple "how to start"? something that shows how to set up a window (both opengl and software) and  display a simple cube or sphere. maybe you can post a little recipe to create such a scene. just something to start with, the rest will be trial and error.

[EgonOlsen]

Hmmm...the examples in the example-dir of the distribution are there for this. While they are not step by step tutorials, i think they are documented well enough to get you started. I think the terrain-example is best suited for this.
Then there is the "manual" which describes things on a more abstract level. If it's really needed, i may add a small "hello-world"-example to it.

Hope this helps.

[Dryyden]

a small hello world would be great..or a recipe (like the recipes in the java3d manual)  

well, the problem with the examples ist that it looks like in every example there is another way of writing the same code...i hope you can understand this...maybe next time i can post this in german, makes describing the problems much easier*g*

in one example exists a gameloop(), in another a render()...know what i mean?...then (please dont get it wrong) everything looks very c++ stylish...

well, maybe i can write my own tutorials (from the beginning "hello world" to more complicated things)...it seems that jpct is the only good 3d engine for java, but there are no tutorials or small recipes so its not easy to start with jpct...

greetings

dryyden

[EgonOlsen]

Ok, also in Deutsch:

Stimmt schon, dass die Beispiele uneinheitlich sind. Das liegt primär daran, dass sie zu völlig unterschiedlichen Zeitpunkten entstanden sind und ich jetzt manche Dinge nicht mehr so machen würde, die ich z.B. in Bounce so gemacht habe. Das "fortstrittlichste" ist somit sicher das fps-Beispiel. Es sieht so aus, wie ich jPCT momentan benutze.
C++-Stylisch kann ich nicht nachvollziehen. Ich habe nie viel C++ gemacht, also sollte mich das wirklich wundern. Sie sind sicher nicht sehr OOisch, aber das ist Absicht, damit irgendwelche wilden Objektkonstruktionen nicht vom eigentliichen Inhalt ablenken. Oder was meinst du jetzt genau?

Edit: Wenn du Tutorials schreiben möchtest, fände ich das großartig. Ich kann mich ja leider auch nicht zerteilen, weswegen es eine große Hilfe wäre.

[Dryyden]

ok, danke erstmal für die schnelle antwort

also werd ich mich mal ins fps beispiel reinarbeiten und versuchen, ein erstes tutorial zu schreiben...ich denke mal, das simpelste wäre wohl ein einfaches fenster mit würfel...im folgenden könnte man dann immer weiter darauf aufbauen (würfel mit farbe/textur, rotation, translation etc.)...

wenns was neues gibt, melde ich mich mal:)

[Dryyden]

so, bin jetzt soweit mit dem einfachen würfel (grauer würfel wird angezeigt; erstmal nur software-renderer...2. tutorial wäre vielleicht gleiche aufgabe mit hw-renderer) ...fehlen noch die kommentare und noch etwas text...hab aber noch ein paar fragen:

texturen: ich habe eine textur geladen in dem texturmanager hinzugefügt...danach dem würfel die textur zugeordnet...jetzt wird die textur aber nicht angezeigt, erst wenn ich environment mapping oder bumpmapping aktiviere, siehts gut aus...ist das so gewollt?...also muss ich immer eines von beiden aktiviert haben?...oder hab ich was übersehen?...

threads: in jedem deiner beispiele benutzt du threads (hab ich beim ersten tutorial erstmal rausgenommen)...benutzt du die threads nur, damit das rendern und das hochzählen des counters in verschiedenen threads ablaufen oder gehören threads zur philosophie von jpct?...also das hauptprogramm immer in einem thread ablaufen lassen...

[EgonOlsen]

Wenn du den Würfel über die Primitives-Klasse geholt hast, dann hat er erstmal keine Texturkoordinaten, da es ein simpler Drehkörper ist. Du kannst z.B. mit calcTextureWrap() oder -Spherical() eine "draufkleben". Oder den Würfel selber über seine Koordinaten zusammenbauen.
Das mit den Threads ist stellenweise nicht wirklich nötig. Was ich immer tue, ist den Zähler in einem extra Thread laufen zu lassen, um eine Zeitmessung zu realisieren. Der Render-Thread müsste für Applikationen nicht wirklich sein; Du kannst ihn einfach weglassen. Für Applets ist er aber wichtig und um die Portierung zwischen Applet und Applikation zu erleichtern, baue ich es immer gleich so. Hat mit jPCT selber nichts zu tun und ich werde das aus den Beispielen vielleicht auch entfernen, da es wohl mehr verwirrt als hilft.

[Dryyden]

hab jetzt das tutorial mit opengl...ist das gleiche wie das erste, nur eben wird das fenster von lwjgl erstellt und es ist noch kein mapping zw. awt-events und lwjgl vorhanden...

noch eine frage: ich muss ja den software-renderer explizit ausschalten (sonst fehlermeldung)...was ist der unterschied zwischen zuerst den opengl-renderer aktivieren und danach den software-renderer zu deaktivieren und dem umgekehrten weg (erst software deaktivieren, dann opengl aktivieren)...im konsolenfenster stand einmal "using splitted buffer", das andere mal "using combined buffer" (oder so ähnlich)...

hmm, beim lesen der api seh ich gerade, das sowas schon unter frambuffer drinsteht...vielleicht könntest du es nochmal kurz erklären...

ach ja, hab das erste tutorial noch geändert...abbruch jetzt über änderung der schleifenvariable...

[EgonOlsen]

Eigentlich ist es egal, in welcher Reihenfolge man Software ab- und Hardware anschaltet. Die JavaDOCs klingen so, als ob man erst OpenGL an- und dann Software abschalten muss, aber so war das gar nicht gemeint. Evtl. ist diese Reihenfolge sinniger, um nicht völlig ohne Buffer dazustehen, wenn OpenGL fehlschlägt...aber dann ist sowieso was nicht so, wie es sein sollte.
Die verschiedenen Buffer-Modi gelten nur für Software und werden von der FrameBuffer.optimizeBuf...()-Methode gesetzt. Dabei kann es mal passieren, das in einem Durchlauf die eine und im anderen die andere Methode schneller ist...das liegt im Rahmen er Messtoleranz und macht eigentlich nichts. Der ganze Quark existiert überhaupt nur, weil sich die JVM auf einem P4 u.U. sehr merkwürdig verhält. Es scheint hier ein Problem mit dem Alignment von Arrays zu geben, das aber z.T. erst nach ein paar Sekunden Laufzeit auftritt. Auf meinem Rechner ist das teilweise ziemlich signifikant und man kann es durch diese kleine Messung am Anfang mittels optimize...() etwas abmildern (aber nicht beheben).

[Dryyden]

etwas offtopic:

ich bin gerade am überlegen, wie ich eine allgemeine methode zum übersetzen von tastaturkommandos in lwjgl/awt schreiben könnte...würd ich gleich am anfang des tutorials einführen (vermutlich einen kleinen dialog neben dem hauptfenster, in dem man software oder hardware einstellen kann)...wollte ich mal kurz fragen: kennst du jogl?...ist auch eine opengl implementierung, hier kann man aber awt verwenden (das mappen würde also entfallen)...man könnte also ein und dasselbe frame für software + hardware einsetzen...

noch ein vorteil von lwjgl: man hat soundsupport:)...

oder man implementiert in jpct eine wrapperklasse: man definiert seine eigenen tastaturkonstanten (wie lwjgl) und entscheidet dann abhängig davon, ob man software oder lwjgl nutzt, wie die neue tastaturkonstante zu interpretieren ist...

würd ich mich vielleicht mal ransetzen, damit man darauf in den tutorials aufbauen kann...

[EgonOlsen]

Ich kenne Jogl, habe es aber bisher nicht weiter betrachtet. Das mit dem Sound verstehe ich nicht...LWJGL hat Sound via OpenAL, Jogl auch (bzw. Joal). Da nehmen sich beide nichts. Der Punkt ist eigentlich, dass LWJGL besser "passt". Es wrappt OpenGL und das war's. Jogl drückt einem seine Interpretation von OpenGL durch sein abstrakteres Objektmodell auf und das passt nicht sooo gut zu den bestehenden Strukturen von jPCT.
Dennoch sollte eine Jogl-Version von jPCT möglich sein. Die Renderer sind ja eigentlich austauschbar...ich habe mich bisher nur nicht damit beschäftigt und sehe auch die Notwendigkeit momentan nicht.
Fast alle benutzen jPCT im Software-Modus. Das es auch Hardware kann, ist manchen gar nicht richtig bewusst.
Eine Wrapperklasse zwischen LWJGL und jPCT wäre sicher hilfreich, aber ich werde sie nicht direkt in die API intergrieren, da sie meiner Ansicht nach dort nichts verloren hat. jPCT verwendet absichtlich keinerlei Listener/Eventhandler/Adapter-Ansätze...wer das haben möchte, soll es sich selber seinen Bedürfnissen entsprechend bauen. Wenn du sowas bauen möchtest, packe ich es natürlich gerne als Option mit dazu.
Irgendwo hatte ich sogar mal eine Aufruf gepostet, dies zu tun...hat bisher nur keiner gemacht... :wink:

[Dryyden]

ok, bin am herumprobieren mit der wrapperklasse...funktion ist ungefähr so:

falls der softwarerenderer genutzt wird, kann die neue klasse als listener funktionieren...tritt ein keyboardereignis ein, wird ein boolesche variable in einem feld gesetzt (diese entspricht dann einem bestimmten zeichen...eventuell änder ich das noch in variablen)...diese variable im feld kann dann über eine funktion (welche in jpct denn der gedrückten taste entspricht) abgefragt werden...

ähnlich ist es mit lwjgl...auch hier wird die variable im array gesetzt...

in jpct muss man dann nur noch die funktion zur entsprechenden taste aufrufen und das ergebnis auf "gedrückt" testen...klappt soweit ganz gut...kann auch zwischen software und hw-renderer wechseln...ist im prinzip ähnlich deiner variante...

da ist mir noch eine sache aufgefallen (ist lwjgl-typisch)...lwjgl verweigert den dienst, falls es noch ein awt window gibt, während das lwjgl window erstellt wird...wollte das umschalten eigentlich über ein externes fenster realisieren (also über zwei buttons)...muss man also alles menümäßige in dem lwjgl-fenster realisieren...lwjgl ist ja auch mehr eine lösung für spiele...

[EgonOlsen]

da ist mir noch eine sache aufgefallen (ist lwjgl-typisch)...lwjgl verweigert den dienst, falls es noch ein awt window gibt, während das lwjgl window erstellt wird...wollte das umschalten eigentlich über ein externes fenster realisieren (also über zwei buttons)...muss man also alles menümäßige in dem lwjgl-fenster realisieren...lwjgl ist ja auch mehr eine lösung für spiele...

Nö, eigentlich ist die Koexistenz von AWT-Fenster und LWJGL kein Problem (das Terrain-Beispiel tut dieses z.B.). Du darfst nur das Umschalten nicht in einem anderen Thread als das Rendering machen und das tust du, wenn du es z.B. in einem ActionListener erledigst. Probier mal, bei Knopfdruck nur ein Flag mit dem Umschaltwunsch zu setzen, welches in Render-Thread ausgewertet wird und dann die Umschaltung dort erledigt wird. Das sollte eigentlich funktionieren...(Edit: Das ist übrigens der Grund für die Existenz der switchOptions()-Methode im fps-Beispiel).
Oder du hast eine ATI-Karte mit einem Treiber vor Version 3.6...die mögen das nämlich auch nicht.

[Dryyden]

danke für die schnelle antwort, jetzt klappts:)

[Dryyden]

ich nochmal:

funktioniert bump-mapping unter opengl nicht?...bei mir will er das nicht richtig anzeigen...bzw: gar nicht...