Game Development Community

PhysX 3.x Plugin

by Timmy01 · in Torque 3D Professional · 10/28/2013 (5:11 am) · 500 replies

Update:
If you wish to follow this than please check here github.com/ChrisCalef/Torque3D/tree/physx3_advanced_WIP
#81
02/17/2014 (2:52 am)
Looks like Andrew got it in this commit
#82
02/17/2014 (2:53 am)
Ok sweet ;-)
#83
02/17/2014 (11:43 am)
I hate to format my hard drive a week or two ago so I'm just reinstalling everything now to start working on physx again.

Whenever I run the samples, or even a regular project generated with Project Manager and PhysX 3.3 enabled, the application freezes after a few seconds. No errors in the console, no error in visual studio. It just gets completely stuck and stops responding.

The simulations do actually work for the first 4-5 seconds and then it freezes. Cloth works, cubes work. I can shoot the cubes a few times then I go to move and it freezes. In the terrain sample with no physics objects, it freezes just from looking around. The simulation freezes in the visual debugger as well ( I tried running it without the debugger - no difference )

Any ideas?
#84
02/17/2014 (2:03 pm)
@Andrew that sounds weird. All I can say is that the simulation pauses for example when you open the editor. (Thats for particles anw)
Perhaps it's pausing because of something and then forgets to unpause?
#85
02/17/2014 (2:26 pm)
@Andrew:

I'm getting the exact same problem too, I tried a git reset to before the last commit and problem remains. I'll look into it.
#86
02/17/2014 (2:32 pm)
I haven't seen the issue at all, I'll try and let it run for a while and see what happens just to make sure.
#87
02/17/2014 (2:41 pm)
I've had it running for some minutes now and my copy doesn't freeze at all.
#88
02/17/2014 (3:14 pm)
For me running the simulation at 1.0f/30.0f causes a freeze every single time, running the sim at 1.0f/32.0f (or higher) fixes the problem for me. Go back to 1.0f/30.0f and it freezes without fail every time.
#89
02/17/2014 (3:32 pm)
Could it have something to do with processTick? The number 1/32 is screaming tick interval related issue to me.
#90
02/17/2014 (3:36 pm)
Yeah it's gotta be related for sure, the processTick tick interval is 1/32. I'll have a play around today with it. Did changing the timing fix it for you too?
#91
02/17/2014 (3:45 pm)
Yep! Works perfect with the step time changed to 1/32. Now I can check out physx particles!
#92
02/17/2014 (3:47 pm)
I don't even know why I set it to 1/30 originally, it should by default use what the physx2 plugin uses which is TickMs (32) or what bullet uses (1/60) and if people require more accuracy they can change it via the console or hard code it.
#93
02/17/2014 (3:51 pm)
I'll update the repo and set it at 1/TickMs with 4 max steps and than users can adjust it from there to suit their own projects needs.
#94
02/17/2014 (10:28 pm)
Im going to get busy finalizing the physx 3 based vehicles.

Something worth discussing in the future is a more advanced grouping system so it would make it far easier for filtering e.g disable collisions between user defined groups.
#95
02/19/2014 (4:15 pm)
Lukas and I worked together to get the PhysX particles working. It's still in it's infancy but it seems to be working quite well. The biggest issue at the moment is the particles flickering when you get too close to them. Also there's a lack of options for configuring their behavior but it is running on the same emitters/particles as torque usually uses so a lot of visual features are still in tact.


I honestly didn't expect it to work when I put that shape in there, but sure enough it flowed down hill as expected. I'm going to push the changes later tonight and update the samples.
#96
02/19/2014 (4:59 pm)
Nice work guys :-)
#97
02/19/2014 (7:45 pm)
Working on triangle mesh based materials again, may have figured out the issue, I'll keep ya up to date. If i don't get it this time, might post the code here to help debug.
#98
02/19/2014 (11:36 pm)
Hmm I wonder where the flickering comes from, I thought it was a position issue and it would be resolved when the index thing was solved, but it might be a rendering issue..
#99
02/20/2014 (5:23 am)
@Andrew 9s into this video it looks like the size of the particles is based on the angle at which you look at them, is that so?
#100
02/20/2014 (8:43 am)
Actually, at that point in the video the max particles are reached in the system and there's a slight delay before enough of them expire to cause another out pour of new particles. Max particles seems to working fine as well, changing it from 100 to 250 lets the streams run longer. Need to find a balance between max particles and expiry time to reduce them bunching together at the bottom.

PhysX came up with this idea called a sink. The idea is its a plane that immediately expires particles when they impact it. You can put this at the bottom of streams to prevent piles of particles building up. Perhaps at some point we can add support for those.

The code has been pushed to the physx3 repo, but I still haven't pushed the samples. I should have them up soon. I really didn't change much except I duplicated defaultParticle datablock and extended the lifetime to keep the particles alive.