[Opensim-dev] PhysX Development

Fri Aug 14 20:18:11 UTC 2015

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, <gamucf at gmail.com> 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 (
>> misterblue at misterblue.com) 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 <
>> myronjc at virtualworldsgrid.com
>>
>>> 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: opensim-dev-bounces at opensimulator.org
>>> [mailto:opensim-dev-bounces at opensimulator.org] On Behalf Of Kevin Cozens
>>> Sent: Monday, August 10, 2015 7:00 PM
>>> To: opensim-dev at opensimulator.org
>>> 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
>>> Opensim-dev at opensimulator.org
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at opensimulator.org
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>
>>>
>> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20150814/f4221de1/attachment-0001.html>