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
Page «Previous 1 2 3 4 5 6 7 Last »
#1
10/28/2013 (6:22 am)
I'm sure there is plenty of interest - we spend more time explaining how to find the older SDK than how to use it.
#2
10/30/2013 (5:49 pm)
Well seems to be working just fine. I'll have to rip out some code before releasing as i have added extra's to suit the project i'm working on. I'll keep testing over the weekend and try and release it next week.

PVD Screenshot Here
#3
11/04/2013 (5:29 pm)
Please keep us up to date!
#4
11/10/2013 (8:17 pm)
I'd be interested.Also, any thoughts to adding additional functionality to physicsBody, it seems to be missing applyForce(), and getPointVelocity().I've added them myself but haven't done any pull requests yet.
#5
11/13/2013 (4:25 am)
oops, rant removed :-)

It's almost complete, I'm just having a few troubles getting the timing working 100%, if i send someone the code would they mind testing it?
#6
11/16/2013 (4:10 am)
updated and rant removed ;-). Do i just provide a link to the source code for the plugin here?
#7
11/16/2013 (6:37 am)
Are you keeping your work in a Git repo? If so, you could just submit a pull request. The committee will review it and add it to the development branch, people will use it, bugs will be found and fixed, Nirvana will be achieved.

Github's pull request help page
Lukas' Github pull request tutorial
#8
11/29/2013 (9:18 pm)
Sorry for the lack of updates guys, i have been really busy and totally forgot about this thread.

I don't think the plugin is ready yet for a pull request. I have stripped out all the stuff that is directly related to the project i am working (i'm sure i may have missed something though) on and have just supplied the bare bones plugin. Consider it alpha at the moment as i'm sure there will be a few problems found and it is also lacking some features of the PhysX 2 plugin it would be a closer match to the bullet plugin.

Find the code here www.narivtech.com/downloads/physx3.zip

just extract that zip into Engine/source/T3D/physics. I have not put any license or anything on it, so do as you please with it. If anyone does make any changes if they could post them here that would be appreciated. Hopefully i will get time to finish it off myself before the year ends and if i do, than i'll do a pull request for it.

Testing it seems to work ok using the project manager to create a full template project using torque physics, than just drop the zip file in add the location to your physx 3 sdk.
#9
12/17/2013 (12:15 am)
You have an error in the link location.
#10
12/17/2013 (2:36 pm)
Yeah sorry i have taken it down while i'm modifying it to work with PhysX 3.3. I have fixed a few problems present in the original version posted above & it's working a lot better.

It's going to be a busy few weeks for me (i'm sure for everyone too) so in the new year i will fork the T3D repo and set it up properly and hopefully send a pull request back to GG
#11
01/05/2014 (5:35 pm)
Ok i uploaded the physx 3.3 plugin to my own fork of Torque3D, you can check it here github.com/rextimmy/Torque3D/tree/development. I have made no changes to Torque3D codebase and the plugin is definitely not complete yet but it is in a working state. A binary demo can be found here www.narivtech.com/downloads/physx3-demo.7z

Due to the uncertain future of Torque3D i have copyrighted the code to myself (it's still MIT), i mentioned in the GREED thread i was happy to commit the changes to them once they are up and running and i guess when the plugin is fully complete. To be perfectly honest i don't care about the copyright and will happily change it once it becomes more apparent what is happening with Torque3D and or GREED.

There will no doubt be some bugs etc so just post any findings please.

The easiest way to build physx 3 support in is just to create a project using the torque physics and than just include the physx3 directory (Engine/T3D/physics/physx3) to your project and obviously also point your compiler to where ever you installed the PhysX 3.3 SDK.

One thing i have not tested yet is destructible items.
#12
01/16/2014 (8:27 pm)
Hey Timmy,

I finally got around to trying it out. Seems to be working quite well. I spent the last day remaking cloth as the old one had no chance of working since they changed so much about cloth. I've got the basics working like attachment points and samples. Collision works but I need to test some more before concluding it's alright.

Here's a video of it in action:


One bug I noticed, which I'll have to test against 2.8 to see if it's in both or just 3.3 specific, is when I fire the gun for the first time, the framerate drops and the cube that's floating in the water shoots up in the air. You can see it happen in the video.

Once I sort out the remaining bugs in the cloth and add in the missing features I'll post the code.
#13
01/16/2014 (8:29 pm)
great progress :)
well even seein this bug feels great ;)

thank you for your effort
#14
01/16/2014 (11:02 pm)
Yeah i must admit i have done very little testing with the character controller as i don't use it in my project. The PhysX 2.8 plugin doesn't seem to suffer from that first bullet bug.

