xelatihy / yocto-gl Goto Github PK
View Code? Open in Web Editor NEWYocto/GL: Tiny C++ Libraries for Data-Driven Physically-based Graphics
Home Page: https://xelatihy.github.io/yocto-gl
Yocto/GL: Tiny C++ Libraries for Data-Driven Physically-based Graphics
Home Page: https://xelatihy.github.io/yocto-gl
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.
Why don't you add pre-built binaries for people that just want to try it out without bothering to compile the apps?
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.
There is a bug when saving subdivs where an IO error occurs.
https://github.com/xelatihy/yocto-gl/blob/master/yocto/yocto_gltf.h
Should be "material_metallic_roughness"
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.
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
Add a function to help logging timed computation.
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.
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
yimview should support color grading tools
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?
Using latest master branch, build is not possible using MinGW 6.2.0 64bit.
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
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?
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.
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.
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.
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?
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
yocto-gl/apps/w32/include/GLFW/glfw3.h
Line 147 in b120190
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?
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.
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.
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&& ...)
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
/home/xxx/Gits/yocto-gl/bin/yshade car.gltf
Signal: SIGSEGV (Segmentation fault)
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.
Split the main script into shorter scripts so that we can more easily add and remove functionality when working in groups.
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.
Internal functions for loading and saving images should use std::vector instead of raw pointers for safety.
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.
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.
compiling as said in the readme.md leeds me to multiple line of C2864 error in MVSC2017
Can yocto-gl support the directional light source?
I am sorry that now I only find the env light, point light and area light.
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)
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};
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.
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.
Line 367 in 079a7ce
Shouldn't the right hand side be inertia[1][2]
?
Note that I haven't actually used your code, was just browsing the code.
Line 174 in b4b5eb1
Python is good, but not here...
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.
JSON serialization should follow the conventions of binary serialization to simplify code and remove the dependency from the current son library.
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 :)
Use flat structures for images to adhere more closely to data driven design.
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.
Add unit tests to make it simpler to deploy.
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.
format() should assert when the number of arguments used is wrong.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.