A multi core friendly rigid body physics and collision detection library suitable for games and VR applications.

Overview

CLA assistant Build Status Quality Gate Status Bugs Code Smells

Jolt Physics

A multi core friendly rigid body physics and collision detection library suitable for games and VR applications.

Ragdoll Pile
A YouTube video showing a ragdoll pile simulated with Jolt Physics.

For more demos and videos go to the Samples section.

Design Considerations

So why create yet another physics engine? First of all, this has been a personal learning project and secondly I wanted to address some issues that I had with existing physics engines:

  • In games we usually need to do many more things than to simulate the physics world and we need to do this across multiple threads. We therefore place a lot of emphasis on concurrently accessing the physics simulation data outside of the main physics simulation update:
    • Sections of the world can be loaded / unloaded in the background. A batch of physics bodies can be prepared on a background thread without locking or affecting the physics simulation and then inserted into the world all at once with a minimal impact on performance.
    • Collision queries can run in parallel with other operations like insertion / removal of bodies. The query code is guaranteed to see a body in a consistent state, but when a body is changed during a collision query there is no guarantee if the change is visible to the query or not. If a thread modifies the position of a body and then does a collision query, it will immediately see the updated state (this is often a problem when working with a read version and a write version of the world).
    • It is also possible to run collision queries in parallel to the main physics simulation by doing the broad phase query before the simulation step. This way, long running processes (like navigation mesh generation) can be spread out across multiple frames while still running the physics simulation every frame.
  • One of the main sources of performance problems we found was waking up too many bodies while loading / unloading content. Therefore, bodies will not automatically wake up when created and neighboring bodies will not be woken up when bodies are removed. This can be triggered manually if desired.
  • The simulation runs deterministically, so you could replicate a simulation to a remote client by merely replicating the inputs to the simulation.
  • The simulation of this physics engine tries to simulate behavior of rigid bodies in the real world but makes approximations in the simulation so should mainly be used for games or VR simulations.

For more information see the Architecture section.

Features

  • Simulation of rigid bodies of various shapes using continous collision detection:
    • Sphere.
    • Box.
    • Capsule.
    • Tapered-capsule.
    • Cylinder.
    • Convex hull.
    • Compound.
    • Mesh (triangle).
    • Terrain (height field).
  • Simulation of constraints between bodies:
    • Fixed.
    • Point.
    • Distance (including springs).
    • Hinge.
    • Slider (also called prismatic).
    • Cone.
    • Smooth spline paths.
    • Swing-twist (for humanoid shoulders).
    • 6 DOF.
  • Motors to drive the constraints.
  • Collision detection:
    • Casting rays.
    • Testing shapes vs shapes.
    • Casting a shape vs another shape.
    • Broadphase only tests for quickly determining which objects may intersect.
  • Sensors (trigger volumes).
  • Animated ragdolls:
    • Hard keying (kinematic only rigid bodies).
    • Soft keying (setting velocities on dynamic rigid bodies).
    • Driving constraint motors to an animated pose.
  • Game character simulation (capsule), although many games may want to implement characters just using collision tests for more control over the simulation.
  • Vehicle simulation of wheeled and tracked vehicles.
  • Water buoyancy calculations.

Supported Platforms

  • Windows (VS2019) x64
  • Linux (tested on Ubuntu 20.04) x64/ARM64
  • Android (tested on Android 10) x64/ARM64
  • Platform Blue (a popular game console) x64

Required CPU features

  • On x86 the minimal requirements are SSE4.2 but the library can be compiled using FP16C, AVX or AVX2.
  • On ARM64 the library requires NEON with FP16 support.

Compiling

  • The library has been tested to compile with Cl (Visual Studio) and Clang 10+.
  • It uses C++17 and only depends on the standard template library.
  • It doesn't make use of compiler generated RTTI or exceptions.
  • If you want to run on Platform Blue you'll need to provide your own build environment and PlatformBlue.h file due to NDA requirements (see Core.h for further info).

For build instructions go to the Build section.

License

The project is distributed under the MIT license.

