Yocto/GL: Tiny C++ Libraries for Data-Driven Physically-based Graphics


Yocto/GL: Tiny C++ Libraries for Data-Oriented Physically-based Graphics

windows build badge macos build badge ubuntu build badge

Yocto/GL is a collection of small C++17 libraries for building physically-based graphics algorithms released under the MIT license. Yocto/GL is written in a deliberately data-oriented style for ease of development and use. Yocto/GL is split into small libraries to make code navigation easier. See each header file for documentation.

  • yocto/yocto_math.{h}: fixed-size vectors, matrices, rigid frames, rays, bounding boxes, transforms
  • yocto/yocto_color.{h}: color conversion, color adjustment, tone mapping functions, Perlin noise, shading and integration utilities
  • yocto/yocto_geometry.{h}: geometry functions, ray-primitive intersection, point-primitive overlap
  • yocto/yocto_noise.{h}: Perlin noise
  • yocto/yocto_sampling.{h}: random number generation, generation of points and directions, Monte Carlo utilities
  • yocto/yocto_shading.{h}: evaluation and sampling of fresnel functions, bsdf lobes, transmittance lobes, phase functions
  • yocto/yocto_shape.{h,cpp}: various utilities for manipulating triangle meshes, quads meshes and line sets, computation of normals and tangents, linear and Catmull-Clark subdivision, mesh loading and saving, procedural shapes generation, ray intersection and closest point queries
  • yocto/yocto_mesh.{h,cpp}: computational geometry utilities for triangle meshes, mesh geodesic, mesh cutting, mesh loading and saving
  • yocto/yocto_bvh.{h,cpp}: ray intersection and closest point queries of triangle meshes, quads meshes, line sets and instances scenes using a two-level bounding volume hierarchy
  • yocto/yocto_image.{h,cpp}: simple image data type, image resizing, tone mapping, color correction, image loading and saving, procedural images, procedural sun-sky, advanced color conversion utilities
  • yocto/yocto_sceneio.{h,cpp}: simple scene and scene loading and saving of Ply/Obj/Pbrt/glTF and a custom and scalable Json format
  • yocto/yocto_trace.{h,cpp}: path tracing of surfaces and hairs supporting area and environment illumination, microfacet GGX and subsurface scattering, multiple importance sampling
  • yocto/yocto_modelio.{h,cpp}: parsing and writing for Ply/Obj/Pbrt formats
  • yocto/yocto_commonio.h: printing utilities, file io utilities, command line parsing
  • yocto/yocto_json.h: JSON data type, json io utilities, command line parsing
  • yocto/yocto_common.h: container and iterator utilities
  • yocto/yocto_parallel.h: concurrency utilities

You can see Yocto/GL in action in the following applications written to test the library:

  • apps/yscenetrace.cpp: command-line path-tracer
  • apps/ysceneitrace.cpp: interactive path-tracer
  • apps/ysceneitraces.cpp: simpler version of apps/ysceneitrace.cpp for demos
  • apps/ysceneproc.cpp: command-line scene manipulation and conversion
  • apps/yshapeproc.cpp: command-line mesh manipulation and conversion
  • apps/yimageview.cpp: Hdr/Ldr image viewer with tonemapping and color grading
  • apps/yimageviews.cpp: simpler version of apps/yimageview.cpp for demos
  • apps/yimageproc.cpp: command-line image manipulation
  • apps/yimagedenoise.cpp: command-line image denoiser that uses Intel Open Image Denoise
  • apps/ysceneview.cpp: simple OpenGL viewer

Here are some test images rendered with the path tracer. More images are included in the project site.

Example materials: matte, plastic, metal, glass, subsurface, normal mapping

Example shapes: procedural shapes, Catmull-Clark subdivision, hairs, displacement mapping

Image rendered with Yocto/GL path tracer. Model by Disney Animation Studios.

Design Considerations

Yocto/GL follows a "data-oriented programming model" that makes data explicit. Data is stored in simple structs and accessed with free functions or directly. All data is public, so we make no attempt at encapsulation. Most objects is Yocto/GL have value semantic, while large data structures use reference semnatic with strict ownership. This means that everything can be trivially serialized and there is no need for memory management.

