cortex: org/capture-video.org comparison

comparison org/capture-video.org @ 280:301e91a6c2d1

correct formating for capture-video.org

author	Robert McIntyre <rlm@mit.edu>
date	Wed, 15 Feb 2012 10:31:51 -0700
parents	da4de661c5d9
children	7351c9c0c471

comparison

equal deleted inserted replaced

-:d8ff1a293b8c
+:301e91a6c2d1
 * The Problem
 So you've made your cool new JMonkeyEngine3 game and you want to
 create a demo video to show off your hard work. Screen capturing is
 the most straightforward way to do this, but it can slow down your
 game and produce low-quality video as a result. A better way is to
-record a video feed directly from the game while it is
+record a video feed directly from the game while it is running.
-running.
 In this post, I'll explain how you can alter your JMonkeyEngine3 game
 to output video while it is running. The main trick is to alter the
 pace of JMonkeyEngine3's in-game time: we allow the engine as much
 time as it needs to compute complicated in-game events and to encode
 * Video recording requires a steady framerate
 ** The built-in =Timer= rushes to keep up.
 #* Game-time vs. User-time vs. Video-time
-Standard JME3 applications use a =Timer= object to manage time
+Standard JME3 applications use a =Timer= object to manage time in the
-in the simulated world. Because most JME3 applications (e.g. games)
+simulated world. Because most JME3 applications (e.g. games) are
-are supposed to happen \ldquo{}live\rdquo{}, the built-in =Timer=
+supposed to happen \ldquo{}live\rdquo{}, the built-in =Timer= requires
-requires simulated time to match real time. This means that the
+simulated time to match real time. This means that the application
-application must rush to finish all of its calculations on
+must rush to finish all of its calculations on schedule: the more
-schedule: the more complicated the calculations, the more the
+complicated the calculations, the more the application is obligated to
-application is obligated to rush. And if the workload becomes too
+rush. And if the workload becomes too much to handle on schedule,
-much to handle on schedule, =Timer= forces the application to cut
+=Timer= forces the application to cut corners: it demands fast,
-corners: it demands fast, approximate answers instead of careful,
+approximate answers instead of careful, accurate ones.  Although this
-accurate ones.  Although this policy sometimes causes physically impossible
+policy sometimes causes physically impossible glitches and choppy
-glitches and choppy framerates, it ensures that the user will never be
+framerates, it ensures that the user will never be kept waiting while
-kept waiting while the computer stops to make a complicated
+the computer stops to make a complicated calculation.
-calculation.
 Now, the built-in =Timer= values speed over accuracy because real-time
-applications require it. On the other hand, if your goal is to record a
+applications require it. On the other hand, if your goal is to record
-glitch-free video, you need a =Timer= that will take its time to
+a glitch-free video, you need a =Timer= that will take its time to
-ensure that all calculations are accurate, even if they take a long time. In the next section, we
+ensure that all calculations are accurate, even if they take a long
-will create a new kind of =Timer=\mdash{}called =IsoTimer=\mdash{}which
+time. In the next section, we will create a new kind of
-slows down to let the computer finish all its calculations. The result
+=Timer=\mdash{}called =IsoTimer=\mdash{}which slows down to let the
-is a perfectly steady framerate and a flawless physical simulation.
+computer finish all its calculations. The result is a perfectly steady
+framerate and a flawless physical simulation.
 # are supposed to happen \ldquo live \rdquo, this =Timer= requires the
-# application to update in real-time. In order to keep up with the real world, JME applications cannot
+# application to update in real-time. In order to keep up with the
-# afford to take too much time on expensive computations. Whenever the
+# real world, JME applications cannot afford to take too much time on
-# workload becomes too much for the computer to handle on schedule,
+# expensive computations. Whenever the workload becomes too much for
-# =Timer= forces the computer to cut corners, giving fast, approximate
+# the computer to handle on schedule, =Timer= forces the computer to
-# answers instead of careful, accurate ones. Although physical accuracy sometimes
+# cut corners, giving fast, approximate answers instead of careful,
-# suffers as a result, this policy ensures that the user will never be
+# accurate ones. Although physical accuracy sometimes suffers as a
-# kept waiting while the computer stops to make a complicated
+# result, this policy ensures that the user will never be kept waiting
-# calculation.
+# while the computer stops to make a complicated calculation.
 #fast answers are more important than accurate ones.
 # A standard JME3 application that extends =SimpleApplication= or
 # =Application= tries as hard as it can to keep in sync with