Issues
  • Character Controller ground detection problems

    Character Controller ground detection problems

    The way the character controller checks for the ground state has a few problems.

    It simply makes an overlap check with the character shape at the current location to determine which bodies it touches. Unfortunately, this is very unreliable. In many cases there will be no overlap at all, simply because after the simulation the CC is standing ON the ground, but not PENETRATING the ground and thus the check may or may not return the ground body, depending on floating point accuracy I'd guess.

    Simply debug drawing the ground position of the CC and the ground state shows that it flickers between different states. It becomes very apparent when you want to apply the ground velocity (moving platforms), which randomly slide away beneath the CC.

    One way I have attempted to fix this, is to move the ground check artificially 1cm downwards. This fixes the ground detection BENEATH the CC. However, the 'sliding' state is equally affected by this. Once you jump into a wall, the overlap check may or may not return the wall object and thus vary between 'sliding' and 'in air'. To prevent the player to be able to pin the CC to a wall by walking/flying into it, I want to clamp the input velocity against the touched surface. So I need to reliably know when the CC touches a wall. Here I can't use the 'move a tiny bit downwards' tricky though. Instead, the CC shape would need to be expanded slightly. Since the user provided CC shape is used for the overlap check, I currently don't see how this could be accomplished inside Jolt.

    At the moment I think my best bet would be to copy&paste the Jolt CC ground detection code into my code, and adjust it with my own (known) expanded capsule shape. Not a horrible solution actually, but maybe you have an idea how to make this more usable for everyone.

    opened by jankrassnigg 18
  • WIP: Support for 32-bit platforms

    WIP: Support for 32-bit platforms

    I've been writing an implementation of the Source Engine's physics library (VPhysics which uses IVP/Havok) used in games such as Half-Life 2, Portal 2, L4D2, Garry's Mod, etc with Jolt.

    There are some engine branches that are 64-bit and 32-bit, and I would like to provide support for both. I also have a few friends who are integrating Jolt into older games (such as Quake 2) or mods (for games such as Half-Life 1), most of which are 32-bit, to learn more about it.

    I completely understand if you don't want to deal with having this upstream or at least being officially supported.

    Leaving this as a draft as it is not complete yet, but I figured I'd start the conversation now. As of me making this, it can at least run the samples + game physics (albeit with some complaints in Debug).

    opened by Joshua-Ashton 17
  • Add Debug draw helpers for ShapeCast & CastRay

    Add Debug draw helpers for ShapeCast & CastRay

    It would be really helpful for debugging to have the ability to ->Draw a ShapeCast or RayCast wiuth the same params as a CastShapeVsShape or CastRay.

    Obviously one can do their own with pShape->Draw, but for debugging sanity it would be really helpful to have a simple way to visualize individual traces and rays going on without any potential mess ups in the app's code getting the CentreOfMass offsets wrong, rotations/inverse rotations etc.

    Right now in our code, that is what we are doing, with a little picture in picture window showing all the traces, but obviously it would be super nice to validate against exactly what Jolt is seeing.

    opened by Joshua-Ashton 17
  • MotorSettings could use more in-depth documentation

    MotorSettings could use more in-depth documentation

    All physics engines I've worked with (PhysX, Bullet, Havok) expose some values that require some deep understanding of how physics solvers work (which I totally don't have). Surprisingly, the documentation for these values is always very shallow, I guess because the people writing the docs are also missing that deep understanding - your chance to be better! ;-)

    I'm currently applying a motor to a hinge constraint.

    In MotorSettings what is the min force/torque limit? Does this have to do with the direction into which it goes? Or is "min" literally the minimum force/torque that is applied (that wouldn't make sense with the symmetric values though).

    Why is there a distinction between torque and force? As far as I can tell, you always only drive one thing, right? Wouldn't that mean that every drive uses exclusively one value or the other, but never both? In that case, I'd simplify the struct (maybe always call it "force" and mention in the comment that this is a torque for rotational things).

    For position targets, what exactly do mFrequency and mDamping do? Especially mFrequency doesn't tell me much. And can mDamping be larger than 1 ? Maybe give an example for when to set these values differently.

    Also "position" is a bit of an overloaded term, when driving a hinge to a target angle, it is not immediately obvious that this is a "position" (I first thought this might rather apply to slider constraints).

    I am also looking up a lot at implementation details to figure some stuff out. For example to see what "Set symmetric force limits" exactly means and under which conditions "IsValid" actually returns true/false.

    Finally, why is driving a hinge to a target angle so weak?? I have set both force and torque limit to 10000 but it just stops when it encounters any resistance. However, driving the velocity instead, using a limit of 100 is already pretty strong and will push the same object easily out of the way.

    opened by jankrassnigg 15
  • Various mesh shape questions

    Various mesh shape questions

    I recently got triangle meshes and convex meshes up and running in my engine. It's all working, but there were a couple of things I'd like to ask about.

    1. How exactly am I supposed to serialize and deserialize baked/cooked meshes? If I understand it correctly, ConvexHullShapeSettings and MeshShapeSettings are kind of the "mesh resources", meaning the shared mesh state that is referenced by the individual shape instances. For the time being I just serialize the mesh data out myself and when I read the data, I create a new MeshShapeSettings or ConvexHullShapeSettings object from it, passing the data to their constructors. I would assume that this is not the most efficient way to do things. With other physics engines I made the experience that baking physics meshes can take quite some time, and I would prefer not to spend it during loading.

      I saw that the settings classes are derived from SerializableObject but from there on I didn't see an easy way to use this. I think I saw something about std::istream, which, to be frank, completely put me off, since I personally absolutely dislike the std stream stuff.

      Usually I would expect a lightweight reader / writer base class, that literally just needs a virtual "ReadBytes" and "WriteBytes" function, that I can derive from and implement.

    2. Convex hull generation is something that I guess can go wrong? At least in PhysX it could because it had a vertex limit of 255 (which is why I ended up writing my own anyway). Can that potentially happen in Jolt? And if so, how is that communicated through the ConvexHullShapeSettings interface?

    3. For tooling and debugging I have a component that can visualize a collision mesh. Since I don't want to store the mesh data twice, just for visualization purposes, I prefer to query the mesh data from the physics engine on demand instead. Here is what this looks like in the editor:

      image

      For this I found Shape::GetTrianglesNext(), which is a pretty cool function and I just gave it a huge AABB to retrieve everything. Still, I need to create a dummy shape for this, and I get the data in chunks. For the convex hull and triangle meshes, IF the data is somehow available as a vertex list and triangle index list, it would be nice to get direct access to that.

    4. Material pointers are set on the *Settings object and not on the *Shape object, as far as I can see. That makes sharing the same shape (usually convex hull) across different bodies with different materials difficult. E.g. when I create my "ice" boulder and my "rock" boulder, they can't use the same convex hull mesh, because the PhysicsMaterial can't be different, unless I somehow find another way to retrieve material parameters, but then the whole material idea would be pointless.

    5. Shape::Stats gives me the number of triangles in a shape, but not the number of (shared) vertices. If that information is available, would be nice to have.

    6. MeshShapeSettings takes vertices as FLOAT3 (VertexList), ConvexHullShapeSettings as Vec3 (which are actually __m128 and thus need different treatment).

    Okay...that's all I got about that topic for the moment :)

    opened by jankrassnigg 15
  • Serialize whole PhysicsSystem + shapes + constraints?

    Serialize whole PhysicsSystem + shapes + constraints?

    Hello!

    I was interested in being able to dump the game's physics system and add a loader to the Samples to be able to play around with it there. It's also useful for viewing in the viewer.

    Same goes for being able to report some issues with constraint stability in some instances, I wanted to dump my phys env so I could easily demonstrate how it's stable to start, then after playing around with it enough it will go crazy and fly all over. (There's lots of constrained convex objects interacting.)

    There's a few paths I have tried for doing something like this, one was calling SaveState on PhysicsEnvironment, this doesn't seem to save the shapes that I can tell.

    The other path is using the PhysicsScene, but this suffers from not replicating constraints as I have to convert it to use the the BodyCreationInfo.

    Am I missing something?

    opened by Joshua-Ashton 13
  • Bodies can still go through other bodies with linear cast if velocity is applied before every simulation

    Bodies can still go through other bodies with linear cast if velocity is applied before every simulation

    Not super sure what's going on here.

    If I have a body and set it's velocity before every simulation, eventually it goes through the world.

    I'm using LinearCast, but have also tried increasing substeps to 4 + setting the LinearCastThreshold to 0.

    opened by Joshua-Ashton 10
  • Add SSE2 codepath

    Add SSE2 codepath

    Add an SSE2 codepath to Jolt by providing a C++ implementation for all functions that use SSE4.1 instructions. This enables Jolt to run on all x64 processors.

    The SSE2 codepath is ~10% slower than the SSE4.2 codepath on average in the PerformanceTest tests.

    opened by jfpoole 10
  • Locking two bodies at the same time (joint setup)

    Locking two bodies at the same time (joint setup)

    I am trying to create a joint between two bodies.

    ConstraintSettings::Create expects two writable body references. I only have body IDs, so I'm trying to use two BodyLockWrite to lock both bodies and then create the joint. However, an assert fires, telling me that another write lock has already been taken.

    In the samples I couldn't find anything similar, there the joints are always created in the same code that also creates the bodies, so it just holds pointers to those around for the needed duration.

    What's the recommended way to do this?

    opened by jankrassnigg 8
  • Support broader range of CPUs like Intel Core 2 series by using SSE4.1

    Support broader range of CPUs like Intel Core 2 series by using SSE4.1

    Because popcnt is the only instruction from SSE4.2 that used in project, I add a software implementation for it and add cmake options for more flexible builds. All options are ON now and project builds like before. If all options set to OFF then project will be compatible with SSE4.1. I only test it with Clang. I couldn't test it with Visual Studio so I didn't implement cmake options for it.

    Resources related to popcount implementation: https://stackoverflow.com/questions/109023/how-to-count-the-number-of-set-bits-in-a-32-bit-integer https://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetParallel https://godbolt.org/z/qGdh1dvKK

    Tests Results: SSE4.1:

    Running scene: ConvexVsMesh
    Motion Quality, Thread Count, Steps / Second, Hash
    Discrete, 1, 243.629, 5716752184027160728
    Discrete, 2, 422.97, 5716752184027160728
    Discrete, 3, 582.053, 5716752184027160728
    Discrete, 4, 714.728, 5716752184027160728
    Discrete, 5, 791.58, 5716752184027160728
    Discrete, 6, 858.247, 5716752184027160728
    Discrete, 7, 920.468, 5716752184027160728
    Discrete, 8, 950.534, 5716752184027160728
    LinearCast, 1, 247.095, 4650164293306922608
    LinearCast, 2, 427.573, 4650164293306922608
    LinearCast, 3, 577.239, 4650164293306922608
    LinearCast, 4, 665.414, 4650164293306922608
    LinearCast, 5, 793.486, 4650164293306922608
    LinearCast, 6, 858.8, 4650164293306922608
    LinearCast, 7, 922.867, 4650164293306922608
    LinearCast, 8, 967.974, 4650164293306922608
    

    SSE4.2(popcnt):

    Running scene: ConvexVsMesh
    Motion Quality, Thread Count, Steps / Second, Hash
    Discrete, 1, 245.164, 5716752184027160728
    Discrete, 2, 432.407, 5716752184027160728
    Discrete, 3, 588.171, 5716752184027160728
    Discrete, 4, 669.855, 5716752184027160728
    Discrete, 5, 816.022, 5716752184027160728
    Discrete, 6, 888.699, 5716752184027160728
    Discrete, 7, 925.805, 5716752184027160728
    Discrete, 8, 990.85, 5716752184027160728
    LinearCast, 1, 250.708, 4650164293306922608
    LinearCast, 2, 432.997, 4650164293306922608
    LinearCast, 3, 591.494, 4650164293306922608
    LinearCast, 4, 666.552, 4650164293306922608
    LinearCast, 5, 810.698, 4650164293306922608
    LinearCast, 6, 874.057, 4650164293306922608
    LinearCast, 7, 944.47, 4650164293306922608
    LinearCast, 8, 998.861, 4650164293306922608
    

    All options ON:

    Running scene: ConvexVsMesh
    Motion Quality, Thread Count, Steps / Second, Hash
    Discrete, 1, 259.555, 17307524469906541054
    Discrete, 2, 451.237, 17307524469906541054
    Discrete, 3, 602.937, 17307524469906541054
    Discrete, 4, 692.069, 17307524469906541054
    Discrete, 5, 791.086, 17307524469906541054
    Discrete, 6, 922.998, 17307524469906541054
    Discrete, 7, 970.262, 17307524469906541054
    Discrete, 8, 1039.1, 17307524469906541054
    LinearCast, 1, 259.9, 14934805612666754675
    LinearCast, 2, 437.229, 14934805612666754675
    LinearCast, 3, 609.016, 14934805612666754675
    LinearCast, 4, 710.129, 14934805612666754675
    LinearCast, 5, 838.243, 14934805612666754675
    LinearCast, 6, 900.946, 14934805612666754675
    LinearCast, 7, 982.597, 14934805612666754675
    LinearCast, 8, 1025.07, 14934805612666754675
    
    opened by mrezai 7
  • Constraints should have a flag whether to ignore collisions between joined objects

    Constraints should have a flag whether to ignore collisions between joined objects

    AFAIK all other physics engines by default ignore collisions between joined objects. This is quite sensible, since the abstract physics shapes would otherwise often collide with each other, or it's quite difficult to setup physics shapes that don't touch while joined. For ragdolls this is particularly tricky.

    I know that it may be possible to use the collision group filters to do this, but I haven't figured out yet how I would set things up such that two joined bones don't collide, but otherwise collide with the rest. I also can't imagine, that it is particularly efficient to use these filters everywhere.

    If there is an easy way to set this up, I'd be interested to know. But I would still just prefer a flag on the constraints to disable collisions.

    opened by jankrassnigg 7
  • Alignment issue during LockFreeHashMap.Find

    Alignment issue during LockFreeHashMap.Find

    I traced the issue to the dereference from the reinterpret_cast here which assumes 8 byte alignment but was actually 4 byte aligned. Currently my fix is to compare the mBodyA and mBodyB separately. https://github.com/jrouwe/JoltPhysics/blob/564526ad3d426ab8428534d7c9666082e13577d0/Jolt/Physics/Body/BodyPair.h#L21

    opened by fubark 0
  • Constraints can sometimes go whacky mode

    Constraints can sometimes go whacky mode

    Sometimes having a system of fixed constraints can go crazy and fly all over if you prod them enough.

    I have attached a repro case

    Before:

    image

    After:

    image

    I had to change the LoadSnapshotTest to account for my object layers:

    	Ref<PhysicsScene> scene = result.Get();
    	for (BodyCreationSettings &settings : scene->GetBodies())
    	{
    		if (settings.mObjectLayer == 0 || settings.mObjectLayer == 1)
    			settings.mObjectLayer = Layers::NON_MOVING;
    		else
    			settings.mObjectLayer = Layers::MOVING;
    	}
    
    	result.Get()->CreateBodies(mPhysicsSystem);
    

    It's also marginally annoying that mUp points the wrong way too, but not the end of the world.

    snapshot.zip

    opened by Joshua-Ashton 13
  • MeshShape integration issues / data ingress

    MeshShape integration issues / data ingress

    I'm trying to integrate mesh shapes into an existing code base and I ran into performance regressions with MeshShape, and I had a few thoughts about the interface.

    Right now you fill a MeshShapeSettings, which has std::vector<>s for vertices and indices, and pass that to the MeshShape constructor. Bullet, on the other hand, provides an interface through which the caller can expose read-only views into vertex and index data, which is a much better interface: https://github.com/bulletphysics/bullet3/blob/master/src/BulletCollision/CollisionShapes/btStridingMeshInterface.h#L53

    • With MeshShape, I need to create, fill, and destroy STL containers, even though I might have the data right here in memory from a decompressed file on disk usually
    • Bullet lets me specify vertex stride, supporting packed formats and alignment padding
    • Bullet allows u16 and u32 indices, while MeshShapeSettings use the latter, so small meshes (and custom collision meshes) which are the majority need a processing step. Bullet handles existing index format via PHY_* types.
    • Bullet supports multi-part meshes which are common in some scenarios esp in editor

    What's a good path to enable MeshShape to directly access existing data and avoid copies / etc?

    opened by sherief 6
  • Double-precision support?

    Double-precision support?

    Does Jolt supports double-precision? I tried Godot Engine physics and it does support it, I was able to simulate physics normally while 1000Km away from the origin. However, my use case involves creating a lot of mesh colliders at runtime and I'm a concerned about several performance issues with Godot's physics engine, so I was considering giving Jolt a go at some point.

    opened by Zylann 9
  • Broadphase and ObjectLayer filters are missing context

    Broadphase and ObjectLayer filters are missing context

    I'm currently looking into how to implement collision filtering.

    So far I have found these filtering options:

    • in the broadphase via ObjectVsBroadPhaseLayerFilter
    • pair-wise via 16 bit "layer" information through ObjectLayerPairFilter
    • pair-wise via 32 bit "group IDs" and CollisionGroup / GroupFilter

    I'm trying to figure out which of these I should use for what. I assume I should use the broadphase filter to separate static/dynamic objects and maybe stuff like "query shapes" (kinematic bodies that are only used for raycasts but not for simulation - e.g. for character hit boxes). Anything else that makes sense to separate in the broadphase? Triggers maybe?

    I guess the GroupFilter is the most flexible, but also the slowest one. Not sure exactly when this is really needed, maybe for very special cases like the player object ?

    I would like to use the object layer filter to do a quick bitmask check to see whether layer1 objects should collide with layer2 objects. However, the 16 bit layer value is not sufficient for this, so I would need to look up the collision matrix somewhere else.

    Unfortunately PhysicsSystem::Init only takes a raw C function pointer for ObjectVsBroadPhaseLayerFilter and ObjectLayerPairFilter, which means all collision filtering information would need to be hard-coded in those functions (or global).

    Interestingly, NarrowPhaseQuery::CastRay already does a similar thing, but that one takes BroadPhaseLayerFilter and ObjectLayerFilter as interfaces, so that I can pass along context information.

    It would be great if PhysicsSystem::Init would also take interfaces instead.

    opened by jankrassnigg 2
