motion blur
November 16th, 2005 by BramzYou can’t properly render fast cars without motion blur, can you? Motion blur is something that’s already in LiAR’s feature set for some time, so I tried it out on the triangle mesh. And here it is …*drumroll* …
This is a scaled down/cropped version of a 2000×1500 image with 16 samples per pixel. This roughly agrees with 256 samples per pixel in the image being displayed.
Adding motion blur to a ray tracer is actually pretty easy. You add an shutter opening and closing time to the camera, and to each sample being rendered you assign a time stamp. You pick these time stamps at random from a uniform distribution between opening and closing time. You also must have a special scene object which applies a time dependent translation to the object to be moved. When you check for intersection, you simply apply the correct translation with respect to time.
In LiAR, this special scene object is called MotionTranslation and is able to apply a linear non-accelerated motion to a child object. It takes a child object, an initial position and a velocity vector as arguments.
There’s also one extra aspect that has to be taken care of: bounding boxes. Many acceleration techniques use bounding boxes to simply a object. And since this is better time independent, you must take care that the bounding box bounds all possible positions of the object (you don’t want to build that AABB tree for each time stamp being sampled, do you?). For a linear non-accelerated motion this is pretty simple: you simply join the bounding boxes of the models at opening and closing time. If you want to take acceleration into account as well, you must take care of other extrema that can be in between …
Oh, btw, obviously the car is moving forward ;)
November 16th, 2005 at 5:25 pm
Nice motion blur. You should make us an animation ;-)
November 22nd, 2005 at 12:01 am
ingo wald has published some good info on rendering animated scenes, distinguishing mostly between structured and unstructured changes in scene geometry, the latter obviously requiring a rebuild of the object’s spacial subdivision structure.
isn’t bounding both the start- and end-time bounds of a moving object a lot worse than just lerping between them? i think rebuilding the meta-hierarchy (where one needs proper obb/aabb testing- any inefficiency there is very costly) for bounded time intervals, perhaps based on some “total scene change” metric, might be a good approach since it supports arbitrary mappings from time to orientation/offset.
finally, i think it’s very cool that you have temporal integration in liar; it’s a fundamental feature to include, and to spec it early on is exactly right :)