<aside>
🧟 Put your two questions here. Please include your [name.](<http://name.Is>)
</aside>
For the bouncing ball challenge 07, would it make more sense to use frameCount or millis as the mapped variable for x? e.g. const x = map(frameCount % 120, 0, 60, 0, width) - Unnati
this is a very good question, and one of the decisions I want everyone in the class to get a better understanding of.
You can pretty much boil the question down to:
"should I use millis() or frameCount"
This does oversimplify a bit, but it captures most of it.
Every semester I feel like the more I explain it the more confusing it sounds.
So trying not to overexplain:
In this case you could use both pretty effectively. The animation is simple, p5 will have no trouble deliving at the request framerate, and your timing is critical. Under these conditions your franeCiybt and expected actual time correspond pretty welel, and pretty well is good enough.
But, if your animation is complex enough that your framerate dips then your frameCount and expected actual time will drift apart quickly.
OR
If timing really is critical (e.g. syncing to sound), then "pretty well" isn't good enough.
In these cases you have to pick between frameCount and millis() carefully. For realtime animation you need millis() if you are prerendering for later full-speed playback, you need frameCount.
The chapter discusses the some challenges with VR animation: designing for both eyes, a higher frame rate, etc. How would you define “presence”? It seems like an intangible concept I can’t quite articulate - Unnati
It is a little bit hard to articulate, but not really.
Think about a very low frame rate animation. You see things "moving" but you also interpret what you are seeing as a series of stills changing quickly. If the frame rate is good enough you stop thinking about the stills and start thinking of the animation as a single, changing thing.
In VR you have a screen strapped in front of your eyes, but we don't want to think of there being an image in front of our eyes. We want to think that we are "in" the image. Better yet 'in' the world. If that illusion is sucessful, we have presense.
I'm pretty excited about VR partly because I think presense has been acheived. I have spent a fair amount of time in a Vive, Rift, and Quest. They all are good enough that it feels like i'm in another place. I especially notice it sometimes when i take the headset OFF, and "snap back to reality".
Actually presense works well enough that its part of the problem designers face: to use VR you kind of leave other people behind. Its hard to work in VR and meatspace at the same time, etc. "Keep Talk and Nobody Explodes" turns this problem around in a great way.
p.s. as i'm writing this I'm thinking about how the idea of 'intagible' is complicated by VR!
Some of the problems I’ve encountered with doing animations in p5 in the past (especially with using frameCount), is that it essentially breaks my browser and freezes it. Any tips, or best-uses, on not overdoing it? - Kevin
I'm assuming you are talking about prerendered animation. If your realtime animation is freezing your browser, you are trying to do something way way out of what is possible (or you have a simple bug).
p5.js isn't great for prerendered animation. it doesn't make a ton of sense to do prerendered animation in the browser (unless you have another requirement that does fit the browser)
p5.js isn't _great_ for most things actually. It mostly makes sense when you want to share what you make on the web, you want to get started very quickly (sketching), or you are learning. (We use p5 in DT-like many other programs-because of the community of teaching and learning creative coding around it)
Some tips:
- Its okay for a single frame to take seconds or dozens of seconds per frame. If its takeing mintues per frame you might run into issues.
- If you are `save()`ing frames out, you don't want to run TOO FAST, as that will cause problems also. I ususally set my framerate to 1 to make sure i never try to save faster than 1 frame per second.
- Depending on your goals, you might want to use pixelDensity(1) if you are on a high dpi screen. Otherwise you might be doing 4x more work than you need.
- Sometimes depending on you goals, you split drawing over multiple frames. (frame 1 clear the background and do some drawing, frame 2 do more drawing, frame 3 do more drawing, ...., frame n save out the drawing) If you are getting to this point you probably are in the wrong tool.
- Pixel work is very slow in p5, but you can use shaders WITH p5. shaders tear through pixel work.
- If your code is running very slow, you should always be considering that maybe your code is just 'bad'. More specifically, maybe your code is inneficient. Can you improve your algorithm to get to the same result with less work?
There are some examples you write about exporting the animation into a third party and editing it through that. Are there other examples of animating through code, not done through p5? I’m thinking about 2D animations in Unity? - Kevin
Well *i'm* not providing any examples other than what is on the chapter, but almost ALL animation you see uses code. At least in as much as animation tools are software.
But more than that, it is pretty common that larger animation projects have at least some -project specific- code. Software like Blender and Maya provide full apis that let you combine code with manual work. Blender supports Python and node based programming
Is there a way to combine pre-rendered animations(apart from loading and playing videos) along with real time animation in p5? I’m thinking more on the lines of how Unity has animators(pre-rendered). - Smitha
I'm not sure what you mean by Unity animators, but Unity animation is almost entirely realtime. If you aren't laoding and playing videos, you are probably enaged in real-time animtion.
prerendered: rendered before it is watched
realtime: rendered while it is watch