It might be worth noting that making a call from managed to unmanaged code typically has a lot of overhead. I've found that making fewer calls while passing many data in arrays of native types is often a lot faster than making many calls with fewer data. I suspect you've probably experienced similar but I thought I'd mention it on the odd chance you haven't. Here's an interesting article about it: http://www.codeproject.com/Articles/253444/PInvoke-Performance
On Fri, Aug 14, 2015 at 12:26 PM, <[email protected]> wrote: > > Hi! That is very useful information, many thanks! As we go forward, I'd > like to reach out to you more if that would be okay. We are making the > C#/C++ interface be as simple as possible and trying to keep as much native > stuff on the native side as possible. Just a whole lot easier especially > with differences in compiler/linker flags between OpenSim and PhysX (Robert > can go into a ton more on that). > > Glenn > > > > > > On Thu, 13 Aug 2015, Mister Blue wrote: > > Hello Robert and Glenn, >> I'm the main person behind BulletSim and feel free to send me email ( >> [email protected]) if you have any questions about integrating a >> physics engine with OpenSimulator. >> >> Some general ramblings about BulletSim: >> >> The C# part of BulletSim can be in addin-modules -- it doesn't need to be >> 'in core' but needs to be built with >> core so it can be an addin module. Your new physics engine can start out >> as an addin module and, like BulletSim, prove itself before graduating >> into >> core. >> >> There is a separate OpenSimulator source tree... opensim-libs at "git:// >> opensimulator.org/git/opensim-libs" that has a bunch of the non-core >> parts >> of OpenSimulator (http server, old and ancient other tries at he physics >> engine, ...). The C++ portion of BulletSim is in >> 'opensim-libs/trunk/unmanaged/BulletSim' and there are the instructions >> for >> fetching the Bullet sources, patching same, and then building with the >> interface to the C# code). The C++ wrapper mostly deals with passing the >> structures back and forth between the C# and C++ code (pinned memory for >> the position updates and collisions, copying meshes in arrays of floats, >> ...) >> >> The BulletSim design is around making a simulation step be only one >> transition between C# and C++. So, under normal running conditions, there >> is only one transition per simulation step and the data (position updates >> and collisions) are passed in pinned memory so there is no copy. 98% of >> the >> C# code deals with doing and adapting Bullet to what OpenSimulator >> required >> (link sets (ugh!), ...). The C# -> C++ interface for BulletSim is rather >> large... physics engines seem to have lots of calls for all their >> features. >> Bullet, for instance, has what seems like zillions of methods for changing >> constraint parameters. I made those appear in the interface to C#. If I >> had >> it to do over again, I'd probably go more with a functional design where >> there is a "call a named function with parameter blob" design so the >> C#/C++ >> interface was smaller and new function could be added without changing the >> binding of the DLL then use some fancy reflection to build the binding on >> both sides >> >> The .NET C#/C++ binding is pretty good except that int's and boolean's >> change size between 32 and 64bits... if you look at the BulletSim >> interface >> you'll see I use floats and arrays of floats everywhere because they are >> always 32 bit. >> >> I recently played with building "BulletThrift"... a version of BulletSim >> that used Thrift to call a remote process physics engine (experiment in >> distributed physics). It didn't get finished mainly because the existing >> interface to the C++ module is so large. BulletSim actually has a HAL >> layer >> to access the physics engine and there are two physics engines: the C++ >> Bullet and a C# port of Bullet. The latter was last used by Nebadon to run >> OpenSimulator on a Raspberry PI. But this also means it is easy to add a >> link to a remote Bullet. That's where I was going to add BulletThrift that >> would call across the network to a remote Bullet server. My main reason >> for >> doing this was to be able to run Bullet in a pure C++ environment where >> debugging wouldn't be complicated by the managed/unmanaged environment. >> >> If you distributed the physics engine, operationally, I'd expect you'd see >> some of the things that happen when >> running BulletSim on its own thread like jitter caused when there is a >> 'beat' between the physics simulation >> time and the simulator heartbeat. BulletSim running on its own thread >> means that the physics engine is called >> on its own thread and the passing back of collisions and position updates >> happens when the simulator heartbe >> at thread calls into the physics engine. >> >> Anyway, feel free to ask about my learnings. >> >> -- mb >> >> >> >> >> On Tue, Aug 11, 2015 at 8:45 AM, Myron Curtis < >> [email protected] >> >>> wrote: >>> >> >> Thanks, >>> It would add the extra overhead, but it might also enable a central >>> server >>> to manage the physics for several grid instances, and it might be more >>> compatible with web based access to a virtual world if we can ever get >>> that >>> built. >>> Myron >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of Kevin Cozens >>> Sent: Monday, August 10, 2015 7:00 PM >>> To: [email protected] >>> Subject: Re: [Opensim-dev] PhysX Development >>> >>> On 15-08-10 06:39 PM, Myron Curtis wrote: >>> >>>> Could you use PHP as the wrapper? >>>> >>> >>> Interesting idea but I could see it adding (a lot of?) extra overhead >>> compared to coding the wrapper in the same language as Open Simulator or >>> PhysX. >>> >>> -- >>> Cheers! >>> >>> Kevin. >>> >>> http://www.ve3syb.ca/ |"Nerds make the shiny things that >>> distract >>> Owner of Elecraft K2 #2172 | the mouth-breathers, and that's why >>> we're >>> | powerful!" >>> #include <disclaimer/favourite> | --Chris Hardwick >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >>> >> _______________________________________________ > Opensim-dev mailing list > [email protected] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >
_______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
