Hallo!

Ich bin letztes Wochenende irgendwie auf die 3D Programmierung gestoßen und bin nun festentschlossen mich weiter hin damit zu beschäftigen!

Nun... Ich habe letztes Wochenende sogleich natürlich tausende von Tutorials und Einführungen in Sachen 3D Programmierung gefunden.

Ich habe dann einen Open Gl Kurs (der mir sehr verständlich erschien (und es auch war)) befolgt und ca. 60 Seiten gelesen und auch nach Programmiert und soweit alles verstanden.

Aber was jetzt?
Ich würde sehr gerne tiefer in die Materie einsteigen, aber ich weiß nicht wo ich anfangen soll.
Ich habe das grundsätzliche Prinzip der Open Gl Programmierung verstanden und fühle mich auch fähig das ein oder andere zu kreieren.. nur bin ich auf einem Niveau wo mir die einteiger Tuts als föllig klar vorkommen und zudem die weiterführenden schon so extrem sind, dass ich nur sehr wenig verstehe...
Nun meine Frage: "Wie soll ich weiter machen?"

Ich habe mir überlegt, dass es mit sicherheit das beste wäre es erst mal eine Zeit lang so auf sich beruhen zulassen und mit dem bisherigen Wissen kleine Programme zu schreiben um es zu festigen und dann weiter machen zu können mit fortgeschrittenen Tutorials, aber irgendwie finde ich es auch sinnlos 10 mal das gleiche Programm zu coden, nur einmal dreht sich der Würfel rechts rum und das andere mal links rum(vielleicht wird er ja auch noch verschoben ....) aber genau das sind ja keine Probleme mehr...
Haltet ihr es für sinnvoller einfach dinge nachzuprogrammieren, ohne dass man wirklich versteht was man tut , da man es später schon nachundnach nachvollziehen kann?!Ich bin mir ziemlich unsicher wie ich nun an die ganze Sache ran gehen soll und denke, dass letzteres nicht so gut wäre...


Ich würde mich freuen, wenn mir jemand Anregungen für Programme oder Tutorials die wirklich unmittelbar an die Grundkenntnisse von OpenGl anschließen geben/nennen könnte!

mit freundlichen Grüßen,
Robert

Probier auf jeden Fall mal die Shader aus. Auf fast jeder Karte kann man etwas in der Richtung machen. Das ist wenig programmieraufwand und führt schnell zu Erfolgserlebnissen, weil da auch nur ein Würfel oder mit dem richtigen Shader ziemlich interessant aussehen kann. Da braucht man nicht gleich ein ganzes Level oder so.
Außerdem gibt's in dem Bereich nahezu umbegrenzt Möglichkeiten Dinge auszuprobieren und rumzuspielen so daß einem die Shader nicht so schnell langweilig werden.
Wenn du was nicht verstehst, kann du ja erstmal kleine Dinge an dem Programm ändern und beobachten was sich verändert um dann ausprobieren wie genau das funktioniert. Das ist sicherlich interessanter nur Tutorials lesen.
Einige denken man müsse erstmal alle Grundlagen ausprobiert haben um mit den Shader beginnen zu können, aber vieles aus dem Standard OpenGL braucht man heutzutage gar nicht mehr.

Schreib einfach ein kleines "Pong" oder "Asteroids" Spiel - bereits hier musst du dich mit Interaktion zwischen Benutzer und Objekten herumschlagen, konstanter Spielgeschwindigkeit auf unterschiedlichen Rechnern, eventuell Textdarstellung und der Organisation eines nicht völlig simplen Programmablaufs - für den Anfang ist das schon starker Tobak.
SoS Bomberman Tutorial hier auf DelphiGL gibt Einblicke in die Verwaltung eines nicht trivialen Spieleprojektes - zur Softwareentwicklung gehört schließlich nicht nur die Beherrschung einer 3D-Api.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Danke!

Ich denke, dass ich mich dann die nächste Zeit erst einmal damit befassen werde...

Ich werde dann hier im Forum (in form von Problemen und Fragen) berichten!

Robert

Würde hier auch erstmal Mars zustimmen. Ein kleines Spielchen, nix weltbewegendes, stellt einen schon das ein oder andere mal vor Problemen, mit denen man Anfangs gar nicht rechnen wollte.

Zum Bespiel könntest du ja ein echtes 3D-Vier gewinnt schreiben. Wenn du das schön texturierst, ausleuchtest, die Steine und Fläche modellst (zB. mir 3DS Max und dem Loader von Noeska) etc., hast du viel zu tun und danach bestimmt ne Menge dazu gelernt.

