PhysX Development

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

PhysX Development

Glenn Martin
Hi!  I work at the University of Central Florida's Institute for Simulation & Training and lead the development team working on the PhysX implementation into OpenSim for Doug Maxwell (of ARL-STTC).  My Ph.D. is in Modeling and Simulation (with undergrad/master's work in CS) and lead a team of 2-full timers, 1 associate and 2 student assistants (all with CS background).  While I'm relatively new to OpenSim, I've been doing virtual environments work for about 25 years (a lot of traditional virtual reality work as well as game-based training using the Source engine as well as Open Scene Graph).

We are working on two PhysX implementations....one integrated into OpenSim (much like Bullet) and one that sends data to a remote physics server for processing.  In order to better engage the OpenSim community (particularly with regards to implementation specifics so that we make sure we address things in appropriate ways), my team will be posting our current design/implementation plans for early (and frequent) feedback.  We'd love to hear comments from you as we go along!

Looking forward to the interaction!

Glenn Martin


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

PhysX Development

Louden, Robert

Hello! I am part of the team working on the PhysX implementation at the University of Central Florida's Institute for Simulation & Training, along side with the MOSES team. Specifically, I am currently part of the PhysX plugin development for OpenSim.


Originally, we attempted to use PhysX.Net, a C# wrapper for the PhysX library, in order to integrate PhysX into OpenSim. However, PhysX.Net uses C++/CLI and, by default, will compile into a mixed-assembly of managed and native code, which is not supported by Mono. Our goal is to allow for portability on all systems so we worked on updating PhysX.Net to compile entirely in managed code. Unfortunately, we could not link the new, purely managed, PhysX.Net project with the native libraries of PhysX.


We have since started development on our own wrapper. It is being built in C++ and will expose key methods that the PhysX plugin will import for use, similar to BulletSim's implementation.



Robert Louden


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PhysX Development

Myron Curtis

Could you use PHP as the wrapper?

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Louden, Robert
Sent: Monday, August 10, 2015 2:46 PM
To: [hidden email]
Subject: [Opensim-dev] PhysX Development

 

Hello! I am part of the team working on the PhysX implementation at the University of Central Florida's Institute for Simulation & Training, along side with the MOSES team. Specifically, I am currently part of the PhysX plugin development for OpenSim.

 

Originally, we attempted to use PhysX.Net, a C# wrapper for the PhysX library, in order to integrate PhysX into OpenSim. However, PhysX.Net uses C++/CLI and, by default, will compile into a mixed-assembly of managed and native code, which is not supported by Mono. Our goal is to allow for portability on all systems so we worked on updating PhysX.Net to compile entirely in managed code. Unfortunately, we could not link the new, purely managed, PhysX.Net project with the native libraries of PhysX.

 

We have since started development on our own wrapper. It is being built in C++ and will expose key methods that the PhysX plugin will import for use, similar to BulletSim's implementation.

 

 

Robert Louden


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PhysX Development

Glenn Martin
That's an interesting idea.  We are trying to maximize performance, so we have been writing a simple C#/C++ wrapper that will leave the native stuff on the C++ side and keep the calls from OpenSim pretty straight-forward.  I'm going to look at the php idea for later uses, though!

Glenn




On Mon, Aug 10, 2015 at 6:39 PM, Myron Curtis <[hidden email]> wrote:

Could you use PHP as the wrapper?

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Louden, Robert
Sent: Monday, August 10, 2015 2:46 PM
To: [hidden email]
Subject: [Opensim-dev] PhysX Development

 

Hello! I am part of the team working on the PhysX implementation at the University of Central Florida's Institute for Simulation & Training, along side with the MOSES team. Specifically, I am currently part of the PhysX plugin development for OpenSim.

 

Originally, we attempted to use PhysX.Net, a C# wrapper for the PhysX library, in order to integrate PhysX into OpenSim. However, PhysX.Net uses C++/CLI and, by default, will compile into a mixed-assembly of managed and native code, which is not supported by Mono. Our goal is to allow for portability on all systems so we worked on updating PhysX.Net to compile entirely in managed code. Unfortunately, we could not link the new, purely managed, PhysX.Net project with the native libraries of PhysX.

 

We have since started development on our own wrapper. It is being built in C++ and will expose key methods that the PhysX plugin will import for use, similar to BulletSim's implementation.

 

 

Robert Louden


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev



_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PhysX Development

