Code Monkey home page Code Monkey logo

yocto-gl's Introduction

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

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, transforms
  • yocto/yocto_color.{h}: color conversion, color adjustment, tone mapping functions, color grading, color maps, color spaces
  • yocto/yocto_geometry.{h}: rays, bounding boxes, 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_image.{h,cpp}: simple image data type, image resizing, tonemapping, color correction, procedural images, procedural sun-sky
  • yocto/yocto_shape.{h,cpp}: simple shape data structure, utilities for manipulating triangle meshes, quads meshes and line sets, computation of normals and tangents, linear and Catmull-Clark subdivision, procedural shapes generation, ray intersection and closest point queries
  • yocto/yocto_scene.{h,cpp}: scene representation and properties evaluation
  • 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_trace.{h,cpp}: path tracing of surfaces and hairs supporting area and environment illumination, microfacet GGX and subsurface scattering, multiple importance sampling
  • yocto/yocto_sceneio.{h,cpp}: image, shape and scene serialization
  • yocto/yocto_modelio.{h,cpp}: low-level parsing and writing for Ply, Obj, Stl formats
  • yocto/yocto_pbrtio.{h,cpp}: low-level parsing and writing for Pbrt format
  • yocto/yocto_cli.{h}: printing utilities and command line parsing
  • yocto/yocto_parallel.h: concurrency utilities (deprecated)

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

  • apps/ytonemap.cpp: image conversion and viewing
  • apps/ycolorgrade.cpp: image color grading
  • apps/yconvert.cpp: scene conversion
  • apps/yconverts.cpp: shape conversion
  • apps/ytrace.cpp: offline and interactive scene rendering
  • apps/ycutrace.cpp: offline and interactive scene rendering with CUDA
  • apps/yview.cpp: interactive scene viewing

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. 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.

Nearly all objects in Yocto/GL have value semantic. This means that everything can be trivially copied and serialized and there is no need for memory management. While this has the drawback of potentially introducing spurious copies, it does have the benefit of ensuring that no memory corruption can occur, which turned out was a major issue for novice C++ users, even in a very small library like this one.

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 the yocto namespace so libraries can call each others trivially.

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.

For error handling in IO we either return status object or an interface that uses boolean flags and error strings. Internally exceptions are used when used by external libraries, but otherwise no exception are used. At the moment, exceptions are only used to report "programmer errors", namely when preconditions or post conditions are violated in functions, just lime the standard library does.

License

The library is released under the MIT license. We include various external dependencies in the distribution that each have thir own license, compatible with the chosen one.

Compilation

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 required dependencies are included in the distribution and do not need to be installed separately.

Yocto/GL optionally supports building OpenGL demos. OpenGL support is enabled by defining the cmake option YOCTO_OPENGL. OpenGL dependencies are included in this repo.

Yocto/GL optionally supports the use of Intel's Embree for ray casting. See the main CMake file for how to link to it. Embree support is enabled by defining the cmake option YOCTO_EMBREE. Embree needs to be installed separately.

Yocto/GL optionally supports the use of Intel's Open Image Denoise for denoising. See the main CMake file for how to link to it. Open Image Denoise support is enabled by defining the cmake option YOCTO_DENOISE. OIDN needs to be installed separately.

yocto-gl's People

Contributors

alanjian85 avatar bamless avatar bkaradzic avatar edoardocarra avatar giacomonazzaro avatar guillaumechereau avatar hrehfeld avatar marcoandreozzi avatar mattrudder avatar metgraph avatar podd0 avatar udnaan avatar xelatihy avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

yocto-gl's Issues

ygltf::fl_gltf leaks memory

Hi,

while parsing your code, I found that the structure fl_gltf is bound to leak memory when destroyed because all of it member vectors contain unmanaged pointers.

Expected behaviour: not leak any memory, ever.

While there are a number of ways to solve this, I'd just recommend you turn the pointers into flat variables.

Best regards.

Gitter chat ?

I started using your gltf loading code as it's the best I could find atm.
I noticed the new codegen version in the dev branch.
It's not compiling for me atm (MinGW) but I don't want to bother you with issues as you're busy working on it, so I thought maybe a Gitter chat could be a good place to talk ?
https://gitter.im