@Lars: Findest du's wirklich so simpel einfach nach den ersten Schritten in OpenGL mit Shadern anzufangen? Es sieht natürlich schon geil aus, da geb ich dir recht, aber "GrafikAssembler" gleich zu beginn ist vielleicht net so der Hammer oder?

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Mittlerweile ist es ja bei GLSL C Quelltext oder bei den ARB Versionen kann man immerhin mit fxPascal benutzen um die Shader zu erzeugen.
Ich denke es ist doch einfacher ein Programm für eine Sache anzugeben, weil man das ja sowieso gewöhnt ist als die ganzen festen OpenGL Funktionen einzeln zu lernen und zu benutzen. Vielleicht war das früher bei den Register Combinern mal anders aber heutzutage sind die Shader der einfachere Teil von OpenGL. Man kann einfache Shader und komplizierte Shader programmieren. Aber die Shader an sich sind nicht schwieriger anzuwenden als der Rest von OpenGL auch. Und da man ohne Shader heutzutage keine gute Grafik mehr hinbekommen kann, ist es ja nicht schlecht wenn man gleich damit anfängt.
Heutzutage programmiert man ja nicht auch erst einen Software Renderer bevor man dann OpenGL benutzt. Man steigt eben gleich auf einer anderen Ebene ein.

Sehe das auch so wie Lars, und es gibt so einige Leute die direkt Shader machen ohne sich um die API zu kümmern. Dank Shader-IDEs wie RenderMonkey und Co. kann man ja schöne Effekte mit HLSL-Shadern erschaffen ohne überhaupt jemals was mit der OpenGL-API gemacht zu haben (wobei man natürlich schon Grundlagen der 3D-Programmierung kennen sollte, denn ohne zu wissen was man da programmiert bringts nicht).

Ob man jetzt aber z.B. nach dem Einstieg in die GL-Welt Shader schreibt, komplette Spiele oder gar Engines programmiert, nur Techdemos erstellt oder Intros bastelt ist im Endeffekt dann doch Geschmackssache und in meinen Augen ist ne gesunde Mischung der beste Weg, denn so mache ich das auch. Nachdem ich jetzt mit BeanMachine mal wieder ein komplettes Spiel entwickelt habe, bei dem es dann um alle Bereiche der Spieleentwicklung ging (Programmierung, Design, Grafiken, Gameplay, etc.), habe ich gleich gestern wieder damit angefangen an ner neuen Techdemo (volumetrische Schatten für 3DS-Szenen) zu schrauben. Denn irgendwo finde ich es dann am besten wenn man Abwechslung drinne hat ohne sich fest auf ein Gebiet zu versteifen. Hier mal ein kleines (am besten fertiges) Spiel machen, da nen paar Techdemos zu Themen die einen interessieren (diese Techniken kann man dann oft später in nem Spiel umsetzen) und dann noch ein paar Shader schreiben. So hat man ein breit Gefächertes Gebiet auf dem man sich austoben kann und sammelt übrall Erfahrungen die man dann im Endeffekt sogar noch in einem Spiel zusammenbringen kann.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Was hast du denn überhaupt für eine Grafikkarte - wenn es sich hierbei nicht um eine Radeon ab 9500 oder um eine Geforce FX ab 5200 handelt, bleibt dir für Shaderprogrammierung leider nur Softwareemulation.
Auch wenn Shaderprogrammierung interessant ist, würde ich noch nicht rein darauf umsteigen, da insbesondere Notebooks und weit verbreitete Onboard Grafikkarten diese oft nicht unterstützen, von älterer Hardware ganz zu schweigen (abgesehen davon, dass die Umsetzung von GLSL, außer wahrscheinlich auf den CAD Karten von 3DLabs, noch etwas in den Kinderschuhen steckt).

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Naja auf irgendwelche alten Grafikkarten Rücksicht nehmen ist aber auch übertrieben wo es doch die Radeon 9700 schon bald zwei Jahre gibt. Wer heutzutage irgendwas mit Grafik programmieren möchte braucht eigentlich eine DX9 Karte, weil man sonst eh nicht viel (interessantes=neues) machen kann.

Die GF3/4 unterstützen auch Shader, nur eben nicht so schön. ARB VP kann man damit auch verwenden und für minimales Bumpmapping braucht man noch nichtmal irgendwelche NVidia Extensions.
Allerdings ist das dann weniger einsteigerfreundlich als die textbasierten glsl Shader, bei denen man nur einen String übergeben muß.

... und das von jemandem, der erst vor kurzem PPL in Java implementiert hat .