Releases(v1.1.0)
Canny edge detection, one of the efficient edge detection algorithms is implemented on a Zedboard FPGA using verilog

In this project, Canny edge detection, one of the efficient edge detection algorithms is implemented on a Zedboard FPGA using verilog. The input image is stored on a PC and fed to the FPGA. The output processed image is displayed on a VGA monitor.

Jeffrey Samuel 2 May 9, 2022
Multi-Joint dynamics with Contact. A general purpose physics simulator.

Multi-Joint dynamics with Contact. A general purpose physics simulator.

DeepMind 4.5k Jun 28, 2022
Full-body tracking in VR using AprilTag markers.

Full-body tracking in VR using AprilTag markers.

null 728 Jun 26, 2022
graphics and computational physics framework

atto Graphics and computational physics research framework: aligned memory allocation, string manipulation, file IO, etc. 2-, 3- and 4-dimensional vec

Carlos Correia 1 Oct 25, 2021
A 2D Physics Engine written in C++, supporting circles and orientable, non-regular convex polygons.

PhysicsEngine A basic physics engine supporting circles and orientable non-regular convex polygons. Oh, and it has undamped springs and strings. Demo

ThePythonator 3 Mar 19, 2022
Phyxed is a 2D physics engine with support for fixed point math.

Phyxed is a 2D physics engine with support for fixed point math.

