xelatihy / yocto-gl Goto Github PK

View Code? Open in Web Editor NEW

2.8K 94.0 203.0 305.51 MB

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

Home Page: https://xelatihy.github.io/yocto-gl

C 26.98% C++ 68.35% CMake 1.11% Objective-C 1.61% Python 0.53% Objective-C++ 0.60% Shell 0.01% GLSL 0.01% Cuda 0.80%

path-tracer gltf graphics physically-based-rendering computer-graphics rendering path-tracing cplusplus cpp 3d-graphics

yocto-gl's People

Contributors

Stargazers

Watchers

Forkers

papagiannakis mattrudder vr3d mariano-gn templeblock connlan erwincoumans finger563 randrew muilib lefebvre stoeckley digiant 4da bssrdf gomson teella kjue gamedevforks simoncblyth teybeo rzel citrusforks lubosz ashelley southdy invor yxsamurai pteromys awhittle3 linlangongzi mohitnitrr jeanlpicard elva7073 cyanpencil realgreendragon kariem2k xin-xinhanggao andreim14 antoniomuso ymb27 jfaust sikiro-dev geoffmcl mazzapaolo dipietrantonio hinike jonike scrusader dongbu sir-pinecone llde senthuran-ukr brenxthecpdev mrbigdog udnaan marcoandreozzi kxf3199 edoardocarra peterzhousz mlivesu peterzs vtppplusgo mallonoce bsdorra guillaumechereau airseepepe massvoid zhangximing erez-o blockspacer silver960 xtvjxk123456 alan-love lxlyh mkanada haolly fromasmtodisasm octogame viclw17 mortal2000 quantumsheep bamless gianmarcopicarella joe-nano hrehfeld jaeger87 rickymexx salvatorecognetta infancy aimoonchen domenicobrz hanke98 lp249839965 raphaelk12 binayakdotel sarettak elenafk zeta1999 fabrcas

yocto-gl's Issues

Little language confusion

yocto-gl/apps/yscnproc.cpp

Line 174 in b4b5eb1

if (info and scale != 1.0f) {

Python is good, but not here...

Line 5994-5995 cause build error in yocto_gltf.h

Using latest master branch, build is not possible using MinGW 6.2.0 64bit.

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};

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.

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.

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?

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.

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.

UI application should use a window wrapper rather than using straight GLFW

Right now Yocto/GL uses GLFW windows directly. This makes it hard to define our own functions on top of GLFW. For example, we cannot change the callbacks signatures even if that might ve better. Also we cannot automatically handle widgets resizing.

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)

Bug in saving subdivs

There is a bug when saving subdivs where an IO error occurs.

use flat structure for images

Use flat structures for images to adhere more closely to data driven design.

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

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.

Consider image access with `at()` function.

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?

Segmentation fault

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

add unit tests

Add unit tests to make it simpler to deploy.

Implementation of image IO should use std::vector

Internal functions for loading and saving images should use std::vector instead of raw pointers for safety.

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.

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.

use typed OpenGL objects and remove the "gl" prefix

Use typed objects for OpenGL and remove the "gl" prefix on the OpenGL functions. This makes the code less error prone and less pedantic at the same time.

Missing library on MSVC 2017

yocto-gl/apps/w32/include/GLFW/glfw3.h

Line 147 in b120190

#include <GL/glcorearb.h>

Visual Studio 2017 (on Windows 10) can't find this library, so the include fails.
Can I comment the include or I must install something?

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.

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

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

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?

format does not produce an error the. the wrong number of arguments is used

format() should assert when the number of arguments used is wrong.

Add logging of timed events.

Add a function to help logging timed computation.

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.

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.

yo__vhash leaked per obj file

The yo__vhash used by yo_load_obj is never freed, leading to large memory leaks.

https://github.com/xelatihy/yocto-gl/blob/master/yocto/yocto_obj.h#L1021

This function has multiple return paths, so it will need to be restructured or changed in order to always safely free the yo__vhash. Adding a delete vhash at the end of the function will not solve the problem in the case that the file is unable to be opened, or a MTLLIB file fails to open or be parsed.

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

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.

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.

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?

[yocto_math] dot product implementation uses explicit floats

Typo in struct material_metallic_rooughness

https://github.com/xelatihy/yocto-gl/blob/master/yocto/yocto_gltf.h

Should be "material_metallic_roughness"

JSON serialization using dictionaries and serialize methods

JSON serialization should follow the conventions of binary serialization to simplify code and remove the dependency from the current son library.

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

Faster object reference during serialization

Right now, during serialization, checking for object references incurs a O(n^2) costs. This can be made O(1) by passing object dictionaries during serialization.

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

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.

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.

Bug in compute_moments?

yocto-gl/yocto/yocto_sym.h

Line 367 in 079a7ce

inertia[2][1] = inertia[1][1];

Shouldn't the right hand side be inertia[1][2]?

Note that I haven't actually used your code, was just browsing the code.

Compilation error C2864 with json.hpp

compiling as said in the readme.md leeds me to multiple line of C2864 error in MVSC2017

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 :)

yimview support for color grading

yimview should support color grading tools

Split mesh_data and fvmesh_data for better type safety.

mesh_data now contains code also for face-varying stuff.
This means that we cannot use compile time checks for this code.
We can instead just split the two entities.

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