Blender GameEngine Entwicklung [2.64+]

[moerdn]

Nicht mehr ganz taufrisch aber eben erst entdeckt. Die Zusammenfassung eines IRC Meetings im Bezug auf die BGE Entwicklung:
http://lists.blender.org/pipermail/bf-c ... 31803.html

License:
* Attempt to use non-viral licenses going forward
* Allows for code to be reused and shared with other projects (eg, GameKit)
* Modification to existing code needs to be GPL, new “modules” can
be licensed separately
* Try to double license GSoC 2011 projects
* Some food for thought: http://altdevblogaday.org/2011/04/12/sharing-code/

Klingt sehr gut, ein GPL freier Player oder zumindest die Möglichkeit für Non-GPL Plugins wäre ein riesiger Schritt in die richtige Richtung.

Current Projects and Merging:
* The GSoC BGE Shaders branch still has workflow issues and missing
data-types. Mitchell will come up with a list of todos and rebranch
with working code (trying to use an existing branch if possible)
* The GSoC Recast/Detour branch is stable enough to merge, and Nick
will prepare it for merging in the next couple of weeks.
* The TexFace removal feature is almost ready. Dalai will be giving
the patch a “final treatment” this week/next.
* A list of smaller features will be sent to the mailing list for review

Recast&Detour ist 'stable' Es kann also sein, das wir in den nächsten Wochen schon die ersten Builds bauen/herunterladen können!

Weiß jemand, was mit dem 'TexFace removal' gemeint sein könnte?

