rreusser / regl-gpu-lines Goto Github PK

i cloned this repo & did npm install (was hoping to try out some of the examples). got this error:

marina@pumpkin:~/dev/regl-gpu-lines$ npm install
npm ERR! code 1
npm ERR! path /home/marina/dev/regl-gpu-lines/node_modules/gl
npm ERR! command failed
npm ERR! command sh -c prebuild-install || node-gyp rebuild
npm ERR! (node:13786) [DEP0150] DeprecationWarning: Setting process.config is deprecated. In the future the property will be read-only.
npm ERR! (Use `node --trace-deprecation ...` to show where the warning was created)
npm ERR! Package xi was not found in the pkg-config search path.
npm ERR! Perhaps you should add the directory containing `xi.pc'
npm ERR! to the PKG_CONFIG_PATH environment variable
npm ERR! No package 'xi' found
npm ERR! gyp: Call to 'pkg-config --libs-only-L --libs-only-other x11 xi xext' returned exit status 1 while in angle/src/angle.gyp. while loading dependencies of binding.gyp while trying to load binding.gyp
npm ERR! gyp ERR! configure error 
npm ERR! gyp ERR! stack Error: `gyp` failed with exit code: 1
npm ERR! gyp ERR! stack     at ChildProcess.onCpExit (/home/marina/dev/regl-gpu-lines/node_modules/node-gyp/lib/configure.js:351:16)
npm ERR! gyp ERR! stack     at ChildProcess.emit (node:events:365:28)
npm ERR! gyp ERR! stack     at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12)
npm ERR! gyp ERR! System Linux 5.4.0-90-generic
npm ERR! gyp ERR! command "/usr/local/bin/node" "/home/marina/dev/regl-gpu-lines/node_modules/.bin/node-gyp" "rebuild"
npm ERR! gyp ERR! cwd /home/marina/dev/regl-gpu-lines/node_modules/gl
npm ERR! gyp ERR! node -v v16.1.0
npm ERR! gyp ERR! node-gyp -v v7.1.2
npm ERR! gyp ERR! not ok

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/marina/.npm/_logs/2021-11-16T22_39_07_600Z-debug.log

my node version is 16.1.0 and my npm version is 7.12.1

any idea what might be going on?

I'd love for regl to be an afterthought and refactor the core of this module not to actually depend on it. I don't quite know what it means though to write a raw WebGL 1/2 module which uses advanced features but doesn't require an agonizing amount of very specialized interfacing in order to use. Vlad's WebGL 2 boilerplate is certainly very interesting as a potential approach, though until it grows to encompass all of the underlying API surface area, it sort of feels like an all-or-none buy in; you either have to go all the way down to the level of individual WebGL API calls or all the way up to the level of a library which entirely wraps it (threejs, regl). Unless a lightweight wrapper would allow you to just make the raw WebGL calls yourself, which may be the case.

Sometimes it's necessary to, for example, draw lines on a flat surface and then project those into three dimensions after line vertex computation. It seems necessary to add a post-processing pragma for the vertex shader. This is easy to implement but just want to think it over before adding.

They're available. Need to figure out the details. https://github.com/regl-project/regl/blob/master/API.md#vertex-array-objects

This is more of a discussion than a suggestion for the library, but in general, I love how this library has variable-width strokes and colors, which are great for working with a stylus.
However, my particular use case really needs a CPU-side solution, and in C / C++ no less.
Somehow I have been unable to find a library that supports the above and I'm wondering if you could offer suggestions for where to find something like that, or references for how to build it or adapt it from existing solutions. In short, it's strange, but variable-width and color per-vertex polycurves seem very rare.

It's a couple versions behind. Gotta dig up those credentials, then will be able to publish.

In version 1.0.0, iOS 15 Safari shows some overlapping pixels where caps meet segments. I'm not sure what's causing this, unless maybe triangle strips require knowledge that it's a triangle strip in order to avoid? I thought as long as the tris met floating-point-correctly that the GPU had some magic way to get this right.

At any rate it's not a blocker and there are bigger self-intersection issues with transparent lines anyway, but it'd be nice to understand.

I'm currently working on an implementation of regl-gpu-lines for WebGPU.

regl-gpu-lines was the only thing keeping me from switching to WebGPU, because it's so amazing, but I've decided to bite the bullet and switch to WebGPU.

Right now, I'm working on a WebGPU version of this library. I've read the articles at the bottom of the README a few times over but I'm still struggling to grasp the implementation.

Have you guys thought about doing some sort of write up on how regl-gpu-lines works under the hood?

Thanks!!