Time is broken #799
Comments
hollasch
added a commit
that referenced
this issue
Nov 7, 2020
This ends up running into the time problem in our code. To be fully implemented, we'd have to revisit scene time for all three codebases, as well as update the books. This is probably a dead-end, as we need to address time management at a higher level (#799).
This was referenced Dec 14, 2020
|
See also #654, which also includes more thoughtful discussion. |
hollasch
added a commit
that referenced
this issue
Feb 3, 2021
The current design of render time intervals is incomplete, so we've decided to scale this back. Time will be mangaged only by the camera (by specifying ray time), and by objects that respond to time (moving sphere). See #799
hollasch
added a commit
that referenced
this issue
Feb 8, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
There are a bunch of different angles to illustrate this, but here's the most clear. The animation-handling code in The Next Week samples rays randomly over a period of time in the world. In addition, primitives like
moving_sphereare defined to have their centers specified over a time period.Unfortunately, we use variable names like
time0,time1,time_start, andtime_end, which are ambiguous, and are used interchangeably to refer to the scene period and the primitive period. These should have been named something likescene_start,scene_end,sphere_start,sphere_end, and so forth. If you start renaming things like this, the cracks in the current implementation become very apparent.We need to figure out how to resolve all this. I am inclined to hard-code the assumption that the scene will be sampled in the time interval [0,1], and primitives should be written to assume that. The entire intent of sampling in time is to illustrate things like motion blur, and the above is certainly sufficient for that.
The text was updated successfully, but these errors were encountered: