67535 Computer Games Programming Me Mark Shovman qwerty

67535: Computer Games Programming Me: Mark Shovman – qwerty @ cs – mark. shovman @ gmail – Meetings by appointment – Everything is on Moodle You: –Programme/year? –CG/Im. Pr/CV? –Which games do you play?

Games Many definitions, even a separate science: ludology Crucial: Aim of a game is fun many, many kinds of fun

Computer Games Art + Craft + Science + Business Core team: Hacker + Hipster + Hustler

Computer Games Programming –AI –UI –Networks –Databases –Computer Graphics –Languages (LUA) • The aim is fun –Visual WOW –Not realism, but believability • The challenge is FPS

Plan for the year Procedural content generation Post-processing Shadows Rigid and soft bodies Particles and liquids Animation Volumetrics UI and Camera Sound and music

Coursework 4 Assignments x 20% • Procedural Content • Light and Postprocessing • Particle Systems • Physics Final coursework (30%) • A game-inspired interactive 3 D scene • You decide what to do and present during the tutorial before you start NB: Total is 110 NB: Late submission without good reason: -5 pt

Prerequisites Computer Graphics or talk to me after 0 -2 0 0 -1 0 0 2 -1

Computer Graphics reminder Aim: render World Model to Image –Quality Criterion: So that Human Visual System would reconstruct the World Model from that Image Similar Fields: –Computer Vision: I -> WM (Automated) –Image Processing: I -> I –Simulation: WM -> WM –Vision Research: I -> WM (Human and Animal)

Rendering pipeline World model triangle meshes defined by vertices Point of view: camera Light sources Etc. Image: matrix of pixels (colours)

Shaders Aim: customising the rendering pipeline with unique visual effects 1999: Parts of the pipeline are made programmable First target of customisation was shading algorithms hence shaders 2010: Unified shader architecture: fully customisable pipeline.

Programmable pipeline v 1

Programmable pipeline v 2

Programmable pipeline v 3

Vertex shader versions Vertex shader version VS 2. 0 a VS 3. 0 VS 4. 0 Instruction slots 256 ≥ 512 4096 Max # of instructions executed 65536 Instruction predication No Yes Yes Temporary registers 12 13 32 4096 Constant registers ≥ 256 16 x 4096 Static Flow Control Yes Yes Dynamic Flow Control No Yes Yes Dynamic Flow Control Depth No 24 24 > Vertex Texture Fetch No No Yes Texture samplers N/A 4 128 Geometry instancing support No No Yes Bitwise Operators No No No Yes Native Integers No No No Yes (from Wikipedia. org)

Vertex shader command set NOP MOV d, s move MUL D, s 1, s 2 Component multiply ADD D, s 1, s 2 Component add MAD D, s 1, s 2, s 3 Component multiply (s 1, s 2) and add (s 3) RSQ D, s Reciprocal square root DP 3 D, s 1, s 2 Dot product (3 component) DP 4 D, s 1, s 2, Dot product (4 component) DST D, s 1, s 2 Attenuation vector calculation LIT D, s Calculates phong lighting MIN D, s 1, s 2 Component minimise MAX D, s 1, s 2 Component maximise SLT D, s 1, s 2 Component less than SGE D, s 1, s 2 Component greater or equal EXP D, s. w exponent LOGT D, s. w logarithm RCP D, s. w reciprocal

Shader languages Originally, and until recently: assembly First and still best for non-realtime rendering: Render. Man Real-time: • GLSL • HLSL aka Cg • Cuda

Procedural Modelling l

What is “Procedural modelling”? l Creating game content using an algorithm rather than artwork Benefits l l l l Small set of parameters instead of many models Saves development time (only for lots of content) More naturalistic (with the right algorithm) Infinite variation of content: REPLAYABLITY Drawbacks l l l Lack of artistic/design control Takes time to generate Takes up development time

What can be procedurally generated l Models Textures Terrain, Buildings, cities Plants Groups of objects: forests, herds, crowds etc. Animation Music Other content Level layouts World history and politics Names for places, people, animals; even languages

Terrain generation l

Terrain generation l It is virtually impossible to generate terrain based on (fully deterministic) natural geological processes. l l l Tectonic Activity Weathering Sedimentation X billions of years Our techniques bear SOME semblance to the natural process. So long as it ‘looks’ like what we want. How we get there does not need to resemble reality. Just needs to run fast and look great! l

Terrain elevation map l Terrain as a grid of vertices on the XZ axis The height for any given point is the Y-value of the vertex Only the height values and the grid size need to be stored

Try I: Random Heightfield l Random height Fast and easy Generates spiky and unrealistic terrain. Small amount of random ‘noise’ can spice up other landscapes and provide fine detail l l Smoothing Generates unremarkable and repetitive terrain Can be used with other algorithms to emulates weathering l l

Faulting l Emulates geological activity l Algorithm l l Randomly divide landscape into two pieces using a line. Raise one half and lower the other Repeat recursively [with a smaller faulting value] Produces very nice looking terrain But requires a large number of iterations l l

Particle Deposition l Models lava flow, ash, snow, etc. Algorithm l l Drop particles over the surface of the terrain Let them ‘roll down’ until everything around is at the same or higher level Each time a particle lands, it raises the terrain. l l l Generates volcano- like structures l

Particle Deposition Techniques l l A single drop point will create a single large structure Many random drop point will create several features. Dropping other features onto the landscape Impact craters River-makers Forests Glaciers l l

l l Mid-Point Displacement 2 D Algorithm l l l Subdivide segment in half. Add a random offset to the new point Repeat on newly created sections. Usually reducing the offset l l 3 D Algorithm (Diamond-Square) l l l Square step: height for point e Diamond step: height for points f, g, h, i Repeat process for new squares

