Tutorial für Orgre3d für PB?

[¯\_(ツ)_/¯]

Im Compilers Ordner gibt es eine Engine3d.dll und mit Notepad kann ich sowohl D3D9RenderSystem::setAmbientLight als auch PBO_AmbientColor finden .
Kann man mit einem Hex Editor oder Disassemler die Verweise herausfinden ? Dann müsste es einfach sein eine Liste - wie RSBasic vorgeschlagen hat - anzufertigen oder ?

[tft]

Hallo,
da ich zur Zeit ein Project habe das mich mit den Thema 3D und PureBasic beschäftigt.
Würde ich mich als Leader zur verfühgung stellen. Um ein Tutorial für Ogre und Purebasic
auf die Beine zu stellen. Fürs erste übernehme ich das finanzielle.
Dazu benötige ich einige die sich nicht nur dafür interessieren sondern auch bereit sind
etwas dafür zu tun. Und in der lage zu folgen.
1. Einer der die Rechtschreibung überprüft.
2. Jemand der Video Sequenzen aufnimmt und bearbeitet.
3. Eine Webseite erstellt.
4. Ideen für das Tutorial sammelt,sichtet
5. Web Space zur Verfügung stellt.
Sollten sich genug finden. Werde ich dafür sorgen das Project am laufen zu halten.

Gruss TFT

[RSBasic]

1. Einer der die Rechtschreibung überprüft.
3. Eine Webseite erstellt.
5. Web Space zur Verfügung stellt.

[tft]

Hallo,

super !! sind wir dann schon mal 2.

Gruss TFT

[GPI]

Ich versuch gerade das durchzuarbeiten:
http://www.ogre3d.org/tikiwiki/tiki-ind ... =Tutorials
Ist zwar für 1.9, aber das meiste sollte doch passen.
Teil 1 läuft jetzt
Den Screen3DRequester, der in PB enthalten ist, hab ich auch ein bischen erweitert.
Ich werd demnächst mal meine Ergebnisse veröffentlichen, aktuell arbeite ich mich da selbst durch.

Allerdings hab ich hier schon ein paar große Unterschiede festgestellt:
Die ganzen "Listeners" gibts in PB nicht. Die SceneManager gibts in PB auch nicht, bzw. wird intern gehandhabt.

Ogre benutzt zur Identifizierung Namen, PB die bekannten Nummern, wie bei Gadgets,OpenFile etc. Das sieht man bspw. sehr gut, wenn es um Animationen geht, wo auf einmal Namen benötigt werden.

Die Kamera funktioniert in PB anders als in Tutorial. Die Kamera in PB ist eine Mischung aus Kamera und Viewports. Zumindest wurden beide kombiniert.

ScaleNode beeinflusst nicht eine angehängte Entity.

Eine Root-Node gibt es in PB nicht, bzw. jede Node startet einfach als Child von Rootnode.

Generell scheint PB automatisch Nodes zu erstellen.

TransformMesh ist immer relativ. Man kann hier leider keine manuelle Animation erstellen, weil man immer erst alles zurückdrehen muss.

Manuell erstellte Mesh kann man nicht animieren! Man kann leider keine Skeletons, bones oder sonstwas erstellen. Sprich, man muss hier manuell berechnen. Leider alles andere als Ideal. Bei meinen gewünschten Grafikstiel hätte ich noch den Vorteil, das ich es ja Kantig will und kann einfach mit nodes arbeiten...

AmbientColor() hat bei mir keine Auswirkungen. Eventuell wenn ich eine fertige Welt lade, aber wenn man nur ein paar Entitäten rumfliegen lässt, passiert hier nichts.

Falls wer in PB manuell Meshes bauen will, NormalVektor und TangentsVektor kann man anscheinend mit den Befehlen NormalizeMesh() und BuildMeshTangents() erstellen. Was genau die machen - um ehrlich zu sein, keine Ahnung

Purebasic ist aber einfach keine OOP-Sprache. Es war und ist also zwingend erforderlich, die API zu OGRE zu abstrahieren. Und wenn die Entwickler von PB definitiv eine Umstellung auf Objektorientierung ausgeschlossen haben, dann wird es auch entsprechend abstrahiert bleiben. Es gibt ja kaum noch aktuelle prozedurale, funktionale oder imperative 3D Engines bzw. Renderer. Egal welchen sie also nutzen. Sie müssen es abstrahieren.

Irgendwie geht mir der Hut hoch, wenn ich sowas lese. Warum muss man aus allen eine Glaubensfrage machen? Als gebe es nicht genügend Fanatiker, die der Welt schaden. OOP und traditionelle Prozenduale Programmierung schließen sich doch nicht gegenseitig aus! OOP ist nur ein weiteres Werkzeug. Jenachdem was man machen will, nimmt man das eine oder andere. Wobei prinzipiell alles mit beiden möglich ist.
Und ich muss dir wiedersprechen. Purebasic *IST* eine OOP Sprache, mit Interfaces & Structures ist es möglich, Objekte nativ zu erzeugen - ohne PreCompiler oder sonstige Scherze. Es ist nur nicht sehr kompfortabel, eine "Klasse" zu erstellen, weil man Sachen wie eine VT-Tabelle manuell erzeugen muss. Die anschließende Objektnutzung dagegen ist völlig unproblematisch. Es gibt imo keine logischen Grund, nicht jetzt noch den letzten Schritt zu gehen, und eine gescheite Klassen-Definition in PB einzuführen. Keiner erwartet gleich ein C++ Klassen-Machwert mit Überschreiben von Operatoren etc. PB ist schließlich eine BASIC-Programmiersprache. Entwickelt ursprünglich, um Programmieren zu lernen. Und dazu gehören heute einfach Klassen.

