Source: https://www.blendpolis.de/viewtopic.php?f=15&t=34215
Timestamp: 2017-02-21 18:45:04+00:00

Document:
von moerdn » 23.05.2011, 09:55 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.htmlLicense: * 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” canbe 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 missingdata-types. Mitchell will come up with a list of todos and rebranchwith working code (trying to use an existing branch if possible) * The GSoC Recast/Detour branch is stable enough to merge, and Nickwill prepare it for merging in the next couple of weeks. * The TexFace removal feature is almost ready. Dalai will be givingthe patch a “final treatment” this week/next. * A list of smaller features will be sent to the mailing list for reviewRecast&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, separaterender thread to make use of swap buffer wait time, etc) [NOTE: Thisone'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 feedbackEs scheint so, als werden langsam alle Missstände ausgeräumt. Bin echt beeindruckt und voller Vorfreude.mfg, der moerdn
Zuletzt geändert von moerdn am 13.05.2012, 10:23, insgesamt 1-mal geändert.
von mpue » 23.05.2011, 11:52 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/Javazigfach schneller.Weiterhin fehlt mir eine Art Projekt Ansicht, wo ich alle Scripte in einer Art Baum sehenkann 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 wiederumAuto 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
_______________________________________________________________________Soundcloud | Blog | Youtube Kanal | Neuer Remix : TAPETE - Kalt | Neues Video : Concierge
Registriert:05.05.2003, 14:24
von moerdn » 23.05.2011, 13:02 ReSeT hat geschrieben:Der Python Editor hat definitiv eine Renovierung nötig, das Teil ist wirklich aus demletzten 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/Javazigfach 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.ReSeT hat geschrieben:Weiterhin fehlt mir eine Art Projekt Ansicht, wo ich alle Scripte in einer Art Baum sehenkann und an welchen Controllern sie hängen. Stimmt, da gebe ich dir Recht.ReSeT hat geschrieben: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.ReSeT hat geschrieben: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.ReSeT hat geschrieben: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.ReSeT hat geschrieben: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
von mpue » 23.05.2011, 14:51 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 unddas heisst nicht daß Blender nicht trotzdem ein großartiges Tool wäre.
von Monster » 24.05.2011, 06:37 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
von moerdn » 24.05.2011, 08:27 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öschtmfg, der moerdn
von moerdn » 24.05.2011, 13:41 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() Methode3. 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 GruppenHabe 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 bisherpivot = scene.addObject("Gruppen_Instanz", own)base = pivot.base # das base Objekt der Gruppebase.position = ... # etcprint(pivot.base) # Das Toplevel Gruppenelement konvertiert in stringpivot.base.setParent(pivot) # mache den pivot zum Elternobjekt von baseprint(pivot.base.base) # None, da base keine base hatFü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ählendef 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' funktioniertCode: Alles auswählendef 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=pxR6eLeVZJAmfg, der moerdn
von Monster » 24.05.2011, 22:30 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üßeMonster
von moerdn » 24.05.2011, 22:42 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
von Monster » 25.05.2011, 06:44 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ählendef parentToPivot(cont): cont.owner.setParent(cont.owner.pivot) # cont.owner=FaßUnd trotzdem vom Pivot aus:Code: Alles auswählendef 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 = pivotWenn 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 .
von moerdn » 25.05.2011, 07:48 Monster hat geschrieben: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.Monster hat geschrieben: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 machenKlar, 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
von Monster » 25.05.2011, 08:09 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
von moerdn » 25.05.2011, 08:24 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
von Touny » 25.05.2011, 08:31 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.
von moerdn » 25.05.2011, 09:02 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
von moerdn » 25.05.2011, 10:27 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 funktioniertCode: Alles auswählen### Für Parentierung innerhalb der Gruppe an das Dupli Group Pivot#import bgedef 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ählenimport 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
GroupAPI_New.blend
Auch wenns nicht viel nützt, hier das Testfile.
(77.14 KiB) 60-mal heruntergeladen
von Monster » 25.05.2011, 20:17 Moerdn das isst ja wahnsinn, Du bist der Größte! Einfach so mal eingebaut Klasse sag ich da.Monster
von moerdn » 26.05.2011, 08:28 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
von moerdn » 26.05.2011, 12:39 Hier nun die Download Links:Partikelsystem VideoGroup Reference PatchBlender 2.57.1 Windows Build 32 BitDer 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 damitHier 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-CreatedAuch ein sehr interessantes Feature.EDIT:Ein vollständig parametrisierbares Partikelsystem:http://www.youtube.com/watch?v=6Uy_YdDAqCkErklärung dazu:viewtopic.php?f=12&t=27387&start=520
Ein Partikelsystem Test mittels parentierten Gruppeninstanzen
von Monster » 26.05.2011, 21:34 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 Monster
Mitglieder in diesem Forum: Manuel Engel 91 und 3 Gäste

References: BGE 
 BGE 
 BGE 
 BGE 
 BGE 
 BGE 
 BGE 
 BGE 
 BGE 
 BGE 
 bge