Nice work so far on the cloth, it might be worth enabling cuda dispatcher for that. Personally in my own local build of torque i removed the script to set the cpu number and hard coded it to use number of cores-1 (or just 1 if not a dual core). The NVidia guys are right though, physx 3.3 is super fast even without any cuda stuff enabled.

I also forgot originally to mention (this is not really aimed at you andrew as no doubt you noticed it already) but the timing of the plugin is running quite a high resolution that may not be necessary depending on what people are doing, so it's worth playing around with those settings.

I'll take a look myself too over the next few days and see if i can track down that bug but do mention on here if you find it.

#15
01/21/2014 (6:57 pm)
Update time. I added wind to the code, but I needed to find a place to get the force from. In particleEmitter I found a lovely little vector: ParticleEmitter::mWindVelocity which is set by the forest wind emitters. So I took it from there, and now when wind is enabled on a cloth it will blow in response to the forest wind emitters, gusts included. Here's a link to the code in it's current condition:

https://gist.github.com/andr3wmac/8552604

Known problems are:
- Only the 4 corner attachment points work, and if you don't attach any it won't render. Without a fixed point the mesh doesn't show up in the physx debugger, so as far as I can tell it just has to be attached.
- Bounding box isn't really working all that well so sometimes the cloth disappears as you move the camera around because it thinks it's off screen.
- Collision seems to work on the floor, but its hit and miss with objects and the player.

And here's a video of the wind in action:

I'm going to spend the next few days experimenting with a few ideas I have for more advanced cloth stuff (end-goal: I want a characters cape to blow in the wind) Will report back with updates if I accomplish anything cool.
#16
01/21/2014 (7:48 pm)
The PhysX Apex framework looks like it has a lot of good clothing and hair features, is that what you're trying to implement for advanced cloth stuff?
#17
01/21/2014 (8:57 pm)
I'm taking the quickest path to nice looking cloth on characters/objects. I have apex sdk and I've played with the samples and read through them. I worry about how long it would take me to consider it stable enough to use in my game. I don't want to slow down production too long when there might be quicker paths. APEX would be the ultimate solution though.

I'm experimenting with the idea of a UDK style cloth system where you can specify a "cloth bone" if you will, and all the vertices weighted to that bone are used to make up the cloth part of the mesh. This is a really simple system in theory, and I think I could get it done faster than I could APEX.

One way or another, I want dynamic cloth. It's my new obsession since my artist pointed out that UDK can do it really easily. To hell with UDK. I'll make my own cloth physics.. with blackjack.. and hookers.
#18
01/24/2014 (11:52 am)
Update! I managed to create a class I call ClothShape. It's based off SceneObject and takes a ShapeFile. It reads the vertices and triangles and loads them into PhysX, and reads back the alterations and applys them to the shape. It's in very early stages, I just got it working I had to post a video because it's a big step.

First, here's the mesh I made in blender:
i.imgur.com/Ti0RKMj.png
And here's the code from the mission file:
new ClothShape() {
      shapeFile = "art/andrew/cloth_pole.dae";
      position = "1.5511 0 0.167794";
      rotation = "1 0 0 0";
      scale = "1 1 1";
      canSave = "0";
      canSaveDynamicFields = "0";
   };

And here's the result:

Now, you're probably wondering why only the lower half of it is moving. That's because at the moment I don't have any system in place to determine weights on the verts. Instead I just put in a little hack that checks below a certain z value and makes all those verts loose instead of fixed. So that's my next task. I'm going to pursue to bone route and see if I can track down where they store what verts are associated with what nodes. The idea being all verts associated with a "cloth bone" become loose cloth, the rest stay fixed.

Also, does anyone know why the vertex data seems to contain a lot of duplicates? There appears to be a unique set of 3 vertices for every triangle. However, all these triangles are actually sharing verts. In order to load it into PhysX I have to remove all duplicates and replace those numbers in the triangle list. Then when I read the data back out of PhysX I have to translate it back and move all the duplicates as well. It works, and I can certainly optimize it, but I'd like to know why there's so many duplicate verts. When I load an 8 vert cube in, it has 36 verts in the TSMesh.
#19
01/24/2014 (12:08 pm)
This is really nice - good going.
#20
01/24/2014 (2:55 pm)
Hey awesome work so far Andrew!

I gotta say i have never actually gone through the TSMesh class to see how it is storing/loading vertex and index data. I'm guessing there is a fair bit of work going on as the collada mesh is imported and converted to the native dts, I would definitely be starting there to track it down.

Did you ever find anything with that strange first bullet bug? I have had a quick look over it and can't see anything obvious that would be causing it.
Page «Previous 1 2 3 4 5 6 7 Last »