Some ideas of what new developers could look into:
* Discrete LoD
* Save converted BGE data out to a file
* Document bge.constraints and bge.texture modules
* Adding threading to the BGE (eg, loading a new scene, separate
render thread to make use of swap buffer wait time, etc) [NOTE: This
one's tough!]

Wooow, mehr kann ich dazu nicht sagen. Das Proposal für konvertierte BGE Szene habe ich schon angesehen, klingt echt toll. LOD und Multithreading wird die BGE dazu nochmal stark beschleunigen.

Und zum Schluss die schon lange benötigten Verbesserungen für die BGE als GSOC Projekt:

GSoC 2011 Polishing and Bugfixing Project:
* Fixing GLSL lighting bugs
* Fixing python functions for mist, ambient, etc in GLSL mode
* Support for DDS textures with DXT compression (patch started)
* VBO support (patch started)
* Multi-UV (patch started)
* Mip Map settings per texture
* A BA thread will be started for more feedback

Es scheint so, als werden langsam alle Missstände ausgeräumt. Bin echt beeindruckt und voller Vorfreude.

mfg, der moerdn

[ReSeT]

Hmja, klingt alles sehr gut.

<MoserModus>

Was ich allerdings als viel wichtiger erachte, als den ganzen neuen Spielkram:

Der Python Editor hat definitiv eine Renovierung nötig, das Teil ist wirklich aus dem
letzten Jahrtausend. Von einem modernen Editor erwarte ich zumindest eine Autovervollständigung und Syntax Unterstützung für die Blender Python API. Ich hab jedenfalls keine Lust, mich immer durch die API Docs zu wühlen. Das geht unter Eclipse/Java
zigfach schneller.

Weiterhin fehlt mir eine Art Projekt Ansicht, wo ich alle Scripte in einer Art Baum sehen
kann und an welchen Controllern sie hängen. Bisher ist das echt ein totaler Krampf.
Wenn das Projekt größer wird, wird das schon manchmal zur berühmten Suche der Nad(d)el im Heuhaufen. Ich vermute das du Moerdn das eh anders handhabst.

Dann die Shader Entwicklung: Was zu Teufel hat der Shadercode als eingebetteter String im Python Script zu suchen? Hier brauchts einen eigenen Shader Editor, der auch wiederum
Auto Vervollständigung und Syntax-Highlighting für die GLSL bieten sollte.(träum weiter! )

Weiterhin sollte es für ein paar gängige Genres fertige Templates geben, damit man sich nicht jedesmal was zusammenpopeln muss, Stichwort FPS, Vehicle, freie Cam etc.

Ich weiss, es klingt moserig, ich hätte mich auch schon längst mal in die Blender Entwicklung reigefuchst. Da aber leider ausser der Game Engine, ein Großteil der Editoren auch nach dem "Big Rewrite" in C geschrieben ist, hört für mich der Spass auf. C ist nicht mehr zeitgemäß! Größtenteils finde ich hier unwartbaren (weil undokumentiert) und unleserlichen Code vor. C gehört wenn überhaupt in den Microcontroller oder verboten.

Wenn die von mir genannten Punkte umgesetzt/ausgeräumt sind, kann man sich dann mal mit so Sachen wie VBOs (deren Nutzen ich eh für fragwürdig halte, da man mit Display Lists mindestens genauso gut arbeiten kann, wenn man sich zusammenreisst.),LOD und Threading auseinandersetzen. Bis dahin finde ich Spiele Entwicklung nach Old-School Art deutlich effizienter.

Achja, was auch noch ganz toll wäre: Die Blender Entwickler, die sich scheinbar für Götter halten, könnten ruhig mal etwas freundlicher zu Neuankömmlingen sein. Mitunter bekommt man in einem _vollbesetzen_ Chat gar keine, oder irgendeine dumme Antwort von oben herab. Vielleicht finden sich dann ja auch ein paar Coder, die sich der Sache mal annehmen.

</MoserModus>

Gruß
ReSeT

[moerdn]

Der Python Editor hat definitiv eine Renovierung nötig, das Teil ist wirklich aus dem
letzten Jahrtausend. Von einem modernen Editor erwarte ich zumindest eine Autovervollständigung und Syntax Unterstützung für die Blender Python API. Ich hab jedenfalls keine Lust, mich immer durch die API Docs zu wühlen. Das geht unter Eclipse/Java
zigfach schneller.

Der Editor ist mir egal, außer um mal 5 Zeilen Code zu testen verwende ich den sowieso nicht. Aber du hast vollkommen recht, eine automatisch generierte Python API, die man dann für Vervollständigung in Entwicklungsumgebungen wie Eclipse, Emacs etc verwenden kann wäre geil. Sollte nicht sooo schwer sein aus dem C++ Code die API zumindest die Skeletons generieren zu können. Ich glaube für Eclipse gabs da sogar mal irgendwas.

Weiterhin fehlt mir eine Art Projekt Ansicht, wo ich alle Scripte in einer Art Baum sehen
kann und an welchen Controllern sie hängen.

Stimmt, da gebe ich dir Recht.

Ich vermute das du Moerdn das eh anders handhabst.

So viel LB's wie maximal nötig dafür aber soviel Python Code wie möglich verwenden. Ansonsten auf eine 'Projekt Funktion' warten. Ich werde demnächst ein kleines Addon für GE bauen, das mir automatisch ein Projekt generiert.

Weiterhin sollte es für ein paar gängige Genres fertige Templates geben, damit man sich nicht jedesmal was zusammenpopeln muss, Stichwort FPS, Vehicle, freie Cam etc.

Sollte sich relativ einfach über ein Addon nachrüsten lassen. Mit der neuen Blender API hat man nun alle Möglichkeiten. Gerade an der Stelle kann man vielleicht was erreichen. Andererseits ist ein GSOC Projekt mit der Nodifzierung der Logic angelaufen. Dadurch wird die GE vielleicht endlich das Interface bekommen, was man für einen effizienten Workflow benötigt. Die LB's sind einfach zu unflexibel.

C ist nicht mehr zeitgemäß!

Muss leider sagen das mir der C++ Code der BGE auch enorme Kopfschmerzen bereitet. Einfacher wird die Programmierung der Engine durch C++ leider nicht oder ich verstehe noch zu wenig davon.

Achja, was auch noch ganz toll wäre: Die Blender Entwickler, die sich scheinbar für Götter halten, könnten ruhig mal etwas freundlicher zu Neuankömmlingen sein. Mitunter bekommt man in einem _vollbesetzen_ Chat gar keine, oder irgendeine dumme Antwort von oben herab. Vielleicht finden sich dann ja auch ein paar Coder, die sich der Sache mal annehmen.

Für einfachere und kleine Aufgaben, wäre ich auch sofort zu haben. Zum einen um die Code Base besser kennen zu lernen, zum anderen möchte man ja sein Lieblingstool auch verbessern. Ich glaube aber kaum das man um den klassischen Weg der Patches+Mailingliste herum kommt.

Nochmal zur Entwicklung:
Ich finde es sehr wichtig, das vor allem die bis jetzt so schlampig umgesetzten Features ausgebügelt werde. Klar das man sich gedacht hat 2 UV Layouts für GLSL Materialien sind besser als nix aber das ist doch kein guter Entwicklungsstil?

Fixing python functions for mist, ambient, etc in GLSL mode

Das ist echt unverständlich, warum das jetzt erst gemacht wird. Hatte das selber schon ausgebügelt so richtig interessiert hatte es aber keinen. Vielleicht muss man die Leute nur genug nerven :/

Alles in allem stehen aber echt aufregende Zeiten bevor. Der Traum, mit der BGE auch (weiterhin) Geld zu verdienen ist nicht mehr ganz so unrealistisch.

mfg, der moerdn

[ReSeT]

Muss leider sagen das mir der C++ Code der BGE auch enorme Kopfschmerzen bereitet. Einfacher wird die Programmierung der Engine durch C++ leider nicht oder ich verstehe noch zu wenig davon.

Um ehrlich zu sein, finde ich den auch nicht besonders schön. Es ist allerdings mit Eclipse und dem CDT Plugin sehr leicht durch den Code zu navigieren, da kommt man nach einiger Zeit gut rein. Besser wird der Code dadurch allerdings auch nicht.

Sollte sich relativ einfach über ein Addon nachrüsten lassen. Mit der neuen Blender API hat man nun alle Möglichkeiten. Gerade an der Stelle kann man vielleicht was erreichen.

Würde ich schon schreiben, aber mit dem derzeitige Py Editor - No way!

EDIT: Für den Fall, daß sich das so anhört, also ob ich was gegen die Blender Entwickler hätte, dem ist nicht so, ich kenne die Ursachen für solche Schwächen am Code und
das heisst nicht daß Blender nicht trotzdem ein großartiges Tool wäre.

[Monster]

Die Autovervollständigung gibt es für die Blender API doch schon aber halt nicht für die Game API. Auf BA hat jemand eine Datei für die Game API gebastelt, damit die Autovervollständigung auch in PyDev zur Verfügung steht.

Allerdings geht es bei PyDev nicht so schon wie z.B. bei Java. Wahrscheinlich weil Python zu weich ist und man ranschreiben kann was man will. Da kann so ein Parser nur raten, was in seiner Variablen grad drin steckt.

Die API calls sollte man kennen und/oder immer die API zum Nachschlagen da liegen haben. Das ist nun ma so.

Rauszufinden welche Objekte welchen Code benutzen, ist tatsächlich nicht auf einem Blick ersichtlich. Allerdings sehe ich das so, dass das nichts nützt, da Python code lediglich ein Teil der Logik ist. Meine Methode für mehr Übersicht: Ich kopier mir das Modul/Script Feld als Namen für den Controller. Dann sehe ich auch im zugeklappten Zustand, was aufgerufen wird. Beschreibende Namen sind sowiso Pflicht.

Also ich nehme den Internen Editor nur, wenn es mal schnell gehen muß. Sonst nehm ich Eclipse/PyDev und lege die Dateien extern ab. Da gibts da sogar ein Debugger, falls die Printstatements nichts mehr bringen.

@Moerdn: Falls Du wirklich ne "kleine" Aufgabe suchst, Du erinnerst Dich an den KI-Thread?
Wie wärs mit ner kleinen API-Erweiterung: Das Verfügbarmachen des instanziierenden Objekts als Property.

Also alle Objekte einer Instanz können per KX_GameObject.adder (.pivot, .handle oder was auch immer) auf das Objekt mit dem Doupligroup verweisen.
Andersrum wäre ein KX_GameObject.instances das eine Liste der Instanzobjekte liefert auch nicht schlecht.

Das wäre schon mal ein großer Schritt nach vorn, damit man sich eine Gruppenbibliothek aufbauen kann. Mein letztes Build für Blender war noch mit 2.37.

Monster

[moerdn]

Ja, ich habe tatsächlich schon mal in den Code geschaut. Meine Erste Idee war das addObject() ein Tupel zurück gibt. (instance, dupli_empty) oder eben nur ein Element bei einer normalen Instanzierung von Objekten auf inaktivem Layer. Habe aber noch nicht so richtig gefunden wann es sich nun um eine Gruppeninstanz handelt oder nicht.

Deine Idee kam mir auch schon in den Sinn. Dieses Attribut hätten dann aber alle GameObjects und bei den meisten wäre es None.

Es muss jedenfalls immer eine Fallunterscheidung gemacht werden. Handelt es sich um ein Dupli Group Objekt, oder um normale Objekt Instanzierung.

Den Klassen neue Properties zu geben sollte recht einfach möglich sein, muss mal schauen wie man das mit dem Referenz Counting macht. Dieser muss immer explizit von Hand erhöht oder verringert werden sobald man eine Objekt Referenz irgendwo ablegt/löscht

mfg, der moerdn

[moerdn]

Ich habe soeben versucht deine Idee in die Tat umzusetzen und wie es scheint (nach 2-3 kleineren Tests) funktioniert es.

1. KX_GameObject bekommt ein zusätzliches Attribut m_pBaseObject vom Typ KX_GameObject*
2. ein GetBase() Methode
3. die Python Property für den (ausschließlich) lesenden Zugriff auf das Attribut.
4. Die Implementierung der DupliGroupRecurse Methode habe ich um eine Zeile erweitert
groupobj->m_pBaseObject = replica; // Replica ist das Toplevel Objekt, Base der Gruppe.
5. Beim implementieren der GetBase Methode wird die mit AddRef() die Referenz auf das m_pBaseObject erhöht und zurückgegeben, falls der Zeiger NULL ist, wird dann einfach None zurückgegeben. Das ist dann bei allen Objekten so, außer es sind instanzierte Gruppen

Habe mich da sehr an die GetParent und SetParent Implementierung gehalten.

Die Python API wird dann einfach um eine Property erweitert:

Code: Alles auswählen

# Erzeuge Dupli Gruppen Instanz und gib das Dupli_Group Empty, also den Pivot zurück
# funktioniert wie bisher
pivot = scene.addObject("Gruppen_Instanz", own)
base = pivot.base # das base Objekt der Gruppe
base.position = ... # etc
print(pivot.base) # Das Toplevel Gruppenelement konvertiert in string
pivot.base.setParent(pivot) # mache den pivot zum Elternobjekt von base
print(pivot.base.base) # None, da base keine base hat


Für diese einfachen Fälle scheint es ganz gut zu funktionieren, Abstürze traten nach dem Ref Counting nicht mehr auf. Wie es bei komplexen Szenarien aussieht weiß ich noch nicht
(Gruppen, die Gruppen instanzieren)

EDIT:
habe weitere Tests gemacht.

Code: Alles auswählen

def main():
    cont = bge.logic.getCurrentController()
    own = cont.owner

    sce = bge.logic.getCurrentScene()
    cube = sce.addObject("Cube", own)
    cube.base.position = [0,0,1]
    cube.base.setParent(own)
    cube.endObject()

    # own ist Gruppeninstanz und hat ein base Object
    own.base.setParent(own)


Gruppen, die Gruppen Instanzieren und sich so 'verlinken' funktioniert

Code: Alles auswählen

def main():

    cont = bge.logic.getCurrentController()
    own = cont.owner # pivot der Gruppeninstanz

    # own.parent ist eine andere Instanz
    # parent wurde im 3D view mit normaler ctrl+P Parentierung vorgenommen

    own.base.setParent(own.parent)


Parentieren von einer Gruppeninstanz an eine andere ist so Kinderleicht mit einer Zeile Code möglich.

EDIT:
Umgekehrt könnte man auch dem Base Objekt eine Referenz auf das Dupli-Group Objekt geben. Wäre auch nicht verkehrt. hm.

Das Ergebnis:
http://www.youtube.com/watch?v=pxR6eLeVZJA

mfg, der moerdn

[Monster]

Das ist ja cool !

Base ist jetzt aber ein Objekt der Gruppe, oder?
Wie bestimmst Du das? Es könnte ja sein, dass die Objekte nicht mit parent zusammenhängen.
(im LinkLib ist das ja nur ne Krücke zum Finden des Pivots)

Viele Grüße
Monster

[moerdn]

Base ist die Referenz auf das Toplevel Element der Gruppe. Stimmt, daran habe ich gar nicht gedacht, wenn die Objekte innerhalb der Gruppe nicht parentiert sind. Muss ich mal testen was dabei raus kommt. Aber so gesehen ist es murks, da noch keine Entscheidung darüber getroffen wird, welches Objekt denn 'Base' Element der Gruppe sein soll.

Der Algo sieht so aus:

Code: Alles auswählen

   set<CValue*>::iterator oit;
   for (oit=m_groupGameObjects.begin(); oit != m_groupGameObjects.end(); oit++)
   {
      gameobj = (KX_GameObject*)(*oit);

      KX_GameObject *parent = gameobj->GetParent();
      if (parent != NULL)
      {
         parent->Release(); // GetParent() increased the refcount

         // this object is not a top parent. Either it is the child of another
         // object in the group and it will be added automatically when the parent
         // is added. Or it is the child of an object outside the group and the group
         // is inconsistent, skip it anyway
         continue;
      }
      replica = (KX_GameObject*) AddNodeReplicaObject(NULL,gameobj);
      // add to 'rootparent' list (this is the list of top hierarchy objects, updated each frame)
      m_parentlist->Add(replica->AddRef());

      // recurse replication into children nodes
      NodeList& children = gameobj->GetSGNode()->GetSGChildren();

      replica->GetSGNode()->ClearSGChildren();
      for (NodeList::iterator childit = children.begin();!(childit==children.end());++childit)
      {
         SG_Node* orgnode = (*childit);
         SG_Node* childreplicanode = orgnode->GetSGReplica();
         if (childreplicanode)
            replica->GetSGNode()->AddChild(childreplicanode);
      }
      // don't replicate logic now: we assume that the objects in the group can have
      // logic relationship, even outside parent relationship
      // In order to match 3D view, the position of groupobj is used as a
      // transformation matrix instead of the new position. This means that
      // the group reference point is 0,0,0

      // get the rootnode's scale
      MT_Vector3 newscale = groupobj->NodeGetWorldScaling();
      // set the replica's relative scale with the rootnode's scale
      replica->NodeSetRelativeScale(newscale);

      MT_Point3 offset(group->dupli_ofs);
      MT_Point3 newpos = groupobj->NodeGetWorldPosition() +
         newscale*(groupobj->NodeGetWorldOrientation() * (gameobj->NodeGetWorldPosition()-offset));
      replica->NodeSetLocalPosition(newpos);
      // set the orientation after position for softbody!
      MT_Matrix3x3 newori = groupobj->NodeGetWorldOrientation() * gameobj->NodeGetWorldOrientation();
      replica->NodeSetLocalOrientation(newori);
      // update scenegraph for entire tree of children
      replica->GetSGNode()->UpdateWorldData(0);
      replica->GetSGNode()->SetBBox(gameobj->GetSGNode()->BBox());
      replica->GetSGNode()->SetRadius(gameobj->GetSGNode()->Radius());
      // we can now add the graphic controller to the physic engine
      replica->ActivateGraphicController(true);

                // Moerdn Base Object Reference
                groupobj->m_pBaseObject = replica;

      // done with replica
      replica->Release();
   }


Wie du an den letzten Zeilen siehst, wird einfach das letzte Objekt der Gruppe als 'Base' eingetragen. Da müsste man sich noch was besseres überlegen. Welches Objekt der Gruppe soll als Base bestimmt werden? Bei Parent/Child Beziehungen würde ich sagen der root Node.

EDIT: Habe gerade festgestellt das es nicht so wirklich deterministisch ist, sobald die Objekte in der gleichen hierarchischen Ebene liegen. Ein 'Base' ist für die Gruppe somit Pflicht in der jetzigen Variante. Finde ich aber nicht wirklich schlimm da man meistens Beziehungen erstellt. Für den anderen Fall müssten wir noch weitere Kriterien einbauen.

mfg, der moerdn

[Monster]

Deswegen hatte ich mir das andersrum gedacht:
- Alle Objekte der Instanz kennen das Pivot, und
- das Pivot kennt die Liste der Objekte der Instanz.
 
(Die Roots kann man dann ja aus der Liste rausholen [wegen der Parent-Beziehung]).

Die Idee ist, das die Implementierung an den Objekten der Instanz hängt (also an irgendeinem). So ähnlich wie bei Klassen und Objekten. Group = Klasse, Group Instanz = Objekt.

Also um dein Video zu verwenden, das Fass (also das Modell) kann sich dann selbst an sein Pivot parenten (per Python). Also der Anwender braucht das dann nicht mehr selbst über den Pivot zu machen.

Also so was:

Code: Alles auswählen

def parentToPivot(cont):
  cont.owner.setParent(cont.owner.pivot) # cont.owner=Faß


Und trotzdem vom Pivot aus:

Code: Alles auswählen

def parentRootsToPivot(cont):
  roots = [obj for obj in cont.owner.instances if obj.parent is None]
  for root in roots:
    root.setParent(cont.owner) # cont.owner = pivot


Wenn Du möchtest, kann ich Dir noch einen anderen Vorschlag machen, um die Unterstützung Gruppen zu verbessern. Das ist allerdings aufwendiger und würde wohl eine Erweiterung der GUI verlangen. Das würde dann aber auch gleich die Componenten überflüssig machen .

[moerdn]

Also um dein Video zu verwenden, das Fass (also das Modell) kann sich dann selbst an sein Pivot parenten (per Python). Also der Anwender braucht das dann nicht mehr selbst über den Pivot zu machen.

Totschlag- Argument. Das macht es natürlich noch einfacher.

Code: Alles auswählen

     
  replica->ActivateGraphicController(true);

  // alle Objekte der Gruppe in einer Liste speichern
  groupobj->m_pInstanceObjects->push_back(replica);

  // Jede Gruppeninstanz bekommt einen Pointer auf das Dupli-Group Empty.
  replica->m_pPivotObject = groupobj;

  // done with replica
  replica->Release();


Sollte also machbar sein.

Wenn Du möchtest, kann ich Dir noch einen anderen Vorschlag machen, um die Unterstützung Gruppen zu verbessern. Das ist allerdings aufwendiger und würde wohl eine Erweiterung der GUI verlangen. Das würde dann aber auch gleich die Componenten überflüssig machen

Klar, nur heraus damit. Wenn es um Erweiterungen der GUI mittels Python Script dann ist das meiste doch relativ einfach machbar. Ans Ändern der LB's würde ich mich aber nicht trauen.

mfg, der moerdn

[Monster]

Ja genau da müßte es wohl hin.

Also die Idee (vielleicht ist sie ja doch nicht so gut).

bei den Properties an den Objekten sollte es ein Schalter geben (z.B. "G"). Wenn der eingeschaltet ist, wird das Proeprty zum Group Property.

Group Properties werden bei allen Objekten der gleichen Gruppe eingeblendet. Änderungen bei einem Objekt ändern das Property an allen Objekten der Gruppe (Also eine Referenz auf das gleiche Property).

Group Properties werden beim Pivot (nach der Instanziierung mit eingeblendet und stellen damit die (Property)-Schnittstelle zur Instanz dar.

• Jetzt kann der Anwender hier die Parameter für die Instanz eintragen (z.b. "Schrittweite") also die Konfiguration.
• Andersherum können Instanzobjekte hier Ergebnisse ablegen ("Treffer").
• Die Groupobjekte und das Pivot können die Properties in Sensoren und Actuatoren verwenden.
• Ich bin mir nicht sicher, ob eine Unterscheidung zu normalen Properties nötig ist, also eine eigene KX_GameObject.getGroupPropertyNames() oder integriert in getPropertynames()
• Es sollte eine Abfrage obj["groupProperty"] funktionieren.

Ich denke das mit sowas ein unglaublich mächtige Werkzeug zu Verfügung steht. Die Integration unterstützt Python und Logic bricks gleichermaßen.


Falls das dann doch zu komplex ist, wie wärs mit eienr Erweiterung des Parent Actuator: neuer Schalter statt "Parent Object:___" umschalten auf "To Pivot" (erspart den Python controller). Beispiele: Body feld des Message Controllers u8nd M/P beim Collison sensor.

Auf jedenfall ist die angedachte API Erweiterung ein echter Gewinn
Monster

[moerdn]

Am besten wäre es die ganze Idee mal als eine Art proposal im Blender Wiki zu platzieren und auf der mailingliste den Vorschlag zu machen. Ich würde erst mal noch die Änderungen mit der Liste und den Referenezen vornehmen und noch ein kleines Video basteln, welches das Feature demonstriert. Damit sollte man die Jungs dann evtl überzeugen können, das diese Erweiterung ein must-have ist.

Würde dann nen Patch dazu bauen. Allerdings gibt es gerade Probleme mit der GE bei aktuellen Revision. Meine Beispiel Implmentierung ist noch für 2.56.

Wenn das klar geht könnte man dann auch über GUI Erweiterungen nachdenken. Sollte alles machbar sein. Wenn man auf ein Python Script zum Parentieren verzichten kann, dann ist das natürlich noch besser. Lässt sich jedenfalls noch gut ausbauen.

mfg, der moerdn

[Touny]

Also für mich ist das bestenfalls ein kleines "irgendwie am Leben erhalten" und keinesfalls ein "auf den aktuell nötigen Stand bringen".
Alles, was ihr erhofft, gibt es in anderen GameEngines schön längst (Unity...). Warum rumquälen?

Sagt, wenn ich mit meinen Negativ-Posts im GE-Bereich aufhören soll . Aber das Arbeiten mit der GE hat mich echt ernüchtert.

[moerdn]

OT:
Sie wird nicht für jeden Zweck optimal sein. Wenn du Spiele im herkömmlichen Sinne entwickeln willst, gibt es wohl sehr viel bessere Lösungen.

Für unsere Forschungsprojekte werden aber ganz andere Qualitäten gefordert als das was Unity oder Unreal bietet. Wir benötigen nicht die neusten Shader und die Über-Performance. Viel wichtiger ist es den Code ändern, anpassen und erweitern zu können.

Die Blender GameEngine läuft bei uns als Mutlitouch Table Framework und als Virtual Cave mit beliebig vielen Leinwänden. Alles in Stereo, mit Headtracking und Wiimote (später evtl auch Kinect) Support.

Ich wage stark zu bezweifeln, das du das auch nur annähernd mit einer Proprietären Software Lösung hin bekommst.

mfg, der moerdn

[moerdn]

Habs soweit implementiert mit Liste und pivot. Funktioniert auch nach ersten Tests, bekomme aber ein Zombie Object für jedes Objekt der Gruppe bei der Instanzierung. Das muss noch behoben werden. :/

EDIT: ne, ich glaub ich habs hin bekommen. Sollte jetzt funktionieren.

@Monster:
Dein Code Snippet funktioniert

Code: Alles auswählen

##
# Für Parentierung innerhalb der Gruppe an das Dupli Group Pivot
#
import bge

def main():
    con = bge.logic.getCurrentController()
    own = con.owner
   
    print(own.pivot, own.instances)
   
    own.setParent(own.pivot)
main()


Und auch die Parentierung außerhalb:

Code: Alles auswählen

import bge
   
def main():
    con = bge.logic.getCurrentController()
    own = con.owner
   
    print(own.pivot, own.instances)
   
    roots = [obj for obj in own.instances if obj.parent is None]
    for root in roots:
        root.setParent(own)

main()


mfg, der moerdn

[Monster]

Moerdn das isst ja wahnsinn, Du bist der Größte! Einfach so mal eingebaut Klasse sag ich da.

Monster

[moerdn]

Danke aber so schwer wars jetzt nicht. Ich probiere gerade meine Blender Build Umgebung auf Windows zum Laufen zu bringen und vielleicht bekomme ich es auch hin einen einigermaßen brauchbaren Linux Build zu erstellen.

EDIT: scheint unter Win alles reibungslos zu laufen. Ich lade dann nachher Patch und Windows Build hoch.

mfg, der moerdn

[moerdn]

Hier nun die Download Links:

• Partikelsystem Video
• Group Reference Patch
• Blender 2.57.1 Windows Build 32 Bit

Der Patch und Review Prozess. *Klick* Klingt recht Tricky, sollte man also gut verpacken damit er eine Chance auf Aufnahme hat.
- vorher mal Moguri oder Campbell fragen
- Proposal schreiben mit detaillierter Beschreibung, Nutzen etc.
- einfache Beispiele und Blendfiles zum Testen bereitstellen
- ein Video was die Funktionsweise demonstriert
- sollte evtl noch ein paar comments machen im Code, naja sehr viel ist es ja nicht.
und dann ab auf die mailingliste damit

Hier noch einmal eine Liste mit angedachten Verbesserungen für die GE. Zu Gruppen habe ich nix gefunden
Und hier noch der Thread zum Komponenten Branch von Moguri:
http://blenderartists.org/forum/showthr ... ch-Created
Auch ein sehr interessantes Feature.

EDIT:
Ein vollständig parametrisierbares Partikelsystem:
http://www.youtube.com/watch?v=6Uy_YdDAqCk
Erklärung dazu:
viewtopic.php?f=12&t=27387&start=520

[Monster]

Das funktioniert ja richtig gut. Allerdings ruckelt die Testversion bei mir das ist aber bestimmt was anderes.
Auf jedenfall eine unglaublich gute Verbesserung.

Richtig cool