06.07.2026, 19:02
Huhu,
Ich hab mich mal etwas schlau gemacht:
Ein echter Pluspunkt von Bepu hier
Bepu ist reines Managed C#. BulletSim (libBulletSim.so) und ubODE (native ODE) brauchen dagegen pro Plattform eine native Lib – weshalb z.B. auf ARM64 beide eine fatale Exception werfen und man ohne Physik fahren muss. Ein Bepu-Plugin hätte dieses Problem gar nicht. Für Multi-Plattform/ARM ist das ein starkes Argument. Docker Hub
Aufwand – grob nach Bereichen
Ich gebe bewusst keine Stundenzahl, das wäre geraten. Aber die Arbeitspakete lassen sich benennen (nach Aufwand grob absteigend):
Vehicles – das dickste Brett. Das SL/OpenSim-Vehicle-Modell (Linear-/Angular-Motoren, Deflection, Banking, Buoyancy, Hover, Reference Frames) ist in BulletSim/ubODE fertig implementiert. Bepu gibt dir nur Constraints und Kräfte – das komplette Modell müsstest du selbst obendrauf bauen. Das ist der Bereich, wo „fühlt sich nicht an wie SL"-Beschwerden entstehen.
Avatar-Controller – Bepu hat keinen fertigen Character Controller, nur ein Demo-Beispiel. Das musst du adaptieren und tunen (Laufen, Fliegen, Bodenkontakt, Push).
Prim-Shapes / Meshing – Box/Sphere/Cylinder trivial; Sculpts und Mesh-Prims kommen über OpenSims IMesher als Dreiecksnetze/Convex Hulls. Für dynamische, nicht-konvexe Objekte brauchst du Convex-Decomposition (Bepu bringt das nicht mit) und Compound-Shapes.
Terrain – Bullet nutzt ein Heightfield; Bepu hat keine Heightfield-Primitive, du baust aus SetTerrain(float[]) ein Mesh. Machbar, etwas mehr Speicher.
Collision-Events – collision_start/collision/collision_end inkl. Paar-Reporting musst du aus Bepus NarrowPhase-Callbacks selbst aggregieren.
Stepping/Threading – OpenSim ruft Simulate(dt) im Region-Heartbeat; Bepus IThreadDispatcher sauber mit OpenSims Threadpool zu verheiraten braucht Sorgfalt, ist aber Standard.
Kräfte/Params – Buoyancy, llPushObject, Friction/Restitution/Density: über Impulse und Pose-Integrator-Callbacks gut abbildbar.
Ein Prototyp „Avatare + statische/dynamische Prims + Terrain-Kollision" ist relativ schnell machbar; Parität zu BulletSim (insb. Vehicles und volle LSL-Physik-Parameter) ist ein Projekt über viele Monate für eine erfahrene Person. BulletSim ist selbst eine große, gereifte Codebasis – das ist die Messlatte.
Als Referenz/Template: Es gibt eine ausgereifte Bepu-v2-Integration in die Stride-Engine (Nicogo1705/Stride.BepuPhysics), die genau die Bausteine liefert, die dir fehlen – Character-/Car-Controller, Mesh-/ConvexHull-Collider, Trigger, RayCast/SweepCast. Nicht direkt übertragbar, aber sehr nützlich als Vorlage für Character- und Vehicle-Logik. GitHub
Kein absoluter Showstopper, aber Risiken:
Verhaltensparität: Bepus Solver verhält sich anders als Bullet/ODE; für eine Engine getunter Content wird sich anders anfühlen. OpenSim kennt das Problem aber schon zwischen Bullet und ubODE.
Determinismus: Bepu v2 (float) ist nicht garantiert cross-platform-deterministisch. Für server-autoritative Single-Node-Regionen egal – nur relevant, falls du irgendwo auf reproduzierbare Physik über Maschinen hinweg baust.
Maintenance: Bepu ist im Kern ein Ein-Personen-Projekt (Apache-2.0, stabil, aber Bus-Faktor beachten).
Wo ich ehrlich unsicher bin und du prüfen solltest:
Ob schon jemand ein Bepu-Plugin für OpenSim angefangen hat – ich habe in der Suche nichts gefunden, kann es aber nicht ausschließen. Würde ich vor Projektstart gezielt suchen (OpenSim-Foren/Mantis, GitHub).
Die exakten Interface-/Namespace-Namen im .NET-8-Branch – die wurden über die Versionen umbenannt; die Struktur (PhysicsScene/PhysicsActor, AddAvatar, SetTerrain, Tainting, IsThreaded/GetResults) stimmt, die genauen Namespaces solltest du am aktuellen Quellcode verifizieren.
Eine belastbare Stunden-/Personenmonat-Schätzung – die hängt völlig davon ab, ob du volle Vehicle-Parität brauchst oder ein schlankeres Plugin reicht.
Was mich natürlich sofort positiv triggert ist die Tatsache, dass es eine native Lib ist und sogar gut performt.
Okay, Vehicles sind nicht mein Ding. Wie gross müsste eine Var-Region sein um beispielsweise den Nürnburgring nachzubauen?
Wir kennen es aus diversen Threads in diesem Forum in denen es um Simulationen von Fahr- und Flugzeugen geht, sei es terrestrisch oder extra-terrestrisch. Dagegen hat OpenSim und auch Second-Life nichts zu bieten und Simulator-Fans sind auch nicht die Zielgruppe von den beiden.
Die anderen Aspekte wie Avatar-Controller, Shapes und Meshes. Terrain und collisions sind schon kritischer.
Ich denke, auf dem Radar behalten.
Referenzen von Games welche diese Engine schon verwenden.
und evtl mal einen Proof of Consept machen.
Liebe Grüsse
Akira
Ich hab mich mal etwas schlau gemacht:
Ein echter Pluspunkt von Bepu hier
Bepu ist reines Managed C#. BulletSim (libBulletSim.so) und ubODE (native ODE) brauchen dagegen pro Plattform eine native Lib – weshalb z.B. auf ARM64 beide eine fatale Exception werfen und man ohne Physik fahren muss. Ein Bepu-Plugin hätte dieses Problem gar nicht. Für Multi-Plattform/ARM ist das ein starkes Argument. Docker Hub
Aufwand – grob nach Bereichen
Ich gebe bewusst keine Stundenzahl, das wäre geraten. Aber die Arbeitspakete lassen sich benennen (nach Aufwand grob absteigend):
Vehicles – das dickste Brett. Das SL/OpenSim-Vehicle-Modell (Linear-/Angular-Motoren, Deflection, Banking, Buoyancy, Hover, Reference Frames) ist in BulletSim/ubODE fertig implementiert. Bepu gibt dir nur Constraints und Kräfte – das komplette Modell müsstest du selbst obendrauf bauen. Das ist der Bereich, wo „fühlt sich nicht an wie SL"-Beschwerden entstehen.
Avatar-Controller – Bepu hat keinen fertigen Character Controller, nur ein Demo-Beispiel. Das musst du adaptieren und tunen (Laufen, Fliegen, Bodenkontakt, Push).
Prim-Shapes / Meshing – Box/Sphere/Cylinder trivial; Sculpts und Mesh-Prims kommen über OpenSims IMesher als Dreiecksnetze/Convex Hulls. Für dynamische, nicht-konvexe Objekte brauchst du Convex-Decomposition (Bepu bringt das nicht mit) und Compound-Shapes.
Terrain – Bullet nutzt ein Heightfield; Bepu hat keine Heightfield-Primitive, du baust aus SetTerrain(float[]) ein Mesh. Machbar, etwas mehr Speicher.
Collision-Events – collision_start/collision/collision_end inkl. Paar-Reporting musst du aus Bepus NarrowPhase-Callbacks selbst aggregieren.
Stepping/Threading – OpenSim ruft Simulate(dt) im Region-Heartbeat; Bepus IThreadDispatcher sauber mit OpenSims Threadpool zu verheiraten braucht Sorgfalt, ist aber Standard.
Kräfte/Params – Buoyancy, llPushObject, Friction/Restitution/Density: über Impulse und Pose-Integrator-Callbacks gut abbildbar.
Ein Prototyp „Avatare + statische/dynamische Prims + Terrain-Kollision" ist relativ schnell machbar; Parität zu BulletSim (insb. Vehicles und volle LSL-Physik-Parameter) ist ein Projekt über viele Monate für eine erfahrene Person. BulletSim ist selbst eine große, gereifte Codebasis – das ist die Messlatte.
Als Referenz/Template: Es gibt eine ausgereifte Bepu-v2-Integration in die Stride-Engine (Nicogo1705/Stride.BepuPhysics), die genau die Bausteine liefert, die dir fehlen – Character-/Car-Controller, Mesh-/ConvexHull-Collider, Trigger, RayCast/SweepCast. Nicht direkt übertragbar, aber sehr nützlich als Vorlage für Character- und Vehicle-Logik. GitHub
Kein absoluter Showstopper, aber Risiken:
Verhaltensparität: Bepus Solver verhält sich anders als Bullet/ODE; für eine Engine getunter Content wird sich anders anfühlen. OpenSim kennt das Problem aber schon zwischen Bullet und ubODE.
Determinismus: Bepu v2 (float) ist nicht garantiert cross-platform-deterministisch. Für server-autoritative Single-Node-Regionen egal – nur relevant, falls du irgendwo auf reproduzierbare Physik über Maschinen hinweg baust.
Maintenance: Bepu ist im Kern ein Ein-Personen-Projekt (Apache-2.0, stabil, aber Bus-Faktor beachten).
Wo ich ehrlich unsicher bin und du prüfen solltest:
Ob schon jemand ein Bepu-Plugin für OpenSim angefangen hat – ich habe in der Suche nichts gefunden, kann es aber nicht ausschließen. Würde ich vor Projektstart gezielt suchen (OpenSim-Foren/Mantis, GitHub).
Die exakten Interface-/Namespace-Namen im .NET-8-Branch – die wurden über die Versionen umbenannt; die Struktur (PhysicsScene/PhysicsActor, AddAvatar, SetTerrain, Tainting, IsThreaded/GetResults) stimmt, die genauen Namespaces solltest du am aktuellen Quellcode verifizieren.
Eine belastbare Stunden-/Personenmonat-Schätzung – die hängt völlig davon ab, ob du volle Vehicle-Parität brauchst oder ein schlankeres Plugin reicht.
Was mich natürlich sofort positiv triggert ist die Tatsache, dass es eine native Lib ist und sogar gut performt.
Okay, Vehicles sind nicht mein Ding. Wie gross müsste eine Var-Region sein um beispielsweise den Nürnburgring nachzubauen?
Wir kennen es aus diversen Threads in diesem Forum in denen es um Simulationen von Fahr- und Flugzeugen geht, sei es terrestrisch oder extra-terrestrisch. Dagegen hat OpenSim und auch Second-Life nichts zu bieten und Simulator-Fans sind auch nicht die Zielgruppe von den beiden.
Die anderen Aspekte wie Avatar-Controller, Shapes und Meshes. Terrain und collisions sind schon kritischer.
Ich denke, auf dem Radar behalten.
Referenzen von Games welche diese Engine schon verwenden.
und evtl mal einen Proof of Consept machen.
Liebe Grüsse
Akira
![[Bild: footert5jul.jpg]](https://i.postimg.cc/mgksQryk/footert5jul.jpg)