We do this since this makes Yocto/GL easier to extend and quicker to learn, with a more explicit data flow that is easier when writing parallel code. Since Yocto/GL is mainly used for research and teaching, explicit data is both more hackable and easier to understand.

In terms of code style we prefer a functional approach rather than an object oriented one, favoring free functions to class methods. All functions and data are defined in sibling namespaces contained in the yocto namespace so libraries can call all others, but have to do so explicitly.

The use of templates in Yocto was the reason for many refactoring, going from no template to heavy template use. At this point, Yocto uses some templates for readability. In the future, we will increase the use of templates in math code, while keeping many APIs explicitly typed.

We do not use exception for error reporting, but only to report "programmers" errors. For example, IO operations use boolean flags and error strings for human readable errors, while exceptions are used when preconditions or post conditions are violated in functions.

The current version of the library (2.x) is a major refactoring of the previous library versions (1.x) in three main aspects. First, we now allow the use of reference semantic via pointers and adopt it for all large objects, while keeping value semantic for all others. We did this to avoid erroneous copies that cannot detected and avoided at compile time. Second, we had trouble interacting with C libraries that mostly use reference semantic. Third, we reduce the use of exceptions, again for better integration with external code.


Main contributors:

This library includes code from the PCG random number generator, boost hash_combine, and public domain code from github.com/sgorsten/linalg, gist.github.com/badboy/6267743 and github.com/nothings/stb_perlin.h. Other external libraries are included with their own license.


This library requires a C++17 compiler and is know to compiled on OsX (Xcode >= 11), Windows (MSVC 2019) and Linux (gcc >= 9, clang >= 9).

You can build the example applications using CMake with mkdir build; cd build; cmake ..; cmake --build .

Yocto/GL depends on stb_image.h, stb_image_write.h, stb_image_resize.h and tinyexr.h for image loading, saving and resizing, cgltf.h and json.hpp for glTF and JSON support, and filesystem.hpp to support C++17 filesystem API when missing. All dependencies are included in the distribution.

Yocto/GL optionally supports building OpenGL demos, which are handled by including glad, GLFW, ImGui as dependencies in apps. OpenGL support might eventually become part of the Yocto/GL libraries. OpenGL support is enabled by defining the cmake option YOCTO_OPENGL and contained in the yocto_gui library.

Yocto/GL optionally supports the use of Intel's Embree for ray casting. At this point, we rely on prebuilt binaries distributed by Intel. See the main CMake file for how to link to it. Embree support is enabled by defining the cmake option YOCTO_EMBREE.