-# /user-time/.  If a ball is rolling at 1 game-mile per game-hour in the
+# /user-time/.  If a ball is rolling at 1 game-mile per game-hour in
-# game, and you wait for one user-hour as measured by the clock on your
+# the game, and you wait for one user-hour as measured by the clock on
-# wall, then the ball should have traveled exactly one game-mile. In
+# your wall, then the ball should have traveled exactly one
-# order to keep sync with the real world, the game throttles its physics
+# game-mile. In order to keep sync with the real world, the game
-# engine and graphics display.  If the computations involved in running
+# throttles its physics engine and graphics display.  If the
-# the game are too intense, then the game will first skip frames, then
+# computations involved in running the game are too intense, then the
-# sacrifice physics accuracy.  If there are particuraly demanding
+# game will first skip frames, then sacrifice physics accuracy.  If
-# computations, then you may only get 1 fps, and the ball may tunnel
+# there are particuraly demanding computations, then you may only get
-# through the floor or obstacles due to inaccurate physics simulation,
+# 1 fps, and the ball may tunnel through the floor or obstacles due to
-# but after the end of one user-hour, that ball will have traveled one
+# inaccurate physics simulation, but after the end of one user-hour,
-# game-mile.
+# that ball will have traveled one game-mile.
-# When we're recording video, we don't care if the game-time syncs with
+# When we're recording video, we don't care if the game-time syncs
-# user-time, but instead whether the time in the recorded video
+# with user-time, but instead whether the time in the recorded video
 # (video-time) syncs with user-time. To continue the analogy, if we
-# recorded the ball rolling at 1 game-mile per game-hour and watched the
+# recorded the ball rolling at 1 game-mile per game-hour and watched
-# video later, we would want to see 30 fps video of the ball rolling at
+# the video later, we would want to see 30 fps video of the ball
-# 1 video-mile per /user-hour/. It doesn't matter how much user-time it
+# rolling at 1 video-mile per /user-hour/. It doesn't matter how much
-# took to simulate that hour of game-time to make the high-quality
+# user-time it took to simulate that hour of game-time to make the
-# recording.
+# high-quality recording.
 ** COMMENT Two examples to clarify the point:
 *** Recording from a Simple Simulation
 **** Without a Special Timer
 You have a simulation of a ball rolling on an infinite empty plane at
 Now, JME3 will spend $\frac{1}{120}$ of a user-second to step the
 physics tick $\frac{1}{60}$ game-seconds, $\frac{1}{60}$ to draw to
 the screen, and an additional $\frac{1}{60}$ to encode the video and
 write the frame to disk. This is a total of $\frac{1}{24}$
 user-seconds for each $\frac{1}{60}$ game-seconds. It will take
-$(\frac{60}{24} = 2.5)$ user-hours to record one game-hour and game-time
+$(\frac{60}{24} = 2.5)$ user-hours to record one game-hour and
-will appear to flow two-fifths as fast as user time while the game is
+game-time will appear to flow two-fifths as fast as user time while
-running. However, just as in example one, when all is said and done we
+the game is running. However, just as in example one, when all is said
-will have an hour long video at 60 fps.
+and done we will have an hour long video at 60 fps.
 ** COMMENT proposed names for the new timer
 # METRONOME
 # IsoTimer
 =./src/com/aurellem/capture/IsoTimer.java=
 #+include ../../jmeCapture/src/com/aurellem/capture/IsoTimer.java src java
 If an Application uses this =IsoTimer= instead of the normal one, we
