3/31/2016 Note: if you don’t notice camera, then it is working well! “An ideal virtual camera system, regardless of genre, is notable by the lack of attention given to it by the viewer” Advanced Camera Control From Introduction to: M. Haigh-Hutchinson, IMGD 4000 Real-Time Cameras: A Guide for Game Designers and Developers , Morgan Kaufmann 2009 . Original source: Phil Wilkins (Sony Playstation Entertainment). “Designing and Implementing a Dynamic Camera System”, Game Developer's Conference , San God of War 2 trailer https://www.youtube.com/watch?v=GjYbK_-w9pM Francisco, CA, USA, 2008. Camera Objectives Overview • Flexible and designer driven • Zoning – deals with use of spatial database to – Allow game designer to provide player experience select “right” camera from variety of perspectives • Dynamics – calculations for a single, dynamic • Smooth camera – No jarring transitions • Blending – smooth out transitions between • Not require player intervention cameras – Player should not have to manually adjust camera to see game • Rails – constraining camera to path • No collision – Designer must constrain so doesn’t go through walls Zoning : Design Zoning : Objectives A • Have multiple stationary cameras – Cameras in fixed location A • Chosen by player position Select camera – Active camera is based on where player is from database based on player zone • Design so that cameras can “cover” where B location. player is If move across border, will • Switch automatically to right camera “toggle” between B cameras. 1
3/31/2016 Zoning : Design Zoning : Design A A A A Non- Alternative is overlapping overlapping zones . zones. When enter Switch to overlap, switch camera when player ENTERS to new camera zone. B Provides hysteresis. But may not B B “cover” all areas well B Zoning : Implementation Zoning : Implementation A A Camera A Camera A B B C C Camera B Camera C Camera C Each frame, query spatial DB and get cameras. Assume unordered (don’t want assumption A B C about underlying db) If simply switch to new camera, will toggle between A and C every frame. Zoning : Implementation Zoning : Implementation • Submission List A Query Submission – List of all cameras that were submitted last Result List frame B B A A C – Used to distinguish newly submitted cameras C from old ones – New cameras inserted at top B • So, effectively sorted by age • In this example, player moves from A, to C, to B. C • If then to just C, top A B C entry would change. 2
3/31/2016 Zoning : Implementation Zoning : Implementation A A Query Submission Camera A Result List Priority 1 B B A A C Provide priority for more important (higher priority) camera when overlapped. C B Camera B C A B C Priority 2 B Priority 2 2 1 Zoning Implementation Outline • Submission List (with priorities) • Zoning (done) – Insert and delete entries to match • Dynamics (next) query results • Blending – Unless query result was empty • Rails – Sorted by priority – Then by age – Top entry is active camera Dynamics : Objectives Dynamics : Design • Camera impacts 3 properties of avatar as it appears on screen Define “safe zone” (rectangle) – Position – where camera is focused impacts where on on screen where player screen avatar appears (e.g., center? bottom right?) avatar will be. • Make these resolution – Size – how far away camera is impacts how big avatar independent (represent screen, not pixels) appears (e.g., takes up full screen, takes up tiny portion) Note, can be “point” if player always there. – Angle – angle of camera from avatar orientation impacts what representation avatar has (e.g., profile? When avatar oustide of zone, move camera. How? top-down?) 3
3/31/2016 Dynamics : Design Dynamics : Design • Player position and viewing angle depend upon angle between • Instead, calculate angle relative camera and player camera location (black lines) • Specify angle viewing player from as fixed value • Only move camera if angle greater than constraints (blue lines) • But result will be camera moves around lots (background � Camera will move less moves) � can be disconcerting • This is like “high water mark” and “low water mark” in algorithms Dynamics : Design Dynamics : Design Allow designer to set range of valid distances for camera. Control size of player on screen, by controlling distance from camera to player. 5 metres Camera never gets too far from, or too close to, player. Minimum Maximum Similar to angle, often don’t want as fixed value (see next slide). Dynamics : Outline SUMMARY: Let designer control: position of player on screen Implementation angle looking (orientation of camera) size (distance from camera) • Zoning (done) • Dynamics (done) Angle to • Blending (next) World Angle to • Rails Target Distance Target to Target Plane Position 4
3/31/2016 Timers : Design Blending : Overview A • Blending – smooth out transitions between cameras A • Three aspects: When start new camera, – Timers – track and update each blend don’t immediately cut to it, but blend into it over – Ease – controls the smoothness of blend B fixed period of time. – Blend Space – defines what a blend between two cameras does B Timers : Design Timers : Implementation A • Don’t actually blend • Timer List pixels • Rather, create third A – Entry is camera fading in camera from varying proportions of other – New timers inserted at top two cameras – Camera can have multiple timers in list A+B • Moves from first camera to second • This happens if player moves quickly between B • Position and cameras orientation determined by blend – First-In, First-Out (FIFO) of two cameras • Driven by timer – When timer completes, all timers below it are (started when new B removed camera activated) Timers : Implementation Timers : Implementation In this example, player moves from A, to C, to B and back to C. A 1/1 Start at bottom (oldest). C 1/3 B 2/4 A Blend in new camera (higher Timer 1/2 B + 1/2 C on list) based on timer fraction. Submission List Timer List List B B ? C A C 1/3 C 1/3 1/3 C + 2/3 (3/4 B + 1/4 C) B 3/4 Zone A: list empty, start camera A Zone C: starts new timer, camera is blend of A and C Zone B: start new timer, camera is blend of A,B and C 3/4 3/4 B + 1/4 C Camera C’s timer done, so drop camera A C 3/3 Back to Zone B: start new C timer top (C in list twice) Camera B’s timer completes, drop C timer below Camera C’s timer completes, drop B below At C 100% A B C 5
3/31/2016 Ease : Design Ease : Implementation http://cubic.org/docs/hermite.htm • Hermite Spline • Using as-is, get simple linear blend – Used to smoothly interpolate between key- (see sharp corners in picture) • When use to blend cameras, see points (e.g., camera A to camera B) jerk when starts to move and stops � Can be ugly • Fixed endpoints at P1 & P2 • Controllable tangents • ease = [0 , 1] – 0 means no ease (linear) • Want what animators call “ease” – 1 means full ease � Feed linear blend into spline • Ease-in from P1 tangent, and Ease-out from P2 tangent Blend Space : Design Ease : Implementation If blend positions along straight line, will get “zoom” effect. B 3/4 Ease (3/4, ease, 3/4 C.easeIn, B.easeOut) C 3/3 Apply Ease() when calculate blend factor between two cameras ease from 0 to 1 easeIn from old camera (C) Instead, blend along arc, fixed easeOut from new camera (B) distance from player. Outline Rails : Objectives • Zoning (done) • Dynamics (done) • Blending (done) • Rails (next) Want camera on a track � idea borrowed from film industry. Construct rails, put camera on little cart (a “Dolly”). 6
Recommend
More recommend