Windows with mingw64 crashes immediately becuase GL appears uninitialized.

I got things up and running using mingw64.

yshade and ytestgen was built with these commands:

gcc -std=gnu99 apps/yshade.c  -lglfw3 -lOpenGL32 -lglew32  -o bin/yshade
gcc -std=gnu99 apps/ytestgen.c  -lglfw3 -lOpenGL32 -lglew32  -o bin/ytestgen

As described in the README files, I then generated the tests:

bin/ytestgen.exe tests

Then I run:

./bin/yshade.exe --no-ui -r 480 -o tests/sh02.shade.png tests/sh02.obj

Which crashes at glCreateShader. This can be fixed by calling calling glewInit() first.

Full support for extensions

myown.schema.json.txt

glTFmyextension.schema.json.txt
Hi,
I've tried to add some arbitrary extension to the list of JSON schemas (see the attachments) the ygltfgen is parsing and it looks like the generator does not create a code that can be easily used.
For this schema, it generates the types (struct glTFMyown; struct glTFmyextension;) but these cannot be used in a real gltf package example (see below) because those structs cannot referred from other structures or parsed from 'extensions' member of glTF.

The example contains:

   "extensionsUsed": [
        "myextension"
   ],
   "extensions": {
        "myextension" : {
            "myarray" : [
                {
                    "prop1" : "test",
                    "uri" : "SampleFile.txt"
                }
            ]
        }
    },

Is it possible to improve the generator?
Or am I misunderstanding of glTF extensions?

Segmentation fault

/home/xxx/Gits/yocto-gl/bin/yshade car.gltf
Signal: SIGSEGV (Segmentation fault)

yimview should move to fully asynchronous

yimview is not fully asynchronous yet. The application runs fine now, but if we move it to fully asynchronous we will setup the work for the other apps. This will involve

  • use timestamps to check when to refresh data
  • use empty data to avoid refreshing
  • test asynchronous edits by scheduling updates onto a queue that calls specific edit functions
  • do nothing in main besides parsing command line
    • everything is done in done in a centralized update functions that can start/stop jobs

Question: Can ysr_init_scene be safely called repeatedly?

Sorry for using the issue tracker for a question.

I noticed that ysr_init_scene takes the number of bodies to be simulated, but in my use case I don't know how many will be needed at the time the scene is created. Looking at the code of that function it seems that calling ysr_init_scene repeatedly with a higher nbodies value shouldn't cause an issue, I just wondered if you could tell me whether that was safe or not?

Thanks, and thanks for such an awesomely simple physics library :)

Multiple materials per shape.

Shapes can only contain one material now. This is limiting since we need to split shapes on IO.
The simplest fix is that allow multiple materials in shapes and subdivs.

Ubuntu 16.04 yview segment fault

Thanks for your amazing job!

When I type the command
./ytrace tests/basic_pl/basic_pl.gltf
I get the correct result.

But when I type
../bin/yview ../bin/tests/basic_pl/basic_pl.gltf
I get the error info Segmentation fault (core dumped)

I find the error occur in the yview.cpp line 169
if (!is_program_valid(st->prog)) st->prog = make_stdsurface_program();

My OpenGL version is 3.3, is it caused by OpenGL?

BVH should support empty shapes

Right now the BVH does not support empty shapes, crashing with an exception.
It is debatable what is the proper behavior, but certainly a crash is not good.
The current proposal is to support empty nodes when building the BVH.

[documentation request] GLTF C++ code generator from spec

Hi again,

The README.md states that

yocto_gltf (.h/.cpp) - Khronos glTF loader and writer automatically generated by the spec.

So, I'm just curious to know which tool you are using for this.
Are you using the JSON Schema as base for the code gen?

Best regards.

Support for orthographic projection

Is there a way to generate an image rendered using an orthographic projection?
I think it should be simple to modify yt__eval_camera to support this case, not sure how the API should handle it though.

cmake linking error OS X

I have a linking issue on os x.

To fix it I changed in the yocto folder the CMakeLists.txt from:

if(APPLE)
    include_directories(/usr/local/include)
    link_directories(/usr/local/lib)
    find_library(GLFW_LIBRARY NAMES glfw3 glfw PATHS /usr/local/lib)
