ccapture.js VS paper.js

I also tried to find a better recording method. Since I’m now using canvas, there are some solutions to recording that seemed quite elegant. For example, paper.js uses requestAnimationFrame to achieve its smooth animation. There are libraries like ccapture.js that hooks into the various methods like requestAnimationFrame and setInterval, allowing it to render each frame separately.

I actually spent a fair bit of time on this and eventually got something to work. Someone named "spite" made a great library called CCapture for doing this, but it needs to be updated and repackaged for ES6. Right now it is painful to integrate into your project, but it could be super-easy. You can help to encourage someone to fix the issues here.

Check out CCapture.

The image capture step uses ccapture to ensure that the playback frame is converted to an image. All frame images to webm video.

ccapture.js basically let's you write out frames from a threejs camera, which you then stitch together with ffmpeg.

I use ccapture, using the png option, which will spit out a tar with a png of each frame, and then I stitch them with ffmpeg.

This video is 1800 frames (30 FPS * 60s)... a browser trying to save 1800 individual frames would lock up and die. Ccapture.js hooks into the browser's rendering code and captures the frames as a 'blob' - a binary object that is often used for streaming video - and then wraps them up into one single download.

p5.js runs the sketch, ccapture.js captures all of the frames (1800 in this video), and ffmpeg combines the frames into an MP4.

I use ccapture.js, which captures the frames as a blob in real-time then exports it as a .tar file full of jpgs when the sketch is finished (with 'finished' defined as reaching 1800 frames, in this case). This is a lot better than having the browser try to save 1800 jpgs the usual way.

I started with angular and paper.js: http://paperjs.org/

In a thread in the Processing forum, Boolean operations in polygons , user ErraticGenerator suggests using g.js or Paper.js.

It is likely that paper.js provides the functionality needed. I will probably investigate it at some point since it appears to be the more popular library Compare paper.js & bezier.js.

To solve that issue, I searched for some solutions using canvas. I didn’t want to work with pure canvas so after doing some research, I settled with paper.js.

Ooh, the Chebyshev basis is neat. I hadn't seen exactly that before. It reminds me a lot of the "shape control" technique[1] which is also similar to a basis function approach but has a bit of linear solving. Essentially, you get one point (usually at t = 0.5), and also the direction but not magnitudes of the tangents at the endpoints (G1, not C1). This is one of the better-performing existing techniques for offset curve, though does have stability problems (in particular, nasty behavior for a symmetric "S" curve).

Regarding collaboration with Freya, if she is open to it, please get in touch. I do have some ideas.

[1]: A New Shape Control and Classification for Cubic Bézier Curves, Yang and Huang, 1993, PDF cache: https://github.com/paperjs/paper.js/files/752955/A.New.Shape...

Paper.js - example (not interactive, just code)

Just remember you can do some SVG displacement with Paper.JS

> <p>Oh yeah, you reminded me of the template fatigue that was paper.js and it trying to reinvent scripting on the client side with <script type="text/paperscript"> templates that could use templates that could use templates... and so on. [0] I was wondering why people would go to such great lengths just to avoid having to script in the browser.<p>The way I saw it at the time was that I've rediscovered the same mistakes that PHP did back in the days. All the recurs(iv)ed templating problems, all the OOP fatigue that never worked out (magento and zend, anyone?), and all the inheritance based "reinventions" of existing web technologies like OOCSS [1].<p>I mean, at some point every engineer should be wise enough to give up on trying to predict the future. Especially in projects they cannot predict what features are going to be implemented, so I'd naturally assume that modularity and compositional or entity/component aspects will win in later revisions or refactor decisions. But I was wrong with that assumption, I guess :S<p>I also can kinda understand the general bias towards closure among functional folks. I guess that lots of people at the time (or nowadays) had high hopes for it allowing to go more "functional" in its approach, allowing compositional patterns to be useful on the web. But, honestly, JS itself is so flexible and can be used in all kinds of architectural patterns that I think closure's purpose is kind of void by its own concept.<p>When comparing closure with, say, typescript (which I also don't agree with, because "string" and "String" and "any" are pointless from any language design perspective): Typescript at least has the benefit of typed API docs and good IDE integrations (due to LSP) that can be used in large teams to reduce the overhead of getting started with working on foreignly-owned code - whereas closure doesn't have any unique selling point in my opinion. I mean, even scala.js has a unique selling point when being judged like that.<p>[0] <a href="https://github.com/paperjs/paper.js" rel="nofollow">https://github.com/paperjs/paper.js</a><p>[1] <a href="http://oocss.org/" rel="nofollow">http://oocss.org/</a>

Our webapp is written with React and Redux using the official react-redux bindings. Another primary library used in this web app is PaperJS. We recently transitioned this to being a Redux app, though it has used React for a while.

I am currently using http://paperjs.org to create an HTML5 canvas drawing app. I want to let users upload images into the canvas. I know I need to make a login and signup but is there an easier way? I have seen the HTML5 drag and drop upload.