Download Procedural Texture Generation: Synthesizing and Randomizing Textures and more Study notes Computer Graphics in PDF only on Docsity!
Procedural Texture Generation
We often generate textures procedurally
- synthesis from example textures
- randomized material models (e.g., marble, wood, granite, …)
- reaction–diffusion “chemical reaction”
- any other function we can imagine Closely related to procedural geometry synthesis
- and a lot of the techniques crossover
- see book by Ebert et al Texturing & Modeling: A Procedural Approach
Synthesizing Textures
How do we efficiently generate textures?
- a common approach is to photograph something real
- for example, photograph some brick & apply to our walls
- this is nice, but it’s limited — all walls have identical bricks Solution #1: Take lots of different photos
- works, but requires lots of storage Solution #2: Synthesize new brick textures
- start with an example of a given texture
- synthesize new textures which have similar overall look, but whose local features are distinct
- this is by no means a solved problem
Randomized Models
Randomized procedural texture models are quite popular
- start with some regular pattern
- add in a bunch of noise functions, at different frequencies
- Perlin’s noise function is a particularly popular choice
- he won an Academy Award for developing it
- used for both 2-D and solid textures (hypertexture)
Cool demos
- http://graphics.lcs.mit.edu/~legakis/MarbleApplet/marbleapplet.html
- http://mrl.nyu.edu/perlin/demox/Planet.html
Reaction–Diffusion Methods
Imagine that we have some “chemicals” in the plane
- they diffuse across space
- and they react with each other
- according to differential equations we make up This describes realistic animal patterns
- appears this may actually account for real stripe/spot formation
Demos of reaction–diffusion
- http://members.aol.com/_ht_a/jiweichsel/wr3.html
- http://www.ccsf.caltech.edu/ismap/image.html
Generating Textures on Arbitrary Surfaces Using Reaction-Diffusion Greg Turk, SIGGRAPH 91.
One Basic Algorithm
(Wei & Levoy SIGGRAPH 2000) Initially fill with random noise Scan over pixels p in scanline order:
- Collect neighborhood of p
- Find all similar matches in input
- Copy pixel from one of them
raster scan order
input sample
Some Sample Results
Image-Based Rendering
The traditional approach to rendering is geometric
- produce a geometric model of surfaces
- formulate models for reflectance But as we’ve seen, images play a big role in rendering too
- texture mapping is critical for realistic looking scenes
- environment mapping gives us (fake) reflections
- shadow maps allow us to apply shadows to the surfaces How far can we get with image-based representations alone?
- surprisingly far
- synthesize arbitrary views of a scene from select images
2-D Imaging Analogy
Suppose we have a given raster image (of a rubber duck)
- and we want to create a new image with the duck rotated
- how would we do this?
By transforming and resampling the pixels
- for each pixel in the destination image
- calculate corresponding part of the original image
- take that color and fill in the new pixel
Viewing Geometry
Suppose we have two different views of the same scene
- for each, we have a mapping from world space to screen space
- these are represented as 4x4 homogeneous matrices
P 1 P^2
Transforming Between Views
Inverting a transform maps from screen space back to world space
- the proper composition maps from screen space 1 to screen space 2
P 1!^1 P^2
P 2 P 1!^1
View Resampling
This tells us how to resample existing views into novel ones
- compute the world-to-screen transformation for new view
- select some collection of the pre-recorded views
- for each pixel in a pre-recorded view
- take it’s screen space coordinates ( x , y , z )
- transform to screen space of target view ( x’ , y’ , z’ )
- color in pixel and fill in depth value at this location To do this effectively, need to address a couple of problems
- how do we prevent holes in the target image?
- we loop over pixels in the source image
- are we guaranteed to touch every target pixel? no.
- how many pre-recorded views do we need to resample?
- the more views the fewer holes, but the more processing time
Image-Based Rendering:
Rendering With Pixels Alone
We want to completely capture the appearance of a scene
- from any viewpoint
- by storing color samples only By considering a higher dimensional space, we can do that
- for every point in space [3 dimensions]
- for every incoming direction [2 dimensions]
- store the light energy arriving at the point from that direction
- call this a light field (or a lumigraph)
- can also think of it as a representation of ray space Obviously this can get very large very rapidly
- it’s a 5-D table of RGB colors
Light Field Demo
IBR Benefit: Photorealism by Default
Photorealistic reproduction of real scenes is hard
- must model all the geometric complexity of surfaces
- and their complex reflectance & texture properties
- and the transport of light in the scene
- and various optical effects
- and a lot more … Image-based models are photorealistic by construction
- we take photos of the real world
- and we use them to reconstruct images of the original scene
- no further simulation or modeling is required
IBR Benefit: Fixed Processing Cost
The cost of rendering a scene is fixed
- independent of scene complexity
- only depends on resolution of image samples
- this is in clear contrast to geometric models
Potentially allows for output sensitive rendering
- rendering time dependent only on output resolution
IBR methods can often be used without hardware acceleration
- can run at acceptable rates with software-only implementation
- indeed, this is one of the original motivations for such methods
What Can’t We Do With IBR
Any kind of dynamic scene
- assumes lighting conditions are constant & nothing is moving
- difficult to edit image-based scene once created
Simulation that requires geometry (e.g., collision detection)
Can’t always support view-dependent phenomena
- for example: view resampling gets specular highlights wrong
Doesn’t always look truly 3 dimensional
- panoramas (QuicktimeVR) look flat
