PHYSX NEWS PHYSX SDK
PROJECTS TABLE
GPU PHYSX
GAMES INFO
PHYSX
ARTICLES
PHYSX WIKI FORUM
РУССКИЙ ENGLISH


:: Back to news index ::

PhysX SDK 2.8.4: say goodbye to System Software

with 39 comments

nvidia-physx

Newest PhysX SDK 2.8.4.2 is ready for public beta testing – this is last and most stable current generation SDK, next one is going to be 3.0.

In addition, SDK 2.8.4. will be used as basis for upcoming APEX 1.0 toolset.

[18.08.10] Update: Release notes were supplemented with “driverless” mode description.

[19.08.10] Update #2: bug in the PhysXLoader code, that was preventing it from loading the local DLLs in 2.8.4, is now fixed. Replace the PhysXLoader.dll and PhysXLoader64.dll in your SDK installation with the new files from the archive “2.8.4_Loader_patch.rar“, found in the 2.8.4 folder on the developer download site.

[20.08.10] Update #3: PhysX SDK 2.8.4.3 with fixed PhysXLoader .dlls and included (previously missing) PhysXDevice.dll – is ready.

Currently, binary builds are available for 32- and 64-bit PC Windows, and Xbox 360

RELEASE NOTES:

General

  • Removed PhysX Loader source code from source distribution. THIS WILL BE REVERTED FOR RELEASE. PhysXLoader code will be supplied to source licensees.
  • Discontinued the Training Programs.
  • Added source code of NxTetra (tet-maker) utility to source distribution.
  • Removed spin waits from sample code.
  • Added API to permit the user to specify the order in which compartments are simulated.
  • Added compression limits to cloth.
  • Cloth simulation no longer performs prediction for kinematic rigid bodies for improved interaction behavior.
  • New driverless loader option for PC CPU distribution. In 2.8.4, application developers must ship PhysXCore.dll, PhysXCooking.dll, the cudarXX_XX_X.dll and physxdevice.dll with the application ‘locally’, in the directory where the .exe is located:

1. The application requests PhysXCore or PhysXCooking (v 2.8.4) from the PhysXLoader.

2. PhysXLoader searches for another DLL called ‘PhysXUpdateLoader’.

3. If PhysXUpdateLoader is not found, PhysXLoader will load the local PhysXCore or PhysXCooking.

4. If PhysXUpdateLoader is found, it looks for an updated replacement for the PhysXCore or PhysXCooking dlls.

5. If PhysXUpdateLoader cannot find the specified replacement DLL, PhysXLoader will load the local PhysXCore or PhysXCooking dlls.

6. If PhysXUpdateLoader can find the replacement DLLs, these will be loaded in place of the local PhysCore or PhysXCooking dlls.

7. The net result is that the developer has more control over the game installation process, doesn't have to worry about shipping a large System Software with the game, doesn't have to worry that the player will break his System Software somehow, etc.

  • Better rotation matrix input validity checking.
  • Made Desc::isValid() more verbose.
  • CUDA errors are now reported to the debug stream.
  • Added extended scene statistics for GPU memory usage.
  • Lowered the default GPU memory heap size to 32 MB from 128 MB. You may use NxPhysicsSDKDesc::gpuHeapSize to change how much GPU memory is allocated for physics.
  • Disabled GPU acceleration by default. Clear NX_SDF_NO_HARDWARE to enable it.
  • Corrected inertia and volume computation for capsule. For the same capsule dimension and density, the mass and inertia is slightly different compared to the previous release.

Performance

  • Enabled /arch:SSE2 compiler switch for all optimized PC builds.
  • Optimized PS3 SPU Memory Manager
  • Optimized AgPerfmon AgPerfUtils wrapper
  • Optimized cloth simulation on PS3, XBOX 360, PC CPU

Fixed Bugs

  • Debugged PS3 SPU Memory Manager
  • Fluids now collide properly when static shapes are removed or added.
  • Fixed crash bug in character controller sample.
  • Fixed a number of bugs in the HSM.

API changes

  • Cloth
    • NxCloth::getShapePointers() no longer returns shape flags.
    • Added methods to NxCloth and members to NxClothDesc to set compression parameters.
    • NxCloth::setFlag() can no longer be used to change NX_CLF_BENDING_ORTHO, use flag in NxClothDesc instead.
  • Fluids
    • Removed NxFluidFlag::NX_FF_ENABLE_STATIC_FRICTION. Static friction is enabled by default now.
  • Removed NX_SDKF_EXTENDED_DESCRIPTOR.
  • Added NxPhysicsSDK::resizeGpuHeap() to allow changing the GPU heap size after SDK creation. See the GPU Memory section of the User’s Guide for details.
  • NxPhysicsSDKDesc::flags has NX_SDKF_NO_HARDWARE set by default.
  • Added checkValid() method to descriptors that return an error code instead of the boolean of isValid().
  • The experimental NxScene::simulateCompartments() method has been added. It gives more control over the order in which compartments get simulated.

