www.jpct.net

General => German corner => Topic started by: Dryyden on November 28, 2003, 08:10:21 pm

Title: Tutorials
Post by: Dryyden on November 28, 2003, 08:10:21 pm
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.
Title: Tutorials
Post by: EgonOlsen on November 29, 2003, 12:41:31 pm
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.
Title: Tutorials
Post by: Dryyden on November 29, 2003, 03:05:33 pm
a small hello world would be great..or a recipe (like the recipes in the java3d manual)  :D

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
Title: Tutorials
Post by: EgonOlsen on November 29, 2003, 06:51:29 pm
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.
Title: Tutorials
Post by: Dryyden on November 29, 2003, 07:21:48 pm
ok, danke erstmal für die schnelle antwort :D

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:)
Title: Tutorials
Post by: Dryyden on November 30, 2003, 12:12:21 pm
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) :D ...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...
Title: Tutorials
Post by: EgonOlsen on November 30, 2003, 12:34:35 pm
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.
Title: Tutorials
Post by: Dryyden on November 30, 2003, 11:11:29 pm
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...
Title: Tutorials
Post by: EgonOlsen on December 01, 2003, 05:58:37 pm
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).
Title: Tutorials
Post by: Dryyden on December 01, 2003, 08:01:24 pm
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...
Title: Tutorials
Post by: EgonOlsen on December 01, 2003, 08:24:53 pm
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:
Title: Tutorials
Post by: Dryyden on December 04, 2003, 07:25:06 pm
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...
Title: Tutorials
Post by: EgonOlsen on December 04, 2003, 07:44:51 pm
Quote from: "Dryyden"
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.
Title: Tutorials
Post by: Dryyden on December 04, 2003, 08:07:05 pm
danke für die schnelle antwort, jetzt klappts:)
Title: Tutorials
Post by: Dryyden on December 16, 2003, 02:29:31 pm
ich nochmal:

funktioniert bump-mapping unter opengl nicht?...bei mir will er das nicht richtig anzeigen...bzw: gar nicht...
Title: Tutorials
Post by: EgonOlsen on December 16, 2003, 02:53:54 pm
Quote from: "Dryyden"
ich nochmal:

funktioniert bump-mapping unter opengl nicht?...bei mir will er das nicht richtig anzeigen...bzw: gar nicht...
Nee, funktioniert dort nicht. Müsste auch irgendwo in den Docs stehen. Liegt eigentlich an Faulheit meinerseits und daran, dass das Bumpmapping moderner Chips und das des Softwarerenderers leicht anders funktionieren. Lass das mit dem Bumpmapping am besten erstmal weg oder beschränke es auf Software. Ich werde an diesem Verhalten in nächster Zeit nichts ändern..hat sich vorher noch niemals jemand drüber beschwert... :wink:
Title: Tutorials
Post by: Mike on February 27, 2004, 02:56:57 pm
Hallo,

habe heute JPCT entdeckt und bin ziemlich begeistert, habe aber bisher wirklich NULL Ahnung von Java und ausser dem Download und dem Testen der examples hab ich noch nichts hinbekommen.

Deshalb wüsste ich gerne ob das Tutorial schon fertig ist ?

Da es im Download keine ausführbare exe gibt, frage ich mich, was ich machen muss um eine GUI oder so etwas zu erzeugen, mit der ich ein einfaches Applet erstellen könnte.

Bin für jede Hilfe dankbar, je einfacher beschrieben, desto besser, denn ich bin wirklich absoluter Newbie und habe nur wenige Erfahrungen mit html, VB6 und CAD mit Java und allem was dazugehört kenne ich mich nicht aus. Die JavaSDK 1.4.2_03 hab ich allerdings schon installiert.

Gruss und thx
Mike
Title: Tutorials
Post by: EgonOlsen on February 28, 2004, 05:31:45 pm
Mir ist nicht ganz klar, was du mit "GUI für Applets" meinst? Eine Entwicklungsumgebung für Java? Evtl. mit einem GUI-Builder drin? Falls ja, dann empfehle ich JBuilder9 in der Personal Edition. Die gibt es (kostenlos) hier:

http://www.borland.com/products/downloads/download_jbuilder.html

Du musst den JBuilder (leider recht groß) und den Schlüssel runterladen. Damit bekommst eine ,wie ich finde, nette Entwicklungsumgebung, in die man dann auch die jar-Files in jPCTs lib-Verzeichnis einbinden kann und dann kannst du damit loslegen.
Ansonten gibt es nicht Ellipse und Netbeans, aber ich persönlich kann dazu nicht viel sagen, da ich sie kaum verwendet habe.
256MB sollten es für jede dieser Umgebungen aber schon sein. Was die Tutorials angeht: Die sind nicht von mir und ich weiß nicht, wie da der Stand ist und ob da noch was passiert. Ich habe hier zwei Vorversionen davon rumliegen, aber die möchte ich nicht einfach ohne Einverständnis des Erstellers "freischalten".
Title: Tutorials
Post by: starscream on February 28, 2004, 09:11:17 pm
Zum Thema IDE:
mit dem JBuilder konnte ich mich nie so recht anfreunden.
Eclipse hingegen ist der absolute Hammer!
Lag mir sofort und ist eigentlich fast selbsterklärend.

http://www.eclipse.org

Die 3.0M7 ist schon recht stabil, weist aber einige kleinere Cache-Probleme auf.
Neben dem SDK (inkl. JDT) sollte man sich noch das "Eclipse Modelling Famework" (EMF), das Grapphical Environment Framework (GEF) und den Visual Editor (VE) sowie UML2 ziehen.
Wenn man schon mal dabei ist, schadet auch das CDT (C Developer Toolkit) und das WebDAV nicht.
Desweiteren ist ein Blick auf folgende Site lohnenswert:

http://eclipse-plugins.2y.net/eclipse/index.jsp

Und hier kann man ein Subversion-Plugin finden:

http://subclipse.tigris.org/

Wer exotischere Dinge sucht, sollte sich mit einer guten Suchmaschine versuchen. Es gibt fast nichts, was es nicht als Plugin für Eclipse gibt (GrandRapid-Browser-Plugin, ClayDatabase-Plugin, HSQLDB-Plugin...).
Darüber hinaus sind De- und Installation denkbar einfach (entpacken bzw. Verzeichnis löschen) und das Produkt für diverse Betriebssysteme verfügbar.
Ich kann nur jedem empfehlen es zumindest mal auszuprobieren und nicht nach 1 Stunde aufzugeben. Bei Fragen kann ich das gerne hier im Forum beantworten.
Title: Tutorials
Post by: Mike on March 09, 2004, 06:14:06 pm
ich hab mir jetzt ECLIPSE installiert und muss sagen, dass es auch für einen Newbie ganz übersichtlich ist und bisher problemlos funktioniert

Dennoch fänd ich ein kleines Step-by-Step-Tutorial wie Dryyden es schreiben wollte, sehr sinnvoll und wollte nochmal nachfragen ob Kontakt besteht und das vielleicht doch noch veröffentlicht wird.

Wenn jemand ein sehr einfaches Projekt hat - rotierender 3ds-Würfel mit Maussteuerung - oder ähnliches wär ich dankbar wenn er mir sowas zum Einarbeiten zur Verfügung stellen könnte.

Gruss und Thx