l e v e l - o f - d e t a i l

The animations on this page demonstrate the support offered by RenderMan for level-of-detail (LOD). Three models of a gumball seed were made in Maya/ZBrush. Using LOD the renderer chooses the appropriate model to use based on the area of screen space occupied by the model.

This image shows my progression of modeling the gumball seed. First, I created a simple base mesh
in Maya by converting a Sub-D sphere to polygons so that there would only be quads. (ZBrush hates triangles.) 
After importing the mesh into ZBrush, I created polygroups for my extrusion areas. These would later turn into 
the seed's "beaks." The center model shows the model after the extrusions and with some slight pinching and 
pulling. After that, I subdivided the mesh three times and began to sculpt the polygons to form the Hi-res 
model on the right, which ended up being 24,128 polygons.
			

After creating my Hi-res model in ZBrush, it was necessary to delete edge loops until my models
satisfied the polygon restrictions for the project. The Lo-res model needed to be <= 200 polys,
Mid-res <= 3500 polys, and the Hi-res <= 15,000 polys.  I originally applied a displacement map to 
my lo-res, rounder gumball but found that pulling a few vertexs out created a better, sharper look 
that transitioned better with the other models. The animation to the right shows the models being 
rotated in Maya.
			

This image shows the three models textured with the same 1024x1024 tiff file created in ZBrush. 
Each model has very different topologies so I needed to find a way to UV transfer without going 
through the tedious process of re-UVmapping each model. (Hindsight's 20/20, I should have mapped 
my original 24k poly model before reducing the poly count!) Luckily I found out that Maya 8 features 
a mesh > transfer attributes function that did the trick.
			

This image shows how the different models will be swapped out. This is determined by the pixel
area each model covers when rendered. As you can see, my mid-res model is used the most to balance
appearance quality and render time efficiently. Since the mid-res is very similar to the hi-res,
I only use the hi-res model when it is very close to the camera. The lo-res is swapped out very 
early because it doesn't match the other models as well, and I didn't want any "popping" effects. 
Yellow was used to shade the lo-res because it shows up the best on darker backgrounds. The green 
and red shades were arbitrary because I wanted to get away from always using blue in my work.
			

This was the code that determined how the models would be swapped out:
			
			
AttributeBegin
	Detail [-.5 .5 -.5 1 -.5 .5]
	Color 1 1 0
	DetailRange [1 1 500 1000]
	ReadArchive "M:/Maya/projects/default/archives/loresgumballcomplete.rib"
	

	Detail [-.5 .5 -.5 1 -.5 .5]
	Color 1 0 0
	DetailRange [500 1000 50000 65000]
	ReadArchive "M:/Maya/projects/default/archives/midresgumballcomplete.rib"


	Detail [-.5 .5 -.5 1 -.5 .5]
	Color 0 1 0
	DetailRange [50000 65000 400000 400000]
	ReadArchive "M:/Maya/projects/default/archives/hiresgumballcomplete.rib"
AttributeEnd
			
			

Click here for a Hi-res version
			

This animation shows exactly when each model is swapped out. I originally had a LOT more 
geometry flying at the camera, but clutter became an issue as well as render times. I 
settled for just two emitters that shot out 3 gumballs per second. My original idea used
four emitters that each created 5-10 gumballs per second. Unfortunately a lot of the models
penetrated each other's geometry to form confusing "masses." To get believable collision
detection, render times increased drastically. That concept was probably overkill for this 
project, but it was fun simulating it!
			

Click here for a Hi-res version
			

Since all the gumballs are shaded white, this animation tests the believability
of the geometry swap. To be considered a success, the viewer shouldn't be able 
to tell when the geometry is changed. I have tried to minimize any "popping" 
effects.
			

Click here for a Hi-res version
			

This animation was one of those exercises that made me pull my hair out over a
small mistake. After a lot of trial and error, I found out two details that were
necessary to show the textures on my models. First, I needed to put the .tx file in the 
same folder as my referenced .rib files. Second, I needed to change my "combo" parameter
to "texmap". It drove me crazy because the test scene rendered fine when using cutter,
but the textures didn't show when using Maya. Luckily our class webpage has tons of 
useful documentation. As a side note, I added motion blur.
			

	
The image on the left shows the helix geometry used for the particle paths.
I could have used spline curves, but I wanted to explore particle dynamics 
considering what I want to accomplish for my thesis project. This project was
my first attempt at using particle systems. The animation on the right has the 
geometry hidden and shows the proxy objects being animated by the particle system. 
I originally had the gumballs bouncing off the geometry within the tubes, but when 
it came time to render, the lack of fluid motion made it look like a jagged mistake 
rather than an intentional, dynamic effect.
			

This last image shows an alternate path I could have taken for this project. I attached a particle
emitter to the path hoping I could spell out "SCAD" with the gumballs. The effect wasn't particularly
interesting so I scrapped it early on.