vSprites
|
|
|
 |
|
|
Answer: When large numbers of highly detailed objects (many thousands) are in a scene, pre-rendering can offer very efficient render times. An equivalent scene with as many objects in it - Paint Effects or geometry - with shadows - could require more than 10 times as long to render. Other solutions have their own imitations, listed below as well.
|
|
| Possible techniques... | ....and their problems. |
| Maya Paint Effects. |
Works great for a few hundred in a single frame. But with shadows (raytraced or depth), over 3,000 bushes, for 3000+ frames, I think the render time was not even worth bothering to address. Plus, you'd have all this computation going into all these Paint Effects strokes, most of which would affect at most a pixel or two in the image. Also, even with Paint Effect's efficiency of display, having 100,000 paint effect bushes in a scene would still make the scene very bulky. The final nail in the coffin, as usual with Paint Effects, is the need for motion blur, which is pretty much out unless you're willing to "fix it in post" and comp it. vSprites: |
| _ | |
| Particle Sprites. |
Simple and efficient,
but liable to the "twisting" artifact - sprites rotate around
their center. With all these bushes spinning it would look
like a low grade arcade game. |
| _ | |
| Crosshatched Planes |
This would
work if the camera wasn't moving much, and shadows could be
simulated with a piece of geometry serving as the floor. But
with the animation of the camera, the structure of the few
surfaces would be viewed edge-on for at least some bushes all
the time...again more low low-grade arcade game feel. vSprites: Since each object is pre-rendered in full, there is no lack of detail on the object from any angle. |
| _ | |
| All of the above | All the
techniques above fail to optimize geometry or texturing as a
function of distance from the camera - an object 10,000 units
away has just as much detail as one of 10 units distanc, and
takes just as much render time. vSprites: vSprites can reuse texture maps as a function of distance from the camera. This way objects very far from the camera don't need to be re-rendered each frame. |
| _ | |
| All of the above |
All the techniques
above fail to optimize the geometry in the scene to be only
that which is within the camera field of view. The memory
footprint for a valley filled with bushes would be
overwhelming, and most of it unused at any one frame render. |
| |
|
|
|
Ideally, the camera would never know the plant (or any object) was never really there. My initial approach attempted to render every object every 10 degrees of change, and then snap or interpolate as the camera view swept inbetween these ranges. As technically interesting as it was, the visual artifact wasn't acceptable. So, like most people writing scripts, the I redesigned a second time, making vSprites render each object from the relative camera position fresh each frame. This works, but results in a bit of overkill for each frame being rendered - the relative change in angle for the majority of objects was too small to be noticed. So I added a distance requirement to the updating of any vSprite - only objects close enough to the camera to exhibit parallax would be re-rendered. This results in a one-time up front slow first frame render (as all the vSprites are rendered) , but each incremental frame gets completed very quickly as only the few that are close to the camera need to updated. Benefits: 1. Fun to write!
uhhhh. Yeah! Really! Detriments: Initial frame of a
sequence takes over an hour to create and pre-render the
initial set of textures. But that's 1 hour, one time startup
cost for all subsequent (1000's) of frames. |
| Implementation: |
A quick overview of the vSprite architecture as it currently stands: - A mel script vSprites is added to Maya's "Pre-Render MEL" render globals. "vSprites nameOfCameraToBeRendered" - This script
verifies the camera to be rendered, and ensures all scene
prerequisites exist (if not it makes its own default on the
fly). This includes Closest point on surface nodes for camera
field of view determination. - vSprite transforms
are captured via mel an put in an array. The array is saved to
a file - so for scenes where the vSprites don't move, the
transform capture occurs only once. Subsequent frames rendered
simply read in the file if it already exists. - vSprite array data
are parsed to determine their field of view in the camera,
size, render resolution, creation, update, or delete status. - vSprite array data
are processed - adding vSprites to the scene, updating them,
or deleting them as necessary. When vSprites are added, their
file-based texture shader networks are created, but the source
files for them don't exist.... yet. - vSprite array data
are saved to a new handoff file. This is just a binary file
written out from Maya via mel containing relative camera
positions and bush item attributes. - vSprites then
launches another instance of Maya in prompt mode. This
instance of Maya reads in the handoff file, creates a camera,
imports in all the object geometry types to the origin (in
this case a bunch of different paint effect based bushes), and
then keyframes the camera to all the relative positions from
the objects as exists in the parent scene. This Maya file is
then saved, and this instance of Maya in prompt mode quits. - vSprites then
renames all the rendered images from the batch render above to
the appripriate texture file names for the textures to be
matched up in the parent Maya scene. Here is the current list of mel for vSprites. It looks scary, but it all works by simply adding the one line to the render globals mentioned above. vSprites.mel
|