Melanie-2
I believe I'm confident in saying that there would be significant
resistance to adding yet another language/environment dependency to
OpenSim.

- Melanie

On 11/08/2015 03:35, Glenn Martin wrote:

> That's an interesting idea.  We are trying to maximize performance, so we
> have been writing a simple C#/C++ wrapper that will leave the native stuff
> on the C++ side and keep the calls from OpenSim pretty straight-forward.
> I'm going to look at the php idea for later uses, though!
>
> Glenn
>
>
>
>
> On Mon, Aug 10, 2015 at 6:39 PM, Myron Curtis <[hidden email]
>> wrote:
>
>> Could you use PHP as the wrapper?
>>
>>
>>
>> *From:* [hidden email] [mailto:
>> [hidden email]] *On Behalf Of *Louden, Robert
>> *Sent:* Monday, August 10, 2015 2:46 PM
>> *To:* [hidden email]
>> *Subject:* [Opensim-dev] PhysX Development
>>
>>
>>
>> Hello! I am part of the team working on the PhysX implementation at the
>> University of Central Florida's Institute for Simulation & Training, along
>> side with the MOSES team. Specifically, I am currently part of the PhysX
>> plugin development for OpenSim.
>>
>>
>>
>> Originally, we attempted to use PhysX.Net, a C# wrapper for the PhysX
>> library, in order to integrate PhysX into OpenSim. However, PhysX.Net uses
>> C++/CLI and, by default, will compile into a mixed-assembly of managed and
>> native code, which is not supported by Mono. Our goal is to allow for
>> portability on all systems so we worked on updating PhysX.Net to compile
>> entirely in managed code. Unfortunately, we could not link the new, purely
>> managed, PhysX.Net project with the native libraries of PhysX.
>>
>>
>>
>> We have since started development on our own wrapper. It is being built in
>> C++ and will expose key methods that the PhysX plugin will import for use,
>> similar to BulletSim's implementation.
>>
>>
>>
>>
>>
>> Robert Louden
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PhysX Development

Glenn Martin
Well, PhysX from NVIDIA is written in C++ so I'm not sure it can be avoided.  Am I missing something?

Glenn



On Mon, Aug 10, 2015 at 9:46 PM, Melanie <[hidden email]> wrote:
I believe I'm confident in saying that there would be significant
resistance to adding yet another language/environment dependency to
OpenSim.

- Melanie

On 11/08/2015 03:35, Glenn Martin wrote:
> That's an interesting idea.  We are trying to maximize performance, so we
> have been writing a simple C#/C++ wrapper that will leave the native stuff
> on the C++ side and keep the calls from OpenSim pretty straight-forward.
> I'm going to look at the php idea for later uses, though!
>
> Glenn
>
>
>
>
> On Mon, Aug 10, 2015 at 6:39 PM, Myron Curtis <[hidden email]
>> wrote:
>
>> Could you use PHP as the wrapper?
>>
>>
>>
>> *From:* [hidden email] [mailto:
>> [hidden email]] *On Behalf Of *Louden, Robert
>> *Sent:* Monday, August 10, 2015 2:46 PM
>> *To:* [hidden email]
>> *Subject:* [Opensim-dev] PhysX Development
>>
>>
>>
>> Hello! I am part of the team working on the PhysX implementation at the
>> University of Central Florida's Institute for Simulation & Training, along
>> side with the MOSES team. Specifically, I am currently part of the PhysX
>> plugin development for OpenSim.
>>
>>
>>
>> Originally, we attempted to use PhysX.Net, a C# wrapper for the PhysX
>> library, in order to integrate PhysX into OpenSim. However, PhysX.Net uses
>> C++/CLI and, by default, will compile into a mixed-assembly of managed and
>> native code, which is not supported by Mono. Our goal is to allow for
>> portability on all systems so we worked on updating PhysX.Net to compile
>> entirely in managed code. Unfortunately, we could not link the new, purely
>> managed, PhysX.Net project with the native libraries of PhysX.
>>
>>
>>
>> We have since started development on our own wrapper. It is being built in
>> C++ and will expose key methods that the PhysX plugin will import for use,
>> similar to BulletSim's implementation.
>>
>>
>>
>>
>>
>> Robert Louden
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PhysX Development

Melanie-2
That was regarding PHP. We already have C++/native dependencies so
that is fine.

- Melanie

On 11/08/2015 03:50, Glenn Martin wrote:

