• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

PhysX Rocket

unless you have a grayhound proc with two X2700s in Crossfire, your fine toi post fps of the released ppu online.
 
Ok, with PhysxRocket which uses the 2.4.4 sdk
Running the script luminaryjanitor posted.

Software mode stays mostly 45-60 fps Cpu usage 60-65%

Hardware Mode never drops below 60fps Cpu usage Spikes
at the very start at about 25-28% then drops to 5-8% then climbs
back up at the very end, but I think it's climbing because the
script may be done, and the HW only works when script is active?

with 2.5.5 and novodex rocket in software i got something like in the
mid 80's but high 50-60% cpu usage..
 
emmett said:
Ok, with PhysxRocket which uses the 2.4.4 sdk
Running the script luminaryjanitor posted.

Software mode stays mostly 45-60 fps Cpu usage 60-65%

Hardware Mode never drops below 60fps Cpu usage Spikes
at the very start at about 25-28% then drops to 5-8% then climbs
back up at the very end, but I think it's climbing because the
script may be done, and the HW only works when script is active?

with 2.5.5 and novodex rocket in software i got something like in the
mid 80's but high 50-60% cpu usage..

Can you try doing something with, say, 30,000 bricks? That's what AGEIA claims it can do. Let's see if they're right.

BTW, to increase the number of bricks, just use the script that LuminaryJanitor posted, but increase the "height = ", "depth = ", or "width = " numbers.
 
emmett said:
Ok, with PhysxRocket which uses the 2.4.4 sdk
Running the script luminaryjanitor posted.

Software mode stays mostly 45-60 fps Cpu usage 60-65%

Hardware Mode never drops below 60fps Cpu usage Spikes
at the very start at about 25-28% then drops to 5-8% then climbs
back up at the very end, but I think it's climbing because the
script may be done, and the HW only works when script is active?

with 2.5.5 and novodex rocket in software i got something like in the
mid 80's but high 50-60% cpu usage..

For everyone reading this, keep in mind that he is testing on a dual core processor, so 50% is equivalent to 100% of a single cpu, unless the program takes advantage of SMP.
 
There are two sets of values, one for the wall and one for the tower i think.
Tell me what numbers to plug in please.
I tried playing with it, and got all kinds of strange results, like super short tower,
and one time the wall was gone. (maybe FAR out of viewable scope?)
 
Use the script I posted here - it gives you a brick count.

The line "numTotalBricks = CreateBuilding(0, 0, 0, 5, 5, 50)", right near the bottom, is the one you want to change. To put more bricks in the existing building, change the last three numbers (length, width, height). To add another building, add another CreateBuilding call:

numTotalBricks = CreateBuilding(0, 0, 0, 5, 5, 50) + CreateBuilding(pos_x, pos_y, pos_z, length, width, height)

You need to add them together for the brick count to work.

BTW, the shadows will probably have some impact on performance with 20,000 bricks flying around... might give a better benchmark if you set the render mode to "flat".
 
Ok, i tried THAT script, and tried changing those values, but not good results,
the tower will only go so high, like it's maxing out, and it's hollow, not gonna
get 30k bricks that way, how can i make it do a solid tower of bricks?

With that script it seemed like i got the same fps with software and hardware.
also was doing flat render like you said.

What am i doing wrong?

Edit:Oh i see, missed the add another building part, ok.

Edit:I created two extra towers, in software mode all 3 towers are seen, in hardware mode, only 2?? why is this?
 
Just do one building with "30, 30, 30" as the last three numbers. That should get you 27,000 bricks.

The rocks might not hit the building. If they don't, just throw your own rocks by getting close to the building and hitting the spacebar.
 
If it was solid, and the bricks were one unit cubed, then 30x30x30 would give you 30,000 bricks. But because it's hollow, you get around 30x30x4 = 3600 (3720, in fact). You want about 85x85x85 to give you 30,000 bricks in a single tower.