Procedural plant life

Simulating Plant Life May elements in nature show self-similar properties Plants / Trees / Leaves Mountains River Deltas Coastlines Fractal techniques can be used to model these elements

L-Systems Introduced by biologist Aristid Lindenmayar Mathematical grammar used to describe a self-similar system through the use of production rules Can be used to generate and render many natural features

Symbols Production rules control an alphabet of terminal and non- terminal symbols (e. g. F, X, +, -) For example: (A → AB), (B → A) F → F+F--F+F

Axiom and Iterations The L-System is seeded with an axiom The axiom is an initial string to which the production rules will be applied For example, using the single character F: F F+F--F+F+ F+F--F+F--F+F+ F+F--F+F

Symbols have a geometric meaning, for example: F: Move forward +: Rotate 60° anti-clockwise -: Rotate 60° anti-clockwise

L-Systems for Flora Branching is a key feature of most plant life Introducing save / restore symbols [ : store the current position / orientation ] : restore the last state Produces branched structures Similar tree traversal to depth-first searching Through iteration we can produce 2 D geometry which starts to resemble a plant or tree’s structure

Branching Example: Using the single production rule: F → F[+F]F[-F]F

Extension Into 3 D Symbols can be added to control rotation in three dimensions Roll(, /), pitch(^, &) and yaw (+, -) • F → F[&F][&/F][&F] • Use cylinders instead of lines to render in 3 D

Stochastic L-Systems Many L-Systems are very regular, nature isn’t Vary the magnitude of a symbol’s meaning by a pseudorandom amount Or implement probabilistic rules: F (0. 7)→F[+F]F[-F]F F (0. 3) →FF[-F][--F]F

Parametric L-Systems Add parameters to symbols, e. g. length or angle Change parameters in rules: F(3) →F[+F]F[-F]F Have conditional rules based on parameters: F(x): x<3 →F(x+1)[-F(x)]F(x+1)[+F(x)]F(x)

Further Detailing Consider: Branch strengths / weights Effects of gravity / wind Latitude / orientation Evolution of L-systems

Better Trees

Forest http: //www. gamasutra. com/view/feature/130071/random_scattering_creating_. php Random placement overlap Random with replacement if too close slow Random walk from a grid Unrealistic fast and looks good Mass-spring relaxation Better-looking than previous but slow

Forest of different trees Repeat random With replacement for several tree sizes

Further Applications of L-Systems Road networks Buildings (see parametric LSystems) Rivers / deltas

Exercise 1: Roam the Earth WASD camera movement Bonus for Q/E leans, SPACE jumps etc. Procedural generation –One of the techniques taught today: –Terrain (faulting, particles or midline) –L-system tree Deadline: Wednesday, March 18 th, 10 am –Late submission: by agreement or 5 pt penalty

Computer Graphics surgery: vertex transformations From ‘vertex in the world’ To ‘vertex on screen’

Coordinate system Describing space with numbers l Position l Orientation l Force l Movement Most common way – Cartesian coordinates Coordinates are relative to an origin and axes Different origin and axes – different coordinates for the same object

Cartesian 3 D base PS 2 Framework and Open. GL use Right Handed Direct. X mainly uses Left Handed (can use Right Handed)

Coordinate Systems Many coordinate systems used to define a scene • Local Space and World Space (actually a hierarchy) • View Space • Screen Space

Matrix Transformations Translate coordinates between spaces Primary types of transformations: • Translation • Rotation • Scaling • + Projection

Homogenous Coordinates [x y z w] is equivalent to [x/w y/w z/w] in Cartesian For simplicity, w = 1 so [x y z] is equivalent to [x y z 1] What about w=0? [x y z 0] describes a point in infinity along the line defined by [x y z]. Sometimes useful. Can represent Translation as a matrix transform

Shearing (rarely useful) Shears object by manipulating it relative to one of its axes. Vertex is moved by a distance that increases linearly with its distance from the z axis (z-shear).

Concatenation Complex transformations can be obtained by combining primary transformations –e. g. Arbitrary axis rotation The order of concatenation is important Proper or improper use of concatenation can greatly affect application performance.

Local Coordinates or Model Space Model is defined in its own coordinate system Vertices defined relative to a local origin 3 D modelling package generates objects in model space

World Coordinates or World Space Model is placed in world space – this is the coordinate system of our virtual environment. Model generally undergoes rotation and translation transformations when moving from local to world space. Order of transformation application is important.

View Space Virtual camera placed in world Camera has position and orientation Vertices in world space are transformed so that camera position becomes the origin View transformation is generally a translation followed by a rotation

View Space Infinite view is restricted by a view volume (Frustum) View volume restricted by near and far clipping planes and the sides of the frustum. “Viewer” looks along positive z axis (Direct. X) of the camera Objects outside frustum should be rejected. Objects inside frustum require further processing. Diagram shows righthanded (open. GL and PS 2) system

Screen Space Viewport transformation generates Screen Space Clip space screen of dimensions 2 x 2 is mapped to the physical screen dimensions (w x h) of the frame buffer z coordinate is scaled to the resolution of the z-buffer for sorting and hidden surface removal

Vertex transformations Vertex coordinates are given in an Object/Model coordinate system 1. Model→ World (World transform) 2. World → View (View transform) 3. View → Image Plate (Projection transform) 4. Image Plate → Window (handled by window system) The transforms are kept and updated separately, and are combined before rendering into the WVP matrix

Projection and Screen space 1. World • Object position 2. View • Camera position 3. Projection • Frustum 4. Culling • L/R, T/B &N/F planes 5. Screen space • Window resolution (pixels) • Z-buffer resolution (depth levels)