endif(APPLE)

to:

if(APPLE)
    include_directories(/usr/local/include)
    link_directories(/usr/local/lib)
    find_library(GLFW_LIBRARY NAMES glfw3 glfw PATHS /usr/local/lib)
    set(FRAMEWORK_COCOA "-framework Cocoa" CACHE STRING "Cocoa framework for OSX")
    set(FRAMEWORK_COREVIDEO "-framework CoreVideo" CACHE STRING "CoreVideo framework for OSX")
    set(FRAMEWORK_IOKIT "-framework IOKit" CACHE STRING "IOKit framework for OSX")
    set(FRAMEWORK_COREFOUNDATION "-framework CoreFoundation" CACHE STRING "CoreFoundation framework for OSX")
    set(GLFW_LIBRARY ${GLFW_LIBRARY} ${FRAMEWORK_COCOA} ${FRAMEWORK_COREVIDEO} ${FRAMEWORK_IOKIT} ${FRAMEWORK_COREFOUNDATION})
 endif(APPLE)

Compilation error in yocto_gltf.cpp

with gcc 5.4 I have this error :

jngl@jngl-G551JM:~/Developpement/libs/yocto-gl/cmake$ make -j4
Scanning dependencies of target yocto
[  4%] Building CXX object CMakeFiles/yocto.dir/home/jngl/Developpement/libs/yocto-gl/yocto/yocto_trace.cpp.o
[  9%] Building CXX object CMakeFiles/yocto.dir/home/jngl/Developpement/libs/yocto-gl/yocto/yocto_cmd.cpp.o
[ 13%] Building CXX object CMakeFiles/yocto.dir/home/jngl/Developpement/libs/yocto-gl/yocto/yocto_obj.cpp.o
[ 18%] Building CXX object CMakeFiles/yocto.dir/home/jngl/Developpement/libs/yocto-gl/yocto/yocto_gltf.cpp.o
/home/jngl/Developpement/libs/yocto-gl/yocto/yocto_gltf.cpp:3166:55: error: no matching member function for call to 'push_back'
            for (auto child : node->children) { stack.push_back({child, xf}); }
                                                ~~~~~~^~~~~~~~~
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/stl_vector.h:913:7: note: candidate function not viable: cannot convert initializer list argument to
      'const value_type' (aka 'const std::tuple<int, std::array<float, 16> >')
      push_back(const value_type& __x)
      ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/stl_vector.h:931:7: note: candidate function not viable: cannot convert initializer list argument to 'value_type'
      (aka 'std::tuple<int, std::array<float, 16> >')
      push_back(value_type&& __x)
      ^
[ 22%] Building CXX object CMakeFiles/yocto.dir/home/jngl/Developpement/libs/yocto-gl/yocto/yocto_sym.cpp.o                                                                                         
1 error generated.
CMakeFiles/yocto.dir/build.make:110 : la recette pour la cible « CMakeFiles/yocto.dir/home/jngl/Developpement/libs/yocto-gl/yocto/yocto_gltf.cpp.o » a échouée
make[2]: *** [CMakeFiles/yocto.dir/home/jngl/Developpement/libs/yocto-gl/yocto/yocto_gltf.cpp.o] Erreur 1
make[2]: *** Attente des tâches non terminées....
CMakeFiles/Makefile2:179 : la recette pour la cible « CMakeFiles/yocto.dir/all » a échouée
make[1]: *** [CMakeFiles/yocto.dir/all] Erreur 2
Makefile:83 : la recette pour la cible « all » a échouée
make: *** [all] Erreur 2

Light source Type

Can yocto-gl support the directional light source?

I am sorry that now I only find the env light, point light and area light.

Weight about path tracing

Maybe the line 6256 of yocto-gl/yocto/yocto_gl.cpp

weight *= eval_brdfcos(pt, wo, bwi) * weight_brdfcos(pt, wo, bwi);

should be changed to

weight *= eval_brdfcos(pt, wo, bwi, bdelta) * weight_brdfcos(pt, wo, bwi, bdelta);

because bwi is sampled with bdelta together.

Build is broken