You can download PhysX SDK 2.8.4.2 Beta via Developer Support Center.

If you are experiencing trouble with registration of PhysX Developer account, please refer to our registration guide.

Written by Zogrim

August 16th, 2010 at 5:00 pm

Posted in PhysX Drivers, PhysX SDK

Tagged with , ,

39 Responses to 'PhysX SDK 2.8.4: say goodbye to System Software'

Subscribe to comments with RSS

  1. A strange set of changes, but mostly good.

    In particular “Cloth simulation no longer performs prediction for kinematic rigid bodies…”. That always seemed like an odd thing when trying to sync the cloth to graphics.

    NX_SDKF_NO_HARDWARE on by default is rather odd, I guess it is good for newbies who might have driver problems etc.

      

    David Black

    16 Aug 10 at 6:57 pm

  2. NX_SDKF_NO_HARDWARE on by default is rather odd
    It’s OK, cause
    “The GPU heap will be allocated at PhysX SDK initialization time, even if no GPU-accelerated assets are used
    No to mention, that only few games are actually using those GPU-accel. assets

      

    Zogrim

    16 Aug 10 at 7:08 pm

  3. Shrug, I wouldnt worry about 32Mb video mem if I were doing a demo app or first project…

    But in any case, it seems odd that they need a static allocated region at all, surely it would be better to use the amount of memory occupied by hardware content, until the cache limit is reached, after which that amount is allocated. I find it difficult to believe CUDA doesnt have a moderatly efficient dynamic GPU mem allocator.

    Also it would be nice if we had some sys software for 2.8.4, the latest posted doesnt seem to support it. Only up to 2.8.3. Guess I can hack things to use the new DLLs though if it doesnt appear.

      

    David Black

    16 Aug 10 at 8:03 pm

  4. Also it would be nice if we had some sys software for 2.8.4, the latest posted doesnt seem to support it
    Indeed, but I was told it won’t require it, and you may see “driverless” feature in Release Notes.

    Anyway, if you’ll create “2.8.4″ folder at “Program Files\NVIDIA Corporation\PhysX\Engine”, and copy 2.8.4 PhysXCore and PhysXCooking .dlls from “Program Files\NVIDIA Corporation\NVIDIA PhysX SDK\v2.8.4_win_core\Bin\win32 (or win64)” – it will work

    But what I find most lame – SDK docs still have all hardware topics related to PPU (but no clear guide about GPU acceleration), while PPU isn’t supported anymore

      

    Zogrim

    16 Aug 10 at 8:24 pm

  5. “Indeed, but I was told it won’t require it, and you may see “driverless” feature in Release Notes.”

    Well it would be nice if someone told the sample apps that. Presumably they need to set a flag or something.

    “But what I find most lame – SDK docs still have all hardware topics related to PPU (but no clear guide about GPU acceleration), while PPU isn’t supported anymore”

    You would think NVIDIA would hire a proper docs writer for that. Even if they were not so out of date, the docs have a bunch of problems which would require some time to sort out. (although the fact that there are at least some docs is a good thing)

    Hopefully the docs will get an overhaul for 3.0.

      

    David Black

    16 Aug 10 at 8:50 pm

  6. You would think NVIDIA would hire a proper docs writer for that
    Yeah, who read these docs anyway.. /sign/

    But seriously, when SDK went from Ageia to Nvidia, they have hired someone to change “Ageia PhysX” to “Nvidia PhysX” through all the docs.

    And now I can’t even find those “cloth compression” features description.

    Hopefully the docs will get an overhaul for 3.0
    /fingers crossed/

    Anyway, what do you think about SSE2 compiler options ? have you tried it out yet vs x87 ?

      

    Zogrim

    16 Aug 10 at 8:59 pm

  7. “But seriously, when SDK went from Ageia to Nvidia, they have hired someone to change “Ageia PhysX” to “Nvidia PhysX” through all the docs.”

    What I found amusing was that they just changed the ageia.bmp into an NVIDIA logo without changing the name. (not that changing the name would have been a good use of time, if they are short on resources…)

    “Anyway, what do you think about SSE2 compiler options ? have you tried it out yet ?”

    I will try this when I upgrade my engine at some point. At present I cant run at acceptable fps without hardware cloth(and I only have a cloth skirt + a few flags).

    Maybe when the big boys have finished playing with APEX and us mere mortals get it, it will help. Assuming of course the optimizations dont provide a big enough boost(it is surprising the CPU cant handle the small amount of cloth I have anyway).

      

    David Black

    16 Aug 10 at 9:06 pm

  8. What I found amusing
    There was another funny case – in 2.01 PhysX plug-in for 3ds Max convex mesh size limit was set to 32 vertices only, cause Gavin has confused it with with PPU limit.

    Oh, wait.. that’s not funny – that’s horrible ;/
    Old docs are not good even for themselves

    my engine
    Can we have a link ? :)

      

    Zogrim

    16 Aug 10 at 9:19 pm

  9. http://therealdblack.wordpress.com

    Some screen shots and notes are on my blog, but to tell the truth I havnt done anything with the physics in a long time.

    I have been doing more important things, like recently a GUI editor + menus and bindings. Save game support and a crusade to eliminate all graphical glitches (eg shadow flickering, missed pixels between batches, lighting artifacts etc)

      

    David Black

    16 Aug 10 at 9:30 pm

  10. “Oh, wait.. that’s not funny – that’s horrible ;/
    Old docs are not good even for themselves”

    Better that the limit was too small I guess.

    But if things are anything like they were in the old days, getting similar info is next to imposible if you didnt actually write the code… :-)

    Ask 5 diferent firmware developers and get 5 diferent answears to the same question, damn that was fun ;-)

      

    David Black

    16 Aug 10 at 9:35 pm

  11. Some screen shots and notes are on my blog
    Looks promising anyway :)


    Some SDK 2.8.4. news from geeks3d
    I think there’s a relation with the new driverless model I saw in physxloader.h. There is a new function NxCreateModule() that allows to load different modules directly by their names like “PhysXCore” or “PhysXCooking”

    Maybe we’ll be able to solve this..

      

    Zogrim

    16 Aug 10 at 9:36 pm

  12. “I think there’s a relation with the new driverless model I saw in physxloader.h. There is a new function NxCreateModule() that allows to load different modules directly by their names like “PhysXCore” or “PhysXCooking”

    Maybe we’ll be able to solve this..”

    Sigh, can they make versioning/dynamic linking/SDK creation any more complicated…

    So I guess it is not a flag to load from the local dir.

    Using “NxCreateModule()”…

    File Name instead of module name maybe? or it loads from the local dir if the DLL is present and the new call is used?

    hmmm I wonder what it returns, perhaps it is similar to CoCreateInstance() with the additional fact that the object returned is a singleton.

    Now what happens with allocators and error streams???

    GR8

    (hmmm, maybe someday I will find out what the RRB backdoor is… presumably something related to APEX as there seems to be an RRB dll…)

      

    David Black

    16 Aug 10 at 10:50 pm

  13. I will find out what the RRB backdoor is
    I know the transcript – that’s Reduced Rigid Bodies :)

      

    Zogrim

    16 Aug 10 at 11:03 pm

  14. “I know the transcript – that’s Reduced Rigid Bodies ”

    Which transcript?

    But presumably that means there is a subset of the rigid body simulator floating around, presumably ~= 3.0 and/or what is supported by the GPU.

      

    David Black

    16 Aug 10 at 11:07 pm

  15. Unless it has a more technical meaning, ie something funky with reduced coordinates… but I doubt that.

      

    David Black

    16 Aug 10 at 11:08 pm

  16. Which transcript?
    RRB means Ruduced Rigid Bodies (I believe, that is called “transcript” ?)

    But, yeah, it seems it’s related to GPU rigid body physics, since “Rigid Bodies PhysX Patch” for Batman Arkham Asylum (only game with GPU RB currently) contains this RRB.dll

      

    Zogrim

    16 Aug 10 at 11:15 pm

  17. By transcript I think you mean acronym.

    transcript suggests you have read a copy of a conversation which has been written down.

      

    David Black

    16 Aug 10 at 11:23 pm

  18. By transcript I think you mean acronym
    My bad.. I will remember it :)

      

    Zogrim

    16 Aug 10 at 11:27 pm

  19. What does the title exactly mean?
    The future PhysX apps/games won’t require a middleware installed on the PC?

      

    GenL

    17 Aug 10 at 2:43 am

  20. The future PhysX apps/games won’t require a middleware installed on the PC?
    Yeah, in theory, games will be able to load PhysX SDK .dlls from their’s root folders, not from dedicated PSS installation – so it won’t be required.

    As for GPU PhysX components, they will probably merge them with GPU drivers.

      

    Zogrim

    17 Aug 10 at 6:06 pm


Leave a Reply

*
Copyright © 2009-2014. PhysXInfo.com | About PhysXInfo.com project | Privacy Policy
PhysX is trademark of NVIDIA Corporation