> Well, PhysX from NVIDIA is written in C++ so I'm not sure it can be
> avoided.  Am I missing something?
>
> Glenn
>
>
>
> On Mon, Aug 10, 2015 at 9:46 PM, Melanie <[hidden email]> wrote:
>
>> I believe I'm confident in saying that there would be significant
>> resistance to adding yet another language/environment dependency to
>> OpenSim.
>>
>> - Melanie
>>
>> On 11/08/2015 03:35, Glenn Martin wrote:
>> > That's an interesting idea.  We are trying to maximize performance, so we
>> > have been writing a simple C#/C++ wrapper that will leave the native
>> stuff
>> > on the C++ side and keep the calls from OpenSim pretty straight-forward.
>> > I'm going to look at the php idea for later uses, though!
>> >
>> > Glenn
>> >
>> >
>> >
>> >
>> > On Mon, Aug 10, 2015 at 6:39 PM, Myron Curtis <
>> [hidden email]
>> >> wrote:
>> >
>> >> Could you use PHP as the wrapper?
>> >>
>> >>
>> >>
>> >> *From:* [hidden email] [mailto:
>> >> [hidden email]] *On Behalf Of *Louden, Robert
>> >> *Sent:* Monday, August 10, 2015 2:46 PM
>> >> *To:* [hidden email]
>> >> *Subject:* [Opensim-dev] PhysX Development
>> >>
>> >>
>> >>
>> >> Hello! I am part of the team working on the PhysX implementation at the
>> >> University of Central Florida's Institute for Simulation & Training,
>> along
>> >> side with the MOSES team. Specifically, I am currently part of the PhysX
>> >> plugin development for OpenSim.
>> >>
>> >>
>> >>
>> >> Originally, we attempted to use PhysX.Net, a C# wrapper for the PhysX
>> >> library, in order to integrate PhysX into OpenSim. However, PhysX.Net
>> uses
>> >> C++/CLI and, by default, will compile into a mixed-assembly of managed
>> and
>> >> native code, which is not supported by Mono. Our goal is to allow for
>> >> portability on all systems so we worked on updating PhysX.Net to compile
>> >> entirely in managed code. Unfortunately, we could not link the new,
>> purely
>> >> managed, PhysX.Net project with the native libraries of PhysX.
>> >>
>> >>
>> >>
>> >> We have since started development on our own wrapper. It is being built
>> in
>> >> C++ and will expose key methods that the PhysX plugin will import for
>> use,
>> >> similar to BulletSim's implementation.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Robert Louden
>> >>
>> >> _______________________________________________
>> >> Opensim-dev mailing list
>> >> [hidden email]
>> >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>> >>
>> >>
>> >
>> >
>> >
>> > _______________________________________________
>> > Opensim-dev mailing list
>> > [hidden email]
>> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PhysX Development

Kevin Cozens
In reply to this post by Myron Curtis
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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PhysX Development

Myron Curtis
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Kevin Cozens
Sent: Monday, August 10, 2015 7:00 PM
To: [hidden email]
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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PhysX Development

Mister Blue
Hello Robert and Glenn,
I'm the main person behind BulletSim and feel free to send me email ([hidden email]) 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 <[hidden email]> 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Kevin Cozens
Sent: Monday, August 10, 2015 7:00 PM
To: [hidden email]
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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PhysX Development

Glenn Martin

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 (
> [hidden email]) 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 <[hidden email]
>> 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: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Kevin Cozens
>> Sent: Monday, August 10, 2015 7:00 PM
>> To: [hidden email]
>> 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
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PhysX Development

Dahlia Trimble
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, <[hidden email]> 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 (
[hidden email]) 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 <[hidden email]
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Kevin Cozens
Sent: Monday, August 10, 2015 7:00 PM
To: [hidden email]
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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PhysX Development

Glenn Martin
That's a very good point and the model we are using. We originally were looking at PhysX.Net but it is difficult to make it work with OpenSim and mono (at least without some OpenSim compilation changes and we didn't feel that would be accepted), and it likely would have a lot more overhead. 

Glenn

Note: Sent from my cell phone. The opinions and thoughts in this email are my own and do not reflect those of any other person or organization. 

On Aug 14, 2015, at 4:18 PM, Dahlia Trimble <[hidden email]> wrote:

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, <[hidden email]> 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 (
[hidden email]) 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 <[hidden email]
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Kevin Cozens
Sent: Monday, August 10, 2015 7:00 PM
To: [hidden email]
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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Loading...