burito@chairmaker:~/code/$ uname -a
Linux chairmaker 4.15.0-33-generic #36~16.04.1-Ubuntu SMP Wed Aug 15 17:21:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

system: Freshly updated Ubuntu 16.04 LTS

burito@chairmaker:~/code$ git clone [email protected]:xelatihy/yocto-gl
Cloning into 'yocto-gl'...
remote: Counting objects: 6987, done.
remote: Compressing objects: 100% (89/89), done.
remote: Total 6987 (delta 115), reused 131 (delta 85), pack-reused 6813
Receiving objects: 100% (6987/6987), 17.63 MiB | 850.00 KiB/s, done.
Resolving deltas: 100% (5343/5343), done.
Checking connectivity... done.
burito@chairmaker:~/code$ cd yocto-gl/
burito@chairmaker:~/code/yocto-gl$ mkdir build
burito@chairmaker:~/code/yocto-gl$ cd build/
burito@chairmaker:~/code/yocto-gl/build$ cmake ..
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libGL.so  
-- Found GLEW: /usr/include  
-- Configuring done
-- Generating done
-- Build files have been written to: /home/burito/code/yocto-gl/build
burito@chairmaker:~/code/yocto-gl/build$ make
Scanning dependencies of target ygl
[  4%] Building CXX object CMakeFiles/ygl.dir/yocto/ygl.cpp.o
/home/burito/code/yocto-gl/yocto/ygl.cpp: In function ‘std::tuple<std::vector<ygl::vec<float, 3>, std::allocator<ygl::vec<float, 3> > >, std::vector<ygl::vec<float, 3>, std::allocator<ygl::vec<float, 3> > >, std::vector<ygl::vec<float, 2>, std::allocator<ygl::vec<float, 2> > > > ygl::sample_triangles_points(const std::vector<ygl::vec<int, 3> >&, const std::vector<ygl::vec<float, 3> >&, const std::vector<ygl::vec<float, 3> >&, const std::vector<ygl::vec<float, 2> >&, int, int)’:
/home/burito/code/yocto-gl/yocto/ygl.cpp:966:56: error: converting to ‘std::tuple<std::vector<ygl::vec<float, 3>, std::allocator<ygl::vec<float, 3> > >, std::vector<ygl::vec<float, 3>, std::allocator<ygl::vec<float, 3> > >, std::vector<ygl::vec<float, 2>, std::allocator<ygl::vec<float, 2> > > >’ from initializer list would use explicit constructor ‘constexpr std::tuple< <template-parameter-1-1> >::tuple(_UElements&& ...) [with _UElements = {std::vector<ygl::vec<float, 3>, std::allocator<ygl::vec<float, 3> > >&, std::vector<ygl::vec<float, 3>, std::allocator<ygl::vec<float, 3> > >&, std::vector<ygl::vec<float, 2>, std::allocator<ygl::vec<float, 2> > >&}; <template-parameter-2-2> = void; _Elements = {std::vector<ygl::vec<float, 3>, std::allocator<ygl::vec<float, 3> > >, std::vector<ygl::vec<float, 3>, std::allocator<ygl::vec<float, 3> > >, std::vector<ygl::vec<float, 2>, std::allocator<ygl::vec<float, 2> > >}]’
     return {sampled_pos, sampled_norm, sampled_texcoord};
                                                        ^