-can be sure that every call to =simpleUpdate=, for example, corresponds
+can be sure that every call to =simpleUpdate=, for example,
-to exactly $(\frac{1}{fps})$ seconds of game-time.
+corresponds to exactly $(\frac{1}{fps})$ seconds of game-time.
 * =VideoRecorder= manages video feeds in JMonkeyEngine.
 ** =AbstractVideoRecorder= provides a general framework for managing videos.
 =./src/com/aurellem/capture/video/XuggleVideoRecorder.java=
 #+include ../../jmeCapture/src/com/aurellem/capture/video/XuggleVideoRecorder.java src java
 With this, we are able to record video!
-However, it can be hard to properly install Xuggle. If you would rather not use Xuggle, here is an alternate class that uses
+However, it can be hard to properly install Xuggle. If you would
-[[http://www.randelshofer.ch/blog/2008/08/writing-avi-videos-in-pure-java/][Werner Randelshofer's]] excellent pure Java AVI file writer.
+rather not use Xuggle, here is an alternate class that uses [[http://www.randelshofer.ch/blog/2008/08/writing-avi-videos-in-pure-java/][Werner
+Randelshofer's]] excellent pure Java AVI file writer.
 =./src/com/aurellem/capture/video/AVIVideoRecorder.java=
 #+include ../../jmeCapture/src/com/aurellem/capture/video/AVIVideoRecorder.java src java
 This =AVIVideoRecorder= is more limited than the
 * How to record videos yourself
 ** Include this code.
 No matter how complicated your application is, it's easy to add
 support for video output with just a few lines of code.
 #  You can also record from multiple ViewPorts as the above example shows.
-And although you can use =VideoRecorder= to record advanced split-screen videos with multiple views, in the simplest case, you want to capture a single view\mdash{}
+And although you can use =VideoRecorder= to record advanced
-exactly what's on screen. In this case, the following simple =captureVideo=
+split-screen videos with multiple views, in the simplest case, you
-method will do the job:
+want to capture a single view\mdash{} exactly what's on screen. In
+this case, the following simple =captureVideo= method will do the job:
 #+begin_src java
 public static void captureVideo(final Application app,
 				final File file) throws IOException{
 final AbstractVideoRecorder videoRecorder;
 };
 app.enqueue(thunk);
 }
 #+end_src
-This method selects the appropriate =VideoRecorder= class
+This method selects the appropriate =VideoRecorder= class for the file
-for the file type you specify, and instructs your
+type you specify, and instructs your application to record video to
-application to record video to the file.
+the file.
 Now that you have a =captureVideo= method, you use it like this:
 - Establish an =Isotimer= and set its framerate :: For example, if
 you want to record video with a framerate of 30 fps, include
 this.setTimer(new IsoTimer(30));
 #+end_src
 - Choose the output file :: If you want to record from the game's
 main =ViewPort= to a file called =/home/r/record.flv=, then
-include the following line of code somewhere before you call =app.start()=;
+include the following line of code somewhere before you call
+=app.start()=;
 #+begin_src java :exports code
 Capture.captureVideo(app, new File("/home/r/record.flv"));
 #+end_src
 #+END_HTML
 * COMMENT More Examples
 ** COMMENT Hello Physics
-=HelloVideo= is boring. Let's add some video capturing to =HelloPhysics=
-and create something fun!
+=HelloVideo= is boring. Let's add some video capturing to
+=HelloPhysics= and create something fun!
 This example is a modified version of =HelloPhysics= that creates four
 simultaneous views of the same scene of cannonballs careening into a
 brick wall.
 demo application using Xuggle (www.xuggle.com/).  Everything is
 explained at http://aurellem.org/cortex/capture-video.html.  Here,
 four points of view are simultaneously recorded and then glued
 together later.
 JME3 Xuggle Aurellem video capture
 * Showcase of recorded videos
 I encoded most of the original JME3 Hello demos for your viewing
 pleasure, all using the =Capture= and =IsoTimer= classes.

Mercurial > cortex

comparison org/capture-video.org @ 280:301e91a6c2d1