Page 1 of 2

how could i know if it run correctly with linux server no graphic

Posted: Fri May 31, 2019 6:37 am
by parapoohda
I want to use bepuphysic for my game server which i couldn't view screen for now. I want to test it before use it. I want to asked where to console log when collision. Or there are other way to know it work correctly on dotnet core sdk in my server.
Thank you for answer.
And sorry fo my bad English. It is not my mother tongue

Re: how could i know if it run correctly with linux server no graphic

Posted: Fri May 31, 2019 11:49 pm
by Norbo
One option would be to just pipe the pose of all bodies over to a remote visualization process. For the sake of testing, efficiency wouldn't matter, and you could get a very accurate idea of what's going on.

You could also just monitor the pose of a few objects in a simulation with Console.WriteLines to see if they're reasonable. There are contact callbacks (see DemoNarrowPhaseCallbacks for a simple example implementation used in the demos) that you could write from too. Doing so in production would be a really bad idea due to the performance sensitivity of those callbacks, of course, but for simple testing it would be fine.

For what it's worth, my test runs on linux have gone fine. It passed the FountainStressTestDemo determinism test which covers a great deal of functionality.

Re: how could i know if it run correctly with linux server no graphic

Posted: Sat Jun 01, 2019 3:30 am
by parapoohda
thank you for the answer i will try writeline out.

Re: how could i know if it run correctly with linux server no graphic

Posted: Tue Jun 04, 2019 4:40 am
by parapoohda
i want to know if i writeline in function allow contact generation with parameter CollidableReference a and b with demo planet. Would it writeline when collision. Thank you.

Re: how could i know if it run correctly with linux server no graphic

Posted: Tue Jun 04, 2019 10:22 pm
by Norbo
AllowContactGeneration(CollidableReference a, CollidableReference b) runs for every overlapping AABB pair found by the broad phase. It tells the narrow phase which pairs to actually work on. If you want information about actual collisions (and their associated contacts), you would need to use the ConfigureContactManifold functions. There's one for convex collisions, nonconvex collisions, and convex subpairs associated with nonconvex collisions.

Re: how could i know if it run correctly with linux server no graphic

Posted: Wed Jun 05, 2019 4:10 am
by parapoohda
thank you very much

Re: how could i know if it run correctly with linux server no graphic

Posted: Wed Jun 05, 2019 6:53 am
by parapoohda
If I want to test run on docker do I have to remove graphic. Do I have to do the same with linux server.Thank you. I'm very appreciate your help.

Re: how could i know if it run correctly with linux server no graphic

Posted: Wed Jun 05, 2019 9:25 pm
by Norbo
I'm not sure I understand the question. Physics and graphics are completely independent; the physics do not depend on any graphical libraries or concepts. If you want to use the physics in a serverlike use case, then you probably would not include any graphics.

If you're asking specifically about the demos application, the renderer requires DX11 support so it would not run on linux. I'm not familiar enough with the subtleties of docker and GPU-using applications to say whether the demos on Windows in a docker container would work well.

Re: how could i know if it run correctly with linux server no graphic

Posted: Wed Jun 05, 2019 11:53 pm
by parapoohda
Thank you. I want to test demo in docker but i fail to do so. I try to remove graphic from demo because I think problem is it can't render graphic in docker.

Re: how could i know if it run correctly with linux server no graphic

Posted: Thu Jun 06, 2019 10:43 pm
by Norbo
The SimpleSelfContainedDemo might be helpful for that purpose- it strips away all demos infrastructure, leaving a single file that can run a simulation. You could take that and place it into a console application (plus the library dependencies, of course) and it would work without any graphical dependencies.

Re: how could i know if it run correctly with linux server no graphic

Posted: Wed Jun 26, 2019 4:38 am
by parapoohda
Thank you. I do other thing recently so I didn't look into this project since last reply. Now I try to do it again.

Re: how could i know if it run correctly with linux server no graphic

Posted: Wed Jun 26, 2019 9:20 am
by parapoohda
Eventually i run it in docker success. Thank you.
I made new dotnet project. Add bepu as library. Copy SimpleThreadDispatcher.cs to project.
It is collide as in my pc :D :D

Re: how could i know if it run correctly with linux server no graphic

Posted: Wed Jun 26, 2019 10:02 pm
by Norbo
👍

Re: how could i know if it run correctly with linux server no graphic

Posted: Fri Aug 02, 2019 3:24 pm
by parapoohda
I want to sync physic client and server.
I use unity for client.
I try to also use bepu in unity but I can't use vector<float>
Can I use bepuphysic2 in unity? If not how can I tell unity when it is slide of other object.
Thank you.

Re: how could i know if it run correctly with linux server no graphic

Posted: Fri Aug 02, 2019 9:14 pm
by Norbo
I'd recommend this thread for information about Unity and bepuphysics v2:
viewtopic.php?f=9&t=2528

The short version is that there are some unity runtime bugs that get in the way for most simulations, and beyond that, the current runtime does not accelerate the System.Numerics SIMD intrinsics and so is extremely slow compared to running on CoreCLR.

This limits your options a bit on the unity clientside. Some options:
1) Use a networking model where the client does not need to be aware of physics at all; make it a dumb terminal. There are various ways to do this, but most come down to sending simulation snapshots that the client can interpolate between. I'd recommend gaffer on games for a deeper dive on this topic- the website appears to be down right now, but you can still get the post content off of his github: https://github.com/gafferongames/gaffer ... ntent/post. In particular, https://github.com/gafferongames/gaffer ... olation.md.
2) Use some other physics engine on the client to fill in the gaps between network updates and use a prioritized update scheme or something similar. There will be differences in behavior, but the hope would be that the short time between updates wouldn't allow too much divergence to sneak in. Some related info: https://github.com/gafferongames/gaffer ... ization.md
3) Run the bepuphysics v2 on the client's machine with a prioritized update scheme, but under CoreCLR in a separate process. Send updates between processes to update the unity representation. Complicated, annoying, and carries overhead, but it could technically work.
4) Get unity to fix the runtime issues :P