Ogre3D bietet die Möglichkeit eigene Funktionen bei einem FrameStart und einem FrameEnd auszuführen. Damit Ihr das nicht in C++ machen müsst habe ich die Möglichkeit eingebaut BlitzMax Funktionen durch Ogre3D ausführen zu lassen.

Im Falle des FrameListeners muss man zunächst einen eigenen Type von FrameListener ableiten: BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

Type myFrameListener Extends FrameListener

Wenn Ihr nun eine Instanz von diesem Type erstellt besitzt dieses die beiden abstrakten Funktionen frameStarted() und frameEnded(). Diese beiden Funktionen müssen in Eurem Type definiert, also "ausgeschrieben" werden. Selbst wenn Ihr nur schreibt BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

Function frameStarted(); End Function

Beispiel:

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

Type myFrameListener Extends FrameListener
        Function frameStarted()
                rem
                        do some things at frame start
                endrem
        End Function
        
        Function frameEnded()
                rem
                        do some things at frame end
                endrem
        End Function
End Type
Local fl:myFrameListener = New myFrameListener

Wie man sieht passiert in diesen Funktionen nichts. Würde man bspw. in frameStarted() folgendes hineinschreiben: BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

DebugLog "Hallo Welt"

, dann würde bei jedem FrameStart der Text "Hallo Welt" in die Konsole ausgegeben werden.

Die Instanz von Eurem FrameListener kann nun an Ogre3D übergeben werden, die Methode dazu findet Ihr unter Root.addFrameListener(listener:FrameListener)

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

myRoot.addFrameListener(fl)

Die Examples laufen wieder und ich habe soeben r36 hochgeladen. Nebenbei habe ich auch den "Featured Download" aktualisiert so dass auch alle ohne SVN die neue Version testen können: SEDM.mod + Examples (precompiled, inkl. Source) Revision 36 (ca. 20MB)

Changelog:
Code: [AUSKLAPPEN] [EINKLAPPEN]

Ach Du Schei***, seit zwei Tagen kein SVN Update ... hat der Typ etwa hingeworfen?


Nein, es darf auch mal zwei Tage ohne Update geben. Ich habe einiges am Modul sedm.blitz3dogre.mod umgebaut. Das wurde nach dem Umbau des sedm.bullet.mod nötig weil ich nun irgendwo das RigidBody eines Entity sichern muss. Vorher war das Entity Handle einfach ein Handle auf das Type "Entity", dieses ist aber Bestandteil von sedm.bo3d.mod und sollte keine Bullet Daten halten. Also musste ich das Type "B3DEntity" für das HighLevel Interface einführen um dort die Physik-Daten zwischen zu speichern (man erinnere sich: Blitz3DOgre verwendet per Default Bullet für Kollisionen und Physik).

Desweiteren habe ich mir in BMax das ewige durchrennen der Entity-Liste vom Hals geschafft indem ich nun TMap verwende um die Objekte mittels ihres Namens zu bekommen. Da Ogre3D ohnehin für jedes Objekt einen Namen haben will fand ich das ganz praktisch.
Da ich eh sämtliche Methoden und Funktionen des HighLevel Interface bearbeiten musste habe ich auch gleich den Direktzugriff für alles auf das Basisobjekt auf den Zugriff mittels "Getter" umgestellt wie er schon vor Äonen von Revisionen eingeführt wurde.

Leider funktioniert derzeit bullet.mod nicht so wie ich das gern hätte ... aus irgendeinem Grund wird die AxisAlignedBox nicht mit Daten gefüllt ... aber das ist nur ein kleines Fehlerchen.

