alexlarsson / gthree Goto Github PK

https://threejs.org/docs/#api/en/scenes/Fog

It doesn't make sense to use a non-premultiplied format for textures, and GdkPixbuf isn't exactly great. Move to cairo_surface_t? or custom GBytes?

See:
https://threejs.org/docs/#api/en/objects/Mesh.setDrawMode

We currently support only triangles, would be nice to also do strips and fans.

This is the KHR_DRACO_MESH_COMPRESSION, which seems useful (and implemented by three.js).

Failed to build on armv7hl and i686 arches
https://koji.fedoraproject.org/koji/taskinfo?taskID=37600791

/usr/lib/gcc/i686-redhat-linux/9/include/stddef.h:424: syntax error, unexpected identifier in '  __float128 __max_align_f128 __attribute__((__aligned__(__alignof(__float128))));' at '__float128'

Full build log.

The current code assumes that each GthreeRenderer has full access to the gl context (it tracks the current state after all). GthreeResources are then realized for a particular renderer with e.g. gthree_resource_set_realized_for().

However, we're currently only storing one copy of the gl resources for the various resources (textures, attributes, render-targets), which is not quite right. If you're using the same resources in multiple renderers we should really allocate once for each renderer.

With the current code we should really assert that we realize for the right renderer, however that will break the current multi-view demo which currently works by chance due to the way Gtk+ makes all gl contexts in the same window share resources...

in examples/shadows the (blue) spotlight doesn't seem to cast any shadows on the "floor". Or rather, there is no blue at all on the floor even when there isn't supposed to be any shadows.

When you disable depth writes for some object this seem to break rendering of other objects in the scene. For example, disabling it on the booster in gnome-hexl shows this (see TODO in the ship effects code).

Not currently supported:

• Hemisphere
• RectArea
• Spot

The code currently has the unref commented out, but it it is enabled again we crash when switching models.

The normals for the caps are crap, and we need to set separate groups for the caps.

This would be nice to have for gnome-hexgl hud texture clipping instead of having to use separate passes. And the code is mostly there anyway.

In the points example, some of the flakes combine correctly, but some overwrite the ones behind them even in the area where the map is transparent. Disabling depth tests doesn't seem to fix it, but depth_write does (although that has other issues).

three.js has a bunch of helpers that are useful to generate interesting geomtries for demos and debugging. For example, these would be nice to have:

• ArrowHelper
• AxesHelper
• CameraHelper
• PlaneHelper
• GridHelper
• SkeletonHelper

etc.

Hello Alex.

a38a231 build fine, but next commit 2092385 build fail. :)

Build log:

/usr/bin/ld: gthree/a0bd3e6@@gthree-1@sha/gthreerenderer.c.o: in function `project_planes':
/builddir/build/BUILD/alexlarsson-gthree-2092385/x86_64-redhat-linux-gnu/../gthree/gthreerenderer.c:1214: undefined reference to `graphene_plane_transform'
collect2: error: ld returned 1 exit status

See
https://threejs.org/docs/#api/en/renderers/WebGLRenderTarget

This is very useful for post-process passes. See e.g. https://threejs.org/examples/#webgl_postprocessing_unreal_bloom

See e.g.:
https://threejs.org/docs/#api/en/objects/Mesh.morphTargetInfluences

Make error:

Couldn't find include 'Graphene-1.0.gir' (search path: ['gir-1.0', '/usr/share/gir-1.0', '/usr/share/gir-1.0', '/usr/share/gir-1.0'])
/usr/share/gobject-introspection-1.0/Makefile.introspection:153: recipe for target 'Gthree-1.0.gir' failed

I've installed Graphene to /usr/local folder, its .gir file was placed by make install command here:

/usr/local/share/gir-1.0/Graphene-1.0.gir

See:
https://threejs.org/docs/#api/en/objects/Sprite

I added support for shadow maps to GthreePointLight, and the examples/shadow test. However, the shadow looks wrong to me, needs debugging.

It turns out that three.js has some special code to handle negative scaling in the backface culling code. If the determinant of the transform matrix is negative it auto-flips back and front faces.
If this support is backported, we should also revert d33040a

See https://threejs.org/docs/#api/en/objects/LOD

When this is done we can stop setting auto_update to FALSE if matrix is set in the GLTF loader.

Just want to +1 on this project. It's a nice surprise coming back from Libre Graphics Meeting, to see this project get some commits :)

Three.js has some more primitives that would be nice to have. For example:

• Cone
• Circle
• Dodecahedron
• Edges
• Icosahedron
• Plane
• etc

This is useful for picking.

See:
https://threejs.org/docs/#api/en/objects/Mesh.raycast

graphene has some raycast support which we can use.

If you put something at x = 0, y= 100 z= 0 and look_at (0, 0, 0) things go wrong. I think this is due to that handling of object.up, which isn't well defined in this case. Still it should get something useful.

three.js dropped multimaterial in favour of material being an array. Should we do the same?

There is even a GLTF test for these in the samples: TextureTransformTest

On GL implementations that support float textures we can more efficiently compute the skinning. There is code in three.js for this we can backport.

This needs adding a custom material (see three.js loader) as well as handling the extension itself.

Got the following complaint:

configure.ac:7: error: possibly undefined macro: AC_DISABLE_STATIC
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

Full log: https://gist.github.com/thorsummoner/4468b95a91fb4b1d05cc

Should consider using a graphene_vec3_t instead, this way we a) avoid a gratiious dependency on gtk+ int the core APIs (for example for multi-gtk versions), and b) expose the fact that we never read the alpha part of the GdkRGBA anyway.