I don't know why the counter isn't working in this version of Rocket, but I'll look into it when I've got time.
 
luminary, I ran 30,30,30 and in software mode the tower is twice as high as hardware mode. why is this? in software i ran 15fps. In hardware 40fps but the wall is half the height, and about 4-7% cpu usage. this is with a conroe E6600 currently at 3.4 gig
In software mode the wall looks easily 30k or so bricks. 55-60% cpu usage.


I tried 85,85,85 and the wall is very short, 10 bricks high maybe, but huge. and all hollow in the middle it's not a solid tower for sure.. can you make a script with a solid tower and post it? so i can copy and paste? also was doing flat rendering, is there something i am missing?

Also in software mode i can throw balls at the wall, but in hardware mode I can not.

the balls in the script with the wall that big, the balls in the script do nearly nothing, and two of the walls are untouched, bricks do not move, and in hardware mode i can not toss balls at them...
 
emmett said:
In software mode the wall looks easily 30k or so bricks.
I know it looks like a hell of a lot of bricks, but I guarantee you there are only 3720 bricks in there.

Sounds to me like there are limits imposed on the number of objects you can place (at least in hardware mode), but give this a try anyway. It's a solid stack of cubes, with a ball hurtling straight down on top of it. Change the numbers in wid(), hit() and depth() to change the size. In this case, width*depth*height will give you the number of bricks.

EDIT: BTW, this goes in a .psc file in the pscl folder (not a .lua file like the others)
Code:
PsReset
PsZup false
PsPlaneEmpty

OdfShadows false

OdfLook 67.2997 53.5574 65.2882 66.6635 53.1481 64.6342

PsMatBegin Mat1
PsMatDynamicFriction 0.5
PsMatStaticFriction 0.5
PsMatSpinFriction 0
PsMatRollFriction 0
PsMatRestitution 0
PsMatDynamicFrictionV 0
PsMatStaticFrictionV 0
PsMatDirOfAnisotropy 1 0 0
PsMatDirOfMotion 1 0 0
PsMatSpeedOfMotion 0
PsMatAnisotropic false
PsMatMovingSurface false
PsMatEnd

PsSphere radius(4) position(0,100,0) mass(300) velocity(0,-300,0) material(Mat1)
PsWall sides(1,1,1) wid(15) hit(15) depth(15) position(0,0,0) material(Mat1)

the balls in the script with the wall that big, the balls in the script do nearly nothing
Quick fix is just change the radius in the lines
OdfScript("PsSphere radius(1) ...
to something bigger.

If you want a short explaination of setting up your own positions, speeds and directions, let me know.
 
There seems to be some sort of limit as you said for hardware mode.
I changed the script you just did to height of 60, and it works in software mode.
but even with the original height of 15 in hardware mode, it seems like the top
one and a half layers are missing..

Why would they impose a limit in hardware?
 
There's a limit on the number of actors in a hardware scene because of driver overheads when types of actions are combined (RBC's, joints/fluids etc.). From what I can tell it was done more as a "failsafe" to make sure devs didn't over-egg the cake so to speak - as most games developed during this time were meant to be HW/SW compatible.

There's a workaround which I haven't looked up and the overhead isn't an issue if you're doing one type of action - as in this case - or if you have a lower iteration rate (less accurate).

AFAIK this has been removed in 2.5, put it down to early revision syndrome?
 
Update: I just downloaded and installed PhysX_2.7.2_Tools.exe
http://developer.nvidia.com/object/physx_downloads.html

"Contains Rocket, Rocket data files, and web installer for the required version of DirectX. PhysX plugins will be available from http://SourceForge.net"

It runs fine under Vista!!


The Rocket application is located in:
c:\program files\Ageia Technologies\AGEIA PhysX SDK\v2.7.3\bin\win32\Rocket

Does the fact that this program runs, verify that ageia PhysX must be installed, or would it run on just my CPU with or withought ageia?

I am trying to verify that my 280 now is running ageia Physx.
 
Back
Top