TRigidBody.Create() wurde um den Parameter "userControlled" bereichert (ebenso die Blitz3DOgre Funktion "DynamicEntity()". Dieser Parameter bewirkt dass ein Objekt zwar Kräfte auf andere Physik-Objekte ausübt, selbst aber nicht von physikalischen Effekten tangiert wird. Stelle Dir ein Paddle auf einem Breakout-Tisch vor: Es soll den Ball abstoßen, aber selbst nicht vom Ball bewegt werden.

Wer das nicht bei einem Create() entscheiden will darf die Funktion "TBullet.userControlledBody()" auch nach dem erstellen eines RigidBody anwenden. Für Liebhaber des HighLevel Interface habe ich zwar derzeit noch keine Funktion am Start die das regelt, aber ich denke da kann ich noch was machen.

Im Moment liegt der Fokus auf der Physik und den normalen Kollisionen im Blitz3D-like (HighLevel Interface) Style. Bullet besitzt Funktionalitäten die es mir gestatten die Kollisionserkennung genauso zu gestalten wie es Blitz3D handhabt, allerdings dann nur für userControlledBodies. Normale Dynamics kann ich zwar nach ihrer Kollision befragen, aber nicht daran hindern dass sie auf eine Kollision physikalisch korrekt reagieren. Das heißt dass für Blitz3D Umsteiger ein kleines Klitzebisschen Umdenken angesagt ist: Alles kann wie in Blitz3D für Kollisionen konfiguriert werden, nichts wird so reagieren wie in Blitz3D gewohnt (ein Slide gibt es nicht, entweder physikalisch korrekt oder selbst auf die Kollision reagieren).
Allerdings sind das marginale Änderungen auf die man gelassen warten kann.

Heute war ich beruflich etwas eingespannt und konnte nicht all das schaffen was ich geplant hatte, aber morgen wird es wieder ein Update geben ... das mit Tisch, Paddle und Ball.

Da es nicht ohne Weiteres möglich ist in Ogre3D einen Shader-Parameter per Frame zu ändern (geht schon, aber für den Aha-Effekt ist das gerade zuviel Aufwand) habe ich mich wieder den Kollisionen zugewandt. Ich habe jetzt noch mehr Funktionalität in die DLL verlagert. Zwar bedeutet das weniger Kontrolle auf der BlitzMax Seite, dafür aber mehr Speed und weniger MemLeaks im Allgemeinen.

Im Sample fallen die Kisten nun wieder, allerdings vorerst nur mittels LowLevel API, das HighLevel API Example ist derzeit nicht funktionstüchtig.

Wer mal gucken will ob bei ihm die Kisten korrekt purzeln kann sich das Example herunter laden (ca. 10MB). Das Archiv wird wieder kleiner wenn ich wieder die Release DLLs und Libs verwende.

Es ist zu beachten dass die Klasse "Quaternion" sowohl in bo3d.mod (als Type Quaternion) als auch in bullet.mod (als bQuaternion) definiert ist und nicht zu casten geht (warum auch immer). Als nächstes werde ich ein weiteres Modul (sedm.std.mod) basteln welches beide Module verwenden können damit zumindest dieser Datanaustausch klappt.

Das Modul "bullet.mod" ist übrigens vollkommen unabhängig von bo3d, wer möchte kann es auch für den SoftPixelWrapper von LukasBanana oder irgendeine andere Engine verwenden. Mit ein paar Tricks lässt sich das Modul auch für 2D Spiele verwenden.


Alle weiteren Updates findet man wie immer im SVN.

Das SVN geht wieder und es sind schon wieder einige Updates hochgeladen worden. Die r33 nehme ich als Anlass hier wieder einen Eintrag zu verfassen da es erst dort wieder Änderungen gibt die man auch mit einem "spannenden" Screenshot vermarkten kann.



ShaderParameter lassen sich nun beeinflussen (derzeit nur einmalig, nicht zur Laufzeit). Im Bild seht ihr einen Bloom-Effekt der bescheuert hoch aufgedreht wurde.

Damit auch die Nutzer des Blitz3D-API in den Genuss kommen Ogre3D in einem Canvas (oder wo auch immer) rennen zu lassen, habe ich die Funktion "Graphics3DExt()" hinzugefügt. Diese besitzt ein paar mehr Parameter, unter anderem den Parameter "hWnd" welcher bekannt gibt in welchem Kontext man denn gerne sein Ogre3D sehen würde.

Um an die ShaderParameter zu kommen sind ein paar mehr Schritte nötig als ein einfaches BrushFX fähig wäre. So muss man sich erstmal den Brush holen (GetEntityBrush() ist ja noch einfach) ... dann holt man sich die Technique in der der Shader deklariert wurde und dann den Pass innerhalb der Technique der die notwendigen Parameter bekannt macht. Die LowLevel API Nutzer müssen den ganzen Kram eh selbst machen, für die Blitz3D-API Fans denke ich mir da noch eine Vereinfachung aus, bis dahin muss jeder B3D-API Nutzer halt folgendes machen:
BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

' Fullscreen FX "Bloom"
ScreenFX(cam, "Bloom")

mat = GetBrushByName("Ogre/Compositor/BloomBlend2")	' get the Fullscreen FX Brush
tech = GetBrushTechnique(mat) ' get Brush Technique
pss = GetBrushPass(tech) ' get then Technique Pass
pars = GetPassPars(pss) ' get the GPU FragmentProgramm Parameters of this Pass

SetBrushConstantF(pars, "BlurWeight", 2.0)	' set the Parameter "BlurWeight" to 2.0 (oh my god!)
SetBrushConstantF(pars, "OriginalImageWeight", 1.0) ' set the Parameter "OriginalImageWeight" to 1.0

Sobald die Möglichkeiten drin sind diese Parameter auch dynamisch zur Laufzeit zu kontrollieren widme ich mich wieder den Kollisionen.

Zum Abschluss noch das gesamte Example in Blitz3D like Form
BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

Framework  sedm.blitz3dogre
Import brl.polledinput

phys:TBullet = New TBullet
phys.setGravity()

AppTitle = "BlitzOgre3D / Blitz3D-like API"

Graphics3D(800, 600)
AmbientLight(0.1, 0.1, 0.1)

SetShadowTechnique(SHADOWTYPE_TEXTURE_MODULATIVE)
SetShadowTextureSize(1024)
setShadowFarDistance(100.0)

LoadSkyBox("media.zip/SkyBox.material")

cam = createCamera()

' Fullscreen FX "Bloom"
ScreenFX(cam, "Bloom")

mat = GetBrushByName("Ogre/Compositor/BloomBlend2")	' get the Fullscreen FX Brush
tech = GetBrushTechnique(mat) ' get Brush Technique
pss = GetBrushPass(tech) ' get then Technique Pass
pars = GetPassPars(pss) ' get the GPU FragmentProgramm Parameters of this Pass

SetBrushConstantF(pars, "BlurWeight", 2.0)	' set the Parameter "BlurWeight" to 2.0 (oh my god!)
SetBrushConstantF(pars, "OriginalImageWeight", 1.0) ' set the Parameter "OriginalImageWeight" to 1.0
	
player	= CreatePivot()
CameraRange(cam, 0.1, 10000)

EntityParent(cam, player)
PositionEntity(player, 0.0, 10.0, -40.0)

l = CreateLight()
PositionEntity(l, 10.0, 100.0, 100.0)

box 	= LoadMesh("media.zip/box.mesh")
ground	= LoadMesh("media.zip/ground.mesh")

PositionEntity(ground, 0.0, -5.0, 0.0)

box2	= CopyEntity(box)
PositionEntity(box2, -10.0, 0.0, 7.0)

EntityShadows(ground, False)


Repeat
	mx = MouseXSpeed()
	my = MouseYSpeed()
	
	If KeyDown(KEY_W) Then MoveEntity(player, 0.0, 0.0, 0.1)
	If KeyDown(KEY_A) Then MoveEntity(player, -0.1, 0.0, 0.0)
	If KeyDown(KEY_S) Then MoveEntity(player, 0.0, 0.0, -0.1)
	If KeyDown(KEY_D) Then MoveEntity(player, 0.1, 0.0, 0.0)
		
	If MouseDown(2)
		TurnEntity(player, 0.0, -mx * 0.01, 0.0)
		TurnEntity(cam, -my * 0.01, 0.0, 0.0)
	EndIf
		
	RenderWorld()
	
Until KeyDown(KEY_ESCAPE)

phys = Null

End

Alle Updates können wie immer aus dem SVN gezogen werden

Ich habe mir heute das SVN zerschossen weil ich aus Versehen den Ordner ".svn" in "sedm.mod" gelöscht habe. Es gibt nun bei einem Commit (den ich nur noch auf einzelne SubDirs anwenden kann) nicht nachvollziehbare Fehler.

Wenn jemand einen Tipp hat wie ich das mit TortoiseSVN reparieren kann wäre ich sehr dankbar

Nebenbei habe ich ja heute den CompositorManager rudimentär eingeführt und der funktioniert auch auf alle PostProcess Effects die nicht mit Werten versorgt werden möchten. Da Ogre für den Vorgang des "Werte zuweisen" wieder zwei Hände voll Klassen und eine Arbeitsagenturwartehalle voll Parameter für den einfachen Vorgang eines "set" vorsieht muss ich noch ein bisschen stricken bis jedwedes CG Programm funktioniert.

Das SVN propagiert gerade irgendwas von Revision 30, das stimmt aber nicht. Eigentlich ist es r29 und auch das ist unvollständig weil SVN nicht in der Lage ist seine Positionsdaten selbst zu verwalten. Anscheinend wohnt der Head dieses Projekts noch bei Mama.

Ich versuche über das Wochenende den Krimskram zu reparieren, bis das passiert ist habe ich das komplette Archiv als Download hochgeladen. Einfach ins SVN gehen und auf "Downloads" klicken.

Heute waren wieder hauptsächlich Brushes das Tagesziel. So habe ich diverse Brush Commands im HighLevel_API implementiert und ganz ganz viele Material Methoden im LowLevel Interface.

Desweiteren kam für das HighLevel API noch die Funktion "SetShadowFarDistance(distance:Float)" hinzu da ich festgestellt habe dass GPU Shadows ab und zu nicht sichtbar sind wenn man die maximale RenderRange der Schatten nicht vernünftig setzt. Bitte beachten: Die derzeit implementierten Schatten-Modi sind die die Ogre3D von Haus aus mitbringt. Es gibt andere und bessere Möglichkeiten Schatten zu implementieren, aber das muss dann jeder für sich selbst mittels Shader machen. Für die meisten Anwendungen reichen die vier Schatten-Modis der Engine aber aus.

Was an der Material Klasse passiert ist war hauptsächlich stoisches Abarbeiten der Ogre::Material Class um da mal zu einem Ende zu kommen. Außerdem soll demnächst ein Material-Editor als Beispiel für die Nutzung von MaxGUI und Ogre3D hinzu kommen.

Wichtig wäre vielleicht noch zu erwähnen dass die Blitz3D Funktionen BrushBlend und BrushFX fast vollständig implementiert worden sind ("fast" deshalb weil mir BrushFX() VertexColors noch Sorgen macht, das ist aber das einzige Flag das ich noch nicht umsetzen konnte). Beiden Funktionen wurden weitere Flags spendiert. So kann BrushBlend nun auch mit BLEND_COLOR (Farbtransparenz als Gegenstück zu Alpha-Transparenz) und BLEND_REPLACE aufgerufen werden. Prinzipiell sind zu den dokumentierten BlendModes nur die Modes 4 und 5 hinzugekommen.
Bei BrushFX wurde die Liste der Flags noch um den Wert 32 erweitert, dieser definiert ob auch transparente Objekte einen Schatten werfen dürfen.

Angefangen wurde heute der eigenständige Bullet-Wrapper. Dieser kann zu sedm.bo3d hinzu importiert werden, sedm.blitz3dogre.mod importiert sedm.bullet.mod automatisch und realisiert damit Kollisionen. Derzeit ist das Modul wirklich nur "angefangen", es beinhaltet zwei Klassen mit jeweils einer Methode und das wars. Selbstverständlich wird das noch großzügig ausgebaut.
Das Bullet Module wird (bis auf Einzelheiten die in BMax nicht umsetztbar sind (bspw. mangels Parameter für den Konstruktor oder mangels echtem Destructor)) exakt so übernommen wie die Bullet Physics Engine dies vorgibt. Die Klassen heissen gleich, die Methoden tragen denselben Namen. Gäbe es echte Kontruktoren und Namespaces in BlitzMax könnte man dasselbe fast auch für Ogre3D machen.

Zum Abschluss noch das Commit-Log der Revision 27 und ein Screenshot auf dem man ein wenig von den Brush-Funktionen sieht. Mehr von den Brush-Funktionen sieht man im Module und im beigelegten Sample. (Beachte: Das Sample liegt immer in sedm.mod/bo3d.mod/example ... würde ich für jedes Modul einen eigenen Example Ordner anlegen müsste ich auch immer alle DLLs dort mit reinpacken und das Archiv wäre jetzt schon vier Mal so groß.
Code: [AUSKLAPPEN] [EINKLAPPEN]



Das ganze Paket, inkl. Source für alle Module und Examples sind wie immer im SVN abrufbar.

Heute habe ich mich fast ausschliesslich mit der Klasse "Material" beschäftigt, denn diese ist äußerst wichtig. Die Klasse "Material" ist sowas wie die Brushes in Blitz3D, nur um einiges umfangreicher und mächtiger.

Code: [AUSKLAPPEN] [EINKLAPPEN]
Neben o.g. Neuerungen sind auch einige Sachen umgebaut worden. Während ich einige Parameter in C/C++ immer erst durch eigene Neudefinitionen erstellt habe und diese dann per switch() auf die Ogre Werte gesetzt habe, musste ich nun feststellen dass das nicht immer notwendig ist ... was natürlich wieder ein klein bisschen Speed bringt. Nach und nach werde ich nun alle "Eigendefinitionen" zurück nehmen und direkt die Ogre3D Werte verwenden. Im Type "Material" ist dies bereits passiert.

Sobald ich die Material-Klasse durch habe folgen noch die Klassen "Technique" und "Pass". Eigentlich kann man all das auch direkt durch Ogre3D MaterialScripts erledigen, aber evtl. will man ja hier und da auch mal prozeduale Materialien einsetzen. Zudem kann ich ohne diese Funktionen die Blitz3D Brush-Funktionen nicht "emulieren".

Das SVN steht nun auf Revision 26. Mod-Source, C-Source, Example Source und benötigte Files sowie ein Executable liegen wie immer bei.

Es ist noch ordentlich was zu tun, gehen wir es an.

Der 100ste Eintrag in diesem Worklog .... PAAAAARTY!

Jetzt im Ernst und im Horst:

Heute hatte ich wieder nur wenig Zeit, aber die habe ich genutzt um das MaterialSystem (in Blitz3D "Brushes") anzufangen.



Zunächst der Source zum obigen Bild:
BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

Framework  sedm.blitz3dogre
Import brl.polledinput

AppTitle = "BlitzOgre3D / Blitz3D-like API"

Graphics3D(800, 600)
AmbientLight(0.1, 0.1, 0.1)

SetShadowTechnique()
LoadSkyBox("media.zip/SkyBox.material")

cam = createCamera()
player	= CreatePivot()

CameraRange(cam, 0.1, 1000)

EntityParent(cam, player)
PositionEntity(player, 0.0, 10.0, -40.0)

l = CreateLight(LT_POINT)
PositionEntity(l, -100.0, 100.0, -100.0)

box 	= LoadMesh("media.zip/box.mesh")
ground	= LoadMesh("media.zip/ground.mesh")

PositionEntity(ground, 0.0, -5.0, 0.0)

box2	= CopyEntity(box)
PositionEntity(box2, -10.0, 0.0, 7.0)

box_brush = CopyEntityBrush(box2)
BrushColor(box_brush, 255, 0, 0)
BrushShininess(box_brush, 1.0)

PaintEntity(box2, box_brush)


EntityShadows(ground, False)

Repeat
	mx = MouseXSpeed()
	my = MouseYSpeed()
	
	If KeyDown(KEY_W) Then MoveEntity(player, 0.0, 0.0, 0.01)
	If KeyDown(KEY_A) Then MoveEntity(player, -0.01, 0.0, 0.0)
	If KeyDown(KEY_S) Then MoveEntity(player, 0.0, 0.0, -0.01)
	If KeyDown(KEY_D) Then MoveEntity(player, 0.01, 0.0, 0.0)
	
	If MouseDown(2)
		TurnEntity(player, 0.0, -mx * 0.01, 0.0)
		TurnEntity(cam, -my * 0.01, 0.0, 0.0)
	EndIf
	
	RenderWorld()
Until KeyDown(KEY_ESCAPE)

End

Bevor ich das näher erläutere, hier die Änderungen in Revision 25:
Code: [AUSKLAPPEN] [EINKLAPPEN]

Vieles was man aus Blitz3D kennt ist gleich, aber einiges ist ein wenig anders.

GetEntityBrush() holt das Material des SubEntity Nummer 0 aus "Entity". Das ist i.d.R. das gesamte Mesh. Ogre3D gestattet es aber einem Entity beliebig viele SubEntities zuzuordnen (in Blitz3D wären das "Childs") und diesen eigene Materialien zuzuweisen. Im Moment beeinflussen die Brush-Funktionen immer das gesamte Entity. Sobald ich die Child-Funktionen eingebaut habe wird sich das ändern.

Entities die per CopyEntity() erzeugt worden sind teilen sich ihr Material mit dem Entity von dem sie kopiert worden sind. So beeinflusst ein BrushColor() alle Entitiy-Kopien. Damit man einem kopierten Entity eigene Materialeigenschaften zuweisen kann habe ich die Funktion "CopyEntityBrush()" eingeführt. Das macht augenscheinlich dasselbe wie "GetEntityBrush()", erzeugt aber ein neues Material welches unabhängig vom Parent definiert werden kann.

Die allerbeste Methode in Ogre3D Materialien zu definieren ist aber immer noch ein Script für das Objekt zu erzeugen

Aufjepasst: Auch wenn im Type "Entity" die Methode "setMaterial()" bereits existiert: NICHT benutzen, es lässt Euch einiges an Speicher verlieren und crasht beim beenden der App. Sobald ich dieses Problem gelöst habe taucht die Methode auch im ChangeLog auf ... bis dahin benützt einfach "setMaterialName", die Method ist sicher.

Nochwas zum beachten: Ogre3D verwendet für Farbangaben stets Werte zwischen 0 und 1 während Blitz3D da recht unbeständig ist. Ich habe versucht im Blitz3D-like Interface dies zu berücksichtigen. Haltet Euch also, wenn es um Blitz3D geht, an die Blitz3D Doku.

Neben der Implementierung von Schatten habe ich heute noch einen Bug entfernt der verhindert hat dass man Resources direkt aus einem Zip Archiv laden kann. Jetzt kann man folgendes schreiben um ein Mesh oder eine Skybox oder whatever aus einem Archiv zu laden:
Code: [AUSKLAPPEN] [EINKLAPPEN]

Ja, Skybox laden ist nun auch wieder drin. Während das LowLevel API exakt so funktioniert wie es in Ogre3D passiert, muss man mit dem HighLevel API nur "LoadSkybox()" bemühen. Wichtig ist: Man lädt keine Texturen, sondern ein Material und das Material-File muss exakt so heissen wie das Material selbst ... Ogre3D ist case-sensitive!

HighLevel API User die Resourcen aus ZIP Archiven nutzen wollen müssen ihr Archiv auf ".zip" enden lassen, während es den LowLevel API Nutzern egal sein kann wie das File heißt (myFuckingFreshArchiv.kiss geht auch) da sie ja den LocationType angeben können welcher im Falle eines Archivs einfach "Zip" lautet.

Bei den Schatten hat sich einiges getan, prinzipiell das was ich schon hatte ... nur das LowLevel User jetzt wesentlich mehr Möglichkeiten haben die Sache zu optimieren als das vorher der Fall war da ich ja direkt die Ogre3D Funktionalität durchschleife. Das beigelegte Beispielprogramm zeigt Textureshadows auf einer 512x512 Textur. Sowohl LowLevel als auch HighLevel API User haben die Möglichkeit die Art des Schattens und die Größe der ShadowTexture selbst zu bestimmen.

Wer gern HighLevel programmiert aber hin und wieder auf die Methoden des LowLevel API zugreifen möchte, für den habe ich angefangen ein Interface zu implementieren. Derzeit gibt es nur "getSceneManager()" aber das wird noch erweitert. Wem also das "LoadSkyBox()" mit seinen Möglichkeiten nicht genügt, der darf auch "getSceneManager().setSkyBox()" verwenden um an alle Parameter des Ogre3D Originals zu kommen. Allerdings muss derjenige dann auch dafür Sorge tragen das alle Voraussetzungen für diese Methode erfüllt sind, bspw. dass das Verzeichnis aus dem die Skybox geladen werden soll dem ResourceGroupManager bekannt gemacht worden ist.

hier die Änderungen in r23 und r24
Code: [AUSKLAPPEN] [EINKLAPPEN]

Und zur Abwechslung mal wieder ein Screenshot:


Wie gehabt findet sich all das im SVN, ein ausführbares Example liegt im Ordner "sedm.mod/bo3d.mod/example/" bereit.