Anders Elfgren 23 Jan 18, 2022
Real-Time SLAM for Monocular, Stereo and RGB-D Cameras, with Loop Detection and Relocalization Capabilities

Real-Time SLAM for Monocular, Stereo and RGB-D Cameras, with Loop Detection and Relocalization Capabilities

Raul Mur-Artal 7.3k Jun 29, 2022
FFVideo - an example FFmpeg lib, and wxWidgets Player with video filters and face detection

An example FFmpeg lib, and wxWidgets Player application with video filters and face detection, it is a no-audio video player intended for video experiments and developers learning how to code media applications.

Blake Senftner 20 Mar 26, 2022
Sketch-Based Streaming Anomaly Detection in Dynamic Graphs

AnoGraph Implementation of Sketch-Based Streaming Anomaly Detection in Dynamic Graphs. Siddharth Bhatia, Mohit Wadhwa, Philip S. Yu, Bryan Hooi Existi

Stream-AD 51 May 10, 2022
A C math library targeted at games

Kazmath Kazmath is a simple 3D maths library written in C. It was initially coded for use in my book, Beginning OpenGL Game Programming - Second editi

Luke Benstead 502 May 25, 2022
StereoKit is an easy-to-use open source mixed reality library for building HoloLens and VR applications with C# and OpenXR!