Im Ernst, ich würde wirklich erst mal mit OpenGL 1.1 anfangen, das garantiert überall läuft - mit ganz normalen, texturierten (oder auch nicht) Polygonen lässt sich auch vieles machen - und man muss keine zwei Sources und den Grafiktreiber gleichzeitig debuggen.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Ja, ich meinte ja nur das man sich mit zu viel Vorsicht und Kompatibilität eine ganze Menge Möglichkeiten verbauen kann. Gerade wenn man anfängt hat man vielleicht Probleme die Datenstrukturen zu organisieren usw.. Wenn man vielleicht nur irgendwie einen Boden und eine Decke und ein paar rechteckige Blöcke dazwischen hinbekommt,oder eine Höhenkarte, dann ist das alles unberührt von den Shadern, denn die können sehr gut gemacht werden ohne mit dem Rest des Programms in Konflikt zu geraten. Man muß nicht erst Klassen entwerfen und sich groß Gedanken machen um dort eine sehr gute Qualität zu haben. Daher ist es da auch leichter die eine oder andere Technik einfach als Shader ins Programm zu packen.
Das sieht man ja an vielen Shader Demos. Letztlich einfache Model Viewer mit einem genialen Shader.
Es ist leichter einen sehr guten Shader als eine sehr gute Szenenverwaltung zu programmieren.

Bei den Diagrammen hat sich das PPL und Texturierung leider nicht wirklich ausgezahlt. Bin aus zeitlichen Gründen noch nicht dazu gekommen da mal ein Applet mit Texturen zu machen.

uuuhhhhhh... nen ganzes Paket antowrten : THX!


Aber ich gleube ich war nicht deutlich genug.... ich bin wirklich anfänger...
ich habe 3 mal nen würfel gebaut usw... also wirklich noch ganz jung.. und sonst bin ich auch nicht DER PRogrammierer... mache zwar so noch nen bisl Delphi in der Schule und so noch webdesign(Php/Flash) aber bin ü+berall eher so noch an den basics dran.. wollte nur nicht immer genau dieselben sachen machen... aber ich denke, dass ich damit genug ansätze habe... sonst muss ich einfach noch mal nen anderes tut oder so machen...

mit den shadern habe ich mal kurz reingeguckt und bin mir nicht so sicher, ob ich dafür schon bereit bin ^^
zudem sagtet ihr, dass man eine halbwegs gute grakarte braucht.. das köännte vielleicht ein problem darstellen, da ich ne uralte habe: Nvidia riva 128/128ZX habe..

BTW: habe mir neulich neue treiber runtergeladen.. da gibbet aber nur treiber für Nvidia riva 128/128ZX AGP und Nvidia riva 128/128ZX PCI... welche soll ich nehmen??? nirgendwo steht was von AGP oder PCI bei mir.. weder im geräte manager noch sonst wo...?!
oder ist das egal? kann man da was falschmachen, wenn man einfach ausprobiert?

Robert

Mach deinen Rechner auf und schau dir dir Farbe des Steckplatzes an, in der die Grafikkarte Steckt. Ist die Farbe anders als die restlichen Steckplätze und ist der Steckplatz weiter rechts (etwa 1.5 cm) wird es AGP sein, sonst PCI. Aber für Shader dürfte die Karte wirklich nicht fit sein Schon ne etwas älteres Modell.

ok danke für die antwort.... ich habe aber ein Problem:
Ich habe wirklich lim |->0 plan von Hardware....
was ist die Grafikkarte? Wenn ich meinen Pc aufmache, sehe ich nur freie steckplätze (außer drei: 1 mal netzwerkkarte und 2 mal rams....).. ich sollte mir vielleicht auch eher mal nen neuen echner zulegen.... (350mhz... 8gb....scheiß grafikkarte.... totalkapputes cd rom laufwerk (brenner geht aber ) naja.. wäre echt nett, wenn du mir da helfen könntest.. dann wäre es auch schon eher vielleicht lim |->1....

nun, wenn du die grafikkarte wirklich nicht findest, kann das mehrere gründe haben: ziehen wir das pferd von hinten auf. schau an deinen monitor, dort müssten im wesentlichen 2 Kabel ankommen. Einer für Strom, der entweder von einer Steckdose oder vom Netzteil deines Rechners ausgeht. Das andere Kabel ist interessanter. Dieses müsste dich geradewegs zu deiner Grafikkarte führen: eine einfache Platine die irgendwo auf der Hauptplatine steckt. Wenns dumm läuft ist die Grafikkarte direkt in die Hauptplatibe(Die grosse Platine, auf der Speicher, CPU-Kühler und alle anderen Steckplätze aufsitzen) integriert. Dann lässt natürlich nicht am Steckplatz - da nicht vorhanden - nicht erkennen, ob du mit AGP oder PCI angebunden bist. Na schau das erstmal nach, bevor ich erkläre wie mann dann dahinter kommt, ob PCI oder AGP - ich bin mir noch nichtmal sicher wie ichs machen würde, hatte das Problem noch nie.