SoftPixel Engine (Entwicklungen eingestellt)

1
…
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
14
15
16
17

Werbeanzeige

babelfish

Alter Hase

Beiträge: 1 222

Wohnort: Schweiz

Beruf: Informatiker

131

29.09.2010, 23:51

Hey.
Bin endlich mal dazu gekommen mir die Tutorials anzusehen, sieht alles sehr schön aus

Wenn ich mich dann doch dazu entschliesse mich in die dritte Dimension zu wagen ist deine Engine sicher ein Blick Wert.

Beim "Shaping" Beispiel fehlt noch der media Ordner, existiert er nicht kommt beim Speichern des Shapes ein Fehler.
Die Hilfe ist zum färben auch nicht sonderlich hilfreich. RGB funktioniert ja nur wenn die Ebene schwarz ist, sonst geht CMY mit rechter Maustaste.

Und bei Drawing2D ist das Tileset ein png, und kein jpg

Zum Seitenanfang

LukasBanana

Alter Hase

Beiträge: 1 097

Beruf: Shader Tools Programmer

132

30.09.2010, 10:06

Ups, das mit jpg hab ich noch gar nicht bemerkt - danke

Im Tutorial Source code habe ich ja ne Info wo ich das Bild herhabe und da war es schon JPG und da habe ich das beim Speichern wohl übersehen xD.
Aber nur gut, dass die SPE inzwischen auf sowas vorbereitet ist

Beim Färben im Shaping Tutorial müsstest du erst wieder alles schwarz machen, weil die Farben dann einfach addiert werden.
Ist ein bischen blöd zu steuer - ich weiß - aber wenn ich da ne richtige GUI eingebaut hätte, wer's ein recht umfrangreiches Tutorial geworden und für Anfänger vielleicht etwas unübersichtlich.

Gruß,
Lukas

EDIT:
Stimmt, den "media/" Ordner beim Shaping Tutorial hab ich auch vergessen. Da sollte eig. auch schon ein Modell drin liegen, dass ich selbst 'geshapet' habe

Mein YouTube Channel
Mein Twitter Profil
Meine Projekte auf github.com
Meine Projekte auf bitbucket.org

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »LukasBanana« (30.09.2010, 10:19)

Zum Seitenanfang

LukasBanana

Alter Hase

Beiträge: 1 097

Beruf: Shader Tools Programmer

133

06.12.2010, 19:27

Heute habe ich einen Chatroom für die SoftPixel Engine über afterworkchat.de eingerichtet:
SoftPixelChat

Mein YouTube Channel
Mein Twitter Profil
Meine Projekte auf github.com
Meine Projekte auf bitbucket.org

Zum Seitenanfang

LukasBanana

Alter Hase

Beiträge: 1 097

Beruf: Shader Tools Programmer

134

30.03.2011, 20:46

Die nächste Release Version wird immer noch eine Weile auf sich warten müssen. u.a. weil ich im Moment wieder die Architektur des Szenegraphen komplett am überarbeiten bin. Dabei soll das ganze nach außen hin natürlich möglichst unverändert bleiben.
Die Klassen-Hierarchy der Szenen Objekte sieht bei mir gerade so aus:

Quellcode

sp::BasicObject
    * sp::Node
          * sp::scene::SceneNode
                * sp::scene::Camera
                * sp::scene::Light
                * sp::scene::RenderNode
                      * sp::scene::MaterialNode
                            * sp::scene::Billboard
                            * sp::scene::Mesh
                            * sp::scene::Terrain
                      * sp::scene::SceneManager
                            * sp::scene::SceneManagerSimple
                            * sp::scene::SceneManagerSimpleChildTree

Dass der SceneManager jetzt auch ein 'renderable-node' ist liegt daran, dass man in der nächsten Version sogar einen gesammten Szenegraphen-Baum in einen anderen Szenenknoten einhängen können soll.
Außerdem soll das ganze jetzt weit aus dynamischer werden, sodass man die Klassen "Mesh", "Camera" usw. selbst leicht erweitern kann. Für die Anfänger bleibt es also weiter hin wie gehabt, aber für die, die sich mit
Szenegraphen und C++ allgemein schon etwas besser auskennen, gibt es dann mehr Freiheiten und Möglichkeiten

Alles was sich bis jetzt an der API ändert ist, dass ich den Namen der ursprünglichen Klasse "Node" jetzt (wie in der Irrlicht Engine) in "SceneNode" geändert habe.
Was die einzelnen Unterklassen alles bedeuten, könnt ihr dann natürlich in der API Docu durchlesen

Gruß,
Lukas

Mein YouTube Channel
Mein Twitter Profil
Meine Projekte auf github.com
Meine Projekte auf bitbucket.org

Zum Seitenanfang

Schrompf

Alter Hase

Beiträge: 1 470

Wohnort: Dresden

Beruf: Softwareentwickler

135

31.03.2011, 10:41

Ein Terrain ist ein Material? Ein SceneManager ist ein RenderNode? Mir scheint, Du bist gerade in der "Ableitung ist die Lösung"-Phase Deiner Coder-Karriere. :-) Die hält aber nur, bis Du zum xten Mal für einfache Aufgaben ein dynamic_cast<> tippst, num um rauszukriegen, ob ein bestimmter Node eine bestimmte Eigenschaft besitzt. Ich empfehle, diese Softwarestruktur teilweise zu überarbeiten. Ich würde bestimmte Eigenschaften (wie z.B. die Gruppierbarkeit) in die Basisklasse ziehen und einige Sachen (wie Material, Terrain, Billboard oder Mesh) eher als Komponente anstatt als Ableitung realisieren.