StereoKit is an easy-to-use open source mixed reality library for building HoloLens and VR applications with C# and OpenXR! Inspired by libraries like XNA and Processing, StereoKit is meant to be fun to use and easy to develop with, yet still quite capable of creating professional and business ready software.

Nick Klingensmith 410 Jun 24, 2022
A minimalist library with basic facilities for developing interactive real-time 3D applications, with a strong emphasis on simplicity and ease of use.

SlimEngine A minimalist and platform-agnostic base project for interactive graphical applications (2D/3D) with a strong emphasis on simplicity, ease o

Arnon Marcus 66 May 10, 2022
Modern C++14 library for the development of real-time graphical applications

CI Community Support bs::framework is a C++ library that aims to provide a unified foundation for the development of real-time graphical applications,

null 1.7k Jun 29, 2022
SPIRV-Reflect is a lightweight library that provides a C/C++ reflection API for SPIR-V shader bytecode in Vulkan applications.

SPIRV-Reflect SPIRV-Reflect is a lightweight library that provides a C/C++ reflection API for SPIR-V shader bytecode in Vulkan applications. SPIRV-Ref

The Khronos Group 407 Jun 18, 2022
A multi-platform library for OpenGL, OpenGL ES, Vulkan, window and input

GLFW Introduction GLFW is an Open Source, multi-platform library for OpenGL, OpenGL ES and Vulkan application development. It provides a simple, platf

GLFW 9.2k Jun 24, 2022
Lightweight and modular C++11 graphics middleware for games and data visualization

Magnum — Lightweight and modular C++11/C++14 graphics middleware for games and data visualization Looking for an open-source library that gives you gr

Vladimír Vondruš 4.1k Jul 3, 2022
Metal-cpp is a low-overhead C++ interface for Metal that helps developers add Metal functionality to graphics apps, games, and game engines that are written in C++.

About metal-cpp is a low overhead and header only C++ interface for Metal that helps developers add Metal functionality to graphics applications that

Бранимир Караџић 138 Jun 27, 2022
Four little games made in C / C++ (CSFML / SFML)

Graphical projects Name Language Grade Year My hunter C / CSFML B 2017 My runner C / CSFML B 2017 My world C / CSFML B 2018 My rpg C / CSFML A 2018 Re

Luis Rosario 11 Mar 30, 2021
Open-source, cross-platform, C++ game engine for creating 2D/3D games.

GamePlay v3.0.0 GamePlay is an open-source, cross-platform, C++ game framework/engine for creating 2D/3D mobile and desktop games. Website Wiki API De

gameplay3d 3.7k Jul 3, 2022