NVIDIA PhysX SDK

Overview

NVIDIA PhysX SDK 4.1

Copyright (c) 2021 NVIDIA Corporation. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  • Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
  • Neither the name of NVIDIA CORPORATION nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Introduction

Welcome to the NVIDIA PhysX SDK source code repository. This depot includes the PhysX SDK and the Kapla Demo application.

The NVIDIA PhysX SDK is a scalable multi-platform physics solution supporting a wide range of devices, from smartphones to high-end multicore CPUs and GPUs. PhysX is already integrated into some of the most popular game engines, including Unreal Engine, and Unity3D. PhysX SDK on developer.nvidia.com.

Documentation

Please see Release Notes for updates pertaining to the latest version.

The full set of documentation can also be found in the repository under physx/documentation or online at http://gameworksdocs.nvidia.com/simulation.html

Platform specific information can be found here:

Quick Start Instructions

Requirements:

  • Python 2.7.6 or later
  • CMake 3.12 or later

To begin, clone this repository onto your local drive. Then change directory to physx/, run ./generate_projects.[bat|sh] and follow on-screen prompts. This will let you select a platform specific solution to build. You can then open the generated solution file with your IDE and kick off one or more configuration builds.

To build and run the Kapla Demo see kaplademo/README.md.

Acknowledgements

This depot contains external third party open source software copyright their respective owners. See kaplademo/README.md and externals/README.md for details.