CMakeFiles/ygl.dir/build.make:62: recipe for target 'CMakeFiles/ygl.dir/yocto/ygl.cpp.o' failed
make[2]: *** [CMakeFiles/ygl.dir/yocto/ygl.cpp.o] Error 1
CMakeFiles/Makefile2:141: recipe for target 'CMakeFiles/ygl.dir/all' failed
make[1]: *** [CMakeFiles/ygl.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

Gcc does not like. 3.8 is pictured here, 5.0 also tested, same result (to the letter).

burito@chairmaker:~/code/yocto-gl/build$ rm -rf * && CC=clang CXX=clang++ cmake .. && make
-- The C compiler identification is Clang 3.8.0
-- The CXX compiler identification is Clang 3.8.0
-- Check for working C compiler: /usr/bin/clang
-- Check for working C compiler: /usr/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/clang++
-- Check for working CXX compiler: /usr/bin/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libGL.so  
-- Found GLEW: /usr/include  
-- Configuring done
-- Generating done
-- Build files have been written to: /home/burito/code/yocto-gl/build
Scanning dependencies of target ygl
[  4%] Building CXX object CMakeFiles/ygl.dir/yocto/ygl.cpp.o
/home/burito/code/yocto-gl/yocto/ygl.cpp:966:12: error: chosen constructor is explicit in copy-initialization
    return {sampled_pos, sampled_norm, sampled_texcoord};
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/tuple:479:19: note: constructor declared here
        constexpr tuple(_UElements&&... __elements)
                  ^
1 error generated.
CMakeFiles/ygl.dir/build.make:62: recipe for target 'CMakeFiles/ygl.dir/yocto/ygl.cpp.o' failed
make[2]: *** [CMakeFiles/ygl.dir/yocto/ygl.cpp.o] Error 1
CMakeFiles/Makefile2:141: recipe for target 'CMakeFiles/ygl.dir/all' failed
make[1]: *** [CMakeFiles/ygl.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

That's what Clang 3.8 had to say. Clang 6 gives the exact same error, again, to the letter.

create directories on save

C/C++ file save APIs do not allow to crate missing directories in a path. We should implement this somehow. The real problem is that this is a std::filesystm issue, but for now std::filesystem is not up to date yet on all platforms, especially OsX.

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

Pre-built binaries?

Why don't you add pre-built binaries for people that just want to try it out without bothering to compile the apps?

Use using directives for std containers

Yocto/GL now uses the standard std:: naming conventions. While this is good, it makes it hard to switch containers when desired, for example to try different container types or stl implementation. Just remove all std:: namespace usage with using directive.

UI application should switch to async behavior.

UI application are now sometimes synchronous and sometimes asynchronous. This cases some idiosyncrasies between versions that we want to eliminate. In rare cases, this also causes crashes.
This will require several changes to be applied that will be split across several issues.

yshader crashes on multiple samples

Config: Windows 10 x64, mingw64 binaries, nvidia drivers

When running ./bin/yshade.exe -r 480 tests/sh02.obj segfaults. When debugging, it resolves to yocto_glu.h:687 and glDrawElements when trying to draw a light object whose etype is yg_etype_point and nelems == 1.

I'll submit a patch which fixes this, but it may just be a hack and perhaps something deeper is going wrong. Many other samples still don't run for me at this point, but I'll probably not look into it further.

Enforce looser io policy

Right now, IO errors are very hard and stop IO parsing. This is probably not a good idea since having partial scenes is typical in graphics. We need to enforce a simpler policy that breaks only in the case of catastrophic errors but continues if it can.

add unit tests

Add unit tests to make it simpler to deploy.

  • evaluate test running models
  • consider catch2
  • add simple quick directory
  • setup tests
    • image io
    • image tonemap
    • scene io
    • ytrace rendering
  • consider catch2

example application build failed

Aften I run the cmake .. with no problem. I run the cmake --build, it fail for the reason:

CMakeFiles/yocto_gl.dir/build.make:62: recipe for target 'CMakeFiles/yocto_gl.dir/yocto/yocto_gl.cpp.o' failed
make[2]: *** [CMakeFiles/yocto_gl.dir/yocto/yocto_gl.cpp.o] Error 1
CMakeFiles/Makefile2:178: recipe for target 'CMakeFiles/yocto_gl.dir/all' failed
make[1]: *** [CMakeFiles/yocto_gl.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

there are some error like

error: converting to ‘std::tuple<std::vector<ygl::vec4i, std::allocatorygl::vec4i >, std::vector<ygl::vec3f, std::allocatorygl::vec3f >, std::vector<ygl::vec3f, std::allocatorygl::vec3f >, std::vector<ygl::vec2f, std::allocatorygl::vec2f > >’ from initializer list would use explicit constructor ‘constexpr std::tuple< >::tuple(_UElements&& ...)

Split build script into smaller scripts

Split the main script into shorter scripts so that we can more easily add and remove functionality when working in groups.

  • build release
  • build clean
  • build Xcode
  • build format
  • keep old build.py as deprecated

Ubuntu16.04 Build error

When I type cmake .. I got

-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libGL.so  
-- Found GLEW: /usr/include  
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Configuring done
-- Generating done
-- Build files have been written to: /home/xhg/yocto-gl/build

But when I type make, I got too many errors like this

Scanning dependencies of target yocto_gl
[  4%] Building CXX object CMakeFiles/yocto_gl.dir/yocto/yocto_gl.cpp.o
In file included from /home/xhg/yocto-gl/yocto/yocto_gl.cpp:76:0:
/home/xhg/yocto-gl/yocto/yocto_gl.h: In function ‘std::tuple<std::vector<ygl::vec4i, std::allocator<ygl::vec4i> >, std::vector<ygl::vec3f, std::allocator<ygl::vec3f> >, std::vector<ygl::vec3f, std::allocator<ygl::vec3f> >, std::vector<ygl::vec2f, std::allocator<ygl::vec2f> > > ygl::convert_face_varying(const std::vector<ygl::vec4i>&, const std::vector<ygl::vec4i>&, const std::vector<ygl::vec4i>&, const std::vector<ygl::vec3f>&, const std::vector<ygl::vec3f>&, const std::vector<ygl::vec2f>&)’:
/home/xhg/yocto-gl/yocto/yocto_gl.h:4430:42: error: converting to ‘std::tuple<std::vector<ygl::vec4i, std::allocator<ygl::vec4i> >, std::vector<ygl::vec3f, std::allocator<ygl::vec3f> >, std::vector<ygl::vec3f, std::allocator<ygl::vec3f> >, std::vector<ygl::vec2f, std::allocator<ygl::vec2f> > >’ from initializer list would use explicit constructor ‘constexpr std::tuple< <template-parameter-1-1> >::tuple(_UElements&& ...) [with _UElements = {std::vector<ygl::vec4i, std::allocator<ygl::vec4i> >&, std::vector<ygl::vec3f, std::allocator<ygl::vec3f> >&, std::vector<ygl::vec3f, std::allocator<ygl::vec3f> >&, std::vector<ygl::vec2f, std::allocator<ygl::vec2f> >&}; <template-parameter-2-2> = void; _Elements = {std::vector<ygl::vec4i, std::allocator<ygl::vec4i> >, std::vector<ygl::vec3f, std::allocator<ygl::vec3f> >, std::vector<ygl::vec3f, std::allocator<ygl::vec3f> >, std::vector<ygl::vec2f, std::allocator<ygl::vec2f> >}]’
     return {quads, qpos, qnorm, qtexcoord};
                                          ^
/home/xhg/yocto-gl/yocto/yocto_gl.h: In function ‘std::tuple<std::vector<ygl::vec2i, std::allocator<ygl::vec2i> >, std::vector<ygl::vec3i, std::allocator<ygl::vec3i> >, std::vector<ygl::vec4i, std::allocator<ygl::vec4i> >, std::vector<ygl::vec2i, std::allocator<ygl::vec2i> >, std::vector<ygl::vec4i, std::allocator<ygl::vec4i> > > ygl::subdivide_elems(const std::vector<ygl::vec2i>&, const std::vector<ygl::vec3i>&, const std::vector<ygl::vec4i>&, int)’:
/home/xhg/yocto-gl/yocto/yocto_gl.h:4508:53: error: converting to ‘std::tuple<std::vector<ygl::vec2i, std::allocator<ygl::vec2i> >, std::vector<ygl::vec3i, std::allocator<ygl::vec3i> >, std::vector<ygl::vec4i, std::allocator<ygl::vec4i> >, std::vector<ygl::vec2i, std::allocator<ygl::vec2i> >, std::vector<ygl::vec4i, std::allocator<ygl::vec4i> > >’ from initializer list would use explicit constructor ‘constexpr std::tuple< <template-parameter-1-1> >::tuple(_UElements&& ...) [with _UElements = {std::vector<ygl::vec2i, std::allocator<ygl::vec2i> >&, std::vector<ygl::vec3i, std::allocator<ygl::vec3i> >&, std::vector<ygl::vec4i, std::allocator<ygl::vec4i> >&, std::vector<ygl::vec2i, std::allocator<ygl::vec2i> >&, const std::vector<ygl::vec4i, std::allocator<ygl::vec4i> >&}; <template-parameter-2-2> = void; _Elements = {std::vector<ygl::vec2i, std::allocator<ygl::vec2i> >, std::vector<ygl::vec3i, std::allocator<ygl::vec3i> >, std::vector<ygl::vec4i, std::allocator<ygl::vec4i> >, std::vector<ygl::vec2i, std::allocator<ygl::vec2i> >, std::vector<ygl::vec4i, std::allocator<ygl::vec4i> >}]’
     return {tlines, ttriangles, tquads, edges, quads};
                                                     ^
/home/xhg/yocto-gl/yocto/yocto_gl.h: In function ‘std::tuple<std::vector<ygl::vec4i, std::allocator<ygl::vec4i> >, std::vector<ygl::vec2f, std::allocator<ygl::vec2f> > > ygl::make_uvquads(int, int)’:
/home/xhg/yocto-gl/yocto/yocto_gl.h:4612:22: error: converting to ‘std::tuple<std::vector<ygl::vec4i, std::allocator<ygl::vec4i> >, std::vector<ygl::vec2f, std::allocator<ygl::vec2f> > >’ from initializer list would use explicit constructor ‘constexpr std::tuple<_T1, _T2>::tuple(_U1&&, _U2&&) [with _U1 = std::vector<ygl::vec4i>&; _U2 = std::vector<ygl::vec2f>&; <template-parameter-2-3> = void; _T1 = std::vector<ygl::vec4i>; _T2 = std::vector<ygl::vec2f>]’
     return {quads, uv};
                      ^
/home/xhg/yocto-gl/yocto/yocto_gl.h: In function ‘std::tuple<std::vector<ygl::vec2i, std::allocator<ygl::vec2i> >, std::vector<ygl::vec2f, std::allocator<ygl::vec2f> > > ygl::make_lines(int, int)’:
/home/xhg/yocto-gl/yocto/yocto_gl.h:4632:22: error: converting to ‘std::tuple<std::vector<ygl::vec2i, std::allocator<ygl::vec2i> >, std::vector<ygl::vec2f, std::allocator<ygl::vec2f> > >’ from initializer list would use explicit constructor ‘constexpr std::tuple<_T1, _T2>::tuple(_U1&&, _U2&&) [with _U1 = std::vector<ygl::vec2i>&; _U2 = std::vector<ygl::vec2f>&; <template-parameter-2-3> = void; _T1 = std::vector<ygl::vec2i>; _T2 = std::vector<ygl::vec2f>]’
     return {lines, uv};
                      ^
/home/xhg/yocto-gl/yocto/yocto_gl.h: In function ‘std::tuple<std::vector<int, std::allocator<int> >, std::vector<ygl::vec2f, std::allocator<ygl::vec2f> > > ygl::make_points(int)’:
/home/xhg/yocto-gl/yocto/yocto_gl.h:4643:23: error: converting to ‘std::tuple<std::vector<int, std::allocator<int> >, std::vector<ygl::vec2f, std::allocator<ygl::vec2f> > >’ from initializer list would use explicit constructor ‘constexpr std::tuple<_T1, _T2>::tuple(_U1&&, _U2&&) [with _U1 = std::vector<int>&; _U2 = std::vector<ygl::vec2f>&; <template-parameter-2-3> = void; _T1 = std::vector<int>; _T2 = std::vector<ygl::vec2f>]’
     return {points, uv};

Objs not readable from other applications.

Objs created by yocto aren't readable by other application. I enter the error given by Blender when I import obj:

Traceback (most recent call last):
File "/usr/share/blender/scripts/addons/io_scene_obj/init.py", line 147, in execute
return import_obj.load(context, **keywords)
File "/usr/share/blender/scripts/addons/io_scene_obj/import_obj.py", line 1182, in load
unique_material_images, use_image_search, float_func)
File "/usr/share/blender/scripts/addons/io_scene_obj/import_obj.py", line 344, in create_materials
context_material.specular_hardness = int((float_func(line_split[1]) * 0.51) + 1)
ValueError: bpy_struct: item.attr = val: Material.specular_hardness value not in 'int' range ((-0x7fffffff - 1), 0x7fffffff)
location: :-1

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?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.