Das Problem mit der Ogre-Implantierung in Purebasic ist, das sie auf eigene, sehr unkonventionelle Weise implantiert wurde. Die Ursprüngliche API ist imo kaum wieder zu erkennen. Da wurde sehr viel erweitert, umgeschrieben, umbenannt. Das macht es unglaublich schwierig in eine Ogre-Hilfe einzulesen.
Leider hat Fred es versäumt aufzuschreiben, was sich alles gegenüber der Original-API verändert hat.
Ein weiteres Problem ist, das die Anleitung leider davon ausgeht, das man von allen Ahnung hat. Was genau die UV-Coordinaten bei Meshes sein sollen, hat sich mir erst sehr viel später erschlossen. Und das ist nur eine Kleinigkeit.

Ich persönlich denke, das eine "Lego"-Engine nicht verkehrt wäre. Es hat imo schon seinen Grund, warum Minecraft so erfolgreich ist. Weil man da leicht aus ein paar Grundbausteinen eine Welt aufbauen kann. So ein Leveleditor wäre imo eine Wucht in PB.
Genauso könnte man die Figuren in Spiel erstellen. Ein einfache Skellettkonstruktion, an die man Klötzchen dranklebt.
In die Richtung würde ich gehen. Mit modernen 3D Spielen kann ich eh nicht mal ansatzweise konkurrieren. Also geht man einfach den Weg, absichtlich "häßliche" Grafik zu machen

[GPI]

Vielleicht nicht uninteressant: Ich hab die Anleitung zu Ogre 1.8 gefunden:
http://www.ogre3d.org/docs/manual/index.html
Viel Spaß damit

[X0r]

Code: Alles auswählen

Purebasic *IST* eine OOP Sprache, mit Interfaces & Structures ist es möglich, Objekte nativ zu erzeugen - ohne PreCompiler oder sonstige Scherze [...]

Laut Definition ist eine Sprache nur dann objektorientiert, wenn sie OOP auch nativ untersützt. Sonst wäre C auch eine objektorientierte Sprache.

Ehrlich gesagt ist es immer noch ziemlich bescheiden, dass PureBasic diesen Schritt nicht gehen will. Das Argument von fred, die Community würde sich sonst spalten, halte ich für unzutreffend. Denn was wir z. Z. sehen ist, dass immer mehr Benutzer ihre Bibliotheken in unlesbarer Form, weil objektorientiert, veröffentlichen. Und was noch schlimmer ist: jeder kocht da sein eigenes Süppchen und implementiert seine Klassen auf unterschiedliche Weise. Es herrscht ja kein allgemein anerkannter Standard in der PB-Community.
Freds Entscheidung ist da also mehr als kontraproduktiv und sorgt dafür, dass immer mehr schlecht lesbare bzw. wartbare Codes veröffentlicht werden. Ferner wenden sich auch gerade aufgrund fehlendem OOP nicht wenige, integre Benutzer von PureBasic ab.

Ich selbst habe in der Vergangenheit auch gerade deshalb oft versucht, von PureBasic wegzukommen. Leider brauche ich aber eine Sprache, die nativen Code erzeugt, mit einer guten Sammlung von abgestimmten Libraries daherkommt und möglichst ohne externe Laufzeitbibliotheken (vcrt6 ist nicht weiter schlimm, da selbst auf Windows XP vorinstalliert) daherkommt. Delphi scheint da eine ganz gute Alternative zu sein...wäre da nicht der Preis.

Strategisch betrachtet ist das alles recht undurchdacht.

[GPI]

oh man, ich verfluche die API in PB immer mehr....

um ehrlich zu sein, ich bin komplett verwirrt.
movecamera - das ist *IMMER* relativ! egal ob #pb_world,#pb_parent
nur bei Local ist es abhängig von der Blickrichtung! und da darf man es auf keinen Fall mit #pb_relativ kombinieren!

Die Anleitung ist wieder mal völlig falsch...

[tft]

Hallo,

ich denke Falsch ist nicht das richtige Wort. Die Camera wird eigentlich immer an eine Node gehängt. Um es der
Camera Führung einfacher zu machen. So erhält man 2 unabhängige Achsen.Und die Camera selber dreht sich unabhängig
von der Bewegung. Wenn man nur das Camera Object verwendet laufen die Parameter ins lehre. Weil bei der Camera eine echte
Bewegung im Raum, zu berechnungs Fehlern führt ,wenn diese zu weit von der Mitte weg ist. Das gibt dann ruckler. Das ist auch bei
Objecten so deren Abstand bei Bewegung zu gross wird. Ich will damit ausdrücken das es wenig sinn macht die Camera zu bewegen.
Sondern eher alles drumm herum . Das kann von Darstellung zu Darstellung Variieren.

Gruss TFT

[GPI]

Die Anleitung spricht davon, das man die Camera #pb_world, #pb_local und #pb_parent bewegen kann (das dann kombiniert mit #pb_absolute und #pb_relative). Das stimmt nicht. #pb_World hat nicht die gewünschte Funktion. In Gegensatz zu bspw. MoveNode(), MoveEntity() etc.
Aber auch so hab ich probleme mit der Nachvollziehbarkeit, was genau sich da bewegt. #PB_Absolute wird bspw. gerne ignoriert, es wird immer #pb_relative verschoben, egal ob angegeben ist oder nicht.

Auch ist die Anleitung etwas ungenau. Es wird nicht nur die Position, sondern auch der Blickwinkel beachtet!