Issues
  • Raycasts fail for articulations after a while

    Raycasts fail for articulations after a while

    I have set up a ragdoll using articulations and I am observing rather weird behavior with raycasts. Just after a while of activity, parts of an articulation stop being hit by raycasts. It still interacts with other actors and can be pushed by a character controller, but raycasts just don't hit those parts anymore, as if suddenly the collision filter changed.

    Here is a video (zipped because apparently I can upload larger zips than mp4s):

    Raycasts through Articulation.zip

    After a while the top beam stops hitting the articulation, for no apparent reason. Then the gun also doesn't hit those parts anymore, though it still hits the bottom half of the articulation.

    I'm also attaching the corresponding PVD recording, though since articulations aren't supported that well by it, I don't see any useful data in it.

    Articulation Raycasts.zip

    opened by jankrassnigg 40
  • drives failing to achieve maximum force

    drives failing to achieve maximum force

    I'm simulating a wheel loader. This link shows the basic layout of a wheel loader for illustration purposes though it's not this one that I'm simulating https://wastemanagementreview.com.au/wp-content/uploads/2018/11/wheel-loader-pic.jpg .

    Effectively there's a linear drive which pushes on the lever in the middle which in turn pulls on a link connected to the bucket which then rotates. Note that this is implemented using constrained ridid bodies rather than articulations with the PGS solver in physx 4.1.2. The drive itself is a force limited damper with target velocity dictated by user input. There are a few complications over that basic model which I'm glossing over which are hopefully unimportant.

    I have a requirement that when the bucket is on the ground and the hydraulic is contracted such that the bucket is rotated downwards the machine should lift off the ground. i.e. the hydraulic which rotates the bucket should be strong enough to lift the machine by rotating the bucket.

    What I am observing is that the machine is failing to lift and yet the force exerted by the drive is a fraction of the maximum force it is permitted to exert. I'd like to know:

    • why is this?
    • what are my options to fix it?

    Changing the damping coefficient has a minimal impact. Changing the target velocity makes a big difference. If I say I want to extend at 1m/s with 10^10N of force then I don't get enough force to move. If I say I want to extend at 2m/s then it moves just fine. These are of course just illustrative values.

    My suspicion is that it's to do with the relevant mass ratios in the system. In general the ratios of the various physical parts in the system maintain the 1:10 recommendation but they're not ideal. It's a little harder to tell for moments of inertia but I believe in my case the force pushing on the bucket is only about 9% of the force at the hydraulic (depending on the exact configuration of the system) due to the levers involved. The mass any individual part is certainly less than 10% of the mass of the whole machine which I'm trying to lift.

    I believe the TGS solver is intended to do a better job of this and indeed it has solved similar problems in the past for me but it has also caused unacceptable instability (read: explosions) so I conclude that it is inappropriate for my problem.

    I'm curious about whether articulations would do a better job of this. Unfortunately it would be quite difficult to restructure everything to use an articulation so I wouldn't want to attempt it unless there was a theoretical expectation it would solve my problem. I'm also concerned about the circular dependencies in the parts in the system and how that would work for an articulation.

    From reading the code and documentation, it appears that using the mass/inertia scales should solve my problem. However I've found that if I scale mass/inertia symmetrically across the two bodies then I achieve no effect. This surprises me as it seems like for damping to make so little difference, dt * damping * unitResponse must be must greater than 1 so reducing unitResponse should solve my problem but in (https://github.com/NVIDIAGameWorks/PhysX/blob/c3d5537bdebd6f5cd82fcaf87474b838fe6fd5fa/physx/source/lowleveldynamics/src/DyConstraintSetup.cpp#L478) it appears that unitResponse is directly proportional to the mass/inertia scales.

    Applying mass/inertia scales asymmetrically results in a net force on the system as a whole resulting in my machine accelerating faster and faster along the ground without any input.

    I could implement some sort of feedback loop where I artifically apply additional force or increase target speed when I observe that neither the target speed nor maximum force are reached. However I'd prefer to avoid this because of the weird side effects it might have in cases where things would otherwise work fine.

    opened by asdasdasdasdasdf 39
  • PhysX 5.0 - Available in 2020 ?

    PhysX 5.0 - Available in 2020 ?

    PhysX 5.0 is just around the corner, and we wanted to provide a look at all the new features! In this version, available in 2020, we’ll be introducing support for a unified constrained particle simulation frame。

    Tody is 2020.12.29!

    opened by swq0553 24
  • Bug with TGS + linear limit  or linear drive between Kinematic and Dynamic body

    Bug with TGS + linear limit or linear drive between Kinematic and Dynamic body

    Hi all,

    Re-posting this from within a longer thread for visibility and clarity, given the problem is now pretty clearly a bug.

    Original issue

    • https://github.com/NVIDIAGameWorks/PhysX/issues/356

    Problem

    With a PxD6Joint between a kinematic and dynamic rigid body, both limits and drives misbehave under TGS, but not PGS. The dynamic body appears to inherit too much velocity from the kinematic body.

    TGS

    | Case | Demo |:-----|:--- | TGS Linear Limit | bug | PGS Linear Limit | good | TGS Drive | bugdrives

    The problem is made much worse with a rotating kinematic body.

    | Case | Demo |:-----|:--- | PGS Linear Drive | kinematicrotating | TGS Linear Drive | tgsrotation


    Reproducible

    Lines of interest are..

    And the result as seen from PVD, where TGS appears to introduce additional velocity to the dynamic rigid when jointed to an animated kinematic rigid, whereas PGS does not.

    bugtgs pgsgood


    PxDistanceJoint

    The problem can also be seen with other joints, like the PxDistanceJoint

    PxJoint* createJoint(PxRigidActor* parent, const PxTransform& parentTm,
                         PxRigidActor* child, const PxTransform& childTm) {
    
        PxDistanceJoint* joint = PxDistanceJointCreate(*gPhysics, parent, parentTm, child, childTm);
        joint->setDistanceJointFlag(PxDistanceJointFlag::eMAX_DISTANCE_ENABLED, true);
        joint->setDistanceJointFlag(PxDistanceJointFlag::eSPRING_ENABLED, true);
        joint->setMaxDistance(0.0f);
        joint->setStiffness(100.f);
        joint->setDamping(100.f);
    
        return joint;
    }
    

    distancealsobad

    Any idea what a fellow like myself can do to fix this?

    Thanks

    opened by alanjfs 19
  • Odd behavior with linearLimit and PxD6Joint

    Odd behavior with linearLimit and PxD6Joint

    Hi all,

    I'm looking at an odd result I can't make sense out of.

    oddmuscle

    I've simplified the setup with a minimal amount of moving parts.

    Which, as you can see, there are a total of 3 rigid bodies and 2 constraints.

    1. Two kinematic rigids for the upper and lower arm
    2. One dynamic rigid for the "muscle"
    3. Two constraints pulling it in either direction, towards the muscle attachment points on both arm rigids

    I'll attach a PVD session file here as well, where you can inspect the attributes more closely.

    madmuscle.zip

    What I'm expecting to see, is for these two constraints to pull the muscle in a straight line towards the end points. But instead, it somehow gets mad amounts of angular force applied to it as the lower arm moves. Why? What's happening?

    opened by alanjfs 15
  • Crash in PxsNphaseImplementationContext::unregisterContactManager method.

    Crash in PxsNphaseImplementationContext::unregisterContactManager method.

    Visual studio debugger console output:

    "Exception thrown: read access violation. cm was nullptr."

    Autos output:

    •   cm	0x0000000000000000 <NULL>	physx::PxsContactManager *
      
    •   this	0x0000022da9505fa0 {mRemovedContactManagers={mData=0x0000000000000000 {???} mSize=0 mCapacity=0 } mNarrowPhasePairs=...}	physx::PxsNphaseImplementationContext *
      
    •   physx::PxvNphaseImplementationContextUsableAsFallback	{...}	physx::PxvNphaseImplementationContextUsableAsFallback
      
    •   mRemovedContactManagers	{mData=0x0000000000000000 {???} mSize=0 mCapacity=0 }	physx::shdfnd::Array<unsigned int,physx::shdfnd::NamedAllocator>
      
    •   mNarrowPhasePairs	{mOutputContactManagers={mData=0x0000022db38209a0 {contactPatches=0x0000022e2d271120 "" contactPoints=...} ...} ...}	physx::PxsContactManagers
      
    •   mNewNarrowPhasePairs	{mOutputContactManagers={mData=0x0000022e2ca80000 {contactPatches=0x0000000000000000 <NULL> contactPoints=...} ...} ...}	physx::PxsContactManagers
      
    •   mModifyCallback	0x0000000000000000 <NULL>	physx::PxContactModifyCallback *
      
    •   mIslandSim	0x0000022dc6042b40 {mIslandHandles={mFreeHandles={mData=0x0000022ee403ac80 {1162} mSize=1257 mCapacity=...} ...} ...}	physx::IG::IslandSim *
      

    Call Stack:

    PhysX_64.dll!physx::PxsNphaseImplementationContext::unregisterContactManager(physx::PxsContactManager * cm) Line 691 C++ PhysX_64.dll!physx::Sc::Scene::finishBroadPhaseStage2(const unsigned int ccdPass) Line 6074 C++ PhysX_64.dll!physx::Sc::Scene::updateCCDSinglePassStage3(physx::PxBaseTask * continuation) Line 3125 C++ PhysX_64.dll!physx::Cm::Task::run() Line 67 C++ CarbonEditor.exe!physx::Ext::CpuWorkerThread::execute() Line 97 C++ PhysXFoundation_64.dll!physx::shdfnd::`anonymous namespace'::PxThreadStart(void * arg) Line 101 C++ kernel32.dll!BaseThreadInitThunk() Unknown ntdll.dll!RtlUserThreadStart() Unknown

    opened by lbrysh 14
  • D6 joints jitter on ragdoll

    D6 joints jitter on ragdoll

    Hello.

    We have ragdoll implementation using D6 joints with soft limits [All linear limits are locked, some angular limits are locked others are limited to some degree]. It works fine on high fps, simulation rate. Sadly it doesn't work well on low fps(20-30) and low simulation rate(~30). Joints produce jitter. [We use PGS in the project but switching to TGS didn't help]

    On the other hand there is no such issues on fps and simulation rate around 100. Expamle: ezgif-4-a8254f77fc23

    So what I tried:

    1. enabled projection for joints (didn't help)
    2. tweaked max depenetration vel, contact/rest offset (didn't help)
    3. relaxes joints limits (didn't help)
    4. tweaked mass of the bodies. this helped in most cases but ragdoll was looking not physically/visually correct. Artists didn't agree to this solution.
    5. increased solver iteration count (didn't help)

    I tried to make use of PVD but wasn't able to collect all the necessary information about joint. What I was able to collect you can find in the link below(.pxd2): https://drive.google.com/file/d/1SC5bFUe-6WemCRKsqEG8vfZUbovOPZnb/view?usp=sharing

    Also I gave it a try to debug PhysX code but it appears to be pretty complicated part of code related to constraints/contacts, so I gave up on this for now. If you can point me to spots in code where I can start digging would be just awesome.

    Based on what I've tried and what I've seen, my guess that joint's limits can't be solved by a solver that's why bodies remains awaken for a while trying to solve the constraints. But for some reasons we can't observe such behavior on the higher simulation rate. maybe there is some clamping for say impulses that on higher simulation dt clamp necessary impulse to push other bodies and fulfill the constraint. Nevertheless I wasn't able to find anything like that.

    Any advice is highly appreciated!

    opened by Esentiel 13
  • TGS and gaps between PxD6Joints

    TGS and gaps between PxD6Joints

    Hello PhysX team!

    I've had a problem for many moons whereby any gap between two rigid bodies connected by a PxD6Joint (or any joint, it seems) would cause severe jitter in my simulations.

    https://user-images.githubusercontent.com/47274066/155728339-fb135657-2d32-4ef6-ba60-5ba95d6653fb.mp4

    The problem is worsened with thinner radii and greater differences in mass. Except when using PGS, at which point there seems to be no limit to how thin or short things can get.

    PGS

    https://user-images.githubusercontent.com/47274066/155728632-73b38d0c-7943-40a6-bc21-b3f2304d7d1c.mp4

    I've managed to reproduce the problem using only these capsule, but the problem is much worse in more complex setups and much less obvious that gaps are to blame. Here are a few PVDs to illustrate things.

    | PVD | Description |:-----|:----- | gaps_1_sphere.zip | Largest possible gap, a sphere |gaps_2_capsule.zip | Slightly less of a gap, with a short capsule | gaps_3_mass1.zip | Less gap, with with a constant mass of 1 for each rigid body | gaps_4_pgs.zip | PGS, works in any scenario.

    I really enjoy TGS for it's strong drives and would much prefer to keep using it, but these jitters make the choice less easy. :( It's taken a while to get it to happen on such a small scale, and next time it happens in a more complex scenario I'll try and upload the PVD for it as well. In case there are two separate issues hiding underneath.

    Any idea of what to do about this?

    opened by alanjfs 12
  • Sweep normals on edges

    Sweep normals on edges

    Hi. I have noticed, that if geometry (in my case a capsule) hits an edge during scene sweep, the blocking hit normal seems to be a product of some sort of interpolation between the normals of faces that form given edge. So my questions are:

    1. Is there a way to get actual normals of both surfaces without doing additional queries?
    2. If not is there a reliable way to get those normals with additional queries? I tried doing raycasts with small offsets from original hit point but this approach feels... shaky.

    Context: I perform a downwards sweep in order to detect floor surface. So when hitting edge, I would like to check both surfaces to see, which one is closer to horizontal plane. Basically I am looking for a way to reliably get floor normal (blue) instead of edge "normal" (red): image

    opened by nikita-one 12
  • License incompatibility of PhysX' BSD and FleX' Gameworks license

    License incompatibility of PhysX' BSD and FleX' Gameworks license

    To my understanding, we can't use PhysX-4.0 together with FleX because PhysX is now distributed under the 3-Clause BSD license which forbids the usage of the name NVIDIA without written consent. This is the exact opposite of the NVIDIA GAMEWORKS license as it requires detailed attribution to NVIDIA in section 6.

    Is there any recommendation on how to deal with that? I am quite certain you don't want to allow the usage of NVIDIA's name individually? Or ... can you tell if there are any plans for FleX becoming available under BSD license?

    opened by thebrandre 11
  • How in include Physx in a cmake project

    How in include Physx in a cmake project

    I am using PhysX and cmake to make a game for my university project. However, I am having issues with cmake library. My PhysX code is added as a git submodule within my project in submodules directory

    cmake_minimum_required(VERSION 3.14)
    ## Giving a name to the project
    project(weird_golf_game)
    
    #Setup CMake to run tests
    enable_testing()
    
    ## Including headers, from both the current project and from the imported libraries
    include_directories(include)
    ...
    include_directories(submodules/PhysX/physx/include)
    add_subdirectory(submodules/PhysX/physx/compiler/public)
    
    ## I want to use the C++17 standard, forsooth!
    set(CMAKE_CXX_STANDARD 17)
    set(CMAKE_CXX_STANDARD_REQUIRED ON)
    
    # OpenGL
    find_package(OpenGL REQUIRED)
    
    add_executable(weird_golf_game ...)
    target_link_libraries(weird_golf_game ... opengl32 PhysX)
    

    but on running cmake I am getting these error:

    PHYSX ROOT D:/Source/Repos/weird-golf-game/submodules/PhysX/physx
    PhysX Build Platform: 
    Using CXX Compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.23.28105/bin/Hostx64/x64/cl.exe
    CMake Error at submodules/PhysX/externals/cmakemodules/NvidiaBuildOptions.cmake:48 (MESSAGE):
      When using the GameWorks output structure you must specify
      PX_OUTPUT_LIB_DIR as the base
    Call Stack (most recent call first):
      submodules/PhysX/physx/source/compiler/cmake/CMakeLists.txt:70 (INCLUDE)
    
    
    Configuring incomplete, errors occurred!
    See also "D:/Source/Repos/weird-golf-game/out/CMakeFiles/CMakeOutput.log".
    
    opened by arijeetbaruah 10
  • triangleMesh collision detection

    triangleMesh collision detection

    Hello,

    I have an application where I need to detect the collision of 2 objects (RigidBody Kinematic and Static) as trianglemesh.

    In the ReportFileShader I get the collision but the SimulationEventCallback::OnContact is not invoked.

    According to: https://documentation.help/NVIDIA-PhysX-SDK-Guide/Shapes.html

    the collision of 2 triangle meshes is not supported.

    Is this still up to date? or is there a possibility how I could get the collision?

    opened by EberleAutomatischeSysteme 1
  • Really Hope Someone Can Answer This About PhysX Wheel Collision

    Really Hope Someone Can Answer This About PhysX Wheel Collision

    Hello,

    I have been working on a physics based motorcycle on and off for over a year. One of the biggest issues is the wheel collision. If you use a sphere for the wheel it works smooth but the issue is the sphere collision sticks out the side and will hit other items or when the bike falls over the wheels will be floating in the air because of the sphere collision.

    If you use a cylinder the tire works perfect at low speeds and the tire acts realist but when you start going faster the tires start to bounce off the ground see the attached videos.

    Do you know how to make a cylinder in a 3D modeling program that would roll smooth? I have tried making a few different ones in a 3D modeling program and then importing them into Unreal Engine 4.27/PhysX but so far all the ones I made bounce at high speeds.

    I would really, really, really, appreciate any help you could provide, this is driving me mad :)!!!

    Sincerely, John Daniels Proud Arts LLC

    Tire1 Tire2

    https://user-images.githubusercontent.com/44750851/172510001-f0286eae-17a0-4bb6-8afc-4838c1328823.mp4

    https://user-images.githubusercontent.com/44750851/172510009-44b7669f-89e5-4fa4-aac2-b20e70171883.mp4

    opened by ProudArts 7
  • macOS arm64 support and various other fixes

    macOS arm64 support and various other fixes

    By default this will make a macOS universal build (with both x86_64 and arm64 in the same files) but supports per-architecture builds using the CMake PX_OUTPUT_ARCH flag.

    opened by dpogue 2
  • Angular Velocity vs Quaternions

    Angular Velocity vs Quaternions

    I may just be having a dumb moment, but I'm having some trouble wrapping my head around the angular velocity component in PhysX.

    Angular velocity is expressed as a vector-3. Does this mean it is equivalent to Euler angles or yaw-pitch-roll?

    I'm used to working with rotations as quaternions, matrices, or axis-angles, so I'm probably tripping over myself more than is necessary.

    What I'm trying to accomplish is to compute a unit rotation (and translation) between two full/absolute transforms (quaternion + vector), then convert that into linear and angular velocity. IE, convert 2 keyframes into velocity. But I got hung up when I started to convert my rotation into an angular velocity vector.

    I've converted Euler into quaternion, but not the other way around. After looking around online, I managed to scrape together this function out of bits and pieces:

    vec3 qtn::Eulers() const
    {
    	return vec3(
    		atan2(-2.0f * ( x * y - w * z ),w * w + x * x - y * y - z * z),
    		asin(2.0f * ( x * z + w * y )),
    		atan2(-2.0f * ( y * z - w * x ),w * w - x * x - y * y + z * z)
    	);
    }
    

    My project is still not at a stage where I can test things. I don't expect anyone to confirm the math for me, but could anyone tell me if I'm heading in the right direction? Can I generate this vector, scale it (if necessary), then upload that to a body as angular velocity?

    EDIT: After doing some more research, it seems there is yet another way to represent a rotation - especially when that rotation is representing an angular velocity. And that is to define a unit vector for the rotation axis, then scale that axis by the angle-velocity-length (per second). Now I'm not a math wiz, but that seems very similar to a Euler angle vector. Perhaps when it comes to velocity, there really isn't a difference between Euler angles and a scaled axis? If anyone can shed some light on this for me, I would really appreciate it.

    I'm assuming there is code somewhere under the hood of PhysX that would help me understand angular velocity. Most likely the code that applies that velocity to the current body's rotation. But I haven't been able to locate that bit yet.

    Sorry to drag this out. Really appreciate any guidance.

    opened by RobertMtx 1
  • How to calculate

    How to calculate "damage", or "collision force"

    Is it possible to get information on how much "damage", or force, is applied to each object during a collision? I saw that it's possible to get the "impulse" but I'm not sure if that is the right way to go. The alternative is to roll a homegrown solution, but that seems counter productive as it would seem that the physics engine already can provide this information.

    opened by mlp1802 16
  • Visual Studio 2022 support soon?

    Visual Studio 2022 support soon?

    generate_projects.bat doesn't work for me. does anyone know if they will update the SDK to support Visual Studios 2022? I'm not in any particular rush or anything but I was wondering if anyone can confirm if someone is working on it and/or an estimate as to when it'll be available. I hope I didn't confuse anyone

    opened by lotusblue963 0
Releases(4.0.0)
Owner
NVIDIA GameWorks
NVIDIA Technologies for game and application developers
NVIDIA GameWorks
Gstreamer plugin that allows use of NVIDIA Maxine SDK in a generic pipeline.

GST-NVMAXINE Gstreamer plugin that allows use of NVIDIA MaxineTM sdk in a generic pipeline. This plugin is intended for use with NVIDIA hardware. Visi

Alex Pitrolo 14 May 11, 2022
NVIDIA Image Scaling SDK

NVIDIA Image Scaling SDK v1.0 The MIT License(MIT) Copyright(c) 2021 NVIDIA CORPORATION & AFFILIATES. All rights reserved. Permission is hereby grante

NVIDIA GameWorks 346 Jun 23, 2022
GPU Cloth TOP in TouchDesigner using CUDA-enabled NVIDIA Flex

This project demonstrates how to use NVIDIA FleX for GPU cloth simulation in a TouchDesigner Custom Operator. It also shows how to render dynamic meshes from the texture data using custom PBR GLSL material shaders inside TouchDesigner.

Vinícius Ginja 35 Apr 7, 2022
Forward - A library for high performance deep learning inference on NVIDIA GPUs

a library for high performance deep learning inference on NVIDIA GPUs.

Tencent 123 Mar 17, 2021
A library for high performance deep learning inference on NVIDIA GPUs.

Forward - A library for high performance deep learning inference on NVIDIA GPUs Forward - A library for high performance deep learning inference on NV

Tencent 502 May 31, 2022
GPU ray tracing framework using NVIDIA OptiX 7

GPU ray tracing framework using NVIDIA OptiX 7

Shunji Kiuchi 22 Jun 11, 2022
ROS2 packages based on NVIDIA libArgus library for hardware-accelerated CSI camera support.

Isaac ROS Argus Camera This repository provides monocular and stereo nodes that enable ROS developers to use cameras connected to Jetson platforms ove

NVIDIA Isaac ROS 26 Jun 16, 2022
Hardware-accelerated DNN model inference ROS2 packages using NVIDIA Triton/TensorRT for both Jetson and x86_64 with CUDA-capable GPU.

Isaac ROS DNN Inference Overview This repository provides two NVIDIA GPU-accelerated ROS2 nodes that perform deep learning inference using custom mode

NVIDIA Isaac ROS 36 Jun 20, 2022
Visual odometry package based on hardware-accelerated NVIDIA Elbrus library with world class quality and performance.

Isaac ROS Visual Odometry This repository provides a ROS2 package that estimates stereo visual inertial odometry using the Isaac Elbrus GPU-accelerate

NVIDIA Isaac ROS 164 Jun 19, 2022
The core engine forked from NVidia's Q2RTX. Heavily modified and extended to allow for a nicer experience all-round.

Nail & Crescent - Development Branch Scratchpad - Things to do or not forget: Items are obviously broken. Physics.cpp needs more work, revising. Proba

PalmliX Studio 13 Jun 3, 2022
Docker files and scripts to setup and run VINS-FUSION-gpu on NVIDIA jetson boards inside a docker container.

jetson_vins_fusion_docker This repository provides Docker files and scripts to easily setup and run VINS-FUSION-gpu on NVIDIA jetson boards inside a d

Mohamed Abdelkader Zahana 18 May 30, 2022
NVIDIA Texture Tools samples for compression, image processing, and decompression.

NVTT 3 Samples This repository contains a number of samples showing how to use NVTT 3, a GPU-accelerated texture compression and image processing libr

NVIDIA DesignWorks Samples 31 Jun 13, 2022
Golang bindings for Nvidia Datacenter GPU Manager (DCGM)

Bindings Golang bindings are provided for NVIDIA Data Center GPU Manager (DCGM). DCGM is a set of tools for managing and monitoring NVIDIA GPUs in clu

NVIDIA Corporation 28 Jun 23, 2022
Vendor and game agnostic latency reduction middleware. An alternative to NVIDIA Reflex.

LatencyFleX (LFX) Vendor and game agnostic latency reduction middleware. An alternative to NVIDIA Reflex. Why LatencyFleX? There is a phenomenon commo

Tatsuyuki Ishi 480 Jun 26, 2022
TensorRT is a C++ library for high performance inference on NVIDIA GPUs and deep learning accelerators.

TensorRT Open Source Software This repository contains the Open Source Software (OSS) components of NVIDIA TensorRT. Included are the sources for Tens

NVIDIA Corporation 5.5k Jun 27, 2022
Dataset Synthesizer - NVIDIA Deep learning Dataset Synthesizer (NDDS)

NVIDIA Deep learning Dataset Synthesizer (NDDS) Overview NDDS is a UE4 plugin from NVIDIA to empower computer vision researchers to export high-qualit

NVIDIA Corporation 502 Jun 15, 2022
waifu2x converter ncnn version, runs fast on intel / amd / nvidia GPU with vulkan

waifu2x ncnn Vulkan ncnn implementation of waifu2x converter. Runs fast on Intel / AMD / Nvidia with Vulkan API. waifu2x-ncnn-vulkan uses ncnn project

null 2.1k Jun 24, 2022
NVIDIA GPUs htop like monitoring tool

NVTOP What is NVTOP? Nvtop stands for NVidia TOP, a (h)top like task monitor for NVIDIA GPUs. It can handle multiple GPUs and print information about

Maxime Schmitt 4.1k Jun 24, 2022