Häuptling von Dreamworlds. Baut aktuell an nichts konkretem, weil das Vollzeitangestelltenverhältnis ihn fest im Griff hat. Baut daneben nur noch sehr selten an der Open Asset Import Library mit.

Zum Seitenanfang

LukasBanana

Alter Hase

Beiträge: 1 097

Beruf: Shader Tools Programmer

136

31.03.2011, 14:46

Wie kommst du darauf, dass ein MaterialNode ein Material ist?

Ein MaterialNode hat ein Material und bietet vor allem setter und getter Funktionen. Ein Terrain hat schließlich auch ein Material, daher ist es auch ein MaterialNode.
Wenn du mit mir jetzt über die Namensgebung diskutieren willst, ist das was anderes

Für SceneManager passt hier z.B. "SceneGraph" besser. Das werde ich warhscheinlich auch umbenenne. Hat man einen haupt SceneGraph dann kann man weitere in einen anderen Node einhängen.
Was soll falsch daran sein? Szenegraphen kann man auf sehr viele Arten umsetzten. Auch wenn du eine andere Art gewohnt bist heißt das nicht, dass dieses schlecht durchdacht ist.
Ich arbeite daran schließlich nicht erst seit gestern

EDIT:
Ok, das mit dem SceneManager wäre sicher gut, das in zwei Klassen auf zu teilen. Einen SceneManager, der das Laden von Meshes usw. verwaltet und einen SceneGraph für den gesammten Szenenknoten.
Aber allgemein, gefällt mir diese Struktur schon mal sehr gut.

Mein YouTube Channel
Mein Twitter Profil
Meine Projekte auf github.com
Meine Projekte auf bitbucket.org

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »LukasBanana« (31.03.2011, 14:51)

Zum Seitenanfang

Schrompf

Alter Hase

Beiträge: 1 470

Wohnort: Dresden

Beruf: Softwareentwickler

137

31.03.2011, 14:54

Eine Ableitung stellt immer eine "Is a" Beziehung, während Komponenten eine "Has a"-Beziehungen darstellen. Konkret: wenn Du einen TerrainNode von einem MaterialNode ableitest, legst Du damit fest, dass ein Terrain immer und zu jeder Zeit genau ein Material hat. Das steht im Widerspruch zu den mir bekannten Terrain-Techniken, die üblicherweise mehrere Materialien anhand einer AlphaMap oder PerVertex-Anteilen mischen.

Ich glaube Dir übrigens gern, dass Du das nicht zum ersten Mal machst. Ich wollte Dich nur warnen, dass Du das noch ein weiteres Mal machen wirst, wenn Du diese Struktur beibehälst. Ich wollte nicht überheblich klingen. Falls das so rüberkam, tut es mir leid. Ich wollte Dir nur einen Tipp geben, solange die Korrektur noch mit wenig Aufwand machbar ist.

Häuptling von Dreamworlds. Baut aktuell an nichts konkretem, weil das Vollzeitangestelltenverhältnis ihn fest im Griff hat. Baut daneben nur noch sehr selten an der Open Asset Import Library mit.

Zum Seitenanfang

LukasBanana

Alter Hase

Beiträge: 1 097

Beruf: Shader Tools Programmer

138

31.03.2011, 15:28

Also momentan kann meine Engine für jedes Geometry Objekt sowieso nur ein Material nutzen. Dieses beinhaltet aber auch nur dinge wie: Diffuse, Ambient ..., Shininess, AlphaTest, DepthTest, ..., Blending (source & destination) etc.
Im Grunde hast du natürlich Recht mit dem "is a" und "has a". Nur speziell im Falle des MaterialNode ist das bei meiner Engine so:

C-/C++-Quelltext

class MaterialNode {
    public:
        void setDiffuseColor(video::color Color) // Sets das Feld "m_Material.DiffuseColor"
    private:
        video::SMaterialStates m_Material; // Einfache Struktur mit allen benötigen (öffentlichen) Feldern
};

Dies Funktionen "setDiffuseColor" will ich natürlich nicht für Mesh und Terrain zwei mal schreiben. Jetzt könnte man das natürlich schon in der Struktur "SMaterialStates" machen, oder gleich eine Klasse daraus machen.
Das habe ich aber nicht gemacht, weil die Materialeigenschaften extra in einer komplett öffentlichen Sturktur sein soll und weil es einfacher sein soll, Geometrie Objekte zu configurieren.
Wenn ich das anders mache sähte es nänmlich so aus:

	C-/C++-Quelltext
1	Mesh->getMaterial()->setDiffuseColor(video::color(255, 255, 255));

Ist im Prinzip nichts schlimmes, aber das stört mich an einigen Stellen. Wenn man das immer so 100% logisch macht, würde das setzen von Vertex Koordinaten z.B. so aus sehen:

	C-/C++-Quelltext
1	Mesh->getSurface(0)->getVertex(0)->setCoord(dim::vector3df(0, 0, 0));

Anstatt so:

	C-/C++-Quelltext
1	Mesh->setVertexCoord(0, dim::vector3d(0, 0, 0));

Diese mehrfache Verschachtelung von Felder finde ich irgend wann lästig. Das ist der Grund, warum ich aus Mesh, Billboard und Terrain ein "MaterialNode" (oder 'Materiable' Node) gemacht habe.
Lange Rede kurzer Sinn: vlt. passe ich das irgend wann noch mal an, aber im Moment sehe ich keinen Grund, das zu ändern.

Danke trotzdem für dienen Vorschlag

Mein YouTube Channel
Mein Twitter Profil
Meine Projekte auf github.com
Meine Projekte auf bitbucket.org