jeelizFaceFilter VS three-stdlib

Ikr! That's what I was thinking when I came across Jeeliz. Now I have worked with tensorflow.js based libraries in the past but they're usually quite CPU intensive for a live video use case. Jeeliz looked promising as it's designed for this use case. So I thought why not try it out by adding some 3d AR filters to our video calls. Well! that is what we're going to do.

I created a demo face filter web app using jeeliz. It has great features however, I found that the tracking performance wasn't perfect. Media pipe seems to require building out custom features manually to achieve the face filter app I need. I'm wondering if building a more custom app with mediapipe would be worth the extra effort over Jeeliz.

We have forked parts of the three core stuff to minimise breaks. drei for instance uses https://github.com/pmndrs/three-stdlib not examples/jsm. The threejs version you install can still pull the rug but pmndrs works against that with conditionals, shaders for instance are made to function despite three breaking stuff. You can generally rely on it and Fiber + eco system has semantic versioning.

React Three Fiber has been a fantastic way to quickly prototype 3D apps and games, and even efficient enough to carry them through to production. The problem? It’s can be a lot of setup. Just from that last paragraph, you see the string of dependencies R3F uses, and it gets even more complicated from there when you familiarize yourself with the current ThreeJS ecosystem (see: three-stdlib).

three doesn't play well with node and node based environments. poimandres has been building out three's reach more and more, for instance https://github.com/pmndrs/three-stdlib this will all run under next/nuxt or whatever without workarounds.

three is harder to use in next because it doesn't run under node. with three-fiber we have begun to fork some parts of it: https://github.com/pmndrs/three-stdlib that will make it easier to use it under next, even if you use "vanilla" three, stdlib's GLTFLoader will run fine whereas there/jsm won't (without workarounds). is there any reason why you would not want to use react for three though? you're using it for the dom already, r3f is the exact same thing as react-dom, a renderer, it doesn't wrap three.

Same, the pmndrs folks at least pulled some of the examples stuff into https://github.com/pmndrs/three-stdlib which is ESM

you can use the same tools that react users use because we face the same problems. for instance, next/nuxt are running under node, which doesn't understand what "import" means, so you'll not be able to use anything from three/examples/jsm/ (loaders, controls, etc). but we have made solutions for that. for instance https://github.com/pmndrs/three-stdlib generally there is lots on the poimandres github org that is equally valid for vanilla, react, vue and anything else.

don't mix three and react. take an hour to read through react-three-fiber docs and port it. you will be so much better off, 95% of that code will just vanish. poimandres also takes care of all the other parts, for instance three/examples/jsm/* is not node compatible, you can't easily use it in next. but there exists three-stdlib now and many other things that make your life easier.