Yocto/GL optionally supports the use of Intel's Open Image Denoise for denoising renders. At this point, we rely on prebuilt binaries distributed by Intel. See the main CMake file for how to link to it. Open Image Denoise support is enabled by defining the cmake option YOCTO_DENOISE. See apps/yimagedenoise for a demonstration.

  • Version 4 - Design Documents

    Version 4 - Design Documents

    This issue tracks design consideration for the v4 simplification. Instead of keeping separate design documents for each part of the library, we keep everything into one for simplicity.

    version4 design 
    opened by xelatihy 14
  • issues for save image

    issues for save image

    There seem to be two bugs when saving images. The first in apps\ysceneitrace\ysceneitrace.cpp: it should be save_image(app->outname, app->display, app->error); instead of save_image(app->imagename, app->display, app->error); for "save image" The second in libs/yocto_gui/yocto_imgui.cpp: It should be:

    if (ImGui::Button("Ok")) {
          path = state.dirname + "/" + state.filename;

    because the dirname does not contain the "/"

    opened by kopaka1822 9
  • Compilation error with gcc 8.2.0

    Compilation error with gcc 8.2.0

    I get those errors when I try to compile the code at current version (e155ccb2)

    Tried with: gcc (Ubuntu 8.2.0-7ubuntu1) 8.2.0

    /home/guillaume/src/yocto-gl/yocto/yocto_bvh.cpp: In lambda function:
    /home/guillaume/src/yocto-gl/yocto/yocto_bvh.cpp:1487:69: error: call of overloaded ‘affine(yocto::frame3f&)’ is ambiguous
                                              inverse((affine3f)instance.frame), ray)
    In file included from /home/guillaume/src/yocto-gl/yocto/yocto_bvh.h:91,
                     from /home/guillaume/src/yocto-gl/yocto/yocto_bvh.cpp:29:
    /home/guillaume/src/yocto-gl/yocto/yocto_math.h:1289:24: note: candidate: ‘constexpr yocto::affine<T, 3>::affine(const yocto::mat<T, 4, 4>&) [with T = float]’
         constexpr explicit affine(const mat<T, 4, 4>& m)
    /home/guillaume/src/yocto-gl/yocto/yocto_math.h:1271:8: note: candidate: ‘constexpr yocto::affine<float, 3>::affine(const yocto::affine<float, 3>&)’
     struct affine<T, 3> {
    /home/guillaume/src/yocto-gl/yocto/yocto_math.h:1271:8: note: candidate: ‘constexpr yocto::affine<float, 3>::affine(yocto::affine<float, 3>&&)’
    opened by guillaumechereau 8
  • Crash in sample_environment_direction_pdf

    Crash in sample_environment_direction_pdf

    The rendering thread sometimes crashes in the function sample_environment_direction_pdf.

    It seems to happen when the texcoord variable gets a y value of exactly 1.0, in that case the idx overflows the elements_cdf size.

    bug next release 
    opened by guillaumechereau 8
  • yocto_cutrace compile errors

    yocto_cutrace compile errors

    Cool project!

    I am getting a lot of compile errors in yocto_cutrace. Most are related to vector functions:

    /tmp/yocto-gl/libs/yocto/yocto_cutrace.cu(173): error: no instance of constructor "yocto::vec2f::vec2f" matches the argument list argument types are: (int, int)

    /tmp/yocto-gl/libs/yocto/yocto_cutrace.cu(376): error: namespace "std" has no member "swap"

    I am compiling with gcc 11.1 and CUDA 11.5 on linux.

    opened by ib00 6
  • Split Yocto/Math

    Split Yocto/Math

    This issue track ideas on how to split Yocto/Math. Right now math contains a lot of different functions that are int eh following categories

    • linear algebraic types vec/mat/frame/transforms
    • color manipulation on vec
    • geometry types ray/bbox/intersection/overlap
    • random number generation
    • noise
    • Monte Carlo helpers
    • brdf/phasefunc Monte Carlo helpers

    We probably want to split Math into two or more files. This issue track proposal on how to do this.

    enhancement version3 
    opened by xelatihy 6
  • Error Compiling on VS2017

    Error Compiling on VS2017

    I am getting the following errors when compiling on VS2017:

    Error	C2512	'ym::vec<int,N>': no appropriate default constructor available	yocto	...\yocto-gl\yocto\yocto_gltf.h	1929
    Error	C2039	'tolower': is not a member of 'std'	yocto	...\yocto-gl\yocto\yocto_utils.h	620	
    Error	C2398	Element '1': conversion from 'double' to 'float' requires a narrowing conversion	yocto	....\yocto-gl\yocto\yocto_trace.cpp	1309	

    There are more C2398's at lines 1309 for elements 2 and 3 as well. Ideas?

    opened by dresch86 6
  • Compilation error at std::array initialization

    Compilation error at std::array initialization

    gcc 5.4 does not accept a = {} initialization for std::array. (and clang will report it as warning when increasing warning level(e.g. -Wall))

    $ g++ -std=c++11 yocto_gltf.h
    yocto_gltf.h:615:55: error: array must be initialized with a brace-enclosed initializer
         std::array<float, 4> baseColorFactor = {1, 1, 1, 1};

    More C++11 compliant solution is

    std::array<float, 4> baseColorFactor{{1, 1, 1, 1}}; // OK
    opened by syoyo 6
  • Error with metallic materials ?

    Error with metallic materials ?

    I think there is a bug in the BRDF evaluation of materials with metallic value:

      if (metallic) {
          point.specular = point.specular * (1 - metallic) + metallic * point.diffuse;
          point.diffuse  = metallic * point.diffuse * (1 - metallic);

    The multiplication by metallic in point.diffuse computation seems wrong: a material with a very little metallic factor value will have a diffuse value close to zero, while I would expect the opposite. Or am I wrong?

    opened by guillaumechereau 5
  • Adaptive Sampling.

    Adaptive Sampling.

    Please, take a look at my implementation of 'Adaptive Sampling', using yocto-gl. I do my best to not change too much the original code, just adding a new one. So, the integration may be easy, if you think it is useful.


    enhancement undecided 
    opened by mkanada 4
  • load_text() fails on Windows

    load_text() fails on Windows

    Thanks for making such a great looking project available!

    I've compiled the latest github version of yocto-gl on Windows 10 using Microsoft Visual Studio Community 2019 Version 16.5.0 and am unable to load any of the json test scenes because of a failure in load_text() on line 949 in yocto_sceneio.cpp

    if (fread(str.data(), 1, length, fs) != length) return read_error();

    opened by Hurleyworks 4
  • API improvements

    API improvements

    This issue tracks changes to the API:

    • [ ] names for trace
      • [ ] render?
      • [ ] cutrace and trace naming
    • [x] names for BVH
      • [x] use only one data structure?
      • [x] uniform bvh and cutrace?
    • [ ] use of span and imspan?
    opened by xelatihy 0
  • Core Improvements

    Core Improvements

    This issue tracks implementation to core libraries:

    • [ ] pass math types by value
    • [ ] consider removing operator [] from vecs and use at() free function instead, at least in shared code
    • [ ] consider using frame_fromz instead of basis_fromz whener possible
    • [ ] shape functions take a frame
    • [ ] implement out own async function to ensure all operating systems run the same code
    opened by xelatihy 0
  • Trace Improvements

    Trace Improvements

    This issue tracks improvements to trace

    • [ ] port to Metal path tracer
    • [ ] consider making more functions public
    • [ ] eyelight should only do diffuse
    • [ ] camlight should do diffuse + specular
    • [ ] consider thick primitives (points as spheres, lines as capsule)
    opened by xelatihy 0
  • IO Improvements

    IO Improvements

    This issue tracks changes to input/output functions for easier implementation.

    • [ ] move io to yocto_io.xxx
    • [ ] implement ply directly in pbrt
    • [ ] implement ply and obj output directly in shapes
    • [ ] consider implementing ply and obj input directly in shapes
    • [ ] consider removing fast_float dependency
    • [ ] Remove support for Obj extensions
    opened by xelatihy 0
  • v4.4.0(Dec 28, 2022)

    This release adds an experimental CUDA path tracer and refactors some internal data structures to better match the library goals, together with including many bug fixes.

    This release will be the last in the 4.x line. This upcoming release will introduce many code breaking changes that are necessary to further expand the library. Differently than what was done solar, the next release will be backward incompatible and deprecated methods will be removed.

    What's Changed

    • Cuda/Optix renderer (#1339, #1340, #1341, #1343, #1344, #1345, #1347, #1349, #1350, #1360, #1363)
    • Simpler example apps (#1352, #1365, #1367)
    • Split IO sources (#1321, $1323, #1359, #1378, #1381)
    • Split Embree Bvh from Yocto/Bvh (#1324)
    • Function renaming (#1325, #1382)
    • Yocto/Math simplification (#1333, #1338, #1368, #1326)
    • Better CLI (#1319)
    • Fix OpenGL color space (#1383)
    • Bug fixes and build (#1304, #1316, #1317, #1318, #1330, #1335, #1398, #1409)
    Source code(tar.gz)
    Source code(zip)
  • v4.3.0(Oct 20, 2021)

    This release is mostly a big fix release and introduces a new file format for the scene that is easier than the previous. All previous files will still load.

    What's Changed

    • Added Python scene validator
    • Moldeio does not use math
    • Merge gui in yocto
    • Deprecate Yocto/Parallel
    • Remove less used external libs
    • Remove Json implementations
    • Simpler BVH implementation
    • Shorter CLI implementation
    Source code(tar.gz)
    Source code(zip)
  • v4.2.0(Sep 7, 2021)

    This release is mostly a refactoring of the IO functionality, to make it simpler, and the introduction of a simpler Json format. All changes should be backward compatible, beside the removal of exceptions from the APIs.

    • Updated docs (#1280)
    • Removing all IO exceptions (#1278)
    • Remove exceptions from CLI (#1277)
    • Remove exception from IO implementation (#1276)
    • Merge IO functionality in Yocto/SceneIO. (#1275)
    • Remove PFM support (#1274)
    • Switch JSON implementation (#1273)
    • Simpler Json Format (#1272)
    Source code(tar.gz)
    Source code(zip)
  • v4.1.0(Aug 9, 2021)

    This release improves mostly upon utilities and IO functionality in preparation for a 5.0 release with more graphics features. The release should be mostly backward compliant besides one change listed below.

    • Backward incompatible change: Rename metallic to reflective in material_type enum (#1266)
    • Better code layout: IO functionality split into image io, shape io, and scene io (#1258)
    • Microfacet bug fixes (#1264)
    • Furnace test (#1259)
    • Bug fixes (#1256, #1252, #1250, and smaller commits)
    • Update docs (#1268)
    • Update ImGui and STB dependencies. (#1267)
    • Cleanup to possibly support better point and line intersection (#1257)
    • UI keys consistent with Blender (#1255)
    • Faster and simpler IO (#1253, #1251, #1246)
    • File format 4.1, with full backward compatibility. (#1248, #1249)
    • Simpler apps (#1247)
    • Json representation (#1244, #1245, #1243, #1239, #1223)
    • Tone mapping, batch rendering, and denoising in CLI scene rendering (#1242, #1230)
    • Better names for scene elements: camera_data, texture_data, etc, with old names supported via typedefs. (#1240)
    • Eyelight rendering with ambient occlusion (#1221)
    Source code(tar.gz)
    Source code(zip)
  • v4.0.0(Mar 25, 2021)

    This marks a major new release of Yocto/GL which is not backward compatible with the previous release. Major changes were introduced to reduce the amount of code, as well as simplify library usage. Please see the docs for an overview of the release.

    Source code(tar.gz)
    Source code(zip)
  • v3.3.0(Dec 31, 2020)

    This release marks the last release of the v3 line. It contains a few additions, mostly related to support libraries, as well as more example apps. Starting from the next commit, incompatible changes will land in the main branch to begin working on the v4 line. The list of changes are:

    • implemented command line apps with commands to reduce the number of demo apps (#1135, #1132, #1124, #1122, #1121)
    • added a simple image viewer as a library component (#1134, #1133, #1123)
    • added support for Json storage and IO in the new library Yocto/Json (#1131, #1130, #1129, #1128, #1127, #1126, #1116, #1112, #1111, #1110, #1109, #1108, #1107, #1105, #1102, #1098, #1102)
    • mesh processing utilities (#1103, #1097, #1094, #1093, #1084, #1103, #1097)
    • added STL and glTF IO (#1125, #1113, #1092, #1091)
    • command-line parsing with JSON schemas (#1120, #1119, #1083)
    • bug fixes (#1096, #1089)
    • example sculpting app (#1087)
    • city generation example (#1082)
    Source code(tar.gz)
    Source code(zip)
  • v3.2.0(Sep 14, 2020)

    This release is mostly a bug fix and cleanup release with some improvements made to the interactive renderers. This release marks the last release in the 3.X line. This is a list of the major changes.

    • Image
      • Simplified image IO and textures in scene (#1022, #1023, #1048, #1071)
      • Image support for width() and height() (#1028)
    • Path tracing
      • Define trace scene (#1025, #1024)
      • External bvh in trace (#1067, #1068, #1069, #1070)
      • Lights outside the scene for path tracing (#1065, #1066)
    • SceneIO
      • Removal of scene creation APIs (#1076, #1031)
      • Removed references from modelio (#1072)
    • Cli
      • Simpler cli implementation (#1037, #1038, #1015, #1014, #1026)
    • General
      • Move rays and bounding boxes to Yocto/Geometry (#1073)
      • Documentation update
      • Bug fix (#1027)
      • Applying linter fixes and general cleanup (#1043, #1042, #1044, #1046, #1039, #1030, #1029, #1020, #1017, #1036, #1042)
      • Update library versions (#1033)
      • Common utils are shared between files (#1019, #1021)
    • Gui
      • Glfw compiled as external library (#1078)
      • Image-based-lighting for real-time viewers (#1034, #1051, #1053, #1035, #1040, #1050, #1045, #1046, #1047, #1050, #1053, #1054, #1056, #1057, #1058, #1059, #1060, #1061, #1062)
    Source code(tar.gz)
    Source code(zip)
  • v3.1.0(Aug 15, 2020)

    This release contains several bug fixes and also a change in the build to use std::filesystem. Summary if changes:

    • Using std::filesystem instead of ghc::filesystem (#1008, #1011)
      • This may require a later compiler than before, but brings stability especially on Windows
    • Improvements to yocto_gui
      • Split yocto_gui into two libraries (#1012)
      • Update yocto_gui for better rendering support (#1009)
      • Removed unused ImGui helpers (#1007)
      • Simple mesh viewer with thick points and lines (#1006)
      • Bugfix in gui dialog (#1013)
    • Generate tests internally (#1004)
    • More general command-line parser (#1000)
    • Removed Git Submodules
    • Applying cpplint (#999)
    • Buig fixes (#1005, #1003, #1002, #998)
    Source code(tar.gz)
    Source code(zip)
  • v3.0.0(Jul 3, 2020)

    This release makes a few major changes in the Yocto/GL repository from feedback gained by others.

    • Functionality is split into multiple libraries to make it easier to extend Yocto in the future and make code navigation easier
    • Significantly better documentation that move from the header files to Markdown compiled with mkdocs
    • A shared, and simplified scene, scene model for both IO and path tracing
    • Bug fixes throughout most of the library
    • Addition of new facilities in an experimental form
    Source code(tar.gz)
    Source code(zip)
  • v2.0.0(Mar 9, 2020)

    This is a major update for Yocto/GL that incorporates changes for both significant efficiency and usability of the APIs when including Yocto/GL libraries in external projects. Some of the main changes are listed here.

    • added separate namespaces to all libraries
    • remove Yocto/Bvh library that is now merged into Yocto/Shape
    • split Yocto/ModelIO into separate Yocto/Ply, Yocto/Obj, Yocto/Pbrt for more modularity
      • remove support for YAML parsing since it was hard to maintain
      • use of pointers for references instead of indices for efficiency, pointer-stability and type safety of references
    • changes to scene representation in Yocto/SceneIO
      • explicit instancing for efficiency
      • renamed instance to object
      • use of pointers instead of indices to ensure pointer stability and for efficiency
      • use of JSON as the main file format instead of YAML
      • names are not explicit paths any longer, but just filenames without extensions
    • changes to scene representation in Yocto/Trace
      • explicit instancing for efficiency
      • renamed instance to object
    • move more common functionality from other libraries into Yocto/Math
    • several new APIs across all libraries
      • explicit scene element creation
      • pointer-based references
    • code cleanup in all libraries at least in the non-API code
    • change build system and library location to make the code more modular
    Source code(tar.gz)
    Source code(zip)
  • v1.4.0(Feb 27, 2020)

  • v1.3.0(Nov 11, 2019)

  • v1.2.0(Sep 9, 2019)

  • v1.1.0(Sep 8, 2019)

    This release includes two main changes, mostly internal. Low-level scene parsers are moved to the new ModelIO library and include SAX-like parsing without callbacks. The path tracer has been significantly reduce in code length, while maintaining the same behaviour. The material model now has better energy conservation.

    Source code(tar.gz)
    Source code(zip)
  • v1.0.0(Jun 19, 2019)

    First stable release. For a list of features, please consult the readme file.

    Moving forward, we will follow semantic versioning. We plan to have relatively quick releases with new features, and use deprecation for API changes. Experimental APIs might crop up from time to time, and they will be marked as such until stable or removed. We will follow a relatively strict policy for the library, while the example applications will be changed more liberally.

    Source code(tar.gz)
    Source code(zip)
A terminal-based graphics library for both 2D and 3D graphics.

TermGL A terminal-based graphics library for both 2D and 3D graphics. Written in C, created for terminals supporting ANSI escape codes. Table of Conte

null 215 Dec 28, 2022
Vulkan physically based raytracer including denoising

VulkanPBRT Vulkan physically based raytracer including denoising. The GPU raytracer is based on Vulkan only, as well as for the denoising only the Vul

null 18 Nov 25, 2022
SoL (for Speed of Light, or sun in Spanish) is a Physically-based rendering library written in modern C++

SoL (for Speed of Light, or sun in Spanish) is a small rendering library written in C++20. Its goal is to strike a good balance between performance and usability, and allow easy experimentation for rendering researchers.

Arsène Pérard-Gayot 10 May 19, 2022
🌞 A physically based monte carlo path tracer written in C++

Physically Based Path Tracer The below 3D model for the Head of Michelangelo's David bust was taken from this link. Other .obj files taken from The St

Aman Shenoy 45 Dec 27, 2022
A modern C++ physically based renderer

The Dakku Renderer Warning: This project is currently under developing and does not guarantee any consistency. About Dakku is a physically based rende

xehoth 6 Apr 15, 2022
A physically based shader for woven cloth

ThunderLoom A physically based shader for woven cloth This projects consits of three main parts: Irawan shading model At its core is an implementation

null 92 Oct 29, 2022
Source code for pbrt, the renderer described in the third edition of "Physically Based Rendering: From Theory To Implementation", by Matt Pharr, Wenzel Jakob, and Greg Humphreys.

pbrt, Version 3 This repository holds the source code to the version of pbrt that is described in the third edition of Physically Based Rendering: Fro

Matt Pharr 4.4k Jan 7, 2023
appleseed is an open source, physically-based global illumination rendering engine primarily designed for animation and visual effects.

appleseed is an open source, physically-based global illumination rendering engine primarily designed for animation and visual effects.

appleseedhq 2k Jan 8, 2023
Low Level Graphics Library (LLGL) is a thin abstraction layer for the modern graphics APIs OpenGL, Direct3D, Vulkan, and Metal

Low Level Graphics Library (LLGL) Documentation NOTE: This repository receives bug fixes only, but no major updates. Pull requests may still be accept

Lukas Hermanns 1.5k Jan 8, 2023
The tiny C library of 2D computer graphics.

libcg The tiny C library of 2D computer graphics. Getting Started The library's .c and .h files can be dropped into a project and compiled along with

xboot.org 86 Jan 1, 2023
kaun is a replacement for löve's built-in love.graphics module intended for 3D graphics

kaun kaun is a replacement for löve's built-in love.graphics module intended for 3D graphics. It is a Lua module you can require from a shared library

Joel Schumacher 4 Apr 5, 2021
This repo contains the DirectX Graphics samples that demonstrate how to build graphics intensive applications on Windows.

DirectX-Graphics-Samples This repo contains the DirectX 12 Graphics samples that demonstrate how to build graphics intensive applications for Windows

Microsoft 4.9k Dec 26, 2022
A community driven OS by the youth

Welcome Welcome to the mandelbrot Operating System. This OS is built by a humble group of teenagers over at Discord. We do this solely to have fun and

null 206 Dec 16, 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.3k Dec 30, 2022
Matplot++: A C++ Graphics Library for Data Visualization 📊🗾

Matplot++ A C++ Graphics Library for Data Visualization Data visualization can help programmers and scientists identify trends in their data and effic

Alan de Freitas 3k Jan 4, 2023
This is a openGL cube demo program. It was made as a tech demo using PVR_PSP2 Driver layer GPU libraries.

OpenGL Cube Demo using PVR_PSP2 Driver layer GPU libraries This is a openGL cube demo program. It was made as a tech demo using PVR_PSP2 Driver layer

David Cantu 5 Oct 31, 2021
Software RayTracing engine written in C++ without the usage of any libraries.

Software Raytracing Engine This is a software unidirectional raytracing engine, fully written in C++17, with no dependencies or external libraries use

Makar Ivashko 3 Nov 16, 2022
Cross-platform, graphics API agnostic, "Bring Your Own Engine/Framework" style rendering library.

bgfx - Cross-platform rendering library GitHub Discussions Discord Chat What is it? Cross-platform, graphics API agnostic, "Bring Your Own Engine/Fram

Бранимир Караџић 12.6k Jan 8, 2023