ࡱ> "Y G bjbjWW g ==: =]       4B B B B h F4B N&n2$Y:Y:Y:YZ|L-%M>M>M>M>M>M$OQbM <ZZ<<bM_C  :Y:Y&_C_C_C<X :Y :Y_CF64L  0M :Yz#<@B B BMPersistence of Vision "! Ray-Tracer POV-Ray "! Version 3.1g User's Documentation May 1999 Copyright 1999 POV-Team "! POV-Ray "! is based on DKBTrace 2.12 by David K. Buck and Aaron A. Collins. POV-Ray, POV-Help, POV-Team, and Persistence of Vision are trademarks of the POV-Team.  TOC \o "2-6" \t "Heading 1,1" 1 Introduction  PAGEREF _Toc449869233 \h 10 1.1 Program Description  PAGEREF _Toc449869234 \h 11 1.2 What is Ray-Tracing?  PAGEREF _Toc449869235 \h 11 1.3 What is POV-Ray?  PAGEREF _Toc449869236 \h 11 1.4 How Do I Begin?  PAGEREF _Toc449869237 \h 12 1.5 Notation and Basic Assumptions  PAGEREF _Toc449869238 \h 12 1.6 What's New in POV-Ray 3.1?  PAGEREF _Toc449869239 \h 13 1.6.1 Media Replaces Halo & Atmosphere  PAGEREF _Toc449869240 \h 13 1.6.2 New #macro Feature  PAGEREF _Toc449869241 \h 14 1.6.3 Arrays Added  PAGEREF _Toc449869242 \h 14 1.6.4 File I/O and other Directives  PAGEREF _Toc449869243 \h 14 1.6.5 Additional New Features  PAGEREF _Toc449869244 \h 14 2 Beginning Tutorial  PAGEREF _Toc449869245 \h 16 2.1 Our First Image  PAGEREF _Toc449869246 \h 16 2.1.1 Understanding POV-Ray's Coordinate System  PAGEREF _Toc449869247 \h 16 2.1.2 Adding Standard Include Files  PAGEREF _Toc449869248 \h 17 2.1.3 Adding a Camera  PAGEREF _Toc449869249 \h 18 2.1.4 Describing an Object  PAGEREF _Toc449869250 \h 18 2.1.5 Adding Texture to an Object  PAGEREF _Toc449869251 \h 19 2.1.6 Defining a Light Source  PAGEREF _Toc449869252 \h 19 2.2 Simple Shapes  PAGEREF _Toc449869253 \h 20 2.2.1 Box Object  PAGEREF _Toc449869254 \h 20 2.2.2 Cone Object  PAGEREF _Toc449869255 \h 20 2.2.3 Cylinder Object  PAGEREF _Toc449869256 \h 21 2.2.4 Plane Object  PAGEREF _Toc449869257 \h 21 2.3 CSG Objects  PAGEREF _Toc449869258 \h 21 2.3.1 What is CSG?  PAGEREF _Toc449869259 \h 21 2.3.2 CSG Union  PAGEREF _Toc449869260 \h 22 2.3.3 CSG Intersection  PAGEREF _Toc449869261 \h 23 2.3.4 CSG Difference  PAGEREF _Toc449869262 \h 23 2.3.5 CSG Merge  PAGEREF _Toc449869263 \h 25 2.3.6 CSG Pitfalls  PAGEREF _Toc449869264 \h 25 2.3.6.1 Coincidence Surfaces  PAGEREF _Toc449869265 \h 25 2.4 Advanced Shapes  PAGEREF _Toc449869266 \h 25 2.4.1 Bicubic Patch Object  PAGEREF _Toc449869267 \h 26 2.4.2 Blob Object  PAGEREF _Toc449869268 \h 32 2.4.2.1 Component Types and Other New Features  PAGEREF _Toc449869269 \h 34 2.4.2.2 Complex Blob Constructs and Negative Strength  PAGEREF _Toc449869270 \h 34 2.4.3 Height Field Object  PAGEREF _Toc449869271 \h 36 2.4.4 Lathe Object  PAGEREF _Toc449869272 \h 38 2.4.4.1 Understanding The Concept of Splines  PAGEREF _Toc449869273 \h 39 2.4.5 Mesh Object  PAGEREF _Toc449869274 \h 43 2.4.6 Polygon Object  PAGEREF _Toc449869275 \h 44 2.4.7 Prism Object  PAGEREF _Toc449869276 \h 46 2.4.7.1 Teaching An Old Spline New Tricks  PAGEREF _Toc449869277 \h 47 2.4.7.2 Smooth Transitions  PAGEREF _Toc449869278 \h 48 2.4.7.3 Multiple Sub-Shapes  PAGEREF _Toc449869279 \h 49 2.4.7.4 Conic Sweeps And The Tapering Effect  PAGEREF _Toc449869280 \h 50 2.4.8 Superquadric Ellipsoid Object  PAGEREF _Toc449869281 \h 52 2.4.9 Surface of Revolution Object  PAGEREF _Toc449869282 \h 55 2.4.10 Text Object  PAGEREF _Toc449869283 \h 57 2.4.11 Torus Object  PAGEREF _Toc449869284 \h 60 2.5 The Light Source  PAGEREF _Toc449869285 \h 65 2.5.1 The Pointlight Source  PAGEREF _Toc449869286 \h 65 2.5.2 The Spotlight Source  PAGEREF _Toc449869287 \h 66 2.5.3 The Cylindrical Light Source  PAGEREF _Toc449869288 \h 67 2.5.4 The Area Light Source  PAGEREF _Toc449869289 \h 67 2.5.5 The Ambient Light Source  PAGEREF _Toc449869290 \h 68 2.5.6 Light Source Specials  PAGEREF _Toc449869291 \h 69 2.5.6.1 Using Shadowless Lights  PAGEREF _Toc449869292 \h 69 2.5.6.2 Assigning an Object to a Light Source  PAGEREF _Toc449869293 \h 69 2.5.6.3 Using Light Fading  PAGEREF _Toc449869294 \h 70 2.6 Simple Texture Options  PAGEREF _Toc449869295 \h 70 2.6.1 Surface Finishes  PAGEREF _Toc449869296 \h 71 2.6.2 Adding Bumpiness  PAGEREF _Toc449869297 \h 71 2.6.3 Creating Color Patterns  PAGEREF _Toc449869298 \h 71 2.6.4 Pre-defined Textures  PAGEREF _Toc449869299 \h 72 2.7 Advanced Texture Options  PAGEREF _Toc449869300 \h 72 2.7.1 Pigments  PAGEREF _Toc449869301 \h 73 2.7.1.1 Using Color List Pigments  PAGEREF _Toc449869302 \h 73 2.7.1.2 Using Pigment and Patterns  PAGEREF _Toc449869303 \h 73 2.7.1.3 Using Pattern Modifiers  PAGEREF _Toc449869304 \h 74 2.7.1.4 Using Transparent Pigments and Layered Textures  PAGEREF _Toc449869305 \h 75 2.7.1.5 Using Pigment Maps  PAGEREF _Toc449869306 \h 76 2.7.2 Normals  PAGEREF _Toc449869307 \h 77 2.7.2.1 Using Basic Normal Modifiers  PAGEREF _Toc449869308 \h 77 2.7.2.2 Blending Normals  PAGEREF _Toc449869309 \h 78 2.7.3 Finishes  PAGEREF _Toc449869310 \h 80 2.7.3.1 Using Ambient  PAGEREF _Toc449869311 \h 80 2.7.3.2 Using Surface Highlights  PAGEREF _Toc449869312 \h 81 2.7.3.3 Using Reflection and Metallic  PAGEREF _Toc449869313 \h 82 2.7.3.4 Using Iridescence  PAGEREF _Toc449869314 \h 83 2.7.4 Working With Pigment Maps  PAGEREF _Toc449869315 \h 83 2.7.5 Working With Normal Maps  PAGEREF _Toc449869316 \h 84 2.7.6 Working With Texture Maps  PAGEREF _Toc449869317 \h 85 2.7.7 Working With List Textures  PAGEREF _Toc449869318 \h 85 2.7.8 What About Tiles?  PAGEREF _Toc449869319 \h 86 2.7.9 Average Function  PAGEREF _Toc449869320 \h 87 2.7.10 Working With Layered Textures  PAGEREF _Toc449869321 \h 87 2.7.10.1 Declaring Layered Textures  PAGEREF _Toc449869322 \h 89 2.7.10.2 Another Layered Textures Example  PAGEREF _Toc449869323 \h 89 2.7.11 When All Else Fails: Material Maps  PAGEREF _Toc449869324 \h 92 2.7.12 Limitations Of Special Textures  PAGEREF _Toc449869325 \h 94 2.8 Using the Camera  PAGEREF _Toc449869326 \h 95 2.8.1 Using Focal Blur  PAGEREF _Toc449869327 \h 95 2.9 Using Atmospheric Effects  PAGEREF _Toc449869328 \h 96 2.9.1 The Background  PAGEREF _Toc449869329 \h 97 2.9.2 The Sky Sphere  PAGEREF _Toc449869330 \h 97 2.9.2.1 Creating a Sky with a Color Gradient  PAGEREF _Toc449869331 \h 97 2.9.2.2 Adding the Sun  PAGEREF _Toc449869332 \h 99 2.9.2.3 Adding Some Clouds  PAGEREF _Toc449869333 \h 100 2.9.3 The Fog  PAGEREF _Toc449869334 \h 101 2.9.3.1 A Constant Fog  PAGEREF _Toc449869335 \h 101 2.9.3.2 Setting a Minimum Translucency  PAGEREF _Toc449869336 \h 102 2.9.3.3 Creating a Filtering Fog  PAGEREF _Toc449869337 \h 103 2.9.3.4 Adding Some Turbulence to the Fog  PAGEREF _Toc449869338 \h 103 2.9.3.5 Using Ground Fog  PAGEREF _Toc449869339 \h 104 2.9.3.6 Using Multiple Layers of Fog  PAGEREF _Toc449869340 \h 105 2.9.3.7 Fog and Hollow Objects  PAGEREF _Toc449869341 \h 106 2.9.4 The Rainbow  PAGEREF _Toc449869342 \h 106 2.9.4.1 Starting With a Simple Rainbow  PAGEREF _Toc449869343 \h 106 2.9.4.2 Increasing the Rainbow's Translucency  PAGEREF _Toc449869344 \h 108 2.9.4.3 Using a Rainbow Arc  PAGEREF _Toc449869345 \h 109 2.9.5 Animation  PAGEREF _Toc449869346 \h 110 2.9.5.1 The Clock Variable: Key To It All  PAGEREF _Toc449869347 \h 110 2.9.5.2 Clock Dependant Variables And Multi-Stage Animations  PAGEREF _Toc449869348 \h 112 2.9.5.3 The Phase Keyword  PAGEREF _Toc449869349 \h 113 2.9.5.4 Do Not Use Jitter Or Crand  PAGEREF _Toc449869350 \h 114 2.9.5.5 INI File Settings  PAGEREF _Toc449869351 \h 114 3 POV-Ray Options  PAGEREF _Toc449869352 \h 116 3.1 Setting POV-Ray Options  PAGEREF _Toc449869353 \h 116 3.1.1 Command Line Switches  PAGEREF _Toc449869354 \h 116 3.1.2 Using INI Files  PAGEREF _Toc449869355 \h 116 3.1.3 Using the POVINI Environment Variable  PAGEREF _Toc449869356 \h 118 3.2 Options Reference  PAGEREF _Toc449869357 \h 118 3.2.1 Animation Options  PAGEREF _Toc449869358 \h 119 3.2.1.1 External Animation Loop  PAGEREF _Toc449869359 \h 119 3.2.1.2 Internal Animation Loop  PAGEREF _Toc449869360 \h 119 3.2.1.3 Subsets of Animation Frames  PAGEREF _Toc449869361 \h 120 3.2.1.4 Cyclic Animation  PAGEREF _Toc449869362 \h 121 3.2.1.5 Field Rendering  PAGEREF _Toc449869363 \h 121 3.2.2 Output Options  PAGEREF _Toc449869364 \h 121 3.2.2.1 General Output Options  PAGEREF _Toc449869365 \h 121 3.2.2.1.1 Height and Width of Output  PAGEREF _Toc449869366 \h 121 3.2.2.1.2 Partial Output Options  PAGEREF _Toc449869367 \h 122 3.2.2.1.3 Interrupting Options  PAGEREF _Toc449869368 \h 122 3.2.2.1.4 Resuming Options  PAGEREF _Toc449869369 \h 122 3.2.2.2 Display Output Options  PAGEREF _Toc449869370 \h 123 3.2.2.2.1 Display Hardware Settings  PAGEREF _Toc449869371 \h 123 3.2.2.2.2 Display Related Settings  PAGEREF _Toc449869372 \h 124 3.2.2.2.3 Mosaic Preview  PAGEREF _Toc449869373 \h 125 3.2.2.3 File Output Options  PAGEREF _Toc449869374 \h 126 3.2.2.3.1 Output File Type  PAGEREF _Toc449869375 \h 126 3.2.2.3.2 Output File Name  PAGEREF _Toc449869376 \h 127 3.2.2.3.3 Output File Buffer  PAGEREF _Toc449869377 \h 127 3.2.2.4 CPU Utilization Histogram  PAGEREF _Toc449869378 \h 127 3.2.2.4.1 File Type  PAGEREF _Toc449869379 \h 128 3.2.2.4.2 File Name  PAGEREF _Toc449869380 \h 128 3.2.2.4.3 Grid Size  PAGEREF _Toc449869381 \h 128 3.2.3 Scene Parsing Options  PAGEREF _Toc449869382 \h 129 3.2.3.1 Input File Name  PAGEREF _Toc449869383 \h 129 3.2.3.2 Library Paths  PAGEREF _Toc449869384 \h 129 3.2.3.3 Language Version  PAGEREF _Toc449869385 \h 129 3.2.4 Shell-out to Operating System  PAGEREF _Toc449869386 \h 130 3.2.4.1 String Substitution in Shell Commands  PAGEREF _Toc449869387 \h 130 3.2.4.2 Shell Command Sequencing  PAGEREF _Toc449869388 \h 131 3.2.4.3 Shell Command Return Actions  PAGEREF _Toc449869389 \h 131 3.2.5 Text Output  PAGEREF _Toc449869390 \h 133 3.2.5.1 Text Streams  PAGEREF _Toc449869391 \h 134 3.2.5.2 Console Text Output  PAGEREF _Toc449869392 \h 134 3.2.5.3 Directing Text Streams to Files  PAGEREF _Toc449869393 \h 135 3.2.5.4 Help Screen Switches  PAGEREF _Toc449869394 \h 136 3.2.6 Tracing Options  PAGEREF _Toc449869395 \h 136 3.2.6.1 Quality Settings  PAGEREF _Toc449869396 \h 136 3.2.6.2 Radiosity Setting  PAGEREF _Toc449869397 \h 137 3.2.6.3 Automatic Bounding Control  PAGEREF _Toc449869398 \h 137 3.2.6.4 Removing User Bounding  PAGEREF _Toc449869399 \h 138 3.2.6.5 Anti-Aliasing Options  PAGEREF _Toc449869400 \h 138 4 Scene Description Language  PAGEREF _Toc449869401 \h 142 4.1 Language Basics  PAGEREF _Toc449869402 \h 142 4.1.1 Identifiers and Keywords  PAGEREF _Toc449869403 \h 142 4.1.2 Comments  PAGEREF _Toc449869404 \h 144 4.1.3 Float Expressions  PAGEREF _Toc449869405 \h 145 4.1.3.1 Float Literals  PAGEREF _Toc449869406 \h 146 4.1.3.2 Float Identifiers  PAGEREF _Toc449869407 \h 146 4.1.3.3 Float Operators  PAGEREF _Toc449869408 \h 147 4.1.3.4 Built-in Float Identifiers  PAGEREF _Toc449869409 \h 147 4.1.3.5 Boolean Keywords  PAGEREF _Toc449869410 \h 149 4.1.3.6 Float Functions  PAGEREF _Toc449869411 \h 149 4.1.4 Vector Expressions  PAGEREF _Toc449869412 \h 151 4.1.4.1 Vector Literals  PAGEREF _Toc449869413 \h 152 4.1.4.2 Vector Identifiers  PAGEREF _Toc449869414 \h 152 4.1.4.3 Vector Operators  PAGEREF _Toc449869415 \h 152 4.1.4.4 Operator Promotion  PAGEREF _Toc449869416 \h 153 4.1.4.5 Built-in Vector Identifiers  PAGEREF _Toc449869417 \h 153 4.1.4.6 Vector Functions  PAGEREF _Toc449869418 \h 154 4.1.5 Specifying Colors  PAGEREF _Toc449869419 \h 154 4.1.5.1 Color Vectors  PAGEREF _Toc449869420 \h 155 4.1.5.2 Color Keywords  PAGEREF _Toc449869421 \h 156 4.1.5.3 Color Identifiers  PAGEREF _Toc449869422 \h 156 4.1.5.4 Color Operators  PAGEREF _Toc449869423 \h 157 4.1.5.5 Common Color Pitfalls  PAGEREF _Toc449869424 \h 157 4.1.6 Strings  PAGEREF _Toc449869425 \h 158 4.1.6.1 String Literals  PAGEREF _Toc449869426 \h 158 4.1.6.2 String Identifiers  PAGEREF _Toc449869427 \h 159 4.1.6.3 String Functions  PAGEREF _Toc449869428 \h 159 4.1.7 Array Identifiers  PAGEREF _Toc449869429 \h 160 4.1.7.1 Declaring Arrays  PAGEREF _Toc449869430 \h 160 4.1.7.2 Array Initalizers  PAGEREF _Toc449869431 \h 161 4.2 Language Directives  PAGEREF _Toc449869432 \h 161 4.2.1 Include Files and the #include Directive.  PAGEREF _Toc449869433 \h 162 4.2.2 The #declare and #local Directives  PAGEREF _Toc449869434 \h 162 4.2.2.1 Declaring identifiers  PAGEREF _Toc449869435 \h 163 4.2.2.2 #declare vs. #local  PAGEREF _Toc449869436 \h 164 4.2.2.3 Identifier Name Collisions  PAGEREF _Toc449869437 \h 164 4.2.2.4 Destroying Identifiers with #undef  PAGEREF _Toc449869438 \h 166 4.2.3 File I/O Directives  PAGEREF _Toc449869439 \h 166 4.2.3.1 The #fopen Directive  PAGEREF _Toc449869440 \h 166 4.2.3.2 The #fclose Directive  PAGEREF _Toc449869441 \h 166 4.2.3.3 The #read Directive  PAGEREF _Toc449869442 \h 166 4.2.3.4 The #write Directive  PAGEREF _Toc449869443 \h 167 4.2.4 The #default Directive  PAGEREF _Toc449869444 \h 168 4.2.5 The #version Directive  PAGEREF _Toc449869445 \h 169 4.2.6 Conditional Directives  PAGEREF _Toc449869446 \h 169 4.2.6.1 The #if...#else...#end Directives  PAGEREF _Toc449869447 \h 169 4.2.6.2 The #ifdef and #ifndef Directives  PAGEREF _Toc449869448 \h 170 4.2.6.3 The #switch, #case, #range and #break Directives  PAGEREF _Toc449869449 \h 170 4.2.6.4 The #while...#end Directive  PAGEREF _Toc449869450 \h 171 4.2.7 User Message Directives  PAGEREF _Toc449869451 \h 172 4.2.7.1 Text Message Streams  PAGEREF _Toc449869452 \h 172 4.2.7.2 Text Formatting  PAGEREF _Toc449869453 \h 173 4.2.8 User Defined Macros  PAGEREF _Toc449869454 \h 173 4.2.8.1 The #macro Directive  PAGEREF _Toc449869455 \h 173 4.2.8.2 Invoking Macros  PAGEREF _Toc449869456 \h 174 4.2.8.3 Are POV-Ray Macros a Function or a Macro?  PAGEREF _Toc449869457 \h 175 4.2.8.4 Returning a Value Like a Function  PAGEREF _Toc449869458 \h 175 4.2.8.5 Returning Values Via Parameters  PAGEREF _Toc449869459 \h 176 4.3 POV-Ray Coordinate System  PAGEREF _Toc449869460 \h 177 4.3.1 Transformations  PAGEREF _Toc449869461 \h 177 4.3.1.1 Translate  PAGEREF _Toc449869462 \h 178 4.3.1.2 Scale  PAGEREF _Toc449869463 \h 178 4.3.1.3 Rotate  PAGEREF _Toc449869464 \h 179 4.3.1.4 Matrix Keyword  PAGEREF _Toc449869465 \h 179 4.3.2 Transformation Order  PAGEREF _Toc449869466 \h 179 4.3.3 Transform Identifiers  PAGEREF _Toc449869467 \h 180 4.3.4 Transforming Textures and Objects  PAGEREF _Toc449869468 \h 180 4.4 Camera  PAGEREF _Toc449869469 \h 181 4.4.1 Placing the Camera  PAGEREF _Toc449869470 \h 182 4.4.1.1 Location and Look_At  PAGEREF _Toc449869471 \h 182 4.4.1.2 The Sky Vector  PAGEREF _Toc449869472 \h 183 4.4.1.3 Angle  PAGEREF _Toc449869473 \h 183 4.4.1.4 The Direction Vector  PAGEREF _Toc449869474 \h 183 4.4.1.5 Up and Right Vectors  PAGEREF _Toc449869475 \h 184 4.4.1.5.1 Aspect Ratio  PAGEREF _Toc449869476 \h 184 4.4.1.5.2 Handedness  PAGEREF _Toc449869477 \h 185 4.4.1.6 Transforming the Camera  PAGEREF _Toc449869478 \h 185 4.4.2 Types of Projection  PAGEREF _Toc449869479 \h 186 4.4.3 Focal Blur  PAGEREF _Toc449869480 \h 187 4.4.4 Camera Ray Perturbation  PAGEREF _Toc449869481 \h 187 4.4.5 Camera Identifiers  PAGEREF _Toc449869482 \h 188 4.5 Objects  PAGEREF _Toc449869483 \h 188 4.5.1 Finite Solid Primitives  PAGEREF _Toc449869484 \h 189 4.5.1.1 Blob  PAGEREF _Toc449869485 \h 189 4.5.1.2 Box  PAGEREF _Toc449869486 \h 191 4.5.1.3 Cone  PAGEREF _Toc449869487 \h 192 4.5.1.4 Cylinder  PAGEREF _Toc449869488 \h 193 4.5.1.5 Height Field  PAGEREF _Toc449869489 \h 193 4.5.1.6 Julia Fractal  PAGEREF _Toc449869490 \h 196 4.5.1.7 Lathe  PAGEREF _Toc449869491 \h 198 4.5.1.8 Prism  PAGEREF _Toc449869492 \h 199 4.5.1.9 Sphere  PAGEREF _Toc449869493 \h 201 4.5.1.10 Superquadric Ellipsoid  PAGEREF _Toc449869494 \h 202 4.5.1.11 Surface of Revolution  PAGEREF _Toc449869495 \h 203 4.5.1.12 Text  PAGEREF _Toc449869496 \h 205 4.5.1.13 Torus  PAGEREF _Toc449869497 \h 206 4.5.2 Finite Patch Primitives  PAGEREF _Toc449869498 \h 206 4.5.2.1 Bicubic Patch  PAGEREF _Toc449869499 \h 207 4.5.2.2 Disc  PAGEREF _Toc449869500 \h 208 4.5.2.3 Mesh  PAGEREF _Toc449869501 \h 208 4.5.2.4 Polygon  PAGEREF _Toc449869502 \h 209 4.5.2.5 Triangle and Smooth Triangle  PAGEREF _Toc449869503 \h 210 4.5.3 Infinite Solid Primitives  PAGEREF _Toc449869504 \h 211 4.5.3.1 Plane  PAGEREF _Toc449869505 \h 211 4.5.3.2 Poly, Cubic and Quartic  PAGEREF _Toc449869506 \h 211 4.5.3.3 Quadric  PAGEREF _Toc449869507 \h 213 4.5.4 Constructive Solid Geometry  PAGEREF _Toc449869508 \h 214 4.5.4.1 Inside and Outside  PAGEREF _Toc449869509 \h 214 4.5.4.2 Union  PAGEREF _Toc449869510 \h 215 4.5.4.3 Intersection  PAGEREF _Toc449869511 \h 216 4.5.4.4 Difference  PAGEREF _Toc449869512 \h 216 4.5.4.5 Merge  PAGEREF _Toc449869513 \h 217 4.5.5 Light Sources  PAGEREF _Toc449869514 \h 218 4.5.5.1 Point Lights  PAGEREF _Toc449869515 \h 218 4.5.5.2 Spotlights  PAGEREF _Toc449869516 \h 218 4.5.5.3 Cylindrical Lights  PAGEREF _Toc449869517 \h 222 4.5.5.4 Area Lights  PAGEREF _Toc449869518 \h 222 4.5.5.5 Shadowless Lights  PAGEREF _Toc449869519 \h 224 4.5.5.6 Looks_like  PAGEREF _Toc449869520 \h 224 4.5.5.7 Light Fading  PAGEREF _Toc449869521 \h 224 4.5.5.8 Atmospheric Media Interaction  PAGEREF _Toc449869522 \h 225 4.5.5.9 Atmospheric Attenuation  PAGEREF _Toc449869523 \h 225 4.5.6 Object Modifiers  PAGEREF _Toc449869524 \h 225 4.5.6.1 Clipped_By  PAGEREF _Toc449869525 \h 226 4.5.6.2 Bounded_By  PAGEREF _Toc449869526 \h 227 4.5.6.3 Material  PAGEREF _Toc449869527 \h 228 4.5.6.4 Inverse  PAGEREF _Toc449869528 \h 228 4.5.6.5 Hollow  PAGEREF _Toc449869529 \h 229 4.5.6.6 No_Shadow  PAGEREF _Toc449869530 \h 229 4.5.6.7 Sturm  PAGEREF _Toc449869531 \h 229 4.6 Interior  PAGEREF _Toc449869532 \h 230 4.6.1 Why are Interior and Media Necessary?  PAGEREF _Toc449869533 \h 230 4.6.2 Empty and Solid Objects  PAGEREF _Toc449869534 \h 231 4.6.3 Refraction  PAGEREF _Toc449869535 \h 232 4.6.4 Attenuation  PAGEREF _Toc449869536 \h 232 4.6.5 Faked Caustics  PAGEREF _Toc449869537 \h 233 4.6.6 Object Media  PAGEREF _Toc449869538 \h 233 4.7 Textures  PAGEREF _Toc449869539 \h 234 4.7.1 Pigment  PAGEREF _Toc449869540 \h 235 4.7.1.1 Solid Color Pigments  PAGEREF _Toc449869541 \h 236 4.7.1.2 Color List Pigments  PAGEREF _Toc449869542 \h 236 4.7.1.3 Color Maps  PAGEREF _Toc449869543 \h 237 4.7.1.4 Pigment Maps and Pigment Lists  PAGEREF _Toc449869544 \h 238 4.7.1.5 Image Maps  PAGEREF _Toc449869545 \h 239 4.7.1.5.1 Specifying an Image Map  PAGEREF _Toc449869546 \h 239 4.7.1.5.2 The Filter and Transmit Bitmap Modifiers  PAGEREF _Toc449869547 \h 240 4.7.1.5.3 Using the Alpha Channel  PAGEREF _Toc449869548 \h 241 4.7.1.6 Quick Color  PAGEREF _Toc449869549 \h 241 4.7.2 Normal  PAGEREF _Toc449869550 \h 242 4.7.2.1 Slope Maps  PAGEREF _Toc449869551 \h 243 4.7.2.2 Normal Maps and Normal Lists  PAGEREF _Toc449869552 \h 245 4.7.2.3 Bump Maps  PAGEREF _Toc449869553 \h 246 4.7.2.3.1 Specifying a Bump Map  PAGEREF _Toc449869554 \h 246 4.7.2.3.2 Bump_Size  PAGEREF _Toc449869555 \h 247 4.7.2.3.3 Use_Index and Use_Color  PAGEREF _Toc449869556 \h 247 4.7.3 Finish  PAGEREF _Toc449869557 \h 247 4.7.3.1 Ambient  PAGEREF _Toc449869558 \h 248 4.7.3.2 Diffuse Reflection Items  PAGEREF _Toc449869559 \h 249 4.7.3.2.1 Diffuse  PAGEREF _Toc449869560 \h 249 4.7.3.2.2 Brilliance  PAGEREF _Toc449869561 \h 249 4.7.3.2.3 Crand Graininess  PAGEREF _Toc449869562 \h 250 4.7.3.3 Highlights  PAGEREF _Toc449869563 \h 250 4.7.3.3.1 Phong Highlights  PAGEREF _Toc449869564 \h 250 4.7.3.3.2 Specular Highlight  PAGEREF _Toc449869565 \h 250 4.7.3.3.3 Metallic Highlight Modifier  PAGEREF _Toc449869566 \h 251 4.7.3.4 Specular Reflection  PAGEREF _Toc449869567 \h 251 4.7.3.5 Iridescence  PAGEREF _Toc449869568 \h 252 4.7.4 Halo  PAGEREF _Toc449869569 \h 253 4.7.5 Patterned Textures  PAGEREF _Toc449869570 \h 253 4.7.5.1 Texture Maps  PAGEREF _Toc449869571 \h 253 4.7.5.2 Tiles  PAGEREF _Toc449869572 \h 254 4.7.5.3 Material Maps  PAGEREF _Toc449869573 \h 255 4.7.5.3.1 Specifying a Material Map  PAGEREF _Toc449869574 \h 255 4.7.6 Layered Textures  PAGEREF _Toc449869575 \h 257 4.7.7 Patterns  PAGEREF _Toc449869576 \h 258 4.7.7.1 Agate  PAGEREF _Toc449869577 \h 258 4.7.7.2 Average  PAGEREF _Toc449869578 \h 258 4.7.7.3 Boxed  PAGEREF _Toc449869579 \h 259 4.7.7.4 Bozo  PAGEREF _Toc449869580 \h 259 4.7.7.5 Brick  PAGEREF _Toc449869581 \h 260 4.7.7.6 Bumps  PAGEREF _Toc449869582 \h 260 4.7.7.7 Checker  PAGEREF _Toc449869583 \h 261 4.7.7.8 Crackle  PAGEREF _Toc449869584 \h 261 4.7.7.9 Cylindrical  PAGEREF _Toc449869585 \h 261 4.7.7.10 Density_File  PAGEREF _Toc449869586 \h 262 4.7.7.11 Dents  PAGEREF _Toc449869587 \h 262 4.7.7.12 Gradient  PAGEREF _Toc449869588 \h 262 4.7.7.13 Granite  PAGEREF _Toc449869589 \h 263 4.7.7.14 Hexagon  PAGEREF _Toc449869590 \h 263 4.7.7.15 Leopard  PAGEREF _Toc449869591 \h 264 4.7.7.16 Mandel  PAGEREF _Toc449869592 \h 264 4.7.7.17 Marble  PAGEREF _Toc449869593 \h 265 4.7.7.18 Onion  PAGEREF _Toc449869594 \h 265 4.7.7.19 Planar  PAGEREF _Toc449869595 \h 265 4.7.7.20 Quilted  PAGEREF _Toc449869596 \h 265 4.7.7.21 Radial  PAGEREF _Toc449869597 \h 268 4.7.7.22 Ripples  PAGEREF _Toc449869598 \h 268 4.7.7.23 Spherical  PAGEREF _Toc449869599 \h 268 4.7.7.24 Spiral1  PAGEREF _Toc449869600 \h 268 4.7.7.25 Spiral2  PAGEREF _Toc449869601 \h 269 4.7.7.26 Spotted  PAGEREF _Toc449869602 \h 269 4.7.7.27 Waves  PAGEREF _Toc449869603 \h 269 4.7.7.28 Wood  PAGEREF _Toc449869604 \h 269 4.7.7.29 Wrinkles  PAGEREF _Toc449869605 \h 270 4.7.8 Pattern Modifiers  PAGEREF _Toc449869606 \h 270 4.7.8.1 Transforming Patterns  PAGEREF _Toc449869607 \h 271 4.7.8.2 Frequency and Phase  PAGEREF _Toc449869608 \h 271 4.7.8.3 Waveforms  PAGEREF _Toc449869609 \h 272 4.7.8.4 Turbulence  PAGEREF _Toc449869610 \h 273 4.7.8.5 Octaves  PAGEREF _Toc449869611 \h 274 4.7.8.6 Lambda  PAGEREF _Toc449869612 \h 274 4.7.8.7 Omega  PAGEREF _Toc449869613 \h 274 4.7.8.8 Warps  PAGEREF _Toc449869614 \h 274 4.7.8.8.1 Black Hole Warp  PAGEREF _Toc449869615 \h 275 4.7.8.8.2 Repeat Warp  PAGEREF _Toc449869616 \h 277 4.7.8.8.3 Turbulence Warp  PAGEREF _Toc449869617 \h 278 4.7.8.9 Bitmap Modifiers  PAGEREF _Toc449869618 \h 279 4.7.8.9.1 The once Option  PAGEREF _Toc449869619 \h 280 4.7.8.9.2 The map_type Option  PAGEREF _Toc449869620 \h 280 4.7.8.9.3 The interpolate Option  PAGEREF _Toc449869621 \h 280 4.8 Media  PAGEREF _Toc449869622 \h 281 4.8.1 Media Types  PAGEREF _Toc449869623 \h 282 4.8.1.1 Absorption  PAGEREF _Toc449869624 \h 282 4.8.1.2 Emission  PAGEREF _Toc449869625 \h 282 4.8.1.3 Scattering  PAGEREF _Toc449869626 \h 282 4.8.2 Sampling Parameters  PAGEREF _Toc449869627 \h 285 4.8.3 Density  PAGEREF _Toc449869628 \h 285 4.8.3.1 General Density Modifiers  PAGEREF _Toc449869629 \h 286 4.8.3.2 Density with color_map  PAGEREF _Toc449869630 \h 286 4.8.3.3 Density Maps and Density Lists  PAGEREF _Toc449869631 \h 287 4.8.3.4 Multiple Density vs. Multiple Media  PAGEREF _Toc449869632 \h 287 4.9 Atmospheric Effects  PAGEREF _Toc449869633 \h 288 4.9.1 Atmospheric Media  PAGEREF _Toc449869634 \h 288 4.9.2 Background  PAGEREF _Toc449869635 \h 289 4.9.3 Fog  PAGEREF _Toc449869636 \h 289 4.9.4 Sky Sphere  PAGEREF _Toc449869637 \h 290 4.9.5 Rainbow  PAGEREF _Toc449869638 \h 291 4.10 Global Settings  PAGEREF _Toc449869639 \h 292 4.10.1 ADC_Bailout  PAGEREF _Toc449869640 \h 292 4.10.2 Ambient Light  PAGEREF _Toc449869641 \h 293 4.10.3 Assumed_Gamma  PAGEREF _Toc449869642 \h 293 4.10.3.1 Monitor Gamma  PAGEREF _Toc449869643 \h 293 4.10.3.2 Image File Gamma  PAGEREF _Toc449869644 \h 294 4.10.3.3 Scene File Gamma  PAGEREF _Toc449869645 \h 294 4.10.4 HF_Gray_16  PAGEREF _Toc449869646 \h 295 4.10.5 Irid_Wavelength  PAGEREF _Toc449869647 \h 295 4.10.6 Max_Trace_Level  PAGEREF _Toc449869648 \h 295 4.10.7 Max_Intersections  PAGEREF _Toc449869649 \h 296 4.10.8 Number_Of_Waves  PAGEREF _Toc449869650 \h 296 4.10.9 Radiosity  PAGEREF _Toc449869651 \h 297 4.10.9.1 How Radiosity Works  PAGEREF _Toc449869652 \h 297 4.10.9.2 Adjusting Radiosity  PAGEREF _Toc449869653 \h 297 4.10.9.2.1 brightness  PAGEREF _Toc449869654 \h 298 4.10.9.2.2 count  PAGEREF _Toc449869655 \h 298 4.10.9.2.3 distance_maximum  PAGEREF _Toc449869656 \h 298 4.10.9.2.4 error_bound  PAGEREF _Toc449869657 \h 299 4.10.9.2.5 gray_threshold  PAGEREF _Toc449869658 \h 299 4.10.9.2.6 low_error_factor  PAGEREF _Toc449869659 \h 299 4.10.9.2.7 minimum_reuse  PAGEREF _Toc449869660 \h 299 4.10.9.2.8 nearest_count  PAGEREF _Toc449869661 \h 299 4.10.9.2.9 recursion_limit  PAGEREF _Toc449869662 \h 300 4.10.9.3 Tips on Radiosity  PAGEREF _Toc449869663 \h 300 5 APPENDICES  PAGEREF _Toc449869664 \h 301 5.1 Copyright, Legal Information and License -- POVLEGAL.DOC  PAGEREF _Toc449869665 \h 301 5.1.1 General License Agreement -- POVLEGAL.DOC  PAGEREF _Toc449869666 \h 301 5.1.2 Usage Provisions  PAGEREF _Toc449869667 \h 301 5.1.3 General Rules For All Distribution  PAGEREF _Toc449869668 \h 301 5.1.4 Definition Of "Full Package"  PAGEREF _Toc449869669 \h 302 5.1.5 Conditions For CD-ROM or Shareware/Freeware Distribution  PAGEREF _Toc449869670 \h 302 5.1.6 Conditions For On-Line Services And Bbs's Including Internet  PAGEREF _Toc449869671 \h 302 5.1.7 Online Or Remote Execution Of POV-Ray  PAGEREF _Toc449869672 \h 303 5.1.8 Permitted Modification And Custom Versions  PAGEREF _Toc449869673 \h 303 5.1.9 Conditions For Distribution Of Custom Versions  PAGEREF _Toc449869674 \h 304 5.1.10 Conditions For Commercial Bundling  PAGEREF _Toc449869675 \h 304 5.1.11 POV-Team Endorsement Prohibitions  PAGEREF _Toc449869676 \h 305 5.1.12 Retail Value Of This Software  PAGEREF _Toc449869677 \h 305 5.1.13 Other Provisions  PAGEREF _Toc449869678 \h 305 5.1.14 Revocation Of License  PAGEREF _Toc449869679 \h 306 5.1.15 Disclaimer  PAGEREF _Toc449869680 \h 306 5.1.16 Technical Support  PAGEREF _Toc449869681 \h 306 5.2 Authors  PAGEREF _Toc449869682 \h 306 5.2.1 Contacting the Authors  PAGEREF _Toc449869683 \h 308 5.3 What to do if you don't have POV-Ray  PAGEREF _Toc449869684 \h 308 5.3.1 Which Version of POV-Ray should you use?  PAGEREF _Toc449869685 \h 308 5.3.1.1 Microsoft Windows 95/98/NT  PAGEREF _Toc449869686 \h 308 5.3.1.2 MS-Dos & Windows 3.x  PAGEREF _Toc449869687 \h 309 5.3.1.3 Linux for Intel x86  PAGEREF _Toc449869688 \h 309 5.3.1.4 Apple Macintosh  PAGEREF _Toc449869689 \h 310 5.3.1.5 Amiga  PAGEREF _Toc449869690 \h 311 5.3.1.6 SunOS  PAGEREF _Toc449869691 \h 311 5.3.1.7 Generic Unix  PAGEREF _Toc449869692 \h 312 5.3.1.8 All Versions  PAGEREF _Toc449869693 \h 312 5.3.2 Where to Find POV-Ray Files  PAGEREF _Toc449869694 \h 313 5.3.2.1 World Wide Website www.povray.org  PAGEREF _Toc449869695 \h 313 5.3.2.2 Books, Magazines and CD-ROMs  PAGEREF _Toc449869696 \h 313 5.4 Compiling POV-Ray  PAGEREF _Toc449869697 \h 313 5.4.1 Directory Structure  PAGEREF _Toc449869698 \h 314 5.4.2 Configuring POV-Ray Source  PAGEREF _Toc449869699 \h 315 5.4.3 Conclusion  PAGEREF _Toc449869700 \h 315 5.5 Suggested Reading  PAGEREF _Toc449869701 \h 315 6 Index  PAGEREF _Toc449869702 \h 317  Introduction This document details the use of the Persistence of Vision "! Ray-Tracer (POV-Ray "!). It is divided into five parts: 1) This introduction which explains what POV-Ray is and what ray-tracing is. It gives a brief overview of how to create ray-traced images. 2) A " REF _Ref413502638 \h Beginning Tutorial" which explains step by step how to use the different features of POV-Ray. 3) A complete reference on " REF _Ref413502655 \h Scene Description Language" in which you describe the scene. 4) A complete reference on " REF _Ref413502672 \h POV-Ray Options" which explains options (set either by command line switches or by INI file keywords) that tell POV-Ray how to render the scenes. 5) And in our " REF _Ref413502693 \h APPENDICES" you will find some tips and hints, where to get the latest version and versions for other platforms, information on compiling custom versions of POV-Ray, suggested reading, contact addresses and legal information. POV-Ray runs on MS-Dos, Windows 3.x, Windows for Workgroups 3.11, Windows 95, Windows NT, Apple Macintosh 68k, Macintosh Power PC, Amiga, Linux, Sun-OS, UNIX and other platforms. We assume that if you are reading this document then you already have POV-Ray installed and running. However the POV-Team does distribute this file by itself in various formats including online on the internet. If you don't have POV-Ray or aren't sure you have the official version or the latest version, see appendix " REF _Ref411499510 \h What to do if you don't have POV-Ray". This document covers only the generic parts of the program which are common to each version. Each version has platform-specific documentation not included here. We recommend you finish reading this introductory section then read the platform-specific information before trying the tutorial here. The platform-specific docs will show you how to render a sample scene and will give you detailed description of the platform-specific features. The MS-Dos version documentation contains a plain text file POVMSDOS.DOC which contains its specific docs. It can be found in the main directory where you installed POV-Ray such as C:\POVRAY3. The Windows version documentation is available on the POV-Ray program's Help menu or press the F1 key while in the program. The Mac platform documentation consists of a self-displaying document called "POV-Ray MacOS Read Me" which contains information specific to the Mac version of POV-Ray. It is best to read this document first, to learn how to set up and start using the Mac version of POV-Ray. This document is in the "Documentation" folder in the main "POV-Ray 3" folder. The Amiga version documentation is made up of Html documents, stored in the same place of general POV-Ray docs; the 'root' document is "POVRAY3:POV-Reference/AmigaPOV.html" when the program is installed following the instruction given. Amiga specific documentation and POV-Ray general docs are available pressing Help key in the POV-Gui program; this feature is available in POV-Gui since version 2.1 The Linux version documentation contains a plain text file povlinux.doc which contains its specific docs. It can be found in the main directory where you installed POV-Ray such as /usr/povray3. The SunOS version documentation contains a plain text file povsunos.doc which contains its specific docs. It can be found in the main directory where you installed POV-Ray such as /usr/povray3. The generic Unix version documentation contains a plain text file povunix.doc which contains its specific docs. It can be found in the main directory where you installed POV-Ray such as /usr/povray3. Program Description The Persistence of Vision"! Ray-Tracer creates three-dimensional, photo-realistic images using a rendering technique called ray-tracing. It reads in a text file containing information describing the objects and lighting in a scene and generates an image of that scene from the view point of a camera also described in the text file. Ray-tracing is not a fast process by any means, but it produces very high quality images with realistic reflections, shading, perspective and other effects. What is Ray-Tracing? Ray-tracing XE "Ray-tracing"  is a rendering technique that calculates an image of a scene by simulating the way rays of light travel in the real world. However it does its job backwards. In the real world, rays of light are emitted from a light source and illuminate objects. The light reflects off of the objects or passes through transparent objects. This reflected light hits our eyes or perhaps a camera lens. Because the vast majority of rays never hit an observer, it would take forever to trace a scene. Ray-tracing programs like POV-Ray start with their simulated camera and trace rays backwards out into the scene. The user specifies the location of the camera, light sources, and objects as well as the surface texture properties of objects, their interiors (if transparent) and any atmospheric media such as fog, haze, or fire. For every pixel in the final image one or more viewing rays are shot from the camera, into the scene to see if it intersects with any of the objects in the scene. These "viewing rays" originate from the viewer, represented by the camera, and pass through the viewing window (representing the final image). Every time an object is hit, the color of the surface at that point is calculated. For this purpose rays are sent backwards to each light source to determine the amount of light coming from the source. These "shadow rays" are tested to tell whether the surface point lies in shadow or not. If the surface is reflective or transparent new rays are set up and traced in order to determine the contribution of the reflected and refracted light to the final surface color. Special features like inter-diffuse reflection (radiosity), atmospheric effects and area lights make it necessary to shoot a lot of additional rays into the scene for every pixel. What is POV-Ray? The Persistence of Vision "! Ray-Tracer was developed from DKBTrace 2.12 (written by David K. Buck and Aaron A. Collins) by a bunch of people, called the POV-Team "!, in their spare time. The headquarters of the POV-Team is on the internet at http://www.povray.org (see " REF _Ref449774474 \h Where to Find POV-Ray Files" for more details). The POV-Ray "! package includes detailed instructions on using the ray-tracer and creating scenes. Many stunning scenes are included with POV-Ray so you can start creating images immediately when you get the package. These scenes can be modified so you don't have to start from scratch. In addition to the pre-defined scenes, a large library of pre-defined shapes and materials is provided. You can include these shapes and materials in your own scenes by just including the library file name at the top of your scene file, and by using the shape or material name in your scene. Here are some highlights of POV-Ray's features: * Easy to use scene description language. * Large library of stunning example scene files. * Standard include files that pre-define many shapes, colors and textures. * Very high quality output image files (up to 48-bit color). * 15 and 24 bit color display on many computer platforms using appropriate hardware. * Create landscapes using smoothed height fields. * Many camera types, including perspective, panorama, orthographic, fisheye, etc. * Spotlights, cylindrical lights and area lights for sophisticated lighting. * Phong and specular highlighting for more realistic-looking surfaces. * Inter-diffuse reflection (radiosity) for more realistic lighting. * Atmospheric effects like atmosphere, ground-fog and rainbow. * Particle media to model effects like clouds, dust, fire and steam. * Several image file output formats including Targa, PNG and PPM. * Basic shape primitives such as ... spheres, boxes, quadrics, cylinders, cones, triangles and planes. * Advanced shape primitives such as ... Torii (donuts), bezier patches, height fields (mountains), blobs, quartics, smooth triangles, text, fractals, superquadrics, surfaces of revolution, prisms, polygons, lathes and fractals. * Shapes can easily be combined to create new complex shapes using Constructive Solid Geometry (CSG). POV-Ray supports unions, merges, intersections and differences. * Objects are assigned materials called textures (a texture describes the coloring and surface properties of a shape) and interior properties such as index of refraction and particle media (formerly known as "halos"). * Built-in color and normal patterns: Agate, Bozo, Bumps, Checker, Crackle, Dents, Granite, Gradient, Hexagon, Leopard, Mandel, Marble, Onion, Quilted, Ripples, Spotted, Spiral, Radial, Waves, Wood, Wrinkles and image file mapping. * Users can create their own textures or use pre-defined textures such as ... Brass, Chrome, Copper, Gold, Silver, Stone, Wood. * Combine textures using layering of semi-transparent textures or tiles of textures or material map files. * Display preview of image while rendering (not available on all platforms). * Halt and save a render part way through, and continue rendering the halted partial render later. How Do I Begin? POV-Ray scenes are described in a special text language called a "scene description language". You will type commands into a plain text file and POV-Ray will read it to create the image. The process of running POV-Ray is a little different on each platform or operating system. You should read the platform-specific documentation as suggested earlier in this introduction. It will tell you how to command POV-Ray to turn your text scene description into an image. You should try rendering several sample images before attempting to create your own. Once you know how to run POV-Ray on your computer and your operating system, you can proceed with the tutorial which follows. The tutorial explains how to describe the scene using the POV-Ray language. Notation and Basic Assumptions Throughout the tutorial and reference section of this document, the following notation is used to mark keywords of the scene description language, command line switches, INI file keywords and file names. keywordmono-spaced boldPOV-Ray keywords and punctuation+W640 +H480mono-spaced boldcommand-line switchesC:\MYFILE.POVmono-spacedfile names, directories, pathsSYNTAX_ITEMitalics, all capsrequired syntax item[SYNTAX_ITEM]italics, all caps, bracesoptional syntax itemSYNTAX_ITEM...italics, all caps, ellipsisone or more syntax items[SYNTAX_ITEM...]italics, all caps, braces, ellipsiszero or more syntax itemsValue_1italics, mixed casea float value or expressionitalics, mixed case, angle bracesa vector value or expression[ ITEM ]bold square bracesITEM enclosed in required bracesITEM1 | ITEM2vertical barchoice of ITEM1 or ITEM2 In the plain ASCII version of the document there is no visible difference between the different notations. Note that POV-Ray is a command-line program on MS-Dos, Unix and other text-based operating system and is menu-driven on Windows and Macintosh platforms. Some of these operating systems use folders to store files while others use directories. Some separate the folders and sub-folders with a slash character (/), back-slash character (\), or others. We have tried to make this documentation as generic as possible but sometimes we have to refer to folders, files, options etc. and there's no way to escape it. Here are some assumptions we make... 1) You installed POV-Ray in the "C:\POVRAY3" directory. For MS-Dos this is probably true but for Unix it might be "/usr/povray3", or for Windows it might be "C:\Program Files\POV-Ray for Windows", for Mac it might be "MyHD:Apps:POV-Ray 3:", or you may have used some other drive or directory. So if we tell you that "Include files are stored in the \povray3\include directory," we assume you can translate that to something like "::POVRAY3:INCLUDE" or "C:\Program Files\POV-Ray for Windows\include" or whatever is appropriate for your platform, operating system and installation. 2) POV-Ray uses command-line switches and INI files to choose options in all versions but Windows and Mac also use dialog boxes or menu choices to set options. We will describe options assuming you are using switches or INI files when describing what the options do. We have taken care to use the same terminology in designing menus and dialogs as we use in describing switches or INI keywords. See your version-specific documentation on menu and dialogs. 3) Some of you are reading this using a help-reader, built-in help, web-browser, formatted printout, or plain text file. We assume you know how to get around in which ever medium you're using. We'll say "See the chapter on "Setting POV-Ray Option" we assume you can click, scroll, browse, flip pages or whatever to get there. What's New in POV-Ray 3.1? Here is an overview of what is new in POV-Ray 3.1 since version 3.0. Media Replaces Halo & Atmosphere The keywords halo XE "halo"  and atmosphere XE "atmosphere"  have been totally eliminated with no backwards compatibility of any kind provided. They have been replaced by a new feature called media XE "media" . At the scene level, media acts as atmospheric media for fog, haze, dust, etc. On objects, media is not part of texture like halo was. Object media is now part of a new feature called interior XE "interior" . Media is not just a rename for halo. It is a new model with some similar features of halo. BECAUSE POV-Ray 3.1 DISCONTINUES SOME 3.0 FEATURES YOU MAY WISH TO KEEP 3.0 TO RENDER OLDER SCENES. Any pattern type (bozo XE "bozo" , wood XE "wood" , dents XE "dents" , etc.) may be used as a density XE "density"  function for media. New patterns spherical XE "spherical" , cylindrical XE "cylindrical" , planar XE "planar" , and boxed XE "boxed"  added for pigment XE "pigment" , normal XE "normal" , texture XE "texture" , and density XE "density" . New wave types cubic_wave XE "cubic_wave"  and poly_wave XE "poly_wave"  Float have been added. New object modifier interior XE "interior" {...}. Interior contains information about the interior of the object which was formerly contained in the finish XE "finish"  and halo XE "halo"  parts of a texture XE "texture" . Interior items are no longer part of the texture. Instead, they attach directly to the objects. The finish items moved are ior XE "ior" , caustic XE "caustic" , fade_power XE "fade_power" , and fade_distance XE "fade_distance" . The refraction XE "refraction"  keyword is no longer necessary. Any ior other than 1.0 turns on refraction. These 5 finish keywords which are now part of interior will still work in finish but will generate warnings. Some obscure texture_map XE "texture_map"  statements with varying ior will not work. Added reflection_exponent XE "reflection_exponent"  Float to finish to give more realistic reflection of very bright objects. New #macro Feature Add fully recursive and parameterized #macro XE "#macro"  directive. Define like this... #macro MyMacro (P1,P2,P3) ... #end Invoke like this... MyMacro (5,x*5,MyTexture) Note no '#' sign precedes invocation. Macros can be invoked almost anywhere. Parameters must be identifiers or any item that can be declared, MyMacro(pigment{Green},MyObject) for example. Added #local XE "#local"  IDENTIFIER= STATEMENT as alternative to #declare XE "#declare"  to create temporary local identifier in macros or include files. Arrays Added Added multi-dimension arrays XE "array"  #declare MyArray=array[20] or #local PrivateArray=array[30] or #declare Rows=5; #declare Cols=4; #declare Table=array[Rows][Cols] Added optional initializer syntax for arrays. #declare MyArray=array[2][3]{{1,2,3},{4,5,6}} Subscripts start at 0. Anything that can be declared may be in an array. Arrays are initialized as null. You must later fill each element with values. Added float functions for arrays. Given #declare MyArray = array[4][5] then dimensions XE "dimensions" (MyArray) is 2 and dimension_size XE "dimension_size" (MyArray,2) is 5. File I/O and other Directives Added #fopen XE "#fopen" , #fclose XE "#fclose" , #read XE "#read" , and #write XE "#write"  directives for user text files. Added #undef XE "#undef"  identifier directive. Un-declares previously declared identifier. Works on locals or globals. Added requirement that any directive which can end in a float or expression must be terminated by a semi-colon. Specifically this means any #declare XE "#declare"  or #local of float, vector or color or the #version XE "#version"  directive. Additional New Features Added Bezier splines to lathe XE "lathe"  and prism XE "prism" . The spline is made of segments having four points each. Thus there are always four times the number of segments in a prism or lathe. A four point Bezier spline uses 3rd order Bernstein blending functions which are sufficient for smooth curves. Added float constant clock_delta XE "clock_delta"  returns time between frames. Beginning Tutorial The beginning tutorial explains step by step how to use POV-Ray's scene description language to create own your scenes. The use of almost every feature of POV-Ray's language is explained in detail. We will learn basic things like placing cameras and light sources. We will also learn how to create a large variety of objects and how to assign different textures to them. The more sophisticated features like radiosity, interior, media and atmospheric effects will be explained in detail. Our First Image We will create the scene file for a simple picture. Since ray-tracers thrive on spheres, that is what we will render first. Understanding POV-Ray's Coordinate System First, we have to tell POV-Ray where our camera is and where it is looking. To do this, we use 3D coordinates. The usual coordinate system for POV-Ray has the positive y-axis pointing up, the positive x-axis pointing to the right, and the positive z-axis pointing into the screen as follows:  The left-handed coordinate system (the z-axis is pointing away) This kind of coordinate system is called a left-handed coordinate system. If we use our left hand's fingers we can easily see why it is called left-handed. We just point our thumb in the direction of the positive x-axis (to the right), the index finger in the direction of the positive y-axis (straight up) and the middle finger in the positive z-axis direction (forward). We can only do this with our left hand. If we had used our right hand we would not have been able to point the middle finger in the correct direction. The left hand can also be used to determine rotation directions. To do this we must perform the famous "Computer Graphics Aerobics" exercise. We hold up our left hand and point our thumb in the positive direction of the axis of rotation. Our fingers will curl in the positive direction of rotation. Similarly if we point our thumb in the negative direction of the axis our fingers will curl in the negative direction of rotation.  "Computer Graphics Aerobics" to determine the rotation direction. In the above illustration, the left hand is curling around the x-axis. The thumb points in the positive x direction and the fingers curl over in the positive rotation direction. If we want to use a right-handed system, as some CAD systems and modelers do, the right XE "right"  vector in the camera specification needs to be changed. See the detailed description in " REF _Ref411611541 \h Handedness". In a right-handed system we use our right hand for the "Aerobics". There is some controversy over whether POV-Ray's method of doing a right-handed system is really proper. To avoid problems we stick with the left-handed system which is not in dispute. Adding Standard Include Files  XE "#include" Using our personal favorite text editor, we create a file called demo.pov. Note some versions of POV-Ray come with their own built-in text editor which may be easier to use. We then type in the following text. The input is case sensitive, so we have to be sure to get capital and lowercase letters correct. #include "colors.inc" // The include files contain #include "stones.inc" // pre-defined scene elements The first include statement reads in definitions for various useful colors. The second include statement reads in a collection of stone textures. POV-Ray comes with many standard include files. Others of interest are: #include "textures.inc" // pre-defined scene elements #include "shapes.inc" #include "glass.inc" #include "metals.inc" #include "woods.inc" They read pre-defined textures, shapes, glass, metal, and wood textures. It is a good idea to have a look through them to see a few of the many possible shapes and textures available. We should only include files we really need in our scene. Some of the include files coming with POV-Ray are quite large and we should better save the parsing time and memory if we don't need them. In the following examples we will only use the colors.inc, and stones.inc include files. We may have as many include files as needed in a scene file. Include files may themselves contain include files, but we are limited to declaring includes nested only ten levels deep. Filenames specified in the include statements will be searched for in the current directory first. If it fails to find your .Inc files in the current directory, POV-Ray searches any "library paths" that you have specified. Library paths are options set by the +L XE "+L"  command-line switch or Library_Path XE "Library_Path"  option. See the chapter " REF _Ref411667354 \h Setting POV-Ray Options" for more information on library paths. Because it is more useful to keep include files in a separate directory, standard installation of POV-Ray place these files in the \povray3\include directory. If you get an error message saying that POV-Ray cannot open "colors.inc" or other include files, make sure that you specify the library path properly. Adding a Camera The camera XE "camera"  statement describes where and how the camera sees the scene. It gives x-, y- and z-coordinates to indicate the position of the camera and what part of the scene it is pointing at. We describe the coordinates using a three-part vector. A vector is specified by putting three numeric values between a pair of angle brackets and separating the values with commas. We add the following camera statement to the scene. camera { location <0, 2, -3> look_at <0, 1, 2> } Briefly, location <0,2,-3> places the camera up two units and back three units from the center of the ray-tracing universe which is at <0,0,0>. By default +z is into the screen and -z is back out of the screen. Also look_at <0,1,2> rotates the camera to point at the coordinates <0,1,2>. A point 1 unit up from the origin and 2 units away from the origin. This makes it 5 units in front of and 1 unit lower than the camera. The look_at point should be the center of attention of our image. Describing an Object Now that the camera is set up to record the scene, let's place a yellow sphere into the scene. We add the following to our scene file: sphere { <0, 1, 2>, 2 texture { pigment { color Yellow } } } The first vector specifies the center of the sphere. In this example the x coordinate is zero so it is centered left and right. It is also at y=1 or one unit up from the origin. The z coordinate is 2 which is five units in front of the camera, which is at z=-3. After the center vector is a comma followed by the radius which in this case is two units. Since the radius is half the width of a sphere, the sphere is four units wide. Adding Texture to an Object  XE "texture" After we have defined the location and size of the sphere, we need to describe the appearance of the surface. The texture statement specifies these parameters. Texture blocks describe the color, bumpiness and finish properties of an object. In this example we will specify the color only. This is the minimum we must do. All other texture options except color will use default values. The color we define is the way we want an object to look if fully illuminated. If we were painting a picture of a sphere we would use dark shades of a color to indicate the shadowed side and bright shades on the illuminated side. However ray-tracing takes care of that for you. We only need to pick the basic color inherent in the object and POV-Ray brightens or darkens it depending on the lighting in the scene. Because we are defining the basic color the object actually has rather than how it looks the parameter is called pigment. Many types of color patterns are available for use in a pigment statement. The keyword color XE "color"  specifies that the whole object is to be one solid color rather than some pattern of colors. We can use one of the color identifiers previously defined in the standard include file colors.inc. If no standard color is available for our needs, we may define our own color by using the color keyword followed by red XE "red" , green XE "green" , and blue XE "blue"  keywords specifying the amount of red, green and blue to be mixed. For example a nice shade of pink can be specified by: color red 1.0 green 0.8 blue 0.8 The values after each keyword should be in the range from 0.0 to 1.0. Any of the three components not specified will default to 0. A shortcut notation may also be used. The following produces the same shade of pink: color rgb <1.0, 0.8, 0.8> Colors are explained in more detail in section " REF _Ref413394014 \h Specifying Colors". Defining a Light Source One more detail is needed for our scene. We need a light source XE "light source" . Until we create one, there is no light in this virtual world. Thus we add the line Thus we add the line light_source { <2, 4, -3> color White} to the scene file to get our first complete POV-Ray scene file as shown below. #include "colors.inc" background { color Cyan } camera { location <0, 2, -3> look_at <0, 1, 2> } sphere { <0, 1, 2>, 2 texture { pigment { color Yellow } } } light_source { <2, 4, -3> color White} The vector in the light_source XE "light_source"  statement specifies the location of the light as two units to our right, four units above the origin and three units back from the origin. The light source is an invisible tiny point that emits light. It has no physical shape, so no texture is needed. That's it! We close the file and render a small picture of it using whatever methods you used for your particular platform. If you specified a preview display it will appear on your screen. If you specified an output file (the default is file output on), then POV-Ray also created a file. Note that if you do not have high color or true color display hardware then the preview image may look poor but the full detail is written to the image file regardless of the type of display. The scene we just traced isn't quite state of the art but we will have to start with the basics before we soon get to much more fascinating features and scenes. Simple Shapes So far we have just used the sphere shape. There are many other types of shapes that can be rendered by POV-Ray. The following sections will describe how to use some of the more simple objects as a replacement for the sphere used above. Box Object The box XE "box"  is one of the most common objects used. We try this example in place of the sphere: box { <-1, 0, -1>, // Near lower left corner < 1, 0.5, 3> // Far upper right corner texture { T_Stone25 // Pre-defined from stones.inc scale 4 // Scale by the same amount in all // directions } rotate y*20 // Equivalent to "rotate <0,20,0>" } In the example we can see that a box is defined by specifying the 3D coordinates of its opposite corners. The first vector is generally the minimum x-, y- and z-coordinates and the 2nd vector should be the maximum x-, y- and z-values however any two opposite corners may be used. Box objects can only be defined parallel to the axes of the world coordinate system. We can later rotate them to any angle. Note that we can perform simple math on values and vectors. In the rotate parameter we multiplied the vector identifier y by 20. This is the same as <0,1,0>*20 or <0,20,0>. Cone Object Here's another example showing how to use a cone XE "cone" : cone { <0, 1, 0>, 0.3 // Center and radius of one end <1, 2, 3>, 1.0 // Center and radius of other end texture { T_Stone25 scale 4 } } The cone shape is defined by the center and radius of each end. In this example one end is at location <0,1,0> and has a radius of 0.3 while the other end is centered at <1,2,3> with a radius of 1. If we want the cone to come to a sharp point we must use radius=0. The solid end caps are parallel to each other and perpendicular to the cone axis. If we want an open cone with no end caps we have to add the keyword open XE "open"  after the 2nd radius like this: cone { <0, 1, 0>, 0.3 // Center and radius of one end <1, 2, 3>, 1.0 // Center and radius of other end open // Removes end caps texture { T_Stone25 scale 4 } } Cylinder Object We may also define a cylinder XE "cylinder"  like this: cylinder { <0, 1, 0>, // Center of one end <1, 2, 3>, // Center of other end 0.5 // Radius open // Remove end caps texture { T_Stone25 scale 4 } } Plane Object  XE "plane" Let's try out a computer graphics standard "The Checkered Floor". We add the following object to the first version of the demo.pov file, the one including the sphere. plane { <0, 1, 0>, -1 pigment { checker color Red, color Blue } } The object defined here is an infinite plane. The vector <0,1,0> is the surface normal of the plane (i.e. if we were standing on the surface, the normal points straight up). The number afterward is the distance that the plane is displaced along the normal from the origin -- in this case, the floor is placed at y=-1 so that the sphere at y=1, radius=2, is resting on it. We note that even though there is no texture statement there is an implied texture here. We might find that continually typing statements that are nested like texture {pigment} can get to be tiresome so POV-Ray let's us leave out the texture statement under many circumstances. In general we only need the texture block surrounding a texture identifier (like the T_Stone25 example above), or when creating layered textures (which are covered later). This pigment uses the checker color pattern and specifies that the two colors red and blue should be used. Because the vectors <1,0,0>, <0,1,0> and <0,0,1> are used frequently, POV-Ray has three built-in vector identifiers x XE "x" , y XE "y"  and z XE "z"  respectively that can be used as a shorthand. Thus the plane could be defined as: plane { y, -1 pigment { ... } } Note that we do not use angle brackets around vector identifiers. Looking at the floor, we notice that the ball casts a shadow on the floor. Shadows are calculated very accurately by the ray-tracer, which creates precise, sharp shadows. In the real world, penumbral or "soft" shadows are often seen. Later we will learn how to use extended light sources to soften the shadows. CSG Objects Constructive  XE "constructive solid geometry"  XE "CSG" Solid Geometry, or CSG, is a powerful tool to combine primitive objects to create more complex objects as shown in the following sections. What is CSG? CSG  XE "constructive solid geometry"  XE "CSG" stands for Constructive Solid Geometry. POV-Ray allows us to construct complex solids by combining primitive shapes in four different ways. In the union statement, two or more shapes are added together. With the intersection statement, two or more shapes are combined to make a new shape that consists of the area common to both shapes. The difference statement, an initial shape has all subsequent shapes subtracted from it. And last not least merge, which is like a union where the surfaces inside the union are removed (useful in transparent CSG objects). We will deal with each of these in detail in the next few sections. CSG objects can be extremely complex. They can be deeply nested. In other words there can be unions of differences or intersections of merges or differences of intersections or even unions of intersections of differences of merges... ad infinitum. CSG objects are (almost always) finite objects and thus respond to auto-bounding and can be transformed like any other POV primitive shape. CSG Union Let's try making a simple  XE "union" union. Create a file called csgdemo.pov and edit it as follows: #include "colors.inc" camera { location <0, 1, -10> look_at 0 angle 36 } light_source { <500, 500, -1000> White } plane { y, -1.5 pigment { checker Green White } } Let's add two spheres each translated 0.5 units along the x-axis in each direction. We color one blue and the other red. sphere { <0, 0, 0>, 1 pigment { Blue } translate -0.5*x } sphere { <0, 0, 0>, 1 pigment { Red } translate 0.5*x } We trace this file and note the results. Now we place a union block around the two spheres. This will create a single CSG union out of the two objects. union{ sphere { <0, 0, 0>, 1 pigment { Blue } translate -0.5*x } sphere { <0, 0, 0>, 1 pigment { Red } translate 0.5*x } } We trace the file again. The union will appear no different from what each sphere looked like on its own, but now we can give the entire union a single texture and transform it as a whole. Let's do that now. union{ sphere { <0, 0, 0>, 1 translate -0.5*x } sphere { <0, 0, 0>, 1 translate 0.5*x } pigment { Red } scale <1, .25, 1> rotate <30, 0, 45> } We trace the file again. As we can see, the object has changed dramatically. We experiment with different values of scale and rotate and try some different textures. There are many advantages of assigning only one texture to a CSG object instead of assigning the texture to each individual component. First, it is much easier to use one texture if our CSG object has a lot of components because changing the objects appearance involves changing only one single texture. Second, the file parses faster because the texture has to be parsed only once. This may be a great factor when doing large scenes or animations. Third, using only one texture saves memory because the texture is only stored once and referenced by all components of the CSG object. Assigning the texture to all n components means that it is stored n times. CSG Intersection Now let's use these same spheres to illustrate the next kind of CSG object,  XE "intersection" the intersection. We change the word union to intersection and delete the scale and rotate statements: intersection { sphere { <0, 0, 0>, 1 translate -0.5*x } sphere { <0, 0, 0>, 1 translate 0.5*x } pigment { Red } } We trace the file and will see a lens-shaped object instead of the two spheres. This is because an intersection consists of the area shared by both shapes, in this case the lens-shaped area where the two spheres overlap. We like this lens-shaped object so we will use it to demonstrate differences. CSG Difference  XE "difference" We rotate the lens-shaped intersection about the y-axis so that the broad side is facing the camera. intersection{ sphere { <0, 0, 0>, 1 translate -0.5*x } sphere { <0, 0, 0>, 1 translate 0.5*x } pigment { Red } rotate 90*y } Let's create a cylinder and stick it right in the middle of the lens. cylinder { <0, 0, -1> <0, 0, 1>, .35 pigment { Blue } } We render the scene to see the position of the cylinder. We will place a difference block around both the lens-shaped intersection and the cylinder like this: difference { intersection { sphere { <0, 0, 0>, 1 translate -0.5*x } sphere { <0, 0, 0>, 1 translate 0.5*x } pigment { Red } rotate 90*y } cylinder { <0, 0, -1> <0, 0, 1>, .35 pigment { Blue } } } We render the file again and see the lens-shaped intersection with a neat hole in the middle of it where the cylinder was. The cylinder has been subtracted from the intersection. Note that the pigment of the cylinder causes the surface of the hole to be colored blue. If we eliminate this pigment the surface of the hole will be red. OK, let's get a little wilder now. Let's declare our perforated lens object to give it a name. Let's also eliminate all textures in the declared object because we will want them to be in the final union instead. #declare Lens_With_Hole = difference { intersection { sphere { <0, 0, 0>, 1 translate -0.5*x } sphere { <0, 0, 0>, 1 translate 0.5*x } rotate 90*y } cylinder { <0, 0, -1> <0, 0, 1>, .35 } } Let's use a union to build a complex shape composed of copies of this object. union { object { Lens_With_Hole translate <-.65, .65, 0> } object { Lens_With_Hole translate <.65, .65, 0> } object { Lens_With_Hole translate <-.65, -.65, 0> } object { Lens_With_Hole translate <.65, -.65, 0> } pigment { Red } } We render the scene. An interesting object to be sure. But let's try something more. Let's make it a partially-transparent object by adding some filter to the pigment block. union { object { Lens_With_Hole translate <-.65, .65, 0> } object { Lens_With_Hole translate <.65, .65, 0> } object { Lens_With_Hole translate <-.65, -.65, 0> } object { Lens_With_Hole translate <.65, -.65, 0> } pigment { Red filter .5 } } We render the file again. This looks pretty good... only... we can see parts of each of the lens objects inside the union! This is not good. CSG Merge  XE "merge" This brings us to the fourth kind of CSG object, the merge. Merges are the same as unions, but the geometry of the objects in the CSG that is inside the merge is not traced. This should eliminate the problem with our object. Let's try it. merge { object { Lens_With_Hole translate <-.65, .65, 0> } object { Lens_With_Hole translate <.65, .65, 0> } object { Lens_With_Hole translate <-.65, -.65, 0> } object { Lens_With_Hole translate <.65, -.65, 0> } pigment { Red filter .5 } } Sure enough, it does! CSG Pitfalls There is a severe pitfall in the CSG code that we have to be aware of. Coincidence Surfaces POV-Ray uses inside/outside tests to determine the points at which a ray intersects a CSG object. A problem arises when the surfaces of two different shapes coincide because there is no way (due to numerical problems) to tell whether a point on the coincident surface belongs to one shape or the other. Look at the following example where a cylinder is used to cut a hole in a larger box. difference { box { -1, 1 pigment { Red } } cylinder { -z, z, 0.5 pigment { Green } } } Note that the vectors -1 and 1 in the box definition expand to <-1,-1,-1> and <1,1,1> respectively. If we trace this object we see red speckles where the hole is supposed to be. This is caused by the coincident surfaces of the cylinder and the box. One time the cylinder's surface is hit first by a viewing ray, resulting in the correct rendering of the hole, and another time the box is hit first, leading to a wrong result where the hole vanishes and red speckles appear. This problem can be avoided by increasing the size of the cylinder to get rid of the coincidence surfaces. This is done by: difference { box { -1, 1 pigment { Red } } cylinder { -1.001*z, 1.001*z, 0.5 pigment { Green } } } In general we have to make the subtracted object a little bit larger in a CSG difference. We just have to look for coincident surfaces and increase the subtracted object appropriately to get rid of those surfaces. The same problem occurs in CSG intersections and is also avoided by scaling some of the involved objects. Advanced Shapes After we have gained some experience with the simpler shapes available in POV-Ray it is time to go on to the more advanced, thrilling shapes. We should be aware that the shapes described below are not trivial to understand. We needn't be worried though if we do not know how to use them or how they work. We just try the examples and play with the features described in the reference chapter. There is nothing better than learning by doing. You may wish to skip to the chapter " REF _Ref411671219 \h Simple Texture Options" before proceeding with these advanced shapes. Bicubic Patch Object  XE "bicubic_patch"  XE "Bezier patch" Bicubic or Bezier patches are useful surface representations because they allow an easy definition of surfaces using only a few control points. The control points serve to determine the shape of the patch. Instead of defining the vertices of triangles, we simply give the coordinates of the control points. A single patch has 16 control points, one at each corner, and the rest positioned to divide the patch into smaller sections. For ray-tracing (or rendering) the patches are approximated using triangles. Bezier patches are almost always created using a third party modeler so for this tutorial, we will use moray (any other modeler that supports Bezier patches and POV-Ray can also be used). We will use moray only to create the patch itself, not the other elements of the scene. Note that moray is not included with POV-Ray. It is a separate shareware program that currently only runs on MS-Dos and Win95/NT but this tutorial assumes you are using the MS-Dos version. If you do not have moray or are not on MS-Dos, you can still render the sample scene described below, even though you cannot see how moray created it. Simply type in the bicubic_patch declaration listed below. Bezier patches are actually very useful and, with a little practice, some pretty amazing things can be created with them. For our first tutorial, let's make a sort of a teepee/tent shape using a single sheet patch. First, we start moray and, from the main edit screen, we click on "CREATE". We Name our object Teepee. The "CREATE BEZIER PATCH" dialogue box will appear. We have to make sure that "SHEET" is depressed. We click on "OK, CREATE". At the bottom of the main edit screen, we click on "EXTENDED EDIT". We hold the cursor over the "TOP" view and right click to make the pop-up menu appear. We click on "MAXIMIZE". We [ALT]-drag to zoom in a little. We click on "MARK ALL", and under the transformation mode box, "UFRM SCL". We drag the mouse to scale the patch until it is approximately four units wide. We click on "TRANSLATE", and move the patch so that its center is over the origin. We right click "MINIMIZE" and "UNMARK ALL". We [SHIFT]-drag a box around the lower right control point to mark it. We [ALT]-zoom into the "FRONT" view so that we can see the patch better. In the "FRONT" view, we "TRANSLATE" that point 10 units along the negative z-axis (we note that in MORAY z is up). We "UNMARK ALL". We repeat this procedure for each of the other three corner points. We make sure we remember to "UNMARK ALL" once each point has been translated. We should have a shape that looks as though it is standing on four pointed legs. We "UNMARK ALL". Working once again in the "TOP" view, we [SHIFT]-drag a box around the four center control points to mark them. We right-click over the "TOP" view and "MAXIMIZE". We click on "UFRM SCL" and drag the mouse to scale the four points close together. We [ALT]-drag to zoom closer and get them as close together as we can. We [ALT]-drag to zoom out, right click and "MINIMIZE". In the "FRONT" view, we "TRANSLATE" the marked points 10 units along the positive z-axis. We "UNMARK ALL". The resulting shape is quite interesting, was simple to model, and could not be produced using CSG primitives. Now let's use it in a scene. We click on "DONE" to return to the main edit screen. We note that u_steps and v_steps are both set to 3 and flatness is set to 0.01. We leave them alone for now. We click on "FILES" and then "SAVE SEL" (save selection). We name our new file teepee1.mdl. We press [F3] and open teepee1.mdl. There is no need to save the original file. When teepee1 is open, we create a quick "dummy" texture (moray will not allow us to export data without a texture). We use white with default finish and name it TeePeeTex. We apply it to the object, save the file and press [CTRL-F9]. moray will create two files: teepee1.inc and teepee1.pov. We exit moray and copy teepee1.inc and teepee1.pov into our working directory where we are doing these tutorials. We create a new file called bezdemo.pov and edit it as follows: #include "colors.inc" camera { location <0, .1, -60> look_at 0 angle 40 } background { color Gray25 } //to make the patch easier to see light_source { <300, 300, -700> White } plane { y, -12 texture { pigment { checker color Green color Yellow } } } Using a text editor, we create and declare a simple texture for our teepee object: #declare TeePeeTex = texture { pigment { color rgb <1, 1, 1,> } finish { ambient .2 diffuse .6 } } We paste in the bezier patch data from teepee1.pov (the additional object keywords added by moray were removed): bicubic_patch { type 1 flatness 0.0100 u_steps 3 v_steps 3, <-5.174134, 5.528420, -13.211995>, <-1.769023, 5.528420, 0.000000>, <1.636088, 5.528420, 0.000000>, <5.041199, 5.528420, -13.003932>, <-5.174134, 1.862827, 0.000000>, <0.038471, 0.031270, 18.101474>, <0.036657, 0.031270, 18.101474>, <5.041199, 1.862827, 0.000000>, <-5.174134, -1.802766, 0.000000>, <0.038471, 0.028792, 18.101474>, <0.036657, 0.028792, 18.101474>, <5.041199, -1.802766, 0.000000>, <-5.174134, -5.468359, -13.070366>, <-1.769023, -5.468359, 0.000000>, <1.636088, -5.468359, 0.000000>, <4.974128, -5.468359, -12.801446> texture { TeePeeTex } rotate -90*x // to orient the object to LHC rotate 25*y // to see the four "legs" better } We add the above rotations so that the patch is oriented to POV-Ray's left-handed coordinate system (remember the patch was made in moray in a right handed coordinate system), so we can see all four legs. Rendering this at 200x150 -a we see pretty much what we expect, a white teepee over a green and yellow checkered plane. Let's take a little closer look. We render it again, this time at 320x200. Now we see that something is amiss. There appears to be sharp angling, almost like facing, especially near the top. This is indeed a kind of facing and is due to the u_steps XE "u_steps"  and v_steps XE "v_steps"  parameters. Let's change these from 3 to 4 and see what happens. That's much better, but it took a little longer to render. This is an unavoidable tradeoff. If we want even finer detail, we must use a u_steps and v_steps value of 5 and set flatness to 0. But we must expect to use lots of memory and an even longer tracing time. Well, we can't just leave this scene without adding a few items just for interest. We declare the patch object and scatter a few of them around the scene: #declare TeePee = bicubic_patch { type 1 flatness 0.0100 u_steps 3 v_steps 3, <-5.174134, 5.528420, -13.211995>, <-1.769023, 5.528420, 0.000000>, <1.636088, 5.528420, 0.000000>, <5.041199, 5.528420, -13.003932>, <-5.174134, 1.862827, 0.000000>, <0.038471, 0.031270, 18.101474>, <0.036657, 0.031270, 18.101474>, <5.041199, 1.862827, 0.000000>, <-5.174134, -1.802766, 0.000000>, <0.038471, 0.028792, 18.101474>, <0.036657, 0.028792, 18.101474>, <5.041199, -1.802766, 0.000000>, <-5.174134, -5.468359, -13.070366>, <-1.769023, -5.468359, 0.000000>, <1.636088, -5.468359, 0.000000>, <4.974128, -5.468359, -12.801446> texture { TeePeeTex } rotate -90*x // to orient the object to LHC rotate 25*y // to see the four "legs" better } object { TeePee } object { TeePee translate <8, 0, 8> } object { TeePee translate <-9, 0, 9> } object { TeePee translate <18, 0, 24> } object { TeePee translate <-18, 0, 24> } That looks good. Let's do something about that boring gray background. We delete the background declaration and replace it with: plane { y, 500 texture { pigment { SkyBlue } finish { ambient 1 diffuse 0} } texture { pigment { bozo turbulence .5 color_map { [0 White] [1 White filter 1] } } finish { ambient 1 diffuse 0 } scale <1000, 250, 250> rotate <5, 45, 0> } } This adds a pleasing cirrus-cloud filled sky. Now, let's change the checkered plane to rippled sand dunes: plane {y,-12 texture { pigment { color <.85, .5, .15> } finish { ambient .25 diffuse .6 crand .5 } normal { ripples .35 turbulence .25 frequency 5 } scale 10 translate 50*x } } We render this. Not bad! Let's just add one more element. Let's place a golden egg under each of the teepees. And since this is a bezier patch tutorial, let's make the eggs out of bezier patches. We return to moray and create another bezier patch. We name it Egg1 and select "CYLINDRICAL 2 - PATCH" from the "CREATE BEZIER PATCH" dialogue box. We click on "EXTENDED EDIT". We "MARK ALL" and rotate the patch so that the cylinder lays on its side. We "UNMARK ALL". In the "FRONT" view, we [SHIFT]-drag a box around the four points on the right end to mark them. In the "SIDE" view, we right click and "MAXIMIZE". We [ALT]-drag to zoom in a little closer. We "UFRM SCL" the points together as close as possible. We zoom in closer to get them nice and tight. We zoom out, right click and "MINIMIZE". We click on "TRANSLATE" and drag the points to the left so that they are aligned on the z-axis with the next group of four points. This should create a blunt end to the patch. We repeat this procedure for the other end. We "UNMARK ALL". In the "FRONT" view, the control grid should be a rectangle now and the patch should be an ellipsoid. We [SHIFT]-drag a box around the upper right corner of the control grid to mark those points. We then [SHIFT]-drag a box around the lower right corner to mark those points as well. In the "SIDE" view, we "UFRM SCL" the points apart a little to make that end of the egg a little wider than the other. We "UNMARK ALL". The egg may need a little proportional adjustment. We should be able to "MARK ALL" and "LOCAL SCL" in the three views until we get it to look like an egg. When we are satisfied that it does, we "UNMARK ALL" and click on done. Learning from our teepee object, we now go ahead and change u_steps and v_steps to 4. We create a dummy texture, white with default finish, name it EggTex and apply it to the egg. From the FILES menu, we "SAVE SEL" to filename egg1.mdl. We load this file and export ([CTRL F9]). We exit moray and copy the files egg1.inc and egg1.pov into our working directory. Back in bezdemo.pov, we create a nice, shiny gold texture: #declare EggTex = texture { pigment { BrightGold } finish { ambient .1 diffuse .4 specular 1 roughness 0.001 reflection .5 metallic } } And while we're at it, let's dandy up our TeePeeTex texture: #declare TeePeeTex = texture { pigment { Silver } finish { ambient .1 diffuse .4 specular 1 roughness 0.001 reflection .5 metallic } } Now we paste in our egg patch data and declare our egg: #declare Egg = union { // Egg1 bicubic_patch { type 1 flatness 0.0100 u_steps 4 v_steps 4, <2.023314, 0.000000, 4.355987>, <2.023314, -0.000726, 4.355987>, <2.023312, -0.000726, 4.356867>, <2.023312, 0.000000, 4.356867>, <2.032037, 0.000000, 2.734598>, <2.032037, -1.758562, 2.734598>, <2.027431, -1.758562, 6.141971>, <2.027431, 0.000000, 6.141971>, <-1.045672, 0.000000, 3.281572>, <-1.045672, -1.758562, 3.281572>, <-1.050279, -1.758562, 5.414183>, <-1.050279, 0.000000, 5.414183>, <-1.044333, 0.000000, 4.341816>, <-1.044333, -0.002947, 4.341816>, <-1.044341, -0.002947, 4.345389>, <-1.044341, 0.000000, 4.345389> } bicubic_patch { type 1 flatness 0.0100 u_steps 4 v_steps 4, <2.023312, 0.000000, 4.356867>, <2.023312, 0.000726, 4.356867>, <2.023314, 0.000726, 4.355987>, <2.023314, 0.000000, 4.355987>, <2.027431, 0.000000, 6.141971>, <2.027431, 1.758562, 6.141971>, <2.032037, 1.758562, 2.734598>, <2.032037, 0.000000, 2.734598>, <-1.050279, 0.000000, 5.414183>, <-1.050279, 1.758562, 5.414183>, <-1.045672, 1.758562, 3.281572>, <-1.045672, 0.000000, 3.281572>, <-1.044341, 0.000000, 4.345389>, <-1.044341, 0.002947, 4.345389>, <-1.044333, 0.002947, 4.341816>, <-1.044333, 0.000000, 4.341816> } texture { EggTex } translate <0.5, 0, -5> // centers the egg around the origin translate -9.8*y // places the egg on the ground } We now place a copy of the egg under each teepee. This should require only the x- and z-coordinates of each teepee to be changed: object { Egg } object { Egg translate <8, 0, 8> } object { Egg translate <-9, 0, 9> } object { Egg translate <18, 0, 24> } object { Egg translate <-18, 0, 24> }  Scene build with different Bezier patches. We render this at low resolution such as 320x240. Everything looks good so we run it again at 640x480. Now we see that there is still some facing near the top of the teepees and on the eggs as well. The only solution is to raise u_steps and v_steps from 4 to 5 and set flatness to 0 for all our bezier objects. We make the changes and render it again at 640x480. The facets are gone. Blob Object Blobs are described as spheres and cylinders covered with "goo" which stretches to smoothly join them (see section " REF _Ref428631930 \h Blob"). Ideal for modeling atoms and molecules, blobs are also powerful tools for creating many smooth flowing "organic" shapes. A slightly more mathematical way of describing a blob would be to say that it is one object made up of two or more component pieces. Each piece is really an invisible field of force which starts out at a particular strength and falls off smoothly to zero at a given radius. Where ever these components overlap in space, their field strength gets added together (and yes, we can have negative strength which gets subtracted out of the total as well). We could have just one component in a blob, but except for seeing what it looks like there is little point, since the real beauty of blobs is the way the components interact with one another. Let us take a simple example blob to start. Now, in fact there are a couple different types of components but we will look at them a little later. For the sake of a simple first example, let us just talk about spherical components. Here is a sample POV-Ray code showing a basic camera, light, and a simple two component blob (this scene is called blobdem1.pov): #include "colors.inc" background{White} camera { angle 15 location <0,2,-10> look_at <0,0,0> } light_source { <10, 20, -10> color White } blob { threshold .65 sphere { <.5,0,0>, .8, 1 pigment {Blue} } sphere { <-.5,0,0>,.8, 1 pigment {Pink} } finish { phong 1 } }  A simple, two-part blob. The threshold is simply the overall strength value at which the blob becomes visible. Any points within the blob where the strength matches the threshold exactly form the surface of the blob shape. Those less than the threshold are outside and those greater than are inside the blob. We note that the spherical component looks a lot like a simple sphere object. We have the sphere keyword, the vector representing the location of the center of the sphere and the float representing the radius of the sphere. But what is that last float value? That is the individual strength of that component. In a spherical component, that is how strong the component's field is at the center of the sphere. It will fall off in a linear progression until it reaches exactly zero at the radius of the sphere. Before we render this test image, we note that we have given each component a different pigment. POV-Ray allows blob components to be given separate textures. We have done this here to make it clearer which parts of the blob are which. We can also texture the whole blob as one, like the finish statement at the end, which applies to all components since it appears at the end, outside of all the components. We render the scene and get a basic kissing spheres type blob. The image we see shows the spheres on either side, but they are smoothly joined by that bridge section in the center. This bridge represents where the two fields overlap, and therefore stay above the threshold for longer than elsewhere in the blob. If that is not totally clear, we add the following two objects to our scene and re-render (see file blobdem2.pov). We note that these are meant to be entered as separate sphere objects, not more components in the blob. sphere { <.5,0,0>, .8 pigment { Yellow transmit .75 } } sphere { <-.5,0,0>, .8 pigment { Green transmit .75 } }  The spherical components made visible. Now the secrets of the kissing spheres are laid bare. These semi-transparent spheres show where the components of the blob actually are. If we have not worked with blobs before, we might be surprised to see that the spheres we just added extend way farther out than the spheres that actually show up on the blobs. That of course is because our spheres have been assigned a starting strength of one, which gradually fades to zero as we move away from the sphere's center. When the strength drops below the threshold (in this case 0.65) the rest of the sphere becomes part of the outside of the blob and therefore is not visible. See the part where the two transparent spheres overlap? We note that it exactly corresponds to the bridge between the two spheres. That is the region where the two components are both contributing to the overall strength of the blob at that point. That is why the bridge appears: that region has a high enough strength to stay over the threshold, due to the fact that the combined strength of two spherical components is overlapping there. Component Types and Other New Features The shape shown so far is interesting, but limited. POV-Ray has a few extra tricks that extend its range of usefulness however. For example, as we have seen, we can assign individual textures to blob components, we can also apply individual transformations (translate, rotate and scale) to stretch, twist, and squash pieces of the blob as we require. And perhaps most interestingly, the blob code has been extended to allow cylindrical components. Before we move on to cylinders, it should perhaps be mentioned that the old style of components used in previous versions of POV-Ray still work. Back then, all components were spheres, so it was not necessary to say sphere or cylinder. An old style component had the form: component Strength, Radius,
This has the same effect as a spherical component, just as we already saw above. This is only useful for backwards compatibility. If we already have POV-Ray files with blobs from earlier versions, this is when we would need to recognize these components. We note that the old style components did not put braces around the strength, radius and center, and of course, we cannot independently transform or texture them. Therefore if we are modifying an older work into a new version, it may arguably be of benefit to convert old style components into spherical components anyway.  XE "cylinder" Now for something new and different: cylindrical components. It could be argued that all we ever needed to do to make a roughly cylindrical portion of a blob was string a line of spherical components together along a straight line. Which is fine, if we like having extra to type, and also assuming that the cylinder was oriented along an axis. If not, we would have to work out the mathematical position of each component to keep it is a straight line. But no more! Cylindrical components have arrived. We replace the blob in our last example with the following and re-render. We can get rid of the transparent spheres too, by the way. blob { threshold .65 cylinder { <-.75,-.75,0>, <.75,.75,0>, .5, 1 } pigment { Blue } finish { phong 1 } } We only have one component so that we can see the basic shape of the cylindrical component. It is not quite a true cylinder - more of a sausage shape, being a cylinder capped by two hem-spheres. We think of it as if it were an array of spherical components all closely strung along a straight line. As for the component declaration itself: simple, logical, exactly as we would expect it to look (assuming we have been awake so far): it looks pretty much like the declaration of a cylinder object, with vectors specifying the two endpoints and a float giving the radius of the cylinder. The last float, of course, is the strength of the component. Just as with spherical components, the strength will determine the nature and degree of this component's interaction with its fellow components. In fact, next let us give this fellow something to interact with, shall we? Complex Blob Constructs and Negative Strength Beginning a new POV-Ray file called blobdem3.pov, we enter this somewhat more complex example: #include "colors.inc" background{White} camera { angle 20 location<0,2,-10> look_at<0,0,0> } light_source { <10, 20, -10> color White } blob { threshold .65 sphere { <-.23,-.32,0>,.43, 1 scale <1.95,1.05,.8> } //palm sphere { <+.12,-.41,0>,.43, 1 scale <1.95,1.075,.8> } //palm sphere { <-.23,-.63,0>, .45, .75 scale <1.78, 1.3,1> } //midhand sphere { <+.19,-.63,0>, .45, .75 scale <1.78, 1.3,1> } //midhand sphere { <-.22,-.73,0>, .45, .85 scale <1.4, 1.25,1> } //heel sphere { <+.19,-.73,0>, .45, .85 scale <1.4, 1.25,1> } //heel cylinder { <-.65,-.28,0>, <-.65,.28,-.05>, .26, 1 } //lower pinky cylinder { <-.65,.28,-.05>, <-.65, .68,-.2>, .26, 1 } //upper pinky cylinder { <-.3,-.28,0>, <-.3,.44,-.05>, .26, 1 } //lower ring cylinder { <-.3,.44,-.05>, <-.3, .9,-.2>, .26, 1 } //upper ring cylinder { <.05,-.28,0>, <.05, .49,-.05>, .26, 1 } //lower middle cylinder { <.05,.49,-.05>, <.05, .95,-.2>, .26, 1 } //upper middle cylinder { <.4,-.4,0>, <.4, .512, -.05>, .26, 1 } //lower index cylinder { <.4,.512,-.05>, <.4, .85, -.2>, .26, 1 } //upper index cylinder { <.41, -.95,0>, <.85, -.68, -.05>, .25, 1 } //lower thumb cylinder { <.85,-.68,-.05>, <1.2, -.4, -.2>, .25, 1 } //upper thumb pigment { Flesh } }  A hand made with blobs. As we can guess from the comments, we are building a hand here. After we render this image, we can see there are a few problems with it. The palm and heel of the hand would look more realistic if we used a couple dozen smaller components rather than the half dozen larger ones we have used, and each finger should have three segments instead of two, but for the sake of a simplified demonstration, we can overlook these points. But there is one thing we really need to address here: This poor fellow appears to have horrible painful swelling of the joints! A review of what we know of blobs will quickly reveal what went wrong. The joints are places where the blob components overlap, therefore the combined strength of both components at that point causes the surface to extend further out, since it stays over the threshold longer. To fix this, what we need are components corresponding to the overlap region which have a negative strength to counteract part of the combined field strength. We add the following components to our blob (see file blobdem4.pov). sphere { <-.65,.28,-.05>, .26, -1 } //counteract pinky knuckle bulge sphere { <-.65,-.28,0>, .26, -1 } //counteract pinky palm bulge sphere { <-.3,.44,-.05>, .26, -1 } //counteract ring knuckle bulge sphere { <-.3,-.28,0>, .26, -1 } //counteract ring palm bulge sphere { <.05,.49,-.05>, .26, -1 } //counteract middle knuckle bulge sphere { <.05,-.28,0>, .26, -1 } //counteract middle palm bulge sphere { <.4,.512,-.05>, .26, -1 } //counteract index knuckle bulge sphere { <.4,-.4,0>, .26, -1 } //counteract index palm bulge sphere { <.85,-.68,-.05>, .25, -1 } //counteract thumb knuckle bulge sphere { <.41,-.7,0>, .25, -.89 } //counteract thumb heel bulge  The hand without the swollen joints. Much better! The negative strength of the spherical components counteracts approximately half of the field strength at the points where to components overlap, so the ugly, unrealistic (and painful looking) bulging is cut out making our hand considerably improved. While we could probably make a yet more realistic hand with a couple dozen additional components, what we get this time is a considerable improvement. Any by now, we have enough basic knowledge of blob mechanics to make a wide array of smooth, flowing organic shapes! Height Field Object  XE "height_field" A height_field is an object that has a surface that is determined by the color value or palette index number of an image designed for that purpose. With height fields, realistic mountains and other types of terrain can easily be made. First, we need an image from which to create the height field. It just so happens that POV-Ray is ideal for creating such an image. We make a new file called image.pov and edit it to contain the following: #include "colors.inc" global_settings { assumed_gamma 2.2 hf_gray_16 } The hf_gray_16 XE "hf_gray_16"  keyword causes the output to be in a special 16 bit grayscale that is perfect for generating height fields. The normal 8 bit output will lead to less smooth surfaces. Now we create a camera positioned so that it points directly down the z-axis at the origin. camera { location <0, 0, -10> look_at 0 } We then create a plane positioned like a wall at z=0. This plane will completely fill the screen. It will be colored with white and gray wrinkles. plane { z, 10 pigment { wrinkles color_map { [0 0.3*White] [1 White] } } } Finally, create a light source. light_source { <0, 20, -100> color White } We render this scene at 640x480 +A0.1 +FT. We will get an image that will produce an excellent height field. We create a new file called hfdemo.pov and edit it as follows: #include "colors.inc" We add a camera that is two units above the origin and ten units back ... camera{ location <0, 2, -10> look_at 0 angle 30 } ... and a light source. light_source{ <1000,1000,-1000> White } Now we add the height field. In the following syntax, a Targa image file is specified, the height field is smoothed, it is given a simple white pigment, it is translated to center it around the origin and it is scaled so that it resembles mountains and fills the screen. height_field { tga "image.tga" smooth pigment { White } translate <-.5, -.5, -.5> scale <17, 1.75, 17> } We save the file and render it at 320x240 -A. Later, when we are satisfied that the height field is the way we want it, we render it at a higher resolution with anti-aliasing.  A height field created completely with POV-Ray. Wow! The Himalayas have come to our computer screen! Lathe Object In the real world, lathe XE "lathe"  refers to a process of making patterned rounded shapes by spinning the source material in place and carving pieces out as it turns. The results can be elaborate, smoothly rounded, elegant looking artifacts such as table legs, pottery, etc. In POV-Ray, a lathe object is used for creating much the same kind of items, although we are referring to the object itself rather than the means of production. Here is some source for a really basic lathe (called lathdem1.pov). #include "colors.inc" background{White} camera { angle 10 location <1, 9, -50> look_at <0, 2, 0> } light_source { <20, 20, -20> color White } lathe { linear_spline 6, <0,0>, <1,1>, <3,2>, <2,3>, <2,4>, <0,4> pigment { Blue } finish { ambient .3 phong .75 } }  A simple lathe object. We render this, and what we see is a fairly simply type of lathe, which looks like a child's top. Let's take a look at how this code produced the effect. First, a set of six points are declared which the raytracer connects with lines. We note that there are only two components in the vectors which describe these points. The lines that are drawn are assumed to be in the x-y-plane, therefore it is as if all the z-components were assumed to be zero. The use of a two-dimensional vector is mandatory (Attempting to use a 3D vector would trigger an error... with one exception, which we will explore later in the discussion of splines). Once the lines are determined, the ray-tracer rotates this line around the y-axis, and we can imagine a trail being left through space as it goes, with the surface of that trail being the surface of our object. The specified points are connected with straight lines because we used the linear_spline XE "linear_spline"  keyword. There are other types of splines available with the lathe, which will result in smooth curving lines, and even rounded curving points of transition, but we will get back to that in a moment.  XE "sor" First, we would like to digress a moment to talk about the difference between a lathe and a surface of revolution object (SOR). The SOR object, described in a separate tutorial, may seem terribly similar to the lathe at first glance. It too declares a series of points and connects them with curving lines and then rotates them around the y-axis. The lathe has certain advantages, such as different kinds of splines, linear, quadratic and cubic, and one more thing: The simpler mathematics used by a SOR doesn't allow the curve to double back over the same y-coordinates, thus, if using a SOR, any sudden twist which cuts back down over the same heights that the curve previously covered will trigger an error. For example, suppose we wanted a lathe to arc up from <0,0> to <2,2>, then to dip back down to <4,0>. Rotated around the y-axis, this would produce something like a gelatin mold - a rounded semi torus, hollow in the middle. But with the SOR, as soon as the curve doubled back on itself in the y-direction, it would become an illegal declaration. Still, the SOR has one powerful strong point: because it uses simpler order mathematics, it generally tends to render faster than an equivalent lathe. So in the end, its a matter of: we use a SOR if its limitations will allow, but when we need a more flexible shape, we go with the lathe instead. Understanding The Concept of Splines It would be helpful, in order to understand splines, if we had a sort of Spline Workshop where we could practice manipulating types and points of splines and see what the effects were like. So let's make one! Now that we know how to create a basic lathe, it will be easy (see file lathdem2.pov): #include "colors.inc" camera { orthographic up <0, 5, 0> right <5, 0, 0> location <2.5, 2.5, -100> look_at <2.5, 2.5, 0> } /* set the control points to be used */ #declare Red_Point = <1.00, 0.00, 0>; #declare Orange_Point = <1.75, 1.00, 0>; #declare Yellow_Point = <2.50, 2.00, 0>; #declare Green_Point = <2.00, 3.00, 0>; #declare Blue_Point = <1.50, 4.00, 0>; /* make the control points visible */ cylinder { Red_Point, Red_Point - 20*z, .1 pigment { Red } finish { ambient 1 } } cylinder { Orange_Point, Orange_Point - 20*z, .1 pigment { Orange } finish { ambient 1 } } cylinder { Yellow_Point, Yellow_Point - 20*z, .1 pigment { Yellow } finish { ambient 1 } } cylinder { Green_Point, Green_Point - 20*z, .1 pigment { Green } finish { ambient 1 } } cylinder { Blue_Point, Blue_Point- 20*z, .1 pigment { Blue } finish { ambient 1 } } /* something to make the curve show up */ lathe { linear_spline 5, Red_Point, Orange_Point, Yellow_Point, Green_Point, Blue_Point pigment { White } finish { ambient 1 } }  A simple "Spline Workshop". Now, we take a deep breath. We know that all looks a bit weird, but with some simple explanations, we can easily see what all this does. First, we are using the orthographic camera. If we haven't read up on that yet, a quick summary is: it renders the scene flat, eliminating perspective distortion so that in a side view, the objects look like they were drawn on a piece of graph paper (like in the side view of a modeler or CAD package). There are several uses for this practical new type of camera, but here it is allowing us to see our lathe and cylinders edge on, so that what we see is almost like a cross section of the curve which makes the lathe, rather than the lathe itself. To further that effect, we eliminated shadowing with the ambient 1 finish, which of course also eliminates the need for lighting. We have also positioned this particular side view so that <0,0> appears at the lower left of our scene. Next, we declared a set of points. We note that we used 3D vectors for these points rather than the 2D vectors we expect in a lathe. That's the exception we mentioned earlier. When we declare a 3D point, then use it in a lathe, the lathe only uses the first two components of the vector, and whatever is in the third component is simply ignored. This is handy here, since it makes this example possible. Next we do two things with the declared points. First we use them to place small diameter cylinders at the locations of the points with the circular caps facing the camera. Then we re-use those same vectors to determine the lathe. Since trying to declare a 2D vector can have some odd results, and isn't really what our cylinder declarations need anyway, we can take advantage of the lathe's tendency to ignore the third component by just setting the z-coordinate in these 3D vectors to zero. The end result is: when we render this code, we see a white lathe against a black background showing us how the curve we've declared looks, and the circular ends of the cylinders show us where along the x-y-plane our control points are. In this case, it's very simple. The linear spline has been used so our curve is just straight lines zig-zagging between the points. We change the declarations of Red_Point and Blue_Point to read as follows (see file lathdem3.pov). #declare Red_Point = <2.00, 0.00, 0>; #declare Blue_Point = <0.00, 4.00, 0>;  Moving some points of the spline. We re-render and, as we can see, all that happens is that the straight line segments just move to accommodate the new position of the red and blue points. Linear splines are so simple, we could manipulate them in our sleep, no? Let's try something different. First, we change the points to the following (see file lathdem4.pov). #declare Red_Point = <1.00, 0.00, 0>; #declare Orange_Point = <2.00, 1.00, 0>; #declare Yellow_Point = <3.50, 2.00, 0>; #declare Green_Point = <2.00, 3.00, 0>; #declare Blue_Point = <1.50, 4.00, 0>;  A quadratic spline lathe. We then go down to the lathe declaration and change linear_spline XE "linear_spline"  to quadratic_spline XE "quadratic_spline" . We re-render and what do we have? Well, there's a couple of things worthy of note this time. First, we will see that instead of straight lines we have smooth arcs connecting the points. These arcs are made from quadratic curves, so our lathe looks much more interesting this time. Also, Red_Point is no longer connected to the curve. What happened? Well, while any two points can determine a straight line, it takes three to determine a quadratic curve. POV-Ray looks not only to the two points to be connected, but to the point immediately preceding them to determine the formula of the quadratic curve that will be used to connect them. The problem comes in at the beginning of the curve. Beyond the first point in the curve there is no previous point. So we need to declare one. Therefore, when using a quadratic spline, we must remember that the first point we specify is only there so that POV-Ray can determine what curve to connect the first two points with. It will not show up as part of the actual curve. There's just one more thing about this lathe example. Even though our curve is now put together with smooth curving lines, the transitions between those lines is... well, kind of choppy, no? This curve looks like the lines between each individual point have been terribly mismatched. Depending on what we are trying to make, this could be acceptable, or, we might long for a more smoothly curving shape. Fortunately, if the latter is true, we have another option. The quadratic spline takes longer to render than a linear spline. The math is more complex. Still longer needs the cubic spline, yet, for a really smoothed out shape, this is the only way to go. We go back into our example, and simply replace quadratic_spline with cubic_spline XE "cubic_spline"  (see file lathdem5.pov). We render one more time, and take a look at what we have.  A cubic spline lathe. While a quadratic spline takes three points to determine the curve, a cubic needs four. So, as we might expect, Blue_Point has now dropped out of the curve, just as Red_Point did, as the first and last points of our curve are now only control points for shaping the curves between the remaining points. But look at the transition from Orange_Point to Yellow_Point and then back to Green_Point. Now, rather than looking mismatched, our curve segments look like one smoothly joined curve. The concept of splines is a handy and necessary one, which will be seen again in the prism and polygon objects. But with a little tinkering we can quickly get a feel for working with them. Mesh Object  XE "mesh" Mesh objects are very useful because they allow us to create objects containing hundreds or thousands of triangles. Compared to a simple union of triangles the mesh object stores the triangles more efficiently. Copies of mesh objects need only a little additional memory because the triangles are stored only once. Almost every object can be approximated using triangles but we may need a lot of triangles to create more complex shapes. Thus we will only create a very simple mesh example. This example will show a very useful feature of the triangles meshes though: a different texture can be assigned to each triangle in the mesh. Now let's begin. We will create a simple box with differently colored sides. We create an empty file called meshdemo.pov and add the following lines. camera { location <20, 20, -50> look_at <0, 5, 0> } light_source { <50, 50, -50> color rgb<1, 1, 1> } #declare Red = texture { pigment { color rgb<0.8, 0.2, 0.2> } finish { ambient 0.2 diffuse 0.5 } } #declare Green = texture { pigment { color rgb<0.2, 0.8, 0.2> } finish { ambient 0.2 diffuse 0.5 } } #declare Blue = texture { pigment { color rgb<0.2, 0.2, 0.8> } finish { ambient 0.2 diffuse 0.5 } } We must declare all textures we want to use inside the mesh before the mesh is created. Textures cannot be specified inside the mesh due to the poor memory performance that would result. Now we add the mesh object. Three sides of the box will use individual textures while the other will use the global mesh texture. mesh { /* top side */ triangle { <-10, 10, -10>, <10, 10, -10>, <10, 10, 10> texture { Red } } triangle { <-10, 10, -10>, <-10, 10, 10>, <10, 10, 10> texture { Red } } /* bottom side */ triangle { <-10, -10, -10>, <10, -10, -10>, <10, -10, 10> } triangle { <-10, -10, -10>, <-10, -10, 10>, <10, -10, 10> } /* left side */ triangle { <-10, -10, -10>, <-10, -10, 10>, <-10, 10, 10> } triangle { <-10, -10, -10>, <-10, 10, -10>, <-10, 10, 10> } /* right side */ triangle { <10, -10, -10>, <10, -10, 10>, <10, 10, 10> texture { Green } } triangle { <10, -10, -10>, <10, 10, -10>, <10, 10, 10> texture { Green } } /* front side */ triangle { <-10, -10, -10>, <10, -10, -10>, <-10, 10, -10> texture { Blue } } triangle { <-10, 10, -10>, <10, 10, -10>, <10, -10, -10> texture { Blue } } /* back side */ triangle { <-10, -10, 10>, <10, -10, 10>, <-10, 10, 10> } triangle { <-10, 10, 10>, <10, 10, 10>, <10, -10, 10> } texture { pigment { color rgb<0.9, 0.9, 0.9> } finish { ambient 0.2 diffuse 0.7 } } } Tracing the scene at 320x240 we will see that the top, right and front side of the box have different textures. Though this is not a very impressive example it shows what we can do with mesh objects. More complex examples, also using smooth triangles, can be found under the scene directory as chesmsh.pov and robotmsh.pov. Polygon Object The polygon XE "polygon"  object can be used to create any planar, n-sided shapes like squares, rectangles, pentagons, hexagons, octagons, etc. A polygon is defined by a number of points that describe its shape. Since polygons have to be closed the first point has to be repeated at the end of the point sequence. In the following example we will create the word "POV" using just one polygon statement. We start with thinking about the points we need to describe the desired shape. We want the letters to lie in the x-y-plane with the letter O being at the center. The letters extend from y=0 to y=1. Thus we get the following points for each letter (the z coordinate is automatically set to zero). Letter P (outer polygon): <-0.8, 0.0>, <-0.8, 1.0>, <-0.3, 1.0>, <-0.3, 0.5>, <-0.7, 0.5>, <-0.7, 0.0> Letter P (inner polygon): <-0.7, 0.6>, <-0.7, 0.9>, <-0.4, 0.9>, <-0.4, 0.6> Letter O (outer polygon): <-0.25, 0.0>, <-0.25, 1.0>, < 0.25, 1.0>, < 0.25, 0.0> Letter O (inner polygon): <-0.15, 0.1>, <-0.15, 0.9>, < 0.15, 0.9>, < 0.15, 0.1> Letter V: <0.45, 0.0>, <0.30, 1.0>, <0.40, 1.0>, <0.55, 0.1>, <0.70, 1.0>, <0.80, 1.0>, <0.65, 0.0> Both letters P and O have a hole while the letter V consists of only one polygon. We'll start with the letter V because it is easier to define than the other two letters. We create a new file called polygdem.pov and add the following text. camera { orthographic location <0, 0, -10> right 1.3 * 4/3 * x up 1.3 * y look_at <0, 0.5, 0> } light_source { <25, 25, -100> color rgb 1 } polygon { 8, <0.45, 0.0>, <0.30, 1.0>, // Letter "V" <0.40, 1.0>, <0.55, 0.1>, <0.70, 1.0>, <0.80, 1.0>, <0.65, 0.0>, <0.45, 0.0> pigment { color rgb <1, 0, 0> } } As noted above the polygon has to be closed by appending the first point to the point sequence. A closed polygon is always defined by a sequence of points that ends when a point is the same as the first point. After we have created the letter V we'll continue with the letter P. Since it has a hole we have to find a way of cutting this hole into the basic shape. This is quite easy. We just define the outer shape of the letter P, which is a closed polygon, and add the sequence of points that describes the hole, which is also a closed polygon. That's all we have to do. There'll be a hole where both polygons overlap. In general we will get holes whenever an even number of sub-polygons inside a single polygon statement overlap. A sub-polygon is defined by a closed sequence of points. The letter P consists of two sub-polygons, one for the outer shape and one for the hole. Since the hole polygon overlaps the outer shape polygon we'll get a hole. After we have understood how multiple sub-polygons in a single polygon statement work, it is quite easy to add the missing O letter. Finally, we get the complete word POV. polygon { 30, <-0.8, 0.0>, <-0.8, 1.0>, // Letter "P" <-0.3, 1.0>, <-0.3, 0.5>, // outer shape <-0.7, 0.5>, <-0.7, 0.0>, <-0.8, 0.0>, <-0.7, 0.6>, <-0.7, 0.9>, // hole <-0.4, 0.9>, <-0.4, 0.6>, <-0.7, 0.6> <-0.25, 0.0>, <-0.25, 1.0>, // Letter "O" < 0.25, 1.0>, < 0.25, 0.0>, // outer shape <-0.25, 0.0>, <-0.15, 0.1>, <-0.15, 0.9>, // hole < 0.15, 0.9>, < 0.15, 0.1>, <-0.15, 0.1>, <0.45, 0.0>, <0.30, 1.0>, // Letter "V" <0.40, 1.0>, <0.55, 0.1>, <0.70, 1.0>, <0.80, 1.0>, <0.65, 0.0>, <0.45, 0.0> pigment { color rgb <1, 0, 0> } }  The word "POV" made with one polygon statement. Prism Object The prism is essentially a polygon or closed curve which is swept along a linear path. We can imagine the shape so swept leaving a trail in space, and the surface of that trail is the surface of our prism. The curve or polygon making up a prism's face can be a composite of any number of sub-shapes, can use any kind of three different splines, and can either keep a constant width as it is swept, or slowly tapering off to a fine point on one end. But before this gets too confusing, let's start one step at a time with the simplest form of prism. We enter and render the following POV code (see file prismdm1.pov). #include "colors.inc" background{White} camera { angle 20 location <2, 10, -30> look_at <0, 1, 0> } light_source { <20, 20, -20> color White } prism { linear_sweep linear_spline 0, // sweep the following shape from here ... 1, // ... up through here 7, // the number of points making up the shape ... <3,5>, <-3,5>, <-5,0>, <-3,-5>, <3, -5>, <5,0>, <3,5> pigment { Green } }  A hexagonal prism shape. This produces a hexagonal polygon, which is then swept from y=0 through y=1. In other words, we now have an extruded hexagon. One point to note is that although this is a six sided figure, we have used a total of seven points. That is because the polygon is supposed to be a closed shape, which we do here by making the final point the same as the first. Technically, with linear polygons, if we didn't do this, POV-Ray would automatically join the two ends with a line to force it to close, although a warning would be issued. However, this only works with linear splines, so we mustn't get too casual about those warning messages! Teaching An Old Spline New Tricks If we followed the section on splines covered under the lathe tutorial (see section " REF _Ref411675936 \h Understanding The Concept of Splines"), we know that there are two additional kinds of splines besides linear: the quadratic and the cubic spline. Sure enough, we can use these with prisms to make a more free form, smoothly curving type of prism. There is just one catch, and we should read this section carefully to keep from tearing our hair out over mysterious "too few points in prism" messages which keep our prism from rendering. We can probably guess where this is heading: how to close a non-linear spline. Unlike the linear spline, which simply draws a line between the last and first points if we forget to make the last point equal to the first, quadratic and cubic splines are a little more fussy. First of all, we remember that quadratic splines determine the equation of the curve which connects any two points based on those two points and the previous point, so the first point in any quadratic spline is just control point and won't actually be part of the curve. What this means is: when we make our shape out of a quadratic spline, we must match the second point to the last, since the first point is not on the curve - it's just a control point needed for computational purposes. Likewise, cubic splines need both the first and last points to be control points, therefore, to close a shape made with a cubic spline, we must match the second point to the second from last point. If we don't match the correct points on a quadratic or cubic shape, that's when we will get the "too few points in prism" error. POV-Ray is still waiting for us to close the shape, and when it runs out of points without seeing the closure, an error is issued. Confused? Okay, how about an example? We replace the prism in our last bit of code with this one (see file prismdm2.pov). prism { cubic_spline 0, // sweep the following shape from here ... 1, // ... up through here 6, // the number of points making up the shape ... < 3, -5>, // point#1 (control point... not on curve) < 3, 5>, // point#2 ... THIS POINT ... <-5, 0>, // point#3 < 3, -5>, // point#4 < 3, 5>, // point#5 ... MUST MATCH THIS POINT <-5, 0> // point#6 (control point... not on curve) pigment { Green } }  A cubic, triangular prism shape. This simple prism produces what looks like an extruded triangle with its corners sanded smoothly off. Points two, three and four are the corners of the triangle and point five closes the shape by returning to the location of point two. As for points one and six, they are our control points, and aren't part of the shape - they're just there to help compute what curves to use between the other points. Smooth Transitions Now a handy thing to note is that we have made point one equal point four, and also point six equals point three. Yes, this is important. Although this prism would still be legally closed if the control points were not what we've made them, the curve transitions between points would not be as smooth. We change points one and six to <4,6> and <0,7> respectively and re-render to see how the back edge of the shape is altered (see file prismdm3.pov). To put this more generally, if we want a smooth closure on a cubic spline, we make the first control point equal to the third from last point, and the last control point equal to the third point. On a quadratic spline, the trick is similar, but since only the first point is a control point, make that equal to the second from last point. Multiple Sub-Shapes Just as with the polygon object (see section " REF _Ref411676227 \h Polygon Object") the prism is very flexible, and allows us to make one prism out of several sub-prisms. To do this, all we need to do is keep listing points after we have already closed the first shape. The second shape can be simply an add on going off in another direction from the first, but one of the more interesting features is that if any even number of sub-shapes overlap, that region where they overlap behaves as though it has been cut away from both sub-shapes. Let's look at another example. Once again, same basic code as before for camera, light and so forth, but we substitute this complex prism (see file prismdm4.pov). prism { linear_sweep cubic_spline 0, // sweep the following shape from here ... 1, // ... up through here 18, // the number of points making up the shape ... <3,-5>, <3,5>, <-5,0>, <3, -5>, <3,5>, <-5,0>, // sub-shape #1 <2,-4>, <2,4>, <-4,0>, <2,-4>, <2,4>, <-4,0>, // sub-shape #2 <1,-3>, <1,3>, <-3,0>, <1, -3>, <1,3>, <-3,0> // sub-shape #3 pigment { Green } }  Using sub-shapes to create a more complex shape. For readability purposes, we have started a new line every time we moved on to a new sub-shape, but the ray-tracer of course tells where each shape ends based on whether the shape has been closed (as described earlier). We render this new prism, and look what we've got. It's the same familiar shape, but it now looks like a smaller version of the shape has been carved out of the center, then the carved piece was sanded down even smaller and set back in the hole. Simply, the outer rim is where only sub-shape one exists, then the carved out part is where sub-shapes one and two overlap. In the extreme center, the object reappears because sub-shapes one, two, and three overlap, returning us to an odd number of overlapping pieces. Using this technique we could make any number of extremely complex prism shapes! Conic Sweeps And The Tapering Effect In our original prism, the keyword linear_sweep XE "linear_sweep"  is actually optional. This is the default sweep assumed for a prism if no type of sweep is specified. But there is another, extremely useful kind of sweep: the conic sweep. The basic idea is like the original prism, except that while we are sweeping the shape from the first height through the second height, we are constantly expanding it from a single point until, at the second height, the shape has expanded to the original points we made it from. To give a small idea of what such effects are good for, we replace our existing prism with this (see file prismdm4.pov): prism { conic_sweep linear_spline 0, // height 1 1, // height 2 5, // the number of points making up the shape... <4,4>,<-4,4>,<-4,-4>,<4,-4>,<4,4> rotate <180, 0, 0> translate <0, 1, 0> scale <1, 4, 1> pigment { gradient y scale .2 } }  Creating a pyramid using conic sweeping. The gradient pigment was selected to give some definition to our object without having to fix the lights and the camera angle right at this moment, but when we render it, we what we've created? A horizontally striped pyramid! By now we can recognize the linear spline connecting the four points of a square, and the familiar final point which is there to close the spline. Notice all the transformations in the object declaration. That's going to take a little explanation. The rotate and translate are easy. Normally, a conic sweep starts full sized at the top, and tapers to a point at y=0, but of course that would be upside down if we're making a pyramid. So we flip the shape around the x-axis to put it right side up, then since we actually orbited around the point, we translate back up to put it in the same position it was in when we started. The scale is to put the proportions right for this example. The base is eight units by eight units, but the height (from y=1 to y=0) is only one unit, so we've stretched it out a little. At this point, we're probably thinking, "why not just sweep up from y=0 to y=4 and avoid this whole scaling thing?" That is a very important gotcha! with conic sweeps. To see what's wrong with that, let's try and put it into practice (see file prismdm5.pov). We must make sure to remove the scale statement, and then replace the line which reads 1, // height 2 with 4, // height 2 This sets the second height at y=4, so let's re-render and see if the effect is the same.  Choosing a second height larger than one for the conic sweep. Whoa! Our height is correct, but our pyramid's base is now huge! What went wrong here? Simple. The base, as we described it with the points we used actually occurs at y=1 no matter what we set the second height for. But if we do set the second height higher than one, once the sweep passes y=1, it keeps expanding outward along the same lines as it followed to our original base, making the actual base bigger and bigger as it goes. To avoid losing control of a conic sweep prism, it is usually best to let the second height stay at y=1, and use a scale statement to adjust the height from its unit size. This way we can always be sure the base's corners remain where we think they are. That leads to one more interesting thing about conic sweeps. What if we for some reason don't want them to taper all the way to a point? What if instead of a complete pyramid, we want more of a ziggurat step? Easily done. After putting the second height back to one, and replacing our scale statement, we change the line which reads 0, // height 1 to 0.251, // height 1  Increasing the first height for the conic sweep. When we re-render, we see that the sweep stops short of going all the way to its point, giving us a pyramid without a cap. Exactly how much of the cap is cut off depends on how close the first height is to the second height. Superquadric Ellipsoid Object Sometimes we want to make an object that does not have perfectly sharp edges like a box does. Then, the superquadric ellipsoid shape made by the superellipsoid XE "superellipsoid"  is a useful object. It is described by the simple syntax: superellipsoid { } Where Value_E and Value_N are float values greater than zero and less than or equal to one. Let's make a superellipsoid and experiment with the values of Value_E and Value_N to see what kind of shapes we can make. We create a file called supellps.pov and edit it as follows: #include "colors.inc" camera { location <10, 5, -20> look_at 0 angle 15 } background { color rgb <.5, .5, .5> } light_source { <10, 50, -100> White } The addition of a gray background makes it a little easier to see our object. We now type: superellipsoid { <.25, .25> pigment { Red } } We save the file and trace it at 200x150 -A to see the shape. It will look like a box, but the edges will be rounded off. Now let's experiment with different values of Value_E and Value_N. For the next trace, try <1, 0.2>. The shape now looks like a cylinder, but the top edges are rounded. Now try <0.1, 1>. This shape is an odd one! We don't know exactly what to call it, but it is interesting. Finally, lets try <1, 1>. Well, this is more familiar... a sphere! There are a couple of facts about superellipsoids we should know. First, we should not use a value of 0 for either Value_E nor Value_N. This will cause POV-Ray to incorrectly make a black box instead of our desired shape. Second, very small values of Value_E and Value_N may yield strange results so they should be avoided. Finally, the Sturmian root solver will not work with superellipsoids. Superellipsoids are finite objects so they respond to auto-bounding and can be used in CSG. Now let's use the superellipsoid to make something that would be useful in a scene. We will make a tiled floor and place a couple of superellipsoid objects hovering over it. We can start with the file we have already made. We rename it to tiles.pov and edit it so that it reads as follows: #include "colors.inc" #include "textures.inc" camera { location <10, 5, -20> look_at 0 angle 15 } background { color rgb <.5, .5, .5> } light_source{ <10, 50, -100> White } Note that we have added #include "textures.inc" so we can use pre-defined textures. Now we want to define the superellipsoid which will be our tile. #declare Tile = superellipsoid { <0.5, 0.1> scale <1, .05, 1> } Superellipsoids are roughly 2*2*2 units unless we scale them otherwise. If we wish to lay a bunch of our tiles side by side, they will have to be offset from each other so they don't overlap. We should select an offset value that is slightly more than 2 so that we have some space between the tiles to fill with grout. So we now add this: #declare Offset = 2.1; We now want to lay down a row of tiles. Each tile will be offset from the original by an ever-increasing amount in both the +z and -z directions. We refer to our offset and multiply by the tile's rank to determine the position of each tile in the row. We also union these tiles into a single object called Row like this: #declare Row = union { object { Tile } object { Tile translate z*Offset } object { Tile translate z*Offset*2 } object { Tile translate z*Offset*3 } object { Tile translate z*Offset*4 } object { Tile translate z*Offset*5 } object { Tile translate z*Offset*6 } object { Tile translate z*Offset*7 } object { Tile translate z*Offset*8 } object { Tile translate z*Offset*9 } object { Tile translate z*Offset*10 } object { Tile translate -z*Offset } object { Tile translate -z*Offset*2 } object { Tile translate -z*Offset*3 } object { Tile translate -z*Offset*4 } object { Tile translate -z*Offset*5 } object { Tile translate -z*Offset*6 } } This gives us a single row of 17 tiles, more than enough to fill the screen. Now we must make copies of the Row and translate them, again by the offset value, in both the +x and -x directions in ever increasing amounts in the same manner. object { Row } object { Row translate x*Offset } object { Row translate x*Offset*2 } object { Row translate x*Offset*3 } object { Row translate x*Offset*4 } object { Row translate x*Offset*5 } object { Row translate x*Offset*6 } object { Row translate x*Offset*7 } object { Row translate -x*Offset } object { Row translate -x*Offset*2 } object { Row translate -x*Offset*3 } object { Row translate -x*Offset*4 } object { Row translate -x*Offset*5 } object { Row translate -x*Offset*6 } object { Row translate -x*Offset*7 } Finally, our tiles are complete. But we need a texture for them. To do this we union all of the Rows together and apply a White Marble pigment and a somewhat shiny reflective surface to it: union{ object { Row } object { Row translate x*Offset } object { Row translate x*Offset*2 } object { Row translate x*Offset*3 } object { Row translate x*Offset*4 } object { Row translate x*Offset*5 } object { Row translate x*Offset*6 } object { Row translate x*Offset*7 } object { Row translate -x*Offset } object { Row translate -x*Offset*2 } object { Row translate -x*Offset*3 } object { Row translate -x*Offset*4 } object { Row translate -x*Offset*5 } object { Row translate -x*Offset*6 } object { Row translate -x*Offset*7 } pigment { White_Marble } finish { phong 1 phong_size 50 reflection .35 } } We now need to add the grout. This can simply be a white plane. We have stepped up the ambient here a little so it looks whiter. plane { y, 0 //this is the grout pigment { color White } finish { ambient .4 diffuse .7 } } To complete our scene, let's add five different superellipsoids, each a different color, so that they hover over our tiles and are reflected in them. superellipsoid { <0.1, 1> pigment { Red } translate <5, 3, 0> scale .45 } superellipsoid { <1, 0.25> pigment { Blue } translate <-5, 3, 0> scale .45 } superellipsoid { <0.2, 0.6> pigment { Green } translate <0, 3, 5> scale .45 } superellipsoid { <0.25, 0.25> pigment { Yellow } translate <0, 3, -5> scale .45 } superellipsoid { <1, 1> pigment { Pink } translate y*3 scale .45 }  Some superellipsoids hovering above a tiled floor. We trace the scene at 320x200 -A to see the result. If we are happy with that, we do a final trace at 640x480 +A0.2. Surface of Revolution Object  XE "sor" Bottles, vases and glasses make nice objects in ray-traced scenes. We want to create a golden cup using the surface of revolution object (SOR object). We first start by thinking about the shape of the final object. It is quite difficult to come up with a set of points that describe a given curve without the help of a modeling program supporting POV-Ray's surface of revolution object. If such a program is available we should take advantage of it.  The point configuration of our cup object. We will use the point configuration shown in the figure above. There are eight points describing the curve that will be rotated about the y-axis to get our cup. The curve was calculated using the method described in the reference section (see " REF _Ref411680043 \h Surface of Revolution"). Now it is time to come up with a scene that uses the above SOR object. We edit a file called sordemo.pov and enter the following text. #include "colors.inc" #include "golds.inc" global_settings { assumed_gamma 2.2 } camera { location <10, 15, -20> look_at <0, 5, 0> angle 45 } background { color rgb<0.2, 0.4, 0.8> } light_source { <100, 100, -100> color rgb 1 } plane { y, 0 pigment { checker color Red, color Green scale 10 } } sor { 8, <0.0, -0.5>, <3.0, 0.0>, <1.0, 0.2>, <0.5, 0.4>, <0.5, 4.0>, <1.0, 5.0>, <3.0, 10.0>, <4.0, 11.0> texture { T_Gold_1B } } The scene contains our cup object resting on a checkered plane. Tracing this scene results in the image below.  A surface of revolution object. The surface of revolution is described by starting with the number of points followed by the points with ascending heights. Each point determines the radius of the curve for a given height. E. g. the first point tells POV-Ray that at height -0.5 the radius is 0. We should take care that each point has a larger height than its predecessor. If this is not the case the program will abort with an error message. Text Object Creating text XE "text"  objects using POV-Ray always used to mean that the letters had to be built either from CSG, a painstaking process or by using a black and white image of the letters as a height field, a method that was only somewhat satisfactory. Now, for POV-Ray 3.0, a new primitive has been introduced that can use any TrueType font to create text objects. These objects can be used in CSG, transformed and textured just like any other POV primitive. For this tutorial, we will make two uses of the text object. First, let's just make some block letters sitting on a checkered plane. Any TTF font should do, but for this tutorial, we will use the timrom.ttf or cyrvetic.ttf which come bundled with POV-Ray. We create a file called textdemo.pov and edit it as follows: #include "colors.inc" camera { location <0, 1, -10> look_at 0 angle 35 } light_source { <500,500,-1000> White } plane { y,0 pigment { checker Green White } } Now let's add the text object. We will use the font timrom.ttf and we will create the string "POV-RAY 3.0". For now, we will just make the letters red. The syntax is very simple. The first string in quotes is the font name, the second one is the string to be rendered. The two floats are the thickness and offset values. The thickness float determines how thick the block letters will be. Values of .5 to 2 are usually best for this. The offset value will add to the kerning distance of the letters. We will leave this a 0 for now. text { ttf "timrom.ttf" "POV-RAY 3.0" 1, 0 pigment { Red } } Rendering this at 200x150 -A, we notice that the letters are off to the right of the screen. This is because they are placed so that the lower left front corner of the first letter is at the origin. To center the string we need to translate it -x some distance. But how far? In the docs we see that the letters are all 0.5 to 0.75 units high. If we assume that each one takes about 0.5 units of space on the x-axis, this means that the string is about 6 units long (12 characters and spaces). Let's translate the string 3 units along the negative x-axis. text { ttf "timrom.ttf" "POV-RAY 3.0" 1, 0 pigment { Red } translate -3*x } That's better. Now let's play around with some of the parameters of the text object. First, let's raise the thickness float to something outlandish... say 25! text { ttf "timrom.ttf" "POV-RAY 3.0" 25, 0 pigment { Red } translate -2.25*x } Actually, that's kind of cool. Now let's return the thickness value to 1 and try a different offset value. Change the offset float from 0 to 0.1 and render it again. Wait a minute?! The letters go wandering off up at an angle! That is not what the docs describe! It almost looks as if the offset value applies in both the x- and y-axis instead of just the x axis like we intended. Could it be that a vector is called for here instead of a float? Let's try it. We replace 0.1 with 0.1*x and render it again. That works! The letters are still in a straight line along the x-axis, just a little further apart. Let's verify this and try to offset just in the y-axis. We replace 0.1*x with 0.1*y. Again, this works as expected with the letters going up to the right at an angle with no additional distance added along the x-axis. Now let's try the z-axis. We replace 0.1*y with 0.1*z. Rendering this yields a disappointment. No offset occurs! The offset value can only be applied in the x- and y-directions. Let's finish our scene by giving a fancier texture to the block letters, using that cool large thickness value, and adding a slight y-offset. For fun, we will throw in a sky sphere, dandy up our plane a bit, and use a little more interesting camera viewpoint (we render the following scene at 640x480 +A0.2): #include "colors.inc" camera { location <-5,.15,-2> look_at <.3,.2,1> angle 35 } light_source { <500,500,-1000> White } plane { y,0 texture { pigment { SeaGreen } finish { reflection .35 specular 1 } normal { ripples .35 turbulence .5 scale .25 } } } text { ttf "timrom.ttf" "POV-RAY 3.0" 25, 0.1*y pigment { BrightGold } finish { reflection .25 specular 1 } translate -3*x } #include "skies.inc" sky_sphere { S_Cloud5 } Let's try using text in a CSG object. We will attempt to create an inlay in a stone block using a text object. We create a new file called textcsg.pov and edit it as follows: #include "colors.inc" #include "stones.inc" background { color rgb 1 } camera { location <-3, 5, -15> look_at 0 angle 25 } light_source { <500,500,-1000> White } Now let's create the block. We want it to be about eight units across because our text string "POV-RAY 3.0" is about six units long. We also want it about four units high and about one unit deep. But we need to avoid a potential coincident surface with the text object so we will make the first z-coordinate 0.1 instead of 0. Finally, we will give this block a nice stone texture. box { <-3.5, -1, 0.1>, <3.5, 1, 1> texture { T_Stone10 } } Next, we want to make the text object. We can use the same object we used in the first tutorial except we will use slightly different thickness and offset values. text { ttf "timrom.ttf" "POV-RAY 3.0" 0.15, 0 pigment { BrightGold } finish { reflection .25 specular 1 } translate -3*x } We remember that the text object is placed by default so that its front surface lies directly on the x-y-plane. If the front of the box begins at z=0.1 and thickness is set at 0.15, the depth of the inlay will be 0.05 units. We place a difference block around the two objects. difference { box { <-3.5, -1, 0.1>, <3.5, 1, 1> texture { T_Stone10 } } text { ttf "timrom.ttf" "POV-RAY 3.0" 0.15, 0 pigment { BrightGold } finish { reflection .25 specular 1 } translate -3*x } }  Text carved from stone. We render this at 200x150 -A. We can see the inlay clearly and that it is indeed a bright gold color. We re-render at 640x480 +A0.2 to see the results more clearly, but be forewarned... this trace will take a little time. Torus Object A torus XE "torus"  can be thought of as a donut or an inner-tube. It is a shape that is vastly useful in many kinds of CSG so POV-Ray has adopted this 4th order quartic polynomial as a primitive shape. The syntax for a torus is so simple that it makes it a very easy shape to work with once we learn what the two float values mean. Instead of a lecture on the subject, let's create one and do some experiments with it. We create a file called tordemo.pov and edit it as follows: #include "colors.inc" camera { location <0, .1, -25> look_at 0 angle 30 } background { color Gray50 } // to make the torus easy to see light_source{ <300, 300, -1000> White } torus { 4, 1 // major and minor radius rotate -90*x // so we can see it from the top pigment { Green } } We trace the scene. Well, it's a donut alright. Let's try changing the major and minor radius values and see what happens. We change them as follows: torus { 5, .25 // major and minor radius That looks more like a hula-hoop! Let's try this: torus { 3.5, 2.5 // major and minor radius Whoa! A donut with a serious weight problem! With such a simple syntax, there isn't much else we can do to a torus besides change its texture... or is there? Let's see... Torii are very useful objects in CSG. Let's try a little experiment. We make a difference of a torus and a box: difference { torus { 4, 1 rotate x*-90 // so we can see it from the top } box { <-5, -5, -1>, <5, 0, 1> } pigment { Green } } Interesting... a half-torus. Now we add another one flipped the other way. Only, let's declare the original half-torus and the necessary transformations so we can use them again: #declare Half_Torus = difference { torus { 4, 1 rotate -90*x // so we can see it from the top } box { <-5, -5, -1>, <5, 0, 1> } pigment { Green } } #declare Flip_It_Over = 180*x; #declare Torus_Translate = 8; // twice the major radius Now we create a union of two Half_Torus objects: union { object { Half_Torus } object { Half_Torus rotate Flip_It_Over translate Torus_Translate*x } } This makes an S-shaped object, but we can't see the whole thing from our present camera. Let's add a few more links, three in each direction, move the object along the +z-direction and rotate it about the +y-axis so we can see more of it. We also notice that there appears to be a small gap where the half Torii meet. This is due to the fact that we are viewing this scene from directly on the x-z-plane. We will change the camera's y-coordinate from 0 to 0.1 to eliminate this. union { object { Half_Torus } object { Half_Torus rotate Flip_It_Over translate x*Torus_Translate } object { Half_Torus translate x*Torus_Translate*2 } object { Half_Torus rotate Flip_It_Over translate x*Torus_Translate*3 } object { Half_Torus rotate Flip_It_Over translate -x*Torus_Translate } object { Half_Torus translate -x*Torus_Translate*2 } object { Half_Torus rotate Flip_It_Over translate -x*Torus_Translate*3 } object { Half_Torus translate -x*Torus_Translate*4 } rotate y*45 translate z*20 } Rendering this we see a cool, undulating, snake-like something-or-other. Neato. But we want to model something useful, something that we might see in real life. How about a chain? Thinking about it for a moment, we realize that a single link of a chain can be easily modeled using two half tori and two cylinders. We create a new file. We can use the same camera, background, light source and declared objects and transformations as we used in tordemo.pov: #include "colors.inc" camera { location <0, .1, -25> look_at 0 angle 30 } background { color Gray50 } light_source{ <300, 300, -1000> White } #declare Half_Torus = difference { torus { 4,1 sturm rotate x*-90 // so we can see it from the top } box { <-5, -5, -1>, <5, 0, 1> } pigment { Green } } #declare Flip_It_Over = x*180; #declare Torus_Translate = 8; Now, we make a complete torus of two half tori: union { object { Half_Torus } object { Half_Torus rotate Flip_It_Over } } This may seem like a wasteful way to make a complete torus, but we are really going to move each half apart to make room for the cylinders. First, we add the declared cylinder before the union: #declare Chain_Segment = cylinder { <0, 4, 0>, <0, -4, 0>, 1 pigment { Green } } We then add two Chain_Segments to the union and translate them so that they line up with the minor radius of the torus on each side: union { object { Half_Torus } object { Half_Torus rotate Flip_It_Over } object { Chain_Segment translate x*Torus_Translate/2 } object { Chain_Segment translate -x*Torus_Translate/2 } } Now we translate the two half tori +y and -y so that the clipped ends meet the ends of the cylinders. This distance is equal to half of the previously declared Torus_Translate: union { object { Half_Torus translate y*Torus_Translate/2 } object { Half_Torus rotate Flip_It_Over translate -y*Torus_Translate/2 } object { Chain_Segment translate x*Torus_Translate/2 } object { Chain_Segment translate -x*Torus_Translate/2 } } We render this and viola! A single link of a chain. But we aren't done yet! Whoever heard of a green chain? We would rather use a nice metallic color instead. First, we remove any pigment blocks in the declared torsos and cylinders. Then we add the following before the union: #declare Chain_Gold = texture { pigment { BrightGold } finish { ambient .1 diffuse .4 reflection .25 specular 1 metallic } } We then add the texture to the union and declare the union as a single link: #declare Link = union { object { Half_Torus translate y*Torus_Translate/2 } object { Half_Torus rotate Flip_It_Over translate -y*Torus_Translate/2 } object { Chain_Segment translate x*Torus_Translate/2 } object { Chain_Segment translate -x*Torus_Translate/2 } texture { Chain_Gold } } Now we make a union of two links. The second one will have to be translated +y so that its inner wall just meets the inner wall of the other link, just like the links of a chain. This distance turns out to be double the previously declared Torus_Translate minus 2 (twice the minor radius). This can be described by the expression: Torus_Translate*2-2*y We declare this expression as follows: #declare Link_Translate = Torus_Translate*2-2*y; In the object block, we will use this declared value so that we can multiply it to create other links. Now, we rotate the second link 90*y so that it is perpendicular to the first, just like links of a chain. Finally, we scale the union by 1/4 so that we can see the whole thing: union { object { Link } object { Link translate y*Link_Translate rotate y*90 } scale .25 } We render this and we will see a very realistic pair of links. If we want to make an entire chain, we must declare the above union and then create another union of this declared object. We must be sure to remove the scaling from the declared object: #declare Link_Pair = union { object { Link } object { Link translate y*Link_Translate rotate y*90 } } Now we declare our chain: #declare Chain = union { object { Link_Pair} object { Link_Pair translate y*Link_Translate*2 } object { Link_Pair translate y*Link_Translate*4 } object { Link_Pair translate y*Link_Translate*6 } object { Link_Pair translate -y*Link_Translate*2 } object { Link_Pair translate -y*Link_Translate*4 } object { Link_Pair translate -y*Link_Translate*6 } } And finally we create our chain with a couple of transformations to make it easier to see. These include scaling it down by a factor of 1/10, and rotating it so that we can clearly see each link: object { Chain scale .1 rotate <0, 45, -45> }  The torus object can be used to create chains. We render this and we should see a very realistic gold chain stretched diagonally across the screen. The Light Source  XE "light_source" In any ray-traced scene, the light needed to illuminate our objects and their surfaces must come from a light source. There are many kinds of light sources available in POV-Ray and careful use of the correct kind can yield very impressive results. Let's take a moment to explore some of the different kinds of light sources and their various parameters. The Pointlight Source  XE "pointlight" Pointlights are exactly what the name indicates. A pointlight has no size, is invisible and illuminates everything in the scene equally no matter how far away from the light source it may be (this behavior can be changed). This is the simplest and most basic light source. There are only two important parameters, location and color. Let's design a simple scene and place a pointlight source in it. We create a new file and name it litedemo.pov. We edit it as follows: #include "colors.inc" #include "textures.inc" camera { location <-4, 3, -9> look_at <0, 0, 0> angle 48 } We add the following simple objects: plane { y, -1 texture { pigment { checker color rgb<0.5, 0, 0> color rgb<0, 0.5, 0.5> } finish { diffuse 0.4 ambient 0.2 phong 1 phong_size 100 reflection 0.25 } } } torus { 1.5, 0.5 texture { Brown_Agate } rotate <90, 160, 0> translate <-1, 1, 3> } box { <-1, -1, -1>, <1, 1, 1> texture { DMFLightOak } translate <2, 0, 2.3> } cone { <0,1,0>, 0, <0,0,0>, 1 texture { PinkAlabaster } scale <1, 3, 1> translate <-2, -1, -1> } sphere { <0,0,0>,1 texture { Sapphire_Agate } translate <1.5, 0, -2> } Now we add a pointlight: light_source { <2, 10, -3> color White } We render this at 200x150 -A and see that the objects are clearly visible with sharp shadows. The sides of curved objects nearest the light source are brightest in color with the areas that are facing away from the light source being darkest. We also note that the checkered plane is illuminated evenly all the way to the horizon. This allows us to see the plane, but it is not very realistic. The Spotlight Source Spotlights are a very useful type of light source. They can be used to add highlights and illuminate features much as a photographer uses spots to do the same thing. To create a spotlight simply add the spotlight XE "spotlight"  keyword to a regular point light. There are a few more parameters with spotlights than with pointlights. These are radius, falloff, tightness and point_at. The radius XE "radius"  parameter is the angle of the fully illuminated cone. The falloff XE "falloff"  parameter is the angle of the umbra cone where the light falls off to darkness. The tightness XE "tightness"  is a parameter that determines the rate of the light falloff. The point_at XE "point_at"  parameter is just what it says, the location where the spotlight is pointing to. Let's change the light in our scene as follows: light_source { <0, 10, -3> color White spotlight radius 15 falloff 20 tightness 10 point_at <0, 0, 0> } We render this at 200x150 -A and see that only the objects are illuminated. The rest of the plane and the outer portions of the objects are now unlit. There is a broad falloff area but the shadows are still razor sharp. Let's try fiddling with some of these parameters to see what they do. We change the falloff value to 16 (it must always be larger than the radius value) and render again. Now the falloff is very narrow and the objects are either brightly lit or in total darkness. Now we change falloff back to 20 and change the tightness value to 100 (higher is tighter) and render again. The spotlight appears to have gotten much smaller but what has really happened is that the falloff has become so steep that the radius actually appears smaller. We decide that a tightness value of 10 (the default) and a falloff value of 18 are best for this spotlight and we now want to put a few spots around the scene for effect. Let's place a slightly narrower blue and a red one in addition to the white one we already have: light_source { <10, 10, -1> color Red spotlight radius 12 falloff 14 tightness 10 point_at <2, 0, 0> } light_source { <-12, 10, -1> color Blue spotlight radius 12 falloff 14 tightness 10 point_at <-2, 0, 0> } Rendering this we see that the scene now has a wonderfully mysterious air to it. The three spotlights all converge on the objects making them blue on one side and red on the other with enough white in the middle to provide a balance. The Cylindrical Light Source  XE "cylindrical light" Spotlights are cone shaped, meaning that their effect will change with distance. The farther away from the spotlight an object is, the larger the apparent radius will be. But we may want the radius and falloff to be a particular size no matter how far away the spotlight is. For this reason, cylindrical light sources are needed. A cylindrical light source is just like a spotlight, except that the radius and falloff regions are the same no matter how far from the light source our object is. The shape is therefore a cylinder rather than a cone. We can specify a cylindrical light source by replacing the spotlight XE "spotlight"  keyword with the cylinder XE "cylinder"  keyword. We try this now with our scene by replacing all three spotlights with cylinder lights and rendering again. We see that the scene is much dimmer. This is because the cylindrical constraints do not let the light spread out like in a spotlight. Larger radius and falloff values are needed to do the job. We try a radius of 20 and a falloff of 30 for all three lights. That's the ticket! The Area Light Source  XE "area_light" So far all of our light sources have one thing in common. They produce sharp shadows. This is because the actual light source is a point that is infinitely small. Objects are either in direct sight of the light, in which case they are fully illuminated, or they are not, in which case they are fully shaded. In real life, this kind of stark light and shadow situation exists only in outer space where the direct light of the sun pierces the total blackness of space. But here on Earth, light bends around objects, bounces off objects, and usually the source has some dimension, meaning that it can be partially hidden from sight (shadows are not sharp anymore). They have what is known as an umbra, or an area of fuzziness where there is neither total light or shade. In order to simulate these soft shadows, a ray-tracer must give its light sources dimension. POV-Ray accomplishes this with a feature known as an area light. Area lights have dimension in two axis'. These are specified by the first two vectors in the area light syntax. We must also specify how many lights are to be in the array. More will give us cleaner soft shadows but will take longer to render. Usually a 3*3 or a 5*5 array will suffice. We also have the option of specifying an adaptive value. The adaptive XE "adaptive"  keyword tells the ray-tracer that it can adapt to the situation and send only the needed rays to determine the value of the pixel. If adaptive is not used, a separate ray will be sent for every light in the area light. This can really slow things down. The higher the adaptive value the cleaner the umbra will be but the longer the trace will take. Usually an adaptive value of 1 is sufficient. Finally, we probably should use the jitter XE "jitter"  keyword. This tells the ray-tracer to slightly move the position of each light in the area light so that the shadows appear truly soft instead of giving us an umbra consisting of closely banded shadows. OK, let's try one. We comment out the cylinder lights and add the following: light_source { <2, 10, -3> color White area_light <5, 0, 0>, <0, 0, 5>, 5, 5 adaptive 1 jitter } This is a white area light centered at <2,10,-3>. It is 5 units (along the x-axis) by 5 units (along the z-axis) in size and has 25 (5*5) lights in it. We have specified adaptive 1 and jitter. We render this at 200x150 -A. Right away we notice two things. The trace takes quite a bit longer than it did with a point or a spotlight and the shadows are no longer sharp! They all have nice soft umbrae around them. Wait, it gets better. Spotlights and cylinder lights can be area lights too! Remember those sharp shadows from the spotlights in our scene? It would not make much sense to use a 5*5 array for a spotlight, but a smaller array might do a good job of giving us just the right amount of umbra for a spotlight. Let's try it. We comment out the area light and change the cylinder lights so that they read as follows: light_source { <2, 10, -3> color White spotlight radius 15 falloff 18 tightness 10 area_light <1, 0, 0>, <0, 0, 1>, 2, 2 adaptive 1 jitter point_at <0, 0, 0> } light_source { <10, 10, -1> color Red spotlight radius 12 falloff 14 tightness 10 area_light <1, 0, 0>, <0, 0, 1>, 2, 2 adaptive 1 jitter point_at <2, 0, 0> } light_source { <-12, 10, -1> color Blue spotlight radius 12 falloff 14 tightness 10 area_light <1, 0, 0>, <0, 0, 1>, 2, 2 adaptive 1 jitter point_at <-2, 0, 0> } We now have three area-spotlights, one unit square consisting of an array of four (2*2) lights, three different colors, all shining on our scene. We render this at 200x150 -A. It appears to work perfectly. All our shadows have small, tight umbrae, just the sort we would expect to find on an object under a real spotlight. The Ambient Light Source  XE "ambient light" The ambient light source is used to simulate the effect of inter-diffuse reflection. If there wasn't inter-diffuse reflection all areas not directly lit by a light source would be completely dark. POV-Ray uses the ambient XE "ambient"  keyword to determine how much light coming from the ambient light source is reflected by a surface. By default the ambient light source, which emits its light everywhere and in all directions, is pure white (rgb <1,1,1>). Changing its color can be used to create interesting effects. First of all the overall light level of the scene can be adjusted easily. Instead of changing all ambient values in every finish only the ambient light source is modified. By assigning different colors we can create nice effects like a moody reddish ambient lighting. For more details about the ambient light source see " REF _Ref411751086 \h Ambient Light". Below is an example of a red ambient light source. global_settings { ambient_light rgb<1, 0, 0> } Light Source Specials Using Shadowless Lights Light sources can be assigned the shadowless XE "shadowless"  keyword and no shadows will be cast due to its presence in a scene. Sometimes, scenes are difficult to illuminate properly using the lights we have chosen to illuminate our objects. It is impractical and unrealistic to apply a higher ambient value to the texture of every object in the scene. So instead, we would place a couple of fill lights around the scene. Fill lights are simply dimmer lights with the shadowless keyword that act to boost the illumination of other areas of the scene that may not be lit well. Let's try using one in our scene. Remember the three colored area spotlights? We go back and un-comment them and comment out any other lights we have made. Now we add the following: light_source { <0, 20, 0> color Gray50 shadowless } This is a fairly dim light 20 units over the center of the scene. It will give a dim illumination to all objects including the plane in the background. We render it and see. Assigning an Object to a Light Source Light sources are invisible. They are just a location where the light appears to be coming from. They have no true size or shape. If we want our light source to be a visible shape, we can use the looks_like XE "looks_like"  keyword. We can specify that our light source can look like any object we choose. When we use looks_like, then no_shadow XE "no_shadow"  is applied to the object automatically. This is done so that the object will not block any illumination from the light source. If we want some blocking to occur (as in a lampshade), it is better to simply use a union to do the same thing. Let's add such an object to our scene. Here is a light bulb we have made just for this purpose: #declare Lightbulb = union { merge { sphere { <0,0,0>,1 } cylinder { <0,0,1>, <0,0,0>, 1 scale <0.35, 0.35, 1.0> translate 0.5*z } texture { pigment {color rgb <1, 1, 1>} finish {ambient .8 diffuse .6} } } cylinder { <0,0,1>, <0,0,0>, 1 scale <0.4, 0.4, 0.5> texture { Brass_Texture } translate 1.5*z } rotate -90*x scale .5 } Now we add the light source: light_source { <0, 2, 0> color White looks_like { Lightbulb } } Rendering this we see that a fairly believable light bulb now illuminates the scene. However, if we do not specify a high ambient value, the light bulb is not lit by the light source. On the plus side, all of the shadows fall away from the light bulb, just as they would in a real situation. The shadows are sharp, so let's make our bulb an area light: light_source { <0, 2, 0> color White area_light <1, 0, 0>, <0, 1, 0>, 2, 2 adaptive 1 jitter looks_like { Lightbulb } } We note that we have placed this area light in the x-y-plane instead of the x-z-plane. We also note that the actual appearance of the light bulb is not affected in any way by the light source. The bulb must be illuminated by some other light source or by, as in this case, a high ambient value. Using Light Fading If it is realism we want, it is not realistic for the plane to be evenly illuminated off into the distance. In real life, light gets scattered as it travels so it diminishes its ability to illuminate objects the farther it gets from its source. To simulate this, POV-Ray allows us to use two keywords: fade_distance XE "fade_distance" , which specifies the distance at which full illumination is achieved, and fade_power XE "fade_power" , an exponential value which determines the actual rate of attenuation. Let's apply these keywords to our fill light. First, we make the fill light a little brighter by changing Gray50 to Gray75. Now we change that fill light as follows: light_source { <0, 20, 0> color Gray75 fade_distance 5 fade_power 1 shadowless } This means that the full value of the fill light will be achieved at a distance of 5 units away from the light source. The fade power of 1 means that the falloff will be linear (the light falls of at a constant rate). We render this to see the result. That definitely worked! Now let's try a fade power of 2 and a fade distance of 10. Again, this works well. The falloff is much faster with a fade power of 2 so we had to raise the fade distance to 10. Simple Texture Options  XE "texture" The pictures rendered so far where somewhat boring regarding the appearance of the objects. Let's add some fancy features to the texture. Surface Finishes One of the main features of a ray-tracer is its ability to do interesting things with surface finishes such as highlights and reflection. Let's add a nice little Phong highlight (shiny spot) to a sphere. To do this we need to add a finish XE "finish"  keyword followed by a parameter. We change the definition of the sphere to this: sphere { <0, 1, 2>, 2 texture { pigment { color Yellow } // Yellow is pre-defined in COLORS.INC finish { phong 1 } } } We render the scene. The phong XE "phong"  keyword adds a highlight the same color of the light shining on the object. It adds a lot of credibility to the picture and makes the object look smooth and shiny. Lower values of phong will make the highlight less bright (values should be between 0 and 1). Adding Bumpiness The highlight we have added illustrates how much of our perception depends on the reflective properties of an object. Ray-tracing can exploit this by playing tricks on our perception to make us see complex details that aren't really there. Suppose we wanted a very bumpy surface on the object. It would be very difficult to mathematically model lots of bumps. We can however simulate the way bumps look by altering the way light reflects off of the surface. Reflection calculations depend on a vector called a surface normal. This is a vector which points away from the surface and is perpendicular to it. By artificially modifying (or perturbing) this normal vector we can simulate bumps. We change the scene to read as follows and render it: sphere { <0, 1, 2>, 2 texture { pigment { color Yellow } normal { bumps 0.4 scale 0.2 } finish { phong 1} } } This tells POV-Ray to use the bumps XE "bumps"  pattern to modify the surface normal. The value 0.4 controls the apparent depth of the bumps. Usually the bumps are about 1 unit wide which doesn't work very well with a sphere of radius 2. The scale makes the bumps 1/5th as wide but does not affect their depth. Creating Color Patterns We can do more than assigning a solid color to an object. We can create complex patterns in the pigment block like in this example: sphere { <0, 1, 2>, 2 texture { pigment { wood color_map { [0.0 color DarkTan] [0.9 color DarkBrown] [1.0 color VeryDarkBrown] } turbulence 0.05 scale <0.2, 0.3, 1> } finish { phong 1 } } } The keyword wood XE "wood"  specifies a pigment pattern of concentric rings like rings in wood. The color_map XE "color_map"  keyword specifies that the color of the wood should blend from DarkTan to DarkBrown over the first 90% of the vein and from DarkBrown to VeryDarkBrown over the remaining 10%. The turbulence XE "turbulence"  keyword slightly stirs up the pattern so the veins aren't perfect circles and the scale XE "scale"  keyword adjusts the size of the pattern. Most patterns are set up by default to give us one feature across a sphere of radius 1.0. A feature is very roughly defined as a color transition. For example, a wood texture would have one band on a sphere of radius 1.0. In this example we scale the pattern using the scale XE "scale"  keyword followed by a vector. In this case we scaled 0.2 in the x direction, 0.3 in the y direction and the z direction is scaled by 1, which leaves it unchanged. Scale values larger than one will stretch an element. Scale values smaller than one will squish an element. A scale value of one will leave an element unchanged. Pre-defined Textures  XE "#include"  XE "texture" POV-Ray has some very sophisticated textures pre-defined in the standard include files glass.inc, metals.inc, stones.inc and woods.inc. Some are entire textures with pigment, normal and/or finish parameters already defined. Some are just pigments or just finishes. We change the definition of our sphere to the following and then re-render it: sphere { <0, 1, 2>, 2 texture { pigment { DMFWood4 // pre-defined in textures.inc scale 4 // scale by the same amount in all // directions } finish { Shiny } // pre-defined in finish.inc } } The pigment identifier DMFWood4 has already been scaled down quite small when it was defined. For this example we want to scale the pattern larger. Because we want to scale it uniformly we can put a single value after the scale keyword rather than a vector of x, y, z scale factors. We look through the file textures.inc to see what pigments and finishes are defined and try them out. We just insert the name of the new pigment where DMFWood4 is now or try a different finish in place of Shiny and re-render our file. Here is an example of using a complete texture identifier rather than just the pieces. sphere { <0, 1, 2>, 2 texture { PinkAlabaster } } Advanced Texture Options The extremely powerful texturing ability is one thing that really sets POV-Ray apart from other raytracers. So far we have not really tried anything too complex but by now we should be comfortable enough with the program's syntax to try some of the more advanced texture options. Obviously, we cannot try them all. It would take a tutorial a lot more pages to use every texturing option available in POV-Ray. For this limited tutorial, we will content ourselves to just trying a few of them to give an idea of how textures are created. With a little practice, we will soon be creating beautiful textures of our own. Note that early versions of POV-Ray made a distinction between pigment and normal patterns, i. e. patterns that could be used inside a normal or pigment statement. With POV-Ray 3.0 this restriction was removed so that all patterns listed in section " REF _Ref411683931 \h Patterns" can be used as a pigment or normal pattern. Pigments Every surface must have a color. In POV-Ray this color is called a pigment XE "pigment" . It does not have to be a single color. It can be a color pattern, a color list or even an image map. Pigments can also be layered one on top of the next so long as the uppermost layers are at least partially transparent so the ones beneath can show through. Let's play around with some of these kinds of pigments. We create a file called texdemo.pov and edit it as follows: #include "colors.inc" camera { location <1, 1, -7> look_at 0 angle 36 } light_source { <1000, 1000, -1000> White } plane { y, -1.5 pigment { checker Green, White } } sphere { <0,0,0>, 1 pigment { Red } } Giving this file a quick test render at 200x150 -A we see that it is a simple red sphere against a green and white checkered plane. We will be using the sphere for our textures. Using Color List Pigments Before we begin we should note that we have already made one kind of pigment, the color list pigment. In the previous example we have used a checkered pattern on our plane. There are two other kinds of color list pigments, brick XE "brick"  and hexagon XE "hexagon" . Let's quickly try each of these. First, we change the plane's pigment as follows: pigment { hexagon Green, White, Yellow } Rendering this we see a three-color hexagonal pattern. Note that this pattern requires three colors. Now we change the pigment to... pigment { brick Gray75, Red rotate -90*x scale .25 } Looking at the resulting image we see that the plane now has a brick pattern. We note that we had to rotate the pattern to make it appear correctly on the flat plane. This pattern normally is meant to be used on vertical surfaces. We also had to scale the pattern down a bit so we could see it more easily. We can play around with these color list pigments, change the colors, etc. until we get a floor that we like. Using Pigment and Patterns Let's begin texturing our sphere by using a pattern and a color map consisting of three colors. We replace the pigment block with the following. pigment { gradient x color_map { [0.00 color Red] [0.33 color Blue] [0.66 color Yellow] [1.00 color Red] } } Rendering this we see that the gradient XE "gradient"  pattern gives us an interesting pattern of vertical stripes. We change the gradient direction to y. The stripes are horizontal now. We change the gradient direction to z. The stripes are now more like concentric rings. This is because the gradient direction is directly away from the camera. We change the direction back to x and add the following to the pigment block. pigment { gradient x color_map { [0.00 color Red] [0.33 color Blue] [0.66 color Yellow] [1.00 color Red] } rotate -45*z // <- add this line } The vertical bars are now slanted at a 45 degree angle. All patterns can be rotated, scaled and translated in this manner. Let's now try some different types of patterns. One at a time, we substitute the following keywords for gradient x and render to see the result: bozo XE "bozo" , marble XE "marble" , agate XE "agate" , granite XE "granite" , leopard XE "leopard" , spotted XE "spotted"  and wood XE "wood"  (if we like we can test all patterns listed in section " REF _Ref411686157 \h Patterns"). Rendering these we see that each results in a slightly different pattern. But to get really good results each type of pattern requires the use of some pattern modifiers. Using Pattern Modifiers Let's take a look at some pattern modifiers. First, we change the pattern type to bozo. Then we add the following change. pigment { bozo frequency 3 // <- add this line color_map { [0.00 color Red] [0.33 color Blue] [0.66 color Yellow] [1.00 color Red] } rotate -45*z } The frequency XE "frequency"  modifier determines the number of times the color map repeats itself per unit of size. This change makes the bozo pattern we saw earlier have many more bands in it. Now we change the pattern type to marble XE "marble" . When we rendered this earlier, we saw a banded pattern similar to gradient y that really did not look much like marble at all. This is because marble really is a kind of gradient and it needs another pattern modifier to look like marble. This modifier is called turbulence XE "turbulence" . We change the line frequency 3 to turbulence 1 and render again. That's better! Now let's put frequency 3 back in right after the turbulence and take another look. Even more interesting! But wait, it gets better! Turbulence itself has some modifiers of its own. We can adjust the turbulence several ways. First, the float that follows the turbulence keyword can be any value with higher values giving us more turbulence. Second, we can use the keywords omega XE "omega" , lambda XE "lambda"  and octaves XE "octaves"  to change the turbulence parameters. Let's try this now: pigment { marble turbulence 0.5 lambda 1.5 omega 0.8 octaves 5 frequency 3 color_map { [0.00 color Red] [0.33 color Blue] [0.66 color Yellow] [1.00 color Red] } rotate 45*z } Rendering this we see that the turbulence has changed and the pattern looks different. We play around with the numerical values of turbulence, lambda, omega and octaves to see what they do. Using Transparent Pigments and Layered Textures Pigments are described by numerical values that give the rgb value of the color to be used (like color rgb<1,0,0> giving us a red color). But this syntax will give us more than just the rgb values. We can specify filtering transparency by changing it as follows: color rgbf<1,0,0,1>. The f stands for filter XE "filter" , POV-Ray's word for filtered transparency. A value of one means that the color is completely transparent, but still filters the light according to what the pigment is. In this case, the color will be a transparent red, like red cellophane. There is another kind of transparency in POV-Ray. It is called transmittance or non-filtering transparency (the keyword is transmit XE "transmit" ). It is different from filter in that it does not filter the light according to the pigment color. It instead allows all the light to pass through unchanged. It can be specified like this: rgbt <1,0,0,1>. Let's use some transparent pigments to create another kind of texture, the layered texture. Returning to our previous example, declare the following texture. #declare LandArea = texture { pigment { agate turbulence 1 lambda 1.5 omega .8 octaves 8 color_map { [0.00 color rgb <.5, .25, .15>] [0.33 color rgb <.1, .5, .4>] [0.86 color rgb <.6, .3, .1>] [1.00 color rgb <.5, .25, .15>] } } } This texture will be the land area. Now let's make the oceans by declaring the following. #declare OceanArea = texture { pigment { bozo turbulence .5 lambda 2 color_map { [0.00, 0.33 color rgb <0, 0, 1> color rgb <0, 0, 1>] [0.33, 0.66 color rgbf <1, 1, 1, 1> color rgbf <1, 1, 1, 1>] [0.66, 1.00 color rgb <0, 0, 1> color rgb <0, 0, 1>] } } } Note how the ocean is the opaque blue area and the land is the clear area which will allow the underlying texture to show through. Now, let's declare one more texture to simulate an atmosphere with swirling clouds. #declare CloudArea = texture { pigment { agate turbulence 1 lambda 2 frequency 2 color_map { [0.0 color rgbf <1, 1, 1, 1>] [0.5 color rgbf <1, 1, 1, .35>] [1.0 color rgbf <1, 1, 1, 1>] } } } Now apply all of these to our sphere. sphere { <0,0,0>, 1 texture { LandArea } texture { OceanArea } texture { CloudArea } } We render this and have a pretty good rendition of a little planetoid. But it could be better. We don't particularly like the appearance of the clouds. There is a way they could be done that would be much more realistic. Using Pigment Maps Pigments may be blended together in the same way as the colors in a color map using the same pattern keywords and a pigment_map XE "pigment_map" . Let's just give it a try. We add the following declarations, making sure they appear before the other declarations in the file. #declare Clouds1 = pigment { bozo turbulence 1 color_map { [0.0 color White filter 1] [0.5 color White] [1.0 color White filter 1] } } #declare Clouds2 = pigment { agate turbulence 1 color_map { [0.0 color White filter 1] [0.5 color White] [1.0 color White filter 1] } } #declare Clouds3 = pigment { marble turbulence 1 color_map { [0.0 color White filter 1] [0.5 color White] [1.0 color White filter 1] } } #declare Clouds4 = pigment { granite turbulence 1 color_map { [0.0 color White filter 1] [0.5 color White] [1.0 color White filter 1] } } Now we use these declared pigments in our cloud layer on our planetoid. We replace the declared cloud layer with. #declare CloudArea = texture { pigment { gradient y pigment_map { [0.00 Clouds1] [0.25 Clouds2] [0.50 Clouds3] [0.75 Clouds4] [1.00 Clouds1] } } } We render this and see a remarkable pattern that looks very much like weather patterns on the planet earth. They are separated into bands, simulating the different weather types found at different latitudes. Normals Objects in POV-Ray have very smooth surfaces. This is not very realistic so there are several ways to disturb the smoothness of an object by perturbing the surface normal. The surface normal is the vector that is perpendicular to the angle of the surface. By changing this normal the surface can be made to appear bumpy, wrinkled or any of the many patterns available. Let's try a couple of them. Using Basic Normal Modifiers We comment out the planetoid sphere for now and, at the bottom of the file, create a new sphere with a simple, single color texture. sphere { <0,0,0>, 1 pigment { Gray75 } normal { bumps 1 scale .2 } } Here we have added a normal XE "normal"  block in addition to the pigment XE "pigment"  block (note that these do not have to be included in a texture XE "texture"  block unless they need to be transformed together or need to be part of a layered texture). We render this to see what it looks like. Now, one at a time, we substitute for the keyword bumps XE "bumps"  the following keywords: dents XE "dents" , wrinkles XE "wrinkles" , ripples XE "ripples"  and waves XE "waves"  (we can also use any of the patterns listed in "Patterns"). We render each to see what they look like. We play around with the float value that follows the keyword. We also experiment with the scale value. For added interest, we change the plane texture to a single color with a normal as follows. plane { y, -1.5 pigment { color rgb <.65, .45, .35> } normal { dents .75 scale .25 } } Blending Normals Normals can be layered similar to pigments but the results can be unexpected. Let's try that now by editing the sphere as follows. sphere { <0,0,0>, 1 pigment { Gray75 } normal { radial frequency 10 } normal { gradient y scale .2 } } As we can see, the resulting pattern is neither a radial nor a gradient. It is instead the result of first calculating a radial pattern and then calculating a gradient pattern. The results are simply additive. This can be difficult to control so POV-Ray gives the user other ways to blend normals. One way is to use normal maps. A normal map works the same way as the pigment map we used earlier. Let's change our sphere texture as follows. sphere { <0,0,0>, 1 pigment { Gray75 } normal { gradient y frequency 3 turbulence .5 normal_map { [0.00 granite] [0.25 spotted turbulence .35] [0.50 marble turbulence .5] [0.75 bozo turbulence .25] [1.00 granite] } } } Rendering this we see that the sphere now has a very irregular bumpy surface. The gradient pattern type separates the normals into bands but they are turbulated, giving the surface a chaotic appearance. But this give us an idea. Suppose we use the same pattern for a normal map that we used to create the oceans on our planetoid and applied it to the land areas. Does it follow that if we use the same pattern and modifiers on a sphere the same size that the shape of the pattern would be the same? Wouldn't that make the land areas bumpy while leaving the oceans smooth? Let's try it. First, let's render the two spheres side-by-side so we can see if the pattern is indeed the same. We un-comment the planetoid sphere and make the following changes. sphere { <0,0,0>, 1 texture { LandArea } texture { OceanArea } //texture { CloudArea } // <-comment this out translate -x // <- add this transformation } Now we change the gray sphere as follows. sphere { <0,0,0>, 1 pigment { Gray75 } normal { bozo turbulence .5 lambda 2 normal_map { [0.4 dents .15 scale .01] [0.6 agate turbulence 1] [1.0 dents .15 scale .01] } } translate x // <- add this transformation } We render this to see if the pattern is the same. We see that indeed it is. So let's comment out the gray sphere and add the normal XE "normal"  block it contains to the land area texture of our planetoid. We remove the transformations so that the planetoid is centered in the scene again. #declare LandArea = texture { pigment { agate turbulence 1 lambda 1.5 omega .8 octaves 8 color_map { [0.00 color rgb <.5, .25, .15>] [0.33 color rgb <.1, .5, .4>] [0.86 color rgb <.6, .3, .1>] [1.00 color rgb <.5, .25, .15>] } } normal { bozo turbulence .5 lambda 2 normal_map { [0.4 dents .15 scale .01] [0.6 agate turbulence 1] [1.0 dents .15 scale .01] } } } Looking at the resulting image we see that indeed our idea works! The land areas are bumpy while the oceans are smooth. We add the cloud layer back in and our planetoid is complete. There is much more that we did not cover here due to space constraints. On our own, we should take the time to explore slope maps, average and bump maps. Finishes The final part of a POV-Ray texture is the finish. It controls the properties of the surface of an object. It can make it shiny and reflective, or dull and flat. It can also specify what happens to light that passes through transparent pigments, what happens to light that is scattered by less-than-perfectly-smooth surfaces and what happens to light that is reflected by surfaces with thin-film interference properties. There are twelve different properties available in POV-Ray to specify the finish of a given object. These are controlled by the following keywords: ambient, diffuse, brilliance, phong, specular, metallic, reflection, crand and iridescence. Let's design a couple of textures that make use of these parameters. Using Ambient Since objects in POV-Ray are illuminated by light sources, the portions of those objects that are in shadow would be completely black were it not for the first two finish properties, ambient XE "ambient"  and diffuse XE "diffuse" . Ambient is used to simulate the light that is scattered around the scene that does not come directly from a light source. Diffuse determines how much of the light that is seen comes directly from a light source. These two keywords work together to control the simulation of ambient light. Let's use our gray sphere to demonstrate this. Let's also change our plane back to its original green and white checkered pattern. plane {y,-1.5 pigment {checker Green, White} } sphere { <0,0,0>, 1 pigment {Gray75} finish { ambient .2 diffuse .6 } In the above example, the default values for ambient and diffuse are used. We render this to see what the effect is and then make the following change to the finish. ambient 0 diffuse 0 The sphere is black because we have specified that none of the light coming from any light source will be reflected by the sphere. Let's change diffuse back to the default of 0.6. Now we see the gray surface color where the light from the light source falls directly on the sphere but the shaded side is still absolutely black. Now let's change diffuse to 0.3 and ambient to 0.3. The sphere now looks almost flat. This is because we have specified a fairly high degree of ambient light and only a low amount of the light coming from the light source is diffusely reflected towards the camera. The default values of ambient and diffuse are pretty good averages and a good starting point. In most cases, an ambient value of 0.1 ... 0.2 is sufficient and a diffuse value of 0.5 ... 0.7 will usually do the job. There are a couple of exceptions. If we have a completely transparent surface with high refractive and/or reflective values, low values of both ambient and diffuse may be best. Here is an example: sphere { <0,0,0>, 1 pigment { White filter 1 } finish { ambient 0 diffuse 0 reflection .25 specular 1 roughness .001 } interior{ior 1.33} } This is glass, obviously. Glass is a material that takes nearly all of its appearance from its surroundings. Very little of the surface is seen because it transmits or reflects practically all of the light that shines on it. See glass.inc for some other examples. If we ever need an object to be completely illuminated independently of the lighting situation in a given scene we can do this artificially by specifying an ambient value of 1 and a diffuse value of 0. This will eliminate all shading and simply give the object its fullest and brightest color value at all points. This is good for simulating objects that emit light like light bulbs and for skies in scenes where the sky may not be adequately lit by any other means. Let's try this with our sphere now. sphere { <0,0,0>, 1 pigment { White } finish { ambient 1 diffuse 0 } } Rendering this we get a blinding white sphere with no visible highlights or shaded parts. It would make a pretty good streetlight. Using Surface Highlights In the glass example above, we noticed that there were bright little hotspots on the surface. This gave the sphere a hard, shiny appearance. POV-Ray gives us two ways to specify surface specular highlights. The first is called Phong highlighting. Usually, Phong highlights are described using two keywords: phong XE "phong"  and phong_size XE "phong_size" . The float that follows phong determines the brightness of the highlight while the float following phong_size determines its size. Let's try this. sphere { <0,0,0>, 1 pigment { Gray50 } finish { ambient .2 diffuse .6 phong .75 phong_size 25 } } Rendering this we see a fairly broad, soft highlight that gives the sphere a kind of plastic appearance. Now let's change phong_size to 150. This makes a much smaller highlight which gives the sphere the appearance of being much harder and shinier. There is another kind of highlight that is calculated by a different means called specular highlighting. It is specified using the keyword specular XE "specular"  and operates in conjunction with another keyword called roughness XE "roughness" . These two keywords work together in much the same way as phong XE "phong"  and phong_size XE "phong_size"  to create highlights that alter the apparent shininess of the surface. Let's try using specular in our sphere. sphere { <0,0,0>, 1 pigment { Gray50 } finish { ambient .2 diffuse .6 specular .75 roughness .1 } } Looking at the result we see a broad, soft highlight similar to what we had when we used phong_size of 25. Change roughness to .001 and render again. Now we see a small, tight highlight similar to what we had when we used phong_size of 150. Generally speaking, specular is slightly more accurate and therefore slightly more realistic than phong but you should try both methods when designing a texture. There are even times when both phong and specular may be used on a finish. Using Reflection and Metallic There is another surface parameter that goes hand in hand with highlights, reflection XE "reflection" . Surfaces that are very shiny usually have a degree of reflection to them. Let's take a look at an example. sphere { <0,0,0>, 1 pigment { Gray50 } finish { ambient .2 diffuse .6 specular .75 roughness .001 reflection .5 } } We see that our sphere now reflects the green and white checkered plane and the black background but the gray color of the sphere seems out of place. This is another time when a lower diffuse value is needed. Generally, the higher reflection is the lower diffuse XE "diffuse"  should be. We lower the diffuse value to 0.3 and the ambient value to 0.1 and render again. That is much better. Let's make our sphere as shiny as a polished gold ball bearing. sphere { <0,0,0>, 1 pigment { BrightGold } finish { ambient .1 diffuse .1 specular 1 roughness .001 reflection .75 } } That is very close but there is something wrong with the highlight. To make the surface appear more like metal the keyword metallic XE "metallic"  is used. We add it now to see the difference. sphere { <0,0,0>, 1 pigment { BrightGold } finish { ambient .1 diffuse .1 specular 1 roughness .001 reflection .75 metallic } } We see that the highlight has taken on the color of the surface rather than the light source. This gives the surface a more metallic appearance. Using Iridescence Iridescence is what we see on the surface of an oil slick when the sun shines on it. The rainbow effect is created by something called thin-film interference (read section " REF _Ref411753015 \h Iridescence" for details). For now let's just try using it. Iridescence is specified by the irid XE "irid"  statement and three values: amount, thickness XE "thickness"  and turbulence XE "turbulence" . The amount is the contribution to the overall surface color. Usually 0.1 to 0.5 is sufficient here. The thickness affects the "busyness" of the effect. Keep this between 0.25 and 1 for best results. The turbulence is a little different from pigment or normal turbulence. We cannot set octaves XE "octaves" , lambda XE "lambda"  or omega XE "omega"  but we can specify an amount which will affect the thickness in a slightly different way from the thickness value. Values between 0.25 and 1 work best here too. Finally, iridescence will respond to the surface normal since it depends on the angle of incidence of the light rays striking the surface. With all of this in mind, let's add some iridescence to our glass sphere. sphere { <0,0,0>, 1 pigment { White filter 1 } finish { ambient .1 diffuse .1 reflection .2 specular 1 roughness .001 irid { 0.35 thickness .5 turbulence .5 } } interior{ ior 1.5 fade_distance 5 fade_power 1 caustics 1 } } We try to vary the values for amount, thickness and turbulence to see what changes they make. We also try to add a normal block to see what happens. Working With Pigment Maps  XE "pigment_map" Let's look at the pigment map. We must not confuse this with a color map, as color maps can only take individual colors as entries in the map, while pigment maps can use entire other pigment patterns. To get a feel for these, let's begin by setting up a basic plane with a simple pigment map. Now, in the following example, we are going to declare each of the pigments we are going to use before we actually use them. This isn't strictly necessary (we could put an entire pigment description in each entry of the map) but it just makes the whole thing more readable. // simple Black on White checkboard... it's a classic #declare Pigment1 = pigment { checker color Black color White scale .1 } // kind of a "psychedelic rings" effect #declare Pigment2 = pigment { wood color_map { [ 0.0 Red ] [ 0.3 Yellow ] [ 0.6 Green ] [ 1.0 Blue ] } } plane { -z, 0 pigment { gradient x pigment_map { [ 0.0 Pigment1 ] [ 0.5 Pigment2 ] [ 1.0 Pigment1 ] } } } Okay, what we have done here is very simple, and probably quite recognizable if we have been working with color maps all along anyway. All we have done is substituted a pigment map where a color map would normally go, and as the entries in our map, we have referenced our declared pigments. When we render this example, we see a pattern which fades back and forth between the classic checkerboard, and those colorful rings. Because we fade from Pigment1 to Pigment2 and then back again, we see a clear blending of the two patterns at the transition points. We could just as easily get a sudden transition by amending the map to read. pigment_map { [ 0.0 Pigment1 ] [ 0.5 Pigment1 ] [ 0.5 Pigment2 ] [ 1.0 Pigment2 ] } Blending individual pigment patterns is just the beginning. Working With Normal Maps  XE "normal_map"  For our next example, we replace the plane in the scene with this one. plane { -z, 0 pigment { White } normal { gradient x normal_map { [ 0.0 bumps 1 scale .1] [ 1.0 ripples 1 scale .1] } } } First of all, we have chosen a solid white color to show off all bumping to best effect. Secondly, we notice that our map blends smoothly from all bumps at 0.0 to all ripples at 1.0, but because this is a default gradient, it falls off abruptly back to bumps at the beginning of the next cycle. We Render this and see just enough sharp transitions to clearly see where one normal gives over to another, yet also an example of how two normal patterns look while they are smoothly blending into one another. The syntax is the same as we would expect. We just changed the type of map, moved it into the normal block and supplied appropriate bump types. It is important to remember that as of POV-Ray 3, all patterns that work with pigments work as normals as well (and vice versa, of course) so we could just as easily have blended from wood to granite, or any other pattern we like. We experiment a bit and get a feel for what the different patterns look like. After seeing how interesting the various normals look blended, we might like to see them completely blended all the way through rather than this business of fading from one to the next. Well, that is possible too, but we would be getting ahead of ourselves. That is called the average function, and we will return to it a little bit further down the page. Working With Texture Maps  XE "texture_map" We know how to blend colors, pigment patterns, and normals, and we are probably thinking what about finishes? What about whole textures? Both of these can be kind of covered under one topic. While there is no finish map per se, there are texture maps, and we can easily adapt these to serve as finish maps, simply by putting the same pigment and/or normal in each of the texture entries of the map. Here is an example. We eliminate the declared pigments we used before and the previous plane, and add the following. #declare Texture1 = texture { pigment { Grey } finish { reflection 1 } } #declare Texture2 = texture { pigment { Grey } finish { reflection 0 } } cylinder { <-2, 5, -2>, <-2, -5, -2>, 1 pigment { Blue } } plane { -z, 0 rotate y * 30 texture { gradient y texture_map { [ 0.0 Texture1 ] [ 0.4 Texture1 ] [ 0.6 Texture2 ] [ 1.0 Texture2 ] } scale 2 } } Now, what have we done here? The background plane alternates vertically between two textures, identical except for their finishes. When we render this, the cylinder has a reflection part of the way down the plane, and then stops reflecting, then begins and then stops again, in a gradient pattern down the surface of the plane. With a little adaptation, this could be used with any pattern, and in any number of creative ways, whether we just wanted to give various parts of an object different finishes, as we are doing here, or whole different textures altogether. One might ask: if there is a texture map, why do we need pigment and normal maps? Fair question. The answer: speed of calculation. If we use a texture map, for every in-between point, POV-Ray must make multiple calculations for each texture element, and then run a weighted average to produce the correct value for that point. Using just a pigment map (or just a normal map) decreases the overall number of calculations, and our texture renders a bit faster in the bargain. As a rule of thumb: we use pigment or normal maps where we can and only fall back on texture maps if we need the extra flexibility. Working With List Textures  XE "brick"  XE "checker"  XE "hexagon"  If we have followed the corresponding tutorials on simple pigments, we know that there are three patterns called color list patterns, because rather than using a color map, these simple but useful patterns take a list of colors immediately following the pattern keyword. We're talking about checker, hexagon, and, new to POV-Ray 3, the brick pattern. Naturally they also work with whole pigments, normals, and entire textures, just as the other patterns do above. The only difference is that we list entries in the pattern (as we would do with individual colors) rather than using a map of entries. Here is an example. We strike the plane and any declared pigments we had left over in our last example, and add the following to our basic file. #declare Pigment1 = pigment { hexagon color Yellow color Green color Grey scale .1 } #declare Pigment2 = pigment { checker color Red color Blue scale .1 } #declare Pigment3 = pigment { brick color White color Black rotate -90*x scale .1 } box { -5, 5 pigment { hexagon pigment {Pigment1} pigment {Pigment2} pigment {Pigment3} rotate 90*x } } We begin by declaring an example of each of the color list patterns as individual pigments. Then we use the hexagon pattern as a pigment list pattern, simply feeding it a list of pigments rather than colors as we did above. There are two rotate statements throughout this example, because bricks are aligned along the z-direction, while hexagons align along the y-direction, and we wanted everything to face toward the camera we originally declared out in the -z-direction so we can really see the patterns within patterns effect here. Of course color list patterns used to be only for pigments, but as of POV-Ray 3, everything that worked for pigments can now also be adapted for normals or entire textures. A couple of quick examples might look like normal { brick normal { granite .1 } normal { bumps 1 scale .1 } } or... texture { checker texture { Gold_Metal } texture { Silver_Metal } } What About Tiles? In earlier versions of POV-Ray, there was a texture pattern called tiles XE "tiles" . By simply using a checker texture pattern (as we just saw above), we can achieve the same thing as tiles used to do, so it is now obsolete. It is still supported by POV-Ray 3 for backwards compatibility with old scene files, but now is a good time to get in the habit of using a checker pattern instead. Average Function Now things get interesting. Above, we began to see how pigments and normals can fade from one to the other when we used them in maps. But how about if we want a smooth blend of patterns all the way through? That is where a new feature called average XE "average"  can come in very handy. Average works with pigment, normal, and texture maps, although the syntax is a little bit different, and when we are not expecting it, the change can be confusing. Here is a simple example. We use our standard includes, camera and light source from above, and enter the following object. plane { -z, 0 pigment { White } normal { average normal_map { [ gradient x ] [ gradient y ] } } } What we have done here is pretty self explanatory as soon as we render it. We have combined a vertical with a horizontal gradient bump pattern, creating crisscrossing gradients. Actually, the crisscrossing effect is a smooth blend of gradient x with gradient y all the way across our plane. Now, what about that syntax difference? We see how our normal map has changed from earlier examples. The floating point value to the left-hand side of each map entry has been removed. That value usually helps in procedurally mapping each entry to the pattern we have selected, but average is a smooth blend all the way through, not a pattern, so it cannot use those values. In fact, including them may sometimes lead to unexpected results, such as entries being lost or misrepresented in some way. To ensure that we'll get the pattern blend we anticipate, we leave off the floating point value. Working With Layered Textures With the multitudinous colors, patterns, and options for creating complex textures in POV-Ray, we can easily become deeply engrossed in mixing and tweaking just the right textures to apply to our latest creations. But as we go, sooner or later there is going to come that special texture. That texture that is sort of like wood, only varnished, and with a kind of spotty yellow streaking, and some vertical gray flecks, that looks like someone started painting over it all, and then stopped, leaving part of the wood visible through the paint. Only... now what? How do we get all that into one texture? No pattern can do that many things. Before we panic and say image map there is at least one more option: layered textures XE "layered textures" . With layered textures, we only need to specify a series of textures, one after the other, all associated with the same object. Each texture we list will be applied one on top of the other, from bottom to top in the order they appear. It is very important to note that we must have some degree of transparency (filter or transmit) in the pigments of our upper textures, or the ones below will get lost underneath. We won't receive a warning or an error - technically it is legal to do this: it just doesn't make sense. It is like spending hours sketching an elaborate image on a bare wall, then slapping a solid white coat of latex paint over it. Let's design a very simple object with a layered texture, and look at how it works. We create a file called LAYTEX.POV and add the following lines. #include "colors.inc" #include "textures.inc" camera { location <0, 5, -30> look_at <0, 0, 0> } light_source { <-20, 30, -50> color White } plane { y, 0 pigment { checker color Green color Yellow } } background { rgb <.7, .7, 1> } box { <-10, 0, -10>, <10, 10, 10> texture { Silver_Metal // a metal object ... normal { // ... which has suffered a beating dents 2 scale 1.5 } } // (end of base texture) texture { // ... has some flecks of rust ... pigment { granite color_map { [0.0 rgb <.2, 0, 0> ] [0.2 color Brown ] [0.2 rgbt <1, 1, 1, 1> ] [1.0 rgbt <1, 1, 1, 1> ] } frequency 16 } } // (end rust fleck texture) texture { // ... and some sooty black marks pigment { bozo color_map { [0.0 color Black ] [0.2 color rgbt <0, 0, 0, .5> ] [0.4 color rgbt <.5, .5, .5, .5> ] [0.5 color rgbt <1, 1, 1, 1> ] [1.0 color rgbt <1, 1, 1, 1> ] } scale 3 } } // (end of sooty mark texture) } // (end of box declaration) Whew. This gets complicated, so to make it easier to read, we have included comments showing what we are doing and where various parts of the declaration end (so we don't get lost in all those closing brackets!). To begin, we created a simple box over the classic checkerboard floor, and give the background sky a pale blue color. Now for the fun part... To begin with we made the box use the Silver_Metal texture as declared in textures.inc (for bonus points, look up textures.inc and see how this standard texture was originally created sometime). To give it the start of its abused state, we added the dents normal pattern, which creates the illusion of some denting in the surface as if our mysterious metal box had been knocked around quite a bit. The flecks of rust are nothing but a fine grain granite pattern fading from dark red to brown which then abruptly drops to fully transparent for the majority of the color map. True, we could probably come up with a more realistic pattern of rust using pigment maps to cluster rusty spots, but pigment maps are a subject for another tutorial section, so let's skip that just now. Lastly, we have added a third texture to the pot. The randomly shifting bozo texture gradually fades from blackened centers to semi-transparent medium gray, and then ultimately to fully transparent for the latter half of its color map. This gives us a look of sooty burn marks further marring the surface of the metal box. The final result leaves our mysterious metal box looking truly abused, using multiple texture patterns, one on top of the other, to produce an effect that no single pattern could generate! Declaring Layered Textures In the event we want to reuse a layered texture on several objects in our scene, it is perfectly legal to declare a layered texture. We won't repeat the whole texture from above, but the general format would be something like this: #declare Abused_Metal = texture { /* insert your base texture here... */ } texture { /* and your rust flecks here... */ } texture { /* and of course, your sooty burn marks here */ } POV-Ray has no problem spotting where the declaration ends, because the textures follow one after the other with no objects or directives in between. The layered texture to be declared will be assumed to continue until it finds something other than another texture, so any number of layers can be added in to a declaration in this fashion. One final word about layered textures: whatever layered texture we create, whether declared or not, we must not leave off the texture wrapper. In conventional single textures a common shorthand is to have just a pigment, or just a pigment and finish, or just a normal, or whatever, and leave them outside of a texture statement. This shorthand does not extend to layered textures. As far as POV-Ray is concerned we can layer entire textures, but not individual pieces of textures. For example #declare Bad_Texture = texture { /* insert your base texture here... */ } pigment { Red filter .5 } normal { bumps 1 } will not work. The pigment and the normal are just floating there without being part of any particular texture. Inside an object, with just a single texture, we can do this sort of thing, but with layered textures, we would just generate an error whether inside the object or in a declaration. Another Layered Textures Example To further explain how layered textures work another example is described in detail. A tablecloth is created to be used in a picnic scene. Since a simple red and white checkered cloth looks entirely too new, too flat, and too much like a tiled floor, layered textures are used to stain the cloth. We're going to create a scene containing four boxes. The first box has that plain red and white texture we started with in our picnic scene, the second adds a layer meant to realistically fade the cloth, the third adds some wine stains, and the final box adds a few wrinkles (not another layer, but we must note when and where adding changes to the surface normal have an effect in layered textures). We start by placing a camera, some lights, and the first box. At this stage, the texture is plain tiling, not layered. See file layered1.pov. #include "colors.inc" camera { location <0, 0, -6> look_at <0, 0, 0> } light_source { <-20, 30, -100> color White } light_source { <10, 30, -10> color White } light_source { <0, 30, 10> color White } #declare PLAIN_TEXTURE = // red/white check texture { pigment { checker color rgb<1.000, 0.000, 0.000> color rgb<1.000, 1.000, 1.000> scale <0.2500, 0.2500, 0.2500> } } // plain red/white check box box { <-1, -1, -1>, <1, 1, 1> texture { PLAIN_TEXTURE } translate <-1.5, 1.2, 0> } We render this scene. It is not particularly interesting, isn't it? That is why we will use some layered textures to make it more interesting. First, we add a layer of two different, partially transparent grays. We tile them as we had tiled the red and white colors, but we add some turbulence to make the fading more realistic. We add following box to the previous scene and re-render (see file layered2.pov). #declare FADED_TEXTURE = // red/white check texture texture { pigment { checker color rgb<0.920, 0.000, 0.000> color rgb<1.000, 1.000, 1.000> scale <0.2500, 0.2500, 0.2500> } } // greys to fade red/white texture { pigment { checker color rgbf<0.632, 0.612, 0.688, 0.698> color rgbf<0.420, 0.459, 0.520, 0.953> turbulence 0.500 scale <0.2500, 0.2500, 0.2500> } } // faded red/white check box box { <-1, -1, -1>, <1, 1, 1> texture { FADED_TEXTURE } translate <1.5, 1.2, 0> } Even though it is a subtle difference, the red and white checks no longer look quite so new. Since there is a bottle of wine in the picnic scene, we thought it might be a nice touch to add a stain or two. While this effect can almost be achieved by placing a flattened blob on the cloth, what we really end up with is a spill effect, not a stain. Thus it is time to add another layer. Again, we add another box to the scene we already have scripted and re-render (see file layered3.pov). #declare STAINED_TEXTURE = // red/white check texture { pigment { checker color rgb<0.920, 0.000, 0.000> color rgb<1.000, 1.000, 1.000> scale <0.2500, 0.2500, 0.2500> } } // greys to fade check texture { pigment { checker color rgbf<0.634, 0.612, 0.688, 0.698> color rgbf<0.421, 0.463, 0.518, 0.953> turbulence 0.500 scale <0.2500, 0.2500, 0.2500> } } // wine stain texture { pigment { spotted color_map { [ 0.000 color rgb<0.483, 0.165, 0.165> ] [ 0.329 color rgbf<1.000, 1.000, 1.000, 1.000> ] [ 0.734 color rgbf<1.000, 1.000, 1.000, 1.000> ] [ 1.000 color rgb<0.483, 0.165, 0.165> ] } turbulence 0.500 frequency 1.500 } } // stained box box { <-1, -1, -1>, <1, 1, 1> texture { STAINED_TEXTURE } translate <-1.5, -1.2, 0> } Now there's a tablecloth texture with personality. Another touch we want to add to the cloth are some wrinkles as if the cloth had been rumpled. This is not another texture layer, but when working with layered textures, we must keep in mind that changes to the surface normal must be included in the uppermost layer of the texture. Changes to lower layers have no effect on the final product (no matter how transparent the upper layers are). We add this final box to the script and re-render (see file layered4.pov) #declare WRINKLED_TEXTURE = // red and white check texture { pigment { checker color rgb<0.920, 0.000, 0.000> color rgb<1.000, 1.000, 1.000> scale <0.2500, 0.2500, 0.2500> } } // greys to "fade" checks texture { pigment { checker color rgbf<0.632, 0.612, 0.688, 0.698> color rgbf<0.420, 0.459, 0.520, 0.953> turbulence 0.500 scale <0.2500, 0.2500, 0.2500> } } // the wine stains texture { pigment { spotted color_map { [ 0.000 color rgb<0.483, 0.165, 0.165> ] [ 0.329 color rgbf<1.000, 1.000, 1.000, 1.000> ] [ 0.734 color rgbf<1.000, 1.000, 1.000, 1.000> ] [ 1.000 color rgb<0.483, 0.165, 0.165> ] } turbulence 0.500 frequency 1.500 } normal { wrinkles 5.0000 } } // wrinkled box box { <-1, -1, -1>, <1, 1, 1> texture { WRINKLED_TEXTURE } translate <1.5, -1.2, 0> } Well, this may not be the tablecloth we want at any picnic we're attending, but if we compare the final box to the first, we see just how much depth, dimension, and personality is possible just by the use of creative texturing. One final note: the comments concerning the surface normal do not hold true for finishes. If a lower layer contains a specular finish and an upper layer does not, any place where the upper layer is transparent, the specular will show through. When All Else Fails: Material Maps We have some pretty powerful texturing tools at our disposal, but what if we want a more free form arrangement of complex textures? Well, just as image maps do for pigments, and bump maps do for normals, whole textures can be mapped using a material map, should the need arise. Just as with image maps and bump maps, we need a source image in bitmapped format which will be called by POV-Ray to serve as the map of where the individual textures will go, but this time, we need to specify what texture will be associated with which palette index. To make such an image, we can use a paint program which allows us to select colors by their palette index number (the actual color is irrelevant, since it is only a map to tell POV-Ray what texture will go at that location). Now, if we have the complete package that comes with POV-Ray, we have in our include files an image called povmap.gif which is a bitmapped image that uses only the first four palette indices to create a bordered square with the words "Persistence of Vision" in it. This will do just fine as a sample map for the following example. Using our same include files, the camera and light source, we enter the following object. plane { -z, 0 texture { material_map { gif "povmap.gif" interpolate 2 once texture { PinkAlabaster } // the inner border texture { pigment { DMFDarkOak } } // outer border texture { Gold_Metal } // lettering texture { Chrome_Metal } // the window panel } translate <-0.5, -0.5, 0> scale 5 } } The position of the light source and the lack of foreground objects to be reflected do not show these textures off to their best advantage. But at least we can see how the process works. The textures have simply been placed according to the location of pixels of a particular palette index. By using the once XE "once"  keyword (to keep it from tiling), and translating and scaling our map to match the camera we have been using, we get to see the whole thing laid out for us. Of course, that is just with palette mapped image formats, such as GIF and certain flavors of PNG. Material maps can also use non-paletted formats, such as the TGA files that POV-Ray itself outputs. That leads to an interesting consequence: We can use POV-Ray to produce source maps for POV-Ray! Before we wrap up with some of the limitations of special textures, let's do one more thing with material maps, to show how POV-Ray can make its own source maps. To begin with, if using an non-paletted image, POV-Ray looks at the 8 bit red component of the pixel's color (which will be a value from 0 to 255) to determine which texture from the list to use. So to create a source map, we need to control very precisely what the red value of a given pixel will be. We can do this by 1.) Using an rgb statement to choose our color such as rgb , where "N" is the red value we want to assign that pigment, and then... 2.) Use no light sources and apply a finish of finish{ambient 1} to all objects, to ensure that highlighting and shadowing will not interfere. Confused? Alright, here is an example, which will generate a map very much like povmap.gif which we used earlier, except in TGA file format. We notice that we have given the pigments blue and green components too. POV-Ray will ignore that in our final map, so this is really for us humans, whose unaided eyes cannot tell the difference between red variances of 0 to 4/255ths. Without those blue and green variances, our map would look to our eyes like a solid black screen. That may be a great way to send secret messages using POV-Ray (plug it into a material map to decode) but it is no use if we want to see what our source map looks like to make sure we have what we expected to. We render the following code, and name the resulting file povmap.tga. camera { orthographic up <0, 5, 0> right <5, 0, 0> location <0, 0, -25> look_at <0, 0, 0> } plane { -z, 0 pigment { rgb <1/255, 0, 0.5> } finish { ambient 1 } } box { <-2.3, -1.8, -0.2>, <2.3, 1.8, -0.2> pigment { rgb <0/255, 0, 1> } finish { ambient 1 } } box { <-1.95, -1.3, -0.4>, <1.95, 1.3, -0.3> pigment { rgb <2/255, 0.5, 0.5> } finish { ambient 1 } } text { ttf "crystal.ttf", "The vision", 0.1, 0 scale <0.7, 1, 1> translate <-1.8, 0.25, -0.5> pigment { rgb <3/255, 1, 1> } finish { ambient 1 } } text { ttf "crystal.ttf", "Persists!", 0.1, 0 scale <0.7, 1, 1> translate <-1.5, -1, -0.5> pigment { rgb <3/255, 1, 1> } finish { ambient 1 } } All we have to do is modify our last material map example by changing the material map from GIF to TGA and modifying the filename. When we render using the new map, the result is extremely similar to the palette mapped GIF we used before, except that we didn't have to use an external paint program to generate our source: POV-Ray did it all! Limitations Of Special Textures There are a couple limitations to all of the special textures we have seen (from textures, pigment and normal maps through material maps). First, if we have used the default directive to set the default texture for all items in our scene, it will not accept any of the special textures discussed here. This is really quite minor, since we can always declare such a texture and apply it individually to all objects. It doesn't actually prevent us from doing anything we couldn't otherwise do. The other is more limiting, but as we will shortly see, can be worked around quite easily. If we have worked with layered textures, we have already seen how we can pile multiple texture patterns on top of one another (as long as one texture has transparency in it). This very useful technique has a problem incorporating the special textures we have just seen as a layer. But there is an answer! For example, say we have a layered texture called Speckled_Metal, which produces a silver metallic surface, and then puts tiny specks of rust all over it. Then we decide, for a really rusty look, we want to create patches of concentrated rust, randomly over the surface. The obvious approach is to create a special texture pattern, with transparency to use as the top layer. But of course, as we have seen, we wouldn't be able to use that texture pattern as a layer. We would just generate an error message. The solution is to turn the problem inside out, and make our layered texture part of the texture pattern instead, like this // This part declares a pigment for use // in the rust patch texture pattern #declare Rusty = pigment { granite color_map { [ 0 rgb <0.2, 0, 0> ] [ 1 Brown ] } frequency 20 } // And this part applies it // Notice that our original layered texture // "Speckled_Metal" is now part of the map #declare Rust_Patches = texture { bozo texture_map { [ 0.0 pigment {Rusty} ] [ 0.75 Speckled_Metal ] [ 1.0 Speckled_Metal ] } } And the ultimate effect is the same as if we had layered the rust patches on to the speckled metal anyway. With the full array of patterns, pigments, normals, finishes, layered and special textures, there is now practically nothing we cannot create in the way of amazing textures. An almost infinite number of new possibilities are just waiting to be created! Using the Camera Using Focal Blur Let's construct a simple scene to illustrate the use of focal blur. For this example we will use a pink sphere, a green box and a blue cylinder with the sphere placed in the foreground, the box in the center and the cylinder in the background. A checkered floor for perspective and a couple of light sources will complete the scene. We create a new file called focaldem.pov and enter the following text #include "colors.inc" #include "shapes.inc" #include "textures.inc" sphere { <1, 0, -6>, 0.5 finish { ambient 0.1 diffuse 0.6 } pigment { NeonPink } } box { <-1, -1, -1>, < 1, 1, 1> rotate <0, -20, 0> finish { ambient 0.1 diffuse 0.6 } pigment { Green } } cylinder { <-6, 6, 30>, <-6, -1, 30>, 3 finish { ambient 0.1 diffuse 0.6 } pigment {NeonBlue} } plane { y, -1.0 pigment { checker color Gray65 color Gray30 } } light_source { <5, 30, -30> color White } light_source { <-5, 30, -30> color White } Now we can proceed to place our focal blur camera to an appropriate viewing position. Straight back from our three objects will yield a nice view. Adjusting the focal point will move the point of focus anywhere in the scene. We just add the following lines to the file: camera { location <0.0, 1.0, -10.0> look_at <0.0, 1.0, 0.0> // focal_point <-6, 1, 30> // blue cylinder in focus // focal_point < 0, 1, 0> // green box in focus focal_point < 1, 1, -6> // pink sphere in focus aperture 0.4 // a nice compromise // aperture 0.05 // almost everything is in focus // aperture 1.5 // much blurring // blur_samples 4 // fewer samples, faster to render blur_samples 20 // more samples, higher quality image } The focal point is simply the point at which the focus of the camera is at its sharpest. We position this point in our scene and assign a value to the aperture to adjust how close or how far away we want the focal blur to occur from the focused area. The aperture setting can be considered an area of focus. Opening up the aperture has the effect of making the area of focus smaller while giving the aperture a smaller value makes the area of focus larger. This is how we control where focal blur begins to occur around the focal point. The blur samples setting determines how many rays are used to sample each pixel. Basically, the more rays that are used the higher the quality of the resultant image, but consequently the longer it takes to render. Each scene is different so we have to experiment. This tutorial has examples of 4 and 20 samples but we can use more for high resolution images. We should not use more samples than is necessary to achieve the desired quality - more samples take more time to render. The confidence and variance settings are covered in section " REF _Ref414259498 \h Focal Blur". We experiment with the focal point, aperture, and blur sample settings. The scene has lines with other values that we can try by commenting out the default line with double slash marks and un-commenting the line we wish to try out. We make only one change at a time to see the effect on the scene. Two final points when tracing a scene using a focal blur camera. We needn't specify anti-aliasing because the focal blur code uses its one sampling method that automatically takes care of anti-aliasing. Focal blur can only be used with the perspective camera. Using Atmospheric Effects POV-Ray offers a variety of atmospheric effects, i. e. features that affect the background of the scene or the air by which everything is surrounded. It is easy to assign a simple color or a complex color pattern to a virtual sky sphere. You can create anything from a cloud free, blue summer sky to a stormy, heavy clouded sky. Even starfields can easily be created. You can use different kinds of fog to create foggy scenes. Multiple fog layers of different colors can add an eerie touch to your scene. A much more realistic effect can be created by using an atmosphere, a constant fog that interacts with the light coming from light sources. Beams of light become visible and objects will cast shadows into the fog. Last but not least you can add a rainbow to your scene. The Background The background XE "background"  feature is used to assign a color to all rays that don't hit any object. This is done in the following way. camera { location <0, 0, -10> look_at <0, 0, 0> } background { color rgb <0.2, 0.2, 0.3> } sphere { 0, 1 pigment { color rgb <0.8, 0.5, 0.2> } } The background color will be visible if a sky sphere is used and if some translucency remains after all sky sphere pigment layers are processed. The Sky Sphere The sky_sphere XE "sky_sphere"  can be used to easily create a cloud covered sky, a nightly star sky or whatever sky you have in mind. In the following examples we'll start with a very simple sky sphere that will get more and more complex as we add new features to it. Creating a Sky with a Color Gradient Beside the single color sky sphere that is covered with the background feature the simplest sky sphere is a color gradient. You may have noticed that the color of the sky varies with the angle to the earth's surface normal. If you look straight up the sky normally has a much deeper blue than it has at the horizon. We want to model this effect using the sky sphere as shown in the scene below (skysph1.pov). #include "colors.inc" camera { location <0, 1, -4> look_at <0, 2, 0> angle 80 } light_source { <10, 10, -10> White } sphere { 2*y, 1 pigment { color rgb <1, 1, 1> } finish { ambient 0.2 diffuse 0 reflection 0.6 } } sky_sphere { pigment { gradient y color_map { [0 color Red] [1 color Blue] } scale 2 translate -1 } } The interesting part is the sky sphere statement. It contains a pigment that describe the look of the sky sphere. We want to create a color gradient along the viewing angle measured against the earth's surface normal. Since the ray direction vector is used to calculate the pigment colors we have to use the y-gradient. The scale and translate transformation are used to map the points derived from the direction vector to the right range. Without those transformations the pattern would be repeated twice on the sky sphere. The scale statement is used to avoid the repetition and the translate -1 statement moves the color at index zero to the bottom of the sky sphere (that's the point of the sky sphere you'll see if you look straight down). After this transformation the color entry at position 0 will be at the bottom of the sky sphere, i. e. below us, and the color at position 1 will be at the top, i. e. above us. The colors for all other positions are interpolated between those two colors as you can see in the resulting image.  A simple gradient sky sphere. If you want to start one of the colors at a specific angle you'll first have to convert the angle to a color map index. This is done by using the formula color_map_index = (1 - cos(angle)) / 2 where the angle is measured against the negated earth's surface normal. This is the surface normal pointing towards the center of the earth. An angle of 0 degrees describes the point below us while an angle of 180 degrees represents the zenith. In POV-Ray you first have to convert the degree value to radian values as it is shown in the following example. sky_sphere { pigment { gradient y color_map { [(1-cos(radians( 30)))/2 color Red] [(1-cos(radians(120)))/2 color Blue] } scale 2 translate -1 } } This scene uses a color gradient that starts with a red color at 30 degrees and blends into the blue color at 120 degrees. Below 30 degrees everything is red while above 120 degrees all is blue. Adding the Sun In the following example we will create a sky with a red sun surrounded by a red color halo that blends into the dark blue night sky. We'll do this using only the sky sphere feature. The sky sphere we use is shown below. A ground plane is also added for greater realism (skysph2.pov). sky_sphere { pigment { gradient y color_map { [0.000 0.002 color rgb <1.0, 0.2, 0.0> color rgb <1.0, 0.2, 0.0>] [0.002 0.200 color rgb <0.8, 0.1, 0.0> color rgb <0.2, 0.2, 0.3>] } scale 2 translate -1 } rotate -135*x } plane { y, 0 pigment { color Green } finish { ambient .3 diffuse .7 } } The gradient pattern and the transformation inside the pigment are the same as in the example in the previous section. The color map consists of three colors. A bright, slightly yellowish red that is used for the sun, a darker red for the halo and a dark blue for the night sky. The sun's color covers only a very small portion of the sky sphere because we don't want the sun to become too big. The color is used at the color map values 0.000 and 0.002 to get a sharp contrast at value 0.002 (we don't want the sun to blend into the sky). The darker red color used for the halo blends into the dark blue sky color from value 0.002 to 0.200. All values above 0.200 will reveal the dark blue sky. The rotate -135*x statement is used to rotate the sun and the complete sky sphere to its final position. Without this rotation the sun would be at 0 degrees, i.e. right below us.  A red sun descends into the night. Looking at the resulting image you'll see what impressive effects you can achieve with the sky sphere. Adding Some Clouds To further improve our image we want to add some clouds by adding a second pigment. This new pigment uses the bozo pattern to create some nice clouds. Since it lays on top of the other pigment it needs some transparent colors in the color map (look at entries 0.5 to 1.0). sky_sphere { pigment { gradient y color_map { [0.000 0.002 color rgb <1.0, 0.2, 0.0> color rgb <1.0, 0.2, 0.0>] [0.002 0.200 color rgb <0.8, 0.1, 0.0> color rgb <0.2, 0.2, 0.3>] } scale 2 translate -1 } pigment { bozo turbulence 0.65 octaves 6 omega 0.7 lambda 2 color_map { [0.0 0.1 color rgb <0.85, 0.85, 0.85> color rgb <0.75, 0.75, 0.75>] [0.1 0.5 color rgb <0.75, 0.75, 0.75> color rgbt <1, 1, 1, 1>] [0.5 1.0 color rgbt <1, 1, 1, 1> color rgbt <1, 1, 1, 1>] } scale <0.2, 0.5, 0.2> } rotate -135*x }  A cloudy sky with a setting sun. The sky sphere has one drawback as you might notice when looking at the final image (skysph3.pov). The sun doesn't emit any light and the clouds will not cast any shadows. If you want to have clouds that cast shadows you'll have to use a real, large sphere with an appropriate texture and a light source somewhere outside the sphere. The Fog You can use the fog XE "fog"  feature to add fog of two different types to your scene: constant fog and ground fog. The constant fog has a constant density everywhere while the ground fog's density decreases as you move upwards. The usage of both fog types will be described in the next sections in detail. A Constant Fog The simplest fog type is the constant fog that has a constant density in all locations. It is specified by a distance XE "distance"  keyword which actually describes the fog's density and a fog color XE "color" . The distance value determines the distance at which 36.8% of the background are still visible (for a more detailed explanation of how the fog is calculated read the reference section " REF _Ref411773210 \h Fog"). The fog color can be used to create anything from a pure white to a red, blood-colored fog. You can also use a black fog to simulate the effect of a limited range of vision. The following example will show you how to add fog to a simple scene (fog1.pov). #include "colors.inc" camera { location <0, 20, -100> } background { color SkyBlue } plane { y, -10 pigment { checker color Yellow color Green scale 20 } } sphere { <0, 25, 0>, 40 pigment { Red } finish { phong 1.0 phong_size 20 } } sphere { <-100, 150, 200>, 20 pigment { Green } finish { phong 1.0 phong_size 20 } } sphere { <100, 25, 100>, 30 pigment { Blue } finish { phong 1.0 phong_size 20 } } light_source { <100, 120, 40> color White} fog { distance 150 color rgb<0.3, 0.5, 0.2> }  A foggy scene. According to their distance the spheres in this scene more or less vanish in the greenish fog we used, as does the checkerboard plane. Setting a Minimum Translucency If you want to make sure that the background does not completely vanish in the fog you can set the transmittance channel of the fog's color to the amount of background you always want to be visible. Using as transmittance value of 0.2 as in fog { distance 150 color rgbt<0.3, 0.5, 0.2, 0.2> } the fog's translucency never drops below 20% as you can see in the resulting image (fog2.pov).  Adding a translucency threshold you make sure that the background does not vanish. Creating a Filtering Fog The greenish fog we have used so far doesn't filter the light passing through it. All it does is to diminish the light's intensity. We can change this by using a non-zero filter channel in the fog's color (fog3.pov). fog { distance 150 color rgbf<0.3, 0.5, 0.2, 1.0> } The filter value determines the amount of light that is filtered by the fog. In our example 100% of the light passing through the fog will be filtered by the fog. If we had used a value of 0.7 only 70% of the light would have been filtered. The remaining 30% would have passed unfiltered.  A filtering fog. You'll notice that the intensity of the objects in the fog is not only diminished due to the fog's color but that the colors are actually influenced by the fog. The red and especially the blue sphere got a green hue. Adding Some Turbulence to the Fog In order to make our somewhat boring fog a little bit more interesting we can add some turbulence, making it look like it had a non-constant density (fog4.pov). fog { distance 150 color rgbf<0.3, 0.5, 0.2, 1.0> turbulence 0.2 turb_depth 0.3 }  Adding some turbulence makes the fog more interesting. The turbulence XE "turbulence"  keyword is used to specify the amount of turbulence used while the turb_depth XE "turb_depth"  value is used to move the point at which the turbulence value is calculated along the viewing ray. Values near zero move the point to the viewer while values near one move it to the intersection point (the default value is 0.5). This parameter can be used to avoid noise that may appear in the fog due to the turbulence (this normally happens at very far away intersection points, especially if no intersection occurs, i. e. the background is hit). If this happens just lower the turb_depth XE "turb_depth"  value until the noise vanishes. You should keep in mind that the actual density of the fog does not change. Only the distance-based attenuation value of the fog is modified by the turbulence value at a point along the viewing ray. Using Ground Fog The much more interesting and flexible fog type is the ground fog, which is selected with the fog_type XE "fog_type"  statement. It's appearance is described with the fog_offset XE "fog_offset"  and fog_alt XE "fog_alt"  keywords. The fog_offset specifies the height, i. e. y value, below which the fog has a constant density of one. The fog_alt keyword determines how fast the density of the fog will approach zero as one moves along the y axis. At a height of fog_offset+fog_alt the fog will have a density of 25%. The following example (fog5.pov) uses a ground fog which has a constant density below y=25 (the center of the red sphere) and quickly falls off for increasing altitudes. fog { distance 150 color rgbf<0.3, 0.5, 0.2, 1.0> fog_type 2 fog_offset 25 fog_alt 1 }  The ground fog only covers the lower parts of the world.' Using Multiple Layers of Fog It is possible to use several layers of fog by using more than one fog statement in your scene file. This is quite useful if you want to get nice effects using turbulent ground fogs. You could add up several, differently colored fogs to create an eerie scene for example. Just try the following example (fog6.pov). fog { distance 150 color rgb<0.3, 0.5, 0.2> fog_type 2 fog_offset 25 fog_alt 1 turbulence 0.1 turb_depth 0.2 } fog { distance 150 color rgb<0.5, 0.1, 0.1> fog_type 2 fog_offset 15 fog_alt 4 turbulence 0.2 turb_depth 0.2 } fog { distance 150 color rgb<0.1, 0.1, 0.6> fog_type 2 fog_offset 10 fog_alt 2 }  Quite nice results can be achieved using multiple layers of fog. You can combine constant density fogs, ground fogs, filtering fogs, non-filtering fogs, fogs with a translucency threshold, etc. Fog and Hollow Objects Whenever you use the fog feature and the camera is inside a non-hollow object you won't get any fog effects. For a detailed explanation why this happens see " REF _Ref412028393 \h Empty and Solid Objects". In order to avoid this problem you have to make all those objects hollow by either making sure the camera is outside these objects (using the inverse XE "inverse"  keyword) or by adding the hollow XE "hollow"  to them (which is much easier). The Rainbow The rainbow XE "rainbow"  feature can be used to create rainbows and maybe other more strange effects. The rainbow is a fog like effect that is restricted to a cone-like volume. Starting With a Simple Rainbow The rainbow is specified with a lot of parameters: the angle under which it is visible, the width of the color band, the direction of the incoming light, the fog-like distance based particle density and last but not least the color map to be used. The size and shape of the rainbow are determined by the angle XE "angle"  and width XE "width"  keywords. The direction XE "direction"  keyword is used to set the direction of the incoming light, thus setting the rainbow's position. The rainbow is visible when the angle between the direction vector and the incident light direction is larger than angle-width/2 and smaller than angle+width/2. The incoming light is the virtual light source that is responsible for the rainbow. There needn't be a real light source to create the rainbow effect. The rainbow is a fog-like effect, i.e. the rainbow's color is mixed with the background color based on the distance to the intersection point. If you choose small distance values the rainbow will be visible on objects, not just in the background. You can avoid this by using a very large distance value. The color map is the crucial part of the rainbow since it contains all the colors that normally can be seen in a rainbow. The color of the innermost color band is taken from the color map entry 0 while the outermost band is take from entry 1. You should note that due to the limited color range any monitor can display it is impossible to create a real rainbow. There are just some colors that you cannot display. The filter channel of the rainbow's color map is used in the same way as with fogs. It determines how much of the light passing through the rainbow is filtered by the color. The following example shows a simple scene with a ground plane, three spheres and a somewhat exaggerated rainbow (rainbow1.pov). #include "colors.inc" camera { location <0, 20, -100> look_at <0, 25, 0> angle 80 } background { color SkyBlue } plane { y, -10 pigment { color Green } } light_source {<100, 120, 40> color White} // declare rainbow's colors #declare r_violet1 = color rgbf<1.0, 0.5, 1.0, 1.0>; #declare r_violet2 = color rgbf<1.0, 0.5, 1.0, 0.8>; #declare r_indigo = color rgbf<0.5, 0.5, 1.0, 0.8>; #declare r_blue = color rgbf<0.2, 0.2, 1.0, 0.8>; #declare r_cyan = color rgbf<0.2, 1.0, 1.0, 0.8>; #declare r_green = color rgbf<0.2, 1.0, 0.2, 0.8>; #declare r_yellow = color rgbf<1.0, 1.0, 0.2, 0.8>; #declare r_orange = color rgbf<1.0, 0.5, 0.2, 0.8>; #declare r_red1 = color rgbf<1.0, 0.2, 0.2, 0.8>; #declare r_red2 = color rgbf<1.0, 0.2, 0.2, 1.0>; // create the rainbow rainbow { angle 42.5 width 5 distance 1.0e7 direction <-0.2, -0.2, 1> jitter 0.01 color_map { [0.000 color r_violet1] [0.100 color r_violet2] [0.214 color r_indigo] [0.328 color r_blue] [0.442 color r_cyan] [0.556 color r_green] [0.670 color r_yellow] [0.784 color r_orange] [0.900 color r_red1] } } Some irregularity is added to the color bands using the jitter XE "jitter"  keyword.  A colorful rainbow. The rainbow in our sample is much too bright. You'll never see a rainbow like this in reality. You can decrease the rainbow's colors by decreasing the RGB values in the color map. Increasing the Rainbow's Translucency The result we have so far looks much too bright. Just reducing the rainbow's color helps but it's much better to increase the translucency of the rainbow because it is more realistic if the background is visible through the rainbow. We can use the transmittance channel of the colors in the color map to specify a minimum translucency, just like we did with the fog. To get realistic results we have to use very large transmittance values as you can see in the following example (rainbow2.pov). rainbow { angle 42.5 width 5 distance 1.0e7 direction <-0.2, -0.2, 1> jitter 0.01 color_map { [0.000 color r_violet1 transmit 0.98] [0.100 color r_violet2 transmit 0.96] [0.214 color r_indigo transmit 0.94] [0.328 color r_blue transmit 0.92] [0.442 color r_cyan transmit 0.90] [0.556 color r_green transmit 0.92] [0.670 color r_yellow transmit 0.94] [0.784 color r_orange transmit 0.96] [0.900 color r_red1 transmit 0.98] } } The transmittance values increase at the outer bands of the rainbow to make it softly blend into the background.  A much more realistic rainbow. The resulting image looks much more realistic than our first rainbow. Using a Rainbow Arc Currently our rainbow has a circular shape, even though most of it is hidden below the ground plane. You can easily create a rainbow arc by using the arc_angle XE "arc_angle"  keyword with an angle below 360 degrees. If you use arc_angle 120 for example you'll get a rainbow arc that abruptly vanishes at the arc's ends. This does not look good. To avoid this the falloff_angle XE "falloff_angle"  keyword can be used to specify a region where the arc smoothly blends into the background. As explained in the rainbow's reference section (see " REF _Ref412028912 \h Rainbow") the arc extends from -arc_angle/2 to arc_angle/2 while the blending takes place from -arc_angle/2 to -falloff_angle/2 and falloff_angle/2 to arc_angle/2. This is the reason why the falloff_angle has to be smaller or equal to the arc_angle. In the following examples we use an 120 degrees arc with a 45 degree falloff region on both sides of the arc (rainbow3.pov). rainbow { angle 42.5 width 5 arc_angle 120 falloff_angle 30 distance 1.0e7 direction <-0.2, -0.2, 1> jitter 0.01 color_map { [0.000 color r_violet1 transmit 0.98] [0.100 color r_violet2 transmit 0.96] [0.214 color r_indigo transmit 0.94] [0.328 color r_blue transmit 0.92] [0.442 color r_cyan transmit 0.90] [0.556 color r_green transmit 0.92] [0.670 color r_yellow transmit 0.94] [0.784 color r_orange transmit 0.96] [0.900 color r_red1 transmit 0.98] } } The arc angles are measured against the rainbows up direction which can be specified using the up XE "up"  keyword. By default the up direction is the y-axis.  A rainbow arc. We finally have a realistic looking rainbow arc. Animation  XE "animation" There are a number of programs available that will take a series of still image files (such as POV-Ray outputs) and assemble them into animations. Such programs can produce AVI, MPEG, FLI/FLC, QuickTime, or even animated GIF files (for use on the World Wide Web). The trick, therefore, is how to produce the frames. That, of course, is where POV-Ray comes in. In earlier versions producing an animation series was no joy, as everything had to be done manually. We had to set the clock variable, and handle producing unique file names for each individual frame by hand. We could achieve some degree of automation by using batch files or similar scripting devices, but still, We had to set it all up by hand, and that was a lot of work (not to mention frustration... imagine forgetting to set the individual file names and coming back 24 hours later to find each frame had overwritten the last). Now, at last, with POV-Ray 3, there is a better way. We no longer need a separate batch script or external sequencing programs, because a few simple settings in our INI file (or on the command line) will activate an internal animation sequence which will cause POV-Ray to automatically handle the animation loop details for us. Actually, there are two halves to animation support: those settings we put in the INI file (or on the command line), and those code modifications we work into our scene description file. If we've already worked with animation in previous versions of POV-Ray, we can probably skip ahead to the section " REF _Ref412029139 \h INI File Settings" below. Otherwise, let's start with basics. Before we get to how to activate the internal animation loop, let's look at a couple examples of how a couple of keywords can set up our code to describe the motions of objects over time. The Clock Variable: Key To It All POV-Ray supports an automatically declared floating point variable identified as clock (all lower case). This is the key to making image files that can be automated. In command line operations, the clock variable is set using the +k switch. For example, +k3.4 from the command line would set the value of clock to 3.4. The same could be accomplished from the INI file using Clock=3.4 in an INI file. If we don't set clock for anything, and the animation loop is not used (as will be described a little later) the clock variable is still there - it's just set for the default value of 0.0, so it is possible to set up some POV code for the purpose of animation, and still render it as a still picture during the object/world creation stage of our project. The simplest example of using this to our advantage would be having an object which is travelling at a constant rate, say, along the x-axis. We would have the statement translate in our object's declaration, and then have the animation loop assign progressively higher values to clock. And that's fine, as long as only one element or aspect of our scene is changing, but what happens when we want to control multiple changes in the same scene simultaneously? The secret here is to use normalized clock values, and then make other variables in your scene proportional to clock. That is, when we set up our clock, (we're getting to that, patience!) have it run from 0.0 to 1.0, and then use that as a multiplier to some other values. That way, the other values can be whatever we need them to be, and clock can be the same 0 to 1 value for every application. Let's look at a (relatively) simple example #include "colors.inc" camera { location <0, 3, -6> look_at <0, 0, 0> } light_source { <20, 20, -20> color White } plane { y, 0 pigment { checker color White color Black } } sphere { <0, 0, 0> , 1 pigment { gradient x color_map { [0.0 Blue ] [0.5 Blue ] [0.5 White ] [1.0 White ] } scale .25 } rotate <0, 0, -clock*360> translate <-pi, 1, 0> translate <2*pi*clock, 0, 0> } Assuming that a series of frames is run with the clock progressively going from 0.0 to 1.0, the above code will produce a striped ball which rolls from left to right across the screen. We have two goals here: 1. Translate the ball from point A to point B, and, 2. Rotate the ball in exactly the right proportion to its linear movement to imply that it is rolling -- not gliding -- to its final position. Taking the second goal first, we start with the sphere at the origin, because anywhere else and rotation will cause it to orbit the origin instead of rotating. Throughout the course of the animation, the ball will turn one complete 360 degree turn. Therefore, we used the formula, 360*clock to determine the rotation in each frame. Since clock runs 0 to 1, the rotation of the sphere runs from 0 degrees through 360. Then we used the first translation to put the sphere at its initial starting point. Remember, we couldn't have just declared it there, or it would have orbited the origin, so before we can meet our other goal (translation), we have to compensate by putting the sphere back where it would have been at the start. After that, we re-translate the sphere by a clock relative distance, causing it to move relative to the starting point. We've chosen the formula of 2*pi* r*clock (the widest circumference of the sphere times current clock value) so that it will appear to move a distance equal to the circumference of the sphere in the same time that it rotates a complete 360 degrees. In this way, we've synchronized the rotation of the sphere to its translation, making it appear to be smoothly rolling along the plane. Besides allowing us to coordinate multiple aspects of change over time more cleanly, mathematically speaking, the other good reason for using normalized clock values is that it will not matter whether we are doing a ten frame animated GIF, or a three hundred frame AVI. Values of the clock are proportioned to the number of frames, so that same POV code will work without regard to how long the frame sequence is. Our rolling ball will still travel the exact same amount no matter how many frames our animation ends up with. Clock Dependant Variables And Multi-Stage Animations Okay, what if we wanted the ball to roll left to right for the first half of the animation, then change direction 135 degrees and roll right to left, and toward the back of the scene. We would need to make use of POV-Ray's new conditional rendering directives, and test the clock value to determine when we reach the halfway point, then start rendering a different clock dependant sequence. But our goal, as above, it to be working in each stage with a variable in the range of 0 to 1 (normalized) because this makes the math so much cleaner to work with when we have to control multiple aspects during animation. So let's assume we keep the same camera, light, and plane, and let the clock run from 0 to 2! Now, replace the single sphere declaration with the following... #if ( clock <= 1 ) sphere { <0, 0, 0> , 1 pigment { gradient x color_map { [0.0 Blue ] [0.5 Blue ] [0.5 White ] [1.0 White ] } scale .25 } rotate <0, 0, -clock*360> translate <-pi, 1, 0> translate <2*pi*clock, 0, 0> } #else // (if clock is > 1, we're on the second phase) // we still want to work with a value from 0 - 1 #declare ElseClock = clock - 1; sphere { <0, 0, 0> , 1 pigment { gradient x color_map { [0.0 Blue ] [0.5 Blue ] [0.5 White ] [1.0 White ] } scale .25 } rotate <0, 0, ElseClock*360> translate <-2*pi*ElseClock, 0, 0> rotate <0, 45, 0> translate } #end If we spotted the fact that this will cause the ball to do an unrealistic snap turn when changing direction, bonus points for us - we're a born animator. However, for the simplicity of the example, let's ignore that for now. It will be easy enough to fix in the real world, once we examine how the existing code works. All we did differently was assume that the clock would run 0 to 2, and that we wanted to be working with a normalized value instead. So when the clock goes over 1.0, POV assumes the second phase of the journey has begun, and we declare a new variable Elseclock which we make relative to the original built in clock, in such a way that while clock is going 1 to 2, Elseclock is going 0 to 1. So, even though there is only one clock, there can be as many additional variables as we care to declare (and have memory for), so even in fairly complex scenes, the single clock variable can be made the common coordinating factor which orchestrates all other motions. The Phase Keyword There is another keyword we should know for purposes of animations: the phase XE "phase"  keyword. The phase keyword can be used on many texture elements, especially those that can take a color, pigment, normal or texture map. Remember the form that these maps take. For example: color_map { [0.00 White ] [0.25 Blue ] [0.76 Green ] [1.00 Red ] } The floating point value to the left inside each set of brackets helps POV-Ray to map the color values to various areas of the object being textured. Notice that the map runs cleanly from 0.0 to 1.0? Phase causes the color values to become shifted along the map by a floating point value which follows the keyword phase XE "phase" . Now, if we are using a normalized clock value already anyhow, we can make the variable clock the floating point value associated with phase, and the pattern will smoothly shift over the course of the animation. Let's look at a common example using a gradient normal pattern #include "colors.inc" #include "textures.inc" #background { rgb<0.8, 0.8, 0.8> } camera { location <1.5, 1, -30> look_at <0, 1, 0> angle 10 } light_source { <-100, 20, -100> color White } // flag polygon { 5, <0, 0>, <0, 1>, <1, 1>, <1, 0>, <0, 0> pigment { Blue } normal { gradient x phase clock scale <0.2, 1, 1> sine_wave } scale <3, 2, 1> translate <-1.5, 0, 0> } // flagpole cylinder { <-1.5, -4, 0>, <-1.5, 2.25, 0>, 0.05 texture { Silver_Metal } } // polecap sphere { <-1.5, 2.25, 0>, 0.1 texture { Silver_Metal } } Now, here we've created a simple blue flag with a gradient normal pattern on it. We've forced the gradient to use a sine-wave type wave so that it looks like the flag is rolling back and forth as though flapping in a breeze. But the real magic here is that phase keyword. It's been set to take the clock variable as a floating point value which, as the clock increments slowly toward 1.0, will cause the crests and troughs of the flag's wave to shift along the x-axis. Effectively, when we animate the frames created by this code, it will look like the flag is actually rippling in the wind. This is only one, simple example of how a clock dependant phase shift can create interesting animation effects. Trying phase will all sorts of texture patterns, and it is amazing the range of animation effects we can create simply by phase alone, without ever actually moving the object. Do Not Use Jitter Or Crand  XE "jitter"  XE "crand"  One last piece of basic information to save frustration. Because jitter is an element of anti-aliasing, we could just as easily have mentioned this under the INI file settings section, but there are also forms of anti-aliasing used in area lights, and the new atmospheric effects of POV-Ray, so now is as good a time as any. Jitter is a very small amount of random ray perturbation designed to diffuse tiny aliasing errors that might not otherwise totally disappear, even with intense anti-aliasing. By randomizing the placement of erroneous pixels, the error becomes less noticeable to the human eye, because the eye and mind are naturally inclined to look for regular patterns rather than random distortions. This concept, which works fantastically for still pictures, can become a nightmare in animations. Because it is random in nature, it will be different for each frame we render, and this becomes even more severe if we dither the final results down to, say 256 color animations (such as FLC's). The result is jumping pixels all over the scene, but especially concentrated any place where aliasing would normally be a problem (e.g., where an infinite plane disappears into the distance). For this reason, we should always set jitter to off in area lights and anti-aliasing options when preparing a scene for an animation. The (relatively) small extra measure quality due to the use of jitter will be offset by the ocean of jumpies that results. This general rule also applies to any truly random texture elements, such as crand. INI File Settings Okay, so we have a grasp of how to code our file for animation. We know about the clock variable, user declared clock-relative variables, and the phase keyword. We know not to jitter or crand when we render a scene, and we're all set build some animations. Alright, let's have at it. The first concept we'll need to know is the INI file settings, Initial_Frame XE "Initial_Frame"  and Final_Frame XE "Final_Frame" . These are very handy settings that will allow us to render a particular number of frames and each with its own unique frame number, in a completely hands free way. It is of course, so blindingly simple that it barely needs explanation, but here's an example anyway. We just add the following lines to our favorite INI file settings Initial_Frame = 1 Final_Frame = 20 and we'll initiate an automated loop that will generate 20 unique frames. The settings themselves will automatically append a frame number onto the end of whatever we have set the output file name for, thus giving each frame an unique file number without having to think about it. Secondly, by default, it will cycle the clock variable up from 0 to 1 in increments proportional to the number of frames. This is very convenient, since, no matter whether we are making a five frame animated GIF or a 300 frame MPEG sequence, we will have a clock value which smoothly cycles from exactly the same start to exactly the same finish. Next, about that clock. In our example with the rolling ball code, we saw that sometimes we want the clock to cycle through values other than the default of 0.0 to 1.0. Well, when that's the case, there are setting for that too. The format is also quite simple. To make the clock run, as in our example, from 0.0 to 2.0, we would just add to your INI file the lines Initial_Clock = 0.0 Final_Clock = 2.0 Now, suppose we were developing a sequence of 100 frames, and we detected a visual glitch somewhere in frames, say 51 to 75. We go back over our code and we think we've fixed it. We'd like to render just those 25 frames instead of redoing the whole sequence from the beginning. What do we change? If we said make Initial_Frame = 51, and Final_Frame = 75, we're wrong. Even though this would re-render files named with numbers 51 through 75, they will not properly fit into our sequence, because the clock will begin at its initial value starting with frame 51, and cycle to final value ending with frame 75. The only time Initial_Frame and Final_Frame should change is if we are doing an essentially new sequence that will be appended onto existing material.  XE "Subset_Start_Frame"  XE "Subset_End_Frame" If we wanted to look at just 51 through 75 of the original animation, we need two new INI settings Subset_Start_Frame = 51 Subset_End_Frame = 75 Added to settings from before, the clock will still cycle through its values proportioned from frames 1 to 100, but we will only be rendering that part of the sequence from the 51st to the 75th frames. This should give us a basic idea of how to use animation. Although, this introductory tutorial doesn't cover all the angles. For example, the last two settings we just saw, subset animation, can take fractional values, like 0.5 to 0.75, so that the number of actual frames will not change what portion of the animation is being rendered. There is also support for efficient odd-even field rendering as would be useful for animations prepared for display in interlaced playback such as television (see the reference section for full details). With POV-Ray 3 now fully supporting a complete host of animation options, a whole fourth dimension is added to the raytracing experience. Whether we are making a FLIC, AVI, MPEG, or simply an animated GIF for our web site, animation support takes a lot of the tedium out of the process. And don't forget that phase and clock can be used to explore the range of numerous texture elements, as well as some of the more difficult to master objects (hint: the julia fractal for example). So even if we are completely content with making still scenes, adding animation to our repertoire can greatly enhance our understanding of what POV-Ray is capable of. Adventure awaits! POV-Ray Options The reference section describes all command line switches and INI file keywords that are used to set the options of POV-Ray. It is supposed to be used as a reference for looking up things. It does not contain detailed explanations on how scenes are written or how POV-Ray is used. It just explains all features, their syntax, applications, limits, drawbacks, etc. POV-Ray was originally created as a command-line program for operating systems without graphical interfaces, dialog boxes and pull-down menus. Most versions of POV-Ray still use command-line switches to tell it what to do. This documentation assumes you are using the command-line version. If you are using Macintosh, MS-Windows or other GUI versions, there will be dialog boxes or menus which do the same thing. There is system-specific documentation for each system describing the specific commands. Setting POV-Ray Options There are two distinct ways of setting POV-Ray options: command line switches and INI file keywords. Both are explained in detail in the following sections. Command Line Switches Command line switches consist of a + (plus) or - (minus) sign, followed by one or more alphabetic characters and possibly a numeric value. Here is a typical command line with switches. POVRAY +Isimple.pov +V +W80 +H60 povray is the name of the program and it is followed by several switches. Each switch begins with a plus or minus sign. The +I XE "+I"  switch with the filename tells POV-Ray what scene file it should use as input and +V XE "+V"  tells the program to output its status to the text screen as it's working. The +W XE "+W"  and +H XE "+H"  switches set the width and height of the image in pixels. This image will be 80 pixels wide by 60 pixels high. In switches which toggle a feature, the plus turns it on and minus turns it off. For example +P XE "+P"  turns on the pause for keypress when finished option while -P XE "-P"  turns it off. Other switches are used to specify values and do not toggle a feature. Either plus or minus may be used in that instance. For example  XE "+W" +W320 sets the width to 320 pixels. You could also use  XE "-W" -W320 and get the same results. Switches may be specified in upper or lower case. They are read left to right but in general may be specified in any order. If you specify a switch more than once, the previous value is generally overwritten with the last specification. The only exception is the +L XE "+L"  switch for setting library paths. Up to ten unique paths may be specified. Almost all + or - switches have an equivalent option which can be used in an INI file which is described in the next section. A detailed description of each switch is given in the option reference section. Using INI Files Because it is difficult to set more than a few options on a command line, you have the ability to put multiple options in one or more text files. These initialization files XE "initialization files"  or INI files XE "INI files"  have .ini as their default extension. Previous versions of POV-Ray called them default files XE "default files"  or DEF files XE "DEF files" . You may still use existing DEF files with this version of POV-Ray. The majority of options you use will be stored in INI files. The command line switches are recommended for options which you will turn off or on frequently as you perform test renderings of a scene you are developing. The file povray.ini is automatically read if present. You may specify additional INI files on the command-line by simply typing the file name on the command line. For example: POVRAY MYOPTS.INI If no extension is given, then .ini is assumed. POV-Ray knows this is not a switch because it is not preceded by a plus or minus. In fact a common error among new users is that they forget to put the +I XE "+I"  switch before the input file name. Without the switch, POV-Ray thinks that the scene file simple.pov is an INI file. Don't forget! If no plus or minus precedes a command line switch, it is assumed to be an INI file name. You may have multiple INI files on the command line along with switches. For example: POVRAY MYOPTS +V OTHER This reads options from myopts.ini, then sets the +V XE "+V"  switch, then reads options from other.ini. An INI file is a plain ASCII text file with options of the form... Option_keyword=VALUE ; Text after semicolon is a comment For example the INI equivalent of the switch +Isimple.pov is... Input_File_Name=simple.pov Options are read top to bottom in the file but in general may be specified in any order. If you specify an option more than once, the previous values are generally overwritten with the last specification. The only exception is the Library_Path XE "Library_Path" =path options. Up to ten unique paths may be specified. Almost all INI-style options have equivalent + or - switches. The option reference section gives a detailed description of all POV-Ray options. It includes both the INI-style settings and the +/- switches. The INI keywords are not case sensitive. Only one INI option is permitted per line of text. You may also include switches in your INI file if they are easier for you. You may have multiple switches per line but you should not mix switches and INI options on the same line. You may nest INI files by simply putting the file name on a line by itself with no equals sign after it. Nesting may occur up to ten levels deep. For example: ; This is a sample INI file. This entire line is a comment. ; Blank lines are permitted. Input_File_Name=simple.pov ;This sets the input file name +W80 +H60 ; Traditional +/- switches are permitted too MOREOPT ; Read MOREOPT.INI and continue with next line +V ; Another switch ; That's all folks! INI files may have labeled sections so that more than one set of options may be stored in a single file. Each section begins with a label in [] brackets. For example: ; RES.INI ; This sample INI file is used to set resolution. +W120 +H100 ; This section has no label. ; Select it with "RES" [Low] +W80 +H60 ; This section has a label. ; Select it with "RES[Low]" [Med] +W320 +H200 ; This section has a label. ; Select it with "RES[Med]" [High] +W640 +H480 ; Labels are not case sensitive. ; "RES[high]" works [Really High] +W800 +H600 ; Labels may contain blanks When you specify the INI file you should follow it with the section label in brackets. For example... POVRAY RES[Med] +Imyfile.pov POV-Ray reads res.ini and skips all options until it finds the label Med. It processes options after that label until it finds another label and then it skips. If no label is specified on the command line then only the unlabeled area at the top of the file is read. If a label is specified, the unlabeled area is ignored. Because a blank space is considered a delimiter for command-line switches, POV-Ray has a difficult time reading file names or INI labels containing blanks. The rule is that INI-style options allow blanks in INI files but switches do not allow blanks whether in INI files or on the command line. For example: +Imy file.pov ;doesn't work anywhere Input_File=my file.pov ;works only in INI file To nest INI files which have blanks in the file name or labels use the Include_INI XE "Include_INI"  option like this: Input_File=my file.pov Include_Ini=my options[this section] Using the POVINI Environment Variable The environment variable POVINI is used to specify the location and name of a default INI file that is read every time POV-Ray is executed. If POVINI is not specified, or if your computer platform does not use environment variables, a default INI file may be read. If the specified file does not exist, a warning message is printed. To set the environment variable under MS-DOS you might put the following line in your autoexec.bat file... set POVINI=c:\povray3\default.ini On most operating systems the sequence of reading options is as follows: 1. Read options from default INI file specified by the POVINI environment variable or platform specific INI file. 2. Read switches from command line (this includes reading any specified INI/DEF files). The POVRAYOPT environment variable supported by previous POV-Ray versions is no longer available. Options Reference As explained in the previous section, options may be specified by switches or INI-style options. Almost all INI-style options have equivalent +/ - switches and most switches have equivalent INI-style option. The following sections give a detailed description of each POV-Ray option. It includes both the INI-style settings and the +/ - switches. The notation and terminology used is described in the tables below. Keyword=bool Turn Keyword on if bool equals true, yes, on or 1 and Turn it off if it is any other value.Keyword=trueDo this option if true, yes, on or 1 is specified.Keyword=falseDo this option if false, no, off or 0 is specified.Keyword=filenameSet Keyword to filename where filename is any valid file name. Note: some options prohibit the use of any of the above true or false values as a file name. They are noted in later sections.nAny integer such as in +W320n.nAny float such as in Clock=3.450.nAny float < 1.0 even if it has no leading 0sAny string of textx or yAny single characterpathAny directory name, drive optional, no final path separator ("\" or "/", depending on the operating system)Unless otherwise specifically noted, you may assume that either a plus or minus sign before a switch will produce the same results. Animation Options POV-Ray 3.0 greatly improved its animation capability with the addition of an internal animation loop, automatic output file name numbering and the ability to shell out to the operating system to external utilities which can assemble individual frames into an animation. The internal animation loop is simple yet flexible. You may still use external programs or batch files to create animations without the internal loop as you may have done in POV-Ray 2. External Animation Loop Clock=n.nSets clock float identifier to n.n+Kn.nSame as Clock=n.nThe Clock XE "Clock" =n.n option or the +K XE "+K" n.n switch may be used to pass a single float value to the program for basic animation. The value is stored in the float identifier clock XE "clock" . If an object had a rotate <0,clock,0> attached then you could rotate the object by different amounts over different frames by setting +K10.0,+K20.0... etc. on successive renderings. It is up to the user to repeatedly invoke POV-Ray with a different Clock value and a different Output_File_Name XE "Output_File_Name"  for each frame. Internal Animation Loop Initial_Frame=nSets initial frame number to nFinal_Frame=nSets final frame number to nInitial_Clock=n.nSets initial clock value to n.nFinal_Clock=n.nSets final clock value to n.n+KFInSame as Initial_Frame=n+KFFnSame as Final_Frame=n+KIn.nSame as Initial_Clock=n.n+KFn.nSame as Final_Clock=n.nThe internal animation loop new to POV-Ray 3.0 relieves the user of the task of generating complicated sets of batch files to invoke POV-Ray multiple times with different settings. While the multitude of options may look intimidating, the clever set of default values means that you will probably only need to specify the Final_Frame XE "Final_Frame" =n or the +KFF XE "+KFF" n option to specify the number of frames. All other values may remain at their defaults. Any Final_Frame setting other than -1 will trigger POV-Ray's internal animation loop. For example Final_Frame=10 or +KFF10 causes POV-Ray to render your scene 10 times. If you specified Output_File_Name=file.tga then each frame would be output as file01.tga, file02.tga, file03.tga etc. The number of zero-padded digits in the file name depends upon the final frame number. For example +KFF100 would generate file001.tga through file100.tga. The frame number may encroach upon the file name. On MS-DOS with an eight character limit, myscene.pov would render to mysce001.tga through mysce100.tga. The default Initial_Frame XE "Initial_Frame" =1 will probably never have to be changed. You would only change it if you were assembling a long animation sequence in pieces. One scene might run from frame 1 to 50 and the next from 51 to 100. The Initial_Frame=n or +KFI XE "+KFI" n option is for this purpose. Note that if you wish to render a subset of frames such as 30 through 40 out of a 1 to 100 animation, you should not change Frame_Initial or Frame_Final. Instead you should use the subset commands described in section " REF _Ref412119618 \h Subsets of Animation Frames". Unlike some animation packages, the action in POV-Ray animated scenes does not depend upon the integer frame numbers. Rather you should design your scenes based upon the float identifier clock XE "clock" . By default, the clock value is 0.0 for the initial frame and 1.0 for the final frame. All other frames are interpolated between these values. For example if your object is supposed to rotate one full turn over the course of the animation, you could specify rotate 360*clock*y. Then as clock runs from 0.0 to 1.0, the object rotates about the y-axis from 0 to 360 degrees. The major advantage of this system is that you can render a 10 frame animation or a 100 frame or 500 frame or 329 frame animation yet you still get one full 360 degree rotation. Test renders of a few frames work exactly like final renders of many frames. In effect you define the motion over a continuous float valued parameter (the clock) and you take discrete samples at some fixed intervals (the frames). If you take a movie or video tape of a real scene it works the same way. An object's actual motion depends only on time. It does not depend on the frame rate of your camera. Many users have already created scenes for POV-Ray 2 that expect clock values over a range other than the default 0.0 to 1.0. For this reason we provide the Initial_Clock XE "Initial_Clock" =n.n or +KI XE "+KI" n.n and Final_Clock XE "Final_Clock" =n.n or +KF XE "+KF" n.n options. For example to run the clock from 25.0 to 75.0 you would specify Initial_Clock=25.0 and Final_Clock=75.0. Then the clock would be set to 25.0 for the initial frame and 75.0 for the final frame. In-between frames would have clock values interpolated from 25.0 through 75.0 proportionally. Users who are accustomed to using frame numbers rather than clock values could specify Initial_Clock=1.0 and Final_Clock=10.0 and Frame_Final=10 for a 10 frame animation. For new scenes, we recommend you do not change the Initial_Clock or Final_Clock from their default 0.0 to 1.0 values. If you want the clock to vary over a different range than the default 0.0 to 1.0, we recommend you handle this inside your scene file as follows... #declare Start = 25.0; #declare End = 75.0; #declare My_Clock = Start+(End-Start)*clock; Then use My_Clock in the scene description. This keeps the critical values 25.0 and 75.0 in your .pov file. Note that more details concerning the inner workings of the animation loop are in the section on shell-out operating system commands in section " REF _Ref412212281 \h Shell-out to Operating System". Subsets of Animation Frames Subset_Start_Frame=nSet subset starting frame to nSubset_Start_Frame=0.nSet subset starting frame to n percentSubset_End_Frame=nSet subset ending frame to nSubset_End_Frame=0.nSet subset ending frame to n percent+SFn or +SF0.nSame as Subset_Start_Frame+EFn or +EF0.nSame as Subset_End_FrameWhen creating a long animation, it may be handy to render only a portion of the animation to see what it looks like. Suppose you have 100 frames but only want to render frames 30 through 40. If you set Initial_Frame XE "Initial_Frame" =30 and Final_Frame XE "Final_Frame" =40 then the clock would vary from 0.0 to 1.0 from frames 30 through 40 rather than 0.30 through 0.40 as it should. Therefore you should leave Initial_Frame=1 and Final_Frame=100 and use Subset_Start_Frame XE "Subset_Start_Frame" =30 and Subset_End_Frame XE "Subset_End_Frame" =40 to selectively render part of the scene. POV-Ray will then properly compute the clock values. Usually you will specify the subset using the actual integer frame numbers however an alternate form of the subset commands takes a float value in the range 0.0 <=n.nnn <=1.0 which is interpreted as a fraction of the whole animation. For example, Subset_Start_Frame=0.333 and Subset_End_Frame=0.667 would render the middle 1/3rd of a sequence regardless of the number of frames. Cyclic Animation Cyclic_Animation=bool Turn cyclic animation on/off+KC Turn cyclic animation on-KC Turn cyclic animation offMany computer animation sequences are designed to be run in a continuous loop. Suppose you have an object that rotates exactly 360 degrees over the course of your animation and you did rotate 360*clock*y to do so. Both the first and last frames would be identical. Upon playback there would be a brief one frame jerkiness. To eliminate this problem you need to adjust the clock so that the last frame does not match the first. For example a ten frame cyclic animation should not use clock 0.0 to 1.0. It should run from 0.0 to 0.9 in 0.1 increments. However if you change to 20 frames it should run from 0.0 to 0.95 in 0.05 increments. This complicates things because you would have to change the final clock value every time you changed Final_Frame XE "Final_Frame" . Setting Cyclic_Animation XE "Cyclic_Animation" =on or using +KC XE "+KC"  will cause POV-Ray to automatically adjust the final clock value for cyclic animation regardless of how many total frames. The default value for this setting is off. Field Rendering Field_Render=boolTurn field rendering on/offOdd_Field=boolSet odd field flag+UFTurn field rendering on-UFTurn field rendering off+UOSet odd field flag on-UOSet odd field flag offField rendering is sometimes used for animations when the animation is being output for television. TVs only display alternate scan lines on each vertical refresh. When each frame is being displayed the fields are interlaced to give the impression of a higher resolution image. The even scan lines make up the even field, and are drawn first (i.e. scan lines 0, 2, 4, etc.), followed by the odd field, made up of the odd numbered scan lines are drawn afterwards. If objects in an animation are moving quickly, their position can change noticeably from one field to the next. As a result, it may be desirable in these cases to have POV-Ray render alternate fields at the actual field rate (which is twice the frame rate), rather than rendering full frames at the normal frame rate. This would save a great deal of time compared to rendering the entire animation at twice the frame rate, and then only using half of each frame. By default, field rendering is not used. Setting Field_Render XE "Field_Render" =on or using +UF XE "+UF"  will cause alternate frames in an animation to be only the even or odd fields of an animation. By default, the first frame is the even field, followed by the odd field. You can have POV-Ray render the odd field first by specifying Odd_Field XE "Odd_Field" =on, or by using the +UO XE "+UO"  switch. Output Options General Output Options Height and Width of Output Height=nSets screen height to n pixelsWidth=nSets screen width to n pixels+HnSame as Height=n (when n > 8)+WnSame as Width=nThese switches set the height and width of the image in pixels. This specifies the image size for file output. The preview display, if on, will generally attempt to pick a video mode to accommodate this size but the display settings do not in any way affect the resulting file output. Partial Output Options Start_Column=nSet first column to n pixelsStart_Column=0.n Set first column to n percent of width+SCn or +SC0.nSame as Start_ColumnStart_Row=nSet first row to n pixelsStart_Row=0.nSet first row to n percent of height+SRn or +SnSame as Start_Row=n+SR0.n or +S0.nSame as Start_Row=0.nEnd_Column=nSet last column to n pixelsEnd_Column=0.nSet last column to n percent of width+ECn or +EC0.nSame as End_ColumnEnd_Row=nSet last row to n pixelsEnd_Row=0.nSet last row to n percent of height+ERn or +EnSame as End_Row=n+ER0.n or +E0.nSame as End_Row=0.nWhen doing test rendering it is often convenient to define a small, rectangular sub-section of the whole screen so you can quickly check out one area of the image. The Start_Row XE "Start_Row" , End_Row XE "End_Row" , Start_Column XE "Start_Column"  and End_Column XE "End_Column"  options allow you to define the subset area to be rendered. The default values are the full size of the image from (1,1) which is the upper left to (w,h) on the lower right where w and h are the Width XE "Width" =n and Height XE "Height" =n values you have set. Note if the number specified is greater than 1 then it is interpreted as an absolute row or column number in pixels. If it is a decimal value between 0.0 and 1.0 then it is interpreted as a percent of the total width or height of the image. For example: Start_Row=0.75 and Start_Column=0.75 starts on a row 75% down from the top at a column 75% from the left. Thus it renders only the lower-right 25% of the image regardless of the specified width and height. The +SR XE "+SR" , +ER XE "+ER" , +SC XE "+SC"  and +EC XE "+EC"  switches work in the same way as the corresponding INI-style settings for both absolute settings or percentages. Early versions of POV-Ray allowed only start and end rows to be specified with +S XE "+S" n and +E XE "+E" n so they are still supported in addition to +SR and +ER. Interrupting Options Test_Abort=boolTurn test for user abort on/off+XTurn test abort on-XTurn test abort offTest_Abort_Count=nSet to test for abort every n pixels+XnSet to test for abort every n pixels on-XnSet to test for abort off (in future test every n pixels)On some operating systems once you start a rendering you must let it finish. The Test_Abort XE "Test_Abort" =on option or +X XE "+X"  switch causes POV-Ray to test the keyboard for keypress. If you have pressed a key, it will generate a controlled user abort. Files will be flushed and closed but only data through the last full row of pixels is saved. POV-Ray exits with an error code 2 (normally POV-Ray returns 0 for a successful run or 1 for a fatal error). When this option is on, the keyboard is polled on every line while parsing the scene file and on every pixel while rendering. Because polling the keyboard can slow down a rendering, the Test_Abort_Count XE "Test_Abort_Count" =n option or +X XE "+X" n switch causes the test to be performed only every n pixels rendered or scene lines parsed. Resuming Options Continue_Trace=boolSets continued trace on/off+CSets continued trace on-CSets continued trace offCreate_Ini=fileGenerate an INI file to fileCreate_Ini=trueGenerate file.ini where file is scene name.Create_Ini=falseTurn off generation of previously set file.ini+GIfileSame as Create_Ini=fileIf you abort a render while it's in progress or if you used the End_Row XE "End_Row"  option to end the render prematurely, you can use Continue_Trace XE "Continue_Trace" =on or +C XE "+C"  option to continue the render later at the point where you left off. This option reads in the previously generated output file, displays the partial image rendered so far, then proceeds with the ray-tracing. This option cannot be used if file output is disabled with Output_to_file XE "Output_to_file" =off or -F XE "-F" . The Continue_Trace option may not work if the Start_Row XE "Start_Row"  option has been set to anything but the top of the file, depending on the output format being used. POV-Ray tries to figure out where to resume an interrupted trace by reading any previously generated data in the specified output file. All file formats contain the image size, so this will override any image size settings specified. Some file formats (namely TGA and PNG) also store information about where the file started (i. e. +SC XE "+SC" n and +SR XE "+SR" n options), alpha output +UA XE "+UA" , and bit-depth +FN XE "+FN" n, which will override these settings. It is up to the user to make sure that all other options are set the same as the original render. The Create_Ini XE "Create_Ini"  option or +GI XE "+GI"  switch provides an easy way to create an INI file with all of the rendering options, so you can re-run files with the same options, or ensure you have all the same options when resuming. This option creates an INI file with every option set at the value used for that rendering. This includes default values which you have not specified. For example if you run POV-Ray with... POVRAY +Isimple.pov MYOPTS +GIrerun.ini MOREOPTS POV-Ray will create a file called rerun.ini with all of the options used to generate this scene. The file is not written until all options have been processed. This means that in the above example, the file will include options from both myopts.ini and moreopts.ini despite the fact that the +GI switch is specified between them. You may now re-run the scene with... POVRAY RERUN or resume an interrupted trace with POVRAY RERUN +C If you add other switches with the rerun.ini reference, they will be included in future re-runs because the file is re-written every time you use it. The Create_Ini option is also useful for documenting how a scene was rendered. If you render waycool.pov with Create_Ini=on then it will create a file waycool.ini that you could distribute along with your scene file so other users can exactly re-create your image. Display Output Options Display Hardware Settings Display=boolTurns graphic display on/off+DTurns graphic display on-DTurns graphic display offVideo_Mode=xSet video mode to x; does not affect on/off+DxSet display on; Set mode to x-DxSet display off; but for future use mode xPalette=ySet display palette to y; does not affect on/off+Dxy Set display on; Set mode x; Set palette y-DxySet display off; use mode x, palette y in futureDisplay_Gamma=n.nSets the display gamma to n.nThe Display XE "Display" =on or +D XE "+D"  switch will turn on the graphics display of the image while it is being rendered. Even on some non-graphics systems, POV-Ray may display an 80 by 24 character "ASCII-Art" version of your image. Where available, the display may be full, 24-bit true color. Setting Display=off or using the -D XE "-D"  switch will turn off the graphics display which is the default. The Video_Mode XE "Video_Mode" =x option sets the display mode or hardware type chosen where x is a single digit or letter that is machine dependent. Generally Video_Mode=0 means the default or an auto-detected setting should be used. When using switches, this character immediately follows the switch. For example the +D0 switch will turn on the graphics display in the default mode. The Palette XE "Palette" =y option selects the palette to be used. Typically the single character parameter y is a digit which selects one of several fixed palettes or a letter such G for gray scale, H for 15-bit or 16-bit high color or T for 24-bit true color. When using switches, this character is the 2nd character after the switch. For example the +D0T switch will turn on the graphics display in the default mode with a true color palette. The Display_Gamma XE "Display_Gamma" =n.n setting is new with POV-Ray 3.0, and is not available as a command-line switch. The Display_Gamma setting overcomes the problem of images (whether ray-traced or not) having different brightness when being displayed on different monitors, different video cards, and under different operating systems. Note that the Display_Gamma is a setting based on your computer's display hardware, and should be set correctly once and not changed. The Display_Gamma INI setting works in conjunction with the new assumed_gamma XE "assumed_gamma"  global setting to ensure that POV scenes and the images they create look the same on all systems. See section " REF _Ref412453576 \h Assumed_Gamma" which describes the assumed_gamma global setting and describes gamma more thoroughly. While the Display_Gamma can be different for each system, there are a few general rules that can be used for setting Display_Gamma if you don't know it exactly. If the Display_Gamma keyword does not appear in the INI file, POV-Ray assumes that the display gamma is 2.2. This is because most PC monitors have a gamma value in the range 1.6 to 2.6 (newer models seem to have a lower gamma value). Mac has the ability to do gamma correction inside the system software (based on a user setting in the gamma control panel). If the gamma control panel is turned off, or is not available, the default Macintosh system gamma is 1.8. Some high-end PC graphics cards can do hardware gamma correction and should use the current Display_Gamma setting, usually 1.0. A gamma test image is also available to help users to set their Display_Gamma accurately. For scene files that do not contain an assumed_gamma global setting the INI file option Display_Gamma will not have any affect on the preview output of POV-Ray or for most output file formats. However, the Display_Gamma value is used when creating PNG format output files, and also when rendering the POV-Ray example files (because they have an assumed_gamma), so it should still be correctly set for your system to ensure proper results. Display Related Settings Pause_When_Done=boolSets pause when done on/off+PSets pause when done on-PSets pause when done offVerbose=boolSet verbose messages on/off+VSet verbose messages on-VSet verbose messages offDraw_Vistas=boolTurn draw vistas on/off+UDTurn draw vistas on-UDTurn draw vistas offOn some systems, when the image is complete, the graphics display is cleared and POV-Ray switches back into text mode to print the final statistics and to exit. Normally when the graphics display is on, you want to look at the image awhile before continuing. Using Pause_When_Done XE "Pause_When_Done" =on or +P XE "+P"  causes POV-Ray to pause in graphics mode until you press a key to continue. The default is not to pause (-P XE "-P" ). When the graphics display is not used, it is often desirable to monitor progress of the rendering. Using Verbose XE "Verbose" =on or +V XE "+V"  turns on verbose reporting of your rendering progress. This reports the number of the line currently being rendered, the elapsed time for the current frame and other information. On some systems, this textual information can conflict with the graphics display. You may need to turn this off when the display is on. The default setting is off (-V XE "-V" ). The option Draw_Vistas XE "Draw_Vistas" =on or +UD XE "+UD"  was originally a debugging help for POV-Ray's vista buffer feature but it was such fun we decided to keep it. Vista buffering is a spatial sub-division method that projects the 2-D extents of bounding boxes onto the viewing window. POV-Ray tests the 2-D x, y pixel location against these rectangular areas to determine quickly which objects, if any, the viewing ray will hit. This option shows you the 2-D rectangles used. The default setting is off (-UD XE "-UD" ) because the drawing of the rectangles can take considerable time on complex scenes and it serves no critical purpose. See section " REF _Ref412454596 \h Automatic Bounding Control" for more details. Mosaic Preview Preview_Start_Size=nSet mosaic preview start size to n+SPnSame as Preview_Start_Size=nPreview_End_Size=nSet mosaic preview end size to n+EPnSame as Preview_End_Size=nTypically, while you are developing a scene, you will do many low resolution test renders to see if objects are placed properly. Often this low resolution version doesn't give you sufficient detail and you have to render the scene again at a higher resolution. A feature called "mosaic preview" solves this problem by automatically rendering your image in several passes. The early passes paint a rough overview of the entire image using large blocks of pixels that look like mosaic tiles. The image is then refined using higher resolutions on subsequent passes. This display method very quickly displays the entire image at a low resolution, letting you look for any major problems with the scene. As it refines the image, you can concentrate on more details, like shadows and textures. You don't have to wait for a full resolution render to find problems, since you can interrupt the rendering early and fix the scene, or if things look good, you can let it continue and render the scene at high quality and resolution. To use this feature you should first select a Width XE "Width"  and Height XE "Height"  value that is the highest resolution you will need. Mosaic preview is enabled by specifying how big the mosaic blocks will be on the first pass using Preview_Start_Size XE "Preview_Start_Size" =n or +SP XE "+SP" n. The value n should be a number greater than zero that is a power of two (1, 2, 4, 8, 16, 32, etc.) If it is not a power of two, the nearest power of two less than n is substituted. This sets the size of the squares, measured in pixels. A value of 16 will draw every 16th pixel as a 16*16 pixel square on the first pass. Subsequent passes will use half the previous value (such as 8*8, 4*4 and so on.) The process continues until it reaches 1*1 pixels or until it reaches the size you set with Preview_End_Size XE "Preview_End_Size" =n or +EP XE "+EP" n. Again the value n should be a number greater than zero that is a power of two and less than or equal to Preview_Start_Size. If it is not a power of two, the nearest power of two less than n is substituted. The default ending value is 1. If you set Preview_End_Size to a value greater than 1 the mosaic passes will end before reaching 1*1, but POV-Ray will always finish with a 1*1. For example, if you want a single 8*8 mosaic pass before rendering the final image, set Preview_Start_Size=8 and Preview_End_Size=8. No file output is performed until the final 1*1 pass is reached. Although the preliminary passes render only as many pixels as needed, the 1*1 pass re-renders every pixel so that anti-aliasing and file output streams work properly. This makes the scene take up to 25% longer than the regular 1*1 pass to render, so it is suggested that mosaic preview not be used for final rendering. Also, the lack of file output until the final pass means that renderings which are interrupted before the 1*1 pass can not be resumed without starting over from the beginning. Future versions of POV-Ray will include some system of temporary files or buffers which will eliminate these inefficiencies and limitations. Mosaic preview is still a very useful feature for test renderings. File Output Options Output_to_File=boolSets file output on/off+FSets file output on (use default type)-FSets file output offBy default, POV-Ray writes an image file to disk. When you are developing a scene and doing test renders, the graphic preview may be sufficient. To save time and disk activity you may turn file output off with Output_to_File XE "Output_to_File" =off or -F XE "-F" . Output File Type Output_File_Type=xSets file output format to x+FxnSets file output on; sets format x, depth n-FxnSets file output off; but in future use format x, depth nOutput_Alpha=boolSets alpha output on/off+UASets alpha output on-UASets alpha output offBits_Per_Color=nSets file output bits/color to nThe default type of image file depends on which platform you are using. MS-DOS and most others default to 24-bit uncompressed Targa. See your platform-specific documentation to see what your default file type is. You may select one of several different file types using Output_File_Type XE "Output_File_Type" =x or +F XE "+F" x where x is one of the following... +FCCompressed Targa-24 format (RLE, run length encoded)+FNNew PNG (portable network graphics) format+FPUnix PPM format+FSSystem-specific such as Mac Pict or Windows BMP+FTUncompressed Targa-24 formatNote that the obsolete +FD XE "+FD"  dump format and +FR XE "+FR"  raw format have been dropped from POV-Ray 3.0 because they were rarely used and no longer necessary. PPM, PNG, and system specific formats have been added. PPM format images are uncompressed, and have a simple text header, which makes it a widely portable image format. PNG is a new image format designed not only to replace GIF, but to improve on its shortcomings. PNG offers the highest compression available without loss for high quality applications, such as ray-tracing. The system specific format depends on the platform used and is covered in the appropriate system specific documentation. Most of these formats output 24 bits per pixel with 8 bits for each of red, green and blue data. PNG allows you to optionally specify the output bit depth from 5 to 16 bits for each of the red, green, and blue colors, giving from 15 to 48 bits of color information per pixel. The default output depth for all formats is 8 bits/color (16 million possible colors), but this may be changed for PNG format files by setting Bits_Per_Color XE "Bits_Per_Color" =n or by specifying +FN XE "+FN" n, where n is the desired bit depth. Specifying a smaller color depth like 5 bits/color (32768 colors) may be enough for people with 8- or 16-bit (256 or 65536 color) displays, and will improve compression of the PNG file. Higher bit depths like 10 or 12 may be useful for video or publishing applications, and 16 bits/color is good for grayscale height field output (See section " REF _Ref414188528 \h Height Field" for details on height fields). Targa format also allows 8 bits of alpha transparency data to be output, while PNG format allows 5 to 16 bits of alpha transparency data, depending on the color bit depth as specified above. You may turn this option on with Output_Alpha XE "Output_Alpha" =on or +UA XE "+UA" . The default is off or -UA XE "-UA" . See section " REF _Ref412464620 \h Using the Alpha Channel" for further details on transparency. In addition to support for variable bit-depths, alpha channel, and grayscale formats, PNG files also store the Display_Gamma XE "Display_Gamma"  value so the image displays properly on all systems (see section " REF _Ref412464789 \h Display Hardware Settings"). The hf_gray_16 XE "hf_gray_16"  global setting, as described in section " REF _Ref412464870 \h HF_Gray_16" will also affect the type of data written to the output file. Output File Name Output_File_Name=fileSets output file to file+OfileSame as Output_File_Name=fileThe default output filename is created from the scene name and need not be specified. The scene name is the input name with all drive, path, and extension information stripped. For example if the input file name is c:\povray3\mystuff\myfile.pov the scene name is myfile. The proper extension is appended to the scene name based on the file type. For example myfile.tga or myfile.png might be used. You may override the default output name using Output_File_Name XE "Output_File_Name" =file or +O XE "+O" file. For example: Input_File_Name=myinput.pov Output_File_Name=myoutput.tga If an output file name of "-" is specified (a single minus sign), then the image will be written to standard output, usually the screen. The output can then be piped into another program or to a GUI if desired. If the file specified is actually a path or directory or folder name and not a file name, then the default output name is used but it is written to the specified directory. For example: Input_File_Name=myscene.pov Output_File_Name=c:\povray3\myimages\ This will create c:\povray3\myimages\myscene.tga as the output file. Output File Buffer Buffer_Output=boolTurn output buffering on/off+BTurn output buffering on-BTurn output buffering offBuffer_Size=nSet output buffer size to n kilobytes. If n is zero, no buffering. If n < system default, the system default is used.+BnTurn buffer on, set size n-BnTurn buffer off, but for future set size nThe Buffer_Output XE "Buffer_Output"  and Buffer_Size XE "Buffer_Size"  options and the +B XE "+B"  switch allows you to assign large buffers to the output file. This reduces the amount of time spent writing to the disk. If this parameter is not specified, then as each row of pixels is finished, the line is written to the file and the file is flushed. On most systems, this operation ensures that the file is written to the disk so that in the event of a system crash or other catastrophic event, at least a part of the picture has been stored properly and retrievable on disk. The default is not to use any buffer. CPU Utilization Histogram The CPU utilization histogram is a way of finding out where POV-Ray is spending its rendering time, as well as an interesting way of generating heightfields. The histogram splits up the screen into a rectangular grid of blocks. As POV-Ray renders the image, it calculates the amount of time it spends rendering each pixel and then adds this time to the total rendering time for each grid block. When the rendering is complete, the histogram is a file which represents how much time was spent computing the pixels in each grid block. Not all versions of POV-Ray allow the creation of histograms. The histogram output is dependent on the file type and the system that POV-Ray is being run on. File Type Histogram_Type=ySet histogram type to y (Turn off if type is 'X')+HTySame as Histogram_Type=y XE "Histogram_Type"  XE "+HT" The histogram output file type is nearly the same as that used for the image output file types in " REF _Ref412528893 \h Output File Type". The available histogram file types are as follows. +HTCComma separated values (CSV) often used in spreadsheets+HTNNew PNG (portable network graphics) format grayscale+HTPUnix PPM format+HTSSystem-specific such as Mac Pict or Windows BMP+HTTUncompressed Targa-24 format (TGA)+HTXNo histogram file output is generatedNote that +HTC XE "+HTC"  does not generate a compressed Targa-24 format output file but rather a text file with a comma-separated list of the time spent in each grid block, in left-to-right and top-to bottom order. The units of time output to the CSV file are system dependent. See the system specific documentation for further details on the time units in CSV files. The Targa and PPM format files are in the POV heightfield format (see " REF _Ref414188528 \h Height Field"), so the histogram information is stored in both the red and green parts of the image, which makes it unsuitable for viewing. When used as a height field, lower values indicate less time spent calculating the pixels in that block, while higher indicate more time spent in that block. PNG format images are stored as grayscale images and are useful for both viewing the histogram data as well as for use as a heightfield. In PNG files, the darker (lower) areas indicate less time spent in that grid block, while the brighter (higher) areas indicate more time spent in that grid block. File Name Histogram_Name=fileSet histogram name to file+HNfileSame as Histogram_Name=file XE "Histogram_Name=file"  XE "+HN" The histogram file name is the name of the file in which to write the histogram data. If the file name is not specified it will default to histgram.ext, where ext is based on the file type specified previously. Note that if the histogram name is specified the file name extension should match the file type. Grid Size Histogram_Grid_Size=nn.mmSet histogram grid to nn by mm+HSnn.mmSame as Histogram_Grid_Size=nn.mmThe histogram grid size gives the number of times the image is split up in both the horizontal and vertical directions. For example povray +Isample +W640 +H480 +HTN +HS160.120 +HNhistogrm.png will split the image into 160*120 grid blocks, each of size 4*4 pixels, and output a PNG file, suitable for viewing or for use as a heightfield. Smaller numbers for the grid size mean more pixels are put into the same grid block. With CSV output, the number of values output is the same as the number of grid blocks specified. For the other formats the image size is identical to the rendered image rather than the specified grid size, to allow easy comparison between the histogram and the rendered image. If the histogram grid size is not specified, it will default to the same size as the image, so there will be one grid block per pixel. Note that on systems that do task-switching or multi-tasking the histogram may not exactly represent the amount of time POV-Ray spent in a given grid block since the histogram is based on real time rather than CPU time. As a result, time may be spent for operating system overhead or on other tasks running at the same time. This will cause the histogram to have speckling, noise or large spikes. This can be reduced by decreasing the grid size so that more pixels are averaged into a given grid block. Scene Parsing Options POV-Ray reads in your scene file and processes it to create an internal model of your scene. The process is called parsing. As your file is parsed other files may be read along the way. This section covers options concerning what to parse, where to find it and what version specific assumptions it should make while parsing it. Input File Name Input_File_Name=fileSets input file name to file+IfileSame as Input_File_Name=file XE "Input_File_Name"  XE "+I" You will probably always set this option but if you do not the default input filename is object.pov. If you do not have an extension then .pov is assumed. On case-sensitive operating systems both .pov and .POV are tried. A full path specification may be used (on MS-DOS systems +Ic:\povray3\mystuff\myfile.pov is allowed for example). In addition to specifying the input file name this also establishes the scene name. The scene name is the input name with drive, path and extension stripped. In the above example the scene name is myfile. This name is used to create a default output file name and it is referenced other places. If you use "-" as the input file name the input will be read from standard input. Thus you can pipe a scene created by a program to POV-Ray and render it without having a scene file. Under MS-DOS you can try this feature by typing. type ANYSCENE.POV | povray +I- Library Paths Library_Path=pathAdd path to list of library paths+LpathSame as Library_Path=pathPOV-Ray looks for files in the current directory. If it does not find a file it needs it looks in various other library directories which you specify. POV-Ray does not search your operating system path. It only searches the current directory and directories which you specify with this option. For example the standard include files are usually kept in one special directory. You tell POV-Ray to look there with... Library_Path=c:\povray3\include You must not specify any final path separators ("\" or "/") at the end. Multiple uses of this option switch do not override previous settings. Up to twenty unique paths may be specified. If you specify the exact same path twice it is only counts once. The current directory will be searched first followed by the indicated library directories in the order in which you specified them. Language Version Version=n.nSet initial language compatibility to version n.n+MVn.nSame as Version=n.nAs POV-Ray as evolved from version 1.0 through 3.1 we have made every effort to maintain some amount of backwards compatibility with earlier versions. Some old or obsolete features can be handled directly without any special consideration by the user. Some old or obsolete features can no longer be handled at all. However some old features can still be used if you warn POV-Ray that this is an older scene. In the POV-Ray scene language you can use the #version XE "#version"  directive to switch version compatibility to different setting. See section " REF _Ref412535627 \h The #version Directive" for more details about the language version directive. Additionally you may use the Version XE "Version" =n.n option or the +MV XE "+MV" n.n switch to establish the initial setting. For example one feature introduced in 2.0 that was incompatible with any 1.0 scene files is the parsing of float expressions. Setting Version=1.0 or using +MV1.0 turns off expression parsing as well as many warning messages so that nearly all 1.0 files will still work. Naturally the default setting for this option is Version=3.1. NOTE: Some obsolete or re-designed features are totally unavailable in POV-Ray 3.1 REGARDLES OF THE VERSION SETTING. Details on these features are noted throughout this documentation. Shell-out to Operating System Pre_Scene_Command=sSet command before entire scenePre_Frame_Command=sSet command before each framePost_Scene_Command=sSet command after entire scenePost_Frame_Command=sSet command after each frameUser_Abort_Command=sSet command when user aborts POV-RayFatal_Error_Command=sSet command when POV-Ray has fatal error XE "Fatal_Error_Command"  XE "User_Abort_Command"  XE "Post_Frame_Command"  XE "Post_Scene_Command"  XE "Pre_Frame_Command"  XE "Pre_Scene_Command" Note that no + or - switches are available for these options. They cannot be used from the command line. They may only be used from INI files. POV-Ray offers you the opportunity to shell-out to the operating system at several key points to execute another program or batch file. Usually this is used to manage files created by the internal animation loop however the shell commands are available for any scene. The string s is a single line of text which is passed to the operating system to execute a program. For example Post_Scene_Command=tga2gif -d -m myfile would use the utility tga2gif with the -D and -M parameters to convert myfile.tga to myfile.gif after the scene had finished rendering. String Substitution in Shell Commands It could get cumbersome to change the Post_Scene_Command every time you changed scene names. POV-Ray can substitute various values into a command string for you. For example: Post_Scene_Command=tga2gif -d -m %s POV-Ray will substitute the %s XE "%s"  with the scene name in the command. The scene name is the Input_File_Name XE "Input_File_Name"  or +I XE "+I"  setting with any drive, directory and extension removed. For example: Input_File_Name=c:\povray3\scenes\waycool.pov is stripped down to the scene name waycool which results in... Post_Scene_Command=tga2gif -d -m waycool In an animation it may be necessary to have the exact output file name with the frame number included. The string %o XE "%o"  will substitute the output file name. Suppose you want to save your output files in a zip archive using the utility program pkzip. You could do... Post_Frame_Command=pkzip -m %s %o After rendering frame 12 of myscene.pov POV-Ray would shell to the operating system with pkzip -m myscene mysce012.tga The -M switch in pkzip moves mysce012.tga to myscene.zip and removes it from the directory. Note that %o includes frame numbers only when in an animation loop. During the Pre_Scene_Command XE "Pre_Scene_Command"  and Post_Scene_Command XE "Post_Scene_Command"  there is no frame number so the original, unnumbered Output_File_Name is used. Any User_Abort_Command XE "User_Abort_Command"  or Fatal_Error_Command XE "Fatal_Error_Command"  not inside the loop will similarly give an unnumbered %o substitution. Here is the complete list of substitutions available for a command string. %oOutput file name with extension and embedded frame number if any%sScene name derived by stripping path and ext from input name%nFrame number of this frame%kClock value of this frame%hHeight of image in pixels%wWidth of image in pixels%%A single % sign.Shell Command Sequencing Here is the sequence of events in an animation loop. Non-animated scenes work the exact same way except there is no loop. 1) Process all INI file keywords and command line switches just once. 2) Open any text output streams and do Create_INI XE "Create_INI"  if any. 3) Execute Pre_Scene_Command XE "Pre_Scene_Command"  if any. 4) Loop through frames (or just do once on non-animation). a) Execute Pre_Frame_Command XE "Pre_Frame_Command"  if any. b) Parse entire scene file, open output file and read settings, turn on display, render the frame, destroy all objects, textures etc., close output file, close display. c) Execute Post_Frame_Command XE "Post_Frame_Command"  if any. d) Go back to (4a) until all frames are done. 5) Execute Post_Scene_Command XE "Post_Scene_Command"  if any. 6) Exit POV-Ray. If the user interrupts processing the User_Abort_Command XE "User_Abort_Command" , if any, is executed. User aborts can only occur during the parsing and rendering parts of step (4b) above. If a fatal error occurs that POV-Ray notices the Fatal_Error_Command XE "Fatal_Error_Command" , if any, is executed. Sometimes an unforeseen bug or memory error could cause a total crash of the program in which case there is no chance to shell out. Fatal errors can occur just about anywhere including during the processing of switches or INI files. If a fatal error occurs before POV-Ray has read the Fatal_Error_Command string then obviously no shell can occur. Note that the entire scene is re-parsed for every frame. Future versions of POV-Ray may allow you to hold over parts of a scene from one frame to the next but for now it starts from scratch every time. Note also that the Pre_Frame_Command occurs before the scene is parsed. You might use this to call some custom scene generation utility before each frame. This utility could rewrite your .pov or .inc files if needed. Perhaps you will want to generate new .gif or .tga files for image maps or height fields on each frame. Shell Command Return Actions Pre_Scene_Return=sSet pre scene return actionsPre_Frame_Return=sSet pre frame return actionsPost_Scene_Return=sSet post scene return actionsPost_Frame_Return=sSet post frame return actionsUser_Abort_Return=sSet user abort return actionsFatal_Error_Return=sSet fatal return actions XE "Pre_Scene_Return"  XE "Pre_Frame_Return"  XE "Post_Scene_Return"  XE "Post_Frame_Return"  XE "User_Abort_Return"  XE "Fatal_Error_Return" Note that no + or - switches are available for these options. They cannot be used from the command line. They may only be used from INI files. Most operating systems allow application programs to return an error code if something goes wrong. When POV-Ray executes a shell command it can make use of this error code returned from the shell process and take some appropriate action if the code is zero or non-zero. POV-Ray itself returns such codes. It returns 0 for success, 1 for fatal error and 2 for user abort. The actions are designated by a single letter in the different ..._Return=s options. The possible actions are: Iignore the codeSskip one stepAall steps skippedQquit POV-Ray immediatelyUgenerate a user abort in POV-RayFgenerate a fatal error in POV-RayFor example if your Pre_Frame_Command XE "Pre_Frame_Command"  calls a program which generates your height field data and that utility fails then it will return a non-zero code. We would probably want POV-Ray to abort as well. The option Pre_Frame_Return=F will cause POV-Ray to do a fatal abort if the Pre_Frame_Command returns a non-zero code. Sometimes a non-zero code from the external process is a good thing. Suppose you want to test if a frame has already been rendered. You could use the S action to skip this frame if the file is already rendered. Most utilities report an error if the file is not found. For example the command... pkzip -V myscene mysce012.tga tells pkzip you want to view the catalog of myscene.zip for the file mysce012.tga. If the file isn't in the archive pkzip returns a non-zero code. However we want to skip if the file is found. Therefore we need to reverse the action so it skips on zero and doesn't skip on non-zero. To reverse the zero vs. non-zero triggering of an action precede it with a "-" sign (note a "!" will also work since it is used in many programming languages as a negate operator). Pre_Frame_Return=S will skip if the code shows error (non-zero) and will proceed normally on no error (zero). Pre_Frame_Return=-S will skip if there is no error (zero) and will proceed normally if there is an error (non-zero). The default for all shells is I which means that the return action is ignored no matter what. POV-Ray simply proceeds with whatever it was doing before the shell command. The other actions depend upon the context. You may want to refer back to the animation loop sequence chart in the previous section " REF _Ref412623075 \h Shell Command Sequencing". The action for each shell is as follows. On return from any User_Abort_Command XE "User_Abort_Command"  if there is an action triggered... and you have specified... ... then POV-Ray will..FThen turn this user abort into a fatal error. Do the Fatal_Error_Command, if any. Exit POV-Ray with error code 1.S, A, Q, or UThen proceed with the user abort. Exit POV-Ray with error code 2.On return from any Fatal_Error_Command XE "Fatal_Error_Command"  then POV-Ray will proceed with the fatal error no matter what. It will exit POV-Ray with error code 1. On return from any Pre_Scene_Command XE "Pre_Scene_Command" , Pre_Frame_Command XE "Pre_Frame_Command" , Post_Frame_Command XE "Post_Frame_Command"  or Post_Scene_Commands XE "Post_Scene_Commands"  if there is an action triggered... ...and you have specified... ... then POV-Ray will...F...turn this user abort into a fatal error. Do the Fatal_Error_Command, if any. Exit POV-Ray with error code 1.U...generate a user abort. Do the User_Abort_Command, if any. Exit POV-Ray with an error code 2.Q..quit POV-Ray immediately. Acts as though POV-Ray never really ran. Do no further shells, (not even a Post_Scene_Command) and exit POV-Ray with an error code 0.On return from a Pre_Scene_Command XE "Pre_Scene_Command"  if there is an action triggered... ...and you have specified... ... then POV-Ray will...S...skip rendering all frames. Acts as though the scene completed all frames normally. Do not do any Pre_Frame_Command or Post_Frame_Commands. Do the Post_Scene_Command, if any. Exit POV-Ray with error code 0. On the earlier chart this means skip step #4.A...skip all scene activity. Works exactly like Q quit. On the earlier chart this means skip to step #6. Acts as though POV-Ray never really ran. Do no further shells, (not even a Post_Scene_Command) and exit POV-Ray with an error code 0.On return from a Pre_Frame_Command XE "Pre_Frame_Command"  if there is an action triggered... ...and you have specified... ... then POV-Ray will...S...skip only this frame. Acts as though this frame never existed. Do not do the Post_Frame_Command. Proceed with the next frame. On the earlier chart this means skip steps (4b) and (4c) but loop back as needed in (4d).A...skip rendering this frame and all remaining frames. Acts as though the scene completed all frames normally. Do not do any further Post_Frame_Commands. Do the Post_Scene_Command, if any. Exit POV-Ray with error code 0. On the earlier chart this means skip the rest of step (4) and proceed at step (5).On return from a Post_Frame_Command if there is an action triggered... ...and you have specified... ... then POV-Ray will...S or A...skip all remaining frames. Acts as though the scene completed all frames normally. Do not do any further Post_Frame_Commands. Do the Post_Scene_Command, if any. Exit POV-Ray with error code 0. On the earlier chart this means skip the rest of step (4) and proceed at step (5).On return from any Post_Scene_Command XE "Post_Scene_Command"  if there is an action triggered and you have specified S or A then no special action occurs. This is the same as I for this shell command. Text Output Text output is an important way that POV-Ray keeps you informed about what it is going to do, what it is doing and what it did. New to POV-Ray 3.0, the program splits its text messages into 7 separate streams. Some versions of POV-Ray color-codes the various types of text. Some versions allow you to scroll back several pages of messages. All versions allow you to turn some of these text streams off/on or to direct a copy of the text output to one or several files. This section details the options which give you control over text output. Text Streams There are seven distinct text streams that POV-Ray uses for output. On some versions each stream is designated by a particular color. Text from these streams are displayed whenever it is appropriate so there is often an intermixing of the text. The distinction is only important if you choose to turn some of the streams off or to direct some of the streams to text files. On some systems you may be able to review the streams separately in their own scroll-back buffer. Here is a description of each stream. Banner: XE "banner stream"  This stream displays the program's sign-on banner, copyright, contributor's list, and some help screens. It cannot be turned off or directed to a file because most of this text is displayed before any options or switches are read. Therefore you cannot use an option or switch to control it. There are switches which display the help screens. They are covered in section " REF _Ref413229845 \h Help Screen Switches". Debug: XE "debug stream"  This stream displays debugging messages. It was primarily designed for developers but this and other streams may also be used by the user to display messages from within their scene files. See section " REF _Ref412625191 \h Text Message Streams" for details on this feature. This stream may be turned off and/or directed to a text file. Fatal:  XE "fatal stream" This stream displays fatal error messages. After displaying this text, POV-Ray will terminate. When the error is a scene parsing error, you may be shown several lines of scene text that leads up to the error. This stream may be turned off and/or directed to a text file. Render:  XE "render stream" This stream displays information about what options you have specified to render the scene. It includes feedback on all of the major options such as scene name, resolution, animation settings, anti-aliasing and others. This stream may be turned off and/or directed to a text file. Statistics:  XE "statistics stream" This stream displays statistics after a frame is rendered. It includes information about the number of rays traced, the length of time of the processing and other information. This stream may be turned off and/or directed to a text file. Status:  XE "status stream" This stream displays one-line status messages that explain what POV-Ray is doing at the moment. On some systems this stream is displayed on a status line at the bottom of the screen. This stream cannot be directed to a file because there is generally no need to. The text displayed by the Verbose XE "Verbose"  option or +V XE "+V"  switch is output to this stream so that part of the status stream may be turned off. Warning:  XE "warning stream" This stream displays warning messages during the parsing of scene files and other warnings. Despite the warning, POV-Ray can continue to render the scene. You will be informed if POV-Ray has made any assumptions about your scene so that it can proceed. In general any time you see a warning, you should also assume that this means that future versions of POV-Ray will not allow the warned action. Therefore you should attempt to eliminate warning messages so your scene will be able to run in future versions of POV-Ray. This stream may be turned off and/or directed to a text file. Console Text Output Debug_Console XE "Debug_Console" =boolTurn console display of debug info text on/off+GD XE "+GD" Same as Debug_Console=On-GDSame as Debug_Console=OffFatal_Console XE "Fatal_Console" =boolTurn console display of fatal error text on/off+GF XE "+GF" Same as Fatal_Console=On-GFSame as Fatal_Console=OffRender_Console XE "Render_Console" =boolTurn console display of render info text on/off+GR XE "+GR" Same as Render_Console=On-GRSame as Render_Console=OffStatistic_Console XE "Statistic_Console" =boolTurn console display of statistic text on/off+GS XE "+GS" Same as Statistic_Console=On-GSSame as Statistic_Console=OffWarning_Console XE "Warning_Console" =boolTurn console display of warning text on/off+GW XE "+GW" Same as Warning_Console=On-GWSame as Warning_Console=OffAll_Console XE "All_Console" =boolTurn on/off all debug, fatal, render, statistic and warning text to console.+GA XE "+GA" Same as All_Console=On-GASame as All_Console=OffYou may suppress the output to the console of the debug, fatal, render, statistic or warning text streams. For example the Statistic_Console=off option or the -GS switch can turn off the statistic stream. Using on or +GS you may turn it on again. You may also turn all five of these streams on or off at once using the All_Console option or +GA switch. Note that these options take effect immediately when specified. Obviously any error or warning messages that might occur before the option is read are not be affected. Directing Text Streams to Files Debug_File XE "Debug_File" =trueEcho debug info text to DEBUG.OUTDebug_File=falseTurn off file output of debug infoDebug_File=fileEcho debug info text to file+GD XE "+GD" fileBoth Debug_Console=On, Debug_File=file-GDfileBoth Debug_Console=Off, Debug_File=fileFatal_File XE "Fatal_File" =trueEcho fatal text to FATAL.OUTFatal_File=falseTurn off file output of fatalFatal_File=fileEcho fatal info text to file+GF XE "+GF" fileBoth Fatal_Console=On, Fatal_File=file-GFfileBoth Fatal_Console=Off, Fatal_File=fileRender_File XE "Render_File" =trueEcho render info text to RENDER.OUTRender_File=falseTurn off file output of render infoRender_File=fileEcho render info text to file+GR XE "+GR" fileBoth Render_Console=On, Render_File=file-GRfileBoth Render_Console=Off, Render_File=fileStatistic_File XE "Statistic_File" =trueEcho statistic text to STATS.OUTStatistic_File=falseTurn off file output of statisticsStatistic_File=fileEcho statistic text to file+GS XE "+GS" fileBoth Statistic_Console=On, Statistic_File=file-GSfileBoth Statistic_Console=Off, Statistic_File=fileWarning_File XE "Warning_File" =trueEcho warning info text to WARNING.OUTWarning_File=falseTurn off file output of warning infoWarning_File=fileEcho warning info text to file+GW XE "+GW" fileBoth Warning_Console=On, Warning_File=file-GWfileBoth Warning_Console=Off, Warning_File=fileAll_File XE "All_File" =trueEcho all debug, fatal, render, statistic, and warning text to ALLTEXT.OUTAll_File=falseTurn off file output of all debug, fatal, render, statistic, and warning text.All_File=fileEcho all debug, fatal, render, statistic, and warning text to file+GA XE "+GA" fileBoth All_Console=On, All_File=file-GAfileBoth All_Console=Off, All_File=fileYou may direct a copy of the text streams to a text file for the debug, fatal, render, statistic, or warning text streams. For example the Statistic_File=s option or the +GSs switch. If the string s is true or any of the other valid true strings then that stream is redirected to a file with a default name. Valid true values are true, yes, on or 1. If the value is false the direction to a text file is turned off. Valid false values are false, no, off or 0. Any other string specified turns on file output and the string is interpreted as the output file name. Similarly you may specify such a true, false or file name string after a switch such as +GSfile. You may also direct all five streams to the same file using the All_File option or +GA switch. You may not specify the same file for two or more streams because POV-Ray will fail when it tries to open or close the same file twice. Note that these options take effect immediately when specified. Obviously any error or warning messages that might occur before the option is read will not be affected. Help Screen Switches +H or +?Show help screen 0 if this is the only switch+H0 to +H8Show help screen 0 to 8 if this is the only switch+?0 to +?8Same as +H0 to +H8Note that there are no INI style equivalents to these options. Graphical interface versions of POV-Ray such as Mac or Windows have extensive online help. Other versions of POV-Ray have only a few quick-reference help screens. The +? XE "+?"  switch, optionally followed by a single digit from 0 to 8, will display these help screens to the banner text stream. After displaying the help screens, POV-Ray terminates. Because some operating systems do not permit a question mark as a command line switch you may also use the +H XE "+H"  switch. Note however that this switch is also used to specify the height of the image in pixels. Therefore the +H switch is only interpreted as a help switch if it is the only switch on the command line and if the value after the switch is less than or equal to 8. Tracing Options There is more than one way to trace a ray. Sometimes there is a trade-off between quality and speed. Sometimes options designed to make tracing faster can slow things down. This section covers options that tell POV-Ray how to trace rays with the appropriate speed and quality settings. Quality Settings Quality=nSet quality value to n (0 <= n <= 11)+QnSame as Quality=nThe Quality XE "Quality" =n option or +Q XE "+Q" n switch allows you to specify the image rendering quality. You may choose to lower the quality for test rendering and raise it for final renders. The quality adjustments are made by eliminating some of the calculations that are normally performed. For example settings below 4 do not render shadows. Settings below 8 do not use reflection or refraction. The duplicate values allow for future expansion. The values correspond to the following quality levels: 0, 1Just show quick colors. Use full ambient lighting only. Quick colors are used only at 5 or below.2, 3Show specified diffuse and ambient light.4Render shadows, but no extended lights.5Render shadows, including extended lights.6, 7Compute texture patterns.8Compute reflected, refracted, and transmitted rays.9Compute media.10Compute radiosity but no media11Compute radiosity and mediaThe default is 9 if not specified. Radiosity Setting Radiosity XE "Radiosity" =boolTurns radiosity on/off+QR XE "+QR" Turns radiosity on-QRTurns radiosity onRadiosity is an additional calculation which computes diffuse inter-reflection. It is an extremely slow calculation that is somewhat experimental. By default, radiosity is off. The parameters which control how radiosity calculations are performed are specified in the radiosity XE "radiosity"  section of the global_settings XE "global_settings"  statement. See section " REF _Ref412631781 \h Radiosity" for further details. Automatic Bounding Control Bounding=boolTurn bounding on/off+MBTurn bounding on; Set threshold to 25 or previous amount-MBTurn bounding offBounding_Threshold=nSet bound threshold to n+MBnTurn bounding on; bound threshold to n-MBnTurn bounding off; for future threshold to nLight_Buffer=boolTurn light buffer on/off+ULTurn light buffer on-ULTurn light buffer offVista_Buffer=boolTurn vista buffer on/off+UVTurn vista buffer on-UVTurn vista buffer offPOV-Ray uses a variety of spatial sub-division systems to speed up ray-object intersection tests. The primary system uses a hierarchy of nested bounding boxes. This system compartmentalizes all finite objects in a scene into invisible rectangular boxes that are arranged in a tree-like hierarchy. Before testing the objects within the bounding boxes the tree is descended and only those objects are tested whose bounds are hit by a ray. This can greatly improve rendering speed. However for scenes with only a few objects the overhead of using a bounding system is not worth the effort. The Bounding XE "Bounding" =off option or -MB XE "-MB"  switch allows you to force bounding off. The default value is on. The Bounding_Threshold XE "Bounding_Threshold" =n or +MB XE "+MB" n switch allows you to set the minimum number of objects necessary before bounding is used. The default is +MB25 which means that if your scene has fewer than 25 objects POV-Ray will automatically turn bounding off because the overhead isn't worth it. Generally it's a good idea to use a much lower threshold like +MB5. Additionally POV-Ray uses systems known as vista buffers and light buffers to further speed things up. These systems only work when bounding is on and when there are a sufficient number of objects to meet the bounding threshold. The vista buffer is created by projecting the bounding box hierarchy onto the screen and determining the rectangular areas that are covered by each of the elements in the hierarchy. Only those objects whose rectangles enclose a given pixel are tested by the primary viewing ray. The vista buffer can only be used with perspective and orthographic cameras because they rely on a fixed viewpoint and a reasonable projection (i. e. straight lines have to stay straight lines after the projection). The light buffer is created by enclosing each light source in an imaginary box and projecting the bounding box hierarchy onto each of its six sides. Since this relies on a fixed light source, light buffers will not be used for area lights. Reflected and transmitted rays do not take advantage of the light and vista buffer. The default settings are Vista_Buffer XE "Vista_Buffer" =on or +UV XE "+UV"  and Light_Buffer XE "Light_Buffer" =on or +UL XE "+UL" . The option to turn these features off is available to demonstrate their usefulness and as protection against unforeseen bugs which might exist in any of these bounding systems. In general, any finite object and many types of CSG of finite objects will properly respond to this bounding system. In addition blobs and meshes use an additional internal bounding system. These systems are not affected by the above switch. They can be switched off using the appropriate syntax in the scene file (see " REF _Ref428280785 \h Blob" and " REF _Ref412632666 \h Mesh" for details). Text objects are split into individual letters that are bounded using the bounding box hierarchy. Some CSG combinations of finite and infinite objects are also automatically bound. The end result is that you will rarely need to add manual bounding objects as was necessary in earlier versions of POV-Ray unless you use many infinite objects. Removing User Bounding Remove_Bounds=boolTurn unnecessary bounds removal on/off+URTurn unnecessary bounds removal on-URTurn unnecessary bounds removal offSplit_Unions=boolTurn split bounded unions on/off+SUTurn split bounded unions on-SUTurn split bounded unions offEarly versions of POV-Ray had no system of automatic bounding or spatial sub-division to speed up ray-object intersection tests. Users had to manually create bounding boxes to speed up the rendering. Since version 3.0, POV-Ray has had more sophisticated automatic bounding than any previous version. In many cases the manual bounding on older scenes is slower than the new automatic systems. Therefore POV-Ray removes manual bounding when it knows it will help. In rare instances you may want to keep manual bounding. Some older scenes incorrectly used bounding when they should have used clipping. If POV-Ray removes the bounds in these scenes the image will not look right. To turn off the automatic removal of manual bounds you should specify Remove_Bounds= XE "Remove_Bounds=" off or use -UR XE "-UR" . The default is Remove_Bounds=on. One area where the jury is still out is the splitting of manually bounded unions. Unbounded unions are always split into their component parts so that automatic bounding works better. Most users do not bound unions because they know that doing so is usually slower. If you do manually bound a union we presume you really want it bound. For safety sake we do not presume to remove such bounds. If you want to remove manual bounds from unions you should specify Split_Unions XE "Split_Unions" =on or use +SU XE "+SU" . The default is Split_Unions=off. Anti-Aliasing Options Antialias=boolTurns anti-aliasing on/off+ATurns aa on with threshold 0.3 or previous amount-ATurns anti-aliasing offSampling_Method=nSets aa-sampling method (only 1 or 2 are valid)+AMnSame as Sampling_Method=nAntialias_Threshold=n.nSets anti-aliasing threshold+An.nSets aa on with aa-threshold at n.n-An.nSets aa off (aa-threshold n.n in future)Jitter=boolSets aa-jitter on/off+JSets aa-jitter on with 1.0 or previous amount-JSets aa-jitter offJitter_Amount=n.nSets aa-jitter amount to n.n. If n.n <= 0 aa-jitter is set off+Jn.nSets aa-jitter on; jitter amount to n.n. If n.n <= 0 aa-jitter is set off-Jn.nSets aa-jitter off (jitter amount n.n in future)Antialias_Depth=nSets aa-depth (1 <= n <= 9)+RnSame as Antialias_Depth=nThe ray-tracing process is in effect a discrete, digital sampling of the image with typically one sample per pixel. Such sampling can introduce a variety of errors. This includes a jagged, stair-step appearance in sloping or curved lines, a broken look for thin lines, moir patterns of interference and lost detail or missing objects, which are so small they reside between adjacent pixels. The effect that is responsible for those errors is called aliasing. Anti-aliasing is any technique used to help eliminate such errors or to reduce the negative impact they have on the image. In general, anti-aliasing makes the ray-traced image look smoother. The Antialias XE "Antialias" =on option or +A XE "+A"  switch turns on POV-Ray's anti-aliasing system. When anti-aliasing is turned on, POV-Ray attempts to reduce the errors by shooting more than one viewing ray into each pixel and averaging the results to determine the pixel's apparent color. This technique is called super-sampling and can improve the appearance of the final image but it drastically increases the time required to render a scene since many more calculations have to be done. POV-Ray gives you the option to use one of two alternate super-sampling methods. The Sampling_Method XE "Sampling_Method" =n option or +AM XE "+AM" n switch selects either type 1 or type 2. Selecting one of those methods does not turn anti-aliasing on. This has to be done by using the +A command line switch or Antialias=on option. Type 1 is an adaptive, non-recursive super-sampling method. It is adaptive because not every pixel is super-sampled. Type 2 is an adaptive and recursive super-sampling method. It is recursive because the pixel is sub-divided and sub-sub-divided recursively. The adaptive nature of type 2 is the variable depth of recursion. In the default, non-recursive method (+AM1 XE "+AM1" ), POV-Ray initially traces one ray per pixel. If the color of a pixel differs from its neighbors (to the left or above) by more than a threshold value then the pixel is super-sampled by shooting a given, fixed number of additional rays. The default threshold is 0.3 but it may be changed using the Antialias_Threshold XE "Antialias_Threshold" =n.n option. When the switches are used, the threshold may optionally follow the +A. For example +A0.1 turns anti-aliasing on and sets the threshold to 0.1. The threshold comparison is computed as follows. If r1, g1, b1 and r2, g2, b2 are the rgb components of two pixels then the difference between pixels is computed by diff = abs(r1-r2) + abs(g1-g2) + abs(b1-b2) If this difference is greater than the threshold then both pixels are super-sampled. The rgb values are in the range from 0.0 to 1.0 thus the most two pixels can differ is 3.0. If the anti-aliasing threshold is 0.0 then every pixel is super-sampled. If the threshold is 3.0 then no anti-aliasing is done. Lower threshold means more anti-aliasing and less speed. Use anti-aliasing for your final version of a picture, not the rough draft. The lower the contrast, the lower the threshold should be. Higher contrast pictures can get away with higher tolerance values. Good values seem to be around 0.2 to 0.4. When using the non-recursive method, the default number of super-samples is nine per pixel, located on a 3*3 grid. The Antialias_Depth XE "Antialias_Depth" =n option or +R XE "+R" n switch controls the number of rows and columns of samples taken for a super-sampled pixel. For example +R4 would give 4*4=16 samples per pixel. The second, adaptive, recursive super-sampling method starts by tracing four rays at the corners of each pixel. If the resulting colors differ more than the threshold amount additional samples will be taken. This is done recursively, i.e. the pixel is divided into four sub-pixels that are separately traced and tested for further subdivision. The advantage of this method is the reduced number of rays that have to be traced. Samples that are common among adjacent pixels and sub-pixels are stored and reused to avoid re-tracing of rays. The recursive character of this method makes the super-sampling concentrate on those parts of the pixel that are more likely to need super-sampling (see figure below).  Example of how the recursive super-sampling works. The maximum number of subdivisions is specified by the Antialias_Depth XE "Antialias_Depth" =n option or +R XE "+R" n switch. This is different from the adaptive, non-recursive method were the total number of super-samples is specified. A maximum number of n subdivisions results in a maximum number of samples per pixel that is given by the following table. +Rn Number of samples per super-sampled pixel for the non-recursive method +AM1Maximum number of samples per super-sampled pixel for the recursive method +AM211924253981416289525108963642257491664186466049981263169You should note that the maximum number of samples in the recursive case is hardly ever reached for a given pixel. If the recursive method is used with no anti-aliasing each pixel will be the average of the rays traced at its corners. In most cases a recursion level of three is sufficient. Another way to reduce aliasing artifacts is to introduce noise into the sampling process. This is called jittering and works because the human visual system is much more forgiving to noise than it is to regular patterns. The location of the super-samples is jittered or wiggled a tiny amount when anti-aliasing is used. Jittering is used by default but it may be turned off with the Jitter XE "Jitter" =off option or -J XE "-J"  switch. The amount of jittering can be set with the Jitter_Amount XE "Jitter_Amount" =n.n option. When using switches the jitter scale may be specified after the +J XE "+J" n.n switch. For example +J0.5 uses half the normal jitter. The default amount of 1.0 is the maximum jitter which will insure that all super-samples remain inside the original pixel. Note that the jittering noise is random and non-repeatable so you should avoid using jitter in animation sequences as the anti-aliased pixels will vary and flicker annoyingly from frame to frame. If anti-aliasing is not used one sample per pixel is taken regardless of the super-sampling method specified. Scene Description Language The reference section describes the POV-Ray scene description language. It is supposed to be used as a reference for looking up things. It does not contain detailed explanations on how scenes are written or how POV-Ray is used. It just explains all features, their syntax, applications, limits, drawbacks, etc. The scene description language allows you to describe the world in a readable and convenient way. Files are created in plain ASCII text using an editor of your choice. The input file name is specified using the Input_File_Name XE "Input_File_Name" =file option or +I XE "+I" file switch. By default the files have the extension .pov. POV-Ray reads the file, processes it by creating an internal model of the scene and then renders the scene. The overall syntax of a scene is shown below. See " REF _Ref428631813 \h Notation and Basic Assumptions" for more information on syntax notation. SCENE: SCENE_ITEM... SCENE_ITEM: LANGUAGE_DIRECTIVES | camera { CAMERA_ITEMS... } | OBJECTS | ATMOSPHERIC_EFFECTS | global_settings { GLOBAL_ITEMS } In plain English, this means that a scene contains one or more scene items and that a scene item may be any of the five items listed below it. The items may appear in any order. None is a required item. In addition to the syntax depicted above, a LANGUAGE_DIRECTIVE may also appear anywhere embedded in other statements between any two tokens. There are some restrictions on nesting directives also. For details on those five items see section " REF _Ref412708721 \h Language Directives", section " REF _Ref412708763 \h Objects", section " REF _Ref412708795 \h Camera", section " REF _Ref412709003 \h Atmospheric Effects" and section " REF _Ref412709041 \h Global Settings" for details. Language Basics The POV-Ray language consists of identifiers, reserved keywords, floating point expressions, strings, special symbols and comments. The text of a POV-Ray scene file is free format. You may put statements on separate lines or on the same line as you desire. You may add blank lines, spaces or indentations as long as you do not split any keywords or identifiers. Identifiers and Keywords POV-Ray allows you to define identifiers for later use in the scene file. An identifier may be 1 to 40 characters long. It may consist of upper or lower case letters, the digits 0 through 9 or an underscore character ("_"). The first character must be an alphabetic character. The declaration of identifiers is covered later. POV-Ray has a number of reserved keywords which are listed below. abs absorption acos acosh adaptive adc_bailout agate agate_turb all alpha ambient ambient_light angle aperture append arc_angle area_light array asc asin asinh assumed_gamma atan atan2 atanh average background bezier_spline bicubic_patch black_hole blob blue blur_samples bounded_by box boxed bozo break brick brick_size brightness brilliance bumps bump_map bump_size camera case caustics ceil checker chr clipped_by clock clock_delta color color_map colour colour_map component composite concat cone confidence conic_sweep control0 control1 cos cosh count crackle crand cube cubic cubic_spline cubic_wave cylinder cylindrical debug declare default defined degrees density density_file density_map dents difference diffuse dimensionsdimension_size direction disc distance distance_maximum div eccentricity else emission end error error_bound exp extinction fade_distance fade_power falloff falloff_angle false fclose file_exists filter finish fisheye flatness flip floor focal_point fog fog_alt fog_offset fog_type fopen frequency gif global_settings gradient granite gray_threshold green height_field hexagon hf_gray_16 hierarchy hollow hypercomplex if ifdef iff ifndef image_map include int interior interpolate intersection intervals inverse ior irid irid_wavelength jitter julia_fractal lambda lathe leopard light_source linear_spline linear_sweep local location log looks_like look_at low_error_factor macro mandel map_type marble material material_map matrix max max_intersections max_iteration max_trace_level media media_attenuation media_interactionmerge mesh metallic min minimum_reuse mod mortar nearest_count no normal normal_map no_shadow number_of_waves object octaves off offset omega omnimax on once onion open orthographic panoramic perspective pgm phase phong phong_size pi pigment pigment_map planar plane png point_at poly polygon poly_wave pot pow ppm precision prism pwr quadratic_spline quadric quartic quaternion quick_color quick_colour quilted radial radians radiosity radius rainbow ramp_wave rand range ratio read reciprocal recursion_limit red reflection reflection_exponent refraction render repeat rgb rgbf rgbft rgbt right ripples rotate roughness samples scale scallop_wave scattering seed shadowless sin sine_wave sinh skysky_sphere slice slope_map smooth smooth_triangle sor specular sphere spherical spiral1 spiral2 spotlight spotted sqr sqrt statistics str strcmp strength strlen strlwr strupr sturm substr superellipsoid switch sys t tan tanh text texture texture_map tga thickness threshold tightness tile2 tiles torus track transform translate transmit triangle triangle_wave true ttf turbulence turb_depth type u ultra_wide_angle undef union up use_color use_colour use_index u_steps v val variance vaxis_rotate vcross vdot version vlength vnormalize vrotate v_steps warning warp water_level waves while width wood wrinkles write x y yes zAll reserved words are fully lower case. Therefore it is recommended that your identifiers contain at least one upper case character so it is sure to avoid conflict with reserved words. Comments Comments XE "comments"  are text in the scene file included to make the scene file easier to read or understand. They are ignored by the ray-tracer and are there for your information. There are two types of comments in POV-Ray. Two slashes are used for single line comments. Anything on a line after a double slash (// XE "//" ) is ignored by the ray-tracer. For example: // This line is ignored You can have scene file information on the line in front of the comment as in: object { FooBar } // this is an object The other type of comment is used for multiple lines. It starts with "/* XE "/* */" " and ends with "*/". Everything in-between is ignored. For example: /* These lines are ignored by the ray-tracer */ This can be useful if you want to temporarily remove elements from a scene file. /* ... */ comments can comment out lines containing other // comments and thus can be used to temporarily or permanently comment out parts of a scene. /* ... */ comments can be nested, the following is legal: /* This is a comment // This too /* This also */ */ Use comments liberally and generously. Well used, they really improve the readability of scene files. Float Expressions Many parts of the POV-Ray language require you to specify one or more floating point numbers. A floating point number is a number with a decimal point. Floats may be specified using literals, identifiers or functions which return float values. You may also create very complex float expressions from combinations of any of these using various familiar operators. Where POV-Ray needs an integer value it allows you to specify a float value and it truncates it to an integer. When POV-Ray needs a logical or boolean value it interprets any non-zero float as true and zero as false. Because float comparisons are subject to rounding errors POV-Ray accepts values extremely close to zero as being false when doing boolean functions. Typically values whose absolute values are less than a preset value epsilon are considered false for logical expressions. The value of epsilon is system dependent but is generally about 1.0e-10. Two floats a and b are considered to be equal if abs(a-b) < epsilon. The full syntax for float expressions is given below. Detailed explanations are given in the following sub-sections. FLOAT: NUMERIC_TERM [SIGN NUMERIC_TERM] SIGN: + | - NUMERIC_TERM: NUMERIC_FACTOR [MULT NUMERIC_FACTOR] MULT: * | / NUMERIC_FACTOR: FLOAT_LITERAL | FLOAT_IDENTIFIER | SIGN NUMERIC_FACTOR | FLOAT_FUNCTION | FLOAT_BUILT-IN_IDENT | ( FULL_EXPRESSION ) | ! NUMERIC_FACTOR | VECTOR DECIMAL_POINT DOT_ITEM FLOAT_LITERAL: [DIGIT...] [DECIMAL_POINT] DIGIT... [EXP [SIGN] DIGIT...] DIGIT: 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 DECIMAL_POINT: . EXP: e | E DOT_ITEM: x | y | z | t | u | v | red | blue | green | filter | transmit FLOAT_FUNCTION: abs( FLOAT ) | acos( FLOAT ) | val( STRING ) | asc( STRING ) | asin( FLOAT ) | atan2( FLOAT , FLOAT ) | ceil( FLOAT ) | cos( FLOAT ) | defined(IDENTIFIER ) | degrees( FLOAT ) | div( FLOAT , FLOAT ) | exp( FLOAT ) | file_exists( STRING ) | floor( FLOAT ) | int( FLOAT ) | log( FLOAT ) | max( FLOAT , FLOAT ) | min( FLOAT , FLOAT ) | mod( FLOAT , FLOAT ) | pow( FLOAT , FLOAT ) | radians( FLOAT ) | sin( FLOAT ) | sqrt( FLOAT ) | strcmp( STRING , STRING ) | strlen( STRING ) | tan( FLOAT ) | vdot( VECTOR , VECTOR ) | vlength( VECTOR ) | seed( FLOAT ) | rand( FLOAT ) | dimensions( ARRAY_IDENTIFIER ) | dimension_size( ARRAY_IDENTIFIER , FLOAT ) FLOAT_BUILT-IN_IDENT: clock | pi | version | true | yes | on | false | no | off | clock_delta FULL_EXPRESSION: LOGICAL_EXPRESSION [? FULL_EXPRESSION : FULL_EXPRESSION] LOGICAL_EXPRESSION: REL_TERM [LOGICAL_OPERATOR REL_TERM] LOGICAL_OPERATOR: & | | (note this means an ampersand or a vertical bar is a logical operator) REL_TERM: FLOAT [REL_OPERATOR FLOAT] REL_OPERATOR: < | <= | = | >= | > | != INT: FLOAT (note any syntax which requires a integer INT will accept a FLOAT and it will be truncated to an integer internally by POV-Ray). Note: FLOAT_IDENTIFIERS are identifiers previously declared to have float values. The DOT_ITEM syntax is actually a vector or color operator but it returns a float value. See " REF _Ref412721497 \h Vector Operators" or " REF _Ref412722038 \h Color Operators" for details. An ARRAY_IDENTIFIER is just the identifier name of a previously declared array, it does not include the [] braces nor the index. The syntax for STRING is in the section " REF _Ref413065577 \h Strings". Float Literals Float literals are represented by an optional sign ("+" or "-") digits, an optional decimal point and more digits. If the number is an integer you may omit the decimal point and trailing zero. If it is all fractional you may omit the leading zero. POV-Ray supports scientific notation for very large or very small numbers. The following are all valid float literals: -2.0 -4 34 3.4e6 2e-5 .3 0.6 Float Identifiers Float identifiers may be declared to make scene files more readable and to parameterize scenes so that changing a single declaration changes many values. An identifier is declared as follows. FLOAT_DECLARATION: #declare IDENTIFIER = EXPRESSION; | #local IDENTIFIER = EXPRESSION; Where IDENTIFIER is the name of the identifier up to 40 characters long and EXPRESSION is any valid expression which evaluates to a float value. Note that there should be a semi-colon after the expression in a float declaration. This semi-colon is new with POV-Ray version 3.1. If omitted, it generates a warning and some macros may not work properly. See " REF _Ref412711267 \h #declare vs. #local" for information on identifier scope. Here are some examples. #declare Count = 0; #declare Rows = 5.3; #declare Cols = 6.15; #declare Number = Rows*Cols; #declare Count = Count+1; As the last example shows, you can re-declare a float identifier and may use previously declared values in that re-declaration. There are several built-in identifiers which POV-Ray declares for you. See " REF _Ref413233292 \h Built-in Float Identifiers" for details. Float Operators Arithmetic expressions: Basic math expressions can be created from float literals, identifiers or functions using the following operators in this order of precedence... ( )expressions in parentheses first+A -A !Aunary minus, unary plus and logical "not"A*B A/Bmultiplication and divisionA+B A-Baddition and subtractionRelational, logical and conditional expressions may also be created. However there is a restriction that these types of expressions must be enclosed in parentheses first. This restriction, which is not imposed by most computer languages, is necessary because POV-Ray allows mixing of float and vector expressions. Without the parentheses there is an ambiguity problem. Parentheses are not required for the unary logical not operator "!" as shown above. The operators and their precedence are shown here. Relational expressions: The operands are arithmetic expressions and the result is always boolean with 1 for true and 0 for false. All relational operators have the same precedence. (A < B)A is less than B(A <= B)A is less than or equal to B(A = B)A is equal to B (actually abs(A-B)=EPSILON)(A >= B)A is greater than or equal to B(A > B)A is greater than BLogical expressions: The operands are converted to boolean values of 0 for false and 1 for true. The result is always boolean. All logical operators have the same precedence. Note that these are not bit-wise operations, they are logical. (A & B)true only if both A and B are true, false otherwise(A | B)true if either A or B or both are trueConditional expressions: The operand C is boolean while operands A and B are any expressions. The result is of the same type as A and B. (C ? A : B)if C then A else BAssuming the various identifiers have been declared, the following are examples of valid expressions... 1+2+3 2*5 1/3 Row*3 Col*5 (Offset-5)/2 This/That+Other*Thing ((This=Thing)?Foo:Bar) Expressions are evaluated left to right with innermost parentheses evaluated first, then unary +, - or !, then multiply or divide, then add or subtract, then relational, then logical, then conditional. Built-in Float Identifiers There are several built-in float identifiers. You can use them to specify values or to create expressions but you cannot re-declare them to change their values. They are: FLOAT_BUILT-IN_IDENT: clock | pi | version | true | yes | on | false | no | off | clock_delta  XE "#declare" Most built-in identifiers never change value. They are defined as though the following lines were at the start of every scene. #declare pi = 3.1415926535897932384626; #declare true = 1; #declare yes = 1; #declare on = 1; #declare false = 0; #declare no = 0; #declare off = 0; The built-in float identifier pi XE "pi"  is obviously useful in math expressions involving circles. The built-in float identifiers on XE "on" , off XE "off" , yes XE "yes" , no XE "no" , true XE "true" , and false XE "false"  are designed for use as boolean constants. The built-in float identifier clock XE "clock"  is used to control animations in POV-Ray. Unlike some animation packages, the action in POV-Ray animated scenes does not depend upon the integer frame numbers. Rather you should design your scenes based upon the float identifier clock. For non-animated scenes its default value is 0 but you can set it to any float value using the INI file option Clock XE "Clock" =n.n or the command-line switch +K XE "+K" n.n to pass a single float value your scene file. Other INI options and switches may be used to animate scenes by automatically looping through the rendering of frames using various values for clock. By default, the clock value is 0 for the initial frame and 1 for the final frame. All other frames are interpolated between these values. For example if your object is supposed to rotate one full turn over the course of the animation you could specify rotate 360*clock*y. Then as clock runs from 0 to 1, the object rotates about the y-axis from 0 to 360 degrees. Although the value of clock will change from frame-to-frame, it will never change throughout the parsing of a scene. The built-in float identifier clock_delta XE "clock_delta"  returns the amount of time between clock values in animations in POV-Ray. While most animations only need the clock value itself, some animation calculations are easier if you know how long since the last frame. Caution must be used when designing such scenes. If you render a scene with too few frames, the results may be different than if you render with more frames in a given time period. On non-animated scenes, clock_delta defaults to 1.0. See section " REF _Ref413057470 \h Animation Options" for more details. The built-in float identifier version XE "version"  contains the current setting of the version compatibility option. Although this value defaults to 3.1 which is the current POV-Ray version number, the initial value of version may be set by the INI file option Version XE "Version" =n.n or by the +MV XE "+MV" n.n command-line switch. This tells POV-Ray to parse the scene file using syntax from an earlier version of POV-Ray. The INI option or switch only affects the initial setting. Unlike other built-in identifiers, you may change the value of version throughout a scene file. You do not use #declare XE "#declare"  to change it though. The #version XE "#version"  language directive is used to change modes. Such changes may occur several times within scene files. Together with the built-in version identifier the #version directive allows you to save and restore the previous values of this compatibility setting. The new #local XE "#local"  identifier option is especially useful here. For example suppose mystuff.inc is in version 1 format. At the top of the file you could put: #local Temp_Vers = version; // Save previous value #version 1.0; // Change to 1.0 mode ... // Version 1.0 stuff goes here... #version Temp_Vers; // Restore previous version Note that there should be a semi-colon after the float expression in a #version directive. This semi-colon is new with POV-Ray version 3.1. If omitted, it generates a warning and some macros may not work properly. Boolean Keywords The built-in float identifiers on XE "on" , off XE "off" , yes XE "yes" , no XE "no" , true XE "true" , and false XE "false"  are most often used as boolean values with object modifiers or parameters such as sturm XE "sturm" , hollow XE "hollow" , hierarchy XE "hierarchy" , smooth XE "smooth" , media_attenuation XE "media_attenuation" , and media_interaction XE "media_interaction" . Whenever you see syntax of the form keyword [Bool], if you simply specify the keyword without the optional boolean then it assumes keyword on. You need not use the boolean but for readability it is a good idea. You must use one of the false booleans or an expression which evaluates to zero to turn it off. Note some of these keywords default on if no keyword is specified. For example: object{MyBlob} //sturm defaults off but hierarchy defaults on object{MyBlob sturm} //turn sturm on object{MyBlob sturm on} //turn sturm on object{MyBlob sturm off} //turn sturm off object{MyBlob hierarchy} //does nothing, hierarchy was already on object{MyBlob hierarchy off} //turn hierarchy off Float Functions POV-Ray defines a variety of built-in functions for manipulating floats, vectors and strings. Function calls consist of a keyword which specifies the name of the function followed by a parameter list enclosed in parentheses. Parameters are separated by commas. For example: keyword(param1,param2) The following are the functions which return float values. They take one or more float, integer, vector, or string parameters. Assume that A and B are any valid expression that evaluates to a float; I is a float which is truncated to integer internally, S, S1, S2 etc. are strings, and V, V1, V2 etc. are any vector expressions. abs XE "abs" (A) Absolute value of A. If A is negative, returns -A otherwise returns A. acos XE "acos" (A) Arc-cosine of A. Returns the angle, measured in radians, whose cosine is A. asc XE "asc" (S) Returns an integer value in the range 0 to 255 that is the ASCII value of the first character of the string S. For example asc("ABC") is 65 because that is the value of the character "A". asin XE "asin" (A) Arc-sine of A. Returns the angle, measured in radians, whose sine is A. atan2 XE "atan2" (A,B) Arc-tangent of (A/B). Returns the angle, measured in radians, whose tangent is (A/B). Returns appropriate value even if B is zero. Use atan2(A,1) to compute usual atan(A) function. ceil XE "ceil" (A) Ceiling of A. Returns the smallest integer greater than A. Rounds up to the next higher integer. cos XE "cos" (A) Cosine of A. Returns the cosine of the angle A, where A is measured in radians. defined XE "dimension" (IDENTIFIER ) Returns true if the identifier is currently defined, false otherwise. This is especially useful for detecting end-of-file after a #read directive because the file identifer is automatically undefined when end-of-file is reached. See " REF _Ref429985373 \h The #read Directive" for details. degrees XE "degrees" (A) Convert radians to degrees. Returns the angle measured in degrees whose value in radians is A. Formula is degrees=A/pi*180.0. dimensions XE "dimension" ( ARRAY_IDENTIFIER ) Returns the number of dimensions of a previously declared array identifier. For example if you do #declare MyArray=array[6][10] then dimensions(MyArray) returns the value 2. dimension_size XE "dimension_size" ( ARRAY_IDENTIFIER, FLOAT ) Returns the size of a given dimension of a previously declared array identifier. Dimensions are numbered left-to-right starting with 1. For example if you do #declare MyArray=array[6][10] then dimension_size(MyArray,2) returns the value 10. div XE "div" (A,B) Integer division. The integer part of (A/B). exp XE "exp" (A) Exponential of A. Returns the value of e raised to the power A where e is the base of the natural logarithm, i.e. the non-repeating value approximately equal to 2.71828182846. file_exists XE "file_exists" (S) Attempts to open the file specified by the string S. The current directory and all library directories specified by the Library_Path XE "Library_Path"  or +L XE "+L"  options are also searched. See " REF _Ref413142060 \h Library Paths" for details. Returns 1 if successful and 0 if unsuccessful. floor XE "floor" (A) Floor of A. Returns the largest integer less than A. Rounds down to the next lower integer. int XE "int" (A) Integer part of A. Returns the truncated integer part of A. Rounds towards zero. log XE "log" (A) Natural logarithm of A. Returns the natural logarithm base e of the value A. max XE "max" (A,B) Maximum of A and B. Returns A if A larger than B. Otherwise returns B. min XE "min" (A,B) Minimum of A and B. Returns A if A smaller than B. Otherwise returns B. mod XE "mod" (A,B) Value of A modulo B. Returns the remainder after the integer division of A/B. Formula is mod=((A/B)-int(A/B))*B. pow XE "pow" (A,B) Exponentiation. Returns the value of A raised to the power B. radians XE "radians" (A) Convert degrees to radians. Returns the angle measured in radians whose value in degrees is A. Formula is radians=A*pi/180.0. rand XE "rand" (I) Returns the next pseudo-random number from the stream specified by the positive integer I. You must call seed() to initialize a random stream before calling rand(). The numbers are uniformly distributed, and have values between 0.0 and 1.0, inclusively. The numbers generated by separate streams are independent random variables. seed XE "seed" (A) Initializes a new pseudo-random stream with the initial seed value A. The number corresponding to this random stream is returned. Any number of pseudo-random streams may be used as shown in the example below: #declare R1 = seed(0); #declare R2 = seed(12345); #sphere { , rand(R2) } Multiple random generators are very useful in situations where you use rand() to place a group of objects, and then decide to use rand() in another location earlier in the file to set some colors or place another group of objects. Without separate rand() streams, all of your objects would move when you added more calls to rand(). This is very annoying. sin XE "sin" (A) Sine of A. Returns the sine of the angle A, where A is measured in radians. strcmp XE "strcmp" (S1,S2) Compare string S1 to S2. Returns a float value zero if the strings are equal, a positive number if S1 comes after S2 in the ASCII collating sequence, else a negative number. strlen XE "strlen" (S) Length of S. Returns an integer value that is the number of characters in the string S. sqrt XE "sqrt" (A) Square root of A. Returns the value whose square is A. tan XE "tan" (A) Tangent of A. Returns the tangent of the angle A, where A is measured in radians. val XE "val" (S) Convert string S to float. Returns a float value that is represented by the text in string S. For example val("123.45") is 123.45 as a float. vdot XE "vdot" (V1,V2) Dot product of V1 and V2. Returns a float value that is the dot product (sometimes called scalar product of V1 with V2. Formula is vdot=V1.x*V2.x + V1.y*V2.y + V1.z*V2.z. See the animated demo scene VECT2.POV for an illustration. vlength XE "vlength" (V) Length of V. Returns a float value that is the length of vector V. Formula is vlength=sqrt(vdot(A,A)). Can be used to compute the distance between two points. Dist=vlength(V2-V1). See section " REF _Ref413150466 \h Vector Functions" and section " REF _Ref413150500 \h String Functions" for other functions which are somewhat float-related but which return vectors and strings. In addition to the above built-in functions, you may also define your own functions using the new #macro directive. See the section " REF _Ref413063326 \h User Defined Macros" for more details. Vector Expressions POV-Ray often requires you to specify a vector. A vector is a set of related float values. Vectors may be specified using literals, identifiers or functions which return vector values. You may also create very complex vector expressions from combinations of any of these using various familiar operators. POV-Ray vectors may have from two to five components but the vast majority of vectors have three components. Unless specified otherwise, you should assume that the word "vector" means a three component vector. POV-Ray operates in a 3D x, y, z coordinate system and you will use three component vectors to specify x, y and z values. In some places POV-Ray needs only two coordinates. These are often specified by a 2D vector called an UV vector. Fractal objects use 4D vectors. Color expressions use 5D vectors but allow you to specify 3, 4 or 5 components and use default values for the unspecified components. Unless otherwise noted, all 2, 4 or 5 component vectors work just like 3D vectors but they have a different number of components. The syntax for combining vector literals into vector expressions is almost identical to the rules for float expressions. In the syntax for vector expressions below, some of the syntax items are defined in the section for float expressions. See " REF _Ref412720567 \h Float Expressions" for those definitions. Detailed explanations of vector-specific issues are given in the following sub-sections. VECTOR: NUMERIC_TERM [SIGN NUMERIC_TERM] NUMERIC_TERM: NUMERIC_FACTOR [MULT NUMERIC_FACTOR] NUMERIC_FACTOR: VECTOR_LITERAL | VECTOR_IDENTIFIER | SIGN NUMERIC_FACTOR | VECTOR_FUNCTION | VECTOR_BUILT-IN_IDENT | ( FULL_EXPRESSION ) | ! NUMERIC_FACTOR | FLOAT VECTOR_LITERAL: < FLOAT , FLOAT , FLOAT > VECTOR_FUNCTION: vaxis_rotate( VECTOR , VECTOR , FLOAT ) | vcross( VECTOR , VECTOR ) | vrotate( VECTOR , VECTOR ) | vnormalize( VECTOR ) VECTOR_BUILT-IN_IDENT: x | y | z | t | u | v Note: VECTOR_IDENTIFIERS are identifiers previously declared to have vector values. Vector Literals Vectors literals consist of two to five float expressions that are bracketed by angle brackets < and >. The terms are separated by commas. For example here is a typical three component vector: < 1.0, 3.2, -5.4578 > The commas between components are necessary to keep the program from thinking that the 2nd term is the single float expression 3.2-5.4578 and that there is no 3rd term. If you see an error message such as "Float expected but '>' found instead" then you probably have missed a comma. Sometimes POV-Ray requires you to specify floats and vectors side-by-side. The rules for vector expressions allow for mixing of vectors with vectors or vectors with floats so commas are required separators whenever an ambiguity might arise. For example <1,2,3>-4 evaluates as a mixed float and vector expression where 4 is subtracted from each component resulting in <-3,-2,-1>. However the comma in <1,2,3>,-4 means this is a vector followed by a float. Each component may be a full float expression. For example is a valid vector. Vector Identifiers Vector identifiers may be declared to make scene files more readable and to parameterize scenes so that changing a single declaration changes many values. An identifier is declared as follows. VECTOR_DECLARATION: #declare IDENTIFIER = EXPRESSION; | #local IDENTIFIER = EXPRESSION; Where IDENTIFIER is the name of the identifier up to 40 characters long and EXPRESSION is any valid expression which evaluates to a vector value. Note that there should be a semi-colon after the expression in a vector declaration. This semi-colon is new with POV-Ray version 3.1. If omitted, it generates a warning and some macros may not work properly. See " REF _Ref412711267 \h #declare vs. #local" for information on identifier scope. Here are some examples.... #declare Here = <1,2,3>; #declare There = <3,4,5>; #declare Jump = ; #declare Route = There-Here; #declare Jump = Jump+<1,2,3>; Note that you invoke a vector identifier by using its name without any angle brackets. As the last example shows, you can re-declare a vector identifier and may use previously declared values in that re-declaration. There are several built-in identifiers which POV-Ray declares for you. See section " REF _Ref413233324 \h Built-in Vector Identifiers" for details. Vector Operators Vector literals, identifiers and functions may also be combined in expressions the same as float values. Operations are performed on a component-by-component basis. For example <1,2,3> + <4,5,6> evaluates the same as <1+4,2+5,3+6> or <5,7,9>. Other operations are done on a similar component-by-component basis. For example (<1,2,3> = <3,2,1>) evaluates to <0,1,0> because the middle components are equal but the others are not. Admittedly this isn't very useful but its consistent with other vector operations. Conditional expressions such as (C ? A : B) require that C is a float expression but A and B may be vector expressions. The result is that the entire conditional evaluates as a valid vector. For example if Foo and Bar are floats then (Foo < Bar ? <1,2,3> : <5,6,7>) evaluates as the vector <1,2,3> if Foo is less than Bar and evaluates as <5,6,7> otherwise. You may use the dot operator to extract a single float component from a vector. Suppose the identifier Spot was previously defined as a vector. Then Spot.x is a float value that is the first component of this x, y, z vector. Similarly Spot.y and Spot.z reference the 2nd and 3rd components. If Spot was a two component UV vector you could use Spot.u XE ".u"  and Spot.v XE ".v"  to extract the first and second component. For a 4D vector use .x XE ".x" , .y XE ".y" , .z XE ".z" , and .t XE ".t"  to extract each float component. The dot operator is also used in color expressions which are covered later. Operator Promotion You may use a lone float expression to define a vector whose components are all the same. POV-Ray knows when it needs a vector of a particular type and will promote a float into a vector if need be. For example the POV-Ray scale XE "scale"  statement requires a three component vector. If you specify scale 5 then POV-Ray interprets this as scale <5,5,5> which means you want to scale by 5 in every direction. Versions of POV-Ray prior to 3.0 only allowed such use of a float as a vector in various limited places such as scale and turbulence XE "turbulence" . However you may now use this trick anywhere. For example... box{0,1} // Same as box{<0,0,0>,<1,1,1>} sphere{0,1} // Same as sphere{<0,0,0>,1} When promoting a float into a vector of 2, 3, 4 or 5 components, all components are set to the float value, however when promoting a vector of a lower number of components into a higher order vector, all remaining components are set to zero. For example if POV-Ray expects a 4D vector and you specify 9 the result is <9,9,9,9> but if you specify <7,6> the result is <7,6,0,0>. Built-in Vector Identifiers There are several built-in vector identifiers. You can use them to specify values or to create expressions but you cannot re-declare them to change their values. They are: VECTOR_BUILT-IN_IDENT: x | y | z | t | u | v  XE "#declare" All built-in vector identifiers never change value. They are defined as though the following lines were at the start of every scene. #declare x = <1, 0, 0>; #declare y = <0, 1, 0>; #declare z = <0, 0, 1>; #declare t = <0, 0, 0, 1>; #declare u = <1, 0>; #declare v = <0, 1>; The built-in vector identifiers x XE "x" , y XE "y" , and z XE "z"  provide much greater readability for your scene files when used in vector expressions. For example.... plane { y, 1} // The normal vector is obviously "y". plane { <0,1,0>, 1} // This is harder to read. translate 5*x // Move 5 units in the "x" direction. translate <5,0,0> // This is less obvious. An expression like 5*x evaluates to 5*<1,0,0> or <5,0,0>. Similarly u XE "u"  and v XE "v"  may be used in 2D vectors. When using 4D vectors you should use x, y, z, and t XE "t"  and POV-Ray will promote x, y, and z to 4D when used where 4D is required. Vector Functions POV-Ray defines a variety of built-in functions for manipulating floats, vectors and strings. Function calls consist of a keyword which specifies the name of the function followed by a parameter list enclosed in parentheses. Parameters are separated by commas. For example: keyword(param1,param2) The following are the functions which return vector values. They take one or more float, integer, vector, or string parameters. Assume that A and B are any valid expression that evaluates to a vector; and F is any float expression. vaxis_rotate XE "vaxis_rotate" (A,B,F) Rotate A about B by F. Given the x,y,z coordinates of a point in space designated by the vector A, rotate that point about an arbitrary axis defined by the vector B. Rotate it through an angle specified in degrees by the float value F. The result is a vector containing the new x,y,z coordinates of the point. vcross XE "vcross" (A,B) Cross product of A and B. Returns a vector that is the vector cross product of the two vectors. The resulting vector is perpendicular to the two original vectors and its length is proportional to the angle between them. See the animated demo scene VECT2.POV for an illustration. vnormalize XE "vnormalize" (A) Normalize vector A. Returns a unit length vector that is the same direction as A. Formula is vnormalize=A/vlength(A). vrotate XE "vrotate" (A,B) Rotate A about origin by B. Given the x,y,z coordinates of a point in space designated by the vector A, rotate that point about the origin by an amount specified by the vector B. Rotate it about the x-axis by an angle specified in degrees by the float value B.x. Similarly B.y and B.z specify the amount to rotate in degrees about the y-axis and z-axis. The result is a vector containing the new x,y,z coordinates of the point. See section " REF _Ref413163935 \h Float Functions" for other functions which are somewhat vector-related but which return floats. In addition to the above built-in functions, you may also define your own functions using the new #macro directive. See the section " REF _Ref413063326 \h User Defined Macros" for more details. Specifying Colors POV-Ray often requires you to specify a color. Colors consist of five values or color components. The first three are called red XE "red" , green XE "green" , and blue XE "blue" . They specify the intensity of the primary colors red, green and blue using an additive color system like the one used by the red, green and blue color phosphors on a color monitor. The 4th component, called filter XE "filter" , specifies the amount of filtered transparency of a substance. Some real-world examples of filtered transparency are stained glass windows or tinted cellophane. The light passing through such objects is tinted by the appropriate color as the material selectively absorbs some frequencies of light while allowing others to pass through. The color of the object is subtracted from the light passing through so this is called subtractive transparency. The 5th component, called transmit XE "transmit" , specifies the amount of non-filtered light that is transmitted through a surface. Some real-world examples of non-filtered transparency are thin see-through cloth, fine mesh netting and dust on a surface. In these examples, all frequencies of light are allowed to pass through tiny holes in the surface. Although the amount of light passing through is diminished, the color of the light passing through is unchanged. The color of the object is added to the light passing through so this is called additive transparency. Note that early versions of POV-Ray used the keyword alpha XE "alpha"  to specify filtered transparency. However that word is often used to describe non-filtered transparency. For this reason alpha is no longer used. Each of the five components of a color are float values which are normally in the range between 0.0 and 1.0. However any values, even negatives may be used. Under most circumstances the keyword color is optional and may be omitted. We also support the British or Canadian spelling colour. Colors may be specified using vectors, keywords with floats or identifiers. You may also create very complex color expressions from combinations of any of these using various familiar operators. The syntax for specifying a color has evolved since POV-Ray was first released. We have maintained the original keyword-based syntax and added a short-cut vector notation. Either the old or new syntax is acceptable however the vector syntax is easier to use when creating color expressions. The syntax for combining color literals into color expressions is almost identical to the rules for vector and float expressions. In the syntax for vector expressions below, some of the syntax items are defined in the section for float expressions. See " REF _Ref412720567 \h Float Expressions" for those definitions. Detailed explanations of color-specific issues are given in the following sub-sections. COLOR: COLOR_BODY | color COLOR_BODY | (this means the keyword color or colour may colour COLOR_BODY optionally precede any color specification) COLOR_BODY: COLOR_VECTOR | COLOR_KEYWORD_GROUP | COLOR_IDENTIFIER COLOR_VECTOR: rgb <3_Term_Vector> | rgbf <4_Term_Vector> | rgbt <4_Term_Vector> | [ rgbft ] <5_Term_Vector> COLOR_KEYWORD_GROUP: [ COLOR_KEYWORD_ITEM ]... COLOR_KEYWORD_ITEM: COLOR_IDENTIFIER | red Red_Amount | blue Blue_Amount | green Green_Amount | filter Filter_Amount | transmit Transmit_Amount Note: COLOR_IDENTIFIERS are identifiers previously declared to have color values. The 3, 4, and 5 term vectors are usually vector literals but may be vector expressions or floats promoted to vectors. See " REF _Ref412891853 \h Operator Promotion" and the sections below. Color Vectors The syntax for a color vector is... COLOR_VECTOR: rgb <3_Term_Vector> | rgbf <4_Term_Vector> | rgbt <4_Term_Vector> | [ rgbft ] <5_Term_Vector> ...where the vectors are any valid vector expressions of 3, 4 or 5 components. For example color rgb <1.0, 0.5, 0.2>  XE "rgb" This specifies a color whose red component is 1.0 or 100% of full intensity. The green component is 0.5 or 50% of full intensity and the blue component is 0.2 or 20% of full intensity. Although the filter and transmit components are not explicitly specified, they exist and are set to their default values of 0 or no transparency. The rgbf XE "rgbf"  keyword requires a four component vector. The 4th component is the filter component and the transmit component defaults to zero. Similarly the rgbt XE "rgbt"  keyword requires four components where the 4th value is moved to the 5th component which is transmit and then the filter component is set to zero. The rgbft XE "rgbft"  keyword allows you to specify all five components. Internally in expressions all five are always used. Under some circumstances, if the vector expression is a 5 component expression or there is a color identifier in the expression then the rgbtf keyword is optional. Color Keywords The older keyword method of specifying a color is still useful and many users prefer it. COLOR_KEYWORD_GROUP: [ COLOR_KEYWORD_ITEM ]... COLOR_KEYWORD_ITEM: COLOR_IDENTIFIER | red Red_Amount | blue Blue_Amount | green Green_Amount | filter Filter_Amount | transmit Transmit_Amount Although the color keyword at the beginning is optional, it is more common to see it in this usage. This is followed by any of five additional keywords red XE "red" , green XE "green" , blue XE "blue" , filter XE "filter" , or transmit XE "transmit" . Each of these component keywords is followed by a float expression. For example color red 1.0 green 0.5 This specifies a color whose red component is 1.0 or 100% of full intensity and the green component is 0.5 or 50% of full intensity. Although the blue, filter and transmit components are not explicitly specified, they exist and are set to their default values of 0. The component keywords may be given in any order and if any component is unspecified its value defaults to zero. A COLOR_IDENTIFIER can also be specified but it should always be first in the group. See " REF _Ref412904357 \h Common Color Pitfalls" for details. Color Identifiers  XE "#declare" Color identifiers may be declared to make scene files more readable and to parameterize scenes so that changing a single declaration changes many values. An identifier is declared as follows. COLOR_DECLARATION: #declare IDENTIFIER = COLOR; | #local IDENTIFIER = COLOR; Where IDENTIFIER is the name of the identifier up to 40 characters long and COLOR is any valid specification. Note that there should be a semi-colon at the end of the declaration. This semi-colon is new with POV-Ray version 3.1. If omitted, it generates a warning and some macros may not work properly. See " REF _Ref412711267 \h #declare vs. #local" for information on identifier scope. Here are some examples.... #declare White = rgb <1,1,1>; #declare Cyan = color blue 1.0 green 1.0; #declare Weird = rgb ; #declare LightGray = White*0.8; #declare LightCyan = Cyan red 0.6; As the LightGray example shows you do not need any color keywords when creating color expressions based on previously declared colors. The last example shows you may use a color identifier with the keyword style syntax. Make sure that the identifier comes first before any other component keywords. Like floats and vectors, you may re-define colors throughout a scene but the need to do so is rare. Color Operators Color vectors may be combined in expressions the same as float or vector values. Operations are performed on a component-by-component basis. For example rgb <1.0,0.5,0.2>*0.9 evaluates the same as rgb<1.0,0.5,0.2>*<0.9,0.9,0.9> or rgb<0.9,0.45,0.18>. Other operations are done on a similar component-by-component basis. You may use the dot operator to extract a single component from a color. Suppose the identifier Shade was previously defined as a color. Then Shade.red XE ".red"  is the float value of the red component of Shade. Similarly Shade.green XE ".green" , Shade.blue XE ".blue" , Shade.filter XE ".filter"  and Shade.transmit XE ".transmit"  extract the float value of the other color components. Common Color Pitfalls The variety and complexity of color specification methods can lead to some common mistakes. Here are some things to consider when specifying a color. When using filter transparency, the colors which come through are multiplied by the primary color components. For example if gray light such as rgb<0.9,0.9,0.9> passes through a filter such as rgbf<1.0,0.5,0.0,1.0> the result is rgb<0.9,0.45,0.0> with the red let through 100%, the green cut in half from 0.9 to 0.45 and the blue totally blocked. Often users mistakenly specify a clear object by color filter 1.0 but this has implied red, green and blue values of zero. You've just specified a totally black filter so no light passes through. The correct way is either color red 1.0 green 1.0 blue 1.0 filter 1.0 or color transmit 1.0 In the 2nd example it doesn't matter what the rgb values are. All of the light passes through untouched. Another pitfall is the use of color identifiers and expressions with color keywords. For example... color My_Color red 0.5 this substitutes whatever was the red component of My_Color with a red component of 0.5 however... color My_Color + red 0.5 adds 0.5 to the red component of My_Color and even less obvious... color My_Color * red 0.5 that cuts the red component in half as you would expect but it also multiplies the green, blue, filter and transmit components by zero! The part of the expression after the multiply operator evaluates to rgbft<0.5,0,0,0,0> as a full 5 component color. The following example results in no change to My_Color. color red 0.5 My_Color This is because the identifier fully overwrites the previous value. When using identifiers with color keywords, the identifier should be first. Another issue to consider: some POV-Ray syntax allows full color specifications but only uses the rgb part. In these cases it is legal to use a float where a color is needed. For example: finish { ambient 1 } The ambient keyword expects a color so the value 1 is promoted to <1,1,1,1,1> which is no problem. However pigment { color 0.4 } is legal but it may or may not be what you intended. The 0.4 is promoted to <0.4,0.4,0.4,0.4,0.4> with the filter and transmit set to 0.4 as well. It is more likely you wanted... pigment { color rgb 0.4 } in which case a 3 component vector is expected. Therefore the 0.4 is promoted to <0.4,0.4,0.4,0.0,0.0> with default zero for filter and transmit. Finally there is another problem which arises when using color dot operators in #declare XE "#declare"  or #local XE "#local"  directives. Consider the directive: #declare MyColor = rgb <0.75, 0.5, 0.75>; #declare RedAmt = MyColor.red; Now RedAmt should be a float but unfortunately it is a color. POV-Ray looks at the first keyword after the equals to try to guess what type of identifier you want. It sees the color identifier MyColor and assumes you want to declare a color. It then computes the float value as 0.75 then promotes that into rgbft<0.75,0.75,0.75,0.75,0.75>. It would take a major rewrite to fix this problem so we're just warning you about it. Any of the following work-arounds will work properly. #declare RedAmt = 0.0+MyColor.red; #declare RedAmt = 1.0*MyColor.red; #declare RedAmt = (MyColor.red); Strings The POV-Ray language requires you to specify a string of characters to be used as a file name, text for messages or text for a text object. Strings may be specified using literals, identifiers or functions which return string values. See " REF _Ref413065106 \h String Functions" for details on string functions. Although you cannot build string expressions from symbolic operators such as are used with floats, vectors or colors, you may perform various string operations using string functions. Some applications of strings in POV-Ray allow for non-printing formatting characters such as newline or form-feed. STRING: STRING_FUNCTION | STRING_IDENTIFIER | STRING_LITERAL STRING_LITERAL: "up to 256 ASCII characters" STRING_FUNCTION: str( FLOAT , INT , INT ) | concat( STRING , STRING , [STRING ,...]) | chr( INT ) | substr( STRING , INT , INT ) | strupr( STRING ) | strlwr( STRING ) String Literals String literals begin with a double quote mark '"' which is followed by up to 256 printable ASCII characters and are terminated by another double quote mark. The following are all valid string literals: "Here" "There" "myfile.gif" "textures.inc" Note if you need to specify a quote mark in a string literal you must precede it with a backslash. For example "Joe said \"Hello\" as he walked in." is converted to Joe said "Hello" as he walked in. If you need to specify a backslash, most of the time you need do nothing special. However if the string ends in a backslash, you will have to specify two. For example: "This is a backslash \ and so is this\\" Is converted to: This is a backslash \ and so is this\ The substitution of \" with a " occurs in all POV-Ray string literals regardless usage however other formatting codes such as \n for new line are only supported in user message streams. See " REF _Ref412960691 \h Text Formatting" for details. String Identifiers  XE "#declare" String identifiers may be declared to make scene files more readable and to parameterize scenes so that changing a single declaration changes many values. An identifier is declared as follows. STRING_DECLARATION: #declare IDENTIFIER = STRING | #local IDENTIFIER = STRING Where IDENTIFIER is the name of the identifier up to 40 characters long and STRING is any valid string specification. Note that unlike floats, vectors, or colors, there need not be a semi-colon at the end of the declaration. See " REF _Ref412711267 \h #declare vs. #local" for information on identifier scope. Here are some examples... #declare Font_Name = "ariel.ttf" #declare Inc_File = "myfile.inc" #declare Name = "John" #declare Name = concat(Name," Doe") As the last example shows, you can re-declare a string identifier and may use previously declared values in that re-declaration. String Functions POV-Ray defines a variety of built-in functions for manipulating floats, vectors and strings. Function calls consist of a keyword which specifies the name of the function followed by a parameter list enclosed in parentheses. Parameters are separated by commas. For example: keyword(param1,param2) The following are the functions which return string values. They take one or more float, integer, vector, or string parameters. Assume that A is any valid expression that evaluates to a float; B, L, and P are floats which are truncated to integers internally, S, S1, S2 etc are strings. chr XE "chr" (B) Character whose ASCII value is B. Returns a single character string. The ASCII value of the character is specified by an integer B which must be in the range 0 to 255. For example chr(70) is the string "F". When rendering text objects you should be aware that the characters rendered for values of B > 127 are dependent on the (TTF) font being used. Many (TTF) fonts use the Latin-1 (ISO 8859-1) character set, but not all do. concat XE "concat" (S1,S2,...) Concatenate strings S1 and S2. Returns a string that is the concatenation of all parameter strings. Must have at least 2 parameters but may have more. For example: concat("Value is ", str(A,3,1), " inches") If the float value A was 12.34321 the result is "Value is 12.3 inches" which is a string. str XE "str" (A,L,P): Convert float A to a formatted string. Returns a formatted string representation of float value A. The integer parameter L specifies the minimum length of the string and the type of left padding used if the string's representation is shorter than the minimum. If L is positive then the padding is with blanks. If L is negative then the padding is with zeros. The overall minimum length of the formatted string is abs(L). If the string needs to be longer, it will be made as long as necessary to represent the value. The integer parameter P specifies the number of digits after the decimal point. If P is negative then a compiler-specific default precision is use. Here are some examples: str(123.456,0,3) "123.456" str(123.456,4,3) "123.456" str(123.456,9,3) " 123.456" str(123.456,-9,3) "00123.456" str(123.456,0,2) "123.46" str(123.456,0,0) "123" str(123.456,5,0) " 123" str(123.000,7,2) " 123.00" str(123.456,0,-1) "123.456000" (platform specific) strlwr XE "strlwr" (S) Lower case of S. Returns a new string in which all upper case letters in the string S1 are converted to lower case. The original string is not affected. For example strlwr("Hello There!") results in "hello there!". substr XE "substr" (S,P,L) Sub-string from S. Returns a string that is a subset of the characters in parameter S starting at the position specified by the integer value P for a length specified by the integer value L. For example substr("ABCDEFGHI",4,2) evaluates to the string "EF". If P+L>strlen(S) an error occurs. strupr XE "strupr" (S) Upper case of S. Returns a new string in which all lower case letters in the string S are converted to upper case. The original string is not affected. For example strupr("Hello There!") results in "HELLO THERE!". See section " REF _Ref413163935 \h Float Functions" for other functions which are somewhat string-related but which return floats. In addition to the above built-in functions, you may also define your own functions using the new #macro directive. See the section " REF _Ref413063326 \h User Defined Macros" for more details. Array Identifiers New in POV-Ray 3.1 you may now declare arrays of identifiers of up to five dimensions. Any item that can be declared as an identifier can be declared in an array. Declaring Arrays The syntax for declaring an array is as follows: STRING_DECLARATION: #declare IDENTIFIER = array[ INT ][ [ INT ] ]...[ARRAY_INITIALIZER] | #local IDENTIFIER = array[ INT ][ [ INT ] ]...[ARRAY_INITIALIZER] ARRAY_INITIALIZER: {ARRAY_ITEM, [ARRAY_ITEM, ]... } ARRAY_ITEM: RVALUE | ARRAY_INITIALIZER Where IDENTIFIER is the name of the identifier up to 40 characters long and INT is a valid float expression which is internally truncated to an integer which specifies the size of the array. The optional ARRAY_INITIALIZER is discussed in the next section " REF _Ref413231149 \h Array Initalizers". Here is an example of a one-dimensional, uninitalized array. #declare MyArray = array[10] This declares an uninitalized array of ten elements. The elements are referenced as MyArray[0] through MyArray[9]. As yet, the type of the elements are undetermined. Once you have initialized any element of the array, all other elements can only be defined as that type. An attempt to reference an uninitalized element results in an error. For example: #declare MyArray = array[10]; #declare MyArray[5] = pigment{White} //all other elements must be //pigments too. #declare MyArray[2] = normal{bumps 0.2} //generates an error #declare Thing = MyArray[4] //error: uninitalized array element Multi-dimensional arrays up to five dimensions may be declared. For example: #declare MyGrid = array[4][5] declares a 20 element array of 4 rows and 5 columns. Elements are referenced from MyGrid[0][0] to MyGrid[3][4]. Although it is permissible to reference an entire array as a whole, you may not reference just one dimension of a multi-dimensional array. For example: #declare MyArray = array[10] #declare MyGrid = array[4][5] #declare YourArray = MyArray //this is ok #declare YourGrid = MyGrid //so is this #declare OneRow = MyGrid[2] //this is illegal Large uninitalized arrays do not take much memory. Internally they are arrays of pointers so they probably use just 4 bytes per element. Once initialized with values, they consume memory depending on what you put in them. The rules for local vs. global arrays are the same as any other identifier. Note that this applies to the entire array. You cannot mix local and global elements in the same array. See " REF _Ref412711267 \h #declare vs. #local" for information on identifier scope. Array Initalizers Because it is cumbersome to individually initialize the elements of an array, you may initialize it as it is created using array initializer syntax. For example: #include "colors.inc" #declare FlagColors = array[3] {Red,White,Blue} Multi-dimensional arrays may also be initialized this way. For example: #declare Digits = array[4][10] { {7,6,7,0,2,1,6,5,5,0}, {1,2,3,4,5,6,7,8,9,0}, {0,9,8,7,6,5,4,3,2,1}, {1,1,2,2,3,3,4,4,5,5} } The commas are required between elements and between dimensions as shown in the example. Language Directives The POV Scene Language contains several statements called language directives which tell the file parser how to do its job. These directives can appear in almost any place in the scene file - even in the middle of some other statements. They are used to include other text files in the stream of commands, to declare identifiers, to define macros, conditional, or looped parsing and to control other important aspects of scene file processing. Each directive begins with the hash character # (often called a number sign or pound sign). It is followed by a keyword and optionally other parameters. In versions of POV-Ray prior to 3.0, the use of this # character was optional. Language directives could only be used between objects, camera or light_source statements and could not appear within those statements. The exception was the #include XE "#include"  which could appear anywhere. Now that all language directives can be used almost anywhere, the # character is mandatory. The following keywords introduce language directives. #break#case#debug#declare#default#else#end#fclose#fopen#local#macro#read#render#statistics#switch#undef#version#warning#writeEarlier versions of POV-Ray considered the keyword #max_intersections XE "#max_intersections"  and the keyword #max_trace_level XE "#max_trace_level"  to be language directives but they have been moved to the global_settings XE "global_settings"  statement and should be placed there without the # sign. Their use as a directive still works but it generates a warning and may be discontinued in the future. Include Files and the #include Directive. The language allows include files to be specified by placing the line #include "filename.inc" at any point in the input file. The filename may be specified by any valid string expression but it usually is a literal string enclosed in double quotes. It may be up to 40 characters long (or your computer's limit), including the two double-quote characters. The include file is read in as if it were inserted at that point in the file. Using include is almost the same as cutting and pasting the entire contents of this file into your scene. Include files may be nested. You may have at most 10 nested include files. There is no limit on un-nested include files. Generally, include files have data for scenes but are not scenes in themselves. By convention scene files end in .pov and include files end with .inc. It is legal to specify drive and directory information in the file specification however it is discouraged because it makes scene files less portable between various platforms. Use of full lower case is also recommended but not required. It is typical to put standard include files in a special sub-directory. POV-Ray can only read files in the current directory or one referenced by the Library_Path XE "Library_Path"  option or +L XE "+L"  switch. See section " REF _Ref413233147 \h Library Paths". You may use the #local directive to declare identifiers which are temporary in duration and local to the include file in scope. For details see " REF _Ref413233211 \h #declare vs. #local". The #declare and #local Directives Identifiers may be declared and later referenced to make scene files more readable and to parameterize scenes so that changing a single declaration changes many values. There are several built-in identifiers which POV-Ray declares for you. See section " REF _Ref413233292 \h Built-in Float Identifiers" and " REF _Ref413233324 \h Built-in Vector Identifiers" for details. Declaring identifiers  XE "#declare"  XE "#local" An identifier is declared as follows. DECLARATION: #declare IDENTIFIER = RVALUE | #local IDENTIFIER = RVALUE RVALUE: FLOAT; | VECTOR; | COLOR; | STRING | OBJECT | TEXTURE | PIGMENT | NORMAL | FINISH | INTERIOR | MEDIA | DENSITY COLOR_MAP | PIGMENT_MAP | SLOPE_MAP | NORMAL_MAP | DENSITY_MAP | CAMERA | LIGHT_SOURCE | FOG | RAINBOW | SKY_SPHERE | TRANSFORM Where IDENTIFIER is the name of the identifier up to 40 characters long and RVALUE is any of the listed items. They are called that because they are values that can appear to the right of the equals sign. The syntax for each is in the corresponding section of this language reference. Here are some examples. #declare Rows = 5; #declare Count = Count+1; #local Here = <1,2,3>; #declare White = rgb <1,1,1>; #declare Cyan = color blue 1.0 green 1.0; #declare Font_Name = "ariel.ttf" #declare Rod = cylinder {-5*x,5*x,1} #declare Ring = torus {5,1} #local Checks = pigment { checker White, Cyan } object{ Rod scale y*5 } // not "cylinder { Rod }" object { Ring pigment { Checks scale 0.5 } transform Skew } Note that there should be a semi-colon after the expression in all float, vector and color identifier declarations. This semi-colon is new with POV-Ray version 3.1. If omitted, it generates a warning and some macros may not work properly. Declarations, like most language directives, can appear anywhere in the file - even within other statements. For example: #declare Here=<1,2,3>; #declare Count=0; // initialize Count union { object { Rod translate Here*Count } #declare Count=Count+1; // re-declare inside union object { Rod translate Here*Count } #declare Count=Count+1; // re-declare inside union object { Rod translate Here*Count } } As this example shows, you can re-declare an identifier and may use previously declared values in that re-declaration. However if you attempt to re-declare an identifier as anything other than its original type, it will generate a warning message. Note that object identifiers use the generic wrapper statement object XE "object" { ... }. You do not need to know what kind of object it is. Declarations may be nested inside each other within limits. In the example in the previous section you could declare the entire union as a object. However for technical reasons there are instances where you may not use any language directive inside the declaration of floats, vectors or color expressions. Although these limits have been loosened somewhat for POV-Ray 3.1, they still exist. Identifiers declared within #macro XE "#macro"  ... #end blocks are not created at the time the macro is defined. They are only created at the time the macro is actually invoked. Like all other items inside such a #macro definition, they are ignored when the macro is defined. #declare vs. #local  XE "#declare"  XE "#local" Identifiers may be declared either global using #declare or local using the #local directive. Those created by the #declare directive are permanent in duration and global in scope. Once created, they are available throughout the scene and they are not released until all parsing is complete or until they are specifically released using #undef XE "#undef" . See " REF _Ref413236176 \h Destroying Identifiers". Those created by the #local directive are temporary in duration and local in scope. They temporarily override any identifiers with the same name. See " REF _Ref413236810 \h Identifier Name ". If #local is used inside a #macro then the identifier is local to that macro. When the macro is invoked and the #local directive is parsed, the identifier is created. It persists until the #end directive of the macro is reached. At the #end directive, the identifier is destroyed. Subsequent invocations of the macro create totally new identifiers.  XE "#include" Use of #local within an include file but not in a macro, also creates a temporary identifier that is local to that include file. When the include file is included and the #local directive is parsed, the identifier is created. It persists until the end of the include file is reached. At the end of file the identifier is destroyed. Subsequent inclusions of the file totally new identifiers. Use of #local in the main scene file (not in an include file and not in a macro) is identical to #declare. For clarity sake you should not use #local in a main file except in a macro. There is currently no way to create permanent, yet local identifiers in POV-Ray. Local identifiers may be specifically released early using #undef XE "#undef"  but in general there is no need to do so. See " REF _Ref413237003 \h Destroying Identifiers". Identifier Name Collisions Local identifiers may have the same names as previously declared identifiers. In this instance, the most recent, most local identifier takes precedence. Upon entering an include file or invoking a macro, a new symbol table is created. When referencing identifiers, the most recently created symbol table is searched first, then the next most recent and so on back to the global table of the main scene file. As each macro or include file is exited, its table and identifiers are destroyed. Parameters passed by value reside in the same symbol table as the one used for identifiers local to the macro. The rules for duplicate identifiers may seem complicated when multiply-nested includes and macros are involved, but in actual practice the results are generally what you intended. Consider this example: You have a main scene file called myscene.pov and it contains #declare A = 123; #declare B = rgb<1,2,3>; #declare C = 0; #include "myinc.inc" Inside the include file you invoke a macro called MyMacro(J,K,L). Note it isn't important where MyMacro is defined as long as it is defined before it is invoked. In this example, it is important that the macro is invoked from within myinc.inc. The identifiers A, B, and C are generally available at all levels. If either myinc.inc or MyMacro contain a line such as #declare C=C+1; then the value C is changed everywhere as you might expect. Now suppose inside myinc.inc you do... #local A = 546; The main version of A is hidden and a new A is created. This new A is also available inside MyMacro because MyMacro is nested inside myinc.inc. Once you exit myinc.inc, the local A is destroyed and the original A with its value of 123 is now in effect. Once you have created the local A inside myinc.inc, there is no way to reference the original global A unless you #undef XE "#undef"  A or exit the include file. Using #undef always undefines the most local version of an identifier. Similarly if MyMacro contained... #local B = box{0,1} then a new identifier B is created local to the macro only. The original value of B remains hidden but is restored when the macro is finished. Note that the local B need not have the same type as the original. The complication comes when trying to assign a new value to an identifier at one level that was declared local at an earlier level. Suppose inside myinc.inc you do... #local D = 789; If you are inside myinc.inc and you want to increment D by one, you might try to do... #local D = D + 1; but if you try to do that inside MyMacro you'll create a new D which is local to MyMacro and not the D which is external to MyMacro but local to myinc.inc. Therefore you've said "create a MyMacro D from the value of myinc.inc's D plus one". That's probably not what you wanted. Instead you should do... #declare D = D + 1; You might think this creates a new D that is global but it actually increments the myinc.inc version of D. Confusing isn't it? Here are the rules: 1.) When referencing an identifier, you always get the most recent, most local version. By "referencing" we mean using the value of the identifier in a POV-Ray statement or using it on the right of an equals sign in either a #declare or #local. 2.) When declaring an identifier using the #local keyword, the identifier which is created or has a new value assigned, is ALWAYS created at the current nesting level of macros or include files. 3.) When declaring a NEW, NON-EXISTANT identifier using #declare, it is created as fully global. It is put in the symbol table of the main scene file. 4.) When ASSIGNING A VALUE TO AN EXISTING identifier using #declare, it assigns it to the most recent, most local version at the time. In summary, #local always means "the current level", and #declare means "global" for new identifiers and "most recent" for existing identifiers. Destroying Identifiers with #undef Identifiers created with #declare XE "#declare"  will generally persist until parsing is complete. Identifiers created with #local XE "#local"  will persist until the end of the macro or include file in which they were created. You may however un-define an identifier using the #undef XE "#undef"  directive. For example: #undef MyValue If multiple local nested versions of the identifier exist, the most local most recent version is deleted and any identically named identifiers which were created at higher levels will still exist. See also " REF _Ref413241864 \h The #ifdef and #ifndef Directives". File I/O Directives New in POV-Ray 3.1 you may now open, read, write, append, and close plain ASCII text files while parsing POV-Ray scenes. This feature is primarily intended to help pass information between frames of an animation. Values such as an object's position can be written while parsing the current frame and read back during the next frame. Clever use of this feature could allow a POV-Ray scene to generate its own include files or write self-modifying scripts. We trust that users will come up with other interesting uses for this feature. The #fopen Directive Users may open a text file using the #fopen directive. The syntax is as follows: FOPEN_DIRECTIVE: #fopen IDENTIFIER "filename" OPEN_TYPE OPEN_TYPE: read | write | append Where IDENTIFIER is an undefined identifier used to reference this file as a file handle, "filename" is any string literal or string expression which specifies the file name. Files opened with the read XE "read"  are open for read only. Those opened with write XE "write"  create a new file with the specified name and it overwrites any existing file with that name. Those opened with append XE "append"  opens a file for writing but appends the text to the end of any existing file. The file handle identifier created by #fopen is always global and remains in effect (and the file remains open) until the scene parsing is complete or until you #fclose XE "#fclose"  the file. You may use #ifdef XE "#ifdef"  FILE_HANDLE_IDENTIFIER to see if a file is open. The #fclose Directive Files opened with the #fopen XE "#fopen"  directive are automatically closed when scene parsing completes however you may close a file using the #fclose XE "#fclose"  directive. The syntax is as follows: FCLOSE_DIRECTIVE: #fclose FILE_HANDLE_IDENTIFIER Where FILE_HANDLE_IDENTIFIER is previously opened file opened with the #fopen XE "#fopen"  directive. See " REF _Ref413244037 \h The #fopen Directive". The #read Directive You may read string, float or vector values from a plain ASCII text file directly into POV-Ray variables using the #read directive. The file must first be opened in "read" mode using the #fopen directive. The syntax for #read is as follows: READ_DIRECTIVE: #read( FILE_HANDLE_IDENTIFIER, DATA_IDENTIFIER[,DATA_IDENTIFIER]...) DATA_IDENTIFIER: UNDECLARED_IDENTIFIER | FLOAT_IDENTIFIER | VECTOR_IDENTIFIER | STRING_IDENTIFIER Where FILE_HANDLE_IDENTIFIER is the previously opened file. It is followed by one or more DATA_IDENTIFIERs separated by commas. The parentheses around the identifier list are required. A DATA_IDENTIFIER is any undeclared identifier or any previously declared string identifier, float identifier, or vector identifier. Undefined identifiers will be turned into global identifiers of the type determined by the data which is read. Previously defined identifiers remain at whatever global/local status they had when originally created. Type checking is performed to insure that the proper type data is read into these identifiers. The format of the data to be read must be a series of valid string literals, float literals, or vector literals separated by commas. Expressions or identifiers are not permitted in the data file however unary minus signs and exponential notation are permitted on float values. If you attempt to read past end-of-file, the file is automatically closed and the FILE_HANDLE_IDENTIFIER is deleted from the symbol table. This means that the boolean function defined XE "defined" (IDENTIFIER) can be used to detect end-of-file. For example: #fopen MyFile "mydata.txt" read #while (defined(MyFile)) #read (MyFile,Var1,Var2,Var3) ... #end The #write Directive You may write string, float or vector values to a plain ASCII text file from POV-Ray variables using the #write XE "#write"  directive. The file must first be opened in either write XE "write"  or append XE "append"  mode using the #fopen directive. The syntax for #write is as follows: WRITE_DIRECTIVE: #write( FILE_HANDLE_ITEM, DATA_ITEM[,DATA_ITEM]...) DATA_ITEM: FLOAT | VECTOR | STRING Where FILE_HANDLE_IDENTIFIER is the previously opened file. It is followed by one or more DATA_ITEMs separated by commas. The parentheses around the identifier list are required. A DATA_ITEM is any valid string expression, float expression, or vector expression. Float expressions are evaluated and written as signed float literals. If you require format control, you should use the  XE "str" str(VALUE,L,P) function to convert it to a formatted string. See " REF _Ref413244925 \h String Functions" for details on the str function. Vector expressions are evaluated into three signed float constants and are written with angle brackets and commas in standard POV-Ray vector notation. String expressions are evaluated and written as specified. Note that data read by the #read XE "#read"  directive must have comma delimiters between values and quotes around string data but the #write directive does not automatically output commas or quotes. For example the following #read directive reads a string, float and vector. #read (MyFile,MyString,MyFloat,MyVect) It expects to read something like: "A quote delimeted string" , -123.45, <1,2,-3> The POV-Ray code to write this might be: #declare Val1 = -123.45; #declare Vect1 = <1,2,-3>; #write (MyFile,"\"A quote delimited string\",",Val1,",",Vect1,"\n") See " REF _Ref413245145 \h String Literals" and " REF _Ref413245176 \h Text Formatting" for details on writing special characters such as quotes, newline, etc. The #default Directive POV-Ray creates a default texture when it begins processing. You may change those defaults as described below. Every time you specify a texture XE "texture"  statement, POV-Ray creates a copy of the default texture. Anything you put in the texture statement overrides the default settings. If you attach a pigment XE "pigment" , normal XE "normal" , or finish XE "finish"  to an object without any texture statement then POV-Ray checks to see if a texture has already been attached. If it has a texture then the pigment, normal or finish will modify the existing texture. If no texture has yet been attached to the object then the default texture is copied and the pigment, normal or finish will modify that texture. You may change the default texture, pigment, normal or finish using the language directive #default XE "#default"  as follows: DEFAULT_DIRECTIVE: #default {DEFAULT_ITEM } DEFAULT_ITEM: TEXTURE | PIGMENT | NORMAL | FINISH For example: #default{ texture{ pigment{rgb <1,0,0>} normal{bumps 0.3} finish{ambient 0.4} } } means objects will default to red bumps and slightly high ambient finish. Note also you may change just part of it like this: #default { pigment {rgb <1,0,0>} } This still changes the pigment of the default texture. At any time there is only one default texture made from the default pigment, normal and finish. The example above does not make a separate default for pigments alone. Note that the special textures tiles XE "tiles"  and material_map XE "material_map"  or a texture with a texture_map XE "texture_map"  may not be used as defaults. You may change the defaults several times throughout a scene as you wish. Subsequent #default statements begin with the defaults that were in effect at the time. If you wish to reset to the original POV-Ray defaults then you should first save them as follows: //At top of file #declare Original_Default = texture {} later after changing defaults you may restore it with... #default {texture {Original_Default}} If you do not specify a texture for an object then the default texture is attached when the object appears in the scene. It is not attached when an object is declared. For example: #declare My_Object = sphere{ <0,0,0>, 1 } // Default texture not applied object{ My_Object } // Default texture added here You may force a default texture to be added by using an empty texture statement as follows: #declare My_Thing = sphere { <0,0,0>, 1 texture {} } // Default texture applied The original POV-Ray defaults for all items are given throughout the documentation under each appropriate section. The #version Directive As POV-Ray as evolved from version 1.0 through 3.1 we have made every effort to maintain some amount of backwards compatibility with earlier versions. Some old or obsolete features can be handled directly without any special consideration by the user. Some old or obsolete features can no longer be handled at all. However some old features can still be used if you warn POV-Ray that this is an older scene. The #version XE "#version"  directive can be used to switch version compatibility to different setting several times throughout a scene file. The syntax is: VERSION_DIRECTIVE: #version FLOAT; Note that there should be a semi-colon after the float expression in a #version directive. This semi-colon is new with POV-Ray version 3.1. If omitted, it generates a warning and some macros may not work properly. Additionally you may use the Version XE "Version" =n.n option or the +MV XE "+MV" n.n switch to establish the initial setting. See " REF _Ref413248722 \h Language Version" for details. For example one feature introduced in 2.0 that was incompatible with any 1.0 scene files is the parsing of float expressions. Using #version 1.0 turns off expression parsing as well as many warning messages so that nearly all 1.0 files will still work. Naturally the default setting for this option is #version 3.1. NOTE: Some obsolete or re-designed features are totally unavailable in POV-Ray 3.1 REGARDLES OF THE VERSION SETTING. Details on these features are noted throughout this documentation. The built-in float identifier version XE "version"  contains the current setting of the version compatibility option. See " REF _Ref413233292 \h Built-in Float Identifiers". Together with the built-in version identifier the #version directive allows you to save and restore the previous values of this compatibility setting. The new #local XE "#local"  identifier option is especially useful here. For example suppose mystuff.inc is in version 1 format. At the top of the file you could put: #local Temp_Vers = version; // Save previous value #version 1.0; // Change to 1.0 mode ... // Version 1.0 stuff goes here... #version Temp_Vers; // Restore previous version Future versions of POV-Ray may not continue to maintain full backward compatibility even with the #version directive. We strongly encourage you to phase in 3.1 syntax as much as possible. Conditional Directives POV-Ray 3.0 allows a variety of new language directives to implement conditional parsing of various sections of your scene file. This is especially useful in describing the motion for animations but it has other uses as well. Also available is a #while loop directive. You may nest conditional directives 200 levels deep. The #if...#else...#end Directives The simplest conditional directive is a traditional #if XE "#if"  XE "#else"  XE "#end"  directive. It is of the form... IF_DIRECTIVE: #if ( Cond ) TOKENS... [#else TOKENS...] #end The TOKENS are any number of POV-Ray keyword, identifiers, or punctuation and ( Cond ) is a float expression that is interpreted as a boolean value. The parentheses are required. The #end directive is required. A value of 0.0 is false and any non-zero value is true. Note that extremely small values of about 1e-10 are considered zero in case of round off errors. If Cond is true, the first group of tokens is parsed normally and the second set is skipped. If false, the first set is skipped and the second set is parsed. For example: #declare Which=1; #if (Which) box{0,1} #else sphere{0,1} #end The box is parsed and the sphere is skipped. Changing the value of Which to 0 means the box is skipped and the sphere is used. The #else directive and second token group is optional. For example: #declare Which=1; #if (Which) box{0,1} #end Changing the value of Which to 0 means the box is removed. The #ifdef and #ifndef Directives The #ifdef XE "#ifdef"  and #ifndef XE "#ifndef"  directive are similar to the #if XE "#if"  directive however they is used to determine if an identifier has been previously declared. IFDEF_DIRECTIVE: #ifdef ( IDENTIFIER ) TOKENS... [#else TOKENS...] #end IFNDEF_DIRECTIVE: #ifndef ( IDENTIFIER ) TOKENS... [#else TOKENS...] #end If the IDENTIFIER exists then the first group of tokens is parsed normally and the second set is skipped. If false, the first set is skipped and the second set is parsed. This is especially useful for replacing an undefined item with a default. For example: #ifdef (User_Thing) // This section is parsed if the // identifier "User_Thing" was // previously declared object{User_Thing} // invoke identifier #else // This section is parsed if the // identifier "User_Thing" was not // previously declared box{<0,0,0>,<1,1,1>} // use a default #end // End of conditional part The #ifndef directive works the opposite. The first group is parsed if the identifier is not defined. As with the #if directive, the #else XE "#else"  clause is optional and the #end XE "#end"  directive is required. The #switch, #case, #range and #break Directives A more powerful conditional is the #switch XE "#switch"  directive. The syntax is as follows... SWITCH_DIRECTIVE: #switch ( Switch_Value ) SWITCH_CLAUSE... [#else TOKENS...] #end SWITCH_CLAUSE: #case( Case_Value ) TOKENS... [#break] | #range( Low_Value , High_Value ) TOKENS... [#break] The TOKENS are any number of POV-Ray keyword, identifiers, or punctuation and ( Switch_Value ) is a float expression. The parentheses are required. The #end XE "#end"  directive is required. The SWITCH_CLAUSE comes in two varieties. In the #case XE "#case"  variety, the float Switch_Value is compared to the float Case_Value. If they are equal, the condition is true. Note that values whose difference is less than 1e-10 are considered equal in case of round off errors. In the #range XE "#range"  variety, Low_Value Switch and High_Value are floats separated by a comma and enclosed in parentheses. If Low_Value <= Switch_Value and Switch_Value<=High_Value then the condition is true. In either variety, if the clause's condition is true, that clause's tokens are parsed normally and parsing continues until a #break XE "#break" , #else XE "#else"  or #end directive is reached. If the condition is false, POV-Ray skips until another #case or #range is found. There may be any number of #case or #range clauses in any order you want. If a clause evaluates true but no #break is specified, the parsing will fall through to the next #case or #range and that clause conditional is evaluated. Hitting #break while parsing a successful section causes an immediate jump to the #end without processing subsequent sections, even if a subsequent condition would also have been satisfied. An optional #else XE "#else"  clause may be the last clause. It is only executed if the clause before it was a false clause. Here is an example: #switch (VALUE) #case (TEST_1) // This section is parsed if VALUE=TEST_1 #break //First case ends #case (TEST_2) // This section is parsed if VALUE=TEST_2 #break //Second case ends #range (LOW_1,HIGH_1) // This section is parsed if (VALUE>=LOW_1)&(VALUE<=HIGH_1) #break //Third case ends #range (LOW_2,HIGH_2) // This section is parsed if (VALUE>=LOW_2)&(VALUE<=HIGH_2) #break //Fourth case ends #else // This section is parsed if no other case or // range is true. #end // End of conditional part The #while...#end Directive The #while XE "#while"  directive is a looping feature that makes it easy to place multiple objects in a pattern or other uses. WHILE_DIRECTIVE: #while ( Cond ) TOKENS... #end The TOKENS are any number of POV-Ray keyword, identifiers, or punctuation marks which are the body of the loop. The #while directive is followed by a float expression that evaluates to a boolean value. A value of 0.0 is false and any non-zero value is true. Note that extremely small values of about 1e-10 are considered zero in case of round off errors. The parentheses around the expression are required. If the condition is true parsing continues normally until an #end XE "#end"  directive is reached. At the end, POV-Ray loops back to the #while directive and the condition is re-evaluated. Looping continues until the condition fails. When it fails, parsing continues after the #end directive. Note it is possible for the condition to fail the first time and the loop is totally skipped. It is up to the user to insure that something inside the loop changes so that it eventually terminates. Here is a properly constructed loop example: #declare Count=0; #while (Count < 5) object{MyObject translate x*3*Count} #declare Count=Count+1; #end This example places five copies of MyObject in a row spaced three units apart in the x-direction. User Message Directives With the addition of conditional and loop directives, the POV-Ray language has the potential to be more like an actual programming language. This means that it will be necessary to have some way to see what is going on when trying to debug loops and conditionals. To fulfill this need we have added the ability to print text messages to the screen. You have a choice of five different text streams to use including the ability to generate a fatal error if you find it necessary. Limited formatting is available for strings output by this method. Text Message Streams The syntax for a text message is any of the following: TEXT_STREAM_DIRECTIVE: #debug XE "#debug"  STRING | #error XE "#error"  STRING | #render XE "#render"  STRING | #statistics XE "#statistics"  STRING | #warning XE "#warning"  STRING Where STRING is any valid string of text including string identifiers or functions which return strings. For example: #switch (clock*360) #range (0,180) #render "Clock in 0 to 180 range\n" #break #range (180,360) #render "Clock in 180 to 360 range\n" #break #else #warning "Clock outside expected range\n" #warning concat("Value is:",str(clock*360,5,0),"\n") #end There are seven distinct text streams that POV-Ray uses for output. You may output only to five of them. On some versions of POV-Ray, each stream is designated by a particular color. Text from these streams are displayed whenever it is appropriate so there is often an intermixing of the text. The distinction is only important if you choose to turn some of the streams off or to direct some of the streams to text files. On some systems you may be able to review the streams separately in their own scroll-back buffer. See " REF _Ref413328828 \h Directing Text Streams to Files" for details on re-directing the streams to a text file. Here is a description of how POV-Ray uses each stream. You may use them for whatever purpose you want except note that use of the #error XE "#error"  stream causes a fatal error after the text is displayed. Debug: XE "debug stream"  This stream displays debugging messages. It was primarily designed for developers but this and other streams may also be used by the user to display messages from within their scene files. Fatal:  XE "fatal stream" This stream displays fatal error messages. After displaying this text, POV-Ray will terminate. When the error is a scene parsing error, you may be shown several lines of scene text that leads up to the error. Render:  XE "render stream" This stream displays information about what options you have specified to render the scene. It includes feedback on all of the major options such as scene name, resolution, animation settings, anti-aliasing and others. Statistics:  XE "statistics stream" This stream displays statistics after a frame is rendered. It includes information about the number of rays traced, the length of time of the processing and other information. Warning:  XE "warning stream" This stream displays warning messages during the parsing of scene files and other warnings. Despite the warning, POV-Ray can continue to render the scene. The banner and status streams can not be accessed by the user. Text Formatting Some escape sequences are available to include non-printing control characters in your text. These sequences are similar to those used in string literals in the C programming language. The sequences are: "\a"Bell or alarm,0x07"\b"Backspace,0x08"\f"Form feed,0x0C"\n"New line (line feed)0x0A"\r"Carriage return0x0D"\t"Horizontal tab0x09"\v"Vertical tab0x0B"\0"Null0x00"\\"Backslash0x5C"\'"Single quote0x27"\""Double quote0x22For example: #debug "This is one line.\nBut this is another" Depending on what platform you are using, they may not be fully supported for console output. However they will appear in any text file if you re-direct a stream to a file. Note that most of these control characters only apply in text message directives and #write XE "#write"  directives which write strings They are not implemented for other string usage in POV-Ray such as text objects or file names. User Defined Macros New in POV-Ray 3.1 are user defined macros with parameters. This new feature, along with the ability to declare #local XE "#local"  variables, turns the POV-Ray Language into a fully functional programming language. It should now be possible to write scene generation utilities that previously required external utilities. The #macro Directive The syntax for declaring a macro is: MACRO_DEFINITION: #macro XE "#macro"  IDENTIFIER ( [PARAM_IDENT] [, PARAM_IDENT]... ) TOKENS... #end Where IDENTIFIER is the name of the macro and PARAM_IDENTs are a list of zero or more formal parameter identifiers separated by commas and enclosed by parentheses. The parentheses are required even if no parameters are specified. The TOKENS are any number of POV-Ray keyword, identifiers, or punctuation marks which are the body of the macro. The body of the macro may contain almost any POV-Ray syntax items you desire. It is terminated my the #end XE "#end"  directive. Note however that any conditional directives such as #if XE "#if" ...#end, #while XE "#while" ...#end, etc. must be fully nested inside or outside the macro so that the corresponding #end directives pair-up properly. Also you may not nest macro declarations. A macro must be declared before it is invoked. All macro names are global in scope and permanent in duration. You may redefine a macro by another #macro directive with the same name. The previous definition is lost. Macro names respond to #ifdef XE "#ifdef" , #ifndef XE "#ifndef" , and #undef XE "#undef"  directives. See " REF _Ref413241864 \h The #ifdef and #ifndef Directives" and " REF _Ref413339194 \h Destroying Identifiers with #undef". Invoking Macros You invoke the macro by specifying the macro name followed by a list of zero or more actual parameters enclosed in parentheses and separated by commas. The number of actual parameters must match the number of formal parameters in the definition. The parentheses are required even if no parameters are specified. The syntax is: MACRO_INVOCATION: MACRO_IDENTIFIER ( [ACTUAL_PARAM] [, ACTUAL_PARAM]... ) ACTUAL_PARAM: IDENTIFIER | RVALUE An RVALUE is any value that can legally appear to the right of an equals sign in a #declare XE "#declare"  or #local XE "#local"  declaration. See " REF _Ref413339528 \h Declaring identifiers" for information on RVALUEs. When the macro is invoked, a new local symbol table is created. The actual parameters are assigned to formal parameter identifiers as local, temporary variables. POV-Ray jumps to the body of the macro and continues parsing until the matching #end XE "#end"  directive is reached. There, the local variables created by the parameters are destroyed as well as any local identifiers expressly created in the body of the macro. It then resumes parsing at the point where the macro was invoked. It is as though the body of the macro was cut and pasted into the scene at the point where the macro was invoked. Here is a simple macro that creates a window frame object when you specify the inner and outer dimensions. #macro Make_Frame (OuterWidth,OuterHeight,InnerWidth,InnerHeight,Depth) #local Horz = (OuterHeight-InnerHeight)/2; #local Vert = (OuterWidth-InnerWidth)/2; difference { box{<0,0,0>,} box{,} } #end Make_Frame(8,10,7,9,1) //invoke the macro In this example, the macro has five float parameters. The actual parameters (the values 8, 10, 7, 9, and 1) are assigned to the five identifiers in the #macro formal parameter list. It is as though you had used the following five lines of code. #local OuterWidth = 8; #local OuterHeight = 10; #local InnerWidth, = 7; #local InnerHeight = 9; #local Depth = 1; These five identifiers are stored in the same symbol table as any other local identifier such as Horz or Vert in this example. The parameters and local variables are all destroyed when the #end statement is reached. See " REF _Ref413404001 \h Identifier Name Collisions" for a detailed discussion of how local identifiers, parameters, and global identifiers work when a local identifier has the same name as a previously declared identifier. Are POV-Ray Macros a Function or a Macro? POV-Ray macros are a strange mix of macros and functions. In traditional computer programming languages, a macro works entirely by token substitution. The body of the routine is inserted into the invocation point by simply copying the tokens and parsing them as if they had been cut and pasted in place. Such cut-and-paste substitution is often called macro substitution because it is what macros are all about. In this respect, POV-Ray macros are exactly like traditional macros in that they use macro substitution for the body of the macro. However traditional macros also use this cut-and-paste substitution strategy for parameters but POV-Ray does not. Suppose you have a macro in the C programming language Typical_Cmac(Param) and you invoke it as Typical_Cmac(else A=B). Anywhere that Param appears in the macro body, the four tokens else, A, =, and B are substituted into the program code using a cut-and-paste operation. No type checking is performed because anything is legal. The ability to pass an arbitrary group of tokens via a macro parameter is a powerful (and sadly often abused) feature of traditional macros. After careful deliberation, we have decided against this type of parameters for our macros. The reason is that POV-Ray uses commas more frequently in its syntax than do most programming languages. Suppose you create a macro that is designed to operate on one vector and two floats. It might be defined OurMac(V,F1,F2). If you allow arbitrary strings of tokens and invoke a macro such as OurMac(<1,2,3>,4,5) then it is impossible to tell if this is a vector and two floats or if its 5 parameters with the two tokens < and 1 as the first parameter. If we design the macro to accept 5 parameters then we cannot invoke it like this... OurMac(MyVector,4,5). Function parameters in traditional programming languages do not use token substitution to pass values. They create temporary, local variables to store parameters that are either constant values or identifier references which are in effect a pointer to a variable. POV-Ray macros use this function-like system for passing parameters to its macros. In our example OurMac(<1,2,3>,4,5), POV-Ray sees the < and knows it must be the start of a vector. It parses the whole vector expression and assigns it to the first parameter exactly as though you had used the statement #local V=<1,2,3>;. Although we say that POV-Ray parameters are more like traditional function parameters than macro parameters, there still is one difference. Most languages require you to declare the type of each parameter in the definition before you use it but POV-Ray does not. This should be no surprise because Most languages require you to declare the type of any identifier before you use it but POV-Ray does not. This means that if you pass the wrong type value in a POV-Ray macro parameter, it may not generate an error until you reference the identifier in the macro body. No type checking is performed as the parameter is passed. So in this very limited respect, POV-Ray parameters are somewhat macro-like but are mostly function-like. Returning a Value Like a Function POV-Ray macros have a variety of uses. Like most macros, they provide a parameterized way to insert arbitrary code into a scene file. However most POV-Ray macros will be used like functions or procedures in a traditional programming language. This is especially true because the POV-Ray language has no user-defined functions or procedures. Macros are designed to fill all of these roles. When the body of a macro consists of statements that create an entire item such as an object, texture, etc. then the macro acts like a function which returns a single value. The Make_Frame macro example in the section " REF _Ref413414330 \h Invoking Macros" above is such a macro which returns a value that is an object. Here are some examples of how you might invoke it. union { //make a union of two objects object{ Make_Frame(8,10,7,9,1) translate 20*x} object{ Make_Frame(8,10,7,9,1) translate -20*x} } #declare BigFrame = object{ Make_Frame(8,10,7,9,1)} #declare SmallFrame = object{ Make_Frame(5,4,4,3,0.5)} Because no type checking is performed on parameters and because the expression syntax for floats, vectors, and colors is identical, you can create clever macros which work on all three. See the sample scene MACRO3.POV which includes this macro to interpolate values. // Define the macro. Parameters are: // T: Middle value of time // T1: Initial time // T2: Final time // P1: Initial position (may be float, vector or color) // P2: Final position (may be float, vector or color) // Result is a value between P1 and P2 in the same proportion // as T is between T1 and T2. #macro Interpolate(T,T1,T2,P1,P2) (P1+(T1+T/(T2-T1))*(P2-P1)) #end You might invoke it with P1 and P2 as floats, vectors, or colors as follows. sphere{ Interpolate(I,0,15,<2,3,4>,<9,8,7>), //center location is vector Interpolate(I,0,15,3.0,5.5) //radius is float pigment{ color Interpolate(I,0,15,rgb<1,1,0>,rgb<0,1,1>) } } As the float value I varies from 0 to 15, the location, radius, and color of the sphere vary accordingly. There is a danger in using macros as functions. In a traditional programming language function, the result to be returned is actually assigned to a temporary variable and the invoking code treats it as a variable of a given type. However macro substitution may result in invalid or undesired syntax. Note the definition of the macro Interpolate above has an outermost set of parentheses. If those parentheses are omitted, it will not matter in the examples above, but what if you do this... #declare Value = Interpolate(I,0,15,3.0,5.5)*15; The end result is as if you had done... #declare Value = P1+(T1+T/(T2-T1))*(P2-P1) * 15; which is syntactically legal but not mathematically correct because the P1 term is not multiplied. The parentheses in the original example solves this problem. The end result is as if you had done... #declare Value = (P1+(T1+T/(T2-T1))*(P2-P1)) * 15; which is correct. Returning Values Via Parameters Sometimes it is necessary to have a macro return more than one value or you may simply prefer to return a value via a parameter as is typical in traditional programming language procedures. POV-Ray macros are capable of returning values this way. The syntax for POV-Ray macro parameters says that the actual parameter may be an IDENTIFIER or an RVALUE. Values may only be returned via a parameter if the parameter is an IDENTIFIER. Parameters that are RVALUES are constant values that cannot return information. An RVALUE is anything that legally may appear to the right of an equals sign in a #declare XE "#declare"  or #local XE "#local"  directive. For example consider the following trivial macro which rotates an object about the x-axis. #macro Turn_Me(Stuff,Degrees) #declare Stuff = object{Stuff rotate x*Degrees} #end This attempts to re-declare the identifier Stuff as the rotated version of the object. However the macro might be invoked with Turn_Me(box{0,1},30) which uses a box object as an RVALUE parameter. This won't work because the box is not an identifier. You can however do this #declare MyObject=box{0,1} Turn_Me(MyObject,30) The identifier MyObject now contains the rotated box. See " REF _Ref413404001 \h Identifier Name Collisions" for a detailed discussion of how local identifiers, parameters, and global identifiers work when a local identifier has the same name as a previously declared identifier. While it is obvious that MyObject is an identifier and box{0,1} is not, it should be noted that Turn_Me(object{MyObject},30) will not work because object{MyObject} is considered an object statement and is not a pure identifier. This mistake is more likely to be made with float identifiers verses float expressions. Consider these examples. #declare Value=5.0; MyMacro(Value) //MyMacro can change the value of Value but... MyMacro(+Value) //This version and the rest are not lone MyMacro(Value+0.0) // identifiers. They are float expressions MyMacro(Value*1.0) // which cannot be changed. Although all four invocations of MyMacro are passed the value 5.0, only the first may modify the value of the identifier. POV-Ray Coordinate System Objects, lights and the camera are positioned using a typical 3D coordinate system. The usual coordinate system for POV-Ray has the positive y-axis pointing up, the positive x-axis pointing to the right and the positive z-axis pointing into the screen. The negative values of the axes point the other direction as shown in the images in section " REF _Ref413502879 \h Understanding POV-Ray's Coordinate System". Locations within that coordinate system are usually specified by a three component vector. The three values correspond to the x, y and z directions respectively. For example, the vector <1,2,3> means the point that's one unit to the right, two units up and three units in front of the center of the universe at <0,0,0>. Vectors are not always points though. They can also refer to an amount to size, move or rotate a scene element or to modify the texture pattern applied to an object. The size, location, orientation, and deformation of items within the coordinate system is controlled by modifiers called transformations. The follow sub-sections describe the transformations and their usage. Transformations The supported transformations are rotate XE "rotate" , scale XE "scale" , and translate XE "translate" . They are used to turn, size and move an object or texture.  XE "matrix" A transformation matrix may also be used to specify complex transformations directly. Groups of transformations may be merged together and stored in a  XE "transform" transformation identifier. The syntax for transformations is as follows. TRANSFORMATION: rotate | scale | translate | transform TRANSFORM_IDENTIFIER | matrix TRANSFORM_DECLARATION: #declare IDENTIFIER = transform{ TRANSFORMATION... } | #local IDENTIFIER = transform{ TRANSFORMATION... } Translate Items may be moved by adding a translate XE "translate"  modifier. It consists of the keyword translate followed by a vector expression. The three terms of the vector specify the number of units to move in each of the x, y and z directions. Translate moves the element relative to it's current position. For example sphere { <10, 10, 10>, 1 pigment { Green } translate <-5, 2, 1> } will move the sphere from the location <10,10,10> to <5,12,11>. It does not move it to the absolute location <-5,2,1>. Translations are always relative to the item's location before the move. Translating by zero will leave the element unchanged on that axis. For example: sphere { <10, 10, 10>, 1 pigment { Green } translate 3*x // evaluates to <3,0,0> so move 3 units // in the x direction and none along y or z } Scale You may change the size of an object or texture pattern by adding a scale XE "scale"  modifier. It consists of the keyword scale followed by a vector expression. The three terms of the vector specify the amount of scaling in each of the x, y and z directions. Uneven scaling is used to stretch or squish an element. Values larger than one stretch the element on that axis while values smaller than one are used to squish it. Scale is relative to the current element size. If the element has been previously re-sized using scale then scale will size relative to the new size. Multiple scale values may used. For example sphere { <0,0,0>, 1 scale <2,1,0.5> } will stretch and smash the sphere into an ellipsoid shape that is twice the original size along the x-direction, remains the same size in the y-direction and is half the original size in the z-direction. If a lone float expression is specified it is promoted to a three component vector whose terms are all the same. Thus the item is uniformly scaled by the same amount in all directions. For example: object { MyObject scale 5 // Evaluates as <5,5,5> so uniformly scale // by 5 in every direction. } Rotate You may change the orientation of an object or texture pattern by adding a rotate XE "rotate"  modifier. It consists of the keyword rotate followed by a vector expression. The three terms of the vector specify the number of degrees to rotate about each of the x-, y- and z-axes. Note that the order of the rotations does matter. Rotations occur about the x-axis first, then the y-axis, then the z-axis. If you are not sure if this is what you want then you should only rotate on one axis at a time using multiple rotation statements to get a correct rotation. As in rotate <0, 30, 0> // 30 degrees around Y axis then, rotate <-20, 0, 0> // -20 degrees around X axis then, rotate <0, 0, 10> // 10 degrees around Z axis. Rotation is always performed relative to the axis. Thus if an object is some distance from the axis of rotation it will not only rotate but it will orbit about the axis as though it was swinging around on an invisible string. POV-Ray uses a left-handed rotation system. Using the famous "Computer Graphics Aerobics" exercise, you hold up your left hand and point your thumb in the positive direction of the axis of rotation. Your fingers will curl in the positive direction of rotation. Similarly if you point your thumb in the negative direction of the axis your fingers will curl in the negative direction of rotation. See " REF _Ref413506445 \h Understanding POV-Ray's Coordinate System" for a illustration. Matrix Keyword The matrix XE "matrix"  keyword can be used to explicitly specify the transformation matrix to be used for objects or textures. Its syntax is: MATRIX: matrix XE "matrix"  Where Val00 through Val32 are float expressions enclosed in angle brackets and separated by commas. Note this is not a vector. It is a set of 12 float expressions. These floats specify the elements of a 4 by 4 matrix with the fourth column implicitly set to <0,0,0,1>. At any given point P, P=, is transformed into the point Q, Q= by qx = Val00 * px + Val10 * py + Val20 * pz + Val30 qy = Val01 * px + Val11 * py + Val21 * pz + Val31 qz = Val02 * px + Val12 * py + Val22 * pz + Val32 Normally you won't use the matrix keyword because it's less descriptive than the transformation commands and harder to visualize. However the matrix command allows more general transformation effects like shearing XE "shearing" . The following matrix causes an object to be sheared along the y-axis. object { MyObject matrix < 1, 1, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0 > } Transformation Order Because rotations are always relative to the axis and scaling is relative to the origin, you will generally want to create an object at the origin and scale and rotate it first. Then you may translate it into its proper position. It is a common mistake to carefully position an object and then to decide to rotate it. However because a rotation of an object causes it to orbit about the axis, the position of the object may change so much that it orbits out of the field of view of the camera! Similarly scaling after translation also moves an object unexpectedly. If you scale after you translate the scale will multiply the translate amount. For example translate <5, 6, 7> scale 4 will translate to <20,24,28> instead of <5,6,7>. Be careful when transforming to get the order correct for your purposes. Transform Identifiers  XE "#declare"  XE "#local" At times it is useful to combine together several transformations and apply them in multiple places. A transform identifier may be used for this purpose. Transform identifiers are declared as follows: TRANSFORM_DECLARATION: #declare IDENTIFIER = transform{ TRANSFORMATION... } | #local IDENTIFIER = transform{ TRANSFORMATION... } Where IDENTIFIER is the name of the identifier up to 40 characters long and TRANSFORMATION is any valid transformation modifier. See " REF _Ref412711267 \h #declare vs. #local" for information on identifier scope. Here is an example... #declare MyTrans = transform { rotate ThisWay scale SoMuch rotate -ThisWay scale Bigger translate OverThere rotate WayAround } A transform identifier is invoked by the transform XE "transform"  keyword without any brackets as shown here: object { MyObject // Get a copy of MyObject transform MyTrans // Apply the transformation translate -x*5 // Then move it 5 units left } object { MyObject // Get another copy of MyObject transform MyTrans // Apply the same transformation translate x*5 // Then move this one 5 units right } On extremely complex CSG objects with lots of components it may speed up parsing if you apply a declared transformation rather than the individual translate XE "translate" , rotate XE "rotate" , scale XE "scale" , or matrix XE "matrix"  modifiers. The transform is attached just once to each component. Applying each individual translate, rotate, scale, or matrix modifiers takes longer. This only affects parsing - rendering works the same either way. Transforming Textures and Objects When an object is transformed all textures attached to the object at that time are transformed as well. This means that if you have a translate XE "translate" , rotate XE "rotate" , scale XE "scale" , or matrix XE "matrix"  modifier in an object before a texture, then the texture will not be transformed. If the transformation is after the texture then the texture will be transformed with the object. If the transformation is inside the texture XE "texture"  statement then only the texture is affected. The shape remains the same. For example: sphere { 0, 1 texture { Jade } // texture identifier from TEXTURES.INC scale 3 // this scale affects both the // shape and texture } sphere { 0, 1 scale 3 // this scale affects the shape only texture { Jade } } sphere { 0, 1 texture { Jade scale 3 // this scale affects the texture only } } Transformations may also be independently applied to pigment patterns and surface normal patterns. Note that scaling a normal pattern affects only the width and spacing. It does not affect the apparent height or depth of the bumps. For example: box { <0, 0, 0>, <1, 1, 1> texture { pigment { checker Red, White scale 0.25 // This affects only the color pattern } normal { bumps 0.3 // This specifies apparent height of bumps scale 0.2 // Scales diameter and space between bumps // but not the height. Has no effect on // color pattern. } rotate y*45 // This affects the entire texture but } // not the object. } Camera The camera definition describes the position, projection type and properties of the camera viewing the scene. Its syntax is: CAMERA: camera{ [CAMERA_ITEMS...] } CAMERA_ITEM: CAMERA_TYPE | CAMERA_VECTOR | CAMERA_MODIFIER | CAMERA_IDENTIFIER CAMERA_TYPE: perspective | orthographic | fisheye | ultra_wide_angle | omnimax | panoramic | cylinder CylinderType CAMERA_VECTOR: location | right | up | direction | sky CAMERA_MODIFIER: angle Degrees | look_at | blur_samples Num_of_Samples | aperture Size | focal_point | confidence Blur_Confidence | varience Blur_Varience | NORMAL | TRANSFORMATION Depending on the projection type some of the parameters are required, some are optional and some aren't used. If no projection type is given the perspective camera will be used (pinhole camera). If no camera is specified a default camera is used. CAMERA_ITEMs may legally appear in any order but the order of some items is critical to the proper functioning of the camera. Follow the guidelines in this document closely because POV-Ray will not stop you from making mistakes. Placing the Camera The POV-Ray camera has ten different models, each of which uses a different projection method to project the scene onto your screen. Regardless of the projection type all cameras use the location XE "location" , right XE "right" , up XE "up" , direction XE "direction" , and keywords to determine the location and orientation of the camera. The type keywords and these four vectors fully define the camera. All other camera modifiers adjust how the camera does its job. The meaning of these vectors and other modifiers differ with the projection type used. A more detailed explanation of the camera types follows later. In the sub-sections which follows, we explain how to place and orient the camera by the use of these four vectors and the sky XE "sky"  and look_at XE "look_at"  modifiers. You may wish to refer to the illustration of the perspective camera below as you read about these vectors.  The perspective camera. Location and Look_At Under many circumstances just two vectors in the camera statement are all you need to position the camera: location XE "location"  and look_at XE "look_at"  vectors. For example: camera { location <3,5,-10> look_at <0,2,1> } The location is simply the x, y, z coordinates of the camera. The camera can be located anywhere in the ray-tracing universe. The default location is <0,0,0>. The look_at XE "look_at"  vector tells POV-Ray to pan and tilt the camera until it is looking at the specified x, y, z coordinates. By default the camera looks at a point one unit in the z-direction from the location. The look_at modifier should almost always be the last item in the camera statement. If other camera items are placed after the look_at vector then the camera may not continue to look at the specified point. The Sky Vector Normally POV-Ray pans left or right by rotating about the y-axis until it lines up with the look_at XE "look_at"  point and then tilts straight up or down until the point is met exactly. However you may want to slant the camera sideways like an airplane making a banked turn. You may change the tilt of the camera using the sky XE "sky"  vector. For example: camera { location <3,5,-10> sky <1,1,0> look_at <0,2,1> } This tells POV-Ray to roll the camera until the top of the camera is in line with the sky vector. Imagine that the sky vector is an antenna pointing out of the top of the camera. Then it uses the sky vector as the axis of rotation left or right and then to tilt up or down in line with the sky until pointing at the look_at point. In effect you're telling POV-Ray to assume that the sky isn't straight up. Note that the sky vector must appear before the look_at vector. The sky vector does nothing on its own. It only modifies the way the look_at vector turns the camera. The default value is sky<0,1,0>. Angle The angle XE "angle"  keyword followed by a float expression specifies the (horizontal) viewing angle in degrees of the camera used. Even though it is possible to use the direction XE "direction"  vector to determine the viewing angle for the perspective camera it is much easier to use the angle XE "angle"  keyword. When you specify the angle, POV-Ray adjusts the length of the direction vector accordingly. The formula used is direction_length = 0.5 * right_length / tan(angle / 2) where right_length is the length of the right XE "right"  vector. You should therefore specify the direction and right vectors before the angle keyword. The right vector is explained in the next section. There is no limitation to the viewing angle except for the perspective projection. If you choose viewing angles larger than 360 degrees you'll see repeated images of the scene (the way the repetition takes place depends on the camera). This might be useful for special effects. The Direction Vector You will probably not need to explicitly specify or change the camera direction XE "direction"  vector but it is described here in case you do. It tells POV-Ray the initial direction to point the camera before moving it with the look_at XE "look_at"  or rotate XE "rotate"  vectors (the default value is direction<0,0,1>). It may also be used to control the (horizontal) field of view with some types of projection. The length of the vector determines the distance of the viewing plane from the camera's location. A shorter direction vector gives a wider view while a longer vector zooms in for close-ups. In early versions of POV-Ray, this was the only way to adjust field of view. However zooming should now be done using the easier to use angle XE "angle"  keyword. If you are using the ultra_wide_angle XE "ultra_wide_angle" , panoramic XE "panoramic" , or cylindrical XE "cylindrical"  projection you should use a unit length direction vector to avoid strange results. The length of the direction XE "direction"  vector doesn't matter when using the orthographic XE "orthographic" , fisheye XE "fisheye" , or omnimax XE "omnimax"  projection types. Up and Right Vectors The primary purpose of the up XE "up"  and right XE "right"  vectors is to tell POV-Ray the relative height and width of the view screen. The default values are: right 4/3*x up y In the default perspective XE "perspective"  camera, these two vectors also define the initial plane of the view screen before moving it with the look_at XE "look_at"  or rotate XE "rotate"  vectors. The length of the right vector (together with the direction XE "direction"  vector) may also be used to control the (horizontal) field of view with some types of projection. The look_at XE "look_at"  modifier changes both up and right so you should always specify them before look_at. Also the angle calculation depends on the right vector so right should precede it. Most camera types treat the up and right vectors the same as the perspective type. However several make special use of them. In the orthographic XE "orthographic"  projection: The lengths of the up and right vectors set the size of the viewing window regardless of the direction vector length, which is not used by the orthographic camera. When using cylindrical XE "cylindrical"  projection: types 1 and 3, the axis of the cylinder lies along the up vector and the width is determined by the length of right vector or it may be overridden with the angle vector. In type 3 the up vector determines how many units high the image is. For example if you have up 4*y on a camera at the origin. Only points from y=2 to y=-2 are visible. All viewing rays are perpendicular to the y-axis. For type 2 and 4, the cylinder lies along the right vector. Viewing rays for type 4 are perpendicular to the right vector. Note that the up, right, and direction vectors should always remain perpendicular to each other or the image will be distorted. If this is not the case a warning message will be printed. The vista buffer will not work for non-perpendicular camera vectors. If you specify the 3 vectors as initially perpendicular and do not explicitly re-specify the after any look_at XE "look_at"  or rotate XE "rotate"  vectors, the everything will work fine. Aspect Ratio Together the up and right vectors define the aspect ratio (height to width ratio) of the resulting image. The default values up<0,1,0> and right<1.33,0,0> result in an aspect ratio of 4 to 3. This is the aspect ratio of a typical computer monitor. If you wanted a tall skinny image or a short wide panoramic image or a perfectly square image you should adjust the up and right vectors to the appropriate proportions. Most computer video modes and graphics printers use perfectly square pixels. For example Macintosh displays and IBM SVGA modes 640x480, 800x600 and 1024x768 all use square pixels. When your intended viewing method uses square pixels then the width and height you set with the Width XE "Width"  and Height XE "Height"  options or +W or +H XE "+H"  switches should also have the same ratio as the up and right vectors. Note that 640/480 = 4/3 so the ratio is proper for this square pixel mode. Not all display modes use square pixels however. For example IBM VGA mode 320x200 and Amiga 320x400 modes do not use square pixels. These two modes still produce a 4/3 aspect ratio image. Therefore images intended to be viewed on such hardware should still use 4/3 ratio on their up and right vectors but the pixel settings will not be 4/3. For example: camera { location <3,5,-10> up <0,1,0> right <1,0,0> look_at <0,2,1> } This specifies a perfectly square image. On a square pixel display like SVGA you would use pixel settings such as +W480 +H480 or +W600 +H600. However on the non-square pixel Amiga 320x400 mode you would want to use values of +W240 +H400 to render a square image. The bottom line issue is this: the up and right vectors should specify the artist's intended aspect ratio for the image and the pixel settings should be adjusted to that same ratio for square pixels and to an adjusted pixel resolution for non-square pixels. The up and right vectors should not be adjusted based on non-square pixels. Handedness The right XE "right"  vector also describes the direction to the right of the camera. It tells POV-Ray where the right side of your screen is. The sign of the right vector can be used to determine the handedness of the coordinate system in use. The default value is: right<1.33,0,0>. This means that the +x-direction is to the right. It is called a left-handed system because you can use your left hand to keep track of the axes. Hold out your left hand with your palm facing to your right. Stick your thumb up. Point straight ahead with your index finger. Point your other fingers to the right. Your bent fingers are pointing to the +x-direction. Your thumb now points into +y-direction. Your index finger points into the +z-direction. To use a right-handed coordinate system, as is popular in some CAD programs and other ray-tracers, make the same shape using your right hand. Your thumb still points up in the +y-direction and your index finger still points forward in the +z-direction but your other fingers now say the +x-direction is to the left. That means that the right side of your screen is now in the -x-direction. To tell POV-Ray to act like this you can use a negative x value in the right vector such as: right<-1.33,0,0>. Since having x values increasing to the left doesn't make much sense on a 2D screen you now rotate the whole thing 180 degrees around by using a positive z value in your camera's location. You end up with something like this. camera { location <0,0,10> up <0,1,0> right <-1.33,0,0> look_at <0,0,0> } Now when you do your ray-tracer's aerobics, as explained in the section " REF _Ref413593367 \h Understanding POV-Ray's Coordinate System", you use your right hand to determine the direction of rotations. In a two dimensional grid, x is always to the right and y is up. The two versions of handedness arise from the question of whether z points into the screen or out of it and which axis in your computer model relates to up in the real world. Architectural CAD systems, like AutoCAD, tend to use the God's Eye orientation that the z-axis is the elevation and is the model's up direction. This approach makes sense if you're an architect looking at a building blueprint on a computer screen. z means up, and it increases towards you, with x and y still across and up the screen. This is the basic right handed system. Stand alone rendering systems, like POV-Ray, tend to consider you as a participant. You're looking at the screen as if you were a photographer standing in the scene. The up direction in the model is now y, the same as up in the real world and x is still to the right, so z must be depth, which increases away from you into the screen. This is the basic left handed system. Transforming the Camera The various transformations such as translate XE "translate"  and rotate XE "rotate"  modifiers can re-position the camera once you've defined it. For example: camera { location < 0, 0, 0> direction < 0, 0, 1> up < 0, 1, 0> right < 1, 0, 0> rotate <30, 60, 30> translate < 5, 3, 4> } In this example, the camera is created, then rotated by 30 degrees about the x-axis, 60 degrees about the y-axis and 30 degrees about the z-axis, then translated to another point in space. Types of Projection The following list explains the different projection types that can be used with the camera. The most common types are the perspective and orthographic projections. In general the CAMERA_TYPE should be the first item in a camera XE "camera"  statement. If none is specified, the perspective XE "perspective"  camera is the default. Perspective projection: The perspective specifies the default perspective camera which simulates the classic pinhole camera. The (horizontal) viewing angle is either determined by the ratio between the length of the direction XE "direction"  vector and the length of the right XE "right"  vector or by the optional keyword angle XE "angle" , which is the preferred way. The viewing angle has to be larger than 0 degrees and smaller than 180 degrees. See the figure in " REF _Ref413677066 \h Placing the Camera" for the geometry of the perspective camera.  XE "orthographic" Orthographic projection: This projection uses parallel camera rays to create an image of the scene. The size of the image is determined by the lengths of the right and up XE "up"  vectors. If you add the orthographic keyword after all other parameters of a perspective camera you'll get an orthographic view with the same image area, i.e. the size of the image is the same. In this case you needn't specify the lengths of the right and up vector because they'll be calculated automatically. You should be aware though that the visible parts of the scene change when switching from perspective to orthographic view. As long as all objects of interest are near the look_at XE "look_at"  point they'll be still visible if the orthographic camera is used. Objects farther away may get out of view while nearer objects will stay in view.  XE "fisheye" Fisheye projection: This is a spherical projection. The viewing angle is specified by the angle keyword. An angle of 180 degrees creates the "standard" fisheye while an angle of 360 degrees creates a super-fisheye ("I-see-everything-view"). If you use this projection you should get a circular image. If this isn't the case, i.e. you get an elliptical image, you should read " REF _Ref413677452 \h Aspect Ratio". Ultra wide angle projection: This projection is somewhat similar to the fisheye but it projects the image onto a rectangle instead of a circle. The viewing angle can be specified using the angle keyword.  XE "omnimax" Omnimax projection: The omnimax projection is a 180 degrees fisheye that has a reduced viewing angle in the vertical direction. In reality this projection is used to make movies that can be viewed in the dome-like Omnimax theaters. The image will look somewhat elliptical. The angle keyword isn't used with this projection.  XE "panoramic" Panoramic projection: This projection is called "cylindrical equirectangular projection". It overcomes the degeneration problem of the perspective projection if the viewing angle approaches 180 degrees. It uses a type of cylindrical projection to be able to use viewing angles larger than 180 degrees with a tolerable lateral-stretching distortion. The angle keyword is used to determine the viewing angle.  XE "cylindrical" Cylindrical projection: Using this projection the scene is projected onto a cylinder. There are four different types of cylindrical projections depending on the orientation of the cylinder and the position of the viewpoint. A float value in the range 1 to 4 must follow the cylinder keyword. The viewing angle and the length of the up or right vector determine the dimensions of the camera and the visible image. The camera to use is specified by a number. The types are: 1vertical cylinder, fixed viewpoint2horizontal cylinder, fixed viewpoint3vertical cylinder, viewpoint moves along the cylinder's axis4horizontal cylinder, viewpoint moves along the cylinder's axisYou should note that the vista buffer can only be used with the perspective and orthographic camera. Focal Blur POV-Ray can simulate focal depth-of-field by shooting a number of sample rays from jittered points within each pixel and averaging the results. To turn on focal blur, you must specify the aperture XE "aperture"  keyword followed by a float value which determines the depth of the sharpness zone. Large apertures give a lot of blurring, while narrow apertures will give a wide zone of sharpness. Note that, while this behaves as a real camera does, the values for aperture are purely arbitrary and are not related to f-stops. You must also specify the blur_samples XE "blur_samples"  keyword followed by an integer value specifying the maximum number of rays to use for each pixel. More rays give a smoother appearance but is slower. By default no focal blur is used, i. e. the default aperture is 0 and the default number of samples is 0. The center of the zone of sharpness is specified by the focal_point XE "focal_point"  vector. Objects close to this point are in focus and those farther from that point are more blurred. The default value is focal_point<0,0,0>. Although blur_samples specifies the maximum number of samples, there is an adaptive mechanism that stops shooting rays when a certain degree of confidence has been reached. At that point, shooting more rays would not result in a significant change. The confidence XE "confidence"  and variance XE "variance"  keywords are followed by float values to control the adaptive function. The confidence value is used to determine when the samples seem to be close enough to the correct color. The variance value specifies an acceptable tolerance on the variance of the samples taken so far. In other words, the process of shooting sample rays is terminated when the estimated color value is very likely (as controlled by the confidence probability) near the real color value. Since the confidence is a probability its values can range from 0 to 1 (the default is 0.9, i. e. 90%). The value for the variance should be in the range of the smallest displayable color difference (the default is 1/128). Larger confidence values will lead to more samples, slower traces and better images. The same holds for smaller variance thresholds. Camera Ray Perturbation The optional normal XE "normal"  may be used to assign a normal pattern to the camera. For example: camera{ location Here look_at There normal{bumps 0.5} } All camera rays will be perturbed using this pattern. The image will be distorted as though you were looking through bumpy glass or seeing a reflection off of a bumpy surface. This lets you create special effects. See the animated scene camera2.pov for an example. See " REF _Ref413681462 \h Normal" for information on normal patterns. Camera Identifiers  XE "#declare" Camera identifiers may be declared to make scene files more readable and to parameterize scenes so that changing a single declaration changes many values. You may declare several camera identifiers if you wish. This makes it easy to quickly change cameras. An identifier is declared as follows. CAMERA_DECLARATION: #declare IDENTIFIER = CAMERA | #local IDENTIFIER = CAMERA Where IDENTIFIER is the name of the identifier up to 40 characters long and CAMERA is any valid camera statement. See " REF _Ref412711267 \h #declare vs. #local" for information on identifier scope. Here is an example... #declare Long_Lens = camera { location -z*100 angle 3 } #declare Short_Lens = camera { location -z*50 angle 15 } camera { Long_Lens // edit this line to change lenses look_at Here } Objects  XE "objects" Objects are the building blocks of your scene. There are a lot of different types of objects supported by POV-Ray. In the sections which follow, we describe " REF _Ref413745376 \h Finite Solid Primitives", " REF _Ref413745425 \h Finite Patch Primitives", " REF _Ref413745485 \h Infinite Solid Primitives", and " REF _Ref413745531 \h Light Sources". These primitive shapes may be combined into complex shapes using " REF _Ref413745643 \h Constructive Solid Geometry" or CSG. The basic syntax of an object is a keyword describing its type, some floats, vectors or other parameters which further define its location and/or shape and some optional object modifiers such as texture, pigment, normal, finish, interior, bounding, clipping or transformations. Specifically the syntax is: OBJECT: FINITE_SOLID_OBJECT | FINITE_PATCH_OBJECT | INFINITE_SOLID_OBJECT | CSG_OBJECT | LIGHT_SOURCE | object { OBJECT_IDENTIFIER [OBJECT_MODIFIERS...] } FINITE_SOLID_OBJECT: BLOB | BOX | CONE | CYLINDER | HEIGHT_FIELD | JULIA_FRACTAL | LATHE | PRISM | SPHERE | SUPERELLIPSOID | SOR | TEXT | TORUS FINITE_PATCH_OBJECT: BICUBIC_PATCH | DISC | MESH | POLYGON | TRIANGLE | SMOOTH_TRIANGLE INFINITE_SOLID_OBJECT: PLANE | POLY | CUBIC | QUARTIC | QUADRIC CSG_OBJECT: UNION | INTERSECTION | DIFFERENCE | MERGE Object identifiers may be declared to make scene files more readable and to parameterize scenes so that changing a single declaration changes many values. An identifier is declared as follows. OBJECT_DECLARATION: #declare IDENTIFIER = OBJECT | #local IDENTIFIER = OBJECT Where IDENTIFIER is the name of the identifier up to 40 characters long and OBJECT is any valid object. Note that to invoke an object identifier, you wrap it in an object{...} statement. You use the object statement regardless of what type of object it originally was. Although early versions of POV-Ray required this object wrapper all of the time, now it is only used with OBJECT_IDENTIFIERS. Object modifiers are covered in detail later. However here is a brief overview. The texture XE "texture"  describes the surface properties of the object. Complete details are in " REF _Ref416274068 \h Textures". Textures are combinations of pigments, normals, and finishes. In the section " REF _Ref417128795 \h Pigment" you'll learn how to specify the color or pattern of colors inherent in the. In " REF _Ref417128833 \h Normal" we describe a method of simulating various patterns of bumps, dents, ripples or waves by modifying the surface normal vector. The section on " REF _Ref417128880 \h Finish" describes the reflective properties of the surface. The " REF _Ref417128927 \h Interior" is a new feature in POV-Ray 3.1. It contains information about the interior of the object which was formerly contained in the finish and halo parts of a texture. Interior items are no longer part of the texture. Instead, they attach directly to the objects. The halo feature has been discontinued and replaced with a new feature called " REF _Ref413750547 \h Media" which replaces both halo and atmosphere. Bounding shapes are finite, invisible shapes which wrap around complex, slow rendering shapes in order to speed up rendering time. Clipping shapes are used to cut away parts of shapes to expose a hollow interior. Transformations tell the ray-tracer how to move, size or rotate the shape and/or the texture in the scene. Finite Solid Primitives There are thirteen different solid finite primitive shapes: blob, box, cone, cylinder, height field, Julia fractal, lathe, prisms, sphere, superellipsoid, surface of revolution, text object and torus. These have a well-defined inside and can be used in CSG (see section " REF _Ref413750710 \h Constructive Solid Geometry"). They are finite and respond to automatic bounding. You may specify an interior for these objects. Blob  XE "blob" Blobs are an interesting and flexible object type. Mathematically they are iso-surfaces of scalar fields, i.e. their surface is defined by the strength of the field in each point. If this strength is equal to a threshold value you're on the surface otherwise you're not. Picture each blob component as an object floating in space. This object is filled with a field that has its maximum at the center of the object and drops off to zero at the object's surface. The field strength of all those components are added together to form the field of the blob. Now POV-Ray looks for points where this field has a given value, the threshold value. All these points form the surface of the blob object. Points with a greater field value than the threshold value are considered to be inside while points with a smaller field value are outside. There's another, simpler way of looking at blobs. They can be seen as a union of flexible components that attract or repel each other to form a blobby organic looking shape. The components' surfaces actually stretch out smoothly and connect as if they were made of honey or something like that. The syntax for blob XE "blob"  is defined as follows: BLOB: blob { BLOB_ITEM... [BLOB_MODIFIERS...]} BLOB_ITEM: sphere{
, Radius, [ strength ] Strength [COMPONENT_MODIFIER...] } | cylinder{, , Radius, [ strength ] Strength [COMPONENT_MODIFIER...] } | component Strength, Radius,
| threshold Amount COMPONENT_MODIFIER: TEXTURE | PIGMENT | NORMAL | FINISH | TRANSFORMATION BLOB_MODIFIER: hierarchy [Boolean] | sturm [Boolean] | OBJECT_MODIFIER The threshold XE "threshold"  keyword is followed by a float value which determines the total field strength value that POV-Ray is looking for. The default value if none is specified is threshold 1.0. By following the ray out into space and looking at how each blob component affects the ray, POV-Ray will find the points in space where the field strength is equal to the threshold value. The following list shows some things you should know about the threshold value. 1) The threshold value must be positive. 2) A component disappears if the threshold value is greater than its strength. 3) As the threshold value gets larger, the surface you see gets closer to the centers of the components. 4) As the threshold value gets smaller, the surface you see gets closer to the surface of the components. Cylindrical components are specified by a cylinder XE "cylinder"  statement. The center of the end-caps of the cylinder is defined by the vectors and . Next is the float value of the Radius followed by the float Strength. These vectors and floats are required and should be separated by commas. The keyword strength may optionally precede the strength value. The cylinder has hemispherical caps at each end. Spherical components are specified by a sphere XE "sphere"  statement. The location is defined by the vector
. Next is the float value of the Radius followed by the float Strength. These vector and float values are required and should be separated by commas. The keyword strength may optionally precede the strength value. You usually will apply a single texture to the entire blob object, and you typically use transformations to change its size, location, and orientation. However both the cylinder and sphere statements may have individual texture, pigment, normal, finish, and transformations applied to them. You may not apply separate interior XE "interior"  statements to the components but you may specify one for the entire blob. Note that by unevenly scaling a spherical component you can create ellipsoidal components. The tutorial section on " REF _Ref413759196 \h Blob Object" illustrates individually textured blob components and many other blob examples. The component XE "component"  keyword is an obsolete method for specifying a spherical component and is only used for compatibility with earlier POV-Ray versions. It may not have textures or transformations individually applied to it. The strength XE "strength"  parameter of either type of blob component is a float value specifying the field strength at the center of the object. The strength may be positive or negative. A positive value will make that component attract other components while a negative value will make it repel other components. Components in different, separate blob shapes do not affect each other. You should keep the following things in mind. 1) The strength value may be positive or negative. Zero is a bad value, as the net result is that no field was added --- you might just as well have not used this component. 2) If strength is positive, then POV-Ray will add the component's field to the space around the center of the component. If this adds enough field strength to be greater than the threshold value you will see a surface. 3) If the strength value is negative, then POV-Ray will subtract the component's field from the space around the center of the component. This will only do something if there happen to be positive components nearby. What happens is that the surface around any nearby positive components will be dented away from the center of the negative component. After all components and the optional threshold value have been specified you may specify zero or more blob modifiers. A blob modifier is any regular object modifier or the hierarchy XE "hierarchy"  or sturm XE "sturm"  keywords. The components of each blob object are internally bounded by a spherical bounding hierarchy to speed up blob intersection tests and other operations. By using the optional keyword hierarchy XE "hierarchy"  followed by an optional boolean float value to turn it off or on. By default it is on. The calculations for blobs must be very accurate. If this shape renders improperly you may add the keyword sturm followed by an optional boolean float value to turn it off or on POV-Ray's slower-yet-more-accurate Sturmian root solver. By default it is off. An example of a three component blob is: blob { threshold 0.6 sphere { <.75, 0, 0>, 1, 1 } sphere { <-.375, .64952, 0>, 1, 1 } sphere { <-.375, -.64952, 0>, 1, 1 } scale 2 } If you have a single blob component then the surface you see will just look like the object used, i.e. a sphere or a cylinder, with the surface being somewhere inside the surface specified for the component. The exact surface location can be determined from the blob equation listed below (you will probably never need to know this, blobs are more for visual appeal than for exact modeling). For the more mathematically minded, here's the formula used internally by POV-Ray to create blobs. You don't need to understand this to use blobs. The density of the blob field of a single component is:  where distance is the distance of a given point from the spherical blob's center or cylinder blob's axis. This formula has the nice property that it is exactly equal to the strength parameter at the center of the component and drops off to exactly 0 at a distance from the center of the component that is equal to the radius value. The density formula for more than one blob component is just the sum of the individual component densities. Box A simple box can be defined by listing two corners of the box using the following syntax for a box XE "box"  statement: BOX: box { , [OBJECT_MODIFIERS...]}  The geometry of a box. Where and are vectors defining the x, y, z coordinates of the opposite corners of the box. Note that all boxes are defined with their faces parallel to the coordinate axes. They may later be rotated to any orientation using the rotate XE "rotate"  keyword. Boxes are calculated efficiently and make good bounding shapes (if manually bounding seems to be necessary). Cone The cone XE "cone"  statement creates a finite length cone or a frustum (a cone with the point cut off). The syntax is: CONE: cone { , Base_Radius, , Cap_Radius [ open ][OBJECT_MODIFIERS...] }  The geometry of a cone. Where and < Cap_Point> are vectors defining the x, y, z coordinates of the center of the cone's base and cap and Base_Radius and Cap_Radius are float values for the corresponding radii. Normally the ends of a cone are closed by flat planes which are parallel to each other and perpendicular to the length of the cone. Adding the optional keyword open XE "open"  after Cap_Radius will remove the end caps and results in a tapered hollow tube like a megaphone or funnel. Cylinder The cylinder XE "cylinder"  statement creates finite length cylinder with parallel end caps The syntax is: CYLINDER: cylinder{ , , Radius [ open ][OBJECT_MODIFIERS...] }  The geometry of a cylinder. Where and are vectors defining the x, y, z coordinates of the cylinder's base and cap and Radius is a float value for the radius. Normally the ends of a cylinder are closed by flat planes which are parallel to each other and perpendicular to the length of the cylinder. Adding the optional keyword open XE "open"  after the radius will remove the end caps and results in a hollow tube. Height Field Height fields are fast, efficient objects that are generally used to create mountains or other raised surfaces out of hundreds of triangles in a mesh. The height_field XE "height_field"  statement syntax is: HEIGHT_FIELD: height_field{ HF_TYPE "filename" [HF_MODIFIER...] } HF_TYPE: gif | tga | pot | png | pgm | ppm | sys HF_MODIFIER: hierarchy [Boolean] | smooth [Boolean] | water_level Level | OBJECT_MODIFIER A height field is essentially a one unit wide by one unit long square with a mountainous surface on top. The height of the mountain at each point is taken from the color number or palette index of the pixels in a graphic image file. The maximum height is one, which corresponds to the maximum possible color or palette index value in the image file.  The size and orientation of an un-scaled height field. The mesh of triangles corresponds directly to the pixels in the image file. Each square formed by four neighboring pixels is divided into two triangles. An image with a resolution of N*M pixels has (N-1)*(M-1) squares that are divided into 2*(N-1)*(M-1) triangles.  Four pixels of an image and the resulting heights and triangles in the height field. The resolution of the height field is influenced by two factors: the resolution of the image and the resolution of the color/index values. The size of the image determines the resolution in the x- and z-direction. A larger image uses more triangles and looks smoother. The resolution of the color/index value determines the resolution along the y-axis. A height field made from an 8 bit image can have 256 different height levels while one made from a 16 bit image can have up to 65536 different height levels. Thus the second height field will look much smoother in the y-direction if the height field is created appropriately. The size/resolution of the image does not affect the size of the height field. The un-scaled height field size will always be 1 by 1 by 1. Higher resolution image files will create smaller triangles, not larger height fields. There are six or possibly seven types of files which can define a height field. The image file type used to create a height field is specified by one of the keywords gif XE "gif" , tga XE "tga" , pot XE "pot" , png XE "png" , pgm XE "pgm" , ppm XE "ppm" , and possibly sys XE "sys"  which is a system specific (e. g. Windows BMP or Macintosh Pict) format file. The GIF, PNG, PGM, and possibly SYS format files are the only ones that can be created using a standard paint program. Though there are paint programs for creating TGA image files they won't be of much use for creating the special 16 bit TGA files used by POV-Ray (see below and " REF _Ref413835579 \h HF_Gray_16" for more details). In an image file like GIF that uses a color palette the color number is the palette index at a given pixel. Use a paint program to look at the palette of a GIF image. The first color is palette index zero, the second is index one, the third is index two and so on. The last palette entry is index 255. Portions of the image that use low palette entries will result in lower parts of the height field. Portions of the image that use higher palette entries will result in higher parts of the height field. Height fields created from GIF files can only have 256 different height levels because the maximum number of colors in a GIF file is 256. The color of the palette entry does not affect the height of the pixel. Color entry 0 could be red, blue, black or orange but the height of any pixel that uses color entry 0 will always be 0. Color entry 255 could be indigo, hot pink, white or sky blue but the height of any pixel that uses color entry 255 will always be 1. You can create height field GIF images with a paint program or a fractal program like Fractint. You can usually get Fractint from most of the same sources as POV-Ray. A POT file is essentially a GIF file with a 16 bit palette. The maximum number of colors in a POT file is 65536. This means a POT height field can have up to 65536 possible height values. This makes it possible to have much smoother height fields. Note that the maximum height of the field is still 1 even though more intermediate values are possible. At the time of this writing the only program that created POT files was a freeware MS-Dos/Windows program called Fractint. POT files generated with this fractal program create fantastic landscapes. The TGA and PPM file formats may be used as a storage device for 16 bit numbers rather than an image file. These formats use the red and green bytes of each pixel to store the high and low bytes of a height value. These files are as smooth as POT files but they must be generated with special custom-made programs. Several programs can create TGA heightfields in the format POV uses, such as Gforge and Terrain Maker. PNG format heightfields are usually stored in the form of a grayscale image with black corresponding to lower and white to higher parts of the height field. Because PNG files can store up to 16 bits in grayscale images they will be as smooth as TGA and PPM images. Since they are grayscale images you will be able to view them with a regular image viewer. gforge can create 16-bit heightfields in PNG format. Color PNG images will be used in the same way as TGA and PPM images. SYS format is a platform specific file format. See your platform specific documentation for details. In addition to all the usual object modifiers, there are three additional height field modifiers available. The optional water_level XE "water_level"  parameter may be added after the file name. It consists of the keyword water_level followed by a float value telling the program to ignore parts of the height field below that value. The default value is zero and legal values are between zero and one. For example water_level 0.5 tells POV-Ray to only render the top half of the height field. The other half is below the water and couldn't be seen anyway. Using water_level renders faster than cutting off the lower part using CSG or clipping. This term comes from the popular use of height fields to render landscapes. A height field would be used to create islands and another shape would be used to simulate water around the islands. A large portion of the height field would be obscured by the water so the water_level parameter was introduced to allow the ray-tracer to ignore the unseen parts of the height field. water_level is also used to cut away unwanted lower values in a height field. For example if you have an image of a fractal on a solid colored background, where the background color is palette entry 0, you can remove the background in the height field by specifying, water_level 0.001. Normally height fields have a rough, jagged look because they are made of lots of flat triangles. Adding the keyword smooth XE "smooth"  causes POV-Ray to modify the surface normal vectors of the triangles in such a way that the lighting and shading of the triangles will give a smooth look. This may allow you to use a lower resolution file for your height field than would otherwise be needed. However, smooth triangles will take longer to render. The default value is off. You may optionally use a boolean value such as smooth on or smooth off. In order to speed up the intersection tests an one-level bounding hierarchy is available. By default it is always used but it can be switched off using hierarchy off to improve the rendering speed for small height fields (i.e. low resolution images). You may optionally use a boolean value such as hierarchy on or hierarchy off. Julia Fractal A julia fractal object is a 3-D slice of a 4-D object created by generalizing the process used to create the classic Julia sets. You can make a wide variety of strange objects using the julia_fractal XE "julia_fractal"  statement including some that look like bizarre blobs of twisted taffy. The julia_fractal syntax is: JULIA_FRACTAL: julia_fractal{ <4D_Julia_Parameter> [JF_ITEM...] [OBJECT_MODIFIER...] } JF_ITEM: ALGEBRA_TYPE | FUNCTION_TYPE | max_iteration Count | precision Amt | slice <4D_Normal>, Distance ALGEBRA_TYPE: quaternion | hypercomplex FUNCTION_TYPE: sqr | cube | exp | reciprocal | sin | asin | sinh | asinh | cos | acos | cosh | acosh | tan | atan | tanh | atanh | log | pwr( X_Val, Y_Val ) The required 4-D vector <4D_Julia_Parameter> is the classic Julia parameter p in the iterated formula f(h) + p. The julia fractal object is calculated by using an algorithm that determines whether an arbitrary point h(0) in 4-D space is inside or outside the object. The algorithm requires generating the sequence of vectors h(0), h(1), ... by iterating the formula h(n+1) = f(h(n)) + p (n = 0, 1, ..., max_iteration-1) where p is the fixed 4-D vector parameter of the julia fractal and f() is one of the functions sqr, cube, ... specified by the presence of the corresponding keyword. The point h(0) that begins the sequence is considered inside the julia fractal object if none of the vectors in the sequence escapes a hypersphere of radius 4 about the origin before the iteration number reaches the integer max_iteration XE "max_iteration"  value. As you increase max_iteration, some points escape that did not previously escape, forming the julia fractal. Depending on the <4D_Julia_Parameter>, the julia fractal object is not necessarily connected; it may be scattered fractal dust. Using a low max_iteration can fuse together the dust to make a solid object. A high max_iteration is more accurate but slows rendering. Even though it is not accurate, the solid shapes you get with a low, max_iteration value can be quite interesting. If none is specified, the default is max_iteration 20. Since the mathematical object described by this algorithm is four-dimensional and POV-Ray renders three dimensional objects, there must be a way to reduce the number of dimensions of the object from four dimensions to three. This is accomplished by intersecting the 4-D fractal with a 3-D "plane" defined by the slice XE "slice"  modifier and then projecting the intersection to 3-D space. The keyword is followed by 4D vector and a float separated by a comma. The slice plane is the 3-D space that is perpendicular to <4D_Normal> and is Distance units from the origin. Zero length <4D_Normal> vectors or a <4D_Normal> vector with a zero fourth component are illegal. If none is specified, the default is slice <0,0,0,1>,0. You can get a good feel for the four dimensional nature of a julia fractal by using POV-Ray's animation feature to vary a slice's Distance parameter. You can make the julia fractal appear from nothing, grow, then shrink to nothing as Distancechanges, much as the cross section of a 3-D object changes as it passes through a plane. The precision XE "precision"  parameter is a tolerance used in the determination of whether points are inside or outside the fractal object. Larger values give more accurate results but slower rendering. Use as low a value as you can without visibly degrading the fractal object's appearance but note values less than 1.0 are clipped at 1.0. The default if none is specified is precision 20. The presence of the keywords quaternion XE "quaternion"  or hypercomplex XE "hypercomplex"  determine which 4-D algebra is used to calculate the fractal. The default is quaternion. Both are 4-D generalizations of the complex numbers but neither satisfies all the field properties (all the properties of real and complex numbers that many of us slept through in high school). Quaternions have non-commutative multiplication and hypercomplex numbers can fail to have a multiplicative inverse for some non-zero elements (it has been proved that you cannot successfully generalize complex numbers to four dimensions with all the field properties intact, so something has to break). Both of these algebras were discovered in the 19th century. Of the two, the quaternions are much better known, but one can argue that hypercomplex numbers are more useful for our purposes, since complex valued functions such as sin, cos, etc. can be generalized to work for hypercomplex numbers in a uniform way. For the mathematically curious, the algebraic properties of these two algebras can be derived from the multiplication properties of the unit basis vectors 1 = <1,0,0,0>, i=< 0,1,0,0>, j=<0,0,1,0> and k=< 0,0,0,1>. In both algebras 1 x = x 1 = x for any x (1 is the multiplicative identity). The basis vectors 1 and i behave exactly like the familiar complex numbers 1 and i in both algebras. Quaternion basis vector multiplication rules:ij = kjk = iki = jji = -kkj = -iik = -jii = jj = kk = -1ijk = -1 Hypercomplex basis vector multiplication rules:ij = kjk = -iki = -jji = kkj = -iik = -jii = jj = kk = -1ijk = 1A distance estimation calculation is used with the quaternion calculations to speed them up. The proof that this distance estimation formula works does not generalize from two to four dimensions but the formula seems to work well anyway, the absence of proof notwithstanding!  XE "sqr"  XE "cube"  XE "exp"  XE "reciprocal"  XE "sin"  XE "asin"  XE "sinh"  XE "asinh"  XE "cos"  XE "cosh"  XE "acosh"  XE "tan"  XE "atan"  XE "tanh"  XE "atanh"  XE "log"  XE "pwr" The presence of one of the function keywords sqr, cube, etc. determines which function is used for f(h) in the iteration formula h(n+1) = f(h(n)) + p. The default is sqr. Most of the function keywords work only if the hypercomplex keyword is present. Only sqr and cube work with quaternion. The functions are all familiar complex functions generalized to four dimensions. Function Keyword Maps 4-D value h to:sqrh*hcubeh*h*hexpe raised to the power hreciprocal1/hsinsine of hasinarcsine of hsinhhyperbolic sine of hasinhinverse hyperbolic sine of hcoscosine of hacosarccosine of hcoshhyperbolic cos of hacoshinverse hyperbolic cosine of htantangent of hatanarctangent of htanhhyperbolic tangent of hatanhinverse hyperbolic tangent of hlognatural logarithm of hpwr(x,y)h raised to the complex power x+iyA simple example of a julia fractal object is: julia_fractal { <-0.083,0.0,-0.83,-0.025> quaternion sqr max_iteration 8 precision 15 } The first renderings of julia fractals using quaternions were done by Alan Norton and later by John Hart in the '80's. This new POV-Ray implementation follows Fractint in pushing beyond what is known in the literature by using hypercomplex numbers and by generalizing the iterating formula to use a variety of transcendental functions instead of just the classic Mandelbrot z2 + c formula. With an extra two dimensions and eighteen functions to work with, intrepid explorers should be able to locate some new fractal beasts in hyperspace, so have at it! Lathe The lathe XE "lathe"  is an object generated from rotating a two-dimensional curve about an axis. This curve is defined by a set of points which are connected by linear, quadratic, cubic or bezier spline curves. The syntax is: LATHE: lathe { [SPLINE_TYPE] Number_Of_Points, ... [LATHE_MODIFIER...] } SPLINE_TYPE: linear_spline | quadratic_spline | cubic_spline | bezier_spline LATHE_MODIFIER: sturm | OBJECT_MODIFIER The first item is a keyword specifying the type of spline. The default if none is specified is linear_spline XE "linear_spline" . The required integer value Number_Of_Points specifies how many two-dimensional points are used to define the curve. The points follow and are specified by 2-D vectors. The curve is not automatically closed, i.e. the first and last points are not automatically connected. You will have to do this by your own if you want a closed curve. The curve thus defined is rotated about the y-axis to form the lathe object which is centered at the origin. The following examples creates a simple lathe object that looks like a thick cylinder, i.e. a cylinder with a thick wall: lathe { linear_spline 5, <2, 0>, <3, 0>, <3, 5>, <2, 5>, <2, 0> pigment {Red} } The cylinder has an inner radius of 2 and an outer radius of 3, giving a wall width of 1. It's height is 5 and it's located at the origin pointing up, i.e. the rotation axis is the y-axis. Note that the first and last point are equal to get a closed curve. The splines that are used by the lathe and prism objects are a little bit difficult to understand. The basic concept of splines is to draw a curve through a given set of points in a determined way. The default linear_spline XE "linear_spline"  is the simplest spline because it's nothing more than connecting consecutive points with a line. This means that the curve that is drawn between two points only depends on those two points. No additional information is taken into account. The other splines are different in that they do take other points into account when connecting two points. This creates a smooth curve and, in the case of the cubic spline, produces smoother transitions at each point. The quadratic_spline XE "quadratic_spline"  keyword creates splines that are made of quadratic curves. Each of them connects two consecutive points. Since those two points (call them second and third point) are not sufficient to describe a quadratic curve the predecessor of the second point is taken into account when the curve is drawn. Mathematically the relationship (their location on the 2-D plane) between the first and second point determines the slope of the curve at the second point. The slope of the curve at the third point is out of control. Thus quadratic splines look much smoother than linear splines but the transitions at each point are generally not smooth because the slopes on both sides of the point are different. The cubic_spline XE "cubic_spline"  keyword creates splines overcome the transition problem of quadratic splines because they also take the fourth point into account when drawing the curve between the second and third point. The slope at the fourth point is under control now and allows a smooth transition at each point. Thus cubic splines produce the most flexible and smooth curves. The bezier_spline is an alternate kind of cubic spline. Points 1 and 4 specify the end points of a segment and points 2 and 3 are control points which specify the slope at the endpoints. Points 2 and 3 do not actually lie on the spline. They adjust the slope of the spline. If you draw an imaginary line between point 1 and 2, it represents the slope at point 1. It is a line tangent to the curve at point 1. The greater the distance between 1 and 2, the flatter the curve. With a short tangent the spline can bend more. The same holds true for control point 3 and endpoint 4. If you want the spline to be smooth between segments, point 3 and 4 on one segment and point 1 and 2 on the next segment must form a straight line and point 4 of one segment must be the same as point one on the next segment. You should note that the number of spline segments, i. e. curves between two points, depends on the spline type used. For linear splines you get n-1 segments connecting the points P[i], i=1,...,n. A quadratic spline gives you n-2 segments because the last point is only used for determining the slope as explained above (thus you'll need at least three points to define a quadratic spline). The same holds for cubic splines where you get n-3 segments with the first and last point used only for slope calculations (thus needing at least four points). The bezier spline requires 4 points per segment. If you want to get a closed quadratic and cubic spline with smooth transitions at the end points you have to make sure that in the cubic case P[n-1] = P[2] (to get a closed curve), P[n] = P[3] and P[n-2] = P[1] (to smooth the transition). In the quadratic case P[n-1] = P[1] (to close the curve) and P[n] = P[2]. The sturm XE "sturm"  keyword can be used to specify that the slower but more accurate Sturmian root solver should be used. Use it with the quadratic spline lathe if the shape does not render properly. Since a quadratic polynomial has to be solved for the linear spline lathe the Sturmian root solver is not needed. In case of cubic or bezier splines, the Sturmian root solver is always used because a 6th order polynomial has to be solved. Prism The prism XE "prism"  is an object generated specifying one or more two-dimensional, closed curves in the x-z plane and sweeping them along y axis. These curves are defined by a set of points which are connected by linear, quadratic, cubic or bezier splines. The syntax for the prism is: PRISM: prism { [PRISM_ITEMS...] Height_1, Height_2, Number_Of_Points, , , ... [ open ] [PRISM_MODIFIERS...] } PRISM_ITEM: linear_spline | quadratic_spline | cubic_spline | bezier_spline | linear_sweep | conic_sweep PRISM_MODIFIER: sturm | OBJECT_MODIFIER The first items specify the spline type and sweep type. The defaults if none is specified is linear_spline XE "linear_spline"  and conic_sweep XE "conic_sweep" . This is followed by two float values Height_1 and Height_2 which are the y coordinates of the top and bottom of the prism. This is followed by a float value specifying the number of 2-D points you will use to define the prism. (This includes all control points needed for quadratic, cubic and bezier splines). This is followed by the specified number of 2-D vectors which define the shape in the x-z plane. The interpretation of the points depends on the spline type. The prism object allows you to use any number of sub-prisms inside one prism statement (they are of the same spline and sweep type). Wherever an even number of sub-prisms overlaps a hole appears. Note you need not have multiple sub-prisms and they need not overlap as these examples do. In the linear_spline XE "linear_spline"  the first point specified is the start of the first sub-prism. The following points are connected by straight lines. If you specify a value identical to the first point, this closes the sub-prism and next point starts a new one. When you specify the value of that sub-prism's start, then it is closed. Each of the sub-prisms has to be closed by repeating the first point of a sub-prism at the end of the sub-prism's point sequence. In this example, there are two rectangular sub-prisms nested inside each other to create a frame. prism { linear_spline 0, 1, 10, <0,0>, <6,0>, <6,8>, <0,8>, <0,0>, //outer rim <1,1>, <5,1>, <5,7>, <1,7>, <1,1> //inner rim } The last sub-prism of a linear spline prism is automatically closed - just like the last sub-polygon in the polygon statement - if the first and last point of the sub-polygon's point sequence are not the same. This make it very easy to convert between polygons and prisms. Quadratic, cubic and bezier splines are never automatically closed. In the quadratic_spline XE "quadratic_spline" , each sub-prism needs an additional control point at the beginning of each sub-prisms' point sequence to determine the slope at the start of the curve. The first point specified is the control point which is not actually part of the spline. The second point is the start of the spline. The sub-prism ends when this second point is duplicated. The next point is the control point of the next sub-prism. The point after that is the first point of the second sub-prism. Here is an example: prism { quadratic_spline 0, 1, 12, <1,-1>, <0,0>, <6,0>, <6,8>, <0,8>, <0,0>, //outer rim //Control is <1,-1> and <0,0> is first & last point <2,0>, <1,1>, <5,1>, <5,7>, <1,7>, <1,1> //inner rim //Control is <2,0> and <1,1> is first & last point } In the cubic_spline XE "cubic_spline" , each sub-prism needs two additional control points -- one at the beginning of each sub-prisms' point sequence to determine the slope at the start of the curve and one at the end. The first point specified is the control point which is not actually part of the spline. The second point is the start of the spline. The sub-prism ends when this second point is duplicated. The next point is the control point of the end of the first sub-prism. Next is the beginning control point of the next sub-prism. The point after that is the first point of the second sub-prism. Here is an example: prism { cubic_spline 0, 1, 14, <1,-1>, <0,0>, <6,0>, <6,8>, <0,8>, <0,0>, <-1,1>, //outer rim //First control is <1,-1> and <0,0> is first & last point // Last control of first spline is <-1,1> <2,0>, <1,1>, <5,1>, <5,7>, <1,7>, <1,1>, <0,2> //inner rim //First control is <2,0> and <1,1> is first & last point // Last control of first spline is <0,2> } The bezier_spline is an alternate kind of cubic spline. Points 1 and 4 specify the end points of a segment and points 2 and 3 are control points which specify the slope at the endpoints. Points 2 and 3 do not actually lie on the spline. They adjust the slope of the spline. If you draw an imaginary line between point 1 and 2, it represents the slope at point 1. It is a line tangent to the curve at point 1. The greater the distance between 1 and 2, the flatter the curve. With a short tangent the spline can bend more. The same holds true for control point 3 and endpoint 4. If you want the spline to be smooth between segments, point 3 and 4 on one segment and point 1 and 2 on the next segment must form a straight line and point 4 of one segment must be the same as point one on the next segment. By default linear sweeping is used to create the prism, i.e. the prism's walls are perpendicular to the x-z-plane (the size of the curve does not change during the sweep). You can also use conic_sweep XE "conic_sweep"  that leads to a prism with cone-like walls by scaling the curve down during the sweep. Like cylinders the prism is normally closed. You can remove the caps on the prism by using the open XE "open"  keyword. If you do so you shouldn't use it with CSG because the results may get wrong. For an explanation of the spline concept read the description of the " REF _Ref415568197 \h Lathe" object. Also see the tutorials on " REF _Ref415568254 \h Lathe Object" and " REF _Ref415568292 \h Prism Object". The sturm XE "sturm"  keyword specifies the slower but more accurate Sturmian root solver which may be used with the cubic or bezier spline prisms if the shape does not render properly. The linear and quadratic spline prisms do not need the Sturmian root solver. Sphere The syntax of the sphere XE "sphere"  object is: SPHERE: sphere {
, Radius [OBJECT_MODIFIERS...] }  The geometry of a sphere. Where
is a vector specifying the x, y, z coordinates of the center of the sphere and Radius is a float value specifying the radius. Spheres may be scaled unevenly giving an ellipsoid shape. Because spheres are highly optimized they make good bounding shapes (if manual bounding seems to be necessary). Superquadric Ellipsoid The superellipsoid XE "superellipsoid"  object creates a shape known as a superquadric ellipsoid object. It is an extension of the quadric ellipsoid. It can be used to create boxes and cylinders with round edges and other interesting shapes. Mathematically it is given by the equation:  The values of e and n, called the east-west and north-south exponent, determine the shape of the superquadric ellipsoid. Both have to be greater than zero. The sphere is given by e = 1 and n = 1. The syntax of the superquadric ellipsoid is: SUPERELLIPSOID: superellipsoid{ [OBJECT_MODIFIERS...] } The 2-D vector specifies the e and n values in the equation above. The object sits at the origin and occupies a space about the size of a box{<-1,-1,-1>,<1,1,1>}. Two useful objects are the rounded box and the rounded cylinder. These are declared in the following way. #declare Rounded_Box = superellipsoid { } #declare Rounded_Cylinder = superellipsoid { <1, Round> } The roundedness value Round determines the roundedness of the edges and has to be greater than zero and smaller than one. The smaller you choose the values, the smaller and sharper the edges will get. Very small values of e and n might cause problems with the root solver (the Sturmian root solver cannot be used). Surface of Revolution The sor XE "sor"  object is a surface of revolution generated by rotating the graph of a function about the y-axis. This function describes the dependence of the radius from the position on the rotation axis. The syntax is: SOR: sor { Number_Of_Points, , , ... [ open ] [SOR_MODIFIERS...] } SOR_MODIFIER: sturm | OBJECT_MODIFIER The float value Number_Of_Points specifies the number of 2-D vectors which follow. The points through are two-dimensional vectors consisting of the radius and the corresponding height, i.e. the position on the rotation axis. These points are smoothly connected (the curve is passing through the specified points) and rotated about the y-axis to form the SOR object. The first and last points are only used to determine the slopes of the function at the start and end point. They do not actually lie on the curve. The function used for the SOR object is similar to the splines used for the lathe object. The difference is that the SOR object is less flexible because it underlies the restrictions of any mathematical function, i.e. to any given point y on the rotation axis belongs at most one function value, i.e. one radius value. You can't rotate closed curves with the SOR object. The optional keyword open allows you to remove the caps on the SOR object. If you do this you shouldn't use it with CSG anymore because the results may be wrong. The SOR object is useful for creating bottles, vases, and things like that. A simple vase could look like this: #declare Vase = sor { 7, <0.000000, 0.000000> <0.118143, 0.000000> <0.620253, 0.540084> <0.210970, 0.827004> <0.194093, 0.962025> <0.286920, 1.000000> <0.468354, 1.033755> open } One might ask why there is any need for a SOR object if there is already a lathe object which is much more flexible. The reason is quite simple. The intersection test with a SOR object involves solving a cubic polynomial while the test with a lathe object requires to solve of a 6th order polynomial (you need a cubic spline for the same smoothness). Since most SOR and lathe objects will have several segments this will make a great difference in speed. The roots of the 3rd order polynomial will also be more accurate and easier to find. The sturm XE "sturm"  keyword may be added to specify the slower but more accurate Sturmian root solver. It may be used with the surface of revolution object if the shape does not render properly. The following explanations are for the mathematically interested reader who wants to know how the surface of revolution is calculated. Though it is not necessary to read on it might help in understanding the SOR object. The function that is rotated about the y-axis to get the final SOR object is given by  with radius r and height h. Since this is a cubic function in h it has enough flexibility to allow smooth curves. The curve itself is defined by a set of n points P(i), i=0...n-1, which are interpolated using one function for every segment of the curve. A segment j, j=1...n-3, goes from point P(j) to point P(j+1) and uses points P(j-1) and P(j+2) to determine the slopes at the endpoints. If there are n points we will have n-3 segments. This means that we need at least four points to get a proper curve. The coefficients A(j), B(j), C(j) and D(j) are calculated for every segment using the equation  where r(j) is the radius and h(j) is the height of point P(j). The figure below shows the configuration of the points P(i), the location of segment j, and the curve that is defined by this segment.  Segment j of n-3 segments in a point configuration of n points. The points describe the curve of a surface of revolution.' Text A text XE "text"  XE "ttf"  object creates 3-D text as an extruded block letter. Currently only TrueType fonts are supported but the syntax allows for other font types to be added in the future. The syntax is: TEXT_OBECT: text { ttf "fontname.ttf" "String_of_Text" Thickness, [OBJECT_MODIFIERS...] } Where fontname.ttf is the name of the TrueType font file. It is a quoted string literal or string expression. The string expression which follows is the actual text of the string object. It too may be a quoted string literal or string expression. See section " REF _Ref415649609 \h Strings" for more on string expressions. The text will start with the origin at the lower left, front of the first character and will extend in the +x-direction. The baseline of the text follows the x-axis and decenders drop into the -y-direction. The front of the character sits in the x-y-plane and the text is extruded in the +z-direction. The front-to-back thickness is specified by the required value Thickness. Characters are generally sized so that 1 unit of vertical spacing is correct. The characters are about 0.5 to 0.75 units tall. The horizontal spacing is handled by POV-Ray internally including any kerning information stored in the font. The required vector defines any extra translation between each character. Normally you should specify a zero for this value. Specifying 0.1*x would put additional 0.1 units of space between each character. Here is an example: text { ttf "timrom.ttf" "POV-Ray 3.1" 1, 0 pigment { Red } } Only printable characters are allowed in text objects. Characters such as return, line feed, tabs, backspace etc. are not supported. Torus A torus XE "torus"  is a 4th order quartic polynomial shape that looks like a donut or inner tube. Because this shape is so useful and quartics are difficult to define, POV-Ray lets you take a short-cut and define a torus by: TORUS: torus { Major, Minor [TORUS_MODIFIER...] } TORUS_MODIFIER: sturm | OBJECT_MODIFIER where Major is a float value giving the major radius and Minor is a float specifying the minor radius. The major radius extends from the center of the hole to the mid-line of the rim while the minor radius is the radius of the cross-section of the rim. The torus is centered at the origin and lies in the x-z-plane with the y-axis sticking through the hole.  Major and minor radius of a torus. The torus is internally bounded by two cylinders and two rings forming a thick cylinder. With this bounding cylinder the performance of the torus intersection test is vastly increased. The test for a valid torus intersection, i.e. solving a 4th order polynomial, is only performed if the bounding cylinder is hit. Thus a lot of slow root solving calculations are avoided. Calculations for all higher order polynomials must be very accurate. If the torus renders improperly you may add the keyword sturm XE "sturm"  to use POV-Ray's slower-yet-more-accurate Sturmian root solver. Finite Patch Primitives There are six totally thin, finite objects which have no well-defined inside. They are bicubic patch, disc, smooth triangle, triangle, polygon and mesh. They may be combined in CSG union but cannot be use in other types of CSG (or inside a clipped_by XE "clipped_by"  statement). Because these types are finite POV-Ray can use automatic bounding on them to speed up rendering time. As with all shapes they can be translated, rotated and scaled. Bicubic Patch A bicubic_patch XE "bicubic_patch"  is a 3D curved surface created from a mesh of triangles. POV-Ray supports a type of bicubic patch called a Bezier patch. A bicubic patch is defined as follows: BICUBIC_PATCH: bicubic_patch { PATCH_ITEMS... ,,,, ,,,, ,,,, ,,, [OBJECT_MODIFIERS...] } PATCH_ITEMS: type Patch_Type | u_steps Num_U_Steps | v_steps Num_V_Steps | flatness Flatness The keyword type XE "type"  is followed by a float Patch_Type which currently must be either 0 or 1. For type 0 only the control points are retained within POV-Ray. This means that a minimal amount of memory is needed but POV-Ray will need to perform many extra calculations when trying to render the patch. Type 1 preprocesses the patch into many subpatches. This results in a significant speedup in rendering at the cost of memory. The four parameters type, flatness, u_steps and v_steps may appear in any order. All but flatness are required. They are followed by 16 vectors (4 rows of 4) that define the x, y, z coordinates of the 16 control points which define the patch. The patch touches the four corner points , , and while the other 12 points pull and stretch the patch into shape. The Bezier surface is enclosed by the convex hull formed by the 16 control points, this is known as the convex hull property. The keywords u_steps XE "u_steps"  and v_steps XE "v_steps"  are each followed by integer values which tell how many rows and columns of triangles are the minimum to use to create the surface. The maximum number of individual pieces of the patch that are tested by POV-Ray can be calculated from the following: pieces = 2^u_steps * 2^v_steps. This means that you really should keep u_steps and v_steps under 4. Most patches look just fine with u_steps 3 and v_steps 3, which translates to 64 subpatches (128 smooth triangles). As POV-Ray processes the Bezier patch it makes a test of the current piece of the patch to see if it is flat enough to just pretend it is a rectangle. The statement that controls this test is specified with the flatness XE "flatness"  keyword followed by a float. Typical flatness values range from 0 to 1 (the lower the slower). The default if none is specified is 0.0. If the value for flatness is 0 POV-Ray will always subdivide the patch to the extend specified by u_steps and v_steps. If flatness is greater than 0 then every time the patch is split, POV-Ray will check to see if there is any need to split further. There are both advantages and disadvantages to using a non-zero flatness. The advantages include: - If the patch isn't very curved, then this will be detected and POV-Ray won't waste a lot of time looking at the wrong pieces. - If the patch is only highly curved in a couple of places, POV-Ray will keep subdividing there and concentrate it's efforts on the hard part. The biggest disadvantage is that if POV-Ray stops subdividing at a particular level on one part of the patch and at a different level on an adjacent part of the patch there is the potential for cracking. This is typically visible as spots within the patch where you can see through. How bad this appears depends very highly on the angle at which you are viewing the patch. Like triangles, the bicubic patch is not meant to be generated by hand. These shapes should be created by a special utility. You may be able to acquire utilities to generate these shapes from the same source from which you obtained POV-Ray. Here is an example: bicubic_patch { type 0 flatness 0.01 u_steps 4 v_steps 4 <0, 0, 2>, <1, 0, 0>, <2, 0, 0>, <3, 0,-2>, <0, 1 0>, <1, 1, 0>, <2, 1, 0>, <3, 1, 0>, <0, 2, 0>, <1, 2, 0>, <2, 2, 0>, <3, 2, 0>, <0, 3, 2>, <1, 3, 0>, <2, 3, 0>, <3, 3, -2> } The triangles in a POV-Ray bicubic_patch are automatically smoothed using normal interpolation but it is up to the user (or the user's utility program) to create control points which smoothly stitch together groups of patches. Disc Another flat, finite object available with POV-Ray is the disc XE "disc" . The disc is infinitely thin, it has no thickness. If you want a disc with true thickness you should use a very short cylinder. A disc shape may be defined by: DISC: disc {
, , Radius [, Hole_Radius] [OBJECT_MODIFIERS...] } The vector
defines the x, y, z coordinates of the center of the disc. The vector describes its orientation by describing its surface normal vector. This is followed by a float specifying the Radius. This may be optionally followed by another float specifying the radius of a hole to be cut from the center of the disc. Mesh The mesh XE "mesh"  object can be used to efficiently store large numbers of triangles. Its syntax is: MESH: mesh { MESH_TRIANGLE... [MESH_MODIFIER...] } MESH_TRIANGLE: triangle { , , [MESH_TEXTURE] } | smooth_triangle { , , , , , [MESH_TEXTURE] } MESH_TEXTURE: texture { TEXTURE_IDENTIFIER } MESH_MODIFIER: hierarchy [ Boolean ] | OBJECT_MODIFIER Any number of triangle XE "triangle"  and/or smooth_triangle XE "smooth_triangle"  statements can be used and each of those triangles can be individually textured by assigning a texture identifier to it. The texture has to be declared before the mesh is parsed. It is not possible to use texture definitions inside the triangle or smooth triangle statements. This is a restriction that is necessary for an efficient storage of the assigned textures. See " REF _Ref415659046 \h Triangle and Smooth Triangle" for more information on triangles. The mesh's components are internally bounded by a bounding box hierarchy to speed up intersection testing. The bounding hierarchy can be turned off with the hierarchy XE "hierarchy"  off keyword. This should only be done if memory is short or the mesh consists of only a few triangles. The default is hierarchy on. Copies of a mesh object refer to the same triangle data and thus consume very little memory. You can easily trace hundred copies of an 10000 triangle mesh without running out of memory (assuming the first mesh fits into memory). The mesh object has two advantages over a union of triangles: it needs less memory and it is transformed faster. The memory requirements are reduced by efficiently storing the triangles vertices and normals. The parsing time for transformed meshes is reduced because only the mesh object has to be transformed and not every single triangle as it is necessary for unions. The mesh object can currently only include triangle and smooth triangle components. That restriction may change, allowing polygonal components, at some point in the future. Polygon The polygon XE "polygon"  object is useful for creating rectangles, squares and other planar shapes with more than three edges. Their syntax is: POLYGON: polygon { Number_Of_Points, ... [OBJECT_MODIFIER...]} The float Number_Of_Points tells how many points are used to define the polygon. The points through describe the polygon or polygons. A polygon can contain any number of sub-polygons, either overlapping or not. In places where an even number of polygons overlaps a hole appears. When you repeat the first point of a sub-polygon, it closes it and starts a new sub-polygon's point sequence. This means that all points of a sub-polygon are different. If the last sub-polygon is not closed a warning is issued and the program automatically closes the polygon. This is useful because polygons imported from other programs may not be closed, i.e. their first and last point are not the same. All points of a polygon are three-dimensional vectors that have to lay on the same plane. If this is not the case an error occurs. It is common to use two-dimensional vectors to describe the polygon. POV-Ray assumes that the z value is zero in this case. A square polygon that matches the default planar image map is simply: polygon { 4, <0, 0>, <0, 1>, <1, 1>, <1, 0> texture { finish { ambient 1 diffuse 0 } pigment { image_map { gif "test.gif" } } } //scale and rotate as needed here } The sub-polygon feature can be used to generate complex shapes like the letter "P", where a hole is cut into another polygon: #declare P = polygon { 12, <0, 0>, <0, 6>, <4, 6>, <4, 3>, <1, 3>, <1, 0>, <0, 0>, <1, 4>, <1, 5>, <3, 5>, <3, 4>, <1, 4> } The first sub-polygon (on the first line) describes the outer shape of the letter "P". The second sub-polygon (on the second line) describes the rectangular hole that is cut in the top of the letter "P". Both rectangles are closed, i.e. their first and last points are the same. The feature of cutting holes into a polygon is based on the polygon inside/outside test used. A point is considered to be inside a polygon if a straight line drawn from this point in an arbitrary direction crosses an odd number of edges (this is known as Jordan's curve theorem). Another very complex example showing one large triangle with three small holes and three separate, small triangles is given below: polygon { 28, <0, 0> <1, 0> <0, 1> <0, 0> // large outer triangle <.3, .7> <.4, .7> <.3, .8> <.3, .7> // small outer triangle #1 <.5, .5> <.6, .5> <.5, .6> <.5, .5> // small outer triangle #2 <.7, .3> <.8, .3> <.7, .4> <.7, .3> // small outer triangle #3 <.5, .2> <.6, .2> <.5, .3> <.5, .2> // inner triangle #1 <.2, .5> <.3, .5> <.2, .6> <.2, .5> // inner triangle #2 <.1, .1> <.2, .1> <.1, .2> <.1, .1> // inner triangle #3 } Triangle and Smooth Triangle The triangle XE "triangle"  primitive is available in order to make more complex objects than the built-in shapes will permit. Triangles are usually not created by hand but are converted from other files or generated by utilities. A triangle is defined by TRIANGLE: triangle { , , [OBJECT_MODIFIER...] } where is a vector defining the x, y, z coordinates of each corner of the triangle. Because triangles are perfectly flat surfaces it would require extremely large numbers of very small triangles to approximate a smooth, curved surface. However much of our perception of smooth surfaces is dependent upon the way light and shading is done. By artificially modifying the surface normals we can simulate a smooth surface and hide the sharp-edged seams between individual triangles. The smooth_triangle XE "smooth_triangle"  primitive is used for just such purposes. The smooth triangles use a formula called Phong normal interpolation to calculate the surface normal for any point on the triangle based on normal vectors which you define for the three corners. This makes the triangle appear to be a smooth curved surface. A smooth triangle is defined by SMOOTH_TRIANGLE: smooth_triangle { , , , , , [OBJECT_MODIFIER...] } where the corners are defined as in regular triangles and is a vector describing the direction of the surface normal at each corner. These normal vectors are prohibitively difficult to compute by hand. Therefore smooth triangles are almost always generated by utility programs. To achieve smooth results, any triangles which share a common vertex should have the same normal vector at that vertex. Generally the smoothed normal should be the average of all the actual normals of the triangles which share that point. The mesh XE "mesh"  object is a way to combine many triangle and smooth_triangle objects together in a very efficient way. See " REF _Ref412632666 \h Mesh" for details. Infinite Solid Primitives There are five polynomial primitive shapes that are possibly infinite and do not respond to automatic bounding. They are plane, cubic, poly, quadric and quartic. They do have a well defined inside and may be used in CSG and inside a clipped_by XE "clipped_by"  statement. As with all shapes they can be translated, rotated and scaled. Plane The plane XE "plane"  primitive is a simple way to define an infinite flat surface. The plane is specified as follows: PLANE: plane { , Distance [OBJECT_MODIFIERS...] } The vector defines the surface normal of the plane. A surface normal is a vector which points up from the surface at a 90 degree angle. This is followed by a float value that gives the distance along the normal that the plane is from the origin (that is only true if the normal vector has unit length; see below). For example: plane { <0, 1, 0>, 4 } This is a plane where straight up is defined in the positive y-direction. The plane is 4 units in that direction away from the origin. Because most planes are defined with surface normals in the direction of an axis you will often see planes defined using the x XE "x" , y XE "y"  or z XE "z"  built-in vector identifiers. The example above could be specified as: plane { y, 4 } The plane extends infinitely in the x- and z-directions. It effectively divides the world into two pieces. By definition the normal vector points to the outside of the plane while any points away from the vector are defined as inside. This inside/outside distinction is important when using planes in CSG and clipped_by XE "clipped_by" . It is also important when using fog or atmospheric media. If you place a camera on the "inside" half of the world, then the fog or media will not appear. Such issues arise in any solid object but it is more common with planes. Users typically know when they've accidentally placed a camera inside a sphere or box but "inside a plane" is an unusual concept. You can reverse the inside/outside properties of an object by adding the object modifier inverse XE "inverse" . See " REF _Ref415664580 \h Inverse" and " REF _Ref415663975 \h Empty and Solid Objects" for details. A plane is called a polynomial shape because it is defined by a first order polynomial equation. Given a plane: plane { , D } it can be represented by the equation A*x + B*y + C*z - D*sqrt(A2 + B2 + C2) = 0. Therefore our example plane{y,4} is actually the polynomial equation y=4. You can think of this as a set of all x, y, z points where all have y values equal to 4, regardless of the x or z values. This equation is a first order polynomial because each term contains only single powers of x, y or z. A second order equation has terms like x2, y2, z2, xy, xz and yz. Another name for a 2nd order equation is a quadric equation. Third order polys are called cubics. A 4th order equation is a quartic. Such shapes are described in the sections below. Poly, Cubic and Quartic Higher order polynomial surfaces may be defined by the use of a poly XE "poly"  shape. The syntax is POLY: poly { Order, [POLY_MODIFIERS...] } POLY_MODIFIERS: sturm | OBJECT_MODIFIER where Order is an integer number from 2 to 7 inclusively that specifies the order of the equation. A1, A2, ... An are float values for the coefficients of the equation. There are m such terms where n = ((Order+1)*(Order+2)*(Order+3))/6. The cubic XE "cubic"  object is an alternate way to specify 3rd order polys. Its syntax is: CUBIC: cubic { [POLY_MODIFIERS...] } Also 4th order equations may be specified with the quartic XE "quartic"  object. Its syntax is: QUARTIC: quartic { [POLY_MODIFIERS...] } The following table shows which polynomial terms correspond to which x,y,z factors. Remember cubic is actually a 3rd order polynomial and quartic is 4th order. 2nd3rd4th5th6th7th5th6th7th6th7thA1x2x3x4x5x6x7A41y3xy3x2y3A81z3xz3A2xyx2yx3yx4yx5yx6yA42y2z3xy2z3x2y2z3A82z2xz2A3xzx2zx3zx4zx5zx5zA43y2z2xy2z2x2y2z2A83zxzA4xx2x3x4x5x5A44y2zxy2zx2y2zA841xA5y2xy2x2y2x3y2x4y2x5y2A45y2xy2x2y2A85y7A6yzxyzx2yzx3yzx4yzx5yzA46yz4xyz4x2yz4A86y6zA7yxyx2yx3yx4yx5yA47yz3xyz3x2yz3A87y6A8z2xz2x2z2x3z2x4z2x5z2A48yz2xyz2x2yz2A88y5z2A9zxzx2zx3zx4zx5zA49yzxyzx2yzA89y5zA101xx2x3x4x5A50yxyx2yA90y5A11y3xy3x2y3x3y3x4y3A51z5xz5x2z5A91y4z3A12y2zxy2zx2y2zx3y2zx4y2zA52z4xz4x2z4A92y4z2A13y2xy2x2y2x3y2x4y2A53z3xz3x2z3A93y4zA14yz2xyz2x2yz2x3yz2x4yz2A54z2xz2x2z2A94y4A15yzxyzx2yzx3yzx4yzA55zxzx2zA95y3z4A16yxyx2yx3yx4yA561xx2A96y3z3A17z3xz3x2z3x3z3x4z3A57y6xy6A97y3z2A18z2xz2x2z2x3z2x4z2A58y5zxy5zA98y3zA19zxzx2zx3zx4zA59y5xy5A99y3A201xx2x3x4A60y4z2xy4z2A100y2z5A21y4xy4x2y4x3y4A61y4zxy4zA101y2z4A22y3zxy3zx2y3zx3y3zA62y4xy4A102y2z3A23y3xy3x2y3x3y3A63y3z3xy3z3A103y2z2A24y2z2xy2z2x2y2z2x3y2z2A64y3z2xy3z2A104y2zA25y2zxy2zx2y2zx3y2zA65y3zxy3zA105y2A26y2xy2x2y2x3y2A66y3xy3A106yz6A27yz3xyz3x2yz3x3yz3A67y2z4xy2z4A107yz5A28yz2xyz2x2yz2x3yz2A68y2z3xy2z3A108yz4A29yzxyzx2yzx3yzA69y2z2xy2z2A109yz3A30yxyx2yx3yA70y2zxy2zA110yz2A31z4xz4x2z4x3z4A71y2xy2A111yzA32z3xz3x2z3x3z3A72yz5xyz5A112yA33z2xz2x2z2x3z2A73yz4xyz4A113z7A34zxzx2zx3zA74yz3xyz3A114z6A351xx2x3A75yz2xyz2A115z5A36y5xy5x2y5A76yzxyzA116z4A37y4zxy4zx2y4zA77yxyA117z3A38y4xy4x2y4A78z6xz6A118z2A39y3z2xy3z2x2y3z2A79z5xz5A119zA40y3zxy3zx2y3zA80z4xz4A1201Polynomial shapes can be used to describe a large class of shapes including the torus, the lemniscate, etc. For example, to declare a quartic surface requires that each of the coefficients (A1 ... A35) be placed in order into a single long vector of 35 terms. As an example let's define a torus the hard way. A Torus can be represented by the equation: x4 + y4 + z4 + 2 x2 y2 + 2 x2 z2 + 2 y2 z2 - 2 (r_02 + r_12) x2 + 2 (r_02 - r_12) y2 - 2 (r_02 + r_12) z2 + (r_02 - r_12)2 = 0 Where r_0 is the major radius of the torus, the distance from the hole of the donut to the middle of the ring of the donut, and r_1 is the minor radius of the torus, the distance from the middle of the ring of the donut to the outer surface. The following object declaration is for a torus having major radius 6.3 minor radius 3.5 (Making the maximum width just under 20). // Torus having major radius sqrt(40), minor radius sqrt(12) quartic { < 1, 0, 0, 0, 2, 0, 0, 2, 0, -104, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 2, 0, 56, 0, 0, 0, 0, 1, 0, -104, 0, 784 > sturm } Poly, cubic and quartics are just like quadrics in that you don't have to understand what one is to use one. The file shapesq.inc has plenty of pre-defined quartics for you to play with. Polys use highly complex computations and will not always render perfectly. If the surface is not smooth, has dropouts, or extra random pixels, try using the optional keyword sturm XE "sturm"  in the definition. This will cause a slower but more accurate calculation method to be used. Usually, but not always, this will solve the problem. If sturm doesn't work, try rotating or translating the shape by some small amount. There are really so many different polynomial shapes, we can't even begin to list or describe them all. If you are interested and mathematically inclined, an excellent reference book for curves and surfaces where you'll find more polynomial shape formulas is: "The CRC Handbook of Mathematical Curves and Surfaces" David von Seggern CRC Press, 1990 Quadric The quadric XE "quadric"  object can produce shapes like paraboloids (dish shapes) and hyperboloids (saddle or hourglass shapes). It can also produce ellipsoids, spheres, cones, and cylinders but you should use the sphere XE "sphere" , cone XE "cone" , and cylinder XE "cylinder"  objects built into POV-Ray because they are faster than the quadric version. Note that you do not confuse "quaDRic" with "quaRTic". A quadric is a 2nd order polynomial while a quartic is 4th order. Quadrics render much faster and are less error-prone but produce less complex objects. The syntax is: QUADRIC: quadric { ,,,J [OBJECT_MODIFIERS...] } Although the syntax actually will parse 3 vector expressions followed by a float, we traditionally have written the syntax as above where A through J are float expressions. These 10 float that define a surface of x, y, z points which satisfy the equation A x2 + B y2 + C z2 + D xy + E xz + F yz + G x + H y + I z + J = 0 Different values of A, B, C, ... J will give different shapes. If you take any three dimensional point and use its x, y and z coordinates in the above equation the answer will be 0 if the point is on the surface of the object. The answer will be negative if the point is inside the object and positive if the point is outside the object. Here are some examples: X2 + Y2 + Z2 - 1 = 0SphereX2 + Y2 - 1 = 0Infinite cylinder along the Z axisX2 + Y2 - Z2 = 0Infinite cone along the Z axisThe easiest way to use these shapes is to include the standard file shapes.inc into your program. It contains several pre-defined quadrics and you can transform these pre-defined shapes (using translate, rotate and scale) into the ones you want. For a complete list, see the file shapes.inc. Constructive Solid Geometry In addition to all of the primitive shapes POV-Ray supports, you can also combine multiple simple shapes into complex shapes using Constructive Solid Geometry (CSG). There are four basic types of CSG operations: union, intersection, difference, and merge. CSG objects can be composed of primitives or other CSG objects to create more, and more complex shapes. Inside and Outside Most shape primitives, like spheres, boxes and blobs divide the world into two regions. One region is inside the object and one is outside. Given any point in space you can say it's either inside or outside any particular primitive object. Well, it could be exactly on the surface but this case is rather hard to determine due to numerical problems. Even planes have an inside and an outside. By definition, the surface normal of the plane points towards the outside of the plane. You should note that triangles and triangle-based shapes cannot be used as solid objects in CSG since they have no well defined inside and outside. CSG uses the concepts of inside and outside to combine shapes together as explained in the following sections. Imagine you have two objects that partially overlap like shown in the figure below. Four different areas of points can be distinguished: points that are neither in object A nor in object B, points that are in object A but not in object B, points that are not in object A but in object B and last not least points that are in object A and object B.  Two overlapping objects. Keeping this in mind it will be quite easy to understand how the CSG operations work. When using CSG it is often useful to invert an object so that it'll be inside-out. The appearance of the object is not changed, just the way that POV-Ray perceives it. When the inverse XE "inverse"  keyword is used the inside of the shape is flipped to become the outside and vice versa. The inside/outside distinction is not important for a union XE "union" , but is important for intersection XE "intersection" , difference XE "difference" , and merge XE "merge" .Therefore any objects may be combined using union but only solid objects, i.e. objects that have a well-defined interior can be used in the other kinds of CSG. The objects described in " REF _Ref416092785 \h Finite Patch Primitives" have no well defined inside/outside. All objects described in the sections " REF _Ref416092921 \h Finite Solid Primitives" and " REF _Ref416092986 \h Infinite Solid Primitives". Union  The union of two objects. The simplest kind of CSG is the union XE "union" . The syntax is: UNION: union { OBJECTS... [OBJECT_MODIFIERS...] } Unions are simply glue used to bind two or more shapes into a single entity that can be manipulated as a single object. The image above shows the union of A and B. The new object created by the union operation can be scaled, translated and rotated as a single shape. The entire union can share a single texture but each object contained in the union may also have its own texture, which will override any texture statements in the parent object. You should be aware that the surfaces inside the union will not be removed. As you can see from the figure this may be a problem for transparent unions. If you want those surfaces to be removed you'll have to use the merge XE "merge"  operations explained in a later section. The following union will contain a box and a sphere. union { box { <-1.5, -1, -1>, <0.5, 1, 1> } cylinder { <0.5, 0, -1>, <0.5, 0, 1>, 1 } } Earlier versions of POV-Ray placed restrictions on unions so you often had to combine objects with composite XE "composite"  statements. Those earlier restrictions have been lifted so composite is no longer needed. It is still supported for backwards compatibility. Intersection The intersection XE "intersection"  object creates a shape containing only those areas where all components overlap. A point is part an intersection if it is inside both objects, A and B, as show in the figure below.  The intersection of two objects. The syntax is: INTERSECTION: intersection { SOLID_OBJECTS... [OBJECT_MODIFIERS...] } The component objects must have well defined inside/outside properties. Patch objects are not allowed. Note that if all components do not overlap, the intersection object disappears. Here is an example that overlaps: intersection { box { <-1.5, -1, -1>, <0.5, 1, 1> } cylinder { <0.5, 0, -1>, <0.5, 0, 1>, 1 } } Difference The CSG difference XE "difference"  operation takes the intersection between the first object and the inverse of all subsequent objects. Thus only points inside object A and outside object B belong to the difference of both objects. The results is a subtraction of the 2nd shape from the first shape as shown in the figure below.  The difference between two objects. The syntax is: DIFFERENCE: difference { SOLID_OBJECTS... [OBJECT_MODIFIERS...] } The component objects must have well defined inside/outside properties. Patch objects are not allowed. Note that if the first object is entirely inside the subtracted objects, the difference object disappears. Here is an example of a properly formed difference: difference { box { <-1.5, -1, -1>, <0.5, 1, 1> } cylinder { <0.5, 0, -1>, <0.5, 0, 1>, 1 } } Note that internally, POV-Ray simply adds the inverse XE "inverse"  keyword to the second (and subsequent) objects and then performs an intersection. The example above is equivalent to: intersection { box { <-1.5, -1, -1>, <0.5, 1, 1> } cylinder { <0.5, 0, -1>, <0.5, 0, 1>, 1 inverse } } Merge The union XE "union"  operation just glues objects together, it does not remove the objects' surfaces inside the union. Under most circumstances this doesn't matter. However if a transparent union is used, those interior surfaces will be visible. The merge XE "merge"  operations can be used to avoid this problem. It works just like union but it eliminates the inner surfaces like shown in the figure below.  Merge removes inner surfaces. The syntax is: MERGE: merge { SOLID_OBJECTS... [OBJECT_MODIFIERS...] } The component objects must have well defined inside/outside properties. Patch objects are not allowed. Note that merge is slower rendering than union so it should only be used when it is really necessary. Light Sources The light_source XE "light_source"  is not really an object. Light sources have no visible shape of their own. They are just points or areas which emit light. They are categorized as objects so that they can be combined with regular objects using union. Their full syntax is: LIGHT_SOURCE: light_source { , COLOR [LIGHT_MODIFIERS...] } LIGHT_MODIFIER: LIGHT_TYPE | SPOTLIGHT_ITEM | AREA_LIGHT_ITEMS | GENERAL_LIGHT_MODIFIERS LIGHT_TYPE: spotlight | shadowless | cylinder SPOTLIGHT_ITEM: radius Radius | falloff Falloff | tightness Tightness | point_at AREA_LIGHT_ITEM: area_light , , Size_1, Size_2 | adaptive Adaptive | jitter Jitter GENERAL_LIGHT_MODIFIERS: looks_like { OBJECT } | TRANSFORMATION fade_distance Fade_Distance | fade_power Fade_Power | media_attenuation [Bool] | media_interaction [Bool] The different types of light sources and the optional modifiers are described in the following sections. The first two items are common to all light sources. The vector gives the location of the light. The COLOR gives the color of the light. Only the red, green, and blue components are significant. Any transmit or filter values are ignored. Note that you vary the intensity of the light as well as the color using this parameter. A color such as rgb <0.5,0.5,0.5> gives a white light that is half the normal intensity. All of the keywords or items in the syntax specification above may appear in any order. Some keywords only have effect if specified with other keywords. The keywords are grouped into functional categories to make it clear which keywords work together. The GENERAL_LIGHT_MODIFIERS work with all types of lights and all options. Note that TRANSFORMATIONS such as translate XE "translate" , rotate XE "rotate"  etc. may be applied but no other OBJECT_MODIFIERS may be used. There are four mutually exclusive light types. If no LIGHT_TYPE is specified it is a point light. The other choices are spotlight XE "spotlight" , shadowless XE "shadowless" , and cylinder XE "cylinder" . Point Lights The simplest kid of light is a point light. A point light source sends light of the specified color uniformly in all directions. The default light type is a point source. The and COLOR is all that is required. For example: light_source { <1000,1000,-1000>, rgb <1,0.75,0> //an orange light } Spotlights Normally light radiates outward equally in all directions from the source. However the spotlight XE "spotlight"  keyword can be used to create a cone of light that is bright in the center and falls of to darkness in a soft fringe effect at the edge. Although the cone of light fades to soft edges, objects illuminated by spotlights still cast hard shadows. The syntax is: SPOTLIGHT_SOURCE: light_source { , COLOR spotlight [LIGHT_MODIFIERS...] } LIGHT_MODIFIER: SPOTLIGHT_ITEM | AREA_LIGHT_ITEMS | GENERAL_LIGHT_MODIFIERS SPOTLIGHT_ITEM: radius Radius | falloff Falloff | tightness Tightness | point_at The point_at XE "point_at"  keyword tells the spotlight to point at a particular 3D coordinate. A line from the location of the spotlight to the point_at coordinate forms the center line of the cone of light. The following illustration will be helpful in understanding how these values relate to each other.  The geometry of a spotlight. The falloff XE "falloff" , radius XE "radius" , and tightness XE "tightness"  keywords control the way that light tapers off at the edges of the cone. These four keywords apply only when the spotlight or cylinder keywords are used. The falloff keyword specifies the overall size of the cone of light. This is the point where the light falls off to zero intensity. The float value you specify is the angle, in degrees, between the edge of the cone and center line. The radius keyword specifies the size of the "hot-spot" at the center of the cone of light. The "hot-spot" is a brighter cone of light inside the spotlight cone and has the same center line. The radius value specifies the angle, in degrees, between the edge of this bright, inner cone and the center line. The light inside the inner cone is of uniform intensity. The light between the inner and outer cones tapers off to zero. For example with radius 10 and falloff 20 the light from the center line out to 10 degrees is full intensity. From 10 to 20 degrees from the center line the light falls off to zero intensity. At 20 degrees or greater there is no light. Note that if the radius and falloff values are close or equal the light intensity drops rapidly and the spotlight has a sharp edge. The default values for both radius and falloff is 70. The values for these two parameters are half the opening angles of the corresponding cones, both angles have to be smaller than 90 degrees. The light smoothly falls off between the radius and the falloff angle like shown in the figures below (as long as the radius angle is not negative).  Intensity multiplier curve with a fixed falloff angle of 45 degrees.  Intensity multiplier curve with a fixed radius angle of 45 degrees. The tightness keyword is used to specify an additional exponential softening of the edges. The intensity of light at an angle from the center line is given by: intensity * cos(angle)tightness. The default value for tightness is 10. Lower tightness values will make the spotlight brighter, making the spot wider and the edges sharper. Higher values will dim the spotlight, making the spot tighter and the edges softer. Values from 1 to 100 are acceptable.  Intensity multiplier curve with fixed angle and falloff angles of 30 and 60 degrees respectively and different tightness values. You should note from the figures that the radius and falloff angles interact with the tightness parameter. Only negative radius angles will give the tightness value full control over the spotlight's appearance as you can see from the figure below. In that case the falloff angle has no effect and the lit area is only determined by the tightness parameter.  Intensity multiplier curve with a negative radius angle and different tightness values. Spotlights may be used anyplace that a normal light source is used. Like any light sources, they are invisible. They may also be used in conjunction with area lights. Cylindrical Lights The cylinder XE "cylinder"  keyword specifies a cylindrical light source that is great for simulating laser beams. Cylindrical light sources work pretty much like spotlights except that the light rays are constrained by a cylinder and not a cone. The syntax is: CYLINDER_LIGHT_SOURCE: light_source { , COLOR cylinder [LIGHT_MODIFIERS...] } LIGHT_MODIFIER: SPOTLIGHT_ITEM | AREA_LIGHT_ITEMS | GENERAL_LIGHT_MODIFIERS SPOTLIGHT_ITEM: radius Radius | falloff Falloff | tightness Tightness | point_at The point_at, radius, falloff and tightness keywords control the same features as with the spotlight. See " REF _Ref416105656 \h Spotlights" for details. You should keep in mind that the cylindrical light source is still a point light source. The rays are emitted from one point and are only constraint by a cylinder. The light rays are not parallel. Area Lights Area light sources occupy a finite, one- or two-dimensional area of space. They can cast soft shadows because an object can partially block their light. Point sources are either totally blocked or not blocked. The area_light XE "area_light"  keyword in POV-Ray creates sources that are rectangular in shape, sort of like a flat panel light. Rather than performing the complex calculations that would be required to model a true area light, it is approximated as an array of point light sources spread out over the area occupied by the light. The array-effect applies to shadows only. The object's illumination is still that of a point source. The intensity of each individual point light in the array is dimmed so that the total amount of light emitted by the light is equal to the light color specified in the declaration. The syntax is: AREA_LIGHT_SOURCE: light_source { , COLOR area_light , , Size_1, Size_2 [adaptive Adaptive] [ jitter Jitter ] [LIGHT_MODIFIERS...] } The light's location and color are specified in the same way as a for a regular light source. Any type of light source may be an area light. The area_light command defines the size and orientation of the area light as well as the number of lights in the light source array. The vectors and specify the lengths and directions of the edges of the light. Since the area lights are rectangular in shape these vectors should be perpendicular to each other. The larger the size of the light the thicker the soft part of shadows will be. The integers Size_1 and Size_2 specify the number of rows and columns of point sources of the. The more lights you use the smoother your shadows will be but the longer they will take to render. Note that it is possible to specify spotlight parameters along with the area light parameters to create area spotlights. Using area spotlights is a good way to speed up scenes that use area lights since you can confine the lengthy soft shadow calculations to only the parts of your scene that need them. An interesting effect can be created using a linear light source. Rather than having a rectangular shape, a linear light stretches along a line sort of like a thin fluorescent tube. To create a linear light just create an area light with one of the array dimensions set to 1. The jitter XE "jitter"  command is optional. When used it causes the positions of the point lights in the array to be randomly jittered to eliminate any shadow banding that may occur. The jittering is completely random from render to render and should not be used when generating animations. The adaptive XE "adaptive"  command is used to enable adaptive sampling of the light source. By default POV-Ray calculates the amount of light that reaches a surface from an area light by shooting a test ray at every point light within the array. As you can imagine this is very slow. Adaptive sampling on the other hand attempts to approximate the same calculation by using a minimum number of test rays. The number specified after the keyword controls how much adaptive sampling is used. The higher the number the more accurate your shadows will be but the longer they will take to render. If you're not sure what value to use a good starting point is adaptive 1. The adaptive keyword only accepts integer values and cannot be set lower than 0. When performing adaptive sampling POV-Ray starts by shooting a test ray at each of the four corners of the area light. If the amount of light received from all four corners is approximately the same then the area light is assumed to be either fully in view or fully blocked. The light intensity is then calculated as the average intensity of the light received from the four corners. However, if the light intensity from the four corners differs significantly then the area light is partially blocked. The area light is split into four quarters and each section is sampled as described above. This allows POV-Ray to rapidly approximate how much of the area light is in view without having to shoot a test ray at every light in the array. Visually the sampling goes like shown below.  Area light adaptive samples. While the adaptive sampling method is fast (relatively speaking) it can sometimes produces inaccurate shadows. The solution is to reduce the amount of adaptive sampling without completely turning it off. The number after the adaptive keyword adjusts the number of times that the area light will be split before the adaptive phase begins. For example if you use adaptive 0 a minimum of 4 rays will be shot at the light. If you use adaptive 1 a minimum of 9 rays will be shot (adaptive 2 gives 25 rays, adaptive 3 gives 81 rays, etc). Obviously the more shadow rays you shoot the slower the rendering will be so you should use the lowest value that gives acceptable results. The number of rays never exceeds the values you specify for rows and columns of points. For example area_light x,y,4,4 specifies a 4 by 4 array of lights. If you specify adaptive 3 it would mean that you should start with a 9 by 9 array. In this case no adaptive sampling is done. The 4 by 4 array is used. Shadowless Lights Using the shadowless XE "shadowless"  keyword you can stop a light source from casting shadows. These lights are sometimes called "fill lights". They are another way to simulate ambient light however shadowless lights have a definite source. The syntax is: SHADOWLESS_LIGHT_SOURCE: light_source { , COLOR shadowless [LIGHT_MODIFIERS...] } LIGHT_MODIFIER: AREA_LIGHT_ITEMS | GENERAL_LIGHT_MODIFIERS Shadowless may be used with area_light XE "area_light"  but not spotlight XE "spotlight"  or cylinder XE "cylinder" . Looks_like Normally the light source itself has no visible shape. The light simply radiates from an invisible point or area. You may give a light source any shape by adding a looks_like { OBJECT } statement. There is an implied no_shadow XE "no_shadow"  attached to the looks_like object so that light is not blocked by the object. Without the automatic no_shadow the light inside the object would not escape. The object would, in effect, cast a shadow over everything. If you want the attached object to block light then you should attach it with a union XE "union"  and not a looks_like as follows: union { light_source { <100, 200, -300> color White } object { My_Lamp_Shape } } Presumably parts of the lamp shade are transparent to let some light out. Light Fading By default POV-Ray does not diminish light from any light source as it travels through space. In order to get a more realistic effect fade_distance XE "fade_distance"  and fade_power XE "fade_power"  keywords followed by float values can be used to model the distance based falloff in light intensity. The fade_distance Fade_Distance is used to specify the distance at which the full light intensity arrives, i. e. the intensity which was given by the COLOR specification. The actual attenuation is described by the fade_power Fade_Power, which determines the falloff rate. For example linear or quadratic falloff can be used by setting fade_power to 1 or 2 respectively. The complete formula to calculate the factor by which the light is attenuated is  with d being the distance the light has traveled.  Light fading functions for different fading powers. You should note two important facts: First, for Fade_Distance larger than one the light intensity at distances smaller than Fade_Distance actually increases. This is necessary to get the light source color if the distance traveled equals the Fade_Distance. Second, only light coming directly from light sources is attenuated. Reflected or refracted light is not attenuated by distance. Atmospheric Media Interaction By default light sources will interact with an atmosphere added to the scene. This behaviour can be switched off by using media_interaction XE "media_interaction"  off keyword inside the light source statement. Note in POV-Ray 3.0 this feature was turned off and on with the atmosphere XE "atmosphere"  keyword. Atmospheric Attenuation Normally light coming from light sources is not influenced by fog or atmospheric media. This can be changed by turning the media_attenuation XE "media_attenuation"  on for a given light source on. All light coming from this light source will now be diminished as it travels through the fog or media. This results in an distance-based, exponential intensity falloff ruled by the used fog or media. If there is no fog or media no change will be seen. Note in POV-Ray 3.0 this feature was turned off and on with the atmospheric_attenuation XE "atmospheric_attenuation"  keyword. Object Modifiers A variety of modifiers may be attached to objects. The following items may be applied to any object: OBJECT_MODIFIER: clipped_by { UNTEXTURED_SOLID_OBJECT... } | clipped_by { bounded_by } | bounded_by { UNTEXTURED_SOLID_OBJECT... } | bounded_by { clipped_by } | no_shadow | inverse | sturm [ Bool ] | hierarchy [ Bool ] | interior { INTERIOR_ITEMS... } | material { [MATERIAL_IDENTIFIER][MATERIAL_ITEMS...] } | texture { TEXTURE_BODY } | pigment { PIGMENT_BODY } | normal { NORMAL_BODY } | finish { FINISH_ITEMS... } | TRANSFORMATION Transformations such as translate, rotate and scale have already been discussed. The modifiers " REF _Ref416274068 \h Textures" and its parts " REF _Ref416591760 \h Pigment", " REF _Ref416591806 \h Normal", and " REF _Ref416591872 \h Finish" as well as " REF _Ref416274104 \h Interior", and " REF _Ref413750547 \h Media" (which is part of interior) are each in major chapters of their own below. In the sub-sections below we cover several other important modifiers: clipped_by XE "clipped_by" , bounded_by XE "bounded_by" , material XE "material" , no_shadow XE "no_shadow" , hollow XE "hollow" , inverse XE "inverse" , sturm XE "sturm" , and hierarchy XE "hierarchy" . Although the examples below use object statements and object identifiers, these modifiers may be used on any type of object such as sphere, box etc. Clipped_By The clipped_by XE "clipped_by"  statement is technically an object modifier but it provides a type of CSG similar to CSG intersection. The syntax is: CLIPPED_BY: clipped_by { UNTEXTURED_SOLID_OBJECT... } | clipped_by { bounded_by } Where UNTEXTURED_SOLID_OBJECT is one or more solid objects which have had no texture applied. For example: object { My_Thing clipped_by{plane{y,0}} } Every part of the object My_Thing that is inside the plane is retained while the remaining part is clipped off and discarded. In an intersection XE "intersection"  object the hole is closed off. With clipped_by it leaves an opening. For example the following figure shows object A being clipped by object B.  An object clipped by another object. You may use clipped_by to slice off portions of any shape. In many cases it will also result in faster rendering times than other methods of altering a shape. Occasionally you will want to use the clipped_by and bounded_by XE "bounded_by"  options with the same object. The following shortcut saves typing and uses less memory. object { My_Thing bounded_by { box { <0,0,0>, <1,1,1> } } clipped_by { bounded_by } } This tells POV-Ray to use the same box as a clip that was used as a bounds. Bounded_By The calculations necessary to test if a ray hits an object can be quite time consuming. Each ray has to be tested against every object in the scene. POV-Ray attempts to speed up the process by building a set of invisible boxes, called bounding boxes, which cluster the objects together. This way a ray that travels in one part of the scene doesn't have to be tested against objects in another, far away part of the scene. When large a number of objects are present the boxes are nested inside each other. POV-Ray can use bounding boxes on any finite object and even some clipped or bounded quadrics. However infinite objects (such as a planes, quartic, cubic and poly) cannot be automatically bound. CSG objects are automatically bound if they contain finite (and in some cases even infinite) objects. This works by applying the CSG set operations to the bounding boxes of all objects used inside the CSG object. For difference and intersection operations this will hardly ever lead to an optimal bounding box. It's sometimes better (depending on the complexity of the CSG object) to have you place a bounding shape yourself using a bounded_by XE "bounded_by"  statement. Normally bounding shapes are not necessary but there are cases where they can be used to speed up the rendering of complex objects. Bounding shapes tell the ray-tracer that the object is totally enclosed by a simple shape. When tracing rays, the ray is first tested against the simple bounding shape. If it strikes the bounding shape the ray is further tested against the more complicated object inside. Otherwise the entire complex shape is skipped, which greatly speeds rendering. The syntax is: BOUNDED_BY: bounded_by { UNTEXTURED_SOLID_OBJECT... } | bounded_by { clipped_by } Where UNTEXTURED_SOLID_OBJECT is one or more solid objects which have had no texture applied. For example: intersection { sphere { <0,0,0>, 2 } plane { <0,1,0>, 0 } plane { <1,0,0>, 0 } bounded_by { sphere { <0,0,0>, 2 } } } The best bounding shape is a sphere or a box since these shapes are highly optimized, although, any shape may be used. If the bounding shape is itself a finite shape which responds to bounding slabs then the object which it encloses will also be used in the slab system. While it may a good idea to manually add a bounded_by to intersection, difference and merge, it is best to never bound a union. If a union has no bounded_by POV-Ray can internally split apart the components of a union and apply automatic bounding slabs to any of its finite parts. Note that some utilities such as raw2pov may be able to generate bounds more efficiently than POV-Ray's current system. However most unions you create yourself can be easily bounded by the automatic system. For technical reasons POV-Ray cannot split a merge object. It is may be best to hand bound a merge, especially if it is very complex. Note that if bounding shape is too small or positioned incorrectly it may clip the object in undefined ways or the object may not appear at all. To do true clipping, use clipped_by XE "clipped_by"  as explained in the previous section. Occasionally you will want to use the clipped_by and bounded_by options with the same object. The following shortcut saves typing and uses less memory. object { My_Thing clipped_by{ box { <0,0,0>,<1,1,1 > }} bounded_by{ clipped_by } } This tells POV-Ray to use the same box as a bounds that was used as a clip. Material One of the changes in POV-Ray 3.1 was remove several items from texture{finish{...}} and to move them to the new interior XE "interior"  statement. The halo XE "halo"  statement, formerly part of texture XE "texture" , are now renamed media XE "media"  and made a part of the interior. This split was deliberate and purposeful (see " REF _Ref417286060 \h Why are Interior and Media Necessary?") however beta testers have pointed out that it makes it difficult to entirely describe the surface properties and interior of an object in one statement that can be referenced by a single identifier in a texture library. The result is that we created a "wrapper" around texture and interior which we call material. The syntax is: MATERIAL: material { [MATERIAL_IDENTIFIER][MATERIAL_ITEMS...] } MATERIAL_ITEMS: TEXTURE | INTERIOR | TRANSFORMATIONS For example: #declare MyGlass=material{texture{Glass_T} interior{Glass_I}} object{MyObject material{MyGlass}} Internally, the "material" isn't attached to the object. The material is just a container that brings the texture and interior to the object. It is the texture and interior itself that is attached to the object. Users should still consider texture and interior as separate items attached to the object. The material is just a "bucket" to carry them. If the object already has a texture, the material texture is layered over it. If the object already has an interior, the material interior fully replaces it and the old interior is destroyed. Transformations inside the material affect only the textures and interiors which are inside the material{} wrapper and only those textures or interiors specifed are affected. For example: object{MyObject material{ texture{MyTexture} scale 4 //affects texture but not object or interior interior{MyInterior} translate 5*x //affects texture and interior, not object } } Note: The material statement has nothing to do with the material_map XE "material_map"  statement. A material_map is not a way to create patterned material. See " REF _Ref428017081 \h Material Maps" for explanation of this unrelated, yet similarly named, older feature. Inverse When using CSG it is often useful to invert an object so that it'll be inside-out. The appearance of the object is not changed, just the way that POV-Ray perceives it. When the inverse XE "inverse"  keyword is used the inside of the shape is flipped to become the outside and vice versa. For example: object { MyObject inverse } The inside/outside distinction is also important when attaching interior XE "interior"  to an object especially if media XE "media"  is also used. Atmospheric media and fog also do not work as expected if your camera is inside an object. Using inverse is useful to correct that problem. Finally the internal_reflections XE "internal_reflections"  and internal_highlights XE "internal_highlights"  keywords depend upon the inside/outside status of an object. Hollow POV-Ray by default assumes that objects are made of a solid material that completely fills the interior of an object. By adding the hollow XE "hollow"  keyword to the object you can make it hollow. That is very useful if you want atmospheric effects to exist inside an object. It is even required for objects containing an interior media. The keyword may optionally be followed by a float expression which is interpreted as a boolean value. For example hollow off may be used to force it off. When the keyword is specified alone, it is the same as hollow on. The default no hollow is specified is off. In order to get a hollow CSG object you just have to make the top level object hollow. All children will assume the same hollow state except their state is explicitly set. The following example will set both spheres inside the union hollow union { sphere { -0.5*x, 1 } sphere { 0.5*x, 1 } hollow } while the next example will only set the second sphere hollow because the first sphere was explicitly set to be not hollow. union { sphere { -0.5*x, 1 hollow off } sphere { 0.5*x, 1 } hollow on } No_Shadow You may specify the no_shadow XE "no_shadow"  keyword in an object to make that object cast no shadow. This is useful for special effects and for creating the illusion that a light source actually is visible. This keyword was necessary in earlier versions of POV-Ray which did not have the looks_like XE "looks_like"  statement. Now it is useful for creating things like laser beams or other unreal effects. During test rendering it speeds things up if no_shadow is applied. Simply attach the keyword as follows: object { My_Thing no_shadow } Sturm Some of POV-Ray's objects allow you to choose between a fast but sometimes inaccurate root solver and a slower but more accurate one. This is the case for all objects that involve the solution of a cubic or quartic polynomial. There are analytic mathematical solutions for those polynomials that can be used. Lower order polynomials are trivial to solve while higher order polynomials require iterative algorithms to solve them. One of those algorithms is the Sturmian root solver. For example: blob { threshold .65 sphere { <.5,0,0>, .8, 1 } sphere { <-.5,0,0>,.8, 1 } sturm } The keyword may optionally be followed by a float expression which is interpreted as a boolean value. For example sturm off may be used to force it off. When the keyword is specified alone, it is the same as sturm on. The default no sturm is specified is off. The following list shows all objects for which the Sturmian root solver can be used. blob cubic lathe (only with quadratic splines) poly prism (only with cubic splines) quartic sor Interior New with POV-Ray 3.1 is an object modifier statement called interior XE "interior" . The syntax is: INTERIOR: interior { [INTERIOR_IDENTIFIER] [INTERIOR_ITEMS...] } INTERIOR_ITEM: ior Value | caustics Value | fade_distance Distance | fade_power Power MEDIA... The interior contains items which describe the properties of the interior of the object. This is in contrast to the texture XE "texture"  which describes the surface properties only. The interior of an object is only of interest if it has a transparent texture which allows you to see inside the object. It also applies only to solid objects which have a well-defined inside/outside distinction. Note that the open XE "open"  keyword, or clipped_by XE "clipped_by"  modifier also allows you to see inside but interior features may not render properly. They should be avoided if accurate interiors are required. Interior identifiers may be declared to make scene files more readable and to parameterize scenes so that changing a single declaration changes many values. An identifier is declared as follows. INTERIOR_DECLARATION: #declare IDENTIFIER = INTERIOR | #local IDENTIFIER = INTERIOR Where IDENTIFIER is the name of the identifier up to 40 characters long and INTERIOR is any valid interior statement. See " REF _Ref412711267 \h #declare vs. #local" for information on identifier scope. Why are Interior and Media Necessary? In previous versions of POV-Ray, most of the items in the interior XE "interior"  statement were previously part of the finish XE "finish"  statement. Also the halo XE "halo"  statement which was once part of the texture XE "texture"  statement has been discontinued and has been replaced by the media XE "media"  statement which is part of interior. You are probably asking WHY? As explained earlier, the interior contains items which describe the properties of the interior of the object. This is in contrast to the texture which describes the surface properties only. However this is not just a philosophical change. There were serious inconsistencies in the old model. The main problem arises when a texture_map XE "texture_map"  or other patterned texture is used. These features allow you to create textures that are a blend of two textures and which vary the entire texture from one point to another. It does its blending by fully evaluating the apparent color as though only one texture was applied and then fully reevaluating it with the other texture. The two final results are blended. It is totally illogical to have a ray enter an object with one index or refraction and then recalculate with another index. The result is not an average of the two ior values. Similarly it makes no sense to have a ray enter at one ior and exit at a different ior without transitioning between them along the way. POV-Ray only calculates refraction as the ray enters or leaves. It cannot incrementally compute a changing ior through the interior of an object. Real world objects such as optical fibers or no-line bifocal eyeglasses can have variable iors but POV-Ray cannot simulate them. Similarly the halo calculations were not performed as the syntax implied. Using a halo in such multi-textured objects did not vary the halo through the interior of the object. Rather, it computed two separate halos through the whole object and averaged the results. The new design for media which replaces halo makes it possible to have media that varies throughout the interior of the object according to a pattern but it does so independently of the surface texture. Because there are other changes in the design of this feature which make it significantly different, it was not only moved to the interior but the name was changed. During our development, someone asked if we will create patterned interiors or a hypothetical interior_map feature. We will not. That would defeat the whole purpose of moving these features in the first place. They cannot be patterned and have logical or self-consistent results. Empty and Solid Objects It is very important that you know the basic concept behind empty and solid objects in POV-Ray to fully understand how features like interior and translucency are used. Objects in POV-Ray can either be solid, empty or filled with (small) particles. A solid object is made from the material specified by its pigment and finish statements (and to some degree its normal statement). By default all objects are assumed to be solid. If you assign a stone texture to a sphere you'll get a ball made completely of stone. It's like you had cut this ball from a block of stone. A glass ball is a massive sphere made of glass. You should be aware that solid objects are conceptual things. If you clip away parts of the sphere you'll clearly see that the interior is empty and it just has a very thin surface. This is not contrary to the concept of a solid object used in POV-Ray. It is assumed that all space inside the sphere is covered by the sphere's interior XE "interior" . Light passing through the object is affected by attenuation and refraction properties. However there is no room for any other particles like those used by fog or interior media. Empty objects are created by adding the hollow XE "hollow"  keyword (see " REF _Ref416607008 \h Hollow") to the object statement. An empty (or hollow) object is assumed to be made of a very thin surface which is of the material specified by the pigment, finish and normal statements. The object's interior is empty, it normally contains air molecules. An empty object can be filled with particles by adding fog or atmospheric media to the scene or by adding an interior media to the object. It is very important to understand that in order to fill an object with any kind of particles it first has to be made hollow. There is a pitfall in the empty/solid object implementation that you have to be aware of. In order to be able to put solid objects inside a media or fog, a test has to be made for every ray that passes through the media. If this ray travels through a solid object the media will not be calculated. This is what anyone will expect. A solid glass sphere in a fog bank does not contain fog. The problem arises when the camera ray is inside any non-hollow object. In this case the ray is already traveling through a solid object and even if the media's container object is hit and it is hollow, the media will not be calculated. There is no way of telling between these two cases. POV-Ray has to determine whether the camera is inside any object prior to tracing a camera ray in order to be able to correctly render medias when the camera is inside the container object. There's no way around doing this. The solution to this problem (that will often happen with infinite objects like planes) is to make those objects hollow too. Thus the ray will travel through a hollow object, will hit the container object and the media will be calculated. Refraction When light passes through a surface either into or out of a dense medium the path of the ray of light is bent. Such bending is called refraction. The amount of bending or refracting of light depends upon the density of the material. Air, water, crystal and diamonds all have different densities and thus refract differently. The index of refraction or ior value is used by scientists to describe the relative density of substances. The ior XE "ior"  keyword is used in POV-Ray in the interior XE "interior"  to turn on refraction and to specify the ior value. For example: object{ MyObject pigment{Clear} interior{ior 1.5}} The default ior value of 1.0 will give no refraction. The index of refraction for air is 1.0, water is 1.33, glass is 1.5 and diamond is 2.4. Normally transparent or semi-transparent surfaces in POV-Ray do not refract light. Earlier versions of POV-Ray required you to use the refraction XE "refraction"  keyword in the finish XE "finish"  statement to turn on refraction. This is no longer necessary. Any non-zero ior value now turns refraction on. In addition to turning refraction on or off, the old refraction keyword was followed by a float value from 0.0 to 1.0. Values in between 0.0 and 1.0 would darken the refracted light in ways that do not correspond to any physical property. Many POV-Ray scenes were created with intermediate refraction values before this bug was discovered so the feature has been maintained. A more appropriate way to reduce the brightness of refracted light is to change the filter XE "filter"  or transmit XE "transmit"  value in the colors specified in the pigment statement or to use the fade_power XE "fade_power"  and fade_distance XE "fade_distance"  keywords. See " REF _Ref417128162 \h Attenuation". Note also that neither the ior nor refraction keywords cause the object to be transparent. Transparency only occurs if there is a non-zero filter or transmit value in the color. The refraction and ior keywords were original specified in finish but are now properly specified in interior. They are accepted in finish for backward compatibility and generate a warning message. Attenuation Light attenuation is used to model the decrease in light intensity as the light travels through a transparent object. The keywords fade_power XE "fade_power"  Fade_Power and fade_distance XE "fade_distance"  Fade_Distance keywords are specified in the interior XE "interior"  statement. The fade_distance value determines the distance the light has to travel to reach half intensity while the fade_power value determines how fast the light will fall off. For realistic effects a fade power of 1 to 2 should be used. Default values for both keywords is 0.0 which turns this feature off. The attenuation is calculated by a formula similar to that used for light source attenuation.  The fade_power and fade_distance keywords were original specified in finish but are now properly specified in interior. They are accepted in finish for backward compatibility and generate a warning message. Faked Caustics Caustics are light effects that occur if light is reflected or refracted by specular reflective or refractive surfaces. Imagine a glass of water standing on a table. If sunlight falls onto the glass you will see spots of light on the table. Some of the spots are caused by light being reflected by the glass while some of them are caused by light being refracted by the water in the glass. Since it is a very difficult and time-consuming process to actually calculate those effects (though it is not impossible) POV-Ray uses a quite simple method to simulate caustics caused by refraction. The method calculates the angle between the incoming light ray and the surface normal. Where they are nearly parallel it makes the shadow brighter. Where the angle is greater, the effect is diminished. Unlike real-world caustics, the effect does not vary based on distance. This caustic effect is limited to areas that are shaded by the transparent object. You'll get no caustic effects from reflective surfaces nor in parts that are not shaded by the object. The caustics XE "caustics"  Power keyword controls the effect. Values typically range from 0.0 to 1.0 or higher. Zero is the default which is no caustics. Low, non-zero values give broad hot-spots while higher values give tighter, smaller simulated focal points. The caustics keyword was originally specified in finish but is now properly specified in interior. It is accepted in finish for backward compatibility and generates a warning message. Object Media The interior XE "interior" statement may contain one or more media XE "media"  statements. Media is used to simulate suspended particles such as smoke, haze, or dust. Or visible gasses such as steam or fire and explosions. When used with an object interior, the effect is constrained by the object's shape. The calculations begin when the ray enters an object and ends when it leaves the object. This section only discusses media when used with object interior. The complete syntax and an explanation of all of the parameters and options for media is given in the section " REF _Ref413750547 \h Media". Typically the object itself is given a fully transparent texture however media also works in partially transparent objects. The texture pattern itself does not effect the interior media except perhaps to create shadows on it. The texture pattern of an object applies only to the surface shell. Any interior media patterns are totally independent of the texture. In previous versions of POV-Ray, this feature was called halo XE "halo"  and was part of the texture XE "texture"  specification along with pigment XE "pigment" , normal XE "normal" , and finish XE "finish" . See " REF _Ref417286060 \h Why are Interior and Media Necessary?" for an explanation of the reasons for the change. Note a strange design side-effect was discovered during testing and it was too difficult to fix. If the enclosing object uses transmit XE "transmit"  rather than filter XE "filter"  for transparency, then the media casts no shadows. For example: object{MyObject pigment{rgbt 1.0} interior{media{MyMedia}}} //no shadows object{MyObject pigment{rgbf 1.0} interior{media{MyMedia}}} //shadows Media may also be specified outside an object to simulate atmospheric media. There is no constraining object in this case. If you only want media effects in a particular area, you should use object media rather than only relying upon the media pattern. In general it will be faster and more accurate because it only calculates inside the constraining object. See " REF _Ref417287116 \h Atmospheric Media" for details on unconstrained uses of media. You may specify more than one media statement per interior statement. In that case, all of the media participate and where they overlap, they add together. Any object which is supposed to have media effects inside it, whether those effects are object media or atmospheric media, must have the hollow XE "hollow"  on keyword applied. Otherwise the media is blocked. See " REF _Ref417287889 \h Empty and Solid Objects" for details. Textures The texture XE "texture"  statement is an object modifier which describes what the surface of an object looks like, i.e. its material. Textures are combinations of pigments, normals, and finishes. Pigment is the color or pattern of colors inherent in the material. Normal is a method of simulating various patterns of bumps, dents, ripples or waves by modifying the surface normal vector. Finish describes the reflective properties of a material. Note that in previous versions of POV-Ray, the texture also contained information about the interior of an object. This information has been moved to a separate object modifier called interior XE "interior" . See " REF _Ref417290349 \h Interior" for details. There are three basic kinds of textures: plain, patterned, and layered. A plain texture consists of a single pigment, an optional normal, and a single finish. A patterned texture combines two or more textures using a block pattern or blending function pattern. Patterned textures may be made quite complex by nesting patterns within patterns. At the innermost levels however, they are made up from plain textures. A layered texture consists of two or more semi-transparent textures layered on top of one another. Note that although we call a plain texture plain it may be a very complex texture with patterned pigments and normals. The term plain only means that it has a single pigment, normal, and finish. The syntax for texture is as follows: TEXTURE: PLAIN_TEXTURE | PATTERNED_TEXTURE | LAYERED_TEXTURE PLAIN_TEXTURE: texture { [TEXTURE_IDENTIFIER] [PNF_IDENTIFIER...] [PNF_ITEMS...] } PNF_IDENTIFIER: PIGMENT_IDENTIFIER | NORMAL_IDENTIFIER | FINISH_IDENTIFIER PNF_ITEMS: PIGMENT | NORMAL | FINISH | TRANSFORMATION LAYERED_TEXTURE: NON_PATTERNED_TEXTURE... PATTERNED_TEXTURE: texture { [PATTERNED_TEXTURE_ID] [TRANSFORMATIONS...] } | texture { PATTERN_TYPE [TEXTURE_PATTERN_MODIFIERS...] } | texture { tiles TEXTURE tile2 TEXTURE [TRANSFORMATIONS...] } | texture { material_map{ BITMAP_TYPE "bitmap.ext" [MATERIAL_MODS...] TEXTURE... [TRANSFORMATIONS...] } } TEXTURE_PATTERN_MODIFIER: PATTERN_MODIFIER | TEXTURE_LIST | texture_map{ TEXTURE_MAP_BODY } In the PLAIN_TEXTURE, each of the items are optional but if they are present the TEXTURE_IDENTIFIER must be first. If no texture identifier is given, then POV-Ray creates a copy of the default texture. See " REF _Ref417299112 \h The #default Directive" for details. Next are optional pigment, normal, and/or finish identifiers which fully override the any pigment, normal and finish already specified in the previous texture identifier or default texture. Typically this is used for backward compatibility to allow things like: texture{MyPigment} where MyPigment is a pigment identifier. Finally we have optional pigment XE "pigment" , normal XE "normal"  or finish XE "finish"  statements which modify any pigment, normal and finish already specified in the identifier. If no texture identifier is specified the pigment, normal and finish statements modify the current default values. This is the typical plain texture: texture{ pigment{MyPigment} normal{MyNormal} finish{MyFinish} scale SoBig rotate SoMuch translate SoFar } The TRANSFORMATIONS may be interspersed between the pigment, normal and finish statements but are generally specified last. If they are interspersed, then they modify only those parts of the texture already specified. For example: texture{ pigment{MyPigment} scale SoBig //affects pigment only normal{MyNormal} rotate SoMuch //affects pigment and normal finish{MyFinish} translate SoFar //finish is never transformable no matter what. //Therefore affects pigment and normal only } Texture identifiers may be declared to make scene files more readable and to parameterize scenes so that changing a single declaration changes many values. An identifier is declared as follows. TEXTURE_DECLARATION: #declare IDENTIFIER = TEXTURE | #local IDENTIFIER = TEXTURE Where IDENTIFIER is the name of the identifier up to 40 characters long and TEXTURE is any valid texture statement. See " REF _Ref412711267 \h #declare vs. #local" for information on identifier scope. The sections below describe all of the options available in " REF _Ref417300511 \h Pigment", " REF _Ref417300541 \h Normal", and " REF _Ref417300575 \h Finish" which are the main part of plain textures.. There are also separate sections for " REF _Ref417301436 \h Patterned Textures" and " REF _Ref417301568 \h Layered Textures" which are made up of plain textures. Note that the tiles XE "tiles"  and material_map XE "material_map"  versions of patterned textures are obsolete and are only supported for backwards compatibility. Pigment The color or pattern of colors for an object is defined by a pigment XE "pigment"  statement. All plain textures must have a pigment. If you do not specify one the default pigment is used. The color you define is the way you want the object to look if fully illuminated. You pick the basic color inherent in the object and POV-Ray brightens or darkens it depending on the lighting in the scene. The parameter is called pigment because we are defining the basic color the object actually is rather than how it looks. The syntax for pigment is: PIGMENT: pigment{ [PIGMENT_IDENTIFIER] [PIGMENT_TYPE] [PIGMENT_MODIFIER...] } PIGMENT_TYPE: PATTERN_TYPE | COLOR | image_map{ BITMAP_TYPE "bitmap.ext" [IMAGE_MAP_MODS...] } PIGMENT_MODIFIER: PATTERN_MODIFIER | COLOR_LIST | PIGMENT_LIST | color_map{ COLOR_MAP_BODY } | colour_map{ COLOR_MAP_BODY } | pigment_map{ PIGMENT_MAP_BODY } | quick_color COLOR | quick_colour COLOR Each of the items in a pigment are optional but if they are present, they must be in the order shown. Any items after the PIGMENT_IDENTIFIER modify or override settings given in the identifier. If no identifier is specified then the items modify the pigment values in the current default texture. The PIGMENT_TYPE fall into roughly four categories. Each category is discussed the sub-sections which follow. The four categories are solid color and image map patterns which are specific to pigment statements or color list patterns, color mapped patterns which use POV-Ray's wide selection of general patterns. See " REF _Ref417310251 \h Patterns" for details about specific patterns. The pattern type is optionally followed by one or more pigment modifiers. In addition to general pattern modifiers such as transformations, turbulence, and warp modifiers, pigments may also have a COLOR_LIST, PIGMENT_LIST, color_map XE "color_map" , pigment_map XE "pigment_map" , and quick_color XE "quick_color"  which are specific to pigments. See " REF _Ref417310705 \h Pattern Modifiers" for information on general modifiers. The pigment-specific modifiers are described in sub-sections which follow. Pigment modifiers of any kind apply only to the pigment and not to other parts of the texture. Modifiers must be specified last. A pigment statement is part of a texture XE "texture"  specification. However it can be tedious to use a texture statement just to add a color to an object. Therefore you may attach a pigment directly to an object without explicitly specifying that it as part of a texture. For example instead of this: object {My_Object texture{pigment{color Red}}} you may shorten it to: object {My_Object pigment{color Red}} Note however that doing so creates an entire texture structure with default normal XE "normal"  and finish XE "finish"  statements just as if you had explicitly typed the full texture{...} around it. Pigment identifiers may be declared to make scene files more readable and to parameterize scenes so that changing a single declaration changes many values. An identifier is declared as follows. PIGMENT_DECLARATION: #declare IDENTIFIER = PIGMENT | #local IDENTIFIER = PIGMENT Where IDENTIFIER is the name of the identifier up to 40 characters long and PIGMENT is any valid pigment statement. See " REF _Ref412711267 \h #declare vs. #local" for information on identifier scope. Solid Color Pigments The simplest type of pigment is a solid color. To specify a solid color you simply put a color specification inside a pigment XE "pigment"  statement. For example: pigment {color Orange} A color specification consists of the optional keyword color XE "color"  followed by a color identifier or by a specification of the amount of red, green, blue, filtered and unfiltered transparency in the surface. See section " REF _Ref413394014 \h Specifying Colors" for more details about colors. Any pattern modifiers used with a solid color are ignored because there is no pattern to modify. Color List Pigments There are three color list patterns: checker XE "checker" , hexagon XE "hexagon"  and brick XE "brick" . The result is a pattern of solid colors with distinct edges rather than a blending of colors as with color mapped patterns. Each of these patterns is covered in more detail in a later section. The syntax is: COLOR_LIST_PIGMENT: pigment{brick [COLOR_1, [COLOR_2]] [PIGMENT_MODIFIERS...] } | pigment{checker [COLOR_1, [COLOR_2]] [PIGMENT_MODIFIERS...] } | pigment{hexagon [COLOR_1, [COLOR_2, [COLOR_3]]] [PIGMENT_MODIFIERS...] } Each COLOR_n is any valid color specification. There should be a comma between each color or the color keyword should be used as a separator so that POV-Ray can determine where each color specification starts and ends. The brick and checker pattern expects two colors and hexagon expects three. If an insufficient number of colors is specified then default colors are used. Color Maps Most of the color patterns do not use abrupt color changes of just two or three colors like those in the brick, checker or hexagon patterns. They instead use smooth transitions of many colors that gradually change from one point to the next. The colors are defined in a pigment modifier called a color_map XE "color_map"  that describes how the pattern blends from one color to the next. Each of the various pattern types available is in fact a mathematical function that takes any x, y, z location and turns it into a number between 0.0 and 1.0 inclusive. That number is used to specify what mix of colors to use from the color map. The syntax for color_map is as follows: COLOR_MAP: color_map{ COLOR_MAP_BODY } | colour_map{ COLOR_MAP_BODY } COLOR_MAP_BODY: COLOR_MAP_IDENTIFIER | COLOR_MAP_ENTRY... COLOR_MAP_ENTRY: [ Value COLOR ] | [ Value_1, Value_2 color COLOR_1 color COLOR_2 ] Where each Value_n is a float values between 0.0 and 1.0 inclusive and each COLOR_n, is color specifications. Note that the [] brackets are part of the actual COLOR_MAP_ENTRY. They are not notational symbols denoting optional parts. The brackets surround each entry in the color map. There may be from 2 to 256 entries in the map. The alternate spelling colour_map XE "colour_map"  may be used. Here is an example: sphere { <0,1,2>, 2 pigment { gradient x //this is the PATTERN_TYPE color_map { [0.1 color Red] [0.3 color Yellow] [0.6 color Blue] [0.6 color Green] [0.8 color Cyan] } } } The pattern function gradient XE "gradient"  x is evaluated and the result is a value from 0.0 to 1.0. If the value is less than the first entry (in this case 0.1) then the first color (red) is used. Values from 0.1 to 0.3 use a blend of red and yellow using linear interpolation of the two colors. Similarly values from 0.3 to 0.6 blend from yellow to blue. Note that the 3rd and 4th entries both have values of 0.6. This causes an immediate abrupt shift of color from blue to green. Specifically a value that is less than 0.6 will be blue but exactly equal to 0.6 will be green. Moving along, values from 0.6 to 0.8 will be a blend of green and cyan. Finally any value greater than or equal to 0.8 will be cyan. If you want areas of unchanging color you simply specify the same color for two adjacent entries. For example: color_map { [0.1 color Red] [0.3 color Yellow] [0.6 color Yellow] [0.8 color Green] } In this case any value from 0.3 to 0.6 will be pure yellow. The first syntax version of COLOR_MAP_ENTRY with one float and one color is the current standard. The other double entry version is obsolete and should be avoided. The previous example would look as follows using the old syntax. color_map { [0.0 0.1 color Red color Red] [0.1 0.3 color Red color Yellow] [0.3 0.6 color Yellow color Yellow] [0.6.0.8 color Yellow color Green] [0.8 1.0 color Green color Green] } You may use color_map with any patterns except brick XE "brick" , checker XE "checker" , hexagon XE "hexagon"  and image_map XE "image_map" . You may declare and use color_map identifiers. For example: #declare Rainbow_Colors= color_map { [0.0 color Magenta] [0.33 color Yellow] [0.67 color Cyan] [1.0 color Magenta] } object{My_Object pigment{ gradient x color_map{Rainbow_Colors} } } Pigment Maps and Pigment Lists In addition to specifying blended colors with a color map you may create a blend of pigments using a pigment_map XE "pigment_map" . The syntax for a pigment map is identical to a color map except you specify a pigment in each map entry (and not a color). The syntax for pigment_map is as follows: PIGMENT_MAP: pigment_map{ PIGMENT_MAP_BODY } PIGMENT_MAP_BODY: PIGMENT_MAP_IDENTIFIER | PIGMENT_MAP_ENTRY... PIGMENT_MAP_ENTRY: [ Value PIGMENT_BODY ] Where Value is a float value between 0.0 and 1.0 inclusive and each PIGMENT_BODY is anything which can be inside a pigment XE "pigment" {...} statement. The pigment keyword and {} braces need not be specified. Note that the [] brackets are part of the actual PIGMENT_MAP_ENTRY. They are not notational symbols denoting optional parts. The brackets surround each entry in the pigment map. There may be from 2 to 256 entries in the map. For example sphere { <0,1,2>, 2 pigment { gradient x //this is the PATTERN_TYPE pigment_map { [0.3 wood scale 0.2] [0.3 Jade] //this is a pigment identifier [0.6 Jade] [0.9 marble turbulence 1] } } } When the gradient XE "gradient"  x function returns values from 0.0 to 0.3 the scaled wood pigment is used. From 0.3 to 0.6 the pigment identifier Jade is used. From 0.6 up to 0.9 a blend of Jade and a turbulent marble is used. From 0.9 on up only the turbulent marble is used. Pigment maps may be nested to any level of complexity you desire. The pigments in a map may have color maps or pigment maps or any type of pigment you want. Any entry of a pigment map may be a solid color however if all entries are solid colors you should use a color_map XE "color_map"  which will render slightly faster. Entire pigments may also be used with the block patterns such as checker XE "checker" , hexagon XE "hexagon"  and brick XE "brick" . For example... pigment { checker pigment { Jade scale .8 } pigment { White_Marble scale .5 } } Note that in the case of block patterns the pigment wrapping is required around the pigment information. A pigment map is also used with the average XE "average"  pigment type. See " REF _Ref417371289 \h Average" for details. You may not use pigment_map or individual pigments with an image_map XE "image_map" . See section " REF _Ref417371359 \h Texture Maps" for an alternative way to do this. You may declare and use pigment map identifiers but the only way to declare a pigment block pattern list is to declare a pigment identifier for the entire pigment. Image Maps When all else fails and none of the above pigment pattern types meets your needs you can use an image_map XE "image_map"  to wrap a 2-D bit-mapped image around your 3-D objects. Specifying an Image Map The syntax for an image_map XE "image_map"  is: IMAGE_MAP: pigment{ image_map{ BITMAP_TYPE "bitmap.ext" [IMAGE_MAP_MODS...] } [PIGMENT_MODFIERS...] } BITMAP_TYPE: gif | tga | iff | ppm | pgm | png | sys IMAGE_MAP_MOD: map_type Type | once | interpolate Type | filter Palette, Amount | filter all Amount | transmit Palette, Amount | transmit all Amount  XE "gif"  XE "tga"  XE "iff"  XE "ppm"  XE "pgm"  XE "png"  XE "sys" After the required BITMAP_TYPE keyword is a string expression containing the name of a bitmapped image file of the specified type. Several optional modifiers may follow the file specification. The modifiers are described below. Note that earlier versions of POV-Ray allowed some modifiers before the BITMAP_TYPE but that syntax is being phased out in favor of the syntax described here. Note sys format is a system-specific format such as BMP for Windows or Pict for Macintosh. Filenames specified in the image_map statements will be searched for in the home (current) directory first and, if not found, will then be searched for in directories specified by any +L XE "+L"  or Library_Path XE "Library_Path"  options active. This would facilitate keeping all your image maps files in a separate subdirectory and giving a Library_Path option to specify where your library of image maps are. See " REF _Ref413142060 \h Library Paths" for details. By default, the image is mapped onto the x-y-plane. The image is projected onto the object as though there were a slide projector somewhere in the -z-direction. The image exactly fills the square area from (x,y) coordinates (0,0) to (1,1) regardless of the image's original size in pixels. If you would like to change this default you may translate, rotate or scale the pigment or texture to map it onto the object's surface as desired. In the section " REF _Ref417376730 \h Checker", the checker XE "checker"  pigment pattern is explained. The checks are described as solid cubes of colored clay from which objects are carved. With image maps you should imagine that each pixel is a long, thin, square, colored rod that extends parallel to the z-axis. The image is made from rows and columns of these rods bundled together and the object is then carved from the bundle. If you would like to change this default orientation you may translate, rotate or scale the pigment or texture to map it onto the object's surface as desired. The file name is optionally followed by one or more BITMAP_MODIFIERS. The filter XE "filter" , filter all XE "filter all" , transmit XE "transmit" , and transmit all XE "transmit all"  modifiers are specific to image maps and are discussed in the following sections. An image_map may also use generic bitmap modifiers map_type XE "map_type" , once XE "once"  and interpolate XE "interpolate"  described in " REF _Ref417983218 \h Bitmap Modifiers" The Filter and Transmit Bitmap Modifiers To make all or part of an image map transparent you can specify filter XE "filter"  and/or transmit XE "transmit"  values for the color palette/registers of PNG, GIF or IFF pictures (at least for the modes that use palettes). You can do this by adding the keyword filter or transmit following the filename. The keyword is followed by two numbers. The first number is the palette number value and the second is the amount of transparency. The values should be separated by a comma. For example: image_map { gif "mypic.gif" filter 0, 0.5 // Make color 0 50% filtered transparent filter 5, 1.0 // Make color 5 100% filtered transparent transmit 8, 0.3 // Make color 8 30% non-filtered transparent } You can give the entire image a filter or transmit value using filter all XE "all"  XE "filter all"  Amount or transmit all XE "transmit all"  Amount. For example: image_map { gif "stnglass.gif" filter all 0.9 } Note that early versions of POV-Ray used the keyword alpha XE "alpha"  to specify filtered transparency however that word is often used to describe non-filtered transparency. For this reason alpha is no longer used. See section " REF _Ref413394014 \h Specifying Colors" for details on the differences between filtered and non-filtered transparency. Using the Alpha Channel  XE "alpha channel" Another way to specify non-filtered transmit transparency in an image map is by using the alpha channel. PNG file format allows you to store a different transparency for each color index in the PNG file, if desired. If your paint programs support this feature of PNG you can do the transparency editing within your paint program rather than specifying transmit values for each color in the POV file. Since PNG and TGA image formats can also store full alpha channel (transparency) information you can generate image maps that have transparency which isn't dependent on the color of a pixel but rather its location in the image. Although POV uses transmit XE "transmit"  0.0 to specify no transparency and 1.0 to specify full transparency, the alpha data ranges from 0 to 255 in the opposite direction. Alpha data 0 means the same as transmit 1.0 and alpha data 255 produces transmit 0.0. Quick Color When developing POV-Ray scenes its often useful to do low quality test runs that render faster. The +Q XE "+Q"  command line switch or Quality XE "Quality"  INI option can be used to turn off some time consuming color pattern and lighting calculations to speed things up. See " REF _Ref417378671 \h Quality Settings" for details. However all settings of +Q5 or Quality=5 or lower turns off pigment calculations and creates gray objects. By adding a quick_color XE "quick_color"  to a pigment you tell POV-Ray what solid color to use for quick renders instead of a patterned pigment. For example: pigment { gradient x color_map{ [0.0 color Yellow] [0.3 color Cyan] [0.6 color Magenta] [1.0 color Cyan] } turbulence 0.5 lambda 1.5 omega 0.75 octaves 8 quick_color Neon_Pink } This tells POV-Ray to use solid Neon_Pink for test runs at quality +Q5 or lower but to use the turbulent gradient pattern for rendering at +Q6 and higher. Note that solid color pigments such as pigment {color Magenta} automatically set the quick_color to that value. You may override this if you want. Suppose you have 10 spheres on the screen and all are yellow. If you want to identify them individually you could give each a different quick_color like this: sphere { <1,2,3>,4 pigment { color Yellow quick_color Red } } sphere { <-1,-2,-3>,4 pigment { color Yellow quick_color Blue } } and so on. At +Q6 or higher they will all be yellow but at +Q5 or lower each would be different colors so you could identify them. The alternate spelling quick_colour XE "quick_colour"  is also supported. Normal Ray-tracing is known for the dramatic way it depicts reflection, refraction and lighting effects. Much of our perception depends on the reflective properties of an object. Ray tracing can exploit this by playing tricks on our perception to make us see complex details that aren't really there. Suppose you wanted a very bumpy surface on the object. It would be very difficult to mathematically model lots of bumps. We can however simulate the way bumps look by altering the way light reflects off of the surface. Reflection calculations depend on a vector called a surface normal vector. This is a vector which points away from the surface and is perpendicular to it. By artificially modifying (or perturbing) this normal vector you can simulate bumps. This is done by adding an optional normal XE "normal"  statement. Note that attaching a normal pattern does not really modify the surface. It only affects the way light reflects or refracts at the surface so that it looks bumpy. The syntax is: NORMAL: normal{ [NORMAL_IDENTIFIER] [NORMAL_TYPE] [NORMAL_MODIFIER...] } NORMAL_TYPE: PATTERN_TYPE Amount | bump_map{ BITMAP_TYPE "bitmap.ext" [BUMP_MAP_MODS...] } NORMAL_MODIFIER: PATTERN_MODIFIER | NORMAL_LIST | normal_map{ NORMAL_MAP_BODY } | slope_map{ SLOPE_MAP_BODY } | bump_size Amount Each of the items in a normal are optional but if they are present, they must be in the order shown. Any items after the NORMAL_IDENTIFIER modify or override settings given in the identifier. If no identifier is specified then the items modify the normal values in the current default texture. The PATTERN_TYPE may optionally be followed by a float value that controls the apparent depth of the bumps. Typical values range from 0.0 to 1.0 but any value may be used. Negative values invert the pattern. The default value if none is specified is 0.5. There are four basic types of NORMAL_TYPEs. They are block pattern normals, continuous pattern normals, specialized normals and bump maps. They differ in the types of modifiers you may use with them. The pattern type is optionally followed by one or more normal modifiers. In addition to general pattern modifiers such as transformations, turbulence, and warp modifiers, normals may also have a NORMAL_LIST, slope_map XE "slope_map" , normal_map XE "normal_map" , and bump_size XE "bump_size" which are specific to normals. See " REF _Ref417310705 \h Pattern Modifiers" for information on general modifiers. The normal-specific modifiers are described in sub-sections which follow. Normal modifiers of any kind apply only to the normal and not to other parts of the texture. Modifiers must be specified last. Originally POV-Ray had some patterns which were exclusively used for pigments while others were exclusively used for normals. Since POV-Ray 3.0 you can use any pattern for either pigments or normals. For example it is now valid to use ripples XE "ripples"  as a pigment or wood XE "wood"  as a normal type. The patterns bumps XE "bumps" , dents XE "dents" , ripples XE "ripples" , waves XE "waves" , wrinkles XE "wrinkles" , and bump_map XE "bump_map"  were once exclusively normal patterns which could not be used as pigments. Because these six types use specialized normal modification calculations they cannot have slope_map XE "slope_map" , normal_map XE "normal_map"  or wave shape modifiers. All other normal pattern types may use them. Because block patterns checker XE "checker" , hexagon XE "hexagon" , and brick XE "brick"  do not return a continuous series of values, they cannot use these modifiers either. See " REF _Ref417310251 \h Patterns" for details about specific patterns. A normal XE "normal"  statement is part of a texture XE "texture"  specification. However it can be tedious to use a texture statement just to add a bumps to an object. Therefore you may attach a normal directly to an object without explicitly specifying that it as part of a texture. For example instead of this: object {My_Object texture{normal{bumps 0.5}}} you may shorten it to: object {My_Object normal{bumps 0.5}} Note however that doing so creates an entire texture structure with default pigment XE "pigment"  and finish XE "finish"  statements just as if you had explicitly typed the full texture{...} around it. Normal identifiers may be declared to make scene files more readable and to parameterize scenes so that changing a single declaration changes many values. An identifier is declared as follows. NORMAL_DECLARATION: #declare IDENTIFIER = NORMAL | #local IDENTIFIER = NORMAL Where IDENTIFIER is the name of the identifier up to 40 characters long and NORMAL is any valid normal statement. See " REF _Ref412711267 \h #declare vs. #local" for information on identifier scope. Slope Maps A slope_map XE "slope_map"  is a normal pattern modifier which gives the user a great deal of control over the exact shape of the bumpy features. Each of the various pattern types available is in fact a mathematical function that takes any x, y, z location and turns it into a number between 0.0 and 1.0 inclusive. That number is used to specify where the various high and low spots are. The slope_map lets you further shape the contours. It is best illustrated with a gradient normal pattern. Suppose you have... plane{ z, 0 pigment{ White } normal { gradient x } } This gives a ramp wave pattern that looks like small linear ramps that climb from the points at x=0 to x=1 and then abruptly drops to 0 again to repeat the ramp from x=1 to x=2. A slope map turns this simple linear ramp into almost any wave shape you want. The syntax is as follows... The syntax for slope_map is as follows: SLOPE_MAP: slope_map{ SLOPE_MAP_BODY } SLOPE_MAP_BODY: SLOPE_MAP_IDENTIFIER | SLOPE_MAP_ENTRY... SLOPE_MAP_ENTRY: [ Value, ] Note that the [] brackets are part of the actual SLOPE_MAP_ENTRY. They are not notational symbols denoting optional parts. The brackets surround each entry in the slope map. There may be from 2 to 256 entries in the map. Each Value is a float value between 0.0 and 1.0 inclusive and each is a 2 component vectors such as <0,1> where the first value represents the apparent height of the wave and the second value represents the slope of the wave at that point. The height should range between 0.0 and 1.0 but any value could be used. The slope value is the change in height per unit of distance. For example a slope of zero means flat, a slope of 1.0 means slope upwards at a 45 degree angle and a slope of -1 means slope down at 45 degrees. Theoretically a slope straight up would have infinite slope. In practice, slope values should be kept in the range -3.0 to +3.0. Keep in mind that this is only the visually apparent slope. A normal does not actually change the surface. For example here is how to make the ramp slope up for the first half and back down on the second half creating a triangle wave with a sharp peak in the center. normal { gradient x // this is the PATTERN_TYPE slope_map { [0 <0, 1>] // start at bottom and slope up [0.5 <1, 1>] // halfway through reach top still climbing [0.5 <1,-1>] // abruptly slope down [1 <0,-1>] // finish on down slope at bottom } } The pattern function is evaluated and the result is a value from 0.0 to 1.0. The first entry says that at x=0 the apparent height is 0 and the slope is 1. At x=0.5 we are at height 1 and slope is still up at 1. The third entry also specifies that at x=0.5 (actually at some tiny fraction above 0.5) we have height 1 but slope -1 which is downwards. Finally at x=1 we are at height 0 again and still sloping down with slope -1. Although this example connects the points using straight lines the shape is actually a cubic spline. This example creates a smooth sine wave. normal { gradient x // this is the PATTERN_TYPE slope_map { [0 <0.5, 1>] // start in middle and slope up [0.25 <1.0, 0>] // flat slope at top of wave [0.5 <0.5,-1>] // slope down at mid point [0.75 <0.0, 0>] // flat slope at bottom [1 <0.5, 1>] // finish in middle and slope up } } This example starts at height 0.5 sloping up at slope 1. At a fourth of the way through we are at the top of the curve at height 1 with slope 0 which is flat. The space between these two is a gentle curve because the start and end slopes are different. At half way we are at half height sloping down to bottom out at 3/4ths. By the end we are climbing at slope 1 again to complete the cycle. There are more examples in slopemap.pov in the sample scenes. A slope_map may be used with any pattern except brick XE "brick" , checker XE "checker" , hexagon XE "hexagon" , bumps XE "bumps" , dents XE "dents" , ripples XE "ripples" , waves XE "waves" , wrinkles XE "wrinkles"  and bump_map XE "bump_map" . You may declare and use slope map identifiers. For example: #declare Fancy_Wave = slope_map { // Now let's get fancy [0.0 <0, 1>] // Do tiny triangle here [0.2 <1, 1>] // down [0.2 <1,-1>] // to [0.4 <0,-1>] // here. [0.4 <0, 0>] // Flat area [0.5 <0, 0>] // through here. [0.5 <1, 0>] // Square wave leading edge [0.6 <1, 0>] // trailing edge [0.6 <0, 0>] // Flat again [0.7 <0, 0>] // through here. [0.7 <0, 3>] // Start scallop [0.8 <1, 0>] // flat on top [0.9 <0,-3>] // finish here. [0.9 <0, 0>] // Flat remaining through 1.0 } object{ My_Object pigment { White } normal { wood slope_map { Fancy_Wave } } } Normal Maps and Normal Lists Most of the time you will apply single normal pattern to an entire surface but you may also create a pattern or blend of normals using a normal_map XE "normal_map" . The syntax for a normal_map is identical to a pigment_map XE "pigment_map"  except you specify a normal XE "normal"  in each map entry. The syntax for normal_map is as follows: NORMAL_MAP: normal_map{ NORMAL_MAP_BODY } NORMAL_MAP_BODY: NORMAL_MAP_IDENTIFIER | NORMAL_MAP_ENTRY... NORMAL_MAP_ENTRY: [ Value NORMAL_BODY ] Where Value is a float value between 0.0 and 1.0 inclusive and each NORMAL_BODY is anything which can be inside a normal XE "normal" {...} statement. The normal keyword and {} braces need not be specified. Note that the [] brackets are part of the actual NORMAL_MAP_ENTRY. They are not notational symbols denoting optional parts. The brackets surround each entry in the normal map. There may be from 2 to 256 entries in the map. For example normal { gradient x //this is the PATTERN_TYPE normal_map { [0.3 bumps scale 2] [0.3 dents] [0.6 dents] [0.9 marble turbulence 1] } } When the gradient XE "gradient"  x function returns values from 0.0 to 0.3 then the scaled bumps normal is used. From 0.3 to 0.6 dents are From 0.6 up to 0.9 a blend of dents and a turbulent marble is used. From 0.9 on up only the turbulent marble is used. Normal maps may be nested to any level of complexity you desire. The normals in a map may have slope maps or normal maps or any type of normal you want. A normal map is also used with the average XE "average"  normal type. See " REF _Ref417980778 \h Average" for details. Entire normals in a normal list may also be used with the block patterns such as checker XE "checker" , hexagon XE "hexagon"  and brick XE "brick" . For example... normal { checker normal { gradient x scale .2 } normal { gradient y scale .2 } } } Note that in the case of block patterns the normal wrapping is required around the normal information. You may not use normal_map or individual normals with a bump_map XE "bump_map" . See section " REF _Ref417980909 \h Texture Maps" for an alternative way to do this. You may declare and use normal map identifiers but the only way to declare a normal block pattern list is to declare a normal identifier for the entire normal. Bump Maps When all else fails and none of the above normal pattern types meets your needs you can use a bump_map XE "bump_map"  to wrap a 2-D bit-mapped bump pattern around your 3-D objects. Instead of placing the color of the image on the shape like an image_map XE "image_map"  a bump_map perturbs the surface normal based on the color of the image at that point. The result looks like the image has been embossed into the surface. By default, a bump map uses the brightness of the actual color of the pixel. Colors are converted to gray scale internally before calculating height. Black is a low spot, white is a high spot. The image's index values may be used instead (see section " REF _Ref417981169 \h Use_Index and Use_Color" below). Specifying a Bump Map The syntax for an bump_map XE "bump_map"  is: BUMP_MAP: normal{ bump_map{ BITMAP_TYPE "bitmap.ext" [BUMP_MAP_MODS...] } [NORMAL_MODFIERS...] } BITMAP_TYPE: gif | tga | iff | ppm | pgm | png | sys BUMP_MAP_MOD: map_type Type | once | interpolate Type | use_color | use_colour | bump_size Value  XE "gif"  XE "tga"  XE "iff"  XE "ppm"  XE "pgm"  XE "png"  XE "sys" After the required BITMAP_TYPE keyword is a string expression containing the name of a bitmapped bump file of the specified type. Several optional modifiers may follow the file specification. The modifiers are described below. Note that earlier versions of POV-Ray allowed some modifiers before the BITMAP_TYPE but that syntax is being phased out in favor of the syntax described here. Note sys format is a system-specific format such as BMP for Windows or Pict for Macintosh. Filenames specified in the bump_map statements will be searched for in the home (current) directory first and, if not found, will then be searched for in directories specified by any +L XE "+L"  or Library_Path XE "Library_Path"  options active. This would facilitate keeping all your bump maps files in a separate subdirectory and giving a Library_Path option to specify where your library of bump maps are. See " REF _Ref413142060 \h Library Paths" for details. By default, the bump pattern is mapped onto the x-y-plane. The bump pattern is projected onto the object as though there were a slide projector somewhere in the -z-direction. The pattern exactly fills the square area from (x,y) coordinates (0,0) to (1,1) regardless of the pattern's original size in pixels. If you would like to change this default you may translate, rotate or scale the pigment or texture to map it onto the object's surface as desired. If you would like to change this default orientation you may translate, rotate or scale the pigment or texture to map it onto the object's surface as desired. The file name is optionally followed by one or more BITMAP_MODIFIERS. The bump_size XE "bump_size" , use_color XE "use_color"  and use_index XE "use_index"  modifiers are specific to bump maps and are discussed in the following sections. See section " REF _Ref417983914 \h Bitmap Modifiers" for the generic bitmap modifiers map_type XE "map_type" , once XE "once"  and interpolate XE "interpolate"  described in " REF _Ref417983218 \h Bitmap Modifiers" Bump_Size The relative bump size can be scaled using the bump_size XE "bump_size"  modifier. The bump size number can be any number other than 0 but typical values are from about 0.1 to as high as 4.0 or 5.0. normal { bump_map { gif "stuff.gif" bump_size 5.0 } } Originally bump_size could only be used inside a bump map but it can now be used with any normal. Typically it is used to override a previously defined size. For example: normal { My_Normal //this is a previously defined normal identifier bump_size 2.0 } Use_Index and Use_Color Usually the bump map converts the color of the pixel in the map to a gray scale intensity value in the range 0.0 to 1.0 and calculates the bumps based on that value. If you specify use_index XE "use_index" , the bump map uses the color's palette number to compute as the height of the bump at that point. So, color number 0 would be low and color number 255 would be high (if the image has 256 palette entries). The actual color of the pixels doesn't matter when using the index. This option is only available on palette based formats. The use_color XE "use_color"  keyword may be specified to explicitly note that the color methods should be used instead. The alternate spelling use_colour XE "use_colour"  is also valid. These modifiers may only be used inside the bump_map XE "bump_map"  statement. Finish The finish properties of a surface can greatly affect its appearance. How does light reflect? What happens in shadows? What kind of highlights are visible. To answer these questions you need a finish XE "finish" . The syntax for finish is as follows: FINISH: finish { [FINISH_IDENTIFIER] [FINISH_ITEMS...] } FINISH_ITEMS: ambient COLOR | diffuse Amount | brilliance Amount | phong Amount | phong_size Amount | specular Amount | roughness Amount | metallic [Amount] | reflection COLOR | reflection_exponent Amount | irid { Irid_Amount [IRID_ITEMS...] } | crand Amount IRID_ITEMS: thickness Amount | turbulence Amount The FINISH_IDENTIFIER is optional but should proceed all other items. Any items after the FINISH_IDENTIFIER modify or override settings given in the FINISH_IDENTIFIER. If no identifier is specified then the items modify the finish values in the current default texture. Note that transformations are not allowed inside a finish because finish items cover the entire surface uniformly. Each of the FINISH_ITEMS listed above is described in sub-sections below. In earlier versions of POV-Ray, the refraction XE "refraction" , ior XE "ior" , and caustics XE "caustics"  keywords were part of the finish statement but they are now part of the interior XE "interior"  statement. They are still supported under finish for backward compatibility but the results may not be 100% identical to previous versions. See " REF _Ref417286060 \h Why are Interior and Media Necessary?" for details. A finish XE "finish"  statement is part of a texture XE "texture"  specification. However it can be tedious to use a texture statement just to add a highlights or other lighting properties to an object. Therefore you may attach a finish directly to an object without explicitly specifying that it as part of a texture. For example instead of this: object {My_Object texture{finish{phong 0.5}}} you may shorten it to: object {My_Object finish{phong 0.5}} Note however that doing so creates an entire texture structure with default pigment XE "pigment"  and normal XE "normal"  statements just as if you had explicitly typed the full texture{...} around it. Finish identifiers may be declared to make scene files more readable and to parameterize scenes so that changing a single declaration changes many values. An identifier is declared as follows. FINISH_DECLARATION: #declare IDENTIFIER = FINISH | #local IDENTIFIER = FINISH Where IDENTIFIER is the name of the identifier up to 40 characters long and FINISH is any valid finish statement. See " REF _Ref412711267 \h #declare vs. #local" for information on identifier scope. Ambient The light you see in dark shadowed areas comes from diffuse reflection off of other objects. This light cannot be directly modeled using ray-tracing. However we can use a trick called ambient lighting to simulate the light inside a shadowed area. Ambient light is light that is scattered everywhere in the room. It bounces all over the place and manages to light objects up a bit even where no light is directly shining. Computing real ambient light would take far too much time, so we simulate ambient light by adding a small amount of white light to each texture whether or not a light is actually shining on that texture. This means that the portions of a shape that are completely in shadow will still have a little bit of their surface color. It's almost as if the texture glows, though the ambient light in a texture only affects the shape it is used on. The ambient XE "ambient"  keyword controls the amount of ambient light. Usually a single float value is specified even though the syntax calls for a color. For example a float value of 0.3 gets promoted to the full color vector <0.3,0.3,0.3,0.3,0.3> which is acceptable because only the red, green and blue parts are used. The default value is 0.1 which gives very little ambient light. The value can range from 0.0 to 1.0. Ambient light affects both shadowed and non-shadowed areas so if you turn up the ambient value you may want to turn down the diffuse XE "diffuse"  and reflection XE "reflection"  values. Note that this method doesn't account for the color of surrounding objects. If you walk into a room that has red walls, floor and ceiling then your white clothing will look pink from the reflected light. POV-Ray's ambient shortcut doesn't account for this. There is also no way to model specular reflected indirect illumination such as the flashlight shining in a mirror. You may color the ambient light using one of two methods. You may specify a color rather than a float after the ambient keyword in each finish statement. For example finish { ambient rgb <0.3,0.1,0.1> } //a pink ambient You may also specify the overall ambient light source used when calculating the ambient lighting of an object using the global ambient_light XE "ambient_light"  setting. The formula is given by Ambient = Finish_Ambient * Global_Ambient_Light_Source See section " REF _Ref418066764 \h Ambient Light" for details. Diffuse Reflection Items When light reflects off of a surface the laws of physics say that it should leave the surface at the exact same angle it came in. This is similar to the way a billiard ball bounces off a bumper of a pool table. This perfect reflection is called specular reflection XE "specular reflection" . However only very smooth polished surfaces reflect light in this way. Most of the time, light reflects and is scattered in all directions by the roughness of the surface. This scattering is called diffuse reflection XE "diffuse reflection"  because the light diffuses or spreads in a variety of directions. It accounts for the majority of the reflected light we see. POV-Ray and most other ray-tracers can only simulate directly light which comes directly from actual light sources. Light coming from other objects such as mirrors via specular reflection (such as shining a flashlight onto a mirror for example) cannot be simulated. Neither can we simulate light coming from other objects via diffuse reflections. For example look at some dark area under a desk or in a corner: even though a lamp may not directly illuminate that spot, you can still see a little bit because light comes from diffuse reflection off of nearby objects. Diffuse The keyword diffuse XE "diffuse"  is used in a finish XE "finish"  statement to control how much of the light coming directly from any light sources is reflected via diffuse reflection. For example finish {diffuse 0.7} means that 70% of the light seen comes from direct illumination from light sources. The default value is diffuse 0.6. Brilliance The amount of direct light that diffuses from an object depends upon the angle at which it hits the surface. When light hits at a shallow angle it illuminates less. When it is directly above a surface it illuminates more. The brilliance XE "brilliance"  keyword can be used in a finish XE "finish"  statement to vary the way light falls off depending upon the angle of incidence. This controls the tightness of the basic diffuse illumination on objects and slightly adjusts the appearance of surface shininess. Objects may appear more metallic by increasing their brilliance. The default value is 1.0. Higher values from 5.0 to about 10.0 cause the light to fall off less at medium to low angles. There are no limits to the brilliance value. Experiment to see what works best for a particular situation. This is best used in concert with highlighting. Crand Graininess Very rough surfaces, such as concrete or sand, exhibit a dark graininess in their apparent color. This is caused by the shadows of the pits or holes in the surface. The crand XE "crand"  keyword can be added to a finish XE "finish"  cause a minor random darkening in the diffuse reflection of direct illumination. Typical values range from crand 0.01 to crand 0.5 or higher. The default value is 0. For example: finish { crand 0.05 } This feature is carried over from the earliest versions of POV-Ray and is considered obsolete. This is because the grain or noise introduced by this feature is applied on a pixel-by-pixel basis. This means that it will look the same on far away objects as on close objects. The effect also looks different depending upon the resolution you are using for the rendering. Note that this should not be used when rendering animations. This is the one of a few truly random features in POV-Ray and will produce an annoying flicker of flying pixels on any textures animated with a crand value. For these reasons it is not a very accurate way to model the rough surface effect. Highlights Highlights are the bright spots that appear when a light source reflects off of a smooth object. They are a blend of specular reflection and diffuse reflection. They are specular-like because they depend upon viewing angle and illumination angle. However they are diffuse-like because some scattering occurs. In order to exactly model a highlight you would have to calculate specular reflection off of thousands of microscopic bumps called micro facets. The more that micro facets are facing the viewer the shinier the object appears and the tighter the highlights become. POV-Ray uses two different models to simulate highlights without calculating micro facets. They are the specular and Phong models. Note that specular and Phong highlights are not mutually exclusive. It is possible to specify both and they will both take effect. Normally, however, you will only specify one or the other. Phong Highlights The phong XE "phong"  keyword in the finish XE "finish"  statement controls the amount of Phong highlighting on the object. It causes bright shiny spots on the object that are the color of the light source being reflected. The Phong method measures the average of the facets facing in the mirror direction from the light sources to the viewer. Phong's value is typically from 0.0 to 1.0, where 1.0 causes complete saturation to the light source's color at the brightest area (center) of the highlight. The default phong 0.0 gives no highlight. The size of the highlight spot is defined by the phong_size XE "phong_size"  value. The larger the phong size the tighter, or smaller, the highlight and the shinier the appearance. The smaller the phong size the looser, or larger, the highlight and the less glossy the appearance. Typical values range from 1.0 (very dull) to 250 (highly polished) though any values may be used. Default phong size is 40 (plastic) if phong_size is not specified. For example: finish { phong 0.9 phong_size 60 } If phong is not specified phong_size has no effect. Specular Highlight The specular XE "specular"  keyword in a finish XE "finish"  statement produces a highlight which is very similar to Phong highlighting but it uses slightly different model. The specular model more closely resembles real specular reflection and provides a more credible spreading of the highlights occurring near the object horizons. The specular value is typically from 0.0 to 1.0, where 1.0 causes complete saturation to the light source's color at the brightest area (center) of the highlight. The default specular 0.0 gives no highlight. The size of the spot is defined by the value given the roughness XE "roughness"  keyword. Typical values range from 1.0 (very rough - large highlight) to 0.0005 (very smooth - small highlight). The default value, if roughness is not specified, is 0.05 (plastic). It is possible to specify wrong values for roughness that will generate an error when you try to render the file. Don't use 0 and if you get errors check to see if you are using a very, very small roughness value that may be causing the error. For example: finish {specular 0.9 roughness 0.02} If specular is not specified roughness has no effect. Note that when light reflects perfectly of a smooth surface such as a mirror, it is called specular reflection however such reflection is not controlled by the specular keyword. The reflection XE "reflection"  keyword controls mirror-like specular reflection. Metallic Highlight Modifier The keyword metallic XE "metallic"  may be used with Phong or specular highlights. This keyword indicates that the color of the highlights will be calculated by an empirical function that models the reflectivity of metallic surfaces. Normally highlights are the color of the light source. Adding this keyword filters the highlight so that white light reflected from a metallic surface takes the color of the surface. The metallic keyword may optionally be follow by a numeric value to specify the influence the amount of the effect. If no keyword is specified, the default value is zero. If the keyword is specified without a value, the default value is one. For example: finish { phong 0.9 phong_size 60 metallic } If phong XE "phong"  or specular XE "specular"  keywords are not specified then metallic has no effect. Specular Reflection When light does not diffuse and it does reflect at the same angle as it hits an object, it is called specular reflection XE "specular reflection" . Such mirror-like reflection is controlled by the reflection XE "reflection"  keyword in a finish XE "finish"  statement. For example: finish { reflection 1.0 ambient 0 diffuse 0 } This gives the object a mirrored finish. It will reflect all other elements in the scene. Usually a single float value is specified after the keyword even though the syntax calls for a color. For example a float value of 0.3 gets promoted to the full color vector < 0.3,0.3,0.3,0.3,0.3> which is acceptable because only the red, green and blue parts are used. The value can range from 0.0 to 1.0. By default there is no reflection. Adding reflection to a texture makes it take longer to render because an additional ray must be traced. The reflected light may be tinted by specifying a color rather than a float. For example finish { reflection rgb <1,0,0> } gives a red mirror that only reflects red light. POV-Ray uses a limited light model that cannot distinguish between objects which are simply brightly colored and objects which are extremely bright. A white piece of paper, a light bulb, the sun, and a supernova, all would be modeled as rgb<1,1,1> and slightly off-white objects would be only slightly darker. It is especially difficult to model partially reflective surfaces in a realistic way. Middle and lower brightness objects typically look too bright when reflected. If you reduce the reflection value, it tends to darken the bright objects too much. Therefore the reflection_exponent XE "reflection_exponent"  keyword has been added. It produces non-linear reflection intensities. The default value of 1.0 produces a linear curve. Lower values darken middle and low intensities and keeps high intensity reflections bright. This is a somewhat experimental feature designed for artistic use. It does not directly correspond to any real world reflective properties. We are researching ways to deal with this issue in a more scientific model. The reflection_exponent has no effect unless reflection is used. Note that although such reflection is called specular it is not controlled by the specular XE "specular"  keyword. That keyword controls a specular highlight. Iridescence Iridescence, or Newton's thin film interference, simulates the effect of light on surfaces with a microscopic transparent film overlay. The effect is like an oil slick on a puddle of water or the rainbow hues of a soap bubble. This effect is controlled by the irid XE "irid"  statement specified inside a finish XE "finish"  statement. This parameter modifies the surface color as a function of the angle between the light source and the surface. Since the effect works in conjunction with the position and angle of the light sources to the surface it does not behave in the same ways as a procedural pigment pattern. The syntax is: IRID: irid { Irid_Amount [IRID_ITEMS...] } IRID_ITEMS: thickness Amount | turbulence Amount The required Irid_Amount parameter is the contribution of the iridescence effect to the overall surface color. As a rule of thumb keep to around 0.25 (25% contribution) or less, but experiment. If the surface is coming out too white, try lowering the diffuse XE "diffuse"  and possibly the ambient XE "ambient"  values of the surface. The thickness XE "thickness"  keyword represents the film's thickness. This is an awkward parameter to set, since the thickness value has no relationship to the object's scale. Changing it affects the scale or busy-ness of the effect. A very thin film will have a high frequency of color changes while a thick film will have large areas of color. The default value is zero. The thickness of the film can be varied with the turbulence XE "turbulence"  keyword. You can only specify the amount of turbulence with iridescence. The octaves, lambda, and omega values are internally set and are not adjustable by the user at this time. This parameter varies only a single value: the thickness. Therefore the value must be a single float value. It cannot be a vector as in other uses of the turbulence keyword. In addition, perturbing the object's surface normal through the use of bump patterns will affect iridescence. For the curious, thin film interference occurs because, when the ray hits the surface of the film, part of the light is reflected from that surface, while a portion is transmitted into the film. This subsurface ray travels through the film and eventually reflects off the opaque substrate. The light emerges from the film slightly out of phase with the ray that was reflected from the surface. This phase shift creates interference, which varies with the wavelength of the component colors, resulting in some wavelengths being reinforced, while others are cancelled out. When these components are recombined, the result is iridescence. See also the global setting " REF _Ref418325405 \h Irid_Wavelength". The concept used for this feature came from the book Fundamentals of Three-Dimensional Computer Graphics by Alan Watt (Addison-Wesley). Halo Earlier versions of POV-Ray used a feature called halo XE "halo"  to simulate fine particles such as smoke, steam, fog, or flames. The halo statement was part of the texture XE "texture"  statement. This feature has been discontinued and replaced by the interior XE "interior"  and media XE "media"  statements which are object modifiers outside the texture statement. See " REF _Ref417286060 \h Why are Interior and Media Necessary?" for a detailed explanation on the reasons for the change. See " REF _Ref413750547 \h Media" for details on media. Patterned Textures Patterned textures are complex textures made up of multiple textures. The component textures may be plain textures or may be made up of patterned textures. A plain texture has just one pigment, normal and finish statement. Even a pigment with a pigment map is still one pigment and thus considered a plain texture as are normals with normal map statements. Patterned textures use either a texture_map XE "texture_map"  statement to specify a blend or pattern of textures or they use block textures such as checker XE "checker"  with a texture list or a bitmap similar to an image map called a material map specified with a material_map statement. The syntax is... PATTERNED_TEXTURE: texture { [PATTERNED_TEXTURE_ID] [TRANSFORMATIONS...] } | texture { PATTERN_TYPE [TEXTURE_PATTERN_MODIFIERS...] } | texture { tiles TEXTURE tile2 TEXTURE [TRANSFORMATIONS...] } | texture { material_map{ BITMAP_TYPE "bitmap.ext" [BITMAP_MODS...] TEXTURE... [TRANSFORMATIONS...] } } TEXTURE_PATTERN_MODIFIER: PATTERN_MODIFIER | TEXTURE_LIST | texture_map{ TEXTURE_MAP_BODY } There are restrictions on using patterned textures. A patterned texture may not be used as a default texture (see section " REF _Ref418327261 \h The #default Directive"). A patterned texture cannot be used as a layer in a layered texture however you may use layered textures as any of the textures contained within a patterned texture. Texture Maps In addition to specifying blended color with a color map or a pigment map you may create a blend of textures using texture_map XE "texture_map" . The syntax for a texture map is identical to the pigment map except you specify a texture in each map entry. The syntax for texture_map is as follows: TEXTURE_MAP: texture_map{ TEXTURE_MAP_BODY } TEXTURE_MAP_BODY: TEXTURE_MAP_IDENTIFIER | TEXTURE_MAP_ENTRY... TEXTURE_MAP_ENTRY: [ Value TEXTURE_BODY ] Where Value is a float value between 0.0 and 1.0 inclusive and each TEXTURE_BODY is anything which can be inside a texture XE "texture" {...} statement. The texture keyword and {} braces need not be specified. Note that the [] brackets are part of the actual TEXTURE_MAP_ENTRY. They are not notational symbols denoting optional parts. The brackets surround each entry in the texture map. There may be from 2 to 256 entries in the map. For example: texture { gradient x //this is the PATTERN_TYPE texture_map { [0.3 pigment{Red} finish{phong 1}] [0.3 T_Wood11] //this is a texture identifier [0.6 T_Wood11] [0.9 pigment{DMFWood4} finish{Shiny}] } } When the gradient XE "gradient"  x function returns values from 0.0 to 0.3 the red highlighted texture is used. From 0.3 to 0.6 the texture identifier T_Wood11 is used. From 0.6 up to 0.9 a blend of T_Wood11 and a shiny DMFWood4 is used. From 0.9 on up only the shiny wood is used. Texture maps may be nested to any level of complexity you desire. The textures in a map may have color maps or texture maps or any type of texture you want. The blended area of a texture map works by fully calculating both contributing textures in their entirety and then linearly interpolating the apparent colors. This means that reflection, refraction and lighting calculations are done twice for every point. This is in contrast to using a pigment map and a normal map in a plain texture, where the pigment is computed, then the normal, then reflection, refraction and lighting are calculated once for that point. Entire textures may also be used with the block patterns such as checker XE "checker" , hexagon XE "hexagon"  and brick XE "brick" . For example... texture { checker texture { T_Wood12 scale .8 } texture { pigment { White_Marble } finish { Shiny } scale .5 } } } Note that in the case of block patterns the texture wrapping is required around the texture information. Also note that this syntax prohibits the use of a layered texture however you can work around this by declaring a texture identifier for the layered texture and referencing the identifier. A texture map is also used with the average XE "average"  texture type. See " REF _Ref417371289 \h Average" for details. You may declare and use texture map identifiers but the only way to declare a texture block pattern list is to declare a texture identifier for the entire texture. Tiles Earlier versions of POV-Ray had a patterned texture called a tiles texture. It used the tiles XE "tiles"  and tile2 XE "tile2"  keywords to create a checkered pattern of textures. TILES_TEXTURE: texture { tiles TEXTURE tile2 TEXTURE [TRANSFORMATIONS...] } Although it is still supported for backwards compatibility you should use a checker XE "checker"  block texture pattern described in section " REF _Ref418328214 \h Texture Maps" rather than tiles textures. Material Maps The material_map XE "material_map"  patterned texture extends the concept of image maps to apply to entire textures rather than solid colors. A material map allows you to wrap a 2-D bit-mapped texture pattern around your 3-D objects. Instead of placing a solid color of the image on the shape like an image map, an entire texture is specified based on the index or color of the image at that point. You must specify a list of textures to be used like a texture palette rather than the usual color palette. When used with mapped file types such as GIF, and some PNG and TGA images, the index of the pixel is used as an index into the list of textures you supply. For unmapped file types such as some PNG and TGA images the 8 bit value of the red component in the range 0-255 is used as an index. If the index of a pixel is greater than the number of textures in your list then the index is taken modulo N where N is the length of your list of textures. Note: The material_map XE "material_map"  statement has nothing to do with the material statement. A material_map is not a way to create patterned material XE "material" . See " REF _Ref428017426 \h Material" for explanation of this unrelated, yet similarly named, older feature. Specifying a Material Map The syntax for an material_map XE "material_map"  is: MATERIAL_MAP: texture { material_map{ BITMAP_TYPE "bitmap.ext" [BITMAP_MODS...] TEXTURE... [TRANSFORMATIONS...] } } BITMAP_TYPE: gif | tga | iff | ppm | pgm | png | sys BITMAP_MOD: map_type Type | once | interpolate Type  XE "gif"  XE "tga"  XE "iff"  XE "ppm"  XE "pgm"  XE "png"  XE "sys" After the required BITMAP_TYPE keyword is a string expression containing the name of a bitmapped material file of the specified type. Several optional modifiers may follow the file specification. The modifiers are described below. Note that earlier versions of POV-Ray allowed some modifiers before the BITMAP_TYPE but that syntax is being phased out in favor of the syntax described here. Note sys format is a system-specific format such as BMP for Windows or Pict for Macintosh. Filenames specified in the material_map statements will be searched for in the home (current) directory first and, if not found, will then be searched for in directories specified by any +L XE "+L"  or Library_Path XE "Library_Path"  options active. This would facilitate keeping all your material maps files in a separate subdirectory and giving a Library_Path option to specify where your library of material maps are. See " REF _Ref413142060 \h Library Paths" for details. By default, the material is mapped onto the x-y-plane. The material is projected onto the object as though there were a slide projector somewhere in the -z-direction. The material exactly fills the square area from (x,y) coordinates (0,0) to (1,1) regardless of the material's original size in pixels. If you would like to change this default you may translate, rotate or scale the texture or texture to map it onto the object's surface as desired. The file name is optionally followed by one or more BITMAP_MODIFIERS. There are no modifiers which are unique to a material_map. It only uses the generic bitmap modifiers map_type XE "map_type" , once XE "once"  and interpolate XE "interpolate"  described in " REF _Ref417983218 \h Bitmap Modifiers". Although interpolate is legal in material maps, the color index is interpolated before the texture is chosen. It does not interpolate the final color as you might hope it would. In general, interpolation of material maps serves no useful purpose but this may be fixed in future versions. Next is one or more texture statements. Each texture in the list corresponds to an index in the bitmap file. For example: texture { material_map { png "povmap.png" texture { //used with index 0 pigment {color red 0.3 green 0.1 blue 1} normal {ripples 0.85 frequency 10 } finish {specular 0.75} scale 5 } texture { //used with index 1 pigment {White} finish {ambient 0 diffuse 0 reflection 0.9 specular 0.75} } // used with index 2 texture {pigment{NeonPink} finish{Luminous}} texture { //used with index 3 pigment { gradient y color_map { [0.00 rgb < 1 , 0 , 0>] [0.33 rgb < 0 , 0 , 1>] [0.66 rgb < 0 , 1 , 0>] [1.00 rgb < 1 , 0 , 0>] } } finish{specular 0.75} scale 8 } } scale 30 translate <-15, -15, 0> } After a material_map statement but still inside the texture statement you may apply any legal texture modifiers. Note that no other pigment, normal, or finish statements may be added to the texture outside the material map. The following is illegal: texture { material_map { gif "matmap.gif" texture {T1} texture {T2} texture {T3} } finish {phong 1.0} } The finish must be individually added to each texture. Note that earlier versions of POV-Ray allowed such specifications but they were ignored. The above restrictions on syntax were necessary for various bug fixes. This means some POV-Ray 1.0 scenes using material maps many need minor modifications that cannot be done automatically with the version compatibility mode. If particular index values are not used in an image then it may be necessary to supply dummy textures. It may be necessary to use a paint program or other utility to examine the map file's palette to determine how to arrange the texture list. The textures within a material map texture may be layered but material map textures do not work as part of a layered texture. To use a layered texture inside a material map you must declare it as a texture identifier and invoke it in the texture list. Layered Textures It is possible to create a variety of special effects using layered textures XE "layered textures" . A layered texture consists of several textures that are partially transparent and are laid one on top of the other to create a more complex texture. The different texture layers show through the transparent portions to create the appearance of one texture that is a combination of several textures. You create layered textures by listing two or more textures one right after the other. The last texture listed will be the top layer, the first one listed will be the bottom layer. All textures in a layered texture other than the bottom layer should have some transparency. For example: object { My_Object texture {T1} // the bottom layer texture {T2} // a semi-transparent layer texture {T3} // the top semi-transparent layer } In this example T2 shows only where T3 is transparent and T1 shows only where T2 and T3 are transparent. The color of underlying layers is filtered by upper layers but the results do not look exactly like a series of transparent surfaces. If you had a stack of surfaces with the textures applied to each, the light would be filtered twice: once on the way in as the lower layers are illuminated by filtered light and once on the way out. Layered textures do not filter the illumination on the way in. Other parts of the lighting calculations work differently as well. The results look great and allow for fantastic looking textures but they are simply different from multiple surfaces. See stones.inc in the standard include files directory for some magnificent layered textures. Note layered textures must use the texture XE "texture"  wrapped around any pigment, normal or finish statements. Do not use multiple pigment, normal or finish statements without putting them inside the texture statement. Layered textures may be declared. For example #declare Layered_Examp = texture {T1} texture {T2} texture {T3} may be invoked as follows: object { My_Object texture { Layer_Examp // Any pigment, normal or finish here // modifies the bottom layer only. } } If you wish to use a layered texture in a block pattern, such as checker XE "checker" , hexagon XE "hexagon" , or brick XE "brick" , or in a material_map XE "material_map" , you must declare it first and then reference it inside a single texture statement. A patterned texture cannot be used as a layer in a layered texture however you may use layered textures as any of the textures contained within a patterned texture. Patterns POV-Ray uses a method called three-dimensional solid texturing to define the color, bumpiness and other properties of an object. You specify the way that the texture varies over a surface by specifying a pattern XE "pattern" . Patterns are used in pigments, normals and texture maps as well as media density. All patterns in POV-Ray are three dimensional. For every point in space, each pattern has a unique value. Patterns do not wrap around a surface like putting wallpaper on an object. The patterns exist in 3d and the objects are carved from them like carving an object from a solid block of wood or stone. Consider a block of wood. It contains light and dark bands that are concentric cylinders being the growth rings of the wood. On the end of the block you see these concentric circles. Along its length you see lines that are the veins. However the pattern exists throughout the entire block. If you cut or carve the wood it reveals the pattern inside. Similarly an onion consists of concentric spheres that are visible only when you slice it. Marble stone consists of wavy layers of colored sediments that harden into rock. These solid patterns can be simulated using mathematical functions. Other random patterns such as granite or bumps and dents can be generated using a random number system and a noise function. In each case, the x, y, z coordinate of a point on a surface is used to compute some mathematical function that returns a float value. When used with color maps or pigment maps, that value looks up the color of the pigment to be used. In normal statements the pattern function result modifies or perturbs the surface normal vector to give a bumpy appearance. Used with a texture map, the function result determines which combinations of entire textures to be used. When used with media density it specifies the density of the particles or gasses. The following sections describe each pattern. See the sections " REF _Ref418334424 \h Pigment", " REF _Ref418334453 \h Normal", " REF _Ref418334482 \h Patterned Textures" and " REF _Ref418334512 \h Density" for more details on how to use patterns. Unless mentioned otherwise, all patterns use the ramp_wave XE "ramp_wave"  wave type by default but may use any wave type and may be used with color_map XE "color_map" , pigment_map XE "pigment_map" , normal_map XE "normal_map" , slope_map XE "slope_map" , texture_map XE "texture_map" , density XE "density" , and density_map XE "density_map" . Agate The agate XE "agate"  pattern is a banded pattern similar to marble but it uses a specialized built-in turbulence function that is different from the traditional turbulence. The traditional turbulence can be used as well but it is generally not necessary because agate is already very turbulent. You may control the amount of the built-in turbulence by adding the optional agate_turb XE "agate_turb"  keyword followed by a float value. For example: pigment { agate agate_turb 0.5 color_map {MyMap} } Average Technically average XE "average"  is not a pattern type but it is listed here because the syntax is similar to other patterns. Typically a pattern type specifies how colors or normals are chosen from a pigment_map XE "pigment_map"  texture_map XE "texture_map" , density_map XE "density_map" , or normal_map XE "normal_map" , however average tells POV-Ray to average together all of the patterns you specify. Average was originally designed to be used in a normal statement with a normal_map as a method of specifying more than one normal pattern on the same surface. However average may be used in a pigment statement with a pigment_map or in a texture statement with a texture_map or media density with density_map to average colors too. When used with pigments, the syntax is: AVERAGED_PIGMENT: pigment { pigment_map{ PIGMENT_MAP_ENTRY... } } PIGMENT_MAP_ENTRY: [ [Weight] PIGMENT_BODY ] Where Weight is an optional float value that defaults to 1.0 if not specified. This weight value is the relative weight applied to that pigment. Each PIGMENT_BODY is anything which can be inside a pigment XE "pigment" {...} statement. The pigment keyword and {} braces need not be specified. Note that the [] brackets are part of the actual PIGMENT_MAP_ENTRY. They are not notational symbols denoting optional parts. The brackets surround each entry in the pigment_map. There may be from 2 to 256 entries in the map. For example pigment { average pigment_map { [1.0 Pigment_1] [2.0 Pigment_2] [0.5 Pigment_3] } } All three pigments are evaluated. The weight values are multiplied by the resulting color. It is then divided by the total of the weights which, in this example is 3.5. When used with texture_map or density_map it works the same way. When used with a normal_map in a normal statement, multiple copies of the original surface normal are created and are perturbed by each pattern. The perturbed normals are then weighted, added and normalized. See the sections " REF _Ref418337353 \h Pigment Maps and Pigment Lists", " REF _Ref418337380 \h Normal Maps and Normal Lists", " REF _Ref418337408 \h Texture Maps", and " REF _Ref428014731 \h Density Maps and Density Lists" for more information. Boxed The boxed XE "boxed"  pattern creates a 2x2x2 unit cube centered at the origin. It is computed by: value =1.0- min(1, max(abs(X), abs(Y), abs(Z))) It starts at 1.0 at the origin and increases to a minimum value of 0.0 as it approaches any plane which is one unit from the origin. It remains at 0.0 for all areas beyond that distance. This pattern was originally created for use with halo XE "halo"  or media XE "media"  but it may be used anywhere any pattern may be used. Bozo The bozo XE "bozo"  pattern is a very smooth, random noise function that is traditionally used with some turbulence to create clouds. The spotted XE "spotted"  pattern is identical to bozo but in early versions of POV-Ray spotted did not allow turbulence to be added. Turbulence can now be added to any pattern so these are redundant but both are retained for backwards compatibility. The bumps XE "bumps"  pattern is also identical to bozo when used anywhere except in a normal XE "normal"  statement. When used as a normal pattern, bumps uses a slightly different method to perturb the normal with a similar noise function. The bozo noise function has the following properties: 1. It's defined over 3D space i.e., it takes x, y, and z and returns the noise value there. 2. If two points are far apart, the noise values at those points are relatively random. 3. If two points are close together, the noise values at those points are close to each other. You can visualize this as having a large room and a thermometer that ranges from 0.0 to 1.0. Each point in the room has a temperature. Points that are far apart have relatively random temperatures. Points that are close together have close temperatures. The temperature changes smoothly but randomly as we move through the room. Now let's place an object into this room along with an artist. The artist measures the temperature at each point on the object and paints that point a different color depending on the temperature. What do we get? A POV-Ray bozo texture! Brick The brick XE "brick"  pattern generates a pattern of bricks. The bricks are offset by half a brick length on every other row in the x- and z-directions. A layer of mortar surrounds each brick. The syntax is given by pigment { brick COLOR_1, COLOR_2 [brick_size ] [mortar Size] } where COLOR_1 is the color of the mortar and COLOR_2 is the color of the brick itself. If no colors are specified a default deep red and dark gray are used. The default size of the brick and mortar together is <8, 3, 4.5> units. The default thickness of the mortar is 0.5 units. These values may be changed using the optional brick_size XE "brick_size"  and mortar XE "mortar"  pattern modifiers. You may also use pigment statements in place of the colors. For example: pigment { brick pigment{Jade}, pigment{Black_Marble} } This example uses normals: normal { brick 0.5 } The float value is an optional bump size. You may also use full normal statements. For example: normal { brick normal{bumps 0.2}, normal{granite 0.3} } When used with textures, the syntax is texture { brick texture{T_Gold_1A}, texture{Stone12} } This is a block pattern which cannot use wave types, color_map XE "color_map" , or slope_map XE "slope_map"  modifiers. Bumps The bumps XE "bumps"  pattern was originally designed only to be used as a normal pattern. It uses a very smooth, random noise function that creates the look of rolling hills when scaled large or a bumpy orange peal when scaled small. Usually the bumps are about 1 unit apart. When used as a normal pattern, this pattern uses a specialized normal perturbation function. This means that the pattern cannot be used with normal_map XE "normal_map" , slope_map XE "slope_map"  or wave type modifiers in a normal XE "normal"  statement. When used as a pigment pattern or texture pattern, the bumps pattern is identical to bozo XE "bozo"  or spotted XE "spotted"  and is similar to normal bumps but is not identical as are most normals when compared to pigments. Checker The checker XE "checker"  pattern produces a checkered pattern consisting of alternating squares of two colors. The syntax is: pigment { checker [COLOR_1 [, COLOR_2]] [PATTERN_MODIFIERS...] } If no colors are specified then default blue and green colors are used. The checker pattern is actually a series of cubes that are one unit in size. Imagine a bunch of 1 inch cubes made from two different colors of modeling clay. Now imagine arranging the cubes in an alternating check pattern and stacking them in layer after layer so that the colors still alternate in every direction. Eventually you would have a larger cube. The pattern of checks on each side is what the POV-Ray checker pattern produces when applied to a box object. Finally imagine cutting away at the cube until it is carved into a smooth sphere or any other shape. This is what the checker pattern would look like on an object of any kind. You may also use pigment statements in place of the colors. For example: pigment { checker pigment{Jade}, pigment{Black_Marble} } This example uses normals: normal { checker 0.5 } The float value is an optional bump size. You may also use full normal statements. For example: normal { checker normal{gradient x scale .2}, normal{gradient y scale .2} } When used with textures, the syntax is texture { checker texture{T_Wood_3A},texture{Stone12} } This use of checker as a texture pattern replaces the special tiles texture in previous versions of POV-Ray. You may still use tiles XE "tiles"  but it may be phased out in future versions so checker textures are best. This is a block pattern which cannot use wave types, color_map XE "color_map" , or slope_map XE "slope_map"  modifiers. Crackle The crackle XE "crackle"  pattern is a set of random tiled polygons. With a large scale and no turbulence it makes a pretty good stone wall or floor. With a small scale and no turbulence it makes a pretty good crackle ceramic glaze. Using high turbulence it makes a good marble that avoids the problem of apparent parallel layers in traditional marble. Mathematically, the set crackle(p)=0 is a 3D Voronoi diagram of a field of semi random points and crackle(p) < 0 is the distance from the set along the shortest path (a Voronoi diagram is the locus of points equidistant from their two nearest neighbors from a set of disjoint points, like the membranes in suds are to the centers of the bubbles). Cylindrical The cylindrical XE "cylindrical"  pattern creates a one unit radius cylinder along the Y axis. It is computed by: value = 1.0-min(1, sqrt(X^2 + Z^2)) It starts at 1.0 at the origin and increases to a minimum value of 0.0 as it approaches a distance of 1 unit from the Y axis. It remains at 0.0 for all areas beyond that distance. This pattern was originally created for use with halo XE "halo"  or media XE "media"  but it may be used anywhere any pattern may be used. Density_File The density_file XE "density_file"  pattern is a 3-D bitmap pattern that occupies a unit cube from location <0,0,0> to <1,1,1>. The data file is a raw binary file format created for POV-Ray called df3 XE "df3"  format. The syntax provides for the possibility of implementing other formats in the future. This pattern was originally created for use with halo XE "halo"  or media XE "media"  but it may be used anywhere any pattern may be used. The syntax is: pigment {density_file df3 "filename.df3" [interpolate Type] [PIGMENT_MODIFIERS...] } where "filename.df3" is a file name of the data file. As a normal pattern, the syntax is normal {density_file df3 "filename.df3" [, Bump_Size] [interpolate Type] [NORMAL_MODIFIERS...] } The optional float Bump_Size should follow the file name and any other modifiers follow that. The df3 format consists of a 6 byte header of three 16-bit integers with high order byte first. These three values give the x,y,z size of the data in pixels (or more appropriately called voxels). This is followed by x*y*z unsigned integer bytes of data. The data in the range of 0 to 255 is scaled into a float value in the range 0.0 to 1.0. It remains at 0.0 for all areas beyond the unit cube. The pattern occupies the unit cube regardless of the dimensions in voxels. The interpolate XE "interpolate"  keyword may be specified to add interpolation of the data. The default value of zero specifies no interpolation. A value of one specifies tri-linear interpolation. See the sample scenes for data file include\spiral.df3,and the scenes which use it: scenes\textures\surfaces\densfile.pov, scenes\interior\media\galaxy.pov for examples. Dents The dents XE "dents"  pattern was originally designed only to be used as a normal pattern. It is especially interesting when used with metallic textures. It gives impressions into the metal surface that look like dents have been beaten into the surface with a hammer. Usually the dents are about 1 unit apart. When used as a normal pattern, this pattern uses a specialized normal perturbation function. This means that the pattern cannot be used with normal_map XE "normal_map" , slope_map XE "slope_map"  or wave type modifiers in a normal XE "normal"  statement. When used as a pigment pattern or texture pattern, the dents pattern is similar to normal dents but is not identical as are most normals when compared to pigments. Gradient One of the simplest patterns is the gradient XE "gradient"  pattern. It is specified as pigment {gradient [PIGMENT_MODIFIERS...] } where is a vector pointing in the direction that the colors blend. For example pigment { gradient x } // bands of color vary as you move // along the "x" direction. produces a series of smooth bands of color that look like layers of colors next to each other. Points at x=0 are the first color in the color map. As the x location increases it smoothly turns to the last color at x=1. Then it starts over with the first again and gradually turns into the last color at x=2. The pattern reverses for negative values of x. Using gradient y or gradient z makes the colors blend along the y- or z-axis. Any vector may be used but x, y and z are most common. As a normal pattern, gradient generates a saw-tooth or ramped wave appearance. The syntax is normal {gradient [, Bump_Size] [NORMAL_MODIFIERS...] } where the vector is a required parameter but the float Bump_Size which follows is optional. Note that the comma is required especially if Bump_Size is negative. Granite The granite XE "granite"  pattern uses a simple 1/f fractal noise function to give a good granite pattern. This pattern is used with creative color maps in stones.inc to create some gorgeous layered stone textures. As a normal pattern it creates an extremely bumpy surface that looks like a gravel driveway or rough stone. Hexagon The hexagon XE "hexagon"  pattern is a block pattern that generates a repeating pattern of hexagons in the x-y-plane. In this instance imagine tall rods that are hexagonal in shape and are parallel to the y-axis and grouped in bundles like shown in the example image. Three separate colors should be specified as follows: pigment{hexagon [COLOR_1 [, COLOR_2 [, COLOR_3]]] [PATTERN_MODIFIERS...] }  The hexagon pattern. The three colors will repeat the hexagonal pattern with hexagon COLOR_1 centered at the origin, COLOR_2 in the +z-direction and COLOR_3 to either side. Each side of the hexagon is one unit long. The hexagonal rods of color extend infinitely in the +y- and -y-directions. If no colors are specified then default blue, green and red colors are used. You may also use pigment statements in place of the colors. For example: pigment { hexagon pigment { Jade }, pigment { White_Marble }, pigment { Black_Marble } } This example uses normals: normal { hexagon 0.5 } The float value is an optional bump size. You may also use full normal statements. For example: normal { hexagon normal { gradient x scale .2 }, normal { gradient y scale .2 }, normal { bumps scale .2 } } When used with textures, the syntax is... texture { hexagon texture { T_Gold_3A }, texture { T_Wood_3A }, texture { Stone12 } } This is a block pattern which cannot use wave types, color_map XE "color_map" , or slope_map XE "slope_map"  modifiers. Leopard Leopard creates regular geometric pattern of circular spots. The formula used is: value = Sqr((sin(x)+sin(y)+sin(z))/3) Mandel The mandel XE "mandel"  pattern computes the standard Mandelbrot fractal pattern and projects it onto the x-y-plane. It uses the x and y coordinates to compute the Mandelbrot set. It is specified as pigment {mandel Max_Iteration [PIGMENT_MODIFIERS...] } The pattern is specified with the keyword mandel followed by an integer number. This number is the maximum number of iterations to be used to compute the set. Typical values range from 10 up to 256 but any positive integer may be used. For example: pigment { mandel 25 color_map { [0.0 color Cyan] [0.3 color Yellow] [0.6 color Magenta] [1.0 color Cyan] } scale .5 } The value passed to the color map is computed by the formula: value = number_of_iterations / max_iterations When used as a normal pattern, the syntax is... normal{mandel Max_Iteration [, Bump_Size] [NORMAL_MODIFIERS...] } where the integer Max_Iteration is a required parameter but the float Bump_Size which follows is optional. Note that the comma is required especially if Bump_Size is negative. Marble The marble XE "marble"  pattern is very similar to the gradient XE "gradient"  x pattern. The gradient pattern uses a default ramp_wave XE "ramp_wave"  wave type which means it uses colors from the color map from 0.0 up to 1.0 at location x=1 but then jumps back to the first color for x > 1 and repeats the pattern again and again. However the marble pattern uses the triangle_wave XE "triangle_wave"  wave type in which it uses the color map from 0 to 1 but then it reverses the map and blends from 1 back to zero. For example: pigment { gradient x color_map { [0.0 color Yellow] [1.0 color Cyan] } } This blends from yellow to cyan and then it abruptly changes back to yellow and repeats. However replacing gradient x with marble smoothly blends from yellow to cyan as the x coordinate goes from 0.0 to 0.5 and then smoothly blends back from cyan to yellow by x=1.0. Earlier versions of POV-Ray did not allow you to change wave types. Now that wave types can be changed for most any pattern, the distinction between marble and gradient x is only a matter of default wave types. When used with turbulence and an appropriate color map, this pattern looks like veins of color of real marble, jade or other types of stone. By default, marble has no turbulence. Onion The onion XE "onion"  is a pattern of concentric spheres like the layers of an onion. Value = mod(sqrt(Sqr(X)+Sqr(Y)+Sqr(Z)), 1.0) Each layer is one unit thick. Planar The planar XE "planar"  pattern creates a horizontal stripe plus or minus one unit above and below the X-Z plane. It is computed by: value =1.0- min(1, abs(Y)) It starts at 1.0 at the origin and increases to a minimum value of 0.0 as the Y values approaches a distance of 1 unit from the X-Z plane. It remains at 0.0 for all areas beyond that distance. This pattern was originally created for use with halo XE "halo"  or media XE "media"  but it may be used anywhere any pattern may be used. Quilted The quilted XE "quilted"  pattern was originally designed only to be used as a normal pattern. The quilted pattern is so named because it can create a pattern somewhat like a quilt or a tiled surface. The squares are actually 3-D cubes that are 1 unit in size. When used as a normal pattern, this pattern uses a specialized normal perturbation function. This means that the pattern cannot be used with normal_map XE "normal_map" , slope_map XE "slope_map"  or wave type modifiers in a normal XE "normal"  statement. When used as a pigment pattern or texture pattern, the quilted pattern is similar to normal quilted but is not identical as are most normals when compared to pigments. The two parameters control0 XE "control0"  and control1 XE "control1"  are used to adjust the curvature of the seam or gouge area between the quilts. The syntax is: It is specified as pigment {quilted [QUILTED_MODIFIERS...] } QUILTED_MODIFIERS: control0 Value_0 | control Value_1 | PIGMENT_MODIFIERS The values should generally be kept to around the 0.0 to 1.0 range. The default value is 1.0 if none is specified. Think of this gouge between the tiles in cross-section as a sloped line.  Quilted pattern with c0=0 and different values for c1.  Quilted pattern with c0=0.33 and different values for c1.  Quilted pattern with c0=0.67 and different values for c1.  Quilted pattern with c0=1 and different values for c1. This straight slope can be made to curve by adjusting the two control values. The control values adjust the slope at the top and bottom of the curve. A control values of 0 at both ends will give a linear slope, as shown above, yielding a hard edge. A control value of 1 at both ends will give an "s" shaped curve, resulting in a softer, more rounded edge. Radial The radial XE "radial"  pattern is a radial blend that wraps around the +y-axis. The color for value 0.0 starts at the +x-direction and wraps the color map around from east to west with 0.25 in the -z-direction, 0.5 in -x, 0.75 at +z and back to 1.0 at +x. Typically the pattern is used with a frequency XE "frequency"  modifier to create multiple bands that radiate from the y-axis. For example: pigement { radial color_map{[0.5 Black][0.5 White]} frequency 10 } creates 10 white bands and 10 black bands radiating from the y axis. Ripples The ripples XE "ripples"  pattern was originally designed only to be used as a normal pattern. It makes the surface look like ripples of water. The ripples radiate from 10 random locations inside the unit cube area <0,0,0> to <1,1,1>. Scale the pattern to make the centers closer or farther apart. Usually the ripples from any given center are about 1 unit apart. The frequency XE "frequency"  keyword changes the spacing between ripples. The phase XE "phase"  keyword can be used to move the ripples outwards for realistic animation. The number of ripple centers can be changed with the global parameter global_settings{number_of_waves Count } somewhere in the scene. This affects the entire scene. You cannot change the number of wave centers on individual patterns. See section " REF _Ref418945803 \h Number_Of_Waves" for details. When used as a normal pattern, this pattern uses a specialized normal perturbation function. This means that the pattern cannot be used with normal_map XE "normal_map" , slope_map XE "slope_map"  or wave type modifiers in a normal XE "normal"  statement. When used as a pigment pattern or texture pattern, the ripples pattern is similar to normal ripples but is not identical as are most normals when compared to pigments. Spherical The spherical XE "spherical"  pattern creates a one unit radius sphere along the Y axis. It is computed by: value = 1.0-min(1, sqrt(X^2 + Y^2 + Z^2)) It starts at 1.0 at the origin and increases to a max value of 0.0 as it approaches a distance of 1 unit from the origin in any direction. It remains at 0.0 for all areas beyond that distance. This pattern was originally created for use with halo XE "halo"  or media XE "media"  but it may be used anywhere any pattern may be used. Spiral1 The spiral1 XE "spiral1"  pattern creates a spiral that winds around the y-axis similar to a screw. When viewed sliced in the X-Z plane, it looks like the spiral arms of a galaxy. Its syntax is: pigment {spiral1 Number_of_Arms [PIGMENT_MODIFIERS...] } The Number_of_Arms value determines how may arms are winding around the y-axis. As a normal pattern, the syntax is normal {spiral1 Number_of_Arms [, Bump_Size] [NORMAL_MODIFIERS...] } where the vector is a required parameter but the float Bump_Size which follows is optional. Note that the comma is required especially if Bump_Size is negative. The pattern uses the triangle_wave XE "triangle_wave"  wave type by default but may use any wave type. Spiral2 The spiral2 XE "spiral2"  pattern creates a double spiral that winds around the y-axis similar spiral1 XE "spiral1"  except it is two overlapping spirals the twist in opposite directions. The results sometimes looks like a basket weave or perhaps the skin of pineapple. The center of a sunflower also has a similar double spiral pattern. Its syntax is: pigment {spiral2 Number_of_Arms [PIGMENT_MODIFIERS...] } The Number_of_Arms value determines how may arms are winding around the y-axis. As a normal pattern, the syntax is normal {spiral2 Number_of_Arms [, Bump_Size] [NORMAL_MODIFIERS...] } where the vector is a required parameter but the float Bump_Size which follows is optional. Note that the comma is required especially if Bump_Size is negative. The pattern uses the triangle_wave XE "triangle_wave"  wave type by default but may use any wave type. Spotted The spotted XE "spotted"  pattern is identical to the bozo XE "bozo"  pattern. Early versions of POV-Ray did not allow turbulence to be used with spotted. Now that any pattern can use turbulence there is no difference between bozo and spotted. See section " REF _Ref418947705 \h Bozo" for details. Waves The waves XE "waves"  pattern was originally designed only to be used as a normal pattern. It makes the surface look like waves on water. The waves pattern looks similar to the ripples pattern except the features are rounder and broader. The effect is to make waves that look more like deep ocean waves. The waves radiate from 10 random locations inside the unit cube area <0,0,0> to <1,1,1>. Scale the pattern to make the centers closer or farther apart. Usually the waves from any given center are about 1 unit apart. The frequency XE "frequency"  keyword changes the spacing between waves. The phase XE "phase"  keyword can be used to move the waves outwards for realistic animation. The number of wave centers can be changed with the global parameter global_settings{number_of_waves Count } somewhere in the scene. This affects the entire scene. You cannot change the number of wave centers on individual patterns. See section " REF _Ref418945803 \h Number_Of_Waves" for details. When used as a normal pattern, this pattern uses a specialized normal perturbation function. This means that the pattern cannot be used with normal_map XE "normal_map" , slope_map XE "slope_map"  or wave type modifiers in a normal XE "normal"  statement. When used as a pigment pattern or texture pattern, the waves pattern is similar to normal waves but is not identical as are most normals when compared to pigments. Wood The wood XE "wood"  pattern consists of concentric cylinders centered on the z-axis. When appropriately colored, the bands look like the growth rings and veins in real wood. Small amounts of turbulence should be added to make it look more realistic. By default, wood has no turbulence. Unlike most patterns, the wood pattern uses the triangle_wave XE "triangle_wave"  wave type by default. This means that like marble, wood uses color map values 0.0 to 1.0 then repeats the colors in reverse order from 1.0 to 0.0. However you may use any wave type. Wrinkles The wrinkles XE "wrinkles"  pattern was originally designed only to be used as a normal pattern. It uses a 1/f noise pattern similar to granite but the features in wrinkles are sharper. The pattern can be used to simulate wrinkled cellophane or foil. It also makes an excellent stucco texture. When used as a normal pattern, this pattern uses a specialized normal perturbation function. This means that the pattern cannot be used with normal_map XE "normal_map" , slope_map XE "slope_map"  or wave type modifiers in a normal XE "normal"  statement. When used as a pigment pattern or texture pattern, the wrinkles pattern is similar to normal wrinkles but is not identical as are most normals when compared to pigments. Pattern Modifiers Pattern modifiers are statements or parameters which modify how a pattern is evaluated or tells what to do with the pattern. The complete syntax is: PATTERN_MODIFIER: BLEND_MAP_MODIFIER | AGATE_MODIFIER | DENSITY_FILE_MODIFIER | QUILTED_MODIFIER | BRICK_MODIFIER | turbulence | octaves Count | omega Amount | lambda Amount | warp { [WARP_ITEMS...] } | TRANSFORMATION BLEND_MAP_MODIFIER: frequency Amount | phase Amount | ramp_wave | triangle_wave | sine_wave | scallop_wave | cubic_wave | poly_wave [Exponent] AGATE_MODIFIER: agate_turb Value BRICK_MODIFIER: brick_size Size | mortar Size DENSITY_FILE_MODIFIER: interpolate Type QUILTED_MODIFIER: control0 Value | control1 Value PIGMENT_MODIFIER: PATTERN_MODIFIER | COLOR_LIST | PIGMENT_LIST | color_map{ COLOR_MAP_BODY } | colour_map{ COLOR_MAP_BODY } | pigment_map{ PIGMENT_MAP_BODY } | quick_color COLOR | quick_colour COLOR NORMAL_MODIFIER: PATTERN_MODIFIER | NORMAL_LIST | normal_map{ NORMAL_MAP_BODY } | slope_map{ SLOPE_MAP_BODY } | bump_size Amount TEXTURE_PATTERN_MODIFIER: PATTERN_MODIFIER | TEXTURE_LIST | texture_map{ TEXTURE_MAP_BODY } DENSITY_MODIFIER: PATTERN_MODIFIER | DENSITY_LIST | COLOR_LIST | color_map{ COLOR_MAP_BODY } | colour_map{ COLOR_MAP_BODY } | density_map{ DENSITY_MAP_BODY } The modifiers PIGMENT_LIST, quick_color XE "quick_color" , and pigment_map XE "pigment_map"  apply only to pigments. See section " REF _Ref418948513 \h Pigment" for details on these pigment-specific pattern modifiers. The modifiers COLOR_LIST and color_map XE "color_map"  apply only to pigments and densities. See sections " REF _Ref418948513 \h Pigment" and " REF _Ref420163369 \h Density" for details on these pigment-specific pattern modifiers. The modifiers NORMAL_LIST, bump_size XE "bump_size" , slope_map XE "slope_map"  and normal_map XE "normal_map"  apply only to normals. See section " REF _Ref418948620 \h Normal" for details on these normal-specific pattern modifiers. The TEXTURE_LIST and texture_map XE "texture_map"  modifiers can only be used with patterned textures. See section " REF _Ref418948678 \h Texture Maps" for details. The DENSITY_LIST and density_map XE "density_map"  modifiers only work with media{density{..}} statements. See " REF _Ref418948799 \h Density" for details. The agate_turb XE "agate_turb"  modifier can only be used with the agate XE "agate"  pattern. See " REF _Ref419107472 \h Agate" for details. The brick_size XE "brick_size"  and mortar XE "mortar"  modifiers can only be used with the brick XE "brick"  pattern. See " REF _Ref419875240 \h Brick" for details. The control0 XE "control0"  and control1 XE "control1"  modifiers can only be used with the quilted XE "quilted"  pattern. See " REF _Ref419875421 \h Quilted" for details. The interpolate XE "interpolate"  modifier can only be used with the density_file XE "density_file"  pattern. See " REF _Ref421689780 \h Density_File" for details. The general purpose pattern modifiers in the following sections can be used with pigment XE "pigment" , normal XE "normal" , texture XE "texture" , or density XE "density"  patterns. Transforming Patterns The most common pattern modifiers are the transformation modifiers translate XE "translate" , rotate XE "rotate" , scale XE "scale" , transform XE "transform" , and matrix XE "matrix" . For details on these commands see section " REF _Ref419875652 \h Transformations". These modifiers may be placed inside pigment, normal, texture, and density statements to change the position, size and orientation of the patterns. Transformations are performed in the order in which you specify them. However in general the order of transformations relative to other pattern modifiers such as turbulence XE "turbulence" , color_map XE "color_map"  and other maps is not important. For example scaling before or after turbulence makes no difference. The turbulence is done first, then the scaling regardless of which is specified first. However the order in which transformations are performed relative to warp XE "warp"  statements is important. See " REF _Ref419875889 \h Warps" for details. Frequency and Phase The frequency XE "frequency"  and phase XE "phase"  modifiers act as a type of scale and translate modifiers for various blend maps. They only have effect when blend maps are used. Blend maps are color_map XE "color_map" , pigment_map XE "pigment_map" , normal_map XE "normal_map" , slope_map XE "slope_map" , density_map XE "density_map" , and texture_map XE "texture_map" . This discussion uses a color map as an example but the same principles apply to the other blend map types. The frequency keyword adjusts the number of times that a color map repeats over one cycle of a pattern. For example gradient XE "gradient"  covers color map values 0 to 1 over the range from x=0 to x=1. By adding frequency 2.0 the color map repeats twice over that same range. The same effect can be achieved using scale 0.5*x so the frequency keyword isn't that useful for patterns like gradient. However the radial pattern wraps the color map around the +y-axis once. If you wanted two copies of the map (or 3 or 10 or 100) you'd have to build a bigger map. Adding frequency 2.0 causes the color map to be used twice per revolution. Try this: pigment { radial color_map{[0.5 color Red][0.5 color White]} frequency 6 } The result is six sets of red and white radial stripes evenly spaced around the object. The float after frequency can be any value. Values greater than 1.0 causes more than one copy of the map to be used. Values from 0.0 to 1.0 cause a fraction of the map to be used. Negative values reverses the map. The phase XE "phase"  value causes the map entries to be shifted so that the map starts and ends at a different place. In the example above if you render successive frames at phase 0 then phase 0.1, phase 0.2, etc. you could create an animation that rotates the stripes. The same effect can be easily achieved by rotating the radial XE "radial"  pigment using rotate y*Angle but there are other uses where phase can be handy. Sometimes you create a great looking gradient or wood color map but you want the grain slightly adjusted in or out. You could re-order the color map entries but that's a pain. A phase adjustment will shift everything but keep the same scale. Try animating a mandel XE "mandel"  pigment for a color palette rotation effect. These values work by applying the following formula New_Value = fmod ( Old_Value * Frequency + Phase, 1.0 ). The frequency and phase modifiers have no effect on block patterns checker XE "checker" , brick XE "brick" , and hexagon XE "hexagon"  nor do they effect image_map XE "image_map" , bump_map XE "bump_map"  or material_map XE "material_map" . They also have no effect in normal statements when used with bumps XE "bumps" , dents XE "dents" , quilted XE "quilted"  or wrinkles XE "wrinkles"  because these normal patterns cannot use normal_map XE "normal_map"  or slope_map XE "slope_map" . They can be used with normal patterns ripples XE "ripples"  and waves XE "waves"  even though these two patterns cannot use normal_map or slope_map either. When used with ripples or waves, frequency adjusts the space between features and phase can be adjusted from 0.0 to 1.0 to cause the ripples or waves to move relative to their center for animating the features. Waveforms POV-Ray allows you to apply various wave forms to the pattern function before applying it to a blend map. Blend maps are color_map XE "color_map" , pigment_map XE "pigment_map" , normal_map XE "normal_map" , slope_map XE "slope_map" , density_map XE "density_map" , and texture_map XE "texture_map" . Most of the patterns which use a blend map, use the entries in the map in order from 0.0 to 1.0. The effect can most easily be seen when these patterns are used as normal patterns with no maps. Patterns such as gradient XE "gradient"  or onion XE "onion"  generate a grove or slot that looks like a ramp that drops off sharply. This is called a ramp_wave XE "ramp_wave"  wave type and it is the default wave type for most patterns. However the wood XE "wood"  and marble XE "marble"  patterns use the map from 0.0 to 1.0 and then reverses it and runs it from 1.0 to 0.0. The result is a wave form which slopes upwards to a peak, then slopes down again in a triangle_wave XE "triangle_wave" . In earlier versions of POV-Ray there was no way to change the wave types. You could simulate a triangle wave on a ramp wave pattern by duplicating the map entries in reverse, however there was no way to use a ramp wave on wood or marble. Now any pattern that takes a map can have the default wave type overridden. For example: pigment { wood color_map { MyMap } ramp_wave } Also available are sine_wave XE "sine_wave" , scallop_wave XE "scallop_wave" , cubic_wave XE "cubic_wave"  and poly_wave XE "poly_wave"  types. These types are of most use in normal patterns as a type of built-in slope map. The sine_wave takes the zig-zag of a ramp wave and turns it into a gentle rolling wave with smooth transitions. The scallop_wave uses the absolute value of the sine wave which looks like corduroy when scaled small or like a stack of cylinders when scaled larger. The cubic_wave is a gentle cubic curve from 0.0 to 1.0 with zero slope at the start and end. The poly_wave is an exponential function. It is followed by an optional float value which specifies exponent. For example poly_wave 2 starts low and climbs rapidly at the end while poly_wave 0.5 climbs rapidly at first and levels off at the end. If no float value is specified, the default is 1.0 which produces a linear function identical to ramp_wave. Although any of these wave types can be used for pigments, normals, textures, or density the effect of many of the wave types are not as noticeable on pigments, textures, or density as they are for normals. Wave type modifiers have no effect on block patterns checker XE "checker" , brick XE "brick" , and hexagon XE "hexagon"  nor do they effect image_map XE "image_map" , bump_map XE "bump_map"  or material_map XE "material_map" . They also have no effect in normal statements when used with bumps XE "bumps" , dents XE "dents" , quilted XE "quilted" , ripples XE "ripples" , waves XE "waves" , or wrinkles XE "wrinkles"  because these normal patterns cannot use normal_map XE "normal_map"  or slope_map XE "slope_map" . Turbulence The keyword turbulence XE "turbulence"  followed by a float or vector may be used to stir up any pigment XE "pigment" , normal XE "normal" , texture XE "texture" , irid XE "irid"  or density XE "density" . A number of optional parameters may be used with turbulence to control how it is computed. The syntax is: TURBULENCE_ITEM: turbulence | octaves Count | omega Amount | lambda Amount Typical turbulence values range from the default 0.0, which is no turbulence, to 1.0 or more, which is very turbulent. If a vector is specified different amounts of turbulence are applied in the x-, y- and z-direction. For example turbulence <1.0, 0.6, 0.1> has much turbulence in the x-direction, a moderate amount in the y-direction and a small amount in the z-direction. Turbulence uses a random noise function called DNoise. This is similar to the noise used in the bozo XE "bozo"  pattern except that instead of giving a single value it gives a direction. You can think of it as the direction that the wind is blowing at that spot. Points close together generate almost the same value but points far apart are randomly different. In general the order of turbulence parameters relative to other pattern modifiers such as transformations, color maps and other maps is not important. For example scaling before or after turbulence makes no difference. The turbulence is done first, then the scaling regardless of which is specified first. See section "" for a way to work around this behavior. In general, the order of turbulence parameters relative to each other and to other pattern modifiers such as transformations or color_map XE "color_map"  and other maps is not important. For example scaling before or after turbulence makes no difference. The turbulence is done first, then the scaling regardless of which is specified first. However the order in which transformations are performed relative to warp XE "warp"  statements is important. You can also specify turbulence inside warp and in this way you can force turbulence to be applied after transformations. See " REF _Ref419875889 \h Warps" for details. Turbulence uses DNoise to push a point around in several steps called octaves XE "octaves" . We locate the point we want to evaluate, then push it around a bit using turbulence to get to a different point then look up the color or pattern of the new point. It says in effect "Don't give me the color at this spot... take a few random steps in different directions and give me that color". Each step is typically half as long as the one before. For example:  Turbulence random walk. The magnitude of these steps is controlled by the turbulence value. There are three additional parameters which control how turbulence is computed. They are octaves, lambda XE "lambda"  and omega XE "omega" . Each is optional. Each is followed by a single float value. Each has no effect when there is no turbulence. Octaves The octaves XE "octaves"  keyword may be followed by an integer value to control the number of steps of turbulence that are computed. Legal values range from 1 to 10. The default value of 6 is a fairly high value; you won't see much change by setting it to a higher value because the extra steps are too small. Float values are truncated to integer. Smaller numbers of octaves give a gentler, wavy turbulence and computes faster. Higher octaves create more jagged or fuzzy turbulence and takes longer to compute. Lambda The lambda XE "lambda"  parameter controls how statistically different the random move of an octave is compared to its previous octave. The default value is 2.0 which is quite random. Values close to lambda 1.0 will straighten out the randomness of the path in the diagram above. The zig-zag steps in the calculation are in nearly the same direction. Higher values can look more swirly under some circumstances. Omega The omega XE "omega"  value controls how large each successive octave step is compared to the previous value. Each successive octave of turbulence is multiplied by the omega value. The default omega 0.5 means that each octave is 1/2 the size of the previous one. Higher omega values mean that 2nd, 3rd, 4th and up octaves contribute more turbulence giving a sharper, crinkly look while smaller omegas give a fuzzy kind of turbulence that gets blurry in places. Warps The warp XE "warp"  statement is a pattern modifier that is similar to turbulence. Turbulence works by taking the pattern evaluation point and pushing it about in a series of random steps. However warps push the point in very well-defined, non-random, geometric ways. The warp statement also overcomes some limitations of traditional turbulence and transformations by giving the user more control over the order in which turbulence, transformation and warp modifiers are applied to the pattern. Currently there are three types of warps but the syntax was designed to allow future expansion. The first two, the repeat XE "repeat"  warp and the black_hole XE "black_hole"  warp are new features for POV-Ray that modify the pattern in geometric ways. The other warp provides an alternative way to specify turbulence. The syntax for using a warp statement is: WARP: warp { WARP_ITEM } WARP_ITEM: repeat [REPEAT_ITEMS...] | black_hole , Radius [BLACK_HOLE_ITEMS...] | turbulence [TURB_ITEMS...] REPEAT_ITEMS: offset | flip BLACK_HOLE_ITEMS: strength Strength | falloff Amount | inverse | type Type | repeat | turbulence TURB_ITEMS: octaves Count | omega Amount | lambda Amount You may have as many separate warp statements as you like in each pattern. The placement of warp statements relative to other modifiers such as color_map XE "color_map"  or turbulence XE "turbulence"  is not important. However placement of warp statements relative to each other and to transformations is significant. Multiple warps and transformations are evaluated in the order in which you specify them. For example if you translate, then warp or warp, then translate, the results can be different. Black Hole Warp A black_hole XE "black_hole"  warp is so named because of its similarity to real black holes. Just like the real thing, you cannot actually see a black hole. The only way to detect its presence is by the effect it has on things that surround it. Take, for example, a wood grain. Using POV-Ray's normal turbulence and other texture modifier functions, you can get a nice, random appearance to the grain. But in its randomness it is regular - it is regularly random! Adding a black hole allows you to create a localized disturbance in a wood grain in either one or multiple locations. The black hole can have the effect of either sucking the surrounding texture into itself (like the real thing) or pushing it away. In the latter case, applied to a wood grain, it would look to the viewer as if there were a knothole in the wood. In this text we use a wood grain regularly as an example, because it is ideally suitable to explaining black holes. However, black holes may in fact be used with any texture or pattern. The effect that the black hole has on the texture can be specified. By default, it sucks with the strength calculated exponentially (inverse-square). You can change this if you like. Black holes may be used anywhere a warp is permitted. The syntax is: BLACK_HOLE_WARP: warp {black_hole , Radius [BLACK_HOLE_ITEMS...] } BLACK_HOLE_ITEMS: strength Strength | falloff Amount | inverse | type Type | repeat | turbulence The minimal requirement is the black_hole keyword followed by a vector followed by a comma and a float Radius. Black holes effect all points within the spherical region around the location and within the radius. This is optionally followed by any number of other keywords which control how the texture is warped. The falloff XE "falloff"  keyword may be used with a float value to specify the power by which the effect of the black hole falls off. The default is two. The force of the black hole at any given point, before applying the strength XE "strength"  modifier, is as follows. First, convert the distance from the point to the center to a proportion (0 to 1) that the point is from the edge of the black hole. A point on the perimeter of the black hole will be 0.0; a point at the center will be 1.0; a point exactly halfway will be 0.5, and so forth. Mentally you can consider this to be a closeness factor. A closeness of 1.0 is as close as you can get to the center (i.e. at the center), a closeness of 0.0 is as far away as you can get from the center and still be inside the black hole and a closeness of 0.5 means the point is exactly halfway between the two. Call this value c. Raise c to the power specified in falloff. By default Falloff is 2, so this is c2 or c squared. The resulting value is the force of the black hole at that exact location and is used, after applying the strength scaling factor as described below, to determine how much the point is perturbed in space. For example, if c is 0.5 the force is 0.52 or 0.25. If c is 0.25 the force is 0.125. But if c is exactly 1.0 the force is 1.0. Recall that as c gets smaller the point is farther from the center of the black hole. Using the default power of 2, you can see that as c reduces, the force reduces exponentially in an inverse-square relationship. Put in plain English, it means that the force is much stronger (by a power of two) towards the center than it is at the outside. By increasing falloff, you can increase the magnitude of the falloff. A large value will mean points towards the perimeter will hardly be affected at all and points towards the center will be affected strongly. A value of 1.0 for falloff will mean that the effect is linear. A point that is exactly halfway to the center of the black hole will be affected by a force of exactly 0.5. A value of falloff of less than one but greater than zero means that as you get closer to the outside, the force increases rather than decreases. This can have some uses but there is a side effect. Recall that the effect of a black hole ceases outside its perimeter. This means that points just within the perimeter will be affected strongly and those just outside not at all. This would lead to a visible border, shaped as a sphere. A value for falloff of 0 would mean that the force would be 1.0 for all points within the black hole, since any number larger 0 raised to the power of 0 is 1.0. The strength keyword may be specified with a float value to give you a bit more control over how much a point is perturbed by the black hole. Basically, the force of the black hole (as determined above) is multiplied by the value of strength, which defaults to 1.0. If you set strength to 0.5, for example, all points within the black hole will be moved by only half as much as they would have been. If you set it to 2.0 they will be moved twice as much. There is a rider to the latter example, though - the movement is clipped to a maximum of the original distance from the center. That is to say, a point that is 0.75 units from the center may only be moved by a maximum of 0.75 units either towards the center or away from it, regardless of the value of strength. The result of this clipping is that you will have an exclusion area near the center of the black hole where all points whose final force value exceeded or equaled 1.0 were moved by a fixed amount. If the inverted XE "inverted"  keyword is specified then points pushed away from the center instead of being pulled in. The repeat XE "repeat"  keyword followed by a vector, allows you to simulate the effect of many black holes without having to explicitly declare them. Repeat is a vector that tells POV-Ray to use this black hole at multiple locations. Using repeat logically divides your scene up into cubes, the first being located at <0,0,0> and going to . Suppose your repeat vector was <1,5,2>. The first cube would be from <0,0,0> to < 1,5,2>. This cube repeats, so there would be one at < -1,-5,-2>, <1,5,2>, <2,10,4> and so forth in all directions, ad infinitum. When you use repeat, the center of the black hole does not specify an absolute location in your scene but an offset into each block. It is only possible to use positive offsets. Negative values will produce undefined results. Suppose your center was <0.5,1,0.25> and the repeat vector is <2,2,2>. This gives us a block at < 0,0,0> and <2,2,2>, etc. The centers of the black hole's for these blocks would be <0,0,0> + < 0.5,1.0,0.25>, i. e. <0.5,1.0,0.25>, and < 2,2,2> + <0.5,1.0,0.25>, i. e. < 2,5,3.0,2.25>. Due to the way repeats are calculated internally, there is a restriction on the values you specify for the repeat vector. Basically, each black hole must be totally enclosed within each block (or cube), with no part crossing into a neighboring one. This means that, for each of the x, y and z dimensions, the offset of the center may not be less than the radius, and the repeat value for that dimension must be >=the center plus the radius since any other values would allow the black hole to cross a boundary. Put another way, for each of x, y and z Radius <= Offset or Center <= Repeat - Radius. If the repeat vector in any dimension is too small to fit this criteria, it will be increased and a warning message issued. If the center is less than the radius it will also be moved but no message will be issued. Note that none of the above should be read to mean that you can't overlap black holes. You most certainly can and in fact this can produce some most useful effects. The restriction only applies to elements of the same black hole which is repeating. You can declare a second black hole that also repeats and its elements can quite happily overlap the first and causing the appropriate interactions. It is legal for the repeat value for any dimension to be 0, meaning that POV-Ray will not repeat the black hole in that direction. The turbulence XE "turbulence"  can only be used in a black hole with repeat. It allows an element of randomness to be inserted into the way the black holes repeat, to cause a more natural look. A good example would be an array of knotholes in wood - it would look rather artificial if each knothole were an exact distance from the previous. The turbulence vector is a measurement that is added to each individual back hole in an array, after each axis of the vector is multiplied by a different random amount ranging from 0 to 1. The resulting actual position of the black hole's center for that particular repeat element is random (but consistent, so renders will be repeatable) and somewhere within the above co-ordinates. There is a rider on the use of turbulence, which basically is the same as that of the repeat vector. You can't specify a value which would cause a black hole to potentially cross outside of its particular block. In summary: For each of x, y and z the offset of the center must be >=radius and the value of the repeat must be >= center + radius + turbulence. The exception being that repeat may be 0 for any dimension, which means do not repeat in that direction. Some examples are given by warp { black_hole <0, 0, 0>, 0.5 } warp { black_hole <0.15, 0.125, 0>, 0.5 falloff 7 strength 1.0 repeat <1.25, 1.25, 0> turbulence <0.25, 0.25, 0> inverse } warp { black_hole <0, 0, 0>, 1.0 falloff 2 strength 2 inverse } Repeat Warp The repeat XE "repeat"  warp causes a section of the pattern to be repeated over and over. It takes a slice out of the pattern and makes multiple copies of it side-by-side. The warp has many uses but was originally designed to make it easy to model wood veneer textures. Veneer is made by taking very thin slices from a log and placing them side-by-side on some other backing material. You see side-by-side nearly identical ring patterns but each will be a slice perhaps 1/32th of an inch deeper. The syntax for a repeat warp is REPEAT_WARP: warp { repeat [REPEAT_ITEMS...] } REPEAT_ITEMS: offset | flip The repeat vector specifies the direction in which the pattern repeats and the width of the repeated area. This vector must lie entirely along an axis. In other words, two of its three components must be 0. For example pigment { wood warp {repeat 2*x} } which means that from x=0 to x=2 you get whatever the pattern usually is. But from x=2 to x=4 you get the same thing exactly shifted two units over in the x-direction. To evaluate it you simply take the x-coordinate modulo 2. Unfortunately you get exact duplicates which isn't very realistic. The optional offset XE "offset"  vector tells how much to translate the pattern each time it repeats. For example pigment { wood warp {repeat x*2 offset z*0.05} } means that we slice the first copy from x=0 to x=2 at z=0 but at x=2 to x=4 we offset to z=0.05. In the 4 to 6 interval we slice at z=0.10. At the n-th copy we slice at 0.05 n z. Thus each copy is slightly different. There are no restrictions on the offset vector. Finally the flip XE "flip"  vector causes the pattern to be flipped or mirrored every other copy of the pattern. The first copy of the pattern in the positive direction from the axis is not flipped. The next farther is, the next is not, etc. The flip vector is a three component x, y, z vector but each component is treated as a boolean value that tells if you should or should not flip along a given axis. For example pigment { wood warp {repeat 2*x flip <1,1,0>} } means that every other copy of the pattern will be mirrored about the x- and y- axis but not the z-axis. A non-zero value means flip and zero means do not flip about that axis. The magnitude of the values in the flip vector doesn't matter. Turbulence Warp The POV-Ray language contains an ambiguity and limitation on the way you specify turbulence XE "turbulence"  and transformations such as translate XE "translate" , rotate XE "rotate" , scale XE "scale" , matrix XE "matrix" , and transform XE "transform"  transforms. Usually the turbulence is done first. Then all translate, rotate, scale, matrix, and transform operations are always done after turbulence regardless of the order in which you specify them. For example this pigment { wood scale .5 turbulence .2 } works exactly the same as pigment { wood turbulence .2 scale .5 } The turbulence is always first. A better example of this limitation is with uneven turbulence and rotations. pigment { wood turbulence 0.5*y rotate z*60 } // as compared to pigment { wood rotate z*60 turbulence 0.5*y } The results will be the same either way even though you'd think it should look different. We cannot change this basic behavior in POV-Ray now because lots of scenes would potentially render differently if suddenly the order transformation vs. turbulence suddenly mattered when in the past, it didn't. However, by specifying our turbulence inside warp statement you tell POV-Ray that the order in which turbulence, transformations and other warps are applied is significant. Here's an example of a turbulence warp. warp { turbulence <0,1,1> octaves 3 lambda 1.5 omega 0.3 } The significance is that this pigment { wood translate <1,2,3> rotate x*45 scale 2 warp { turbulence <0,1,1> octaves 3 lambda 1.5 omega 0.3 } } produces different results than this... pigment { wood warp { turbulence <0,1,1> octaves 3 lambda 1.5 omega 0.3 } translate <1,2,3> rotate x*45 scale 2 } You may specify turbulence without using a warp statement. However you cannot control the order in which they are evaluated unless you put them in a warp. The evaluation rules are as follows: 1) First any turbulence not inside a warp statement is applied regardless of the order in which it appears relative to warps or transformations. 2) Next each warp statement, translate, rotate, scale or matrix one-by-one, is applied in the order the user specifies. If you want turbulence done in a specific order, you simply specify it inside a warp in the proper place. Bitmap Modifiers A bitmap modifier is a modifier used inside an image_map XE "image_map" , bump_map XE "bump_map"  or material_map XE "material_map"  to specify how the 2-D bitmap is to be applied to the 3-D surface. Several bitmap modifiers apply to specific kinds of maps and they are covered in the appropriate sections. The bitmap modifiers discussed in the following sections are applicable to all three types of bitmaps. The once Option Normally there are an infinite number of repeating image maps, bump maps or material maps created over every unit square of the x-y-plane like tiles. By adding the once XE "once"  keyword after a file name you can eliminate all other copies of the map except the one at (0,0) to (1,1). In image maps, areas outside this unit square are treated as fully transparent. In bump maps, areas outside this unit square are left flat with no normal modification. In material maps, areas outside this unit square are textured with the first texture of the texture list. For example: image_map { gif "mypic.gif" once } The map_type Option The default projection of the image onto the x-y-plane is called a planar map type. This option may be changed by adding the map_type XE "map_type"  keyword followed by an integer number specifying the way to wrap the image around the object. A map_type 0 gives the default planar mapping already described. A map_type 1 gives a spherical mapping. It assumes that the object is a sphere of any size sitting at the origin. The y-axis is the north/south pole of the spherical mapping. The top and bottom edges of the image just touch the pole regardless of any scaling. The left edge of the image begins at the positive x-axis and wraps the image around the sphere from west to east in a -y-rotation. The image covers the sphere exactly once. The once XE "once"  keyword has no meaning for this mapping type. With map_type 2 you get a cylindrical mapping. It assumes that a cylinder of any diameter lies along the y-axis. The image wraps around the cylinder just like the spherical map but the image remains one unit tall from y=0 to y=1. This band of color is repeated at all heights unless the once XE "once"  keyword is applied. Finally map_type 5 is a torus or donut shaped mapping. It assumes that a torus of major radius one sits at the origin in the x-z-plane. The image is wrapped around similar to spherical or cylindrical maps. However the top and bottom edges of the map wrap over and under the torus where they meet each other on the inner rim. Types 3 and 4 are still under development. Note that the map_type option may also be applied to bump_map XE "bump_map"  and material_map XE "material_map"  statements. For example: sphere{<0,0,0>,1 pigment{ image_map { gif "world.gif" map_type 1 } } } The interpolate Option Adding the interpolate XE "interpolate"  keyword can smooth the jagged look of a bitmap. When POV-Ray asks an image map color or a bump amount for a bump map, it often asks for a point that is not directly on top of one pixel but sort of between several differently colored pixels. Interpolations returns an in-between value so that the steps between the pixels in the map will look smoother. Although interpolate is legal in material maps, the color index is interpolated before the texture is chosen. It does not interpolate the final color as you might hope it would. In general, interpolation of material maps serves no useful purpose but this may be fixed in future versions. There are currently two types of interpolation: interpolate 2 gives bilinear interpolation while interpolate 4 gives normalized distance. For example: image_map { gif "mypic.gif" interpolate 2 } Default is no interpolation. Normalized distance is the slightly faster of the two, bilinear does a better job of picking the between color. Normally bilinear is used. If your map looks jaggy, try using interpolation instead of going to a higher resolution image. The results can be very good. Media The media XE "media"  statement is used to specify particulate matter suspended in a medium such air or water. It can be used to specify smoke, haze, fog, gas, fire, dust etc. Previous versions of POV-Ray had two incompatible systems for generating such effects. One was halo XE "halo"  for effects enclosed in a transparent or semi-transparent object. The other was atmosphere XE "atmosphere"  for effects that permeated the entire scene. This duplication of systems was complex and unnecessary. Both halo and atmosphere have been eliminated. See " REF _Ref417286060 \h Why are Interior and Media Necessary?" for further details on this change. See " REF _Ref420157351 \h Object Media" for details on how to use media with objects. See " REF _Ref420157406 \h Atmospheric Media" for details on using media for atmospheric effects outside of objects. This section and the sub-sections which follow explains the details of the various media options which are useful for either object media or atmospheric media. Media works by sampling the density of particles at some specified number of points along the ray's path. Sub-samples are also taken until the results reach a specified confidence level. When used in an object's interior XE "interior"  statement, sampling only occurs inside the object. When used for atmospheric media, the samples run from the camera location until the ray strikes an object. Therefore for localized effects, it is best to use an enclosing object even though the density pattern might only produce results in a small area whether the media was enclosed or not. The complete syntax for a media statement is as follows: MEDIA: media { [MEDIA_IDENTIFIER] [MEDIA_ITEMS...] } MEDIA_ITEMS: intervals Number | samples Min, Max | confidence Value | variance Value | ratio Value | absorption COLOR | emission COLOR | scattering { Type, COLOR [ eccentricity Value ] [ extinction Value ] } | density { [DENSITY_IDENTIFIER] [PATTERN_TYPE] [DENSITY_MODIFIER...] } | TRANSFORMATIONS DENSITY_MODIFIER: PATTERN_MODIFIER | DENSITY_LIST | COLOR_LIST | color_map{ COLOR_MAP_BODY } | colour_map{ COLOR_MAP_BODY } | density_map{ DENSITY_MAP_BODY } If a media identifier is specified, it must be the first item. All other media items may be specified in any order. All are optional. You may have multiple density XE "density"  statements in a single media statement. See " REF _Ref428014795 \h Multiple Density vs. Multiple Media" for details. Transformations apply only the density statements which have been already specified. Any density after a transformation is not affected. If the media has no density statements and none was specified in any media identifier, then the transformation has no effect. All other media items except for density and transformations override default values or any previously set values for this media statement. Note that some media effects depend upon light sources. However the participation of a light source depends upon the media_interaction XE "media_interaction"  and media_attenuation XE "media_attenuation"  keywords. See " REF _Ref420911832 \h Atmospheric Media Interaction" and " REF _Ref420911866 \h Atmospheric Attenuation" for details. Note a strange design side-effect was discovered during testing and it was too difficult to fix. If the enclosing object uses transmit XE "transmit"  rather than filter XE "filter"  for transparency, then the media casts no shadows. For example: object{MyObject pigment{rgbt 1.0} interior{media{MyMedia}}} //no shadows object{MyObject pigment{rgbf 1.0} interior{media{MyMedia}}} //shadows Media Types There are three types of particle interaction in media XE "media" : absorbing, emitting, and scattering. All three activities may occur in a single media. Each of these three specifications requires a color. Only the red, green, and blue components of the color are used. The filter and transmit values are ignored. For this reason it is permissible to use one float value to specify an intensity of white color. For example the following two lines are legal and produce the same results: emission 0.75 emission rgb<0.75,0.75,0.75> Absorption The absorption XE "absorption"  keyword specifies a color of light which is absorbed when looking through the media. For example absorption rgb<0,1,0> blocks the green light but permits red and blue to get through. Therefore a white object behind the media will appear magenta. The default value is rgb<0,0,0> which means no light is absorbed -- all light passes through normally. Emission The emission XE "emission"  keyword specifies a color of the light emitted from the particles. Although we say they "emit" light, this only means that they are visible without any illumination shining on them. They to not really emit light that is cast on to nearby objects. This is similar to an object with high ambient XE "ambient"  values. The default value is rgb<0,0,0> which means no light is emitted. Scattering The syntax of a scattering XE "scattering"  statement is: SCATTERING: scattering { Type, COLOR [ eccentricity Value ] [ extinction Value ] } The first float value specifies the type of scattering. This is followed by the color of the scattered light. The default value if no scattering statement is given is rgb<0,0,0> which means no scattering occurs. The scattering effect is only visible when light is shining on the media from a light source. This is similar to difuse XE "difuse"  reflection off of an object. In addition to reflecting light, a scattering media also absorbs light like an absorption XE "absorption"  media. The balance between how much absorption occurs for a given amount of scattering is controlled by the optional extinction XE "extinction"  keyword and a single float value. The default value of 1.0 gives an extinction effect that matches the scattering. Values such as extinction 0.25 give 25% the normal amount. Using extinction 0.0 turns it off completely. Any value other than the 1.0 default is contrary to the real physical model but decreasing extinction can give you more artistic flexibility. The integer value Type specifies one of five different scattering phase functions representing the different models: isotropic, Mie (haze and murky atmosphere), Rayleigh, and Henyey-Greenstein. Type 1, isotropic scattering is the simplest form of scattering because it is independent of direction. The amount of light scattered by particles in the atmosphere does not depend on the angle between the viewing direction and the incoming light. Types 2 and 3 are Mie haze and Mie murky scattering which are used for relatively small particles such as minuscule water droplets of fog, cloud particles, and particles responsible for the polluted sky. In this model the scattering is extremely directional in the forward direction i.e. the amount of scattered light is largest when the incident light is anti-parallel to the viewing direction (the light goes directly to the viewer). It is smallest when the incident light is parallel to the viewing direction. The haze and murky atmosphere models differ in their scattering characteristics. The murky model is much more directional than the haze model.  The Mie "haze" scattering function.  The Mie "murky" scattering function. Type 3 Rayleigh scattering models the scattering for extremely small particles such as molecules of the air. The amount of scattered light depends on the incident light angle. It is largest when the incident light is parallel or anti-parallel to the viewing direction and smallest when the incident light is perpendicular to the viewing direction. You should note that the Rayleigh model used in POV-Ray does not take the dependency of scattering on the wavelength into account.  The Rayleigh scattering function. Type 5 is the Henyey-Greenstein scattering model. It is based on an analytical function and can be used to model a large variety of different scattering types. The function models an ellipse with a given eccentricity e. This eccentricity is specified by the optional keyword eccentricity XE "eccentricity"  which is only used for scattering type five. The default eccentricity value of zero defines isotropic scattering while positive values lead to scattering in the direction of the light and negative values lead to scattering in the opposite direction of the light. Larger values of e (or smaller values in the negative case) increase the directional property of the scattering.  The Heyney-Greenstein scattering function for different eccentricity values. Sampling Parameters Media effects are calculated by sampling the media along the path of the ray. It uses a method called Monte Carlo integration. The intervals XE "intervals"  keyword may be used to specify the integer number of intervals used to sample the ray. The default number of intervals is 10. For object media the intervals are spread between the entry and exit points as the ray passes through the container object. For atmospheric media, the intervals span entire length of the ray from its start until it hits an object. For media types which interact with spotlights or cylinder lights, the intervals which are not illuminated by these light types are weighted differently than the illuminated intervals when distributing samples. The ratio XE "ratio"  keyword distributes intervals differently between lit and unlit areas. The default value of ratio 0.9 means that lit intervals get more samples than unlit intervals. Note that the total number of intervals must exceed the number of illuminated intervals. If a ray passes in and out of 8 spotlights but you've only specified 5 intervals then an error occurs. The samples XE "samples"  Min, Max keyword specifies the minimum and maximum number of samples taken per interval. The default values are samples 1,1. As each interval is sampled, the variance is computed. If the variance is below a threshold value, then no more samples are needed. The variance XE "variance"  and confidence XE "confidence"  keywords specify the permitted variance allowed and the confidence that you are within that variance. The exact calculations are quite complex and involve chi-squared tests and other statistical principles too messy to describe here. The default values are varience 1.0/128 and confidence 0.9. For slower more accurate results, decrease the variance and increase the confidence. Note however that the maximum number of samples limits the calculations even if the proper variance and confidence are never reached. Density Particles of media are normally distributed in constant density throughout the media. However the density XE "density"  statement allows you to vary the density across space using any of POV-Ray's pattern functions such as those used in textures. If no density statement is given then the density remains a constant value of 1.0 throughout the media. More than one density may be specified per media statement. See " REF _Ref428014833 \h Multiple Density vs. Multiple Media". The syntax for density is: DENSITY: density { [DENSITY_IDENTIFIER] [DENSITY_TYPE] [DENSITY_MODIFIER...] } DENSITY_TYPE: PATTERN_TYPE | COLOR DENSITY_MODIFIER: PATTERN_MODIFIER | DENSITY_LIST | color_map{ COLOR_MAP_BODY } | colour_map{ COLOR_MAP_BODY } | density_map{ DENSITY_MAP_BODY } The density statement may begin with an optional density identifier. All subsequent values modify the defaults or the values in the identifier. The next item is a pattern type. This is any one of POV-Ray's pattern functions such as bozo XE "bozo" , wood XE "wood" , gradient XE "gradient" , waves XE "waves" , etc. Of particular usefulness are the spherical XE "spherical" , planar XE "planar" , cylindrical XE "cylindrical" , and boxed XE "boxed"  patterns which were previously available only for use with our discontinued halo XE "halo"  feature. All patterns return a value from 0.0 to 1.0. This value is interpreted as the density of the media at that particular point. See " REF _Ref420919899 \h Patterns" for details on particular pattern types. Although a solid COLOR pattern is legal, in general it is used only when the density statement is inside a density_map XE "density_map" . General Density Modifiers A density XE "density"  statement may be modified by any of the general pattern modifiers such as transformations, turbulence XE "turbulence"  and warp XE "warp" . See " REF _Ref420920063 \h Pattern Modifiers" for details. In addition there are several density-specific modifiers which can be used. Density with color_map Typically a media XE "media"  uses just one constant color throughout. Even if you vary the density, it is usually just one color which is specified by the absorption XE "absorption" , emission XE "emission" , or scattering XE "scattering"  keywords. However when using emission to simulate fire or explosions, the center of the flame (high density area) is typically brighter and white or yellow. The outer edge of the flame (less density) fades to orange, red, or in some cases deep blue. To model the density-dependent change in color which is visible, you may specify a color_map XE "color_map" . The pattern function returns a value from 0.0 to 1.0 and the value is passed to the color map to compute what color or blend of colors is used. See " REF _Ref420922745 \h Color Maps" for details on how pattern values work with color_map. This resulting color is multiplied by the absorption, emission and scattering color. Currently there is no way to specify different color maps for each media type within the same media statement. Consider this example: media{ emission 0.75 scattering {1, 0.5} density { spherical color_map{ [0.0 rgb <0,0,0.5>] [0.5 rgb <0.8, 0.8, 0.4>] [1.0 rgb <1,1,1>] } } } The color map ranges from white at density 1.0 to bright yellow at density 0.5 to deep blue at density 0. Assume we sample a point at density 0.5. The emission is 0.75*<0.8,0.8,0.4> or <0.6,0.6,0.3>. Similarly the scattering color is 0.5*<0.8,0.8,0.4> or <0.4,0.4,0.2>. For block pattern types checker XE "checker" , hexagon XE "hexagon" , and brick XE "brick"  you may specify a color list such as this: density{checker rgb<1,0,0>, rgb<0,0,0>} See " REF _Ref420923317 \h Color List Pigments" which describes how pigment uses a color list. The same principles apply when using them with density. Density Maps and Density Lists In addition to specifying blended colors with a color map you may create a blend of densities using a density_map XE "density_map" . The syntax for a density map is identical to a color map except you specify a density in each map entry (and not a color). The syntax for density_map is as follows: DENSITY_MAP: density_map{ DENSITY_MAP_BODY } DENSITY_MAP_BODY: DENSITY_MAP_IDENTIFIER | DENSITY_MAP_ENTRY... DENSITY_MAP_ENTRY: [ Value DENSITY_BODY ] Where Value is a float value between 0.0 and 1.0 inclusive and each DENSITY_BODY is anything which can be inside a density XE "density" {...} statement. The density keyword and {} braces need not be specified. Note that the [] brackets are part of the actual DENSITY_MAP_ENTRY. They are not notational symbols denoting optional parts. The brackets surround each entry in the density map. There may be from 2 to 256 entries in the map. Density maps may be nested to any level of complexity you desire. The densities in a map may have color maps or density maps or any type of density you want. Entire densities may also be used with the block patterns such as checker XE "checker" , hexagon XE "hexagon"  and brick XE "brick" . For example... density { checker density { Flame scale .8 } density { Fire scale .5 } } Note that in the case of block patterns the density wrapping is required around the density information. A density map is also used with the average XE "average"  density type. See " REF _Ref417371289 \h Average" for details. You may declare and use density map identifiers but the only way to declare a density block pattern list is to declare a density identifier for the entire density. Multiple Density vs. Multiple Media It is possible to have more than one media XE "media"  specified per object and it is legal to have more than one density XE "density"  per media. The effects are quite different. Consider this example: object{MyObject pigment{rgbf 1} interior{ media{ density{Some_Density} density{Another_Density} } } } As the media is sampled, calculations are performed for each density pattern at each sample point. The resulting samples are multiplied together. Suppose one density returned rgb<.8,.8,.4> and the other returned rgb<.25,.25,0>. The resulting color is rgb<.2,.2,0>. Note that in areas where one density returns zero, it will wipe out the other density. The end result is that only density areas which overlap will be visible. This is similar to a CSG intersection operation. Now consider object{MyObject pigment{rgbf 1} interior{ media{ density{Some_Density} } media{ density{Another_Density} } } } In this case each media is computed independently. The resulting colors are added together. Suppose one density and media returned rgb<.8,.8,.4> and the other returned rgb<.25,.25,0>. The resulting color is rgb<1.05,1.05,.4>. The end result is that density areas which overlap will be especially bright and all areas will be visible. This is similar to a CSG union operation. See the sample scene scenes/interior/media/media4.pov for an example which illustrates this. Atmospheric Effects Atmospheric effects are a loosely-knit group of features that affect the background and/or the atmosphere enclosing the scene. POV-Ray includes the ability to render a number of atmospheric effects, such as fog, haze, mist, rainbows and skies. Atmospheric Media Atmospheric effects such as fog, dust, haze, or visible gas may be simulated by a media XE "media"  statement specified in the scene but not attached to any object. All areas not inside a non-hollow object in the entire scene. A very simple approach to add fog to a scene is explained in section " REF _Ref421003334 \h Fog" however this kind of fog does not interact with any light sources like media does. It will not show light beams or other effects and is therefore not very realistic. The atmosphere media effect overcomes some of the fog's limitations by calculating the interaction between light and the particles in the atmosphere using volume sampling. Thus shaft of light beams will become visible and objects will cast shadows onto smoke or fog. With spotlights you'll be able to create the best results because their cone of light will become visible. Pointlights can be used to create effects like street lights in fog. Lights can be made to not interact with the atmosphere by adding media_interaction XE "media_interaction"  off to the light source. They can be used to increase the overall light level of the scene to make it look more realistic. Complete details on media are given in the section " REF _Ref413750547 \h Media". Earlier versions of POV-Ray used an atmosphere XE "atmosphere"  statement for atmospheric effects but that system was incompatible with the old object halo XE "halo"  system. So atmosphere has been eliminated and replaced with a simpler and more powerful media feature. The user now only has to learn one media system for either atmospheric or object use. If you only want media effects in a particular area, you should use object media rather than only relying upon the media pattern. In general it will be faster and more accurate because it only calculates inside the constraining object. You should note that the atmosphere feature will not work if the camera is inside a non-hollow object (see section " REF _Ref421004161 \h Empty and Solid Objects" for a detailed explanation). Background A background color can be specified if desired. Any ray that doesn't hit an object will be colored with this color. The default background is black. The syntax for background XE "background"  is: BACKGROUND: background {COLOR} Fog If it is not necessary for light beams to interact with atmospheric media, then fog XE "fog"  may be a faster way to simulate haze or fog. This feature artificially adds color to every pixel based on the distance the ray has traveled. The syntax for fog is: FOG: fog { [FOG_IDENTIFIER] [FOG_ITEMS...] } FOG_ITEMS: fog_type Fog_Type | distance Distance | COLOR | turbulence | turb_depth Turb_Depth | omega Omega | lambda Lambda | octaves Octaves | fog_offset Fog_Offset | fog_alt Fog_Alt | up | TRANSFORMATION Currently there are two fog types, the default fog_type XE "fog_type"  1 is a constant fog and fog_type 2 is ground fog. The constant fog has a constant density everywhere while the ground fog has a constant density for all heights below a given point on the up axis and thins out along this axis. The color of a pixel with an intersection depth d is calculated by PIXEL_COLOR = exp(-d/D) * OBJECT_COLOR + (1-exp(-d/D)) * FOG_COLOR where D is the specified value of the required fog distance XE "distance"  keyword. At depth 0 the final color is the object's color. If the intersection depth equals the fog distance the final color consists of 64% of the object's color and 36% of the fog's color. For ground fog, the height below which the fog has constant density is specified by the fog_offset XE "fog_offset"  keyword. The fog_alt XE "fog_alt"  keyword is used to specify the rate by which the fog fades away. The default values for both are 0.0 so be sure to specify them if ground fog is used. At an altitude of Fog_Offset+Fog_Alt the fog has a density of 25%. The density of the fog at height less than or equal to Fog_Alt is 1.0 and for height y less than Fog_Alt is calculated by 1/(1 + (y - Fog_Offset) / Fog_Alt) ^2) The total density along a ray is calculated by integrating from the height of the starting point to the height of the end point. The optional up XE "up"  vector specifies a direction pointing up, generally the same as the camera's up vector. All calculations done during the ground fog evaluation are done relative to this up vector, i. e. the actual heights are calculated along this vector. The up vector can also be modified using any of the known transformations described in " REF _Ref421693483 \h Transformations". Though it may not be a good idea to scale the up vector - the results are hardly predictable - it is quite useful to be able to rotate it. You should also note that translations do not affect the up direction (and thus don't affect the fog). The required fog color has three purposes. First it defines the color to be used in blending the fog and the background. Second it is used to specify a translucency threshold. By using a transmittance larger than zero one can make sure that at least that amount of light will be seen through the fog. With a transmittance of 0.3 you'll see at least 30% of the background. Third it can be used to make a filtering fog. With a filter value larger than zero the amount of background light given by the filter value will be multiplied with the fog color. A filter value of 0.7 will lead to a fog that filters 70% of the background light and leaves 30% unfiltered. Fogs may be layered. That is, you can apply as many layers of fog as you like. Generally this is most effective if each layer is a ground fog of different color, altitude and with different turbulence values. To use multiple layers of fogs, just add all of them to the scene. You may optionally stir up the fog by adding turbulence. The turbulence XE "turbulence"  keyword may be followed by a float or vector to specify an amount of turbulence to be used. The omega XE "omega" , lambda XE "lambda"  and octaves XE "octaves"  turbulence parameters may also be specified. See section " REF _Ref421693822 \h Pattern Modifiers" for details on all of these turbulence parameters. Additionally the fog turbulence may be scaled along the direction of the viewing ray using the turb_depth XE "turb_depth"  amount. Typical values are from 0.0 to 1.0 or more. The default value is 0.5 but any float value may be used. You should note that the fog feature will not work if the camera is inside a non-hollow object (see section " REF _Ref421693928 \h Empty and Solid Objects" for a detailed explanation). Sky Sphere The sky sphere is used create a realistic sky background without the need of an additional sphere to simulate the sky. Its syntax is: SKY_SPHERE: sky_sphere { [SKY_SPHERE_IDENTIFIER] [SKY_SPHERE_ITEMS...] } SKY_SPHERE_ITEM: PIGMENT | TRANSFORMATION The sky sphere can contain several pigment layers with the last pigment being at the top, i. e. it is evaluated last, and the first pigment being at the bottom, i. e. it is evaluated first. If the upper layers contain filtering and/or transmitting components lower layers will shine through. If not lower layers will be invisible. The sky sphere is calculated by using the direction vector as the parameter for evaluating the pigment patterns. This leads to results independent from the view point which pretty good models a real sky where the distance to the sky is much larger than the distances between visible objects. If you want to add a nice color blend to your background you can easily do this by using the following example. sky_sphere { pigment { gradient y color_map { [ 0.5 color CornflowerBlue ] [ 1.0 color MidnightBlue ] } scale 2 translate -1 } } This gives a soft blend from CornflowerBlue at the horizon to MidnightBlue at the zenith. The scale and translate operations are used to map the direction vector values, which lie in the range from <-1, -1, -1> to <1, 1, 1>, onto the range from <0, 0, 0> to <1, 1, 1>. Thus a repetition of the color blend is avoided for parts of the sky below the horizon. In order to easily animate a sky sphere you can transform it using the usual transformations described in " REF _Ref421694648 \h Transformations". Though it may not be a good idea to translate or scale a sky sphere - the results are hardly predictable - it is quite useful to be able to rotate it. In an animation the color blendings of the sky can be made to follow the rising sun for example. You should note that only one sky sphere can be used in any scene. It also will not work as you might expect if you use camera types like the orthographic or cylindrical camera. The orthographic camera uses parallel rays and thus you'll only see a very small part of the sky sphere (you'll get one color skies in most cases). Reflections in curved surface will work though, e. g. you will clearly see the sky in a mirrored ball. Rainbow Rainbows are implemented using fog-like, circular arcs. Their syntax is: RAINBOW: rainbow { [RAINBOW_IDENTIFIER] [RAINBOW_ITEMS...] } RAINBOW_ITEM: direction | angle Angle | width Width | distance Distance | COLOR_MAP | jitter Jitter | up | arc_angle Arc_Angle | falloff_angle Falloff_Angle The required direction XE "direction"  vector determines the direction of the (virtual) light that is responsible for the rainbow. Ideally this is an infinitely far away light source like the sun that emits parallel light rays. The position and size of the rainbow are specified by the required angle XE "angle"  and width XE "width"  keywords. To understand how they work you should first know how the rainbow is calculated. For each ray the angle between the rainbow's direction vector and the ray's direction vector is calculated. If this angle lies in the interval from Angle-Width/2 to Angle+Width/2 the rainbow is hit by the ray. The color is then determined by using the angle as an index into the rainbow's color_map. After the color has been determined it will be mixed with the background color in the same way like it is done for fogs. Thus the angle and width parameters determine the angles under which the rainbow will be seen. The optional jitter XE "jitter"  keyword can be used to add random noise to the index. This adds some irregularity to the rainbow that makes it look more realistic. The required distance XE "distance"  keyword is the same like the one used with fogs. Since the rainbow is a fog-like effect it's possible that the rainbow is noticeable on objects. If this effect is not wanted it can be avoided by using a large distance value. By default a sufficiently large value is used to make sure that this effect does not occur. The color_map XE "color_map"  statement is used to assign a color map that will be mapped onto the rainbow. To be able to create realistic rainbows it is important to know that the index into the color map increases with the angle between the ray's and rainbow's direction vector. The index is zero at the innermost ring and one at the outermost ring. The filter and transmittance values of the colors in the color map have the same meaning as the ones used with fogs (see section " REF _Ref421696014 \h Fog"). The default rainbow is a 360 degree arc that looks like a circle. This is no problem as long as you have a ground plane that hides the lower, non-visible part of the rainbow. If this isn't the case or if you don't want the full arc to be visible you can use the optional keywords up XE "up" , arc_angle XE "arc_angle"  and falloff_angle XE "falloff_angle"  to specify a smaller arc. The arc_angle keyword determines the size of the arc in degrees (from 0 to 360 degrees). A value smaller than 360 degrees results in an arc that abruptly vanishes. Since this doesn't look nice you can use the falloff_angle keyword to specify a region in which the rainbow will smoothly blend into the background making it vanish softly. The falloff angle has to be smaller or equal to the arc angle. The up keyword determines were the zero angle position is. By changing this vector you can rotate the rainbow about its direction. You should note that the arc goes from -Arc_Angle/2 to +Arc_Angle/2. The soft regions go from -Arc_Angle/2 to -Falloff_Angle/2 and from +Falloff_Angle/2 to +Arc_Angle/2. The following example generates a 120 degrees rainbow arc that has a falloff region of 30 degrees at both ends: rainbow { direction <0, 0, 1> angle 42.5 width 5 distance 1000 jitter 0.01 color_map { Rainbow_Color_Map } up <0, 1, 0> arc_angle 120 falloff_angle 30 } It is possible to use any number of rainbows and to combine them with other atmospheric effects. Global Settings The global_settings XE "global_settings"  statement is a catch-all statement that gathers together a number of global parameters. The statement may appear anywhere in a scene as long as it is not inside any other statement. You may have multiple global_settings statements in a scene. Whatever values were specified in the last global_settings statement override any previous settings. Regardless of where you specify the statement, the feature applies to the entire scene. Note that some items which were language directives in earlier versions of POV-Ray have been moved inside the global_settings statement so that it is more obvious to the user that their effect is global. The old syntax is permitted but generates a warning. The new syntax is: GLOBAL_SETTINGS: global_settings { [GLOBAL_SETTINGS_ITEMS...] } GLOBAL_SETTINGS_ITEM: adc_bailout Value | ambient_light COLOR | assumed_gamma Value | hf_gray_16 [Bool} | irid_wavelength COLOR | max_intersections Number | max_trace_level Number | number_of_waves Number | radiosity { RADIOSITY_ITEMS... } Each item is optional and may appear in and order. If an item is specified more than once, the last setting overrides previous values. Details on each item are given in the following sections. ADC_Bailout In scenes with many reflective and transparent surfaces, POV-Ray can get bogged down tracing multiple reflections and refractions that contribute very little to the color of a particular pixel. The program uses a system called Adaptive Depth Control (ADC) to stop computing additional reflected or refracted rays when their contribution is insignificant. You may use the global setting adc_bailout XE "adc_bailout"  keyword followed by float value to specify the point at which a ray's contribution is considered insignificant. For example: global_settings { adc_bailout 0.01 } The default value is 1/255, or approximately 0.0039, since a change smaller than that could not be visible in a 24 bit image. Generally this setting is perfectly adequate and should be left alone. Setting adc_bailout to 0 will disable ADC, relying completely on max_trace_level XE "max_trace_level"  to set an upper limit on the number of rays spawned. See section " REF _Ref422128058 \h Max_Trace_Level" for details on how ADC and max_trace_level interact. Ambient Light Ambient light is used to simulate the effect of inter-diffuse reflection that is responsible for lighting areas that partially or completely lie in shadow. POV-Ray provides the ambient_light XE "ambient_light"  keyword to let you easily change the brightness of the ambient lighting without changing every ambient value in all finish statements. It also lets you create interesting effects by changing the color of the ambient light source. The syntax is: global_settings { ambient_light COLOR } The default is a white ambient light source set at rgb <1,1,1>. Only the rgb components are used. The actual ambient used is: Ambient = Finish_Ambient * Global_Ambient. See section " REF _Ref422128412 \h Ambient" for more information. Assumed_Gamma Many people may have noticed at one time or another that some images are too bright or dim when displayed on their system. As a rule, Macintosh users find that images created on a PC are too bright, while PC users find that images created on a Macintosh are too dim. The assumed_gamma XE "assumed_gamma"  global setting works in conjunction with the Display_Gamma XE "Display_Gamma"  INI setting (see section " REF _Ref412464789 \h Display Hardware Settings") to ensure that scene files render the same way across the wide variety of hardware platforms that POV-Ray is used on. The assumed gamma setting is used in a scene file by adding global_settings { assumed_gamma Value } where the assumed gamma value is the correction factor to be applied before the pixels are displayed and/or saved to disk. For scenes created in older versions of POV-Ray, the assumed gamma value will be the same as the display gamma value of the system the scene was created on. For PC systems, the most common display gamma is 2.2, while for scenes created on Macintosh systems should use a scene gamma of 1.8. Another gamma value that sometimes occurs in scenes is 1.0. Scenes that do not have an assumed_gamma global setting will not have any gamma correction performed on them, for compatibility reasons. If you are creating new scenes or rendering old scenes, it is strongly recommended that you put in an appropriate assumed_gamma global setting. For new scenes, you should use an assumed gamma value of 1.0 as this models how light appears in the real world more realistically. The following sections explain more thoroughly what gamma is and why it is important. Monitor Gamma The differences in how images are displayed is a result of how a computer actually takes an image and displays it on the monitor. In the process of rendering an image and displaying it on the screen, several gamma values are important, including the POV scene file or image file gamma and the monitor gamma. Most image files generated by POV-Ray store numbers in the range from 0 to 255 for each of the red, green and blue components of a pixel. These numbers represent the intensity of each color component, with 0 being black and 255 being the brightest color (either 100% red, 100% green or 100% blue). When an image is displayed, the graphics card converts each color component into a voltage which is sent to the monitor to light up the red, green and blue phosphors on the screen. The voltage is usually proportional to the value of each color component. Gamma becomes important when displaying intensities that aren't the maximum or minimum possible values. For example, 127 should represent 50% of the maximum intensity for pixels stored as numbers between 0 and 255. On systems that don't do gamma correction, 127 will be converted to 50% of the maximum voltage, but because of the way the phosphors and the electron guns in a monitor work, this may be only 22% of the maximum color intensity on a monitor with a gamma of 2.2. To display a pixel which is 50% of the maximum intensity on this monitor, we would need a voltage of 73% of the maximum voltage, which translates to storing a pixel value of 186. The relationship between the input pixel value and the displayed intensity can be approximated by an exponential function obright = ibright ^ display_gamma where obright is the output intensity and ibright is the input pixel intensity. Both values are in the range from 0 to 1 (0% to 100%). Most monitors have a fixed gamma value in the range from 1.8 to 2.6. Using the above formula with display_gamma values greater than 1 means that the output brightness will be less than the input brightness. In order to have the output and input brightness be equal an overall system gamma of 1 is needed. To do this, we need to gamma correct the input brightness in the same manner as above but with a gamma value of 1/display_gamma before it is sent to the monitor. To correct for a display gamma of 2.2, this pre-monitor gamma correction uses a gamma value of 1.0/2.2 or approximately 0.45. How the pre-monitor gamma correction is done depends on what hardware and software is being used. On Macintosh systems, the operating system has taken it upon itself to insulate applications from the differences in display hardware. Through a gamma control panel the user may be able to set the actual monitor gamma and Mac will then convert all pixel intensities so that the monitor will appear to have the specified gamma value. On Silicon Graphics machines, the display adapter has built-in gamma correction calibrated to the monitor which gives the desired overall gamma (the default is 1.7). Unfortunately, on PCs and most UNIX systems, it is up to the application to do any gamma correction needed. Image File Gamma Since most PC and UNIX applications and image file formats don't understand display gamma, they don't do anything to correct for it. As a result, users creating images on these systems adjust the image in such a way that it has the correct brightness when displayed. This means that the data values stored in the files are made brighter to compensate for the darkening effect of the monitor. In essence, the 0.45 gamma correction is built in to the image files created and stored on these systems. When these files are displayed on a Macintosh system, the gamma correction built in to the file, in addition to gamma correction built into MacOS, means that the image will be too bright. Similarly, files that look correct on Macintosh or SGI systems because of the built-in gamma correction will be too dark when displayed on a PC. The new PNG format files generated by POV-Ray 3.0 overcome the problem of too much or not enough gamma correction by storing the image file gamma (which is 1.0/display_gamma) inside the PNG file when it is generated by POV-Ray. When the PNG file is later displayed by a program that has been set up correctly, it uses this gamma value as well as the current display gamma to correct for the potentially different display gamma used when originally creating the image. Unfortunately, of all the image file formats POV-Ray supports, PNG is the only one that has any gamma correction features and is therefore preferred for images that will be displayed on a wide variety of platforms. Scene File Gamma The image file gamma problem itself is just a result of how scenes themselves are generated in POV-Ray. When you start out with a new scene and are placing light sources and adjusting surface textures and colors, you generally make several attempts before the lighting is how you like it. How you choose these settings depends upon the preview image or the image file stored to disk, which in turn is dependent upon the overall gamma of the display hardware being used. This means that as the artist you are doing gamma correction in the POV-Ray scene file for your particular hardware. This scene file will generate an image file that is also gamma corrected for your hardware and will display correctly on systems similar to your own. However, when this scene is rendered on another platform, it may be too bright or too dim, regardless of the output file format used. Rather than have you change all the scene files to have a single fixed gamma value (heaven forbid!), POV-Ray 3.0 allows you to specify in the scene file the display gamma of the system that the scene was created on. The assumed_gamma XE "assumed_gamma"  global setting, in conjunction with the Display_Gamma XE "Display_Gamma"  INI setting lets POV-Ray know how to do gamma correction on a given scene so that the preview and output image files will appear the correct brightness on any system. Since the gamma correction is done internally to POV-Ray, it will produce output image files that are the correct brightness for the current display, regardless of what output format is used. As well, since the gamma correction is performed in the high-precision data format that POV-Ray uses internally, it produces better results than gamma correction done after the file is written to disk. Although you may not notice any difference in the output on your system with and without an assumed_gamma setting, the assumed gamma is important if the scene is ever rendered on another platform. HF_Gray_16 The hf_gray_16 XE "hf_gray_16"  setting is useful when using POV-Ray to generate heightfields for use in other POV-Ray scenes. The syntax is... global_settings { hf_gray_16 [Bool] } The boolean value turns the option on or off. If the keyword is specified without the boolean value then the option is turned on. If hf_gray_16 is not specified in any global_settings statement in the entire scene then the default is off. When hf_gray_16 is on, the output file will be in the form of a heightfield, with the height at any point being dependent on the brightness of the pixel. The brightness of a pixel is calculated in the same way that color images are converted to grayscale images: height = 0.3 * red + 0.59 * green + 0.11 * blue. Setting the hf_gray_16 option will cause the preview display, if used, to be grayscale rather than color. This is to allow you to see how the heightfield will look because some file formats store heightfields in a way that is difficult to understand afterwards. See section " REF _Ref414188528 \h Height Field" for a description of how POV-Ray heightfields are stored for each file type. Irid_Wavelength Iridescence calculations depend upon the dominant wavelengths of the primary colors of red, green and blue light. You may adjust the values using the global setting irid_wavelength XE "irid_wavelength"  as follows... global_settings { irid_wavelength COLOR } The default value is rgb <0.25,0.18,0.14> and any filter or transmit values are ignored. These values are proportional to the wavelength of light but they represent no real world units. In general, the default values should prove adequate but we provide this option as a means to experiment with other values. Max_Trace_Level In scenes with many reflective and transparent surfaces POV-Ray can get bogged down tracing multiple reflections and refractions that contribute very little to the color of a particular pixel. The global setting max_trace_level XE "max_trace_level"  defines the integer maximum number of recursive levels that POV-Ray will trace a ray. global_settings { max_trace_level Level } This is used when a ray is reflected or is passing through a transparent object and when shadow rays are cast. When a ray hits a reflective surface, it spawns another ray to see what that point reflects. That is trace level one. If it hits another reflective surface another ray is spawned and it goes to trace level two. The maximum level by default is five. One speed enhancement added to POV-Ray in version 3.0 is Adaptive Depth Control (ADC). Each time a new ray is spawned as a result of reflection or refraction its contribution to the overall color of the pixel is reduced by the amount of reflection or the filter value of the refractive surface. At some point this contribution can be considered to be insignificant and there is no point in tracing any more rays. Adaptive depth control is what tracks this contribution and makes the decision of when to bail out. On scenes that use a lot of partially reflective or refractive surfaces this can result in a considerable reduction in the number of rays fired and makes it safer to use much higher max_trace_level values. This reduction in color contribution is a result of scaling by the reflection amount and/or the filter values of each surface, so a perfect mirror or perfectly clear surface will not be optimizable by ADC. You can see the results of ADC by watching the Rays Saved and Highest Trace Level displays on the statistics screen. The point at which a ray's contribution is considered insignificant is controlled by the adc_bailout XE "adc_bailout"  value. The default is 1/255 or approximately 0.0039 since a change smaller than that could not be visible in a 24 bit image. Generally this setting is perfectly adequate and should be left alone. Setting adc_bailout to 0 will disable ADC, relying completely on max_trace_level to set an upper limit on the number of rays spawned. If max_trace_level is reached before a non-reflecting surface is found and if ADC hasn't allowed an early exit from the ray tree the color is returned as black. Raise max_trace_level if you see black areas in a reflective surface where there should be a color. The other symptom you could see is with transparent objects. For instance, try making a union of concentric spheres with a clear texture on them. Make ten of them in the union with radius's from 1 to 10 and render the scene. The image will show the first few spheres correctly, then black. This is because a new level is used every time you pass through a transparent surface. Raise max_trace_level to fix this problem. Note that raising max_trace_level will use more memory and time and it could cause the program to crash with a stack overflow error, although ADC will alleviate this to a large extent. Values for max_trace_level are not restricted, so it can be set to any number as long as you have the time and memory. However, increasing its setting does not necessarily equate to increased image quality unless such depths are really needed by the scene. Max_Intersections POV-Ray uses a set of internal stacks to collect ray/object intersection points. The usual maximum number of entries in these I-Stacks is 64. Complex scenes may cause these stacks to overflow. POV-Ray doesn't stop but it may incorrectly render your scene. When POV-Ray finishes rendering, a number of statistics are displayed. If you see I-Stack Overflows reported in the statistics you should increase the stack size. Add a global setting to your scene as follows: global_settings { max_intersections Integer } If the I-Stack Overflows remain increase this value until they stop. Number_Of_Waves The waves XE "waves"  and ripples XE "ripples"  pattern are generated by summing a series of waves, each with a slightly different center and size. By default, ten waves are summed but this amount can be globally controlled by changing the number_of_waves XE "number_of_waves"  setting. global_settings { number_of_waves Integer } Changing this value affects both waves and ripples alike on all patterns in the scene. Radiosity Important notice: The radiosity features in POV-Ray are somewhat experimental. There is a high probability that the design and implementation of these features will be changed in future versions. We cannot guarantee that scenes using these features in this version will render identically in future releases or that full backwards compatibility of language syntax can be maintained. Radiosity is an extra calculation that more realistically computes the diffuse interreflection of light. This diffuse interreflection can be seen if you place a white chair in a room full of blue carpet, blue walls and blue curtains. The chair will pick up a blue tint from light reflecting off of other parts of the room. Also notice that the shadowed areas of your surroundings are not totally dark even if no light source shines directly on the surface. Diffuse light reflecting off of other objects fills in the shadows. Typically ray-tracing uses a trick called ambient light to simulate such effects but it is not very accurate. Radiosity is more accurate than simplistic ambient light but it takes much longer to compute. For this reason, POV-Ray does not use radiosity by default. Radiosity is turned on using the Radiosity XE "Radiosity"  INI file option or the +QR XE "+QR"  command line switch. The following sections describes how radiosity works, how to control it with various global settings and tips on trading quality vs. speed. How Radiosity Works The problem of ray-tracing is to figure out what the light level is at each point that you can see in a scene. Traditionally, in ray tracing, this is broken into the sum of these components: - Diffuse, the effect that makes the side of things facing the light brighter; - Specular, the effect that makes shiny things have dings or sparkles on them; - Reflection, the effect that mirrors give; and - Ambient, the general all-over light level that any scene has, which keeps things in shadow from being pure black. POV-Ray's radiosity system, based on a method by Greg Ward, provides a way to replace the last term - the constant ambient light value - with a light level which is based on what surfaces are nearby and how bright in turn they are. The first thing you might notice about this definition is that it is circular: the light of everything is dependent on everything else and vice versa. This is true in real life but in the world of ray-tracing, we can make an approximation. The approximation that is used is: the objects you are looking at have their ambient XE "ambient"  values calculated for you by checking the other objects nearby. When those objects are checked during this process, however, a traditional constant ambient term is used. How does POV-Ray calculate the ambient term for each point? By sending out more rays, in many different directions, and averaging the results. A typical point might use 200 or more rays to calculate its ambient light level correctly. Now this sounds like it would make the ray-tracer 200 times slower. This is true, except that the software takes advantage of the fact that ambient light levels change quite slowly (remember, shadows are calculated separately, so sharp shadow edges are not a problem). Therefore, these extra rays are sent out only once in a while (about 1 time in 50), then these calculated values are saved and reused for nearby pixels in the image when possible. This process of saving and reusing values is what causes the need for a variety of tuning parameters, so you can get the scene to look just the way you want. Adjusting Radiosity As described earlier, radiosity is turned on by using the Radiosity XE "Radiosity"  INI file option or the +QR XE "+QR"  command line switch. However radiosity has many parameters that are specified in a radiosity XE "radiosity"  statement inside a global_settings XE "global_settings"  statement as follows: global_settings { radiosity { [RADIOSITY_ITEMS...] }} RADIOSITY_ITEMS: brightness Float | count Integer | distance_maximum Float | error_bound Float | gray_threshold Float | low_error_factor Float | minimum_reuse Float | nearest_count Integer | recursion_limit Integer Each item is optional and may appear in and order. If an item is specified more than once the last setting overrides previous values. Details on each item is given in the following sections. brightness This brightness XE "brightness"  keyword specifies a float value that is the degree to which ambient values are brightened before being returned upwards to the rest of the system. If an object is red rgb<1,0 0>, with an ambient value of 0.3, in normal situations a red component of 0.3 will be added in. With radiosity on, assume it was surrounded by an object of gray color rgb<0.6,0.6,0.6>. The average color returned by the gathering process will be the same. This will be multiplied by the texture's ambient weight value of 0.3, returning rgb<0.18,0.18,0.18>. This is much darker than the 0.3 which would be added in normally. Therefore, all returned values are brightened by the inverse of the average of the calculated values, so the average ambient added in does not change. Some will be higher than specified (higher than 0.3 in this example) and some will be lower but the overall scene brightness will be unchanged. The default value is 3.3. count The integer number of rays that are sent out whenever a new radiosity value has to be calculated is given by count XE "count" . Values of 100 to 150 make most scenes look good. Higher values might be needed for scenes with high contrast between light levels or small patches of light causing the illumination. This would be used only for a final rendering on an image because it is very compute intensive. Since most scenes calculate the ambient value at 1% to 2% of pixels, as a rough estimate, your rendering will take 1% to 2% of this number times as long. If you set it to 300 your rendering might take 3 to 6 times as long to complete (1% to 2% times 300). When this value is too low, the light level will tend to look a little bit blotchy, as if the surfaces you're looking at were slightly warped. If this is not important to your scene (as in the case that you have a bump map or if you have a strong texture) then by all means use a lower number. The default value is 100. distance_maximum The distance_maximum XE "distance_maximum"  float value is the only tuning value that depends upon the size of the objects in the scene. This one must be set for scenes to render properly... the rest can be ignored for a first try. It is difficult to describe the meaning simply but it sets the distance in model units from a sample at which the error is guaranteed to hit 100% (radiosity_error_bound >=1): no samples are reused at a distance larger than this from their original calculation point. Imagine an apple at the left edge of a table. The goal is to make sure that samples on the surface of the table at the right are not used too close to the apple and definitely not underneath the apple. If you had enough rays there wouldn't be a problem since one of them would be guaranteed to hit the apple and set the reuse radius properly for you. In practice, you must limit this. We use this technique: find the object in your scene which might have the following problem: a small object on a larger flatter surface that you want good ambient light near. Now, how far from this would you have to get to be sure that one of your rays had a good chance of hitting it? In the apple-on-the-table example, assuming I used one POV-Ray unit as one inch, I might use 30 inches. A theoretically sound way (when you are running lots of rays) is the distance at which this object's top is 5 degrees above the horizon of the sample point you are considering. This corresponds to about 11 times the height of the object. So, for a 3-inch apple, 33 inches makes some sense. For good behavior under and around a 1/3 inch pea, use 3 inches etc. Another VERY rough estimate is one third the distance from your eye position to the point you are looking at. The reasoning is that you are probably no more than 90 inches from the apple on the table, if you care about the shading underneath it. The default value is 0. error_bound The error_bound XE "error_bound"  float value is one of the two main speed/quality tuning values (the other is of course the number of rays shot). In an ideal world, this would be the only value needed. It is intended to mean the fraction of error tolerated. For example, if it were set to 1 the algorithm would not calculate a new value until the error on the last one was estimated at as high as 100%. Ignoring the error introduced by rotation for the moment, on flat surfaces this is equal to the fraction of the reuse distance, which in turn is the distance to the closest item hit. If you have an old sample on the floor 10 inches from a wall, an error bound of 0.5 will get you a new sample at a distance of about 5 inches from the wall. 0.5 is a little rough and ready, 0.33 is good for final renderings. Values much lower than 0.3 take forever. The default value is 0.4. gray_threshold Diffusely interreflected light is a function of the objects around the point in question. Since this is recursively defined to millions of levels of recursion, in any real life scene, every point is illuminated at least in part by every other part of the scene. Since we can't afford to compute this, we only do one bounce and the calculated ambient light is very strongly affected by the colors of the objects near it. This is known as color bleed and it really happens but not as much as this calculation method would have you believe. The gray_threshold XE "gray_threshold"  float value grays it down a little, to make your scene more believable. A value of .6 means to calculate the ambient value as 60% of the equivalent gray value calculated, plus 40% of the actual value calculated. At 0%, this feature does nothing. At 100%, you always get white/gray ambient light, with no hue. Note that this does not change the lightness/darkness, only the strength of hue/grayness (in HLS terms, it changes S only). The default value is 0.5 low_error_factor If you calculate just enough samples, but no more, you will get an image which has slightly blotchy lighting. What you want is just a few extra interspersed, so that the blending will be nice and smooth. The solution to this is the mosaic preview: it goes over the image one or more times beforehand, calculating radiosity values. To ensure that you get a few extra, the radiosity algorithm lowers the error bound during the pre-final passes, then sets it back just before the final pass. The low_error_factor XE "low_error_factor"  is a float tuning value which sets the amount that the error bound is dropped during the preliminary image passes. If your low error factor is 0.8 and your error bound is set to 0.4 it will really use an error bound of 0.32 during the first passes and 0.4 on the final pass. The default value is 0.8. minimum_reuse The minimum effective radius ratio is set by minimum_reuse XE "minimum_reuse"  float value. This is the fraction of the screen width which sets the minimum radius of reuse for each sample point (actually, it is the fraction of the distance from the eye but the two are roughly equal). For example, if the value is 0.02 the radius of maximum reuse for every sample is set to whatever ground distance corresponds to 2% of the width of the screen. Imagine you sent a ray off to the horizon and it hits the ground at a distance of 100 miles from your eye point. The reuse distance for that sample will be set to 2 miles. At a resolution of 300*400 this will correspond to (very roughly) 8 pixels. The theory is that you don't want to calculate values for every pixel into every crevice everywhere in the scene, it will take too long. This sets a minimum bound for the reuse. If this value is too low, (which it should be in theory) rendering gets slow, and inside corners can get a little grainy. If it is set too high, you don't get the natural darkening of illumination near inside edges, since it reuses. At values higher than 2% you start getting more just plain errors, like reusing the illumination of the open table underneath the apple. Remember that this is a unitless ratio. The default value is 0.015. nearest_count The nearest_count XE "nearest_count"  integer value is the maximum number of old ambient values blended together to create a new interpolated value. It will always be the n geometrically closest reusable points that get used. If you go lower than 4, things can get pretty patchy. This can be good for debugging, though. Must be no more than 10, since that is the size of the array allocated. The default value is 6. recursion_limit The recursion_limit XE "recursion_limit"  is an integer value which determines how many recursion levels are used to calculate the diffuse inter-reflection. Valid values are one and two. The default value is 1. Tips on Radiosity If you want to see where your values are being calculated set radiosity count XE "count"  down to about 20, set radiosity nearest_count XE "nearest_count"  to 1 and set gray_threshold XE "gray_threshold"  to 0. This will make everything maximally patchy, so you'll be able to see the borders between patches. There will have been a radiosity calculation at the center of most patches. As a bonus, this is quick to run. You can then change the error_bound XE "error_bound"  up and down to see how it changes things. Likewise modify minimum_reuse XE "minimum_reuse"  and distance_maximum XE "distance_maximum" . One way to get extra smooth results: crank up the sample count (we've gone as high as 1300) and drop the low_error_factor XE "low_error_factor"  to something small like 0.6. Bump up the nearest_count XE "nearest_count"  to 7 or 8. This will get better values, and more of them, then interpolate among more of them on the last pass. This is not for people with a lack of patience since it is like a squared function. If your blotchiness is only in certain corners or near certain objects try tuning the error bound instead. Never drop it by more than a little at a time, since the run time will get very long. If your scene looks good but right near some objects you get spots of the right (usually darker) color showing on a flat surface of the wrong color (same as far away from the object), then try dropping distance_maximum. If that still doesn't work well increase your ray count by 100 and drop the error bound just a bit. If you still have problems, drop nearest_count to about 4. APPENDICES Copyright, Legal Information and License -- POVLEGAL.DOC The following sections contain the legal information and license for the Persistence of Vision"! Ray-Tracer, also called POV-Ray"!. Before you use this program you have to read the sections below. General License Agreement -- POVLEGAL.DOC Revised May 1999. THIS NOTICE MUST ACCOMPANY ALL OFFICIAL OR CUSTOM PERSISTENCE OF VISION FILES. IT MAY NOT BE REMOVED OR MODIFIED. THIS INFORMATION PERTAINS TO ALL USE OF THE PACKAGE WORLDWIDE. THIS DOCUMENT SUPERSEDES ALL PREVIOUS GENERAL LICENSES OR DISTRIBUTION POLICIES. ANY INDIVIDUALS, COMPANIES OR GROUPS WHO HAVE BEEN GRANTED SPECIAL LICENSES MAY CONTINUE TO DISTRIBUTE VERSION 2.x BUT MUST RE-APPLY FOR VERSION 3.00 OR LATER. This document pertains to the use and distribution of the Persistence of Vision"! Ray Tracer a.k.a POV-Ray"!. It applies to all POV-Ray program source files, executable (binary) files, scene files, documentation files, help file, bitmaps and INI files contained in official POV-Ray Team"! archives. All of these are referred to here as "the software". The POV-Team reserves the right to revise these rules in future versions and to make additional rules to address new circumstances at any time. All of this software is Copyright 1991,1999 by the POV-Ray Team"!. Although it is distributed as freeware, it is NOT PUBLIC DOMAIN. The copyrighted package may ONLY be distributed and/or modified according to the license granted herein. The spirit of the license is to promote POV-Ray as a standard ray tracer, provide the full POV-Ray package freely to as many users as possible, prevent POV-Ray users and developers from being taken advantage of, enhance the life quality of those who come in contact with POV-Ray. This license was created so these goals could be realized. You are legally bound to follow these rules, but we hope you will follow them as a matter of ethics, rather than fear of litigation. Usage Provisions Permission is granted to the user to use the software and associated files in this package to create and render images. The use of this software for the purpose of creating images is completely free. The creator of a scene file and the image created from the scene file, retains all rights to the image and scene file they created and may use them for any purpose commercial or non-commercial. The user is also granted the right to use the scenes files, fonts, bitmaps, and include files distributed in the INCLUDE and SCENES\INCDEMO sub-directories in their own scenes. Such permission does not extend to files in the SCENES directory or its sub-directories. The SCENES files are for your enjoyment and education but may not be the basis of any derivative works. General Rules For All Distribution The permission to distribute this package under certain very specific conditions is granted in advance, provided that the following conditions are met. These archives must not be re-archived using a different method without the explicit permission of the POV-Team. You may rename the archives only to meet the file name conventions of your system or to avoid file name duplications but we ask that you try to keep file names as similar to the originals as possible. (For example: POVSRC.ZIP to POVSRC30.ZIP) Ready-to-run unarchived distribution on CD-ROM is also permitted if the files are arranged in our standard directory or folder structure as though it had been properly installed on a hard disk. You must distribute a FULL PACKAGE of files as described in the next section. No portion of this package may be separated from the package and distributed separately other than under the conditions specified in the provisions given below. Non-commercial distribution in which no money or compensation is charged (such as a user copying the software for a personal friend or colleague) is permitted with no other restrictions. Teachers and educational institutions may also distribute the material to students for free or they may charge minimal copying costs if the software is to be used in a course. Definition Of "Full Package" A "full package" contains an executable program, documentation, and sample scenes. For generic Unix platforms, there are no executables available so the portable C source code must be included instead of the executable program. POV-Ray is officially distributed for MS-Dos; Windows 95/98/NT; Linux for Intel x86 series; Apple Macintosh; Apple PowerPC; SunOS; and Amiga. Other systems may be added in the future. Distributors need not support all platforms but for each platform you support you must distribute a full package. For example a Macintosh only CD-ROM need not distribute the Windows versions. This software may ONLY be bundled with other software packages according to the conditions specified in the provisions below. Conditions For CD-ROM or Shareware/Freeware Distribution Shareware and freeware distribution companies may distribute the software included in software-only compilations using media such as, but not limited to, floppy disk, CD-ROM, tape backup, optical disks, hard disks, or memory cards. This section only applies to distributors of collected programs. Anyone wishing to bundle the package with a shareware product must use the commercial bundling rules. Distribution on CD-ROM or high capacity media such as backup tape is permitted if the total cost to the user is no more than $0.08 U.S. dollars per megabyte of data. For example a CD-ROM with 600 meg could cost no more than $48.00 US. Any bundling with books, magazines or other print media is permitted if the total cost of the book or magazine with CD is less than the $48.00 limit. Bundling with more expensive publications or distributions should also use the commercial rules. For floppy disk distribution, no more than five dollars U.S. ($5) can be charged per disk for the copying of this software and the media it is provided on. Space on each disk must be used as fully as possible. You may not spread the files over more disks than are necessary. Conditions For On-Line Services And Bbs's Including Internet On-line services, BBS's and internet sites may distribute the POV-Ray software under the conditions in this section. Sites which allow users to run POV-Ray from remote locations must use separate provisions in the section below. The archives must all be easily available on the service and should be grouped together in a similar on-line area. It is strongly requested that sites remove prior versions of POV-Ray to avoid user confusion and simplify or minimize our support efforts. The site may only charge standard usage rates for the downloading of this software. A premium may not be charged for this package. I.E. CompuServe or America On-Line may make these archives available to their users, but they may only charge regular usage rates for the time required to download. Online Or Remote Execution Of POV-Ray Some internet sites have been set up so that remote users can actually run POV-Ray software on the internet server. Other companies sell CPU time for running POV-Ray software on workstations or high-speed computers. Such use of POV-Ray software is permitted under the following conditions. Fees or charges, if any, for such services must be for connect time, storage or processor usage ONLY. No premium charges may be assessed for use of POV-Ray beyond that charged for use of other software. Users must be clearly notified that they are being charged for use of the computer and not for use of POV-Ray software. Users must be prominently informed that they are using POV-Ray software, that such software is free, and where they can find official POV-Ray software. Any attempt to obscure the fact that the user is running POV-Ray is expressly prohibited. All files normally available in a full package distribution, especially a copy of this license and full documentation must be available for download or readable online so that users of an online executable have access to all of the material of a full user package. If the POV-Ray software has been modified in any way, it must also follow the provisions for custom versions below. Permitted Modification And Custom Versions Although the full source code for POV-Ray is distributed, there are strict rules for the use of the source code. The source distribution is provided to; 1) promote the porting of POV-Ray to hardware and operating systems which the POV-Team cannot support. 2) promote experimentation and development of new features to the core code which might eventually be incorporated into the official version. 3) provide insight into the inner workings of the program for educational purposes. These license provisions have been established to promote the growth of POV-Ray and prevent difficulties for users and developers alike. Please follow them carefully for the benefit of all concerned when creating a custom version. The user is granted the privilege to modify and compile the source code for their own personal use in any fashion they see fit. What you do with the software in your own home is your business. However severe restrictions are imposed if the user wishes to distribute a modified version of the software, documentation or other parts of the package (here after referred to as a "custom version"). You must follow the provisions given below. This includes any translation of the documentation into other languages or other file formats. A "custom version" is defined as a fully functional version of POV-Ray with all existing features intact. ANY OTHER USE OF ANY POV-Ray SOURCE CODE IS EXPRESSLY PROHIBITED. The POV-Team does not license source code for any use outside POV-Ray. No portion of the POV-Ray source code may be incorporated into another program unless it is clearly a custom version of POV-Ray that includes all of the basic functions of POV-Ray. All executables, documentation, modified files and descriptions of the same must clearly identify themselves as a modified and unofficial version of POV-Ray. Any attempt to obscure the fact that the user is running POV-Ray or to obscure that this is an unofficial version expressly prohibited. POV-Ray may not be linked into other software either at compile-time using an object code linker nor at run-time as a DLL, ActiveX, or other system. Such linkage can tend to blur the end-user's perception of which program provides which functions and thus qualifies as an attempt to obscure what is running. To allow POV-Ray to communicate with outside programs, the official versions of POV-Ray include several internal communication "hooks" for it to call other tasks, often called an Application Programming Interface, or API. For example: the generic part of POV-Ray provides operating system shell-out API commands. The Windows version has a GUI-extension API and the ability to replace the text editor. Modification to these APIs or other officially supported communication mechanisms to increase functionality beyond that of the official version IS EXPRESSLY PROHIBITED. Conditions For Distribution Of Custom Versions If your re-compiled version meets all requirements for custom versions listed above, the following conditions apply to its distribution: You must provide all POV-Ray support for all users who use your custom version. You must provide information so that user may contact you for support for your custom version. The POV-Ray Team is not obligated to provide you or your users any technical support. Include contact information in the DISTRIBUTION_MESSAGE macros in the source file OPTOUT.H and insure that the program prominently displays this information. Display all copyright notices and credit screens for the official version. Custom versions may only be distributed as freeware. You must make all of your modifications to POV-Ray freely and publicly available with FULL SOURCE CODE to the modified portions of POV-Ray and must freely distribute full source to any new parts of the custom version. The goal is that users must be able to re-compile the program themselves using readily available compilers and run-time libraries and to be able to further improve the program with their own modifications. You must provide documentation for any and all modifications that you have made to the program that you are distributing. Include clear and obvious information on how to obtain the official POV-Ray. The user is encouraged to send enhancements and bug fixes to the POV-Ray Team, but the team is in no way required to utilize these enhancements or fixes. By sending material to the team, the contributor asserts that he owns the materials or has the right to distribute these materials. He authorizes the team to use the materials any way they like. The contributor still retains rights to the donated material, but by donating, grants unrestricted, irrevocable usage and distribution rights to the POV- Team. The team doesn't have to use the material, but if we do, you do not acquire any rights related to POV-Ray. The team will give you credit as the creator of new code if applicable. Include a copy of this document (POVLEGAL.DOC). Conditions For Commercial Bundling Vendors wishing to bundle POV-Ray with commercial software (including shareware) or other distribution not already described above must first obtain explicit permission from the POV-Team. Such permission is rarely granted. The POV-Team will decide if such distribution will be allowed on a case-by-case basis and may impose certain restrictions as it sees fit. The minimum terms are given below. Other conditions may be imposed. * The product must be an existing product that has proven itself as commercially viable without POV-Ray included. * The inclusion of POV-Ray should be promoted only as a free bonus and not as a feature designed to encourage customers to purchase or upgrade solely for the POV-Ray capability. * Purchasers of your product must not be led to believe that they are paying for POV-Ray. Any mention of the POV-Ray bundle on the box, in advertising or in instruction manuals must be clearly marked with a disclaimer that POV-Ray is free software and can be obtained for free or nominal cost from various sources. * Include clear and obvious information on how to obtain the official POV-Ray. * You must provide all POV-Ray support for all users who acquired POV-Ray through your product. The POV-Team is not obligated to provide you or your customers any technical support. * Include a credit page or pages in your documentation for POV-Ray. * If you modify any portion POV-Ray for use with your hardware or software, you must follow the custom version rules in addition to these rules. * Include contact and support information for your product. * Include a full user package as described above. POV-Team Endorsement Prohibitions On rare occasions, the POV-Team endorses distributions in which POV-Team members are compensated participants and which the POV-Team has given approval. Without specific approval, distributors (whether free or commercial) must not claim or imply in any way that the POV-Team officially endorses or supports the distributor or the product (such as CD, book, or magazine) associated with the distribution. You may not claim or imply that the POV-Team derives any benefit from your distribution. If you wish to emphasize that your distribution is legal, you may use this language "This distribution of the official version of POV-Ray is permitted under the terms of the General License in the file POVLEGAL.DOC. The POV- Team does not endorse the distributor or its products. The POV-Team receives no compensation for this distribution." Retail Value Of This Software Although POV-Ray is, when distributed within the terms of this agreement, free of charge, the retail value (or price) of this program is determined as US$20.00 per copy distributed or copied. If the software is distributed or copied without authorization you are legally liable to this debt to the copyright holder or any other person or organization delegated by the copyright holder for the collection of this debt, and you agree that you are legally bound by the above and will pay this debt within 30 days of the event. However, none of the above paragraph constitutes permission for you to distribute this software outside of the terms of this agreement. In particular, the conditions and debt mentioned above (whether paid or unpaid) do not allow you to avoid statutory damages or other legal penalties and does not constitute any agreement that would allow you to avoid such other legal remedies as are available to the copyright holder. Put simply, POV-Ray is only free if you comply with our distribution conditions; it is not free otherwise. The copyright holder of this software chooses to give it away free under these and only these conditions. For the purpose of copyright regulations, the retail value of this software is US$20.00 per copy. Other Provisions The team permits and encourages the creation of programs, including commercial packages, which import, export or translate files in the POV-Ray Scene Description Language. There are no restrictions on use of the language itself. We reserve the right to add or remove or change any part of the language. "POV-Ray", "Persistence of Vision", "POV-Team" and "POV-Help" are trademarks of the POV-Team. While we do not claim any restrictions on the letters "POV" alone, we humbly request that you not use POV in the name of your product. Such use tends to imply it is a product of the POV-Team. Existing programs which used "POV" prior to the publication of this document need not feel guilty for doing so provided that you make it clear that the program is not the work of the team nor endorsed by us. Revocation Of License VIOLATION OF THIS LICENSE IS A VIOLATION OF COPYRIGHT LAWS. IT WILL RESULT IN REVOCATION OF ALL DISTRIBUTION PRIVILEGES AND MAY RESULT IN CIVIL OR CRIMINAL PENALTY. Such violators who are prohibited from distribution will be identified in this document. In this regard, "PC Format", a magazine published by Future Publishing, Ltd. in the United Kingdom, distributed incomplete versions of POV-Ray 1.0 in violation the license which was effect at the time. They later attempted to distribute POV-Ray 2.2 without prior permission of the POV- Team in violation the license which was in effect at the time. There is evidence that other Future Publishing companies have also violated our terms. Therefore "PC Format", and any other magazine, book or CD-ROM publication owned by Future Publishing is expressly prohibited from any distribution of POV-Ray software until further notice. Disclaimer This software is provided as is without any guarantees or warranty. Although the authors have attempted to find and correct any bugs in the package, they are not responsible for any damage or losses of any kind caused by the use or misuse of the package. The authors are under no obligation to provide service, corrections, or upgrades to this package. Technical Support We sincerely hope you have fun with our program. If you have any problems with the program, the team would like to hear about them. Also, if you have any comments, questions or enhancements, please the POV-Ray Team on the internet at http://www.povray.org or our private news server news.povray.org with over a dozen povray-related news groups. The USENET group comp.graphics.rendering.raytracing is also a great source of information on POV-Ray and related topics. License inquiries should be made via email and limited technical support is available via email to: POV-Ray Team Coordinator team-coord@povray.org The following postal address is only for official license business and only if email is impossible. We do not provide technical support via regular mail, only email. We don't care if you don't have a modem or online access. We will not mail you disks with updated versions. Do not send money. Chris Young; 3119 Cossell Drive; Indianapolis, IN 46224 U.S.A. The other authors' contact information may be found in the documentation. Authors Following is a list in alphabetic order of all people who have ever worked on the POV-Ray Team or who have made a note-worthy contribution. If you want to contact or thank the authors read the sections " REF _Ref422141956 \h Contacting the Authors" or use email addresses below. CURRENT POV-Team MEMBERSNAMEPARTICIPATIONEMAILDieter BayerWrote sor, lathe, prism, media and many other featuresdbayer@tomtec.deThomas BaierNew 3.1 team member, tester HYPERLINK mailto:thbaier@ibm.net thbaier@ibm.netChris CasonWindows version coordinator and other contributionsDale C. BrodinAlpha & Beta tester, forum supportbrodin@execpc.comThorsten Froehlich Mac developerThorstenFroehlich@compuserve.comAlan KongAlpha & Beta tester, forum supportakong@pacbell.netLutz KretzschmarMoray author, MS-Dos 24-bit VGA, part of the anti-aliasing code HYPERLINK mailto:lutz@stmuc.com lutz@stmuc.comJoel NewkirkPrimary Amiga developernewkirk@snip.netNathan O'BrienArtist, tester HYPERLINK mailto:no13@no13.net no13@no13.netRedaelli Paolo Amiga developer HYPERLINK mailto:redaelli@inc.it redaelli@inc.itAnton RavesAlpha & Beta tester, Mac contributor HYPERLINK mailto:100022.2603@compuserve.com 100022.2603@compuserve.comEduard SchwanMac version coordinator, mosaic preview, docs HYPERLINK mailto:espsw@compuserve.com espsw@home.comErkki SondergaardAlpha & Beta tester, 3.0 Scene filesTimothy WegnerFractal objects, PNG supporttwegner@phoenix.netChris YoungPOV-Team coordinator, parser codeteam-coord@povray.org PAST POV-Team MEMBERS and CONTRIBTORSNAMEPARTICIPATIONEMAILClaire AmundsenTutorials for the POV-Ray User GuideSteve AngerPOV-Ray 2.0/3.0 developersanger@globalserve.netRandy AntlerMS-Dos display code enhancementsJohn BailyRLE targa codeEric BarishGround fog codeKendall BennettPMODE library supportSteve BennettGIF supportDavid BuckOriginal author of DKBTrace POV-Ray 1.0 developerAaron CollinsCo-author of DKBTrace 2.12 POV-Ray 1.0 developerChris DaileyPOV-Ray 3.0 developerSteve DemlowPOV-Ray 3.0 developerAndreas DilgerFormer Unix coordinator, Linux developer, PNG support HYPERLINK mailto:adilger@enel.ucalgary.ca adilger@enel.ucalgary.ca www-mddsp.enel.ucalgary.ca/People/adilger/Joris van Drunen LittelMac beta testerAlexander EnzmannPOV-Ray 1.0/2.0/3.0 developerxander@mitre.comDan FarmerPOV-Ray 1.0/2.0/3.0 developerCharles FusnerBlob, lathe and prism tutorial tutorials for the POV-Ray User GuideDavid HarrMac balloon help and palette codeJimmy HoeksHelp file for Windows user interfaceTerry KanakisCamera fixKari Juharvi KivisaloGround fog codeCharles MarslettMS-Dos display codePascal MassiminoFractal objectsJim McElhineyPOV-Ray 3.0 developerRobert A. MickelsenArtist, 3.0 docs contributor HYPERLINK mailto:ram@iu.net ram@iu.net www.mickelsenstudios.comMike MillerArtist, scene files, stones.incDouglas MuirBump maps, height fieldsJim NitchalsMac version, scene files (Jim passed away in June 1998 but his contributions to POV-Ray will not be forgotten)Paul NovakTexture contributionsDave ParkAmiga support, AGA video codeDavid PayneRLE targa codeBill PulverTime codeDan Richardson3.0 DocsTim RowleyPPM and Windows-specific BMP image format supporttrowley@geom.umn.eduRobert SkinnerNoise functionsZsolt SzalavariHalo code which was later turned into mediazsolt@cg.tuwien.ac.atScott TaylorLeopard and onion texturesDrew WellsPOV-Ray 1.0 developer, POV-Ray 1.0 team coordinator Contacting the Authors The POV-Team is a collection of volunteer programmers, designers, animators and artists meeting via the internet at http://www.povray.org. The POV-Team's goal is to create freely distributable, high quality rendering and animation software written in C that can be easily ported to many different computers. If you have any questions about POV-Ray, please contact POV-Team Coordinator team-coord@povray.org We love to hear about how you're using and enjoying the program. We also will do our best try to solve any problems you have with POV-Ray and incorporate good suggestions into the program. If you have a question regarding commercial use or distribution of POV-Ray, or anything else particularly sticky, please contact Chris Young, the development team coordinator. Otherwise, spread the mail around. We all love to hear from you! Please do not send large files to us through the e-mail without asking first. Send a query before you send the file, thanks! What to do if you don't have POV-Ray This documentation assumes you already have POV-Ray installed and running however the POV-Team does distribute this file by itself in various formats including online on the internet. If you don't have POV-Ray or aren't sure you have the official version or the latest version, then the following sections will tell you what to get and where to get it. Which Version of POV-Ray should you use? POV-Ray can be used under MS-Dos, Windows 3.x, Windows for Workgroups 3.11, Windows 95, Windows NT, Apple Macintosh 68k, Power PC, Amiga, Linux, UNIX and other platforms. The latest versions of the necessary files are available on our web site at http://www.povray.org and through various CD distributions. See section " REF _Ref449776419 \h Where to Find POV-Ray Files" for more info. If your platform is not supported and you are proficient in compiling source code programs written in C then, see section " REF _Ref422831205 \h Compiling POV-Ray" for more information. Microsoft Windows 95/98/NT The Windows version runs under Windows 95, Windows 98, and Windows NT4 also should run under OS/2 Warp. Windows 3.1 and Windows for Workgroups are no longer supported however the MS-Dos version will run as a dos application under those operating systems. Required hardware and software: Minimum - 486/100 with 16mb RAM and Windows 95. Disk space - 15 megabytes Required POV-Ray files: User archive POVWIN3.EXE - a self-extracting archive containing the program, sample scenes, standard include files and documentation. This file may be split into smaller files for easier downloading. Check the directory of your download or ftp site to see if other files are needed. Recommended: Pentium 200 or Pentium II with 32mb and Windows 95 or NT4. SVGA display preferably with high color or true color ability and drivers installed. (Note: accelerated graphics hardware will not improve performance.) Optional: The source code is not needed to use POV-Ray. It is provided for the curious and adventurous. POVWIN_S.ZIP --- The C source code for POV-Ray for Windows. Contains generic parts and Windows specific parts. It does not include sample scenes, standard include files and documentation so you should also get the executable archive as well. POV-Ray can only be compiled using C compilers that create 32-bit Windows applications. We support Watcom 10.5a or higher, Borland 4.52/5.0 compilers. MS-Dos & Windows 3.x The MS-Dos version runs under MS-Dos or as a DOS application under Windows 3.1 or Windows for Workgroups 3.11. Although it also runs under Windows 95/98/NT4 and OS/2 Warp, users of those systems should use the Windows version.. Required hardware and software: A 386 or better CPU and at least 8 meg of RAM. About 6 meg disk space to install and 2-10 meg or more beyond that for working space. A text editor capable of editing plain ASCII text files. The EDIT program that comes with MS-Dos will work for moderate size files. Graphic file viewer capable of viewing GIF and perhaps TGA and PNG formats. Required POV-Ray files: POVMSDOS.EXE - a self-extracting archive containing the program, sample scenes, standard include files and documentation in plain ASCII text format. This file may be split into smaller files for easier downloading. Check the directory of your download or ftp site to see if other files are needed. Recommended: Pentium 200 or Pentium II (faster the better) 32 meg or more RAM. SVGA display preferably with VESA interface and high color or true color ability. (Note: accelerated graphics hardware will not improve performance.) Optional: The source code is not needed to use POV-Ray. It is provided for the curious and adventurous. POVMSD_S.ZIP - The C source code for POV-Ray for MS-Dos. Contains generic parts and MS-Dos specific parts. It does not include sample scenes, standard include files and documentation so you should also get the executable archive as well. Requires a C compiler that can create 32-bit protected mode applications. We support Watcom 11, Borland 4.52 with DOS Power Pack and DJGPP 2. Linux for Intel x86 Required hardware and software: A 386 or better CPU and at least 8 meg of RAM. About 6 meg disk space to install and 2-10 meg or more beyond that for working space. A text editor capable of editing plain ASCII text files. Graphic file viewer capable of viewing PPM, TGA or PNG formats. Any recent (1994 onwards) Linux kernel and support for ELF format binaries. POV-Ray for Linux is not in a.out-format. ELF libraries libc.so.5, libm.so.5 and one or both of libX11.so.6 or libvga.so.1. Required POV-Ray files: POVLINUX.TGZ or POVLINUX.TAR.GZ - archive containing an official binary for each SVGALib and X-Windows modes. Also contains sample scenes, standard include files and documentation in plain ASCII text. Recommended: Pentium 200 or Pentium II (faster the better) 32 meg or more RAM. SVGA display preferably with VESA interface and high color or true color ability. If you want display, you'll need either SVGALib or X-Windows. (Note: accelerated graphics hardware will not improve performance.) Optional: The source code is not needed to use POV-Ray. It is provided for the curious and adventurous. POVUNI_S.TAR.GZ or POVUNI_S.TGZ - The C source code for POV-Ray for Linux. Contains generic parts and Linux specific parts. It does not include sample scenes, standard include files and documentation so you should also get the executable archive as well. Requires the GNU C compiler and (optionally) the X include files and libraries. Apple Macintosh The MacOS versions run under Apple's MacOS operating system version 7.1 or newer, on any 68020/030/040-based Macintosh-compatible computer (with or without a floating point coprocessor) or any of the PowerPC Macintosh-compatible computers. Required hardware and software: A 68020 or better CPU without a floating point unit (LC or Performa or Centris series); at least 8 MB RAM or A 68020 or better CPU *with* a floating point unit (Mac II or Quadra series); at least 8 MB RAM or Any PowerPC Macintosh computer and at least 8 MB RAM. System 7.1 or newer and color QuickDraw (System 6 is no longer supported). Appearance Extension is also required now. This comes standard in MacOS 8, but can be downloaded from Apple's web site and installed on any Mac running 7.1 or newer. Navigation Services is not required, but will enhance the open/save dialogs if it is present. It is also a free extension available from Apple's web site, which can be used in 7.5.5 or newer. About 6 MB free disk space to install and an additional 2-10 MB free space for your own creations (scenes and images). Graphic file viewer utility capable of viewing Mac PICT, GIF and perhaps TGA and PNG formats (the shareware GraphicConverter or GIFConverter applications are good.) Required POV-Ray files: POVMACNF.SIT or POVMACNF.SIT.HQX - a Stuffit archive containing the non-FPU 68K Macintosh application, sample scenes, standard include files and documentation (slower version for Macs without an FPU) or POVMAC68.SIT or POVMAC68.SIT.HQX - a Stuffit archive containing the FPU 68K Macintosh application, sample scenes, standard include files and documentation (faster version for Macs WITH an FPU) or POVPMAC.SIT or POVPMAC.SIT.HQX - a Stuffit archive containing the native Power Macintosh application, sample scenes, standard include files and documentation. Recommended: 68030/33 or faster with FPU, or any Power Macintosh 8 MB or more RAM for 68K Macintosh; 16 MB or more for Power Macintosh systems. Color monitor preferred, 256 colors OK, but thousands or millions of colors is even better. Optional: The source code is not needed to use POV-Ray. It is provided for the curious and adventurous. POV-Ray can be compiled using Apple's MPW 3.3, Metrowerks CodeWarrior Pro or Symantec 8. POVMACS.SIT or POVMACS.SIT.HQX - The full C source code for POV-Ray for Macintosh. Contains generic parts and Macintosh specific parts. It does not include sample scenes, standard include files and documentation so you should also get the executable archive as well. Amiga The Amiga version comes in several flavors, 68000/68020 without FPU, (not recommended, very slow) 68020/68030 with FPU, 68040, and 68060. There's two way to use POV: Shell only and using the provided GUI interface which requires MUI 3.8. All versions run under OS3.x and up. Support exists for pensharing and window display under OS3.x with 256 color palettes, plus CyberGraphics and Picasso 96 24-bit display. Required: At least 4 meg of RAM. At least 2 meg of hard disk space for the necessities, 5-20 more recommended for workspace. An ASCII text editor, GUI configurable to launch the editor of your choice. Graphic file viewer - POV-Ray outputs to PNG, Targa (TGA), and PPM formats. POV-Ray Amiga can load any image format with Picture.Datatype V43 and the appropriate datatype. Required POV-Ray files: POVAMIx0.LHA -- a LHA archive containing executable, sample scenes, standard include files, and documentation for the 680x0 version of POV-Ray (i.e.: POVAMI60.LHA stands for 68060 version); 68020 version needs FPU. Recommended: 8 meg or more of RAM. 68030 & 68882 or higher processor. 24bit display card (CyberGFX and Picasso 96 library supported) Amiga PowerPC version of POV-Ray is now in beta testing. Watch the or www.povray.org for further news. Optional: The source code is not needed to use POV-Ray. It is provided for the curious and adventurous. POVAMI_S.LHA --- The C source code for POV-Ray for Amiga. Contains generic parts and Amiga specific parts. It does not include sample scenes, standard include files, and documentation so you should also get the executable archive as well. SunOS Required hardware and software: A Sun SPARC processor and at least 4 meg of RAM. About 6 meg disk space to install and 2-10 meg or more beyond that for working space. Graphic file viewer capable of viewing PPM, TGA or PNG formats. A text editor capable of editing plain ASCII text files. SunOS 4.1.3 or other operating system capable of running such a binary (Solaris or possibly Linux for Sparc). Required POV-Ray files: POVSUNOS.TGZ or POVSUNOS.TAR.GZ - archive containing an official binary for each text-only and X-Windows modes. Also contains sample scenes, standard include files and documentation. Recommended: 8 meg or more RAM. If you want display, you'll need X-Windows or an X-Term.- preferably 24-bit TrueColor display ability, although the X display code is known to work with ANY combination of visual and color depth. Graphic file viewer capable of viewing PPM, TGA or PNG formats. Optional: The source code is not needed to use POV-Ray. It is provided for the curious and adventurous. POVUNI_S.TGZ or POVUNI_S.TAR.GZ - The C source code for POV-Ray for UNIX. Contains generic parts and Unix/Linux specific parts. It does not include sample scenes, standard include files and documentation so you should also get the executable archive as well. You will need a C compiler and (optionally) the X include files and libraries and knowledge of how to use it. Although we provide source code for generic Unix systems, we do not provide technical support on how to compile the program. Generic Unix Because Unix runs on a wide variety of hardware and CPUs, the POV-Team cannot provide executable versions for every type of Unix. We distribute generic Unix source code in portable ANSI C source code. You will need a C compiler and (optionally) the X include files and libraries and knowledge of how to use it. Although we provide source code for generic Unix systems, we do not provide technical support on how to compile the program. Required: POVUNI_S.TGZ or POVUNI_S.TAR.GZ - The C source code for POV-Ray for UNIX. Contains generic parts and Unix/Linux specific parts. It does not include sample scenes, standard include files and documentation so you should also get an executable archive for another platform or get POVUNI_D.TGZ or POVUNI_D.TAR.GZ which contains the sample scenes, standard include files and documentation. A C compiler for your computer and KNOWLEDGE OF HOW TO USE IT. Graphic file viewer capable of viewing PPM, TGA or PNG formats. A text editor capable of editing plain ASCII text files. Recommended: Math co-processor. 8 meg or more RAM. Optional: X Windows if you want to be able to display as you render. You will need the X-Windows include files as well. If you're not familiar with compiling programs for X-Windows you may need some help from someone who is knowledgeable at your installation because the X include files and libraries are not always in a standard place. All Versions Each executable archive includes full documentation for POV-Ray itself as well as specific instructions for using POV-Ray with your type of platform. All versions of the program share the same ray-tracing features like shapes, lighting and textures. In other words, an MS-Dos-PC can create the same pictures as a Cray supercomputer as long as it has enough memory. The user will want to get the executable that best matches their computer hardware. In addition to the files listed above, the POV-Team also distributes the user documentation in two alternate forms. Note this is the same documentation distributed in other archives but in a different format. This may be especially useful for MS-Dos or Unix users because their documentation is plain ASCII text only. POVUSER.PDF - Tutorial and Reference documentation in Adobe Acrobat PDF format. Requires Adobe Acrobat Reader available for Windows 3.x, Windows 95/98/NT, Mac and some Unix systems. Go to  HYPERLINK http://www.adobe.com/prodindex/acrobat/readstep.html http://www.adobe.com/prodindex/acrobat/readstep.html to get the reader for free. POVHTML.ZIP - Archive containing Tutorial and Reference documentation in html for viewing with any internet browser. POV31W97.ZIP - Archive containing Tutorial and Reference documentation in Microsoft Word 97 format. See the section " REF _Ref422912420 \h Where to Find POV-Ray Files" for where to find these files. You can contact those sources to find out what the best version is for you and your computer. Where to Find POV-Ray Files The latest versions of the POV-Ray software are available from the following sources. World Wide Website www.povray.org The internet home of POV-Ray is reachable on the World Wide Web via the address http://www.povray.org and via ftp as ftp.povray.org. Please stop by often for the latest files, utilities, news and images from the official POV-Ray internet site. The comp.graphics.rendering.raytracing newsgroup has many competent POV-Ray users that are very willing to share their knowledge. They generally ask that you first browse a few files to see if someone has already answered the same question, and of course, that you follow proper "netiquette". If you have any doubts about the qualifications of the folks that frequent the group, a few minutes spend at the Ray Tracing Competition pages at www.povray.org will quickly convince you! Also the POV-Team operates its own news server on the internet with several news groups related to POV-Ray and other interesting programs. For more information about the server see http://www.povray.org/groups.html. Books, Magazines and CD-ROMs Unfortunately all English language books on POV-Ray are out of print and there are no plans to reprint them. However there is now a POV-Ray 3.02 book and CD-ROM available in Japanese. It talks about the Windows and Mac versions of POV-Ray, and various utilities. The CD-ROM is dual format, Windows/Mac. It was written in Japan by Hideki Komuro-san, and published by ASCII Corp. in June 1998, ISBN 4-7561-1831-3. Many popular computer magazines have been authorized to distribute POV-Ray on cover CDs. Note that such distributions of the official version of POV-Ray is permitted under the terms of the General License in the file POVLEGAL.DOC. The POV-Team does not endorse the distributor or its products. The POV-Team receives no compensation for this distribution. The POV-Team does endorse some CD-ROMs containing POV-Ray which are prepared by team members. A portion of the proceeds from these CDs support our internet sites and other team activities. You can always find the latest information on what is available at our web site www.povray.org. Compiling POV-Ray The following sections will help you to compile the portable C source code into a working executable version of POV-Ray. They are only for those people who want to compile a custom version of POV-Ray or to port it to an unsupported platform or compiler. The first question you should ask yourself before proceeding is "Do I really need to compile POV-Ray at all?" Official POV-Team executable versions are available for MS-Dos, Windows 95/98/NT, Mac 68k, Mac Power PC, Amiga, Linux for Intel x86, and SunOS. Other unofficial compiles may soon be available for other platforms. If you do not intend to add any custom or experimental features to the program and if an executable already exists for your platform then you need not compile this program yourself. If you do want to proceed you should be aware that you are very nearly on your own. The following sections and other related compiling documentation assume you know what you are doing. It assumes you have an adequate C compiler installed and working. It assumes you know how to compile and link large, multi-part programs using a "make" utility or an IDE project file if your compiler supports them. Because makefiles and project files often specify drive, directory or path information, we cannot promise our makefiles or projects will work on your system. We assume you know how to make changes to makefiles and projects to specify where your system libraries and other necessary files are located. In general you should not expect any technical support from the POV-Team on how to compile the program. Everything is provided here as is. All we can say with any certainty is that we were able to compile it on our systems. If it doesn't work for you we probably cannot tell you why. There is no technical documentation for the source code itself except for the comments in the source files. We try our best to write clear, well- commented code but some sections are barely commented at all and some comments may be out dated. We do not provide any technical support to help you to add features. We do not explain how a particular feature works. In some instances, the person who wrote a part of the program is no longer active in the Team and we don't know exactly how it works. When making any custom version of POV-Ray or any unofficial compile, please make sure you read and follow all provisions of our license in POVLEGAL.DOC. In general you can modify and use POV-Ray on your own however you want but if you distribute your unofficial version you must follow our rules. You may not under any circumstances use portions of POV-Ray source code in other programs. Directory Structure POV-Ray source code is distributed in archives with files arranged in a particular hierarchy of directories or folders. When extracting the archives you should do so in a way that keeps the directory structure intact. In general we suggest you create a directory called povray3 or povray31 and extract the files from there. The extraction will create a directory called source with many files and sub-directories. In general, there are separate archives for each hardware platform and operating system but each of these archives may support more than one compiler. For example here is the directory structure for the MS-Dos archive. Other platforms use similar structures. SOURCE SOURCE\LPNG101 SOURCE\ZLIB SOURCE\MSDOS SOURCE\MSDOS\PMODE SOURCE\MSDOS\BORLAND SOURCE\MSDOS\DJGPP SOURCE\MSDOS\WATCOM The source directory contains source files for the generic parts of POV-Ray that are the same on all platforms. The source\lpng101 contains files for compiling a library of routines used in reading and writing PNG (Portable Network Graphics) image files. The source\zlib contains files for compiling a library of routines used by libpng to compress and uncompress data streams. All of these files are used by all platforms and compilers. They are in every version of the source archives. The source\msdos directory contains all source files for the MS-Dos version common to all supported MS-Dos compilers. The pmode sub-directory contains source files for pmode.lib which is required by all MS-Dos versions. The borland, djgpp, and watcom sub-directories contain source, makefiles and project files for C compilers by Borland, DJGPP and Watcom. The source\msdos directory is only in the MS-Dos archive. Similarly the Windows archive contains a source\windows directory. The Unix archive contains source/unix etc. The source\msdos directory contains a file cmpl_msd.doc which contains compiling information specific to the MS-Dos version. Other platform specific directories contain similar cmpl_xxx.doc files and the compiler specific sub-directories also contain compiler specific cmpl_xxx.doc files. Be sure to read all pertinent cmpl_xxx.doc files for your platform and compiler. Configuring POV-Ray Source Every platform has a header file config.h that is generally in the platform specific directory but may be in the compiler specific directory. Some platforms have multiple versions of this file and you may need to copy or rename it as config.h. This file is included in every module of POV-Ray. It contains any prototypes, macros or other definitions that may be needed in the generic parts of POV-Ray but must be customized for a particular platform or compiler. For example different operating systems use different characters as a separator between directories and file names. MS-Dos uses back slash, Unix a front slash or Mac a colon. The config.h file for MS-Dos and Windows contains the following: #define FILENAME_SEPARATOR '\' which tells the generic part of POV-Ray to use a back slash. Every customization that the generic part of the code needs has a default setting in the file source\frame.h which is also included in every module after config.h. The frame.h header contains many groups of defines such as this: #ifndef FILENAME_SEPARATOR #define FILENAME_SEPARATOR '/' #endif which basically says "If we didn't define this previously in config.h then here's a default value". See frame.h to see what other values you might wish to configure. If any definitions are used to specify platform specific functions you should also include a prototype for that function. The file source\msdos\config.h, for example, not only contains the macro: #define POV_DISPLAY_INIT(w,h) MSDOS_Display_Init ((w), (h)); to define the name of the graphics display initialization function, it contains the prototype: void MSDOS_Display_Init (int w, int h); If you plan to port POV-Ray to an unsupported platform you should probably start with the simplest, non-display generic Unix version. Then add new custom pieces via the config.h file. Conclusion We understand that the above sections are only the most trivial first steps but half the fun of working on POV-Ray source is digging in and figuring it out on your own. That's how the POV-Team members got started. We've tried to make the code as clear as we can. Be sure to read the cmpl_xxx.doc files in your platform specific and compiler specific directories for some more minor help if you are working on a supported platform or compiler. Good luck! Suggested Reading Beside the POV-Ray material mentioned in " REF _Ref423165651 \h Books, Magazines and CD-ROMs" there are several good books or periodicals that you should be able to locate in your local computer book store or your local university library. "An Introduction to Ray tracing" Andrew S. Glassner (editor) ISBN 0-12-286160-4; Academic Press 1989 "3D Artist" Newsletter, "The Only Newsletter about Affordable PC 3D Tools and Techniques") Publisher: Bill Allen; P.O. Box 4787; Santa Fe, NM 87502-4787; (505) 982-3532 "Image Synthesis: Theory and Practice" Nadia Magnenat-Thalman and Daniel Thalmann; Springer-Verlag; 1987 "The RenderMan Companion" Steve Upstill; Addison Wesley; 1989 "Graphics Gems" Andrew S. Glassner (editor); Academic Press; 1990 "Fundamentals of Interactive Computer Graphics" J. D. Foley and A. Van Dam; ISBN 0-201-14468-9; Addison-Wesley 1983 "Computer Graphics: Principles and Practice (2nd Ed.)" J. D. Foley, A. van Dam, J. F. Hughes; ISBN 0-201-12110-7; Addison-Wesley, 1990 "Computers, Pattern, Chaos, and Beauty" Clifford Pickover; St. Martin's Press; "SIGGRAPH Conference Proceedings"; Association for Computing Machinery Special Interest Group on Computer Graphics "IEEE Computer Graphics and Applications"; The Computer Society; 10662, Los Vaqueros Circle; Los Alamitos, CA 90720 "The CRC Handbook of Mathematical Curves and Surfaces" David von Seggern; CRC Press; 1990 "The CRC Handbook of Standard Mathematical Tables" CRC Press Index  INDEX \c "3"  #break, 171 #case, 171 #debug, 172 #declare, 14, 148, 153, 156, 158, 159, 163, 164, 166, 174, 176, 180, 188 #default, 168 #else, 169, 170, 171 #end, 169, 170, 171, 173, 174 #error, 172 #fclose, 14, 166 #fopen, 14, 166 #if, 169, 170, 173 #ifdef, 166, 170, 174 #ifndef, 170, 174 #include, 17, 72, 162, 164 #local, 14, 148, 158, 163, 164, 166, 169, 173, 174, 176, 180 #macro, 14, 164, 173 #max_intersections, 162 #max_trace_level, 162 #range, 171 #read, 14, 167 #render, 172 #statistics, 172 #switch, 170 #undef, 14, 164, 165, 166, 174 #version, 14, 129, 148, 169 #warning, 172 #while, 171, 173 #write, 14, 167, 173 %o, 130 %s, 130 .blue, 157 .filter, 157 .green, 157 .red, 157 .t, 153 .transmit, 157 .u, 153 .v, 153 .x, 153 .y, 153 .z, 153 /* */, 144 //, 144 +?, 136 +A, 139 +AM, 139 +AM1, 139 +B, 127 +C, 123 +D, 124 +E, 122 +EC, 122 +EP, 125 +ER, 122 +F, 126 +FD, 126 +FN, 123, 126 +FR, 126 +GA, 135 +GD, 134, 135 +GF, 134, 135 +GI, 123 +GR, 134, 135 +GS, 135 +GW, 135 +H, 116, 136, 184 +HN, 128 +HT, 128 +HTC, 128 +I, 116, 117, 129, 130, 142 +J, 140 +K, 119, 148 +KC, 121 +KF, 120 +KFF, 119 +KFI, 119 +KI, 120 +L, 18, 116, 150, 162, 240, 246, 255 +MB, 137 +MV, 129, 148, 169 +O, 127 +P, 116, 125 +Q, 136, 241 +QR, 137, 297 +R, 139, 140 +S, 122 +SC, 122, 123 +SP, 125 +SR, 122, 123 +SU, 138 +UA, 123, 126 +UD, 125 +UF, 121 +UL, 138 +UO, 121 +UV, 138 +V, 116, 117, 125, 134 +W, 116 +X, 122 abs, 149 absorption, 282, 283, 286 acos, 149 acosh, 197 adaptive, 67, 223 adc_bailout, 292, 296 agate, 74, 258, 271 agate_turb, 258, 271 all, 240 All_Console, 135 All_File, 135 alpha, 154, 241 alpha channel, 241 ambient, 68, 80, 248, 252, 282, 297 ambient light, 68 ambient_light, 249, 293 angle, 106, 183, 186, 291 animation, 110 Antialias, 139 Antialias_Depth, 139, 140 Antialias_Threshold, 139 aperture, 187 append, 166, 167 arc_angle, 109, 291 area_light, 67, 222, 224 array, 14 asc, 149 asin, 149, 197 asinh, 197 assumed_gamma, 124, 293, 295 atan, 197 atan2, 149 atanh, 197 atmosphere, 13, 225, 281, 288 atmospheric_attenuation, 225 average, 87, 239, 246, 254, 258, 287 background, 97, 289 banner stream, 134 Bezier patch, 26 bicubic_patch, 26, 207 Bits_Per_Color, 126 black_hole, 275 blob, 189 blue, 19, 154, 156 blur_samples, 187 bounded_by, 226, 227 Bounding, 137 Bounding_Threshold, 137 box, 20, 191 boxed, 13, 259, 286 bozo, 13, 74, 259, 261, 269, 273, 286 brick, 73, 85, 236, 238, 239, 243, 244, 246, 254, 258, 260, 271, 272, 273, 287 brick_size, 260, 271 brightness, 298 brilliance, 249 Buffer_Output, 127 Buffer_Size, 127 bump_map, 242, 244, 246, 247, 272, 273, 279, 280 bump_size, 242, 247, 271 bumps, 71, 78, 242, 244, 260, 272, 273 camera, 18, 186 caustic, 13 caustics, 233, 248 ceil, 149 checker, 85, 236, 238, 239, 240, 243, 244, 246, 253, 254, 255, 258, 261, 272, 273, 287 chr, 159 clipped_by, 206, 211, 226, 227, 230 clock, 119, 148 Clock, 119, 148 clock_delta, 15, 148 color, 19, 101, 236 color_map, 72, 236, 237, 239, 258, 260, 261, 264, 271, 272, 273, 275, 286, 291 colour_map, 237 comments, 144 component, 190 composite, 215 concat, 159 cone, 20, 192, 213 confidence, 187, 285 conic_sweep, 200, 201 constructive solid geometry, 21 Continue_Trace, 123 control0, 266, 271 control1, 266, 271 cos, 149, 197 cosh, 197 count, 298, 300 crackle, 261 crand, 114, 250 Create_Ini, 123 Create_INI, 131 CSG, 21 cube, 197 cubic, 212 cubic_spline, 42, 199, 200 cubic_wave, 13, 273 Cyclic_Animation, 121 cylinder, 21, 34, 67, 190, 193, 213, 218, 222, 224 cylindrical, 13, 183, 184, 186, 261, 286 cylindrical light, 67 -D, 124 debug stream, 134, 172 Debug_Console, 134 Debug_File, 135 DEF files, 116 default files, 116 defined, 167 degrees, 149 density, 13, 258, 271, 273, 282, 285, 286, 287 density_file, 262, 271 density_map, 258, 271, 272, 286, 287 dents, 13, 78, 242, 244, 262, 272, 273 df3, 262 difference, 23, 215, 216 diffuse, 80, 82, 249, 252 diffuse reflection, 249 difuse, 282 dimension, 149 dimension_size, 14, 150 dimensions, 14 direction, 106, 182, 183, 184, 186, 291 disc, 208 Display, 124 Display_Gamma, 124, 127, 293, 295 distance, 101, 289, 291 distance_maximum, 298, 300 div, 150 Draw_Vistas, 125 eccentricity, 284 emission, 282, 286 End_Column, 122 End_Row, 122, 123 error_bound, 299, 300 exp, 150, 197 extinction, 283 -F, 123, 126 fade_distance, 13, 70, 224, 232 fade_power, 13, 70, 224, 232 falloff, 66, 219, 276 falloff_angle, 109, 291 false, 148, 149 fatal stream, 134, 172 Fatal_Console, 134 Fatal_Error_Command, 130, 131, 132 Fatal_Error_Return, 131 Fatal_File, 135 Field_Render, 121 file_exists, 150 filter, 75, 154, 156, 232, 233, 240, 282 filter all, 240 Final_Clock, 120 Final_Frame, 114, 119, 120, 121 finish, 13, 71, 168, 230, 232, 233, 234, 236, 243, 247, 248, 249, 250, 251, 252 fisheye, 184, 186 flatness, 207 flip, 278 floor, 150 focal_point, 187 fog, 101, 289 fog_alt, 104, 289 fog_offset, 104, 289 fog_type, 104, 289 frequency, 74, 268, 269, 271 gif, 195, 240, 246, 255 global_settings, 137, 162, 292, 297 gradient, 74, 237, 239, 245, 254, 262, 265, 271, 272, 286 granite, 74, 263 gray_threshold, 299, 300 green, 19, 154, 156 halo, 13, 228, 230, 233, 253, 259, 262, 265, 268, 281, 286, 288 Height, 122, 125, 184 height_field, 36, 193 hexagon, 73, 85, 236, 238, 239, 243, 244, 246, 254, 258, 263, 272, 273, 287 hf_gray_16, 36, 127, 295 hierarchy, 149, 190, 191, 208, 226 Histogram_Name=file, 128 Histogram_Type, 128 hollow, 106, 149, 226, 229, 231, 233 hypercomplex, 197 iff, 240, 246, 255 image_map, 238, 239, 246, 272, 273, 279 Include_INI, 118 INI files, 116 Initial_Clock, 120 Initial_Frame, 114, 119, 120 initialization files, 116 Input_File_Name, 129, 130, 142 int, 150 interior, 13, 190, 228, 230, 231, 232, 233, 234, 248, 253, 281 internal_highlights, 228 internal_reflections, 228 interpolate, 240, 247, 256, 262, 271, 281 intersection, 23, 215, 216, 226 intervals, 285 inverse, 106, 211, 215, 217, 226, 228 inverted, 276 ior, 13, 232, 248 irid, 83, 252, 273 irid_wavelength, 295 -J, 140 jitter, 67, 107, 114, 223, 291 Jitter, 140 Jitter_Amount, 140 julia_fractal, 196 lambda, 74, 83, 274, 290 lathe, 14, 38, 198 layered textures, 87, 257 leopard, 74 Library_Path, 18, 117, 150, 162, 240, 246, 255 light source, 19 Light_Buffer, 138 light_source, 19, 65, 218 linear_spline, 39, 42, 198, 199, 200 linear_sweep, 50 location, 182 log, 150, 197 look_at, 182, 183, 184, 186 looks_like, 69, 229 low_error_factor, 299, 300 mandel, 264, 272 map_type, 240, 247, 256, 280 marble, 74, 265, 272 material, 226, 255 material_map, 168, 228, 235, 255, 258, 272, 273, 279, 280 matrix, 177, 179, 180, 271, 278 max, 150 max_iteration, 196 max_trace_level, 293, 295 -MB, 137 media, 13, 228, 230, 233, 253, 259, 262, 265, 268, 281, 282, 286, 287, 288 media_attenuation, 149, 225, 282 media_interaction, 149, 225, 282, 288 merge, 25, 215, 217 mesh, 43, 208, 210 metallic, 82, 251 min, 150 minimum_reuse, 299, 300 mod, 150 mortar, 260, 271 nearest_count, 299, 300 no, 148, 149 no_shadow, 69, 224, 226, 229 normal, 13, 78, 79, 168, 187, 233, 234, 236, 242, 243, 245, 248, 260, 261, 262, 265, 268, 269, 270, 271, 273 normal_map, 84, 242, 243, 245, 258, 261, 262, 265, 268, 269, 270, 271, 272, 273 number_of_waves, 296 object, 164 objects, 188 octaves, 74, 83, 273, 274, 290 Odd_Field, 121 off, 148, 149 offset, 278 omega, 74, 83, 274, 290 omnimax, 184, 186 on, 148, 149 once, 93, 240, 247, 256, 280 onion, 265, 272 open, 20, 193, 201, 230 orthographic, 184, 186 Output_Alpha, 126 Output_File_Name, 119, 127 Output_File_Type, 126 Output_to_file, 123 Output_to_File, 126 -P, 116, 125 Palette, 124 panoramic, 183, 186 pattern, 258 Pause_When_Done, 125 perspective, 184, 186 pgm, 195, 240, 246, 255 phase, 113, 268, 269, 271, 272 phong, 71, 81, 250, 251 phong_size, 81, 250 pi, 148 pigment, 13, 73, 78, 168, 233, 234, 235, 236, 238, 243, 248, 259, 271, 273 pigment_map, 76, 83, 236, 238, 245, 258, 271, 272 planar, 13, 265, 286 plane, 21, 211 png, 195, 240, 246, 255 point_at, 66, 219 pointlight, 65 poly, 211 poly_wave, 13, 273 polygon, 44, 209 Post_Frame_Command, 130, 131, 132 Post_Frame_Return, 131 Post_Scene_Command, 130, 131, 133 Post_Scene_Commands, 132 Post_Scene_Return, 131 pot, 195 pow, 150 ppm, 195, 240, 246, 255 Pre_Frame_Command, 130, 131, 132, 133 Pre_Frame_Return, 131 Pre_Scene_Command, 130, 131, 132, 133 Pre_Scene_Return, 131 precision, 197 Preview_End_Size, 125 Preview_Start_Size, 125 prism, 14, 199 pwr, 197 quadratic_spline, 42, 199, 200 quadric, 213 Quality, 136, 241 quartic, 212 quaternion, 197 quick_color, 236, 241, 271 quick_colour, 242 quilted, 265, 271, 272, 273 radial, 268, 272 radians, 150 radiosity, 137, 297 Radiosity, 137, 297 radius, 66, 219 rainbow, 106 ramp_wave, 258, 265, 272 rand, 150 ratio, 285 Ray-tracing, 11 read, 166 reciprocal, 197 recursion_limit, 300 red, 19, 154, 156 reflection, 82, 249, 251 reflection_exponent, 14, 252 refraction, 13, 232, 248 Remove_Bounds=, 138 render stream, 134, 173 Render_Console, 134 Render_File, 135 repeat, 275, 276, 277 rgb, 155 rgbf, 156 rgbft, 156 rgbt, 156 right, 17, 182, 183, 184, 185, 186 ripples, 78, 242, 244, 268, 272, 273, 296 rotate, 177, 179, 180, 183, 184, 185, 192, 218, 271, 278 roughness, 81, 251 samples, 285 Sampling_Method, 139 scale, 72, 153, 177, 178, 180, 271, 278 scallop_wave, 273 scattering, 282, 286 seed, 150 shadowless, 69, 218, 224 shearing, 179 sin, 150, 197 sine_wave, 273 sinh, 197 sky, 182, 183 sky_sphere, 97 slice, 196 slope_map, 242, 243, 258, 260, 261, 262, 264, 265, 268, 269, 270, 271, 272, 273 smooth, 149, 196 smooth_triangle, 208, 210 sor, 39, 55, 203 specular, 81, 250, 251, 252 specular reflection, 249, 251 sphere, 190, 201, 213 spherical, 13, 268, 286 spiral1, 268, 269 spiral2, 269 Split_Unions, 138 spotlight, 66, 67, 218, 224 spotted, 74, 259, 261, 269 sqr, 197 sqrt, 150 Start_Column, 122 Start_Row, 122, 123 Statistic_Console, 134 Statistic_File, 135 statistics stream, 134, 173 status stream, 134 str, 159, 167 strcmp, 150 strength, 190, 276 strlen, 150 strlwr, 160 strupr, 160 sturm, 149, 190, 199, 201, 203, 206, 213, 226 Subset_End_Frame, 115, 120 Subset_Start_Frame, 115, 120 substr, 160 superellipsoid, 52, 202 sys, 195, 240, 246, 255 t, 154 tan, 151, 197 tanh, 197 Test_Abort, 122 Test_Abort_Count, 122 text, 57, 205 texture, 13, 19, 70, 72, 78, 168, 180, 189, 228, 230, 233, 234, 236, 243, 248, 253, 254, 257, 271, 273 texture_map, 14, 85, 168, 230, 253, 258, 271, 272 tga, 195, 240, 246, 255 thickness, 83, 252 threshold, 190 tightness, 66, 219 tile2, 254 tiles, 86, 168, 235, 254, 261 torus, 60, 206 transform, 177, 180, 271, 278 translate, 177, 178, 180, 185, 218, 271, 278 transmit, 75, 154, 156, 232, 233, 240, 241, 282 transmit all, 240 triangle, 208, 210 triangle_wave, 265, 269, 270, 272 true, 148, 149 ttf, 205 turb_depth, 104, 290 turbulence, 72, 74, 83, 104, 153, 252, 271, 273, 275, 277, 278, 286, 290 type, 207 u, 154 u_steps, 28, 207 -UA, 126 -UD, 125 ultra_wide_angle, 183 union, 22, 215, 217, 224 up, 110, 182, 184, 186, 289, 291 -UR, 138 use_color, 247 use_colour, 247 use_index, 247 User_Abort_Command, 130, 131, 132 User_Abort_Return, 131 v, 154 -V, 125 v_steps, 28, 207 val, 151 variance, 187, 285 vaxis_rotate, 154 vcross, 154 vdot, 151 Verbose, 125, 134 version, 148, 169 Version, 129, 148, 169 Video_Mode, 124 Vista_Buffer, 138 vlength, 151 vnormalize, 154 vrotate, 154 -W, 116 warning stream, 134, 173 Warning_Console, 135 Warning_File, 135 warp, 271, 273, 274, 286 water_level, 195 waves, 78, 242, 244, 269, 272, 273, 286, 296 width, 106, 291 Width, 122, 125, 184 wood, 13, 72, 74, 242, 269, 272, 286 wrinkles, 78, 242, 244, 270, 272, 273 write, 166, 167 x, 21, 153, 211 y, 21, 153, 211 yes, 148, 149 z, 21, 153, 211  May 1999 POV-Ray 3.1g User Documentation Page PAGE317 45DE_`acde}~    "#=>?ABfg    ()CjkUjUjqUjUjwUjUj}UjUmH jUmHmH jU5BFtzeCI} 7 l  9 u  $  &$  $ $FtzeCI} 7 l  9 u * \ + _ / c E'[F XJ=z87o(X y*d TQJ%dCDEGH\]wxy{|    1 2 3 5 6 7 K L f g h j k    3 4 5 7 8 T U o jUjSUjUjYUjUmH jUmHmHj_UjUjeU jUjUAo p q s t $ % & ( ) ; < V W X Z [ n o % & ' ) * > ? Y Z [ ] ^ j Uj5 Uj Uj; Uj UjA Uj UjG UjU jUjMUC * \ + _ / c E'[F x$  &$  $ ^ o p   ) * + - . B C ] ^ _ a b  $%?@ACDtujUjUjUjUjUj#UjUj)Uj Uj/ U jUC!"#%&:;UVWYZ  %&@ABDEpqjUj|UjUjUjUjUj UjUjU jUE 78RSTVW|})*DEFHI_`z{|~789;<jUj^UjUjdUjUjjUjUjpUjU jUjvUC XJ=z87o(X y &$  $  x$ <YZtuvxy23467fg12356NOijkmnjUj@UjUjFUjUjLUjUjRUjUjXU jUC"#$&'78RSTVWz{XYstuwx  $j"$Uj#Uj(#Uj"Uj."Uj!Uj4!Uj Uj: U jUEy*d TQJ%mP &$  @$  $  x$ $%&()CD^_`bcst   34NOPRSno   01KLMOPj)Uj(Uj (Uj'Uj'Uj&Uj&Uj%Uj%U jUj$UCPrs)*DEFHIno !#$LMghiklj-Uji-Uj,Ujo,Uj+Uju+Uj*Uj{*Uj)Uj)U jUC%mP Iy> M !X!!!5"q"""&#d###($`$$$%d%%%&Q&&&'Y'''%(`((()W)))*=*{***(+n++,H,|,,,;-z---).n..../d///0I0001?1y111+2f222$3^333 4E44d/0JKLNOef  '(BCDGHWXrstwx7jK2Uj1UjQ1Uj0UjW0Uj/Uj]/Uj.Ujc.U jUE Iy> M !X!!!5"q"""&#d###($`$ &$  $  $  x$ 789<=hi   + , F G H K L _ ` z { |  !!!!!6!7!Q!R!S!V!W!h!i!!!!!!j-7Uj6Uj36Uj5Uj95Uj4Uj?4Uj3UjE3U jUj2UC!!!!!!!!""."/"0"3"4"O"P"j"k"l"o"p""""""""""""""""### #!#$#%#&#B#C#]#^#_#b#c###############Ͼj;Uj;Uj:Uj:UmH jUmHmHj9Uj!9Uj8Uj'8Uj7U jUA#$$!$"$#$&$'$>$?$Y$Z$[$^$_$x$y$$$$$$$$$$$$$$$%%%%%B%C%]%^%_%b%c%}%~%%%%%%%%%%%%%%% & & &&&/&0&J&K&jt@Uj?Ujz?Uj>Uj>Uj>Uj=Uj =Uj<Uj<U jUC`$$$%d%%%&Q&&&'Y'''%(`((()W)))*=*{*** $  x$  $ K&L&O&P&v&w&&&&&&&&&&&&&&&'''''7'8'R'S'T'W'X'x'y'''''''''''''(((( (#($(>(?(Y(Z([(^(_(|(}(((((((((jDUj\DUjCUjbCUjBUjhBUjAUjnAUj@U jUE((((((()))))5)6)P)Q)R)U)V)y)z)))))))))))))))*******6*7*8*;*<*Y*Z*t*u*v*y*z***************jIUj>IUjHUjDHUjGUjJGUjFUjPFUjEU jUjVEUC*++!+"+#+&+'+L+M+g+h+i+l+m++++++++++++++,&,',A,B,C,F,G,Z,[,u,v,w,z,{,,,,,,,,,,,,,,,--4-5-6-9-:-X-Y-s-t-jNUj NUjMUj&MUjLUj,LUjKUj2KUjJUj8JU jUC*(+n++,H,|,,,;-z---).n..../d///0I0001?1 &$  $  $  x$ t-u-x-y---------------..".#.$.'.(.L.M.g.h.i.l.m................ / /'/(/)/,/-/./B/C/]/^/_/b/c/////ǶjSUjRUjRUmH jUmHmHjQUjQUjPUjPUjOUjOU jUA///////////// 0 0 000'0(0B0C0D0G0H0c0d0~0000000000000000011118191:1=1>1W1X1r1s1t1w1x11111111111jgWUjVUjmVUjUUjsUUjTUjyTUjSUjSU jUE?1y111+2f222$3^333 4E4444,5g5556R666/7m77 &$  $  x$ 11111 2 2$2%2&2)2*2D2E2_2`2a2d2e22222222222222233333"3#3<3=3W3X3Y3\3]3t3u333333333333333444 4 4jI\Uj[UjO[UjZUjUZUjYUj[YUjXUjaXU jUjWUC 4#4$4>4?4@4C4D4c4d4~4444444444444444444 5 5%5&5'5*5+5E5F5`5a5b5e5f55555555555555555666660616K6L6j+aUj`Uj1`Uj_Uj7_Uj^Uj=^Uj]UjC]Uj\U jUC444,5g5556R666/7m777;8z88879v999@:::-;m;;;"<a<<<;====1>a>>>?F????7@p@@@AWAAA B?BBBB(CWCCCCDVDDDD)EjEEE FCFrFFFG\GGGHDHHHHIMIIII,JbJJJ KRKKKdL6M6P6Q666666666666666 77(7)7*7-7.7K7L7f7g7h7k7l7777777777777778848586898:8X8Y8s8t8u8x8y88888888888jeUjeUjdUjdUjcUjcUjbUj%bUjaU jUE77;8z88879v999@:::-;m;;;"<a<<<;====1>a>> &$  $  x$ 88888990919295969T9U9o9p9q9t9u999999999999999::9:::;:>:?:j:k::::::::::::: ; ;&;';(;+;,;K;L;f;g;h;k;l;jrjUjiUjxiUjhUj~hUjhUjgUjgUjfU jUj fUCl;;;;;;;;;;;;;;;<<<<< <!<?<@<Z<[<\<_<`<y<z<<<<<<<<<<<<<==4=5=6=9=:=c=d=~================jToUjnUjZnUjmUj`mUjlUjflUjkUjlkUjjU jUC====>>*>+>,>/>0>?>@>Z>[>\>_>`>p>q>>>>>>>>>>>>>>>?????$?%???@?A?D?E?n?o????????????????????@@0@jsUj>?F????7@p@@@AWAAA B?BBBB(CWCCCCDVD $  &$  $  x$ 0@1@2@5@6@N@O@i@j@k@n@o@~@@@@@@@@@@@@@@@@AAAAA5A6APAQARAUAVAlAmAAAAAAAAAAAAAAABBB B BBB8B9B:B=B>BjxUjxUjwUj$wUjvUj*vUjuUj0uUjtU jUj6tUC>B]B^BxByBzB}B~BBBBBBBBBBBBBBBCC!C"C#C&C'C5C6CPCQCRCUCVCcCdC~CCCCCCCCCCCCCCCCCCCCCDDDDD4D5DODPDj}}Uj}Uj|Uj|Uj{Uj {UjzUjzUjyUjyU jUCPDQDTDUDdDeDDDDDDDDDDDDDDDDDDDDEE"E#E$E'E(EHEIEcEdEeEhEiExEyEEEEEEEEEEEEEEEFFF F F!F"FFAFBFPFQFkFjUjeUjUjkUjUjqUj~Ujw~Uj}U jUEVDDDD)EjEEE FCFrFFFG\GGGHDHHHHIMIIII,J $  @$  x$ kFlFmFpFqFFFFFFFFFFFFFFFFFGGGGG:G;GUGVGWGZG[GjGkGGGGGGGGGGGGGGGGGGGG"H#H=H>H?HBHCH_H`HzH{H|HHHjĆUjGUjʅUjMUjЄUjSUjփUjYUj܂U jUj_UCHHHHHHHHHHHHHHHHHIIIII+I,IFIGIHIKILIaIbI|I}I~IIIIIIIIIIIIIIIII J J%J&J'J*J+J@JAJ[J\J]J`JaJ|J}JJJjUj)UjUj/UjUj5UjUj;UjUjAU jUC,JbJJJ KRKKKL7LjLLLM1M`MMM!NUNNNN O_OOOP &$  $  x$ JJJJJJJJJJJJJKKKK K0K1KKKLKMKPKQKrKsKKKKKKKKKKKKKKKKKKLLLL0L1L2L5L6LHLILcLdLeLhLiLzL{LLLLLLLLLj UjUjUjUjUjUjUjUj#U jUEKL7LjLLLM1M`MMM!NUNNNN O_OOOPPPPP-QcQQQRBRRRR-S_SSS TJTTTTCUUUUVVVVVW=WnWWWX/X_XXXX)YaYYYY,Z_ZZZZ&[Y[[[[&\Y\\\\!][]]] ^B^t^^^_A_y___,`l```aDadLLLLLLLLLLLMMM*M+M,M/M0M>M?MYMZM[M^M_MMMMMMMMMMMMMMMMNNNNN N3N4NNNONPNSNTNjNkNNNNNNNNNNNNNjUjpUjUjvUjUj|UjUjUjU jUjUCNNNNNNNNNNOOOOO=O>OXOYOZO]O^O{O|OOOOOOOOOOOOOOOPPPPP.P/PIPJPKPNPOPrPsPPPPPPPPPPPPP Q Q&Q'QjϙUjRUj՘UjXUjۗUj^UjUjdUjUjjU jUCPPPPP-QcQQQRBRRRR-S_SSS TJTTTTCUUUUVVV $  $  x$ 'Q(Q+Q,QAQBQ\Q]Q^QaQbQpQqQQQQQQQQQQQQQQQRR R R R R!R;RSXSj4UjUj:UjUj@UjÛUjFUjɚUjLU jUEXSYSZS]S^SSSSSSSSSSSSSSSSSTTT T T(T)TCTDTETHTIT]T^TxTyTzT}T~TTTTTTTTTTTTTTT!U"UUAUBU_U`UzU{U|UUUjUjUjUjUj"UjUj(UjUj.U jUjUCUUUUUUUUUUUUUUUUUVVVVV4V5VOVPVQVTVUVdVeVVVVVVVVVVVVVVVVVVWWWW6W7W8W;WXXXYXZX]X^XmXnXXXXXXXXXXXXXXXXXXXXYY"Y#Y$Y'Y(Y?Y@YZY[Y\Y_Y`YpYqYYj]UjUjcUjUjiUjUjoUjUjuU jUEYYYYYYYYYYYYYYYYYYY Z Z%Z&Z'Z*Z+Z=Z>ZXZYZZZ]Z^ZoZpZZZZZZZZZZZZZZZZZZZZ[[[ [![$[%[7[8[R[S[T[W[X[j?Uj°UjEUjȯUjKUjήUjQUjԭUjWU jUjڬUCX[i[j[[[[[[[[[[[[[[[[[[[[\\\ \!\$\%\7\8\R\S\T\W\X\j\k\\\\\\\\\\\\\\\\\\\\\]]]]] ]9]:]T]U]j!UjUj'UjUj-UjUj3UjUj9UjU jUC[[[&\Y\\\\!][]]] ^B^t^^^_A_y___,`l``` &$  $  x$  $  @$ U]V]Y]Z]y]z]]]]]]]]]]]]]]]^^^ ^ ^ ^!^;^<^=^@^A^R^S^m^n^o^r^s^^^^^^^^^^^^^^^^^^^____ _:_;_<_?_@_W_X_r_jUj UjUjUjUjUjUjUjU jUEr_s_t_w_x_______________ ` `%`&`'`*`+`J`K`e`f`g`j`k`````````````````a a a aa"a#a=a>a?aBaCaUaVapaqarauavajhUjUjnUjUjtUjUjzUjUjU jUjUC`aDawaaab\bbb4cncccd:djddd eDe}eee)fbff @$  &$  x$  $ Dawaaab\bbb4cncccd:djddd eDe}eee)fbfffgBgggg+hihhhiWiii j;jjj%kpkkl{llmsmm nQnnnn9ogoooBpppq>qnqqq rPrrrsWssst t^tbt|tduv=vv.wwyy6{`||}.~"qdvaaaaaaaaaaaaaaaaabbbbb:b;bUbVbWbZb[b{b|bbbbbbbbbbbbbcc-c.c/c2c3cLcMcgchciclcmccccccccccccjJUjUjPUjUjVUjUj\UjUjbUjU jUCccccccddddddd3d4d5d8d9dHdIdcdddedhdidddddddddddddddddeee e e"e#e=e>e?eBeCe[e\evewexe{e|eeeeeeeeeeejUj2UjUj8UjUj>UjUjDUjU jUEeeeeeff"f#f$f'f(f@fAf[f\f]f`fafyfzfffffffffffffffg g g gg g!g;gqnqqq rPrrrsWsss x$  &$  $ fooooooooooooooo p!p;pDJVuŦ5Eʧƫʫ̫ͫҫܫݫsxy~AI0J$j0J$U60J(0J%0J#0J$jU jU jUQrGƐ֓5L9KBFϟՠ֠ $CDPbwx$$l v (#$š 0JKSg͢΢ע +DEF@($$$l v (#$F֥.I 4P %)MIJOWYZ045:>@ACGHMQSTV[\afhiĮŮʮӮծ֮خ $&'29:?FHIKQRW]_`bijovxy0J$0J$j0J$U^ïįɯүӯد&().˰ҰӰذ߰IO`cdilnoqxy~ͱϱбױɲʲϲڲܲݲ"#(;=0J(0J$0J$j0J$U\ 4P %)MpͶf890HԻϽ߽[}P+f~|QGW2JN!9N$( g(=f $(3Dd=>EHN³ȳɳγԳֳ׳ߴ%'()345>QYZ_gijյֵ۵÷ͷϷзٷ>DEJPRSU\]biklnsty~øɸʸϸո׸ظƹ0J%0J$0J$0J(j0J$U\MpͶf890HԻϽ߽[}$ƹιϹԹܹ޹߹ !#$`efkprsx}~_yZ[qrs}~pzVXY^`bc{0J# jUjU jU jU6 jlU0J$j0J$U0J$PP+f~|QGW2JN!9N[abgmopU[Wh&5v}_cv|=@AFIKLNSTY^`agklquwx9:PQRcdjU5 jU60J$j0J$U0J$0J# jUjUP$( g(=f $(3DRqwDRqw{ZhU`,:mIU -1 Ay Hre'"..8&8\`7K_c5LRlrdw{ZhU`,:mIU -1dghmprs!8pxOV #$%*+-.;<^`jk*,67B] 0J#6 jU0J$0J$j0J$UY Ay Hre'"..8&8\`7K_cRS_`|"',2!"()^cz{~6;pu &'&,&3&&&&&1'8'e'j'''((3(>(C(N(X(](g(j{ U jU0J# jU0J$Zc5LRlr{)-fw?Pjr{)-fw?Pj(,rQ`sCZ`d       3 ; M S ~     G     |    + b   "Y 6Cdj(,rQ`sCZ`d       3 ; M S ~     G G     |    + b   "Y 6C$$3UaHL"*U,i!r#$%P())&)@)N)[)_)))))) **2*:*@*D*******+++ +++++,C,i,,,,,"-G-l----.*.8.H.N....F0a1i23(3X33333484]4444d$3UaHL"*U,i!r#$%P(g(r(w((((G+R+|++000011111111111111E;J;w;{;@AGALASAAAAA#B(B5d555555686<6P6x6666w7445>5d555555686<6P6x6666w77777777 8 858J8h8s8|888888N9]9k9{999999999:):=:E:T:i:o:s:8;=>"@ZAnBBBBBCC"C8CLC[CaCeCCCCCC DD0DDDSDYD]DDDDD"EIEpEEEE F0FWFdw77777777 8 858J8h8s8|888888N9]9k9{9999999999:):=:E:T:i:o:s:8;=>"@ZAnBBBBBCC"C8CLC[CaCeCCCCCCC DD0DDDSDYD]DDDDD"EIEpEEEE F0FWFFFFFGWFFFFFGEGkGqGGGGH)HOHuHHHHI5I\IIIIIJ$J;J|JJJ>KOKtKKKKKLMMN5QRRRRRRSS?SHSZSSSSSSSUWXZZZZ [-[1[3[Z[]__ma~bbdftg}ggggggiVkkkkll'l=lPlTllldGEGkGqGGGGH)HOHuHHHHI5I\IIIIIJ$J;J|JJJ>KOKtKtKKKKKLMMN5QRRRRRRSS?SHSZSSSSSSSUWWXZZZZ [-[1[3[Z[]__ma~bbdftg}ggggggiVkk'bbbddddkk#q$qTu`uxxizjzoz{z}z~zzz|||||||||^cdgq}ȆɆ{ghrs+;ژS\a j!U6 jU j%U0J$j0J$U jU jU0J# jU0J(0J$Nkkkll'l=lPlTlllll memmm.nwnnoPooo-pvppqq"qlll memmm.nwnnoPooo-pvppqq"q%q=qjscuuu4vwvvwKwwwxxAxUziz{7|O|c|y|||U}}}}}}z~~~~~~~~~~>LVo}Ѐ߁%C\`Bw<ą݅&*4FMd"q%q=qjscuuu4vwvvwKwwwxxAxUziz{7|O|c|y|||U}}}}}}}z~~~~~~~~~~>LVo}Ѐ߁%C\`Bw<ą݅&*4FMzMzÆdžʆ{]0gE "->OcɒJuȓ "&Ypה%;TX(:KZp4CכĝWء.1K/ɦ/Ӭ߬'e!7dÆdžʆ{]0gE "->OcɒJuȓ "&Ypה%;TX(:KKZp4CכĝWء.1K/ɦakHT/0̢΢Ϣ©éΩکԪݪ~߬ѯݯӸڸ۸AMKW  j0SU jBEU j<U60J$j0J$U j3U j}*U0J#0J$P/Ӭ߬'e!7;oڰް$KOkz7;oڰް$KOkzSioƳܳ\p@X^̵ "(e|ԶIrx|ϸa dĻ7TnǼ.Ljz%juƾ޾#OmпԿAdSioƳܳ\p@X^̵ "(e|ԶIrx|ϸa dĻ7TnǼ.Ljjz%juƾ޾#OmпԿA9EM|9EM|"2a-KizZr ,^| #$",=o*C\nP/35f8=GWi|d|"2a-KizZr ,^| #$",=o**+,PQ_k*+34.:VWkl!(-4 ططط0J( jU jU jÃU0J$j0J$U0J$ joUj0oU jaU0J#6j`U jUH*C\nP/35f88=GWi|.RVXkm\.RVXkm\Z.FQky5Sgk;!C[u8Q8a.X(RVEVz8^Fm+4Gd\Z.FQky5Sgk;!'&6=BI 7- .           l  s~oy}P S Y ^ ! !&!+!!!!!##& j2;Uj:U jU jU0J$j0J$U jeU0J$0J#6P!C[u8Q8a..X(RVEVz8^Fm+4GmGm 5](QzP t    O b o           ! 0 F ^ l p           ) - / b    0=Al,>Pbt4 $2?d 5](QzP t    O b o            ! 0 F ^ l p           ) - / b    0=Al,>Pbt4 $2?Clz&Sgz~K?Clz&Sgz~K_uyt d"#######%$3$A$\$$$$$$%<%O%S%j%%3&K&c&&&&&&&&j((((P))))))**&+B+H+z++++++++,,....// /$/c//// 0000171d11R2dK_uyt d"#######%$3$A$\$$$$$$%<%O%S%j%%3&&&++,,y,~,,,,,,,,..44x;;>>@@aFpFGGLLUMVM[MgMiMjMNNNNPPgTiTVVVVVVVGWMWOWVWXWaWfWnWuW{W|WWWWWWWWWWWWWWW0J$5 0J$55j0J$5U jU jU0J$j0J$U0J$ jImU0J#L3&K&c&&&&&&&&j((((P))))))**&+B+H+z+++++++++,,....// /$/c//// 0000171d11R2a2r2R2a2r222222333 4434I4M4n44444505R5X5\5;7E7_7w77777778-8Q8W8o8888888 9'9L9R9j999999p:;;;;;;;;)<N<^<j<<<<<<=$=T=^=x===l>>>>J?T?n???@@@@@AA-AGAlAdr222222333 4434I4M4n44444505R5X5\5;7E7_7w777777778-8Q8W8o8888888 9'9L9R9j999999p:;;;;;;;;;)<N<^<j<<<<<<=$=T=^=x===l>>>>J?T?n????@@@@@AA-AGAlArAAAAAAABC8CSC`CqCCCCCClArAAAAAAABC8CSC`CqCCCCCCCD(D@DdDjDDDDDDE E'ELEREmEqEFFF.GFHPHdHHHHIIIIJJ9JTJlJJJKHKKKK~LLLLDMUMNNPPPPQ!Q9QFQJQoQQQQQQQQRR(R8RORgRoRuRyRRRRRdCCD(D@DdDjDDDDDDE E'ELEREmEqEFFF.GFHPHdHHHHIIIIIJJ9JTJlJJJKHKKKK~LLLLDMUMNNPPPPQQ!Q9QFQJQoQQQQQQQQRR(R8RORgRoRuRyRRRRRRRS5SRRRS5S9SYSwSSSSSSSST)T9TITMTUU+Yi?iDiLiNiOikkk kkkkmmrrsssssstttttttvuuw0J$j0J$U0J$5 0J$55j0J$5U jU0J$6N]]]]]] ^^5^9^J^\^k^y^^^^^^__d)dgk0lAlQlallllllm[noopp p.p=pNpxppppppppppqqCqRq]qtqtqxqqqqqqqqrr*rBrFrss u-w`wwww'zzzzzzzrr*rBrFrss u-w`wwww'zzzzzzz{{~~~~~4<Lr#4AEbs$2Bl{΃͆ކΈhyȊ4MSWď D\#7Udwwwww)w*wwwwwwwwLyWyyy|||||||}}$}-}.}3}<}>}?}"/12}LRV\ΈψԈۈ݈ވaghmsuvpuv{)./49;<h60J$j0J$U0J$jU jUXz{{~~~~~4<Lr#4AEbs$2Bl{΃͆ކΈhyȊ4MSWď D\#7UuגUuגߒJ_٘EG_}LU'?Jbp}ɣEp,ͧyӨ ŪԪ-DJx|/G֮ͮ,D^u{n"1?dגߒJ_٘EG_}LhqrwÓʓΓד  7ABGQST_`emoqv}ח *қכGI¤ǤjkU jU0J#60J$j0J$U0J$WLU'?Jbp}ɣEp,ͧyǤȤͤҤԤդڤ-56;CEF_i¬ĬŬǬάϬԬ۬ݬެ #%&_`vwx!w}~jU jU0J$0J$j0J$UYӨ ŪԪ-DJx|/G֮ͮ,D^uu{n"1?M]mʹӴյj(8F[~аڰƱѱձx}~6Fܶ GUZh"-.3>@AIOPU[]^x60J$j0J$U0J$]?M]mʹӴյj(8F[nϺIS[aܻ 4^;EMSֽ*KYexѾ'-1Wm]5Orz$,2Q\m} d[nϺIS[aܻ 4^;EMSֽ**KYexѾ'-1Wm]5OOrz$,2Q\m} -Nf -Nf$2CWnA^04M_DZqx9]OS};]ek.>Px&d$2CWnA^04M_  !" !&,./CIQXZacmotv~sz<COVJQV]kt+0J#0J$j0J$U0J$\DZqx9]OS};]ek.>Pxx&5Hju&5Hju!%_.CTinar  1DYntxVtI_w':Qhot7Mid!%_.CTina+2DKn Wa\q=BCHMOPU_`eoqrV` $;J0J$j0J$U60J$[r  1DYntxVtI_ww':Qhot7Miwiw#CQdw$4Lat{},w.NWgy4MU[_(=A}$5Hh[    &BFf{d#CQdw$4Lat{},JKabcno !&023RYZ_fhikqrw},-2=?@p w       ghmrtv{60J$j0J$U0J$jeU jUX,w.NWgy4MU[_(=A}$5Hh[    &BFf{3Le~Lg~3Le~Lg~(59Yc(.2J"-7Qqu{iz     !'!>!F!L!P!"$$''(Z**+ +++D+Z+^++++,,G,~,,,,,,--,-L-i---d(59Yc(.2J"-7Qqu{$)*/467lsty%%'''''**11[1g1:4>4@ @CC6HBHNNsSySSSWW[[[[[[[__`0```ecockkrrny{y||||||| %'(jU jU0J# jU0J$j0J$U0J$6Tiz     !'!>!F!L!P!"$$''(Z**+ +++D+Z+Z+^++++,,G,~,,,,,,--,-L-i-------(.8.E.Y.v.-----(.8.E.Y.v..../)/9/A/f//0w235 667F7y77 9:;J;h;;<<=?@&@1@I@_@c@@@@AA*A:AJAqAAAAAA BB.B4BRBVBBC D+D9DIDYDDDDDDD EE)EXEEEEEEEF"F6FwhwwwxExIxDybz|}~~attttu?uMvXvwvvvw>whwwwxExIxDybz|}~~aςӂ8<̓܃eL̆ 2Dh· #6<@)ڋNPn1&Ď֎/7EX^b%4Q`ndaςӂ8<̓܃eL̆ 2QVNOCNRSkv|%&+356tyzABXYZ]^V^ޤ%-5=DN jtU jH]U j?U j"Ujp"U jU0J$ jNU jVU j_U0J$0J#j0J$UI2Dh· #6<@)ڋNPn1&ĎĎ֎/7EX^b%4Q`nOWex~OWex~_RTwޖ0BqИ)/=H^n~ϙ0\ךݚdlSbayàԠ "<Pw{١ݡ7;hp:Y JRcd_RTwޖ0BqИ)/=H^n~ϙ0\ךݚdlSbayàԠԠ "<Pw{١ݡ7;hp:Y JJRc>W08Ilp}@HY|ߩ>W08Ilp}@HY|ߩGXc &IXjx|~հ)FUguղ*.6Gdsڳ[rD:F8h5MXs/fԿ ByUdNOT^`aBLMR\^_ĭ̭έϭ  #*+079:ISz|} '()@Aҵٵڵߵ  JQRW^`aINOTY[\afgljU jU jU jU0J#0J$0J$j0J$UTGXc &IXjx|~հ)FUguղղ*.6Gdsڳ[rD:F8hlqst&2067<BDEOP+$TUklmtu-:]f!"./0ABj U jU jUj U jU jU jcU0J#0J$j0J$U0J$K5MXs/fԿ ByUmyUmy#A]yOQe?(.:IUh-Z;AE1 h 3Fdt 8e#+M@&*Wfd#A]yOQe?(.:IUh--Z;AE1 h 3Fdt 8e#+M@&35KPcl49:?DFGPQ^_`ejlmnJMhm "#     ! & 1           JKVW 0J# jU0J$j0J$U60J$Y&*Wf#8@PVtJ)^#8@PVtJ)^cx&0BJj!E`p:bzu[s/9o#Urvd^cx&0BJj!E`p:bzu[s/9o#Urv5P5o5P5oq |     4 N f 0Nf\t' !!"'#@###)$i$$%&7(D(((()Q)n))+*7*k*****+#+N+y+++++,v,,- /A/v//0/0U01 212z22J3335]5j5555 6 6dq |     4 N f 0Nf\t'<>?DFHINPQVXZ[(*+0245Cfsuv{} %WX]_abglm()9:b l =!A!!!!!!!0J# jU60J$0J$j0J$UY !!"'#@###)$i$$%&7(D(((()Q)n))+*7*k****!!N"X"X#b#r#t#u#z#|#~####V$b$m%y%z%%%%%%%%%%&&&&,,,,///////12M4N4P4Q4 5 5 55]5e5i5p5w5~55555555555555555555 66*6/616365686<6=6M6U6]6b660J$0J$0J#j0J$U\**+#+N+y+++++,v,,- /A/v//0/0U01 212z22J33335]5j5555 6 66L6M6^6777<7=7A7a7b7f77777 @׀הX$$Tl$$ 66L6M6^6777<7=7A7a7b7f7777777777788888::::::::=-===\=]=k========== > >>&>'>.>H>I>P>h>i>>@BCD"G!HiIKVL`M|MMM3NNOO0OOOPOgOOOOOOOOO P%P&P5PNPOPRYTjTTTdb6i6m6u6|6666667767;7=7@7V7`7b7f7777777::::::::::::::::; ; ; ; ;;;!;";';);+;,;/;;;;;;;;;;L<R<S<Y<<<<<<<===-=;===Z=[=]=i=k=========0J$j0J$U60J$]777777788888::::::::=-===td$$Tl$$$$$Tl==\=]=k========== > >>&>'>.>H>I>P>h>i>>@Bܼܰ|t܈܀$$Tl$==========> > >>>>$>&>'>*>->.>6>D>G>H>I>L>O>P>X>d>h>?????????????????B@M@@@@@@A5A?AAAKAMAWAAAAAAASB^BoB{BBBBBBBBBBBCCCCCCCCC0J#0J$j0J$U60J$\CCCCGDTDXDcDDDDDDDDEEEEEEEFFJJJJ&J(J)J*J-J1J4J5J:J=J?J@JCJHJSJTJYJdJfJgJhJkJoJrJsJxJ{J}J~JJJJJJLLL(L-L;LLLLLMMNNNNNNNO.O/O0Oj U0J$j U jU0J$6j0J$UTBCD"G!HiIKVL`M|MMM3NNOO0OOOPOgOOOOOO$$Tl $0OMONOPOcOfOgOOOOOOOOOOOOOOOOOOPP P PP$P&P)P*P.P1P4P5P=PMPQ&Q'Q,Q9Q;Qg?gDgGgIgJgLgOgPgUgXgZg[g`gcgdgiglgngog0h2h3h8h:hhChEhFh0J$j0J$U60J$]FhKhMhOhPhQh}hhhhhhhhhhhhhiii.i/i8i:i;ir@rArBrZr]r^rcrfrhriryr|r}rrrrrrss s%s0J$j0J$U0J#60J$\mmmmmnn#ppsttgvuvvv@wIx`xzxxxxxx܄t$$Tll L$%s/s1s2s=s@sAsFsIsKsLsu#uuuuvvvvvDwNwwwwwwwzxxxxxxxxxxxxxyyyyy:y;y=y?y@yAyjykymyuyvywyyyyyyyyyyyyyyyyyzzzz"z#z=z@zFzMzNzSzZz\z]z`zdzfz60J#0J$j0J$U0J$\xxxxxxyyy*0J$j0J$U60J$\/05abg͞ΞҞ56ޠڰhl$$Tll $ޠߠ#$(XY]z{'Ƨk&7MfT$$$TlMN)Y]jkȥɥΥܥޥߥĨƨǨʨΨѨҨרڨܨݨ*+,CDک@AWjUjwU jU60J$j0J$U>*0J$QWXYrs{ªê٪ڪ۪7HLMaegimnvd JZ[`prsty|~گ36PSnz{|ðİ0J#6jU0J$j0J$U0J$ jUjqUSfgnحf236OPStx$$TlU 5$$$Tl5 Ef236OPSmn|CDγζ϶ԶԷٷLMRbch¸Ǹa"6QRZvwӾݾ BCǿ}%BC &'.HI QdSmn|CDγζ$$Tl4U 5$$TlU 5$ABHUV[hjkp{|ʶ˶϶ҶӶԶܶ tuԷٷMRch¸Ǹ ͺκ"jUjkU jU0J$j0J$U60J$Uζ϶ԶԷٷLMRbch¸Ǹ|X$$Tl4$$$Tll La"6QRZvwӾݾ B$$Tl }$$Tll L$$$Tl4"156LPRUYZbquwx}*6>Aݾ  (<A  $%-=ACDIXZ\acef*.37| z0J$60J#j0J$U0J$ jU60J$XBCǿ}%BC $$Tl L$$$Tl } ')-.6CG<@()?@AWX U`9KLMn DXYZjeU jU0J$j0J$U0J$6X&'.HI Qb9Mm܈p$$Tl$$Tll $b9Mmn CDZ0Y,ViSV347PQTef?E/]oALi|01Ecdydmn CDZ0Y$$Tl4 $$$Tl   "$%2378ov-?-8?NOTcefjlmrtvwRW !-1<jl0J#60J$0J$j0J$U\,ViSV|xx$$Tld$   BR`rsxSV47QTfpqv"#(9;<  #%&hz{0J$j0J$U0J$^347PQTef?E/]oALitT$$Tld$/ iz{|1CDEdwxy+-.;<@AoyQbchy{|,>m~./ 0J$j0J$U60J#0J$\i|01Ecdy0ܼ$$Tl L$0<=q +,:\|}'6OPR%&(+IbcedegUVFd}~jvya4 H  sd<=qDTp$$$TlDT #/RWEFVW/1CDI[]^,-/0238::KLQbdegxy~56PR0J$j0J$UjU jU0J$0J#X +,:\|}'6OPRD$$$Tll L$$Tll $%&(+IbcedegUVٔx$$Tl4l L$$Tll L$$&(HIce eg,gxy~@RSfo"cd~ PQ01GHI]^agj_U jU jU50J$j0J$U0J$UFd}~jvya4 H  |$$$Tl4l L$gh{|GH^_`tu4 ? @ A Y Z H O P Q e f                   + ,  ')67<IKL60J$j0J$U0J$5jU jU jUT s  ()R'(8Rب|hب|pج$$Tl $  ()R'(8RSWrs#$Q}~=>Nefj&'7TUi23C`au*NO`~dLMQR(+,14678@QSW_qs "$349HJKLPQ~0J$j0J$U60J$]RSWrs#$Q}~=>h$$$$Tl >ABGJLMNVdfjr"%VX\_'267OSUXY^acdhin~0J$50J$56OJQJ0J#60J$j0J$U0J$V>Nefj&'7TUit$$TlE ]$$$Tl $23C`au*NO`($$$TlE ]$3>BC[_adejmoptuz *O[_`y} 0J$66j0J$6U0J#0J$50J$j0J$U60J$56OJQJ0J$N`~<=Ruv#$Kq48$$$TlE ]$2;=Rv "#$016BDEKepr  $%*=?LPQRZ[`h0J$560J$56OJQJ0J#0J$j0J$U0J$V<=Ruv#$Kqr%QRq)lmM  B C N       ##$% %3%4%8%J%K%L'Q'''''''(((<(=(B(\(](_(((((((((((( ))?)V)dqr%QRq)lm|H$$$$TlE ]hjkq$()gkmpqvy{|]klm|  "%')-.@Ex}]`d    C F 0J$50J$60J$56OJQJ0J#0J$j0J$UVM  B C N       ##$%|$$Tl$$$TlE ]$F J N         !!!!!!!"""""""*#,#% % % %"%2%4%6%7%8%@%H%I%O%V%W%\%c%e%f%g%h%s%u%v%{%}%%%%L'M'O'Q'''''''((=(>(@(B(](_((((((()')()-)6)8)9):)>)?)W)Z)0J$560J$j0J$U0J$\% %3%4%8%J%K%L'Q'''''''(((<(=(B(\(\$$Tl49$$$Tl4D$\(](_(((((((((((( ))?)V)W)g)z){)H`$$Tl-$$$$Tl49V)W)g)z){))))E+`+n++++++++++,, ,4,5,:,g,h,z,,,,,,,,,,,,,---)-*-/y1M4=556999 : ::2:3:7:[:\:n:::::::::!>K@a@p@@@@@@@@@@ A!A&A@AAAYAvAwA}AAAAAAAAdZ)[)`)c)e)f)g){))************** + +"+#+$+-+.+`+i+m+n+++++++++,,, , , ,2,3,5,8,9,:,e,f,h,u,y,z,,,,,,,,,,,--y//////////////// 06jYU jU0J$0J$j0J$UX{))))E+`+n++++++++++,, ,4,5,:,\$$Tl $$$Tl-$:,g,h,z,,,,,,,,,,,,,---)-*-/y1M4=55hlhl$$$Tl $ 0 00!0#0$0%0&0*0-0.030608090:000s1x111115555555555555555555666 6666666688'8(8)8-8.85868L8M8N8R8S89999 ::3:7:\:i:m:n:::::==jSUjU jU60J$0J$j0J$UU56999 : ::2:3:7:[:\:n:::::::::!>K@a@p@ؠؤ؈،$$Tll L$==============>>???? @ @@@@@@"@%@'@(@9@I@a@k@o@p@@@@@@@@@AAAA!A$A%A&A.A>A?AAAUAXAYAwAyA|A}AAAAAAAAAAAAAAA'B*B>BLBOBPBiBlBqByBBBBBBB60J$0J$j0J$U]p@@@@@@@@@@ A!A&A@AAAYAvAwA}AAAAAAAAp ܀ܬ܌$$Tl< "$AAA&B'B*B=B>BPBBBBBBBCC+CGCHCLCfCgC3E]FG7IJLRMMO)QSS!TUUUUUUV-V.V0V2V4V5V7V9VBPBBBBBBBCC+CGCHCLCfCgC3E]FG\HD|$$$Tl< "BBBBBBB C CC)C*C+C9CFCHCJCKCLCTCdCeC)E1EEEEEFFFFFFF!F"F'F)F+F,F;HJHKHPH_HaHbHcHdHoHrHsHxH{H}H~HHHHHHI I"I.IzIIIIAJIJJJJJJJJKKKK LLLLLaLcLqLvLVPeP0J$j0J$U0J$6]G7IJLRMMO)QSS!TUUUUUUV-V.V0V2V4V $$Tl4 ] -$$ePfPkPzP|P}P~PPPPPPPPPPQQSSXTgThTmT|T~TTTTTTTTTTTT&U'UUUUUU(V-V.V0V5V7V=V?VEVGVOVQVZV\VeVgVqVsV}VVX X,Y2Y3Y8Y>Y@YAYEYPYRYSYXYZY\Y]YYYYYYYYYYZZ jU60J$0J$j0J$U[4V5V7V9V\X\^,^-^2^A^C^D^E^J^T^V^W^\^^^`^a^e^^^<_=_S_T_U_s_t____________```)`*`6`8`3aEaaabbb&b'b3b4bJbKbLbSbTb`babwbxbjZUjYUjYU5;0J%jXU jU0J#0J$60J$j0J$UJxbybbbbbbbbbbbbbbbbb+r,r;rfJfPf[f_fefmf{fffffffffff$deff*f/f5f>fJfPf[f_fefmf{fffffffffffffffff gggg+g6g:g@gEgKgQg\gggrgxgggggggggggggggggh hhh'h0h9h=hBhHhPhVh[hahnhyhhhhhhhhhhhhhhhiii i1i5iBiGiPidfffffff gggg+g6g:g@gEgKgQg\gggrgxgggggggg$ggggggggggh hhh'h0h9h=hBhHhPhVh[hahnhyhhhh$hhhhhhhhhhhhiii i1i5iBiGiPiTiZifijiuiiii$PiTiZifijiuiiiiiiiiiiiiiiiii jjj#j'j7j@jHjWj]jjjrj}jjjjjjjjjjjjjjjjjkkk'k.k4klGlKlYl]ldlrlul|llllllllllldiiiiiiiiiiiiii jjj#j'j7j@jHjWj]jjjrj}jjj$jjjjjjjjjjjjjjjkkk'k.k4klGlKlYl]ldlrlul|lll$lllllllllllllllm mmmm%m1m8m>mBmKmPmXmbm$lllllllm mmmm%m1m8m>mBmKmPmXmbmfmjmnmxm~mmmmmmmmmmmmmmnn nnn"n2n6nAnUn`ngnnnrnwn}nnnnnnnnnnnnnnnnnn oo o$o-o4o>oFoNoXo`odoiotoxooooooooooooooodbmfmjmnmxm~mmmmmmmmmmmmmmnn nnn"n2n6nAnUn$Un`ngnnnrnwn}nnnnnnnnnnnnnnnnnn oo o$o-o$-o4o>oFoNoXo`odoiotoxooooooooooooooooooo$ooooop pppp"p,p6p?pHpVp[p_pjpupzp|pppppppppppppppppqqqq#q/q5q;qAqFqOqUqWqYq]q_q`qr#r ssst+tttttu"v8vEvVvZvvv=xz){0{S{Y{e{s{{{{{{{{ |!|7|K|i|j|y|||}}}dop pppp"p,p6p?pHpVp[p_pjpupzp|pppppppppppp$ppppppqqqq#q/q5q;qAqFqOqUqWqYq]q_q$_q`qr#r ssst+tttttu"v8vEvVvZvvvE$$Tl\)z v=xz){0{S{Y{e{s{{{{{{{{ |!|7|K|i|j|y|||}}}}$}'&{{{{| ||!|"|#|2|3|4|7|8|:|H|K|h|i|j|y||||||||||||||||||||}}}}}}}}"}$}-}.}/}6}7}>}?}F}G}N}O}V}W}^}a}h}l}s}x}}}}}}}}}}}}}}}}}}}}}}}}}}~ ~~~;0J$0J%b}}$}.}}}}H~~~JE&`t,:gl͂߄]Sf|܉ċ$@AIbc[*+4QRZˏ 34<cd  uŒѓ}d$}.}}}}H~~~JE&`t,:gl͂'8h'&~~~#~(~/~0~7~;~B~C~H~P~[~\~c~k~r~s~z~~~~~~~~~~~~~~~~~~~~~~~~~~~~~!")*15<=DEJNUV]^emtu|0J$0J%c$+,38?@EPbcjyǀ΀Ҁـ܀ &;<=MN`qst,:;BDKLSU\]dgklqr LTЃуj[U jU6;0J%0J$\у׃؃#xz҄ӄԄۄ܄foz{|&'(;<ÊĊڊۊ܊-ċ$AI[s+4RZˏ 4<d5js]Uj\Ujy\U0J$0J%j[U jUS߄]Sf|܉ċԔ$$Tl4D$'&$@AIbc[*+4QRZ$$Tl4$$$Tl4D$ˏ 34<cd  uŒt$$Tl$$Tl4$d}Ĕ˔͔Ԕٔ  GIJOQST–ÖȖ˖͖ΖЖӖԖٖܖޖߖ  dijotvw]bӘؘ٘ޘ0J$j0J$U0J$5]ѓ}ʕݕ)FEFSܢ'&ʕݕ)FEFSܢ\&[k}ު8hŬ lT4gl4T7#hҺ5_н"!CKn|0DJZtDd ԙٙך\aٛƝǝݝޝߝ#*+079: !#$%(367<?ABE18aijowyz.5EMġơǡ 0J#j]U jU0J$j0J$U60J$WYa "$%'*+03568;<ADFGIKLQSUVX\]bfhiotuzդڤۤ  $%*0235FGL]_`fwx}ƥ! 0J(0J$j0J$U0J$]\&[k}ު8hŬ lT4gl4T !&'\]ު   "568<=BFHIM[\'1hlmrvxy}¬ìŬʬˬЬլ׬جެ-2VWeo0J$j0J$U0J$^   &'IJRSlstyȮͮ¯ïȯϯѯү֯23@RT^_dmopqr 124BCHVXYZ[su17Pc6jm^U jU0J%0J$j0J$U0J$Wcegjkpsuv|˲̲lwx}³%'(,./4689[\rstƴǴ̴ѴӴԴش  478=@BCGWXj^U jU60J$j0J$U0J$X )*./<=QRTWX]`bcituz{ƶ϶жضٶ67:;@CEFLqr60J$0J$j0J$U]T7#hҺ5_н"!CKn|'&#'(-1348ո۸$'ڹ۹TZʻл589>ACDHPQqrz{¼Ƽȼ#%_efkqstxͽνнԽսڽ޽ 0J$j0J$U0J$6] %(*+/:;^_gh "&',023;JLQS !().578<FG|}'(78NOP`a!'DE[j_Ujg_U jU0J#60J$j0J$U0J$P[\]pq{Kn|+,-013ADJZ[bcjkrst"#*+23:;BDJ\0J$0J%j`U6 jUja`UY0DJZtDib&'\   +5 FPabxyz.AOV #$?@EF (+=D;AFLvzjaUj[aU jU0J%0J$Zib,JiPi>i ()?)YDv $6KSZi&7E\t@t*Adsd,JiPi>i ()&' %')*,./4689?ABGIKL$1   $&'_`afgijlm0J$0J$j0J$U^)?)YDv $6KSZi'&mnstvw}~    ^_abdeklmrsuv "#noDJKPVXY_pqvwW`v0J#0J$0J$j0J$U]  !#$*12CD,/;>CF  jbUjUbU jU60J$0J$j0J$UU puZdinoy "&6EHIJX\`abptxyz ").;@FT[ctz60J%jOcU jU0J$j0J$U0J$W&7E\t@t*A&'zCDZ[\no )   EJKPUWXIN"#&18<HOTaflmz250J$j0J$U60J$jcU jU0J%WAds#f 03N<g;K '&#f 03N<g;K  1  S e 14H-;S 7?jpJRey#n~IxA$KBU' ; Z u !!"&"K"""#$&%&''/(K**d56;>@ACHINSUVX\]bfhikqrw}016>@A()*/13:EFGLMT^ . 2 D    jdUjIdU jU0J%0J$0J$j0J$UT " # ( , . / [ ` l w x }                         W g     `h19psCFVk  MTjCeU jU0J$j0J$U0J$Y  1  S e 14H-;S 7?jjpJRey#n~IxA$K'&Raevy  #*2389>?FMUV]dln_aij  !"#23UV[cef; D O P Q W X Z a l m n u {    [!\!r!0J$j0J$UjeU jU60J$0J%WKBU' ; Z u !!"&"K"""#$&%&''/(K**+1+P+o+++'&r!s!t!!!$$$$$$$$ % %%%%%&%)%*%/%2%4%5%9%X%Y%%%%%c&j&&&&&&&&''' '"'''''((/(2(3(8(;(=(>(F(((((N)O)))))a*b***,,,,#,%,&,*,8,9,,,--60J$j0J$U0J$ jUj=fUX*+1+P+o+++++,-A.0/~0031D1u1112$2E2Q2\2n233Y5x5556`666778=8h88v9::8;O;;;;;;<<7<O<R<<<{>?@@@@@@@@@@AA AAA A!A)A5A=ADAEANAWA^A_A`AB'CmCCDCEESFBGRHI6IJd+++,-A.0/~0031D1u1112$2E2Q2\2n233Y5x5556`66'&-- -----.-/-r-s------.".0.A.G.H.M.S.U.V.Z.h.i..../=/>/T/U/V/e/f/0 0=0>0T0U0V0i0j0111111111111111111111111112$2%2/20212<2=2B2C20J%j7gUjfU jU60J$0J$j0J$UTC2D2Q2X2\2n2:3L3n3o333333L4V4_4i47*7.7:70:1:G:H:I:\:]:< =>>I?J?@ @ @@@@@z@{@@`AAAAAAAAAAAAAAA5BDBEBJBYB[B\BBB-F1FMFQFGGGGGGGHH0J#0J$j0J$U6j1hUjgU jU0J%0J$R66778=8h88v9::8;O;;;;;;<<7<O<R<<<{>?@@@@@@@@@@@AA AAA A!A)A5A=ADAEANAWA^A_A`Atpڐl$$Tl  $`AB'CmCCDCEESFBGRHI6IJJKK:KUK]KKKKGLeLLMMM'&HH HHHH(H)H?H@HAHNHOHbHhHHHHHHII3J4JJJKJLJfJgJnJoJJJJJJJJJJJJJJJJK#K$K/K0K7K:K@KAKLKMKUK]KbKcKjKpKqKxK}K~KKKKKKKKKKKKK0J%j%jUjiUj+iU0J$jhU jU0J$j0J$UNJJKK:KUK]KKKKGLeLLMMMNN9NdNNNNN2Oh?hhhiijjj$jQjWj!k)kkkll@lHllllllll9m?m@mEmKmMmNmmmmmmmmn0J$j0J$U0J#0J$\Zghh1i&jjklllnnn o4oJq_qqqqqrsu(uu v)vv'&nnnnnooqqqqqqqqqqqr rrr!rkrurrrrrrrrssss#s%s&ssssssss"t(ttttttttttttttttt>uDuEuJuPuRuSuuuuuuuu vvv)v/vEvpvvv6;0J$j0J$U60J%0J$jlU jUUvvwv|vvvvvvvvvvvwwwww x xx!x2xGxNx^xbxtx{xxxxxxHyWyh|~|||||||||||~~~~~~~Q~V~W~\~a~c~d~h~n~o~t~z~|~}~~~~~~~~~~~~  &-4:0J%0J$jlU jU0J$j0J$UX)vvvww!x2xcxx{|}>}Y}{}}}}~~ 4 6^ڃUj}Ԉ)BGJɉՉx|ˍLnԑqfȗ%:\ۚ3FS_fu{ATamsОdvvww!x2xcxx{|}>}Y}{}}}}~~ 4 6^ڃ'&:P̀*+@C;@AFKMN Z[qrsHOPU\^_aghmsuv{DLMRZ\]j nUjmUjmU jU0J$0J$j0J$U0J%QUj}Ԉ)BGJɉՉx|'&]}ƈ͈Ԉ#%&;FGLWYZ͋Ջːϐ%-.3;=>ԑܑݑ+3גޒߒ  ,3CDZ[\lm ,jnU jU60J$j0J$U0J%0J$WˍLnԑqfȗ%:\ۚ3'&!"AHX`Ŗ˖̖іזٖږ'#fghlmnЛԛĝȝɝԞڞ۞60J%0J#0J$joU jUj0J$U0J$U3FS_fu{ATamsОן"'<_áʡ+'&#&',/12Ɵǟҟ֟ !)4zТӢ ,016:<=&+,7<KQR\]_kqtv}~60J%0J$j0J$U0J$\ן"'<_áʡ+SYvU<Kvg~"Ǫت 1^zѫC_gάl}Pcw 8ZoݴHiߵ,5Hqzm>ӽ;ݾ¿ÿȿӿؿٿ޿d+SYvU<Kvg~"Ǫت 1^zѫC'& DHINRTUrǥԥĦȦҦ.2J  dims).28lr.349>@A}0J$j0J$U60J$0J%\C_gάl}Pcw 8ZoݴHiߵ'&quv{ůKOôĴɴϴѴҴӴٴݴ *+0;=>?EGPQV^`abhiou23joU jU0J$j0J$U60J$0J%W,5Hqzm>ӽ;ݾ¿ÿX$$Tl F ? $>DEXY23   !"  "#ӽ۽ܽݽÿȿٿ޿*/DI\alq *016<>?@JKL\]opqz{j0J%0J$j0J$U0J$ jU5Yÿȿӿؿٿ޿ $)*/>CDIV[\aXۀlh`@$$Tl F ? $ $)*/>CDIV[\afklq{*fb2BC$O\` 3Lex8bb9ADy+e ?Ddafklq{*T``&$$Tl F ? $*fb2BC$O\` 3Le&'jq>BCHLNOU[\agijlsty   ./MUVj~pUjpU jU0J$j0J$U0J$60J%TV[cefjpqv|~6:WXnop/BXn~WjL`,-jqU6jxqU0J%jpU jU0J$j0J$U0J$Pex8bb9ADy+e ?D-.=>]_df}~$/&0GNH\{"*NOefgHPfn}~}"1jrU6jrrU0J$j0J$U0J%0J$0J# jURD*`fjOM_pI/*`fjOM_pI/^ #z6F^u&] 1K_6BWil8HjmtJ, %      )    + Y c n  d^ #z6F^u&]'h'&45:@BCFLY^cou~ &./9:FGXYZ]cdno{|0J%0J(0J$j0J$U0J$\GQU^$)+,RWj ) / 0 5 ; = >                              ! ' ) / 0J(jlsU jU60J$j0J$U0J$W 1K_6BWil8HjmtJ,, %      )    + Y c n       \qz 'h'&/ 4 = B . 7 L ] }   +        !')* *+<=>AGHRS_`qrtz'(#,-2;=>=FGLUWXZ`aflnoqjsU jU0J%0J$j0J$U jU60J$0J(S      \qz  Atfku <qw>^ap+7D[FbgAIerIXA }   u""&& &8&M&''#'5'8'(d  Atfku <qw'&qvw|  ().79:<BCHNPQSXY^cefkqrw}MTX_`elnoIPcer}#,0J%60J$j0J$U0J$\>^ap+7D[FbgAIerIXA }   u""&& &8&M&''&,3;<IX`akrwx     " ) 4 5 < A K L [ b j k x }    !!D#L#M#R#Z#\#]#_#d#e#j#o#q#r#t#v#w#|#~##########z%}%~%%%0J$j0J$U0J%0J(0J$\%%%%%%%%%%&&&&&&&&&&&&&&&&'''''''''((2)9)))))**********,,b,e,|,,,,- ---[-b----------P.Y.Z._.h.j.k........./%/ jftU0J$0J$j0J$U\''#'5'8'())*++++=+@+---._0u114j5&6;666699:())*++++=+@+---._0u114j5&6;666699:<>>7@)B~CCCCCCCCD6FAF%IKLL+L@LRLUL%MNOQQQQQQRR2RIRLR SSoTVxWY[{\]x_eagaaaaaaaaaa4b5bbb5cdefijDk\kkkkkld%/./X/////////////000!000501111111r2y2z2222222222222233z4444444444444444444444555555?5H5|5555555555555555550J$j0J$U60J$]5555566 6666V6X6Y6^6`6b6c6h6m6n6s6x6z6{677777!7"777777777777777777778 888x88888888888888899 9%9U9W9\9a9z999999999::: :J:S:::0J$j0J$U0J$^:::::::;6;;;d;i;;;;;{<<<<<<<<<<0>7>8>=>D>F>G>K>Q>R>W>]>_>`>>>>>>>??!?0?@@ @@KAPAQAVA[A]A^AcAiAjAoAuAwAxAAAAAAAAAAAAAAACCCHCMCRD]DaDlDDD E EE60J$0J$j0J$U]:<>>7@)B~CCCCCCCCD6FAF%IKLL+L@LRLUL%MNOQEEEEEE F FEFJFKFPFUFWFXFFFNG]GGGJJKKLLLLLLLNNXNI%9~ɆʈxfȒ=EUt˘ΘV!#ܜZ_dll\momnnnnooo ppp1pI&'HyVyWyyyyyyyyzz-z.z/z6z7zzzzzzzz9{:{P{Q{R{X{Y{{{{{{{{}}%}&}'},}-}`afjlmǁ΁0J$0J$j0J$UjU6jUjUjUj#UjUj)U jU jUB<>IPXY`adlmw…̅$9@GNU[bho~Ɇ͆ֆ׆܆$,./ъ60J$0J(0J%0J$j0J$UZI%9~ɆʈxfȒ=&'ъي2:ŋƋˋыӋԋ17NV(016>@A%&|jrsx'0ƕȕɕ͕ҕӕؕݕߕ~!")1?BCHK jUjU jU0J(0J$j0J$U0J$6T=EUt˘ΘV!#ܜZ_Ş27'h'&KMNYZ_deop{˝;?@EIKLy˟̟؟ٟ2>CPĠ%&+356 jU60J$ jU0J%0J(0J$j0J$UVŞ27,ڢܢޢv&;QaXͫwo> \ 5'0U\@6delsz{ d,ڢܢޢv&;Qa'h'&¢âڢܢݢ mt=ABGKMN?KLQ]_`uvĥ˥Υեإߥ!%,-6:FGLPQaɨUXY^acdfijort jЬU jOU0J$j0J$U0J( j)1U0J%0J$VXͫwo> \ 5'0U'&tuwz{ȭ˭̭ѭԭ֭׭>?UVWabituzкۺ%0 %)34560J#jzU jU0J$0J$j0J$UW`lp}GTUZgij%'0<CPUbchoxy| &+25<@GKRW\_fjqu|0J%0J(0J$j0J$U60J$[\@6delsz{Xdt$$Tl l $$Tl4$' ~IPQ y<I SXY^cef%08@epwDMNS\^_ ')*xez{0J$j0J$U0J$0J(]{.CDILNPUY[]beginxz|  !"ORTX"%0J(0J$j0J$U0J$] %-./C``p$$Tl4$$$Tl l $ %-./C"#(=>Dabfrsx 459PQZ}~;A&-5}b#367_d%*.9C  !#(;<>D_`bfpqsx  2359NOQZ[xz{|EJKPj0J$U6H*0J#560J(0J$Y"#(=>$0t@<LlĐ$$Tl$$$Tl4>Dabfrsx 4DThHXx$$Tl$459PQZ}~;A&-5}p'&$$$TlPUWX-5:GIYZ[} } )+,  !#$cp$%*/12 '(12CDEFOPZ[jk0J(0J%0J$j0J$U0J$[b#367_Ejt&'Ejt3r*6h+7q :f  7 k 3   $ W _    t[i/.S]qt'9PUldkmqtu#3   !"'349EGH              y z        jU jU0J(0J$j0J$U0J$0J%V3r*6h+7q '&:f  7 k 3   $ W _    t['&                # ( * + 6 < = B H J K _ g h p q x y         !#$G],-23@JNZ./ACXY[xy~ j}U6 jnU0J%0J(0J$j0J$U0J$jU jUjtUN367<?ABOd,-./89CDSTVZ]^qrt<@ %&+023$%12s!t!;"<""""""""""""######## jU jV2U j(U0J%60J$j0J$U0J(0J$Ui/.S]qt'9PUl'&!s!u!!;"="~"""###?%&7'(((([)a)'&$!s!u!!;"="~"""###?%&7'(((([)a)E*L*w*** , ,.,-s..J0X01-1=1Q11112*2,2922I4U67h89::;;O<=>>>>??E?u????@@AAANCSCCCCCADSDqDDDDDDDD*EQGHtIJKK/L8LLbNd###### $$$%%%%%&&''6(;(c)h)i)n)s)u)v)L*S*T*Y*Z*a*t*u*w********* , ,.$.%.*./.1.2.{///////Z0g0h0m0z0|0}000-1=1B1Q122*2,292=2>2H2O2V26 jU0J$j0J$U0J(jU jU0J#0J$0J%Ra)E*L*w*** , ,.,-s..J0X01-1=1Q11112*2,2922I4U67'&V2W2b2i2p2q2|22222222222222]4a4c4k4m4t4y4444f5o5q5z5|5555?6S6b6i6j6o6v6x6y6~666666677777788#8,8;9C9D9I9Q9S9T9@:G:L:S:?@@@AA A A AAAAAAAA0J(660J$j0J$U0J$0J(Z7h89::;;O<=>>>>??E?u????@@AAANCSCCCC'&AAAAAAAAAAABBPBXBBBWC[C\CaCeCgChCCCCCCCCD DDDDD D!D,D9D:D;D`?````````aaa a!a"a*a+a@aAaCaGaOacccccccccccccccccccccdenej%U jU0J$j0J$U0J%0J(0J$Vneoete~eeeFgMgNgSgZg\g]gegfg|g}g~gggggggggggg{hhhhhhhhhhiiijjj#k'k(k-k1k3k4kPkVkWk\k]kakbkekfkikjkqkkkkkkkkkkl%lglhlzllll0J%H*0J(H*0J(6jUjU jU0J$0J$j0J$UPhmijjJkPkkkkzllm m7>/       nnnnnnnnnnnnnnnnnnnnnnoo ooooo o!o$o'o+o/o3o7o;o7>/       nnnnnnnnnnnnooooo o o o ooooooooooooo"o$o(o)o,o-o0o1o4o5o8o9o=o@oAoBoCoDoGoHoIoJoLoMoNoOoPoQoToWo^o`ocodofogoiojolomoooposovowoxo|o}ooooooooooooooooooCJEHCJEHannnnoo ooooo o d$ o!o$o'o+o/o3oC99999 d$$$$4d_,? 7 >7>/3o7o;o7>/konoqorovozooooooo d$ oooooooC99999 d$$$$4d_,? 7 >7>/ooooooooooooooooooooooooooooooooooooooooooooooooppppppppppppp"p$p%p)p*p,p-p/p0p3p6p8p9pp?p@pCpDpFpGpHpIpKpLpMpNpPpQpRpSpUpVpWpXp[p^pCJEHCJEHaoooooooooooo d$ oooooooC99999 d$$$$4d_,? 7 >7>/oooooooooopp d$ ppp p pppC99999 d$$$$4d_,? 7 >7>/ p pppppp"p&p+p1p2p6p7p:p;p>pApEpJpOpTpYpZp^pbpgpmpnprpspxpyp|p~pppppppppppppppppppppppppppppppppppppppppppqqq q qqqqqqq%q+q1q2q6q9q=qBqCqGqHqMqNqdpppp"p&p+p1p2p6p7p:p d$ :p;p>pApEpJpOpC99999 d$$$$4d_,? 7 >7>/OpTpYpZp^pbpgpmpnprpspxp d$ ^p`papepfphpipkplpoprptpupvpwpzp|pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppqqqqq q q qqqqqqqqq q!q"q#q&q'q(qCJEHCJEHaxpyp|p~ppppC99999 d$$$$4d_,? 7 >7>/pppppppppppp d$ pppppppC99999 d$$$$4d_,? 7 >7>/pppppppppppp d$ pppppppC99999 d$$$$4d_,? 7 >7>/ppppppqqq q qq d$ qqqqqq%qC99999 d$$$$4d_,? 7 >7>/(q)q,q-q.q/q3q6q7q8q;qq?q@qAqDqGqIqJqKqLqOqRqTqUqXqYq[q\q]q^q`qaqbqcqeqfqgqhqkqnqoqpqsqtqvqwqxqyq|qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqCJEHCJEHa%q+q1q2q6q9q=qBqCqGqHqMq d$ MqNqRqSqVqZq_qC99999 d$$$$4d_,? 7 >7>/NqRqSqVqZq_qdqiqjqnqqquqzq{qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqrr r rrrrrrrr"r#r'r(r+r/r4r9r>r?rCrDrGrKrLrPrQrVrWr[r\r_rcrhrmrrrsrwrxr|rrrrrd_qdqiqjqnqqquqzq{qqqq d$ qqqqqqqC99999 d$$$$4d_,? 7 >7>/qqqqqqqqqqqq d$ qqqqqqqC99999 d$$$$4d_,? 7 >7>/qqqqqqqqqqqq d$ qqqqqqqqqrrrrr r rrrrrrrr r!r$r'r)r*r-r.r0r1r2r3r5r6r7r8r:r;r7>/rr r rrrrrrrr"r d$ "r#r'r(r+r/r4rC99999 d$$$$4d_,? 7 >7>/4r9r>r?rCrDrGrKrLrPrQrVr d$ VrWr[r\r_rcrhrC99999 d$$$$4d_,? 7 >7>/hrmrrrsrwrxr|rrrrrr d$ rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrssss sssssss s!s"s&s+s1s7s8s7>/rrrrrrrrrrrr d$ rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrssss s ssssssss s#s$s(s)s,s-s.s/s2s3s4s5s9ss?sBsCsFsJsLsMsNsOsRsUsXsYs\s]s_s`sasbsdsesfsgsjsmsospsCJEHCJEHarrrrrrrC99999 d$$$$4d_,? 7 >7>/rrrrrrrrrrrr d$ rrrrrrrC99999 d$$$$4d_,? 7 >7>/rrssss ssssss d$ ss s!s"s&s+sC99999 d$$$$4d_,? 7 >7>/+s1s7s8s7>/^scshsismsnsssyszssss d$ psqsrsusvswsxs{sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssstttttt t t t tttttttt!t$t%t(tCJEHCJEHasssssssC99999 d$$$$4d_,? 7 >7>/ssssssssssss d$ ssssssssssssssssssssssssstt tttttttt!t"t&t't+t,t-t1t6t7>/ssssssssssss d$ sssssttC99999 d$$$$4d_,? 7 >7>/t tttttttt!t"t&t d$ &t't+t,t-t1t6tC99999 d$$$$4d_,? 7 >7>/(t+t/t0t4t5t7t8t:t;t=t>t@tAtDtGtItJtKtLtOtPtQtRtUtYt\t]t`tctgthtltmtotptrtstutvtxtyt|ttttttttttttttttttttttttttttttttttttttttttttttttttttuuuuCJEHCJEHa6t7>/ntttzt{ttttttttt d$ tttttttC99999 d$$$$4d_,? 7 >7>/tttttttttttt d$ tttttttC99999 d$$$$4d_,? 7 >7>/tttttttttttt d$ ttttttttttuu uuuuuuuu#u$u'u(u,u-u.u1u5u:u?u@uDuEuIuNuOuTuUuWuXu\u]u^uaueujuouputuuuyu~uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuudtttttuuC99999 d$$$$4d_,? 7 >7>/uuu u u u uuuuuuuuuu#u)u,u/u0u3u4u6u7u8u9u;uuAuDuGuHuLuMuPuTuYu\u_u`ucudufuguhuiukulumunuqutuwuxu|u}uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuCJEHCJEHau uuuuuuuu#u$u'u d$ 'u(u,u-u.u1u5uC99999 d$$$$4d_,? 7 >7>/5u:u?u@uDuEuIuNuOuTuUuWu d$ WuXu\u]u^uaueuC99999 d$$$$4d_,? 7 >7>/eujuouputuuuyu~uuuuu d$ uuuuuuuC99999 d$$$$4d_,? 7 >7>/uuuuuuuuuuuu d$ uuuuuuuC99999 d$$$$4d_,? 7 >7>/uuuuuuuuuuuu d$ uuuuuuuC99999 d$$$$4d_,? 7 >7>/uuuuuuuuuuvvv v vvvvvvvvvv#v&v.v2v4v5v8v;v?v@vCvDvFvGvHvIvLvOvQvRvUvVvYv]v_v`vcvfvjvkvlvmvpvqvrvsvuvvvwvxvyvzv}vvvvvvvvvvvvvvvvvvvvvvvvvv}ww"x#xH*0J(CJEHCJEH_uuuuuuuvvvv v d$ uuuvvvv v vvvvvvv!v"v&v'v)v,v-v2v3v6v7v;vvAvEvJvKvOvPvSvWvXv]v^vavbvfvgvhvivnvtv{v|vvvvvvvvvvvvvvvvvvvvvvvvvvvw xNxyxxzVzbzzzz"{,{0{{}~~~~OXd v vvvvvvC99999 d$$$$4d_,? 7 >7>/vv!v"v&v'v)v,v-v2v3v6v d$ 6v7v;vvAvC99999 d$$$$4d_,? 7 >7>/AvEvJvKvOvPvSvWvXv]v^vav d$ avbvfvgvhvivnvC99999 d$$$$4d_,? 7 >7>/nvtv{v|vvvvvvvvv d$ vvvvvvvC99999 d$$$$4d_,? 7 >7>/vvvvvvvvvvvv d$ vvw xNxyxxzCAA???A$$$4d_,? 7 >7>/#x'x(x,x-x3x4x6x7x=x>x@xAxGxHxJxKxUxVx\x]x`xaxjxkxqxrxuxvxxxxxxxxxxxxx{{|||||||   Xabdefgijlmno0J(0J$j0J$U0J$0J#H*ZzVzbzzzz"{,{0{{}~~~~OX؂CX_`$$Tl $'&oqrtuvwyz{ )*؂DEIJNOabfg ݅!">?RSst‹Ë=E0J$j0J$U jU60J#H*0J(H*0J%0J$0J(U؂CX_`pĄńof‹ċ݋3Uُ$P$Ycʔה֕,@nr}hɘ˘ AIXoޛ͞+;_ĠԠ(9kաIcBd`pĄńof‹ċ݋3Uُ$&$$Tl $ǍӍՍ֍؍  ;@ɎʎIJ`abyz   $+,MNP )*/8:;x۔0J% jUj`UjUjfU jU0J$j0J$U0J$O$P$Ycʔה֕,@nr}hɘ˘&'۔)*,'(<=ɘʘ >?A[`=Bŝ̝chўݞޞǟ̟ jLU j3U0J% jU0J$j0J$U0J$W AIXoޛ͞+;_'&̟  ()+;ELZ_ovĠԠڠ۠ !(9CDLMVW^_fkst|ơա "#)0ABI$)+f}ǥХ٥ڥߥ0J$j0J$U0J%0J(0J$\ĠԠ(9kաIcB$"Z^i6F'&$4xŦƦ˦Ԧ֦צ٦ էߧʨ˨Ш٨ۨܨ 346FT[krĪͪתު  &'I jgU0J(0J%0J$0J$j0J$UZB$"Z^i6F&(E4ίx&1sضڶ2ٷ M]iuHԾ#I^`Hxo'V/9k B7|QLd&(E4ίx&1sضڶ2ٷ M]'&IPQV]_`bhintvw}  8?#)߯^dip*3R]dzݳضٶ  %&'-56JKM]kr0J% jE U jU0J(H*0J(6 j1U jU0J$j0J$U0J$QŹ̹͹Թ۹ "'0qrLVW\fhiƾԾ "#$,-589?FGHI^`0J%60J$j0J$Ujq U jU0J$0J(ViuHԾ#I^`Hxo'V'h'&9BLRZ7A|#'7>Vr|}6? 0J%0J( j U0J$0J$j0J$UZ/9k B7|Q'&'   "ivw|&'4dn  r4A\mns;RSXoqr *+,3=>?@ j U jN U0J%0J(0J$0J$j0J$UW@JKLQ[\]^xyzBCDLSTUVbcdkrstu34JKLTUfg}jO U jU0J%0J$\L.9''r}$/&'.9''r}$/| #Mjn8#0pv NTXnv       , 7 ;          + 8 F J P @ I [ z d}~  "#$)*  %.0139:?EGHJQRW^`ach0J$j0J$U0J$j UjC Uj UjI U jUj ULhinsuv|=GHMWYZ $%'-DNZ[`lno3=  -B j= U0J%0J$0J$j0J$U[| #Mjn8#0p'&BLQX/9:?IKL4<=BJLM^bchlno123XYipu} ##bj0J%j + U jU0J$j0J$U0J#60J$Vv NTXnv       , 7 ;     $%'./4;=>SY     9 > ? D I K L    # % & + > ? D W Y Z   # ) * / 5 7 8 i s         y  . 7 8 = F H I > H I N j+ U jU60J$j0J$U0J$X      + 8 F J P @ I [ z   < C h r x N X Z [      $ z & ' ) 8 ; < A H P Q V [ h i q x        2 6 7 < @ B C P Z [ ` j l m                ' c k y   0J(0J%0J$j0J$U0J$Z   < C h r x ) 8 [        x  k  : U m h  W" c# # $ & & ' ' (* ]* * &, / `0 l0 1 2 3 3 3 3 5 8 '9 9 9 V< = ? @ ]@ @ mB C $D -D E F I I I +J :J ~J J J J K $K =K PK K K L L $L pL rL tL L L L M 'O zP P dx ) 8 [        x  k  : U m h  W" c# # '&       H P Q V ^ ` a                      ? D E J O Q R n v     ! (            D H         ! ) * / 7 9 : ! ! ! $! *! ,! -! 3 c3 i3 3 3 3 3 8 '8 (8 -8 58 78 88 98 >8 +9 39 X9 ^9 9 9 9 9 9 9 9 9 : : : ,: 1: 2: 7: <: >: ?: < < 4< 5< jU j~- U0J(0J$j0J$U0J$Y5< K< L< M< R< S< = > > > > > > "> )> *> /> 6> 8> 9> S> Z> [> `> g> i> j> l> r> s> x> ~> > > > > > > > > > > > > > > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? B B +B ,B -B >B ?B B B B B C C C C C C C C jK Uj=K U0J$j0J$U0J$ jUjJ UR]@ @ mB C $D -D E F I I I +J :J ~J J J J K $K =K PK K K L L $L pL rL 'h'h'&C C C C C C D D 1D 8D 9D >D ED GD HD F F F F F F F F F F F F F F EG SG G G H H (I .I }I I I I I I J J J +J :J CJ DJ {J |J ~J J J J J J J J J K K $K =K PK YK ZK K K K K K K K K K K K K K K L L 0J%6jL U0J$j0J$U0J$j7L U jUSL L L L "L $L pL tL L L L L L L L L L L L L 'M 9M M M M M M M M N N O O @O GO HO MO TO VO WO YO _O `O eO kO mO nO rO xO yO ~O O O O P P P P "P (P Q Q S T T T T T T T "T -T .T /T 6T 7T =T GT T T T T T T T 0J$j0J$Uj1M U jU0J%0J$TrL tL L L L M 'O zP P P P P P P P P Q Q R 7R LR R R R S !S S S T &'P P P P P P P P Q Q R 7R LR R R R S !S S S T 7T U 1W 9W @Y [Y dY Y Y Y Y Z Z WZ Z Z Z ] #` Ua a a a b Sc hc c c ud d 0e Ie f f .h Bh h h i j j l m 4m ?m ~m m m m n o o o o o p "p ;p Wp qp p p p p p s s t t .t Ft ]t at t u u u u v ,v dT 7T U 1W 9W @Y [Y dY Y Y Y Y Z Z WZ Z Z Z ] #` Ua a a a b Sc hc c c &'T T T T T CU DU ZU [U \U cU dU hU iU U U U U U U U U U U U U V V V V V /V 0V 7V 8V NV OV PV `V aV V V V V V V V V V V V V V V 0W 1W vW }W ~W W W W W X X dY lY mY Y Y Y Y ǾǾǾ0J%0J$j0J$U0J$jP UjO Uj%O UjN Uj+N U jUjM UGY Y Y Y Y Y Y Z Z Z Z .Z 5Z ?Z FZ RZ WZ aZ bZ pZ qZ rZ yZ Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z c[ u[ \ "\ \ \ Q] R] h] i] j] r] s] `^ j^ l^ x^ z^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ _ _ _ _ _ jQ U0J$j0J$UjP U jU0J$0J%T_ ,_ -_ D` K` L` Q` X` Z` [` ` ` a a b b b b #b %b &b +b 1b 2b 7b =b ?b @b yb b hc qc |c }c ~c c c c c c c c c c c c c d d d !d 7d 8d 9d Ld Md e e e e e e e e e e e e e e .f /f Ef Ff Gf Xf Yf g g g !g (g *g +g -g jR UjQ U0J%0J$j0J$U0J$ jUTc ud d 0e Ie f f .h Bh h h i j j l m 4m ?m ~m m m m n o o o o o p '&-g 4g 5g :g Ag Cg Dg Ig Ng Og Tg Yg [g \g Bh Oh Ph Xh Yh Zh {h |h }h h h h h h h h h h h h h h h h h h i i i i i ni si i i i i j $j j j k k k k k k k m $m ?m Im Jm Xm Ym Zm am lm mm {m |m }m m m m m m m m m m m m m m m m m m 0J(0J%0J$j0J$U0J$\m m m m m n n n n n n n n 'n an hn n n n n wo o o o o o o p p p p p p p p t t cv lv v v v v v v v v v v v v v v v v v v v v v v v v v v v v w w x x x x x x x Py [y xy y y y y y y y y y y y y y y 0J$j0J$U0J%0J$0J(\p "p ;p Wp qp p p p p p s s t t .t Ft ]t at t u u u u v ,v Sv Wv )w Dw Tw ,v Sv Wv )w Dw Tw pw w w w w w w w x x !x @x Ay ky xy y y y y z z { { { { { $| 8| U| | | | | | | } .     $ (  d o # ; m x у Ӄ / e ˄ ܈ I ֐ 5 s b p x   t  ! 0 ? X o dTw pw w w w w w w w x x !x @x Ay ky xy y y y y z z { { { { { $| 8| '&y z z z z z Kz Wz zz z z z z z z z z z z z z z { { | | | | | | | | ~ ~ ~ ~    o v w |                  T [ € ɀ ˀ ̀  + K T U Z c e f u v jR U jU0J$j0J$U0J(0J$0J%V8| U| | | | | | | } .     $ (  d o # ; m x у 'h'&v ς ؂ ق ނ M V W \ e g h x у Ӄ      / 7 9 = D H O Z \ ` e k l s t u { Ä Ą ʄ ˄ ̄ ф Ԅ ք ؄ ݄ 0J(0J%0J$j0J$U0J$ jUj S UVу Ӄ / e ˄ ܈ I ֐ 5 s b p x  &'            2 = L W  # Ç ć ȇ ԇ Շ ڇ Z f ˈ ̈  ' Š Ɋ Њ ъ ֊ ݊ ߊ  , 3 9 : ? E G H J T U Z d f g i q jT U6jS U jU0J$0J%0J$j0J$UTq r w  0 8 9 > F H I K O P U Y [ \ a l m r }  $ * + 0 6 8 9 A I J O W Y Z  ؑ ޑ        ! ' + 7 8 = I K L M S Ӓ ؒ 0J(jT U jU0J$0J$j0J$UXؒ ْ ޒ _ d   . / Ė ̖ Ζ ϖ Ӗ s     " $ & ' ? F G L S U V Ϙ И ! $ ( 1 # , F I Ɯ z }   j~U U6 jUjU U jU0J$0J$j0J$UR  t  ! 0 ? X o Ț ך  ś ߛ Ҝ ݜ    Ț ך  ś ߛ Ҝ ݜ   ( 9 h l ; B h x + 3 t Ѣ + K \ ( ? f 4 * E   " 0 E _ c ϴ ߴ  9  `  ɹ ? & 1 e u  E ~ N V  % E j d ( 9 h l ; B h x + 3 t Ѣ + K \ ( ? f 4 '&   $ & ' : ; w W ] ^ c i k l 3 : ; q r t ΢ Ϣ Ѣ    $ % & + 5 6 D E F K T U [ գ   # $ ) 2 4 5 7 A B G Q S T Z c d i r t u jU U jU0J(0J%60J$0J$j0J$UV ħ ŧ ˩ ϩ Щ թ ٩ ۩ ܩ          ! # $ & - . 3 : < = ? D E J O Q R T \ ] b j l m s { | 2 ; < A J L M O Y Z _ i k l ˫ ҫ ӫ ث ߫      0J$j0J$U0J$ jU\  p q ¬ Ǭ ͬ Ϭ Ь 3 : Ʈ Ȯ ɮ ή Ԯ ծ ڮ  (     % * 1 < = > D E K U ԰ հ ְ  ( ) . 7 9 : ̴ ʹ jV U0J%0J$0J$jxV U jUj0J$UT4 * E   " 0 E _ c ϴ ߴ  9  `  ɹ ? '&ʹ δ ߴ   % & ' . / 0 6 7 8 G I j y  ! Z a b c i + 7 P Y ~           % & + 3 5 6 ; C 0J$j0J$U0J#0J(0J%0J$Z & 1 e u  E ~ N V  % E j  C D I Q S T ! + , 1 ; = > Q [ n y z      0 E L \ r s t y {       & , 9 ; h j       " jU0J(0J%0J$0J$j0J$UV  5 ^  $ : G R q w {   0 ` r Z : F Q   " ( , >   # [ p r   5 h B V a p O Z 0 > }  W c Y n d 5 ^  $ : G R q w {   0 ` r Z : F Q '&   " ( , >   # '&   h o p u | ~  X ^   F N O T \ ^ _    , - X Y [ p r 0J%jlX UjW U0J$j0J$U0J$ jUjrW UQ# [ p r   5 h B V a p O Z &''hr     $ - / 5 6 ; > @ B G J L N S V X Z _ b d f k n p r w z | ~   g h  ! " ' ) + , 0 < = B N P Q " jU0J%0J$j0J$U0J(0J$Z" # $ 1 2       ( * + 0 9 : ? H J K        " # ( 3 4 9 D F G V W m n o  ~ jY UjfY U0J$j0J$U0J$0J%6 jUjX UP   u    - . 0 > E F K R Y Z ` g q r x }     % & 2 A B C J O P V c l m 60J(0J%0J$j0J$U0J$[ 0 > }  W c Y n k  '&m s z ! 2  ' }    ! ) + , X ^     ! # $ < C D I P R S  ( / 0 5 < > ? D J K P V X Y j`Z U jU0J$j0J$U0J%0J$0J(V k  1 U o l  2 = J b      ~    K  $ % M     K L W e w     ( X       & 2        c ! # # % & L' Q' ( ) ) + (, 9, L, , , - - - d    ! 3 4 J K L _ ` G X       ' ) * / 9 : ? I K L ' 4 5 : G I J l % &   jUjZ[ U0J$j0J$U6jZ U jU0J%0J$Q 1 U o l  2 = J b      ~       ! % 0  ) * / 9 ; < V \ ] b h j k S X Y ^ c e f                                   c m      $ 60J$j0J$U0J$]   K  $ % M     K L W e w     ( X   $ * + 0 6 8 9  R [ \ a j l m P X j s   % - ; E F K U W X        O W                 + / m                       ` s t y    H [ q jU60J$j0J$U0J$Z     & 2        c ! # # % & L' Q' ( ) ) + (, 9, L, '&q {          2 = 7 ; < A E G H f l m r x z {                 (     ! " 4 ; < A H J K g p q v  8! B! " " " " (" *" +" |# # # # $ $ & & & & & & & j[ U jU0J%0J(60J$j0J$U0J$V& & ,' ' ' ' ' ' ' ' ' ' ' ( ( ( ( ( ( U( ]( ^( c( k( m( n( s( x( y( ~( ( ( ( ( ( ( ( ( ( ( ) ) R) S) i) j) k) p) q) ) ) ) ) "+ -+ .+ 3+ >+ @+ A+ + + + + + + + + + , , L, U, V, , , , , , , , , , , 0J%j\ UjT\ U jU0J$j0J$U0J$6SL, , , - - - j- l- n- - - - $/ 1/ 30 ]0 j0 0 0 0 0 0 1 2 2 2 2 3 &'h'h', , , , , - - - - - - - j- n- - - - - - - - - - - K. L. b. c. d. z. {. / / / / / / / B0 M0 j0 v0 w0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 =1 I1 l1 s1 t1 y1 1 1 1 1 1 1 1 1 1 1 1 2 3 3 3 3 3 3 3 3 S4 0J(0J$j0J$UjN] U jU0J%0J$V - j- l- n- - - - $/ 1/ 30 ]0 j0 0 0 0 0 0 1 2 2 2 2 3 53 m3 3 3 3 3 4 s5 A7 7 7 7 8 '8 H8 a8 r8 z8 8 8 9 ): : : ; ; ; < < = > ? v@ A A A A B B \B ^B `B mB B B B "E G H J "K K K K K L 7L hL L L L L L 5M @M ^M M M M M N 1N [N N N N N N d 3 53 m3 3 3 3 3 4 s5 A7 7 7 7 8 '8 H8 a8 r8 z8 8 8 9 ): : : ; ; ; < '&S4 [4 4 4 4 4 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 8 8 9 9 9 9 9 9 9 9 9 : : : : : ; ; ,; 1; 2; 7; <; >; ?; D; I; J; O; T; V; W; ; ; ; ; ; ; ; ; ; &< -< .< 3< :< << =< j< k< < < < < < < < < jH^ U0J%6j] U jU0J$j0J$U0J$T< < = > ? v@ A A A A B B \B ^B `B mB B B B "E G H J "K K K K K 'h'h'&< < < < < > > @ @ @ @ @ @ @ @ @ @ @ @ @ A A A A "A $A %A -A .A DA EA FA NA OA A A A A A A A A B B B B \B `B mB pB wB zB B B B B B B B B B B B B B B B B B B B B B B B B B B B C C C C C C C 0J(0J%j^ U jU0J$6j0J$U0J$UC C C C C !C $C &C (C -C 0C 2C 4C 9C C ?C RC ]C oD zD D D !E "E =E IE E E E E E E E E E E F F F F F F F F F F F F F OG YG H I =I II vI ~I I I I I I I I I I I I I I I I I I I I I I I I I I I j_ U6jB_ U jU0J$0J%j0J$U0J$SI J J 6K =K QO ]O T T T T PZ ZZ Z Z Z Z Z Z Z \ ] ] ] ] ] ] ] ] ] ] '] )] *] /] 4] 5] :] ?] A] B] L] X] Y] ^] j] l] m] ^ ^ <_ C_ D_ R_ S_ f f f f f &f 'f +f ,f Bf Cf Df Jf Kf Of Pf ff gf hf zf {f f f f j6a Uj` Uj<` U jU60J$j0J$U0J# jU0J$NK L 7L hL L L L L L 5M @M ^M M M M M N 1N [N N N N N N O O O &O DO IO N O O O &O DO IO CP OP bP yP P P P P P P GR :S 6T GT U V W W 8W fW W W X Z [ [ [ [ [ \ !\ ,\ :\ H\ Z\ \ \ \ \ g^ p^ _ ` b c e 8h >h j j j /j Ej Ij Qj Am im {m m m m m m o o o p p "p ;p Tp mp up {p hq 8r >s Ds s s (u -u w w h j j j /j Ej Ij Qj Am im f f f f f f g g g g g g _g hg ig ng wg yg zg |g g g g g g g g g g g g g g g g g g g g g g g g g g g g g h h h h h h h "h #h (h 3h 5h 6h Bh Gh Hh Mh Rh Th Uh i i i i i i i ]j dj ej jj qj sj tj k (k )k .k 9k ;k k Ik Jk Ok Zk \k ]k _k jk kk pk {k }k ~k k k k k k k k k k >l Hl l l l m m )m {m m m m m m m m m m m m m m m m sn n n n n n n n n n n n n n o o 5o Fo o o 6q Aq Eq Pq yq q Jr Kr ar br cr r r r r r j0b U jU0J(0J%0J$j0J$U0J$Sim {m m m m m m o o o p p "p ;p Tp mp up {p hq 8r >s Ds s s (u -u w w ס  4 Ѣ   E Q ] z d8 O T : B ă  M ц  U p  E I p  n Ɍ Ռ J p ' ł Ƃ ˂ ҂ Ԃ Ղ F M N S Z \ ] ă Ճ փ   ) . / 4 9 ; < ʼn Ɖ ˉ ԉ ։ ׉ ܉     # % & ٌ J p W [ \ a e g h l q r w | ~  Ǝ Ҏ ӎ ؎ * . / 60J%0J$j0J$U0J$\ Ž # F }  X ^ @ I ܘ 9 v 6 ǝ 'h'/ 4 8 : ; ? D E J O Q R  ͐  F ^ _ m n p q r } ~ Ƒ  Ò ɒ    Ҕ  ' ) I b g h m r t u # - . 3 = ? @ B K L Q Z \ ] z җ ח m 0J#60J(0J%0J$j0J$U0J$Ym u v { ˜ Ø ٘ ژ ܘ   # -       3 4 6 G T { Ϝ ؜   ? F G L S U V  ȟ ɟ ʟ ˟ ! ( A H a h       " $ % 6hnH  j$d U0J#60J%0J(0J$j0J$U0J$Uǝ 3 ;  ʟ ̟ > ס  4 Ѣ   E Q ] z 'z 1 9 r Ϧ ߦ  , D J W [ ɧ <   ) 9 S k q u T  g C ` Ʋ o  , V i e g ڵ ܵ   O L Y   L t 5 : \ 1 T J $ ]  d 1 9 r Ϧ ߦ  , D J W [ ɧ <   ' Ƥ Ǥ ̤ Ҥ Ԥ դ ɧ     # $ 9 : < N [ ֨ ߨ  - 5 6 ; C E F H v  S Y k x y ~   ! +     ! # $ g Ů Ʈ ˮ Ѯ 6hnH 60J%0J(0J$j0J$U0J$X ) 9 S k q u T  g C ` Ʋ o  , V i e g &'Ѯ Ӯ Ԯ C ` T X Y ^ b d e i n o t y { | Ű ư ˰ Ұ ԰ հ N X Y ^ h j k m v w |    , = S T V i q r y e f j$ U0J(0J%0J$0J$6j0J$UVg ڵ ܵ   O L Y   L t 5 : \ ' ڵ ۵   ķ ŷ ʷ з ҷ ӷ   Z c d i r t u L k l r s    % & ½ ̽ ͽ ҽ ܽ ޽ ߽   % + - . q x jF U jU0J(0J$j0J$U0J$ j/ U j6 U j UQ \ | T c d r s u v w 3 < _ l m r   $ % * 1 3 4 $ 4 5 C D Z [ ] a o 0J%0J(0J$0J$6j0J$U[ 1 T J $ ]  0 8 k q < ' l U Z  $ . 7 '    ' 4 [ e < C D I P R S p t u z ~  # ( / > ? U V W [ \ u z {   % , l   4 5 6 E F jG Uj/G U jU0J$j0J$U60J$0J%0J(R 0 8 k q < ' l U Z  $ . 7 _ d  !  : : ` p  # \ & H h y & i k \ P 4 I   :   O %  L  = G x ,  ' k | d      9 ? @ E K M N      > B T a b g t v w ; C D I Q S T      # % & C I J O U W X  ' 5 : D E M T [ \ a h m n t { 0J(0J%0J$j0J$U0J$[7 _ d  !  : : ` p  # \ '&    " ) 5 9 D K T U ` p z {   # 3 : D K W \ f g u v w ~   ! & 1 2 A B C H 0J%0J$0J(b & H h y & i k \ P 4 I   :   '&H R S a b c h q r x    ! & 0 1 ? @ A H S T b c d i u v   & ' ( / 0 y jH Uj)H U jU0J$j0J$U0J(0J%0J$S     ! j u w     T ` e p q v    ! , . / I [ n o jJ UjJ UjI U0J$j0J$U0J$0J%j#I U jUN      $ % 8 B C H R T U Z ` a f l n o         E L M R Y [ \ l m   jL UjK UjK U jU0J$j0J$U0J$R    + , - 9 : a j k p y { | ~   % & ' 6 7 q { | j M U0J$0J$jL U jUj0J$UV # , - 2 ; = > C H I N S U V        " $ % ' 1 2 7 A C D F O P U ^ ` a c n o t   " R ] jM U jU0J$j0J$U0J$Y O %  L  = G x ,  ' k | '&] N [ _ h ) . / 4 9 ; < m s t y  L      ' 0 1 6 ? A B D L M R Z \ ] a m n s  60J$j0J$U0J$]          I S T Y c e f j s t y     6 = A F H Q y ~ }        ' ( 0J$0J$j0J$U^( - 8 : ;     ' ) * . 3 4 9 > @ A          $ * , -    e n m w C N ~ ! * 0 7 8 = D F 0J$j0J$U0J$^F G I N O T Y [ \ b i j o v x y ' , - 2 7 9 : < A B G L N O Q X Y ^ e g h j q r w ~      3 = 0J$0J$j0J$U^= > C M O P | r x                 _ ` v w x } jN U jU60J(0J$0J$j0J$UW C     Z \ t   e k : @ 1 t      % I W y '& C     Z \ t   e k : @ 1 t      % I W y     ? 9 I A  ? P     W k  " & p( n* * - - / A1 p1 G2 Y4 5 8 9 9 $9 (9 F9 J9 Q9 U9 z9 9 9 9 9 9 9 9 9 : : ): 5: 9: E: 8< X< e< < < < = = = = = h? t? }? ? ? @ TB d} ~            Z [     ! & , . / 4 9 : ? D F G        D J o t u z  . 7 D H I N R T U R V                       0J% jN U0J$j0J$U0J$6 jUX              % / 0 9 H W ] ^ f m q r y                            # $ * 1 7 8 >               K U V [ e g h       P ` a k 60J$j0J$U0J%0J(0J$[y     ? 9 I A  ? P     W k  " & p( n* * - - / A1 p1 '&k l m t                          0 : X b   [ b c h o q r 8 @ A F N P Q     "! #! " " # # \$ c$ & & & & ' ' ) ) u* }* ~* * * * * * * * * * * * + + + + ?, G, 6H*0J$j0J$U0J%0J(0J$ZG, )- /- A1 p1 3 3 ]4 g4 h4 m4 w4 y4 z4 4 4 5 5 I: O: P: U: [: ]: ^: e< k< l< r< s< < < < < < < < < < < < < < < ? ? ? ? ? ? ? @ @ @ @ @ @ @ C C C C C C C D %D &D +D 4D 6D 7D 9D ?D @D ED KD MD ND PD UD VD [D `D bD cD eD kD lD qD wD 0J%0J$j0J$U0J#0J(0J$Zp1 G2 Y4 5 8 9 9 $9 (9 F9 J9 Q9 U9 z9 9 9 9 9 9 9 9 9 : : ): 5: 9: E: 8< X< X< e< < < < = = = = = h? t? }? ? ? @ TB `B iB B B C C xE E E E E E '&TB `B iB B B C C xE E E E E E E E E E E E eF qF zF F F F F F F F F F LG H H 1I OI ZI bI I I I I I J EJ nJ qJ K 1K 2K K L L ZN jN P P P P P P P Q #R T ]U V V NW [W nW {W W W W W W W W lY Z %[ 3[ G[ Y[ ][ \ \ \ ` b c !c Oc \c c c c ;d d d dwD yD zD D D D D D D D I I L L L L M M M M M M M M M M #M /M 0M 5M AM CM DM O O O O O O O 0Q ?Q jQ rQ sQ xQ Q Q Q Q Q %R /R S S S S S S S T 'T 7U ;U W @W AW W W W W X X X 60J$0J$j0J$U]E E E E E E E eF qF zF F F F F F F F F F LG H H 1I OI ZI bI I I I I I I J EJ nJ qJ K 1K 2K K L L ZN jN P P P P P P P Q #R T ]U V V NW [W [W nW {W W W W W W W W lY Z %[ 3[ G[ Y[ ][ \ \ \ ` b c !c Oc \c c c c '& X uY Y Z Z Z Z \ \ \ \ \ \ \ ] ] ] ] ] ] ] ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ '_ (_ >_ ?_ @_ L_ M_ i_ n_ _ _ _ _ _ _ _ _ _ K` P` na va wa |a a a a b c !c (c )c Lc Mc Oc \c ec fc lc sc zc {c 0J(0J%j Uj0 Uj U jU0J$j0J$U0J$P{c ~c c c c c c c c c c c c c c c c c c c c c c c c c c c d d d d d d d d d d d d d !d "d ,d -d 2d 3d 4d 5d 6d ;d Dd Ed ~d d d d d d d d d d d d d d d d d e e e e e e $e 0e 1e Ae Be Ce e e e e e e e f f )f 0J$j0J$U0J%0J$0J([c ;d d d d d $e De h li hj j j k l m %m 0m Jn n n \p gp p p p q t u &'d d d $e De h li hj j j k l m %m 0m Jn n n \p gp p p p q t u v ,y .y Ry Ty yy X{ Z{ |{ *~ ,~ y~ ~ R Z @ [ d ҈ O o & ] t ƒ ޒ  # E _ g m q  9 Օ - M _ s  Ś   o d)f *f @f Af Bf ef ff f f f f g g g g g g g h h h h h h h h h h h h h h h h h i i i $i %i ,i -i Ci Di Ei \i ]i i i i i j j j j j j j #j %j &j Bj Gj 6k ;k m ?m Dm Nm Pm Qm m m _n in n n j$ Uj U0J$j0J$U0J$j* U jURn n n n n n o p p p p p p /p 9p [p \p wp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p q q q q ?r Er Fr Kr Qr Sr Tr r r r r r r r Vs `s as fs ps rs ss s t +t 9t t t u u v v v v ,y -y Ry j U60J(0J%0J$0J$j0J$UXu v ,y .y Ry Ty yy X{ Z{ |{ *~ ,~ y~ ~ R Z @ [ d ҈ O ''h&Ry Sy y y X{ Y{ { { | | | | | | | *~ +~ ~     ! * , - n s t y ~ ߁      x     ' ) * / 9 : ? I K L P ` e s Ć ņ ʆ ц ӆ Ԇ [ b ̇ Ӈ   jU0J( j U0J$j0J$U0J$ jG U6 j UR   < = O V d m n ň ̈ ҈    % & ' . 9 : H I J O [ \ l m n s z Z ^ _ d h j k m q r w { } ~ ׊      0J$j0J$U0J%0J$ jUjz UWO o & ] t ƒ ޒ  # E _ g m q  9 Օ - M _ &' ' ) * 0 5 6 ; @ B C 0 1 G H I Q R ̌ ӌ   ( / 0 5 < > ?  Ǎ ˍ ͍ ΍ ֍ ׍     # - / 0 2 : ; @ H J K jt U0J%j U jU0J$j0J$U0J$TK P Z [ ` j l m ǐ Ȑ ͐ ֐ ؐ ِ r s đ ͑     ǔ ɔ ʔ Д Ք ֔ ۔ > ? U V W j k ̕ ӕ Z e f k v x y   - 9 : J K L _ u | 0J%jn Uj U jU0J$j0J$U0J$T_ s  Ś   o ȝ       &' — Ǘ / 6 7 < C E F K \ c p r ˜ Ә T [ \ a h j k m t u z 2 9 ՛ ֛ כ ޛ ߛ ۜ * 1 2 7 > @ A F K ʞ מ  j U jU0J$j0J$U0J%0J(0J$V ȝ       - ; H f n { 8 { ѭ ܭ  N ߮ O : O c 8 D   . A G K ? = F z  ?   F  d # 3 @ X f A a    Ф Ѥ 6 ; L Q l m è ͨ Ϩ Ш ( , - 2 6 8 9 F P Ʃ ˩ Z [ q r s Y c d i s u v 0J%jb Uj Ujh U jU0J$j0J$U0J#0J$P - ; H f n { 8 { ѭ '& έ ϭ ѭ ܭ    - 4 > I N S Y ` f m t { ʮ Ю ߮     $ & ' ) @ J < = O ǰ ϰ а հ ݰ ߰       # * + 0 7 9 : M U k m w ~ 60J(0J%0J$0J$j0J$U[ѭ ܭ  N ߮ O : O c 8 D  '& G I J O Q S T ĵ ŵ  # $ ) . 0 1 3 9 : ? E G H M T U Z a c d ɻ ʻ ^ h i n x z { W X n o p D P Q ~  h v   0J%j Uj\ Uj U jU0J$j0J$U0J$0J(P  . A G K ? = F z  ?  'h'& 2 3 4 C D F O P w x z      " / 0 ? L U V [ d f g h m n s x z {       0J$j0J$U0J(0J%0J$ jUjV UV        $ & ( ) + 4 5 : C E F K X Y ^ k m n Z g     $ 4 8 D     2 A 3 B    0 ; < A H U V [ b o p u z 0J(0J%60J$j U jU0J$j0J$UV  F   ; L ^ s w  0 z  $ '&  ; L ^ s w  0 z  $ T  8    /    m x  0  X      + ;  2    Y k > l     i s  m  ! 2! ! ! ." # % % ' ^( r( ) ) ) d    ! " # s ~    > M N S b d e   < G  ' ( - : < = k x y ~ j UjP U jU0J$j0J$U60J%0J$T T  8    /  '      ' ) * S ` a f s u v   |        & ' - . 0     $ . % X d n k l                      $ 3 j U0J$0J(0J$jJ U jUj0J$UT   m x  0  X      + ;  2    Y k > l  '3 5 6 Y p              x        z    c r     > a j l s                           s  ) 1 ( 1 2 7 @ B C [ ^ _ d g i j 0J$0J#60J(0J$j0J$UZ    i s  m  ! 2! ! ! ." # % % ' ^( r( ) ) ) <* * * + &'j S$ Z$ [$ `$ g$ i$ j$ :' I' ( ( ( ( ( ( ( ( ( ( ( ( ( ( B) K) L) Q) Z) \) ]) q) ) ) ) ) ) ) ) ) ) ) ) ) ) * * * * * * * !* 1* 2* 7* <* G* H* M* T* b* c* h* o* * * * * * * * * * * * * * * * + + + + + + + l, o, v, - 50J(0J%60J$j0J$U0J$Z) <* * * + + ^/ d/ 1 ?3 P3 E5 6 : : @> O> ^B oB E E J J L L yM M O ^R S S T :T U V V V W X Z b[ \ 5\ z^ ^ ` a a Ib c sd de f f f g h Ni i j k l zm n n o &p p q r %s it \u fv v w x y z { } ~  + [ Մ { , ] . W w d+ + ^/ d/ 1 ?3 P3 E5 6 : : @> O> ^B oB E E J J L L yM M O ^R S S :T U - +- - - / / / / / / / T3 d3 e3 j3 z3 |3 }3 3 3 : : : : : : : ; ; > $> m@ {@ |@ @ @ @ @ ]D mD nD sD D D D E E E F F F F J K K K K K K L L L L L L L M M M M M M M N N N N 'N )N *N 8N FN GN LN ZN \N ]N LO WO XO ]O hO jO 60J#0J$j0J$U0J$\jO kO O O O O O O O O O O O O O O bP rP sP xP P P P P P P P P P P (S 8S S S  A B C Q R ʩ ˩ ̩ ٩ ک  ! 0 1 d e j7 Uj Uj Uj` Uj UjD U jU0J$0J$j0J$UIU V V W b[ 5\ z^ ^ ` a a Ib c sd de f f f g h Ni i j k l zm n n o &p &p p q r %s it \u fv v w x y z { } ~  + [ Մ { , ] . W W w T s & _ q N  & n w T s & _ q N  & n ӣ  i + k ئ ٦   Q b c p § ç ϧ     7 I J ^ l ͨ Ψ ߨ  S T a y ۩ ܩ 2 3 ? d ' ( : _ ` a p Ы dn ӣ  i + k ئ ٦   Q b c p hX$$l !$$$l4!$$ § ç ϧ     7 I J ^ l ͨ Ψ ߨ  S T a y D$$l !$ ۩ ܩ 2 3 ? d ' ( : _ ` a p Ы \$$l !$    % & \ ]   ! " # - . Ӻ Ժ պ ~  ڼ ۼ ' ( h i j 0 [ \ ] Y ` d l       ~    h t  0J#6j Uj U5jX Uj UjF Uj Uj U jUJЫ    # ) * : _ ` a m ͬ ά Ϭ hp$$l4!$$$$l !$    # ) * : _ ` a m ͬ ά Ϭ ڬ    / 0 1 ? K L M X t ˭ ̭ ͭ ڭ    & \ Ю Ѯ + < = H f g h w ȯ    - 8 9 : P ` a b s а dϬ ڬ    / 0 1 ? K L M X t ˭ ̭ ͭ xp$$l !$ͭ ڭ    & \ Ю Ѯ + < = H f g h w T$$l !$w ȯ    - 8 9 : P ` a b s l$$l !$ а Ѱ Ұ  / H I U u v w    ( > ? @ $$$l !а Ѱ Ұ  / H I U u v w    ( > ? @ J h i j v IJ  + , - = i   7 o \ M ʷ Q z ܻ D ۼ + F ^ y [ ÿ N c H h q R d@ J h i j v IJ  + , - = i t`hLL$$l !$i   7 o \ M ʷ Q z ܻ D $$l !$D ۼ + F ^ y [ ÿ N c H h q R  1   1  9  { I ) M x C N e  /  E  Q ^ q 5 u  ]  N Z g ) i 2 \ x Z d1  9  { I ) M M x C N e  /  E   Q ^ q 5 u  ]  N Z g ) i 2 \ \ x Z 7 K      $ 9 P e {  7 K      $ 9 P e { d  q    @ I    Q { 3 > E     t #       V    YG ZG \G G G G G ={ d  q    @ I    Q { 3 > E     t #     D K M R X ^   , : ` k u " . ~ ( {          r  $ , Y e @ A W X Y u v      * * 8 8 ; ; WG XG YG G G G G G G G 5mHj- U jU0J#K#       V      ! - v          : w   " F         ; I Z o w                  " F  " * 2 : B K T ] e n |              % 2 ; D N " F N X a              # , 5 > G P g o w      " F     ( 8 K o ! ! #! 7! P! Z! c! r! }! ! ! ! ! ! " F ! ! " ." A" R" i" }" " " " " " " " # # ># # # # # # # $ 0$ W$ g$ s$ $ " F $ $ $ $ % $% 4% I% ]% % % % % % % & & 2& R& f& y& & & & & & & & & & " F & ' ' )' =' S' ' ' ' ' ' ' ( ( )( 6( C( r( ( ( ( ( ( ) )) 5) D) \) k) ) " F ) ) ) ) ) ) * * +* >* N* `* v* * * * * * * + + 3+ F+ i+ + + + + + + " F + + , n, , , , , , , , , , - 1- U- - - - - . #. 9. . . . . . / %/ " F %/ 8/ `/ q/ / / / / / / 10 J0 d0 0 0 0 0 0 1 1 +1 31 R1 ^1 q1 1 1 1 1 1 " F 1 2 2 (2 B2 g2 x2 2 2 2 2 2 2 3 "3 53 o3 3 3 3 3 3 4 :4 `4 t4 4 4 4 4 " F 4 4 4 4 4 5 5 5 5 5 6 6 /6 =6 I6 a6 s6 6 6 6 6 6 6 7 7 37 G7 T7 a7 u7 " F u7 7 7 7 7 7 7 8 8 c8 8 8 8 8 8 8 8 9 9 B9 Y9 {9 9 9 9 9 9 9 : 7: " F 7: M: \: r: : : : : : : : : ; *; F; W; d; x; ; ; ; ; ; ; ; ; < < (< A< " F A< ^< w< < < < < < < < < = )= S= = = = = = = > > 3> A> O> ^> h> v> > > " F > > > ? ? 8? V? l? ? ? ? ? ? ? ? ? @ %@ <@ P@ l@ @ @ @ @ @ @ @ @ A " F A 6A BA ZA rA yA A A A A A ,B ^B vB B B B B B B C .C ^C pC C C C C C D " F D %D ,D =D FD OD eD ~D D D D D D D E E E /E 8E KE ]E iE sE E E E E E E E " F E E F F 0F BF [F lF F F F F G G )G 9G GG WG XG ZG [G \G G G G G 4 !$5" F  0/ =!"#$%# 0/ =!"#$% P 0/ =!"#$%}DyK _Toc449869233}DyK _Toc449869234}DyK _Toc449869235}DyK _Toc449869236}DyK _Toc449869237}DyK _Toc449869238}DyK _Toc449869239}DyK _Toc449869240}DyK _Toc449869241}DyK _Toc449869242}DyK _Toc449869243}DyK _Toc449869244}DyK _Toc449869245}DyK _Toc449869246}DyK _Toc449869247}DyK _Toc449869248}DyK _Toc449869249}DyK _Toc449869250}DyK _Toc449869251}DyK _Toc449869252}DyK _Toc449869253}DyK _Toc449869254}DyK _Toc449869255}DyK _Toc449869256}DyK _Toc449869257}DyK _Toc449869258}DyK _Toc449869259}DyK _Toc449869260}DyK _Toc449869261}DyK _Toc449869262}DyK _Toc449869263}DyK _Toc449869264}DyK _Toc449869265}DyK _Toc449869266}DyK _Toc449869267}DyK _Toc449869268}DyK _Toc449869269}DyK _Toc449869270}DyK _Toc449869271}DyK _Toc449869272}DyK _Toc449869273}DyK _Toc449869274}DyK _Toc449869275}DyK _Toc449869276}DyK _Toc449869277}DyK _Toc449869278}DyK _Toc449869279}DyK _Toc449869280}DyK _Toc449869281}DyK _Toc449869282}DyK _Toc449869283}DyK _Toc449869284}DyK _Toc449869285}DyK _Toc449869286}DyK _Toc449869287}DyK _Toc449869288}DyK _Toc449869289}DyK _Toc449869290}DyK _Toc449869291}DyK _Toc449869292}DyK _Toc449869293}DyK _Toc449869294}DyK _Toc449869295}DyK _Toc449869296}DyK _Toc449869297}DyK _Toc449869298}DyK _Toc449869299}DyK _Toc449869300}DyK _Toc449869301}DyK _Toc449869302}DyK _Toc449869303}DyK _Toc449869304}DyK _Toc449869305}DyK _Toc449869306}DyK _Toc449869307}DyK _Toc449869308}DyK _Toc449869309}DyK _Toc449869310}DyK _Toc449869311}DyK _Toc449869312}DyK _Toc449869313}DyK _Toc449869314}DyK _Toc449869315}DyK _Toc449869316}DyK _Toc449869317}DyK _Toc449869318}DyK _Toc449869319}DyK _Toc449869320}DyK _Toc449869321}DyK _Toc449869322}DyK _Toc449869323}DyK _Toc449869324}DyK _Toc449869325}DyK _Toc449869326}DyK _Toc449869327}DyK _Toc449869328}DyK _Toc449869329}DyK _Toc449869330}DyK _Toc449869331}DyK _Toc449869332}DyK _Toc449869333}DyK _Toc449869334}DyK _Toc449869335}DyK _Toc449869336}DyK _Toc449869337}DyK _Toc449869338}DyK _Toc449869339}DyK _Toc449869340}DyK _Toc449869341}DyK _Toc449869342}DyK _Toc449869343}DyK _Toc449869344}DyK _Toc449869345}DyK _Toc449869346}DyK _Toc449869347}DyK _Toc449869348}DyK _Toc449869349}DyK _Toc449869350}DyK _Toc449869351}DyK _Toc449869352}DyK _Toc449869353}DyK _Toc449869354}DyK _Toc449869355}DyK _Toc449869356}DyK _Toc449869357}DyK _Toc449869358}DyK _Toc449869359}DyK _Toc449869360}DyK _Toc449869361}DyK _Toc449869362}DyK _Toc449869363}DyK _Toc449869364}DyK _Toc449869365}DyK _Toc449869366}DyK _Toc449869367}DyK _Toc449869368}DyK _Toc449869369}DyK _Toc449869370}DyK _Toc449869371}DyK _Toc449869372}DyK _Toc449869373}DyK _Toc449869374}DyK _Toc449869375}DyK _Toc449869376}DyK _Toc449869377}DyK _Toc449869378}DyK _Toc449869379}DyK _Toc449869380}DyK _Toc449869381}DyK _Toc449869382}DyK _Toc449869383}DyK _Toc449869384}DyK _Toc449869385}DyK _Toc449869386}DyK _Toc449869387}DyK _Toc449869388}DyK _Toc449869389}DyK _Toc449869390}DyK _Toc449869391}DyK _Toc449869392}DyK _Toc449869393}DyK _Toc449869394}DyK _Toc449869395}DyK _Toc449869396}DyK _Toc449869397}DyK _Toc449869398}DyK _Toc449869399}DyK _Toc449869400}DyK _Toc449869401}DyK _Toc449869402}DyK _Toc449869403}DyK _Toc449869404}DyK _Toc449869405}DyK _Toc449869406}DyK _Toc449869407}DyK _Toc449869408}DyK _Toc449869409}DyK _Toc449869410}DyK _Toc449869411}DyK _Toc449869412}DyK _Toc449869413}DyK _Toc449869414}DyK _Toc449869415}DyK _Toc449869416}DyK _Toc449869417}DyK _Toc449869418}DyK _Toc449869419}DyK _Toc449869420}DyK _Toc449869421}DyK _Toc449869422}DyK _Toc449869423}DyK _Toc449869424}DyK _Toc449869425}DyK _Toc449869426}DyK _Toc449869427}DyK _Toc449869428}DyK _Toc449869429}DyK _Toc449869430}DyK _Toc449869431}DyK _Toc449869432}DyK _Toc449869433}DyK _Toc449869434}DyK _Toc449869435}DyK _Toc449869436}DyK _Toc449869437}DyK _Toc449869438}DyK _Toc449869439}DyK _Toc449869440}DyK _Toc449869441}DyK _Toc449869442}DyK _Toc449869443}DyK _Toc449869444}DyK _Toc449869445}DyK _Toc449869446}DyK _Toc449869447}DyK _Toc449869448}DyK _Toc449869449}DyK _Toc449869450}DyK _Toc449869451}DyK _Toc449869452}DyK _Toc449869453}DyK _Toc449869454}DyK _Toc449869455}DyK _Toc449869456}DyK _Toc449869457}DyK _Toc449869458}DyK _Toc449869459}DyK _Toc449869460}DyK _Toc449869461}DyK _Toc449869462}DyK _Toc449869463}DyK _Toc449869464}DyK _Toc449869465}DyK _Toc449869466}DyK _Toc449869467}DyK _Toc449869468}DyK _Toc449869469}DyK _Toc449869470}DyK _Toc449869471}DyK _Toc449869472}DyK _Toc449869473}DyK _Toc449869474}DyK _Toc449869475}DyK _Toc449869476}DyK _Toc449869477}DyK _Toc449869478}DyK _Toc449869479}DyK _Toc449869480}DyK _Toc449869481}DyK _Toc449869482}DyK _Toc449869483}DyK _Toc449869484}DyK _Toc449869485}DyK _Toc449869486}DyK _Toc449869487}DyK _Toc449869488}DyK _Toc449869489}DyK _Toc449869490}DyK _Toc449869491}DyK _Toc449869492}DyK _Toc449869493}DyK _Toc449869494}DyK _Toc449869495}DyK _Toc449869496}DyK _Toc449869497}DyK _Toc449869498}DyK _Toc449869499}DyK _Toc449869500}DyK _Toc449869501}DyK _Toc449869502}DyK _Toc449869503}DyK _Toc449869504}DyK _Toc449869505}DyK _Toc449869506}DyK _Toc449869507}DyK _Toc449869508}DyK _Toc449869509}DyK _Toc449869510}DyK _Toc449869511}DyK _Toc449869512}DyK _Toc449869513}DyK _Toc449869514}DyK _Toc449869515}DyK _Toc449869516}DyK _Toc449869517}DyK _Toc449869518}DyK _Toc449869519}DyK _Toc449869520}DyK _Toc449869521}DyK _Toc449869522}DyK _Toc449869523}DyK _Toc449869524}DyK _Toc449869525}DyK _Toc449869526}DyK _Toc449869527}DyK _Toc449869528}DyK _Toc449869529}DyK _Toc449869530}DyK _Toc449869531}DyK _Toc449869532}DyK _Toc449869533}DyK _Toc449869534}DyK _Toc449869535}DyK _Toc449869536}DyK _Toc449869537}DyK _Toc449869538}DyK _Toc449869539}DyK _Toc449869540}DyK _Toc449869541}DyK _Toc449869542}DyK _Toc449869543}DyK _Toc449869544}DyK _Toc449869545}DyK _Toc449869546}DyK _Toc449869547}DyK _Toc449869548}DyK _Toc449869549}DyK _Toc449869550}DyK _Toc449869551}DyK _Toc449869552}DyK _Toc449869553}DyK _Toc449869554}DyK _Toc449869555}DyK _Toc449869556}DyK _Toc449869557}DyK _Toc449869558}DyK _Toc449869559}DyK _Toc449869560}DyK _Toc449869561}DyK _Toc449869562}DyK _Toc449869563}DyK _Toc449869564}DyK _Toc449869565}DyK _Toc449869566}DyK _Toc449869567}DyK _Toc449869568}DyK _Toc449869569}DyK _Toc449869570}DyK _Toc449869571}DyK _Toc449869572}DyK _Toc449869573}DyK _Toc449869574}DyK _Toc449869575}DyK _Toc449869576}DyK _Toc449869577}DyK _Toc449869578}DyK _Toc449869579}DyK _Toc449869580}DyK _Toc449869581}DyK _Toc449869582}DyK _Toc449869583}DyK _Toc449869584}DyK _Toc449869585}DyK _Toc449869586}DyK _Toc449869587}DyK _Toc449869588}DyK _Toc449869589}DyK _Toc449869590}DyK _Toc449869591}DyK _Toc449869592}DyK _Toc449869593}DyK _Toc449869594}DyK _Toc449869595}DyK _Toc449869596}DyK _Toc449869597}DyK _Toc449869598}DyK _Toc449869599}DyK _Toc449869600}DyK _Toc449869601}DyK _Toc449869602}DyK _Toc449869603}DyK _Toc449869604}DyK _Toc449869605}DyK _Toc449869606}DyK _Toc449869607}DyK _Toc449869608}DyK _Toc449869609}DyK _Toc449869610}DyK _Toc449869611}DyK _Toc449869612}DyK _Toc449869613}DyK _Toc449869614}DyK _Toc449869615}DyK _Toc449869616}DyK _Toc449869617}DyK _Toc449869618}DyK _Toc449869619}DyK _Toc449869620}DyK _Toc449869621}DyK _Toc449869622}DyK _Toc449869623}DyK _Toc449869624}DyK _Toc449869625}DyK _Toc449869626}DyK _Toc449869627}DyK _Toc449869628}DyK _Toc449869629}DyK _Toc449869630}DyK _Toc449869631}DyK _Toc449869632}DyK _Toc449869633}DyK _Toc449869634}DyK _Toc449869635}DyK _Toc449869636}DyK _Toc449869637}DyK _Toc449869638}DyK _Toc449869639}DyK _Toc449869640}DyK _Toc449869641}DyK _Toc449869642}DyK _Toc449869643}DyK _Toc449869644}DyK _Toc449869645}DyK _Toc449869646}DyK _Toc449869647}DyK _Toc449869648}DyK _Toc449869649}DyK _Toc449869650}DyK _Toc449869651}DyK _Toc449869652}DyK _Toc449869653}DyK _Toc449869654}DyK _Toc449869655}DyK _Toc449869656}DyK _Toc449869657}DyK _Toc449869658}DyK _Toc449869659}DyK _Toc449869660}DyK _Toc449869661}DyK _Toc449869662}DyK _Toc449869663}DyK _Toc449869664}DyK _Toc449869665}DyK _Toc449869666}DyK _Toc449869667}DyK _Toc449869668}DyK _Toc449869669}DyK _Toc449869670}DyK _Toc449869671}DyK _Toc449869672}DyK _Toc449869673}DyK _Toc449869674}DyK _Toc449869675}DyK _Toc449869676}DyK _Toc449869677}DyK _Toc449869678}DyK _Toc449869679}DyK _Toc449869680}DyK _Toc449869681}DyK _Toc449869682}DyK _Toc449869683}DyK _Toc449869684}DyK _Toc449869685}DyK _Toc449869686}DyK _Toc449869687}DyK _Toc449869688}DyK _Toc449869689}DyK _Toc449869690}DyK _Toc449869691}DyK _Toc449869692}DyK _Toc449869693}DyK _Toc449869694}DyK _Toc449869695}DyK _Toc449869696}DyK _Toc449869697}DyK _Toc449869698}DyK _Toc449869699}DyK _Toc449869700}DyK _Toc449869701}DyK _Toc449869702}DyK _Ref413502638}DyK _Ref413502655}DyK _Ref413502672}DyK _Ref413502693}DyK _Ref411499510}DyK _Ref449774474s Dd0lf  c BADrawn\AXIS.GIFb 7)>ͽu n h)ϴRp%%Wl7)>ͽuPNG  IHDR$sBITO0PLTE!!!111BBBRRRcccsss}8bKGDH IDATx݉HEZl-r93QSt|EH*zoXX=/_ڶO-ѓun|Y:Otظ_*wH-m/WY;I2nxS' zsOSoJ4A˜wW97㊂iε8㪂s5#~۸}툟(RS͈*蹪jט;_Z<%mK\MmH,Z.Ktks5Kz+ TkAr6yU j8@T,@y ]aP= ښu0ZtAk*,љPdA}ܖmFP7SsJΠ/-ngPgE}=|(]TnwiAt;+|MоZ@}t4@ ha>jMP@O@Sm hFM.'W@I@#7UR#)kyuT,@T,@4R! SDz1΅xr'@#5| hO4tF*҄ hΗg c?hЀ˯U">Qp-gG^מp T.04H3 h?%@o(5ko=t4@}_* hƓy/ )poJz!<[\wh\;@HLg &\@5v!>Wiz.͑;@P%k=Yz,O@'P_e rOx|<QFz('O@ח'еe rt]y<]S(GO@?/KO@W''|;añ3?pl=h|=d\S?nΞ?l 軃f=;f;|o 'oR?7J 8 ?}qb<}ir<}e<}a<}>LQ>,O@ R'O(п(?G(п(?/ǫ õʅz`R=j]\O@X'w+W+*ە f=JZ|O@ <^\Я5<., 責'Ee<<TP1OjAwiT= n32hS0cU۝߂VrMPᬪ4-3h5ض7bMhUomq87jWg쎏Ή7Y&yjlc׫jn IsCՓo+\5]WOIWt,=0o^/^Y6苝f&6vJz@CJ Dߞ*P~zZ~<-ߞލ'w h h hyZnw=-O@ 'e"{ h h hy hq hi=yZVO=-瞀 +Kkҋҫ˞란;[f{ޛf޻۞ff'GfgڇfڧǞf瞀 O@3l'Z hn4vk hV4{SkS擇Ќ h64꽎.@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@T,@:2zitAXXX8IENDB`%*Dd@l  c HA$Rendered\HAND.JPGRe)K3gR;1A)#F9)K3gR;1JFIFC    $.' ",#(7),01444'9=82<.342C  2!!22222222222222222222222222222222222222222222222222@" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?袊cТ(((((((((((((((((((((( HL3G cGCi+ NJ1Wllr,$r)2 :4ӳ (Q@Q@Q@xE7 A,r?uow&;KtPk 3pV3(;wz/=J~"͓XCaƣ\ <MF/ZΎf  2A鞹.xiA^祉U.jV+V+(((((((((Y!X2ȑ,`qSIV=+HȺA(I?:~8+Gn~VI8ׅy_-(K᫭WZc'vگkw&n-Ӵ?Z_i'38z$khqq}{'ԟƹp6k{A,5SZk:((((QK1@$@!A$$ox{Iܭx.fo?y+3l:X9m>_+R_ޠIM@fXָ;b42;aj->4}}!G9OԊW\հ5N7w#cI;An߈.+w}^_xX HKx~Xs6ٲ!x_+-⮿$KHcqI =ztBaBvH}0z?x5-Ķ\@H)ЏYUOEcd8*\!Ѯ~*c{-2?L~iNWe+:_/ZjvJz"Lg5CMn9ӜŠ(@QEQEQEQEQEQEr1]_s.KfSkׅ nGex &^Rߒ8:Zx;&h|'p!,L.ۇoiZU׈uEWK)>ncGgc>Ҿb8zخj:v#Z[9dޢJwE~ngúKk!0̜юwU T`:W75Ρ}r(H%z=NO]{vv~Oyӆ}_ (ϑ ( ~2Cɡ~N.eS}v> pɋW)#hsW+˰<߾}. !f3RW J]¨kҭQJzh'cqj&5;PʄcXֿ+Hq HNASⲠ+[t2M3E8?4|9Aa@7 9S=r|3W巗v`i<=aR5Z!:~y46'.)n:~'oa'?yJ2^6KQ}s&-yv!8\ƥ_Q?2c$[q &} I"lWoOO}}'ٴR&7%#y'ocV ^;ˈpzBOxw#Ǧ؆ tf*<2z*v& ] D ӏyu֣t7<'M TN0xRX8uۀ˰8Ҏ[݉Њ%/d2YVsҼLW|0Ώ^OzTl0Uq؜>bj)iQ/{_s+((((ͶuAE?bAk76(g9;╵X}S~{j1iZtדr {׌]]j1[ ;8{tkWjwW&X;6;sZ=SOu{ a1mz2;qN6Iso$Nf[xJKя{` ЊZ&]qqʶ&wmEV QES&;x$V j]d}r? O6%a-?ҔI.FW%G\hOX\q6؁?tƳd-bAgڣU{RSokc`>GmvZyV|}|IEHfQJ1OE֖'($ȠkT+K Y2~?`]" D"j-ˌ${S(ƻ|gx@G]4v'5Cm̓:ƣԓF&jsŢWg+Uo]0)h:3=]|D$k?wnaZYkpƱE/9"Gsm KQO05_{ul՜4I<4,YݎK&ck(/ԯe5tlZ5bfZ="װ|.4֮7kA^#ZuKO!?z~g{W5 R]]yv>8A|&>H5X˗CYKN8߉&؃@{PSZ1ROq5̷7dV.zy558<:ҷSPacXj7Y\Jp}j7j߅b{?zכbte=^w֥:eR}/Z3,^2.ZWQEEPEPEPEPêa[7M!9 5_xGC{Cp~׎ q(z \AK$RH#P[91_ biiK c)ax^G#}p]ۗrI札U8_vk ]NRky!bw"lu$-(2LjEEr88(m/{8r2+yNmn%7+ʡQG!VyQjNm3*Veuj۬(,|kу*8?ډCRѽ+ҡci} Z~GSm-*oiPAZIlŭf=rء]*Sym)|k_=CV񅎓lv'o@ߋXbdQָvqjS.Cp}~5;JOg!jR{zi--\JV;?q{G`?~ᮮsIiNMGL ~g?\Fھ7%{i]Zn24 G^a{[8\P #"GO[~%KFcWl +S}zwg9yRNk>S~-kƾJj#1R}Zz{0E,$¼ =K[|<˅bxAe*?ٞ%$~Js_ ?xnu0J'? ]W>_˭3M$;G,uyS{i'뺹xwK+AI׋~iyZ~w>Y-Oka % ғvGӂUxXZTm?\ !߅ٗ]~}> STNqVPp~Q{(GCblG@ox2ٓ ; <ھ455 +k&X1q||'ވ>kQmq=N ᆋ׫QYQEQEQEQEQEW*r?H~@Z$ص\-?^vl턗3srY`slȊĹffI >[ףS[+VoM&m\_9/Ë+p7:SÏνTAdo|%ߒXGϯˌ5b8jZRf'X[_G|ެ·zQǤw)yqE ŧAv>^#!RזSE~OR)ڿAMrpcpzV̯W#5+65[ʶ&k$ROz69 + N _}&3X͝WݓzgjR[-?P#Xwdxz6bKrrAo7goQ#+{Cv>c4fqs<֦m_I1cc8*&ny13/XJV_Ƶ*uV*K,'*O1&8s2{Ȟ[=>!DXc,_bJ9Y?)ZާgkmSS$C r,*?⦼uvQmϙY׋,6uEOg;[h]Dz0*J(?%mvQE ( ( ( ( ( _m,fG?5zUq =0LT@TWg|,Yh9l-/ I!+sUeZcquPU4٩aiz@/&-yڿ(2嫼x, K3=#CVlQR+˭M :~ֶ-~ Hn}^OוG:Tz6&? sEaYFI2t "+ҧZ_I3ΫB'jk}Ұ!-ڴӅ@o9+SҜNJEnoHe FAkC (((ޜ5m2Bه*0*(ӡV5iJ-5GhݽZ\dWA:ҵPxJ:38s(mū$w|5+QEgօQLQL(\%l=tVXF@UpF^jH|޿6%~i%yj冚,^Ag185cQG+Ff!"=Xe&Y<7ѱR?*st.nNpzڡwTFv8UE*i>EJ܊:ڍƞu $H(9=c==Svd_Z~V ]‹hV2VUITQ24ӊ]4Vn~hL<#OI~cKfC\kD W\g5wg1:Z]TWial?匧8잣{WkOH_ɸ?^ >ݏ_[p3嵨{ޏu6(<((i-#C*tnx6@Z}1 f 2`#ˊCK~!dչkEOψWzdik#Z ?A޽N6*]BYlKvfj.@>߈-}b6+2uUZ goӫztWUۦ$Q׉)(A;) Z#|ğүBQwo?,S2/C%ڤn7\FmSZqkjoh =Ob42SWv˒MZ6V<*],n'J>[C'[9|)~ .iݯܖjܟ'śHьqGF .,ÿV]oaBT ֝lD%{/;EWxQE (E(`IQKڹO/8OB.u{(Oz`7tKZfs+|/!pdD_Hb(ӫϐ]j)51yڒ7] mG+Vҳ>\G^Ey\=OCƣ׎b?Ol|mU?4 z_𶉩d=dllW!|15զ:, d1L8c=ʩNM#*\Fm-/4U@O;Jۜ@2ۻ63 /zԫt=k7MRE5[{՛YGWuDpfi;}H~u9+=Db6:0;Ή#JKX! C zX$-_z?xӬ%;Z+կuA:޴L $}<2E}5WgNUܳEWsQ@Q@Q@Q@r_a|v'?u(>U1[?7hTGf_>L])vϟ(#)QE)i()TR-E/J?1ssy5W OGxM_1#l~} l+3B4K<B)"aF)PƝaµWƽWczxo T5+cj`}}KG1Z~!>tW( 7 fpx"cץP\#'_qFq۶;?H_Qa'O\;GjxGpi8m)zao ɥN9ʊX^rO3y_Q_DyEPEPEPEPTh>ӣ_A'UM;; 8It>`M cvN}*:TM]QL(ES*aK-+1Qy׏,P&6KK +20z񿊻2Y; oʐ1ZY%g=j4kK~i3Yig9:})>%?VI *BjYVQ0?r#~&?\ǯk[U_Czt)ag޹)t"-ev$Q;wf!*B-W,;t3YIRW^_>!bI֯}&"M\kPǵk:*6܋k.O^rQ(*+E"Ż/ ze\Zĺ/.dʳ*uե;lLp .è:4\ 5{YR+)ٿCһ#+u9R>O&<9a~&0PkUB⾂H _.Ra$ݕE%-lwQL(ES7m C,JY<6TFo Fşl.3Iݻw?XSc?g_2PUM}{&]£ֿ!aQ!f?묟E?f{V(@zk/0Zqwh~EWO}>4ӯ%$2}ITrIG^<}뫗wr,I?P*k8p/5fXhѾ&qRF}Ly_]W X;q$q$ 7ֵ^+F*ty2=%ѩS^+!{CiWpXKy57t 鶓%HAu=TGW#/Qj:ԉ,r{=}k}|f<(;ߟQE|QEQEQEQEQEQEVf+\ne 1_kNjN.u'N\m>keY9$o6fwM>I:U#OSTGQ]LjY$IۧTLB%ӶJmj!ңme=i91{X.iD^W \UIuTdxk9(>I<>V[;7֫KƮgڳ&Œ{ [FG4-5^߫~f3ϴ9NLּ2.|S61ơTnZ\RhB}yjHSM2DŚtɛjUѤ=E.herˢ)tTfCҶ#М ~Uj=?K5F994LcpO>TLQk 7ËF>M=)5GڧU֭%CQP}p/8HtijЇ?u]a>%լӭCR[#UٕE_CA/#U |^+V:(/S8 Lш Ug׮G[ٖ5d''~Ρk=\ƭa_VC.% O|Cҹuޭ(X3\95I܃IµTRb}N\Bw"]s<~iqX{+t*pG&n6ٿ«ɨtbi}])-mX'F568jy$<>Î4"%՗Ug<fYte-jVLkuz@jKs1[<{ %sܟZ׃w`K ¸25.8U,9‚jVw2 Wmi0EZXK3EWOtoƺv!ʋi5:iV^ڤFJ;:-wP*Z$c5+8~IQs)h}h!P&nT~&p(ʹ$TOTj}R%: +P~Toxi5Ec,4R^2+dz ^GU]eyĺ\jBkH໙K1ǡMT5F_W}R^Q=yf}No^>@ۧZZiJs[G sRFrU_Sp?ݭ8'Vlu5EϠ -TdTZ(9>{GۏlԱzά&}_Υ6QTpi߭i,0/N~T_ጟKTVf=sOXd=֪J*eoa.jӞGO2kT[Hz_ՀFK&L޵!4EQ|Qt&K'ֵ~iz~.eQ]J a)M]z x_jiz[U?}*SxCM7V?KseEhgެ!Xowpsp} fk쎑TwT:ȵHW#:jD2tpTe?o°gqinaokxm)-_:A>4uEtsǫIFc꪿v2jէ?r:m7`ĉ ([55 :>hZş~XI֩F _vn8*J}nnpJn NF?'0K*Uu'ۧ`~ՉO%%dzYƙ&>5(3o::yk5/mmiq IۤϖN=DZVK Kjizَ }MYK,WRsJb^(1]9ֺFKy~XzeY`Yye\UDӾYJ.["jšo!]HTW;[Y([J~Uj}PXi+Jf!~bNO=t$uFjV][H,ЏNJF#z 7^|ZыMApkGbJ_c,.LnʊCkVtTna?8~[fcE%I^GzC΃$>KTQXnHnƻn?=j# G K{ ~\l{вj~KxMe]=LANǟҔҊU99ڝl,cVs]l\[d/+)?&zѪGUnjOz5ZM21mlR3`?>*i@t?0+ZQrB5߳FEe&̷'/_t "%XL KEn6N~5-jJ-'Kڭh8zoZPukP3D/voR܍"@νT Dbmu#քi{)o a3kx$g5feɟF;q)E'? ?S'Yڣ<ˏZ8%~':':Ϊɖ(`  |V<2HCk vty1,r D/aX]9ZbQM7i/c\f+Ibҧh 'ҩ~?6Q[.f5IFMJKZr b8Cf>QkG'k jG۠Jl)Ä_k)qjecǧhbc"or?9U>Q9^{D QM[[kчj3m[B"=dO^UcT9skY].Orc^?[Cvie`(}Oӧz<#{Vs5MSWF 1gVp¥"fm\U=^;Wڦ_ 4fPw FA?Z.I0V0UWu=^S@`$ƵNEsQ6yY4~zjf/v/5E@U n#hOm#>ꎕtҊw6-/(=[[r3[&Ż;X7O(}ֱG FAd9Ȃ= 2~MnФ[^6X~!ՅYCn42UnSVеŪb?/Nz@uNRé}$'eo㛕v:N>K|Jz>jEU+*E7s?Lt#4;? HNcxɹwIfVpyaysJ>v?5.I~P*s[ay]dX0} -;sԮ%čy@F3AVޔ[+@"?ֺ1qmR[>T 1'ո5ݭG?~u2ٚGtrƻwwKi8C8#ubtP3YQ[q"i{ӆsC_ڮZq,Zd?V-w/W)ȭ_CFb*m._hDy1?2?)=QqZ3EN B в{8gxy#?_Ed̻6Z\$@G?h8z!c8ם3oʖoQ\OrF718qrE]9l&j-:KTyqt טjD}%Էз?*R*wY5Ro?ޫ9d/ffָf ?*hRN9Zyi?AX#Me~U'C䦘rĕRqaZmIdֳ,SjI,~~H`cK܄&mlCZ1 :QԋU1oc6o\T[cѴzf6yw)*&ecMqGi,nA['VD Ŷ@ CKSj3WC d>k">hskcpJAiR'u'k'{hا%\Otxs2F&p8?CVH*Pk7Eqֹy7?̞ݷ_ܭ\VG+.Be$jX?ڨ[E,ъemFz8*ilwjMPm~ |oH!Ե Ky#$Uƾ 2#rҹ8RE o.2 ǫeFMeÚY'6rbnڂ:i${W= rg߁z0]NqosF;Iϋ,ۃ3#93jdct+Ea_,}{|;gA52_ @Ko@~nbj qWmb'}NM@0ZMJ&}Ee՛.\Q*:ͥ>pLeG?w>(] ?yV3Iϸ?V9Iң?W~|=ۢ!\?>}+Qokm\;H[nE[}klqΟO*[џyZ?V_hǺcv.ZնM\?emŻtZi݌ƿW=|`х`Hu"=h]2Cn%c`uZOvza "*䢈3[.;;5͒}*]4emSic7S[2e=?֛֊~ji8ԁ)=Rtlˀl? Ī{MtDm֜{"HL{>b[̇L;}#nX/K/Bmwj6/.469oʽgFd dC 3R'\j ̤~u&b:ӯm@ߥ%(CU}Sh|ykxjimv_~>85g|F~6=v_.*!n~THˉ[3 *7:RO y\:l)yͻޔrqxҐΓ8./5)ZA{ߑ˩3LN\O 3hm:-AMI2 #Ԏ:RTQ vy?^CQg7:|y,O/8?0Z p:vw>RD0>Y y^\4_\le'q`^ߟûbIY=*p#X^v9'(: vf,NdojEJq~xfrcvvcQv8j rT.}κt˱{MoNE'êqZIη"3ᇉN8|Y_0$ڽuGtӟ:lK/2ϋ?Wx} {½lҼ7ē[x (lMIzFB)qk"`>oC>T;ۓ,_ʴ5mV-&عT,ǐ?];/yտºwhw:¯VogEA$[80GI+5;RK7{v_@=TO/j[MVEqm2M 5q_=x3ŷ>;<|G~+a`dUWGS592*A-&3u5䍽 l|pdͻhRzY7fE[lUu? \5|@0VKhPIu{kw<dV1#チӶ+WVVmxswC}~ߡ"'6:T}3[Fϣӿ'',=3¯|W|Skua92&8ocV"6%HW7z5OecWOY-s[Tedwv85n>/^3ӭ%ʼ[]~ ^(9X8jk;D G~hW; 7Go^tw7<ϡϱ+URnˠ=}WGw*lϱJA'L"Cѕ[᷊\4y|ߺmֽo+v<׹R!|8eR?+۾*\}~FޠǰW?^'`ʇ;9r⟼uaP$l=}ɥΔ3t"H: N'G$E.;2) ZÌPh4KcDI ?ԓJgV/8}*n:T؜?:up`9~w;kS'^8G"5Ȭsk[]+p!#~VI J:*dGZ3|EmHۮLS<ƾr"? [6 r5F|9-e9ǹ JG2J7,͸kݾ"Hạxx^'kuN#?gBG'dZtBOke D]9?q.NL6mbʺKDYi7'aa*$5z\4.v,M *\uv=zTۂXo%mԾx/2ڒ{gO-@ҵksX\8>،Z|R29}YugW~ӯbuoU?GT]ܚ9)u f>d*VQ} d BkVa.j=K&;̌:={YkkFٺzt>1ݷ́VE7Ug b8YgOp+{iLJÛ[c{kKI G^p |Hگbg|c9&&?/~W}BEztYUVF|rB?:\7''; @`A?A_3%Ԍ,ı>1nC+Qg<ޣ_?3 VlFFIQ`yڸddA^:/ kwb~Ct[aNE֩+W1鹲{Ԛgy2lhq2vAÏ\tqҔn.Y3k/njW`t2c`w4qIl?S*Frr gu8p?QҚA yqnʻزd~U%15G5Ӏ%EEVؑ:VɠO#kiB(&ᶽۧ}c勇m{I>hrb&M&`ڼ,rKzUUYO:H34ODD/4eN?L:g#󫖭A9?S|m=tF=֜K̒`|/G$-K L IVHx~^ks/ƶ_m?EB?VEX'Onh,V?\+>bFvO|V;Z6ڮ\q;MRsO_Ҷ?Ȝ:D?4"Gn=qH2܅nA86@ds)C0*4ildlz@@C+d JPJߩ(vP<{38߀(^$smx{ Zn 9/@7;ybhU_\h,9NjZiT2HN}M ?vTO9.s Z:X,LQ]OK' p_ʳE'<_]-HB/㹳VΝ UXs]ZGub TԖ5@Yһ#;~-~nqPHEqx)SwFn8銱ag!ybw=I⪹˜˴zXi:u%ڠ*?7^ɥj-}[ܻ!@$'aE| %ҷש7^}6v`|ߝpxVUN^&}bĶ޾y8ǓCGfc%jѼȜh?ZS^0OӦ)y`AwcѲ ~1`>,ug$TH%ZF; ^NK0p5?{ FWdLEO_?;(#ow_ 5Sx7|%5 NcYz?I~Hϙt>9$2?q?\qpNyNi9xTZCrOXn3RFSqM<RC*K+c@ UHAm 3i9'܊@gns5?K#Yl-rDow9Y#:BAd؉ǚ./ekZ]j׃-vx;_Hj(vMpXWt׼|+N#Ԓ7@y g@ڜQ@QֹLy[[9$0Q;>_Zx]n`s)nߍwX[۸Y`eLyNECm9aMrOt=FvXbnP ^:ʁE$kFEG?T+卆2cy8$֢bNG9*mW#T1AqD`sM NNE9JI_z@ږ? NeݞqM/ r3Kuqݞ>$LUw4 QkgLjF89)#%psJ`.8+9 v9>kc>HM PNi8qB{TL5 +*y8#)Ѻ)LORbY\ֽusZyʭZդ:RvmWkkg.6f# 5]ԩz31Vг%M=/-1Wba4^יۭHơZD:I6ڮ5{.m'2 M1NJޣu65h>c+au:8|څۛPӺV{Ss>5>RJ&Mc8zYLR-aSki$KdkuZ<8pU%)zTaf3Yq6}^4hҏSI[F<ePҋZ_iB-)SMՖ<>~uqW~P^p=M4ﴦoUӛQ{V{Ԛ~iJ-lr/u۹B ʃ]r{wl0mm->к?hsrh",Q ,}G5h-ё8E'8WU0i˪*|KZޜuюqfZ&7(Dgp)ZkZW;XWj9mIFo„Onݨ~cPV\X \~7uQ$kIK_u|[U8t?G6Gֿo|Ǐ]N?'{nG8 u6.L5)mF$JO۫r9' n]kZPy;+x4/umK1O #N1grVuԭ/{o4[#v}S)rsqx<|W'-+k?3x* 0\xZҘM/{?[pPkiR{Jmχ:mukcg9y-1Y2j[ꬎ 9RsWj[jpLQTe4ËDD|O꜈Б+ """! Bj2"FDdD_䨘L)*G->D*Em5Fi{kV5\QTN2]M&ؕ>9v-ɚ-Yb! טs%<(,$P[(^RIM {*yL%Wĭk+֗lt2ДXס5 g(VMGZɿ+Ӻ\qO~=~WLή7zf'{̶R,ۮw72_P_oY,칉ҹeMLҥJ3%*i&deۏ.yj3=)g3W5LuOdcjy=?MiIRwֵ#e+*+Ԣ3X)y7R>o?*Vu^Y]>#-#O{Hh|NfΥVQ㲔w(⟰f'OĨ˷g3vwDN O:ԗ}t~%w+.˹bn=|#0-ArG%,+|eܨQhEeGvyyKǏL-_D-zN$_֊nfGU9~ gPrjm&sȧr^Ri4/9$ݜWm%:KR1s_M-W"{2$&C<>f5I{#P6BUT=*kPgB_]%TʮK3TJ+o[dqZe<'s5h5mmo YwS9FG߿ң_SF*8[!-ָrW>j>96u{To;!d5eZNSڕE*d'( LmjaVdʅť)RF^҄$Z}dǐnsWmS!}FZkZŸE I=э>ʴo-I%]LqӃ -3WX`)Pz|:)|Z{/.Q^~N$KVh=y] %u"E$#UQc)mӿm E=I8+Utzn[|\N&Poǖ;%Dd@t  c PA,Examples\BLOBDEM2.JPGR%<nhR<\$PmF$<nhR<\JFIFC     C   @" H!1AQaq"#2BRbr$c3s %4DS1!1AQ"2qBRa# ?!B!B!B!B!B!B!B!B!B!B!B!BL6(1.q) MM<[ з} \ZV\]3>rfx#R';fiqCX*qί_1X:θQq'w"F9xQ.2GN.9*pv0;9*OS?vPiAZr~Vf([_KIrs >qX.mv.lukDLJ2|H VA_N馎l<9# ]!HVA퍍sp%hڇm:jGKu F7%Ry#\Y!pKh+Su5 g&W"Zj=0zS?p~!=[/ MvVw)_9Y_%?NT{m+ eDGŒ4:R[1^j:L|+!agP]nWBSWs }#䷋lRT[ddž'nY?z8RW zdJɢxdp!8vT B B xN{d K))!|=U`nZ[ .KKAijG!GO"ƹ,q.Nfy-=۱g?&B:hWm)7J${y NOX88^Lҟ}l瓇Ц-%%lYBK%)Qb8%IQ`2C(y{U]O}kixxX!I-8L#oWGGI#e aqaud2H#xkr" e[^ n̘_Q8әifw!.mqv4rٓۥN:JKPmwF|>~!r_N>r&Lrp<Vͬ=Rj͏RkްZ"[M}8{O& .4 h`m֕hN4&y'R h `*0=F2*JǨzr~Y%1'.cNXVu%;e5鍠818oyеǧ &[hdѵs^ 9x-G5v}W+EA̬KcCm\5+2hB⠄!BzRPi+-M7sIr\xu$ u]\4TJiaI^p4 O mwjG Ŵ '8xy' ɑcVF>n[G{tN?Q5c? `&nSjNNNĜL)Ikp =j[J lSbIzӂқJ*hqzATBTGO 8 2D ].j)*ϋ@RԵ:!1Ӵh>'/Wju52"D11\D-p"9~ǁ]O_i j)a?v}V[Ng0"x=D2t= 0T;etJ(j߿ i>jkFݝ q6R#)m) mr[@<LaThy %FBYM7ɵ2nD+|?E^;%(5(`Z )u찻F#fU^G^YNKv<+3VVu[KM;w%z?v&JB@! u\'J\o5p'q있듋vSHd=yEgp(ۀW]QvUTHeJ\̳fcny!:р6aрKGĶ)K^Ql ! i$OE]rUj 2pYN9FRom0h_P~إ啔F^zTxK5zO4s}Nzӵ9tLdau8є}iUgU5)ERLǗu2Ut!v~cW51}\:;+:l3`hKhH4BeD=$o)X\PvٮY$p-.=pk.;dc=ࠗy2q^gkpu$VQE#և̭hiazyY<KB˛l䦟CAɵrD/wh9+yE');.E㸮llqh52Qxszs 8 r#у,N>D5eBvkƭ?zK> j^SjV:ܭjPW7xVHI Ԫ!u ՚v$Uty#S,PҨщ Da3`๲glu<4i֬!mKhCy'-ͳHvc]`;GmR?dQUǼqdp ƟL*v4/r%U%[3>hj4>ir sO0Xdsd28ʑAuOQM/ލϑO(Ú24oU =sG >K3)v9C I24>:\SU ';LJy#YVw xm-?nBep> ]4J$A\[jWvnVrֽ}8pXG "eq[$U"7O ruO^C9NL(m~~W[Bdm~+lrP)ZɨjbB$rp9 HLRMSwj6ޤ-K\ƌ7:ׁ88S;XVj 5#VҶ&I\-~O ꓕҭx::X)q⓿ A`hV</rO ycpO0LpVWɎC49qfs+F8-OXrU)VOUPU4\!LkUgV:4}>hr M' MnscD2saR_Qg>)*DW&vOE@SUBdQx*긞)Tet)"fUDHOL,|r''%:-Idʂ+(͓ b@L'*h$J`(A%Vy&h{@i?74crBNW\@iJʚ9 9+?dM~ٷ)).8 $8K^25+!Oz읚fNYφ 긫޻OfhRq[NǼ?-5*|>]쾶P 47͹uRW_YW{Y$YhSPLI1@az #fS8))Ɣ< [ѨK=Qb>3`d=*ʵXUuXQ5> @7TXdN9t=f姮-H+H' 0V9l:|1MYˊYYcOCXZxGF f:qyb5*:܎im++8sL\k[g+uQk;9vT91D_Aߵm :Ob&2|,D4 T8]ٛy}u>_VMHWT㬵2'JtDYMLJwPN?x^;2Ru4nV:sqZVMwjjMK[BfonzZ{ ZcSVt~엊^ɸn'TeX˄e[!h<Ӎ@lGPVU{ MحښEiS[+`yzQ=JD_hsԺhȊly8%ǘ U.=zmѦd=1N2?<yEfy,cdV@Nm^ɧ9eHG%ɇtQS; vh,wzC=wvLl6#i6Z%HuKKOG9wpf,ӻwϑܮ]4+vSq ts~-LwB ђRZ\OI\Îђ@QCK US_0rjai%q¿1mٹcK^?#vU, |t:"fd>?dseiUI- –C7cG/!AھĴרZ.:7)tF9n~89Q;*4QНIni%6ƗɌއxrg4oV94>Jhu'^[ȧYREJUhDV/+pkAs+|ue$Oki@e+:weAs9B93GixrxpKm!3\tg|UH%-l$Zd8z((Xc"ut hۜ}\ybɞredÁy$@H6%+$I[g> ImB#V!$OfĨ297x`\i]b5ZR]v?W oF8&{'4MC#g9\+t|箢WOG[O-%];sA; kxDvW]vztћ ݊HK0$h `8*Y[F٬lfgicс2[2hKkމcZ \0A+ĩ)a,JTXւ8W`ٯe}.HIgx|Z7ߞ#%Nk:%rs Hg)'KI'7.nеڮ2i-gÙ;N{,Mo4u`F<'h/\V[!ƻ\$9똑{&㞛sU*xe1+i$Z_ovpLS2q>r VzH(ր[;6CwUkk7c$pt|}Vivcu%TXkUc4qqI cVCWCJ7yVD`"wһpswMo5tlݫc"޾_Vw1r qgIaЄ-&B-iCC>D eoR6?xzXrb5lgnfnp#@1-]1+eMf򖖊8Y(*@kê(ٖQx='/h QE0s0 [|{HZ|ՉuS/h.}6nt߬oD1(hގEYAՍ_ʝ.xԏ Kˣqk6Q4Tr{]lqGֵ$ߴ}i=':pI5LpAu4r)Y i%}z,j%5Lrte/z+KkV[Ο޲0_E4vفKFzcY HlkAi.vHN>OiE@1P kA+aLo{5<^/Lm?l$ )mI|%IGlrE tqdi8 e;CsU͕lʯiׇgp5U#i8phhiPRRzh#(ƁtͿH٠[ R9ss=IYEǍA`!4B!Xki+Kky0ջ9IN%QL2Pg2K$IAKsƧ󮮊Z)\XZZH9>0|0~p#m0O|U[{zUM9q=KY0#BiU4Vmbm3A$ۆLO7_kt4覍ѽ8/kIכ#-y+ 89;Ik}E%B:۳ҮjhYз?ykOE=9"Hs8t R@'h3UD༆Jb6%[K߃)9"J$').+ w$ۊSs.)i-]f澖Դn.1GxeW|{hUC[\ۃ4nF9SB׏*iktU%pF&y[}ê֋= :JH[ȣIIz]LxpRBh!@!@]iZ\땦 gw:w/ϴ^f1 φq+.X.ЩbEQmD ݍk:"Cc'IWU ^>LOGɲ?fZ3v.=E|q&d:έӕ?ݏOԨvG{GKoUTxw*!Yb.VޒNlng74P&CKBBj=T\uL'ߕCW̔5s7EEY~>iwκ⒂8¸Iz(zw jڧa fj߰-a\%T4xJep7f6宻Gڊ,|tm9}-KjZ_J-tnBq!B!B!B!B!B!B!B!B!B!B!B!!Dd@t  c PA,Examples\BLOBDEM3.JPGR@ |-7(RV-DZD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@Z16-/5[mu⺝Œ#!#r p\#Ln29sDH"ߑR%^稞/Z0.e AїKEڴɧ*"̮{=Cqnℭdy+{W]Ook^Qy1]\hj+R}_4DΩv \IoqqI+mO̝߸gN4Wcc[JqRVC3V7k>HDpGkN@cI럾9/n9m;⣚Zfn1[-.c7sȞU-UH\uuiO0 2CVZ)۴o& :\ܓwUsGvJҒ>압)^?87E\2MR#o[j-^yˑ#шcykJJmSN[= t7FAto?_UՄD]G,DDD@DDD@DDD@DDD@DDD@DD4w]ER*:=TdܸgѾ*Mr-;e%=!ǥ#?d0(n;Kz¶pTzH) )*1`3~jlPHCn>Z {u1nv#n~}>F7t8}e7&yF.]k\KƒI`/sv;y s+h8]chECusa67x nkZQ;^2O`jǵ8*JNds&otIƈ`xZnp}ٔmIG sYcqK]>}#Z-Gem%NelLhhd04;r:Hig^ַWT>8,FgɡjY:e{clf ]Y[i$O -1IZ)=UKEtWJ*GyY+]#r2ϲϾ>|`.z:Ϩ( 2~sḏyi[%%z"/^ :&}w6rw".LGѭo4HǓ kNKQ0~(kYM)}w`+cO\Wj+w `Knkcu2'ðcZ:AC Iߧo`{l"q# ]-W3{حֵlץϦ(ha ѱ,n ӗ{-w=r֜jE!JwC봎ݳa6~ !hemP+7lU^ǵ˿i$~DU&pGbcc[wLQSƀ1ejT7m7 eQkF5#7xixJZ+Mf[I`.sprOs`85y{ νc¤g9>k^ӜBJKj`W<ӽH?iچUܪSMtk:g»f?tk7+&uh`s- J* #h#ͪ:9[.9!\Z؅-];uV!`T9i;9woςFTxr|u f h7J:sSW4)ٜ7Gq} &7Mn6+ ۽wURN0iÚl|QNޒ=p*ynT šR '}4P:;;=p=aW>Tj$UWK--+?GZ|)ipF@8q=<.ូ;\T>a,FHZpA @g*ּ!TxcTa+#䭎h[54= #Y~C9ZΝarh/ͽj:k00~D[NcNPh7kZe,Tt؊6~@,י:f򽈈'JϮ8[#%eOSӱ)J!Vm_r8,Pm.5t͗їFOeWj1k fµW2#e>@%9xV4JɴLEN/H*Qm*ܹ8|Z"$usO?;}@$Lp6[MhVGgUώU^ZPVj bž+ӥn5QȝBh``:Sz]9]@sz{i5z }h&|F55 `$3 igt8&5@.G%67E,jsKKKic۲?TĨ5998ĕ_cUєsrmo79;%џLqXwom4I-Nq.sb$O@_>fsCņpv°[D3SV~0gݣ4~C[k]"c/^ ׭!-hL_7Y""9" """ """ """ """ """ .T{f-׼4F/̶ULX ڜ}Jw9GgyM8[*|i|YD;O˝(.8ʸ4ϵH^'D؃6VΞ?ԏAkN#r+8[z~E⵵!`WL%GߩUyɫ:.^,w܌>V`t`b,`n05UVǙht-%XT[ARcZ4 8@W2K]D>vTSϫ.G+u\>kz=dD^~6Li2<`8dypɡɪ]U Q =Ik䞘î;7-T oZS ^fnUz{"G;`ƹO[&L܈曊/XC(^qTEǞ$@W t8k\r\{c742:?wT~89iu nP1gֶxhj]=;SZz@sTQUbr:4}Y]3SnL šU=*aj #u DYGDV#Sf)A:R}NSw~XFoiph oV%UOQgQlyߎVU q*?Q_'X݂ۢo(eᡪ]n- OpK\"z|%['g~u>W]#4*VdA%n o݂"+U9Sߘh*R[$HO乻QZǞwGta5b,6]>BBW*j-ST%5U=֯#R;uٹr(c9R=td:Lh=…['55晄 ~9Gz1ۤ;nt2Ԃ7'8K_ X :(ܾ>ev>x]D*$lJ$r0i0B-k +~?YF&=-~5|+??""9/*H$yY 1Hֵ$?s4,st'Me93HnQ֦gu,lwxYb7mOvHOLbC&F= >gSif)4'd?dKA⮡{'wzXhJW#l  so \8]4?CUxS:epFA*H7Fcg%N~Gt5i伙fz|^DDD@DDD@DDD@\sq.!ZZ{W&&n-zF&{)]ZϿ *Z +-tNѿ̒OOѶF}Tu;e)+ |쬧 2<}5$+"͒b%Tl0/vF$esrkTb[f!}H̯a#ȯ ΟI[P0>k =ĎCai,,T}__ѷ[:dcj"rSJv+/ GIe3Guy dpSO wc-&kf9ĆV ӇWv+e@7C^潮!=kmo#XLcFx14*]$몺q"_㠏m%$-%㮻2k+/V><}:Ho%geANwBgxo.zsɂYϯKB.7)޴m‚V6>kΡMQ$>#Ns{g^50`wz0e'Ϛ;>!/?F4*o$c89n^@8iG+>Ξ)/wGu}/:G߱/ i Hl珶;T糧k.⎻XmY-խ,FwdapoP"+U]^舊H 'ŹS&sKA\ORŪ]w>QK#UMhH!\{y}=,{tpNҲZ_tƘ3 h`[.kF1,H[, {I( lWlukVzdlyF0N߂vFu>kb; ]p,c+5$Mpxp*1y+c$ OH>ȞW7|C^[p{NGAO`5-ybsRĢڲ/iݽ3٫鋞 xN wԟg0uڹ-S[ɻjf'w'?6 'DʛT'$tw 7 kp3ZpS=oѶTU˖PN ?Z7# 컑t.<1%yۺ>1'暶^{īF~ ~\k.etUWĿ7QK0BdGnZ5h}!ݭMxVx Gw@6珵Z逡җ$kZ];-w˽c)訣/vdp[od[p`O-A>D0? qyBL3ﭫ _ӗ~ǡqCvm:ŭwQHp_Kŧ]katT=R.q'e/DV """ """ """ """ """ Ծ{wNmpR!)>G$?Ȓ-ޯ+UfbH>G#pFA ©8Medd0FD5ԣ}.[OCÙsR39k^{Ա`bCq LQUݿYۆLtU5Ѿ/ft-[|qD$w~j!l;Ks|ʜdrBRdI^nk47PO18k'[Agtx8QLGG`$o߲^U:=U8jʟFJ#w./#XF8jʞ'jѷII 1z/4Zn:Ֆ`*sEc8Ol7PTL8ms2==P1ּZ O[n<F}w;U98uE6^^GZVnUR8y,!a/T8lC.?-|AT~.k@yߴvq .YZѼn\C]rT}@<0~ca$ZKGiMHވ(alQ0yܝI$ºfEv"""" """ """ """ """ """ """ """ """ """ """ """ """ -Dd@t  c PA,Examples\BLOBDEM4.JPGRe} OA<F9} OJFIFC     C   @"  Q !1AQ "2aq#3BR$%Wbruv8s&567DTct!!1"2BA ?4D@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDX_b4S^O%\m.rA/;]?5W[۝QYY!mKW 8'kA; V;ޢJE6vuO%B䟈ty=Sm7c_ Kdn&*]ѝ'aQּehg>V%DZD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@\16-/5[mu⺝Œ#!#r p\sGes成E%#$JQ<^I3U@af\ ==Kp/tiNUE]{sٙqY;6ՑHu]u>#%+1=yGWǍ^"Hꯜܭ>V@ƟdH6i]ꗠ(DL`/twrwB]ͿIZEq6?Sޏҥm)cVkIY =Xݯy#ҕ5 {;1y';~佺8tk!iilBC=c]#Ϻ4n=+#NZAy4L =Lꧽ%xʣtGR֕3zz8>oȌ<\ɝ+Ŭ~u5i}CTt07zklq 瑱#|U?ڛ-d[vJz8CK}c?d(n;Kz¶pTt$nth~jZN>J%ҿjq>Cdk^w:kUzB$sV@7RYUtk--Ӏ6 'y+vtM/q$5cZ7kIX5u͎9IoKzIP&6Z c  յNOdrns+GeqA&TGVTfq܈3?B%MGsGj3TTJ%Pҗ'v–4ʣC?q7|r+^ӮMX#g_J$OT1ki#챌1GЫӶld<8xrҳĹG:>f14ZIK $҇>XoB7,u3p7mR/>x%л,p=a+(:$9n#Ʃ 7|P,w|dQFgJTuBQR N']A/{#M@'Y7;XEGK :FI>'1P92jַom#?=:TI38h,g|*皎+#^2Ϩ3VDxƗִd`Xm55 |p>8s-U?8s4g3ͫ4bzDEDDD@DDD@DDD@DDD@DDD@DDPXiqm]I*ޕSzf_8kXHW,|(Y4TTcjT4jƽNW tkH- NAoҩҹx͵e#4v=p8ݺჃ?"?U^dZ6Tත}F'60 Dmų:6m4'9ֻo=._m?i?PO3:N+\d?2㝅d} )x{ᕎXt{0Z Ay 撉qV'K ڲ/T xp o㟟v?dmӲ>c/ovs֎[D3 O/osV戈GI#/\& z)q|Ԥ|+EUg£g~**6 bvHGehsqm%㓥sކ[KzP]M%c'ꭋǗIx&tOsSɣƒ^g1 o;l8oF+TYR4Ql)P  6psB6KL,4)%`cϳ12 9SI˨G5>]|G#4c HGT,t|*8 u)Nwu_Kkd1"ݺw;]s_T@g.dZ2mM4Eeŭ$_uU8A\S ^fnUz{"G;`ƹOfMF-[r".""" """ """ """ """ ""^giMczu-tԵp99eKT7 Ӷ5)10}]DG,3#Տ^q<ޚf(ih/ȩcLMʔ$ԇ-+5\.gWPY7+_%_[#z]f'5q#{-~eG8SȿzfB@ vOo@QEJi) Z伊>6Q3V* X뭀VN㺯?i.2B,rIe|#OJ-ZXC ?إD39Ggm棗Q6kw,C_owpXkbqW|yckv yDV(ۨ)ǵVoT UjU-{ZqoCW> y\Ba_ ;T""" """ """ """ """ /UMq>k䏩W]0s^O~_UYjxqjm||R:7KU\clZXhh(T, +G]k}Q66z:Q+)]ݫ[Kv+FvZk< ^tm:w |;qV}M rF({-Ի*7)qV'^!R_c{DZ{L {+&USk V00^X,:5ƺ9^rZp|{T~OS'TD]8ETEI+!6>Iִw$\慎{N> Y>aci :z4 ,FZ Hs$=(b=u&:Y#l̑eYA⮡{'wzXhmZ+X6< \8h~!Y8mue 2O`v8# *囊PqNA17GxsIopi Zxy/&{YDW;V~enl7q1z%q 9T6Hjɸ׊ک`[H .2֘/E}Ɣ^!|}K콌zLH읝*6'+b>+Okn E{gV,Oɵ*EްhQ{=d,|b,ppv#~dl\7 no䚝WTV=?IҰ>;Han;Vֲ#-k`=YsQ]\-3_x6/Zq! A+k@T2[4Kǩsww-aWg7^jgl7LsIsⶾr>e'f]ң1QQ䔌g=  8VϣK]oKκz7crA;/#$-T9Z˩u},/KukK**$cqppő*֮tDE$DD@DDD@DDD@DDnzznIe|eVعWk8d|S*>N'Wإ/nyzN JVKK[앬iY0ƏRִcEvbIed Ev7Y[oifgHWm4c^h|v{{Oĺ؎tA`2G!{cwciI\6p^9:)JsAӼ|W!'Y zA>Nw^VDøki` }dIn~ ],4Q@Mp:j0h,]mّ뷶޶'4u%$eݻ,R1Yy՗jkMvRQe8 k q'-u識 {4m=_%6m/[K}}{=> y KV@ƻZRX^M5_vɯzc0{Hq\>-QqWX۴Mx\T \٭h.8I+{ߑ9[@ݚЫn12ŭy@DDD@DDD@DDD@DDD@DDDA|r?CmOmpR!)>$?-_zRW5yQEYd|pF A_qs'gkae-ꌈkF2\$3'=9B紥grb9+8~ (k}ꝏ/f4.[|qD$w~j!l;Ks| ʜ2 I!&ԙ;Wq >NqZsbh9LUΜO 5tZ9QKʴ#OD_yܣV4Tgp5oL^G7|Wڅxq(տ3?Y?r[7S6 ~wé:@!f/\fkMۇZ%T9q0yV>޾vMuDc;~@3)٪Ǫ:מTdI)s@ Ǟ"Hϱj'ۚ1k J֪[5#o%<,%ӸJ4cX|Raۇ|寈5W:\,i |I.2V=ZrGd7 *[L8w'r{I9+0]?٢=Dd@p  c LA(Examples\HFDEMO.JPGR<uQ 7=")O<iF<uQ 7=")OJFIFC    $.' ",#(7),01444'9=82<.342C  2!!22222222222222222222222222222222222222222222222222@" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((*ү<:;jE` (mmf6iX*"$TU:Kk[i z?=k__:9#l緭sVݗ`exe_ҩ 8{cV4 GCr_`y3};u )B@$Ғ +𷄮|MvQd=fzz O?RY&Q5% #~(hچ,-d}2j'knE~`~Z0hGS&4 4!01W²,#"J8h92Aϵa[xOSO2W1ܝ@Ҭj4Qr.2&s$cjmc^'bfk~մ8hwه*%CsXv ( )UYz( Np \ J( ( ( QZRVL܌Ѯt>ƨ%nm+}(:+ZikHfڬ`isXj!y%AWg>4sZʥ7t*qǨ*)J"j(IsQvXmcSWG {io\pSZlah۸gvrAM6'9Dx%E~{Hʁ&>|__KKVtjQۦ:k*kqgRr39ǭuw{0 AP4Q_tsrdVۻ{M'͖ɼFq=+wBǑcLcژ 1ǽh.tpѐ9;-6{*'Lt@/$yfls$zR[xN&;7iKl jwzSQ;sD=5*HJ̿WN:Gx]4W 0.d.>=kR`oK!7(6lr>6//8Pzqo`Rvq9=ր)Y}n4vX8v t*XpQڅ͵+Ƌ& 9e&_qg)T!<;c=hbu tȬ@$6J#g:U;BP76I=\cJq=#H߽xvss4nzHkˏ2&aЅɓ#hhO(wIJKrvCް|5y6 4-;yy*{:[+Oi a+ TZmE2"G ;LbYy&Xo<T=jlզ4 .szZ}ƻuo$"Obr8鑓TV@ #^9#S;b`+8';_.j!RøH@S7Ux?1d=Br? zͦ5I!V(wE$/~Vvţ$ ۻ~Co#V?5~P SP%J0 <3keAD:ux,yC'd >}2?rʯq,dGlzP5!U3.`w9ֹ-";mRGI]5x `H'ߥqv~kdIXcOwQ+TT08\ 1⾹kw nd$d˜H]pC

jKmҪ2ڻy4+ɹ>\J?ǩ8.+Iu$!1x c֟u\FnI۔l;v@>Ai(mW$UdB@2JPp3pGe\؟h߃0k89Þ(%ffzoV6p~.Ӏ:v *[aR) ;G-O$X,ڀ7 = s@ŭsW fL8ݎJx6p ;aCsFq bZDaذ{wVv B076@,mC9gQQҍ'AHeeweŒUs=Mtjw(Ȭ^WIZ)9@jb2Ӡ*5uYw.~lcp=bTho0XcUl^!.Oʯ}A /s?Za(DLR㧹ңkf{)r~NHbsqki-2V >T€9-ONԠ.܂+462aǵMZLҲi,IkS:ca2wlxWqkhP\۔s)!A=ր%evVhہ=Nqrڮ KvkG{ASSNyʼnI#Ӱvw7?! D8gpn`S3 JДBrm#ڬ˕K[BwϖH?bjz$[2}2'(=|^OU%F%OjVu F{.ef yEWOXz+DYm oA}K–z>$`Yd!X-u1Vo;&c.K=&([j`3ޒ6!iG@VKu* ig55k7wƨ< `9+Mvx$ե/qgyu գ ylM9=@rZA@f?OU3-̏$Mӵ_+t`R%R}yn;K=J;gR?+cg׷=^[GrvFXqw"mkuoT\Usš7eX{vvZXDYFq(j=k *ս*杨5Xdf| tZH(1!o°n.n4d[Hl{KVDDQxr4vp$l5rۧ!@OnH6n\6A'ty鱼 C 6<[a{Q%UbsVj.e9 YV*1+R=BW|`q@vc[g`D˃ڱȭ2$X"19 {RRM#QX{]kI 08 d};Tԕ{-ېj]^ kI"51@mNYKP(^u׾2ўUyL&(v}-rsu&qJ<"%6̑" ~X##J4;5d"tZ>gs4df =ֵkJ[IYs?y΍ڛA \ 8<~Uy,5XǘaOW%1"Ĩ12*ڢn,<>/usmWd9C緷"4/{N$f9'=i|MK]\M}#'p%G@sҖ (X\?@ݮo+} b䝫#ִfKQwa~4mJQFW-; 2Mv^{u3yQ!ٻtRZd\e㌟58V4U.y9 {VWo"|;}b'F]>MX"z}ZҞd[TEvzzkR_ڴ+w (pCҳlC5ȹ`t}}fzZxa:v2wNǨԎ{qsad (̺C,0kU^x֖NW=+ľ(I" 8h :)qppZ!Ύ>~5wHW!A>wMҖ @-:yV@P^k ۄ-cY[ %#<^=3[N;XݾHv5̏j #y~:MD>;v]"M"?{O'I$&NPt }q֖deN%hϯ|{)Bd\VY>vV4rʂyCq,hTSڥeh%AZּZ qFM& [FIvv'XseE 69/֩j/k0[M|f5ku; ٮS٠]O!u=?:~RLdWjzdHo8<ހ)_]NJ,nEkc1G[&msMjA;[^)]iV &ea n*XaV-۴Jv\7+sʔPy$i5-NekxaN[USҀ6 8cvp1OZ.728:dl6qz^G} MvqߚsrEmaC?3]GS{ˈb;e>iK%B~ħC;WqZ[[l;e;"H<8tPcր)sES*2Fz銷&`'|_K <GZRD`|}Yc*V `ӓ[z[Gb:Hɜ`QKɌ;B@P9mcuy"'K)Z2?Xw`\9C <*wv8ma"]cҀ" +[5E$@v'M6$Ϋ,]1n-ck~dvQܑ[wwPʱ}+{q@6@Tex&[F9|G%BYRϽZԵi+6lKn??ZPz:6IՆI2e@۸zg<,m@+\t]>DXՙA*Jt;x%jecN+u1.˹5*b9d0kE%ͺT_C[g |IrѳǧnZ$H7r >N/mޔI_>V-o̧$*,-6Dg!Zn#JRy'hPyȸ(@] @x5r+hVgrVZͦ#d\\H>5{P-R>u>zk-ڊ8Pۇ9B{x-{jS60~q[ c,yWZa ~1$Z#оr?JKb,nL*@$OV9\,|6ѓG>jHv2| h->Kb S[و;]^gZZ@ZPπ׿jѵ]i,-/خImYrqcbHA-pFH2e|aTq\9 ;[+r ܮ+^eЈ[ o{4k>mvϼ!$\`_S@_'byH7t}9={D˹yR{[XuEl ~w+{+{[r0Mb~if-{U-lgVEy z Oyހ1uO-؄C?*n{+MoZ| Ю$ׅylaGAfoeCjXnE9hJ X@*-"3O}O)aĿg6Ɛghi3nh֧ӵ-mW͝UjWq]]3_@;WMc;OP]99p0ecWvl=?L{{ "%)xZE8k(ms)Kl[ A*^|G3 K%9[*/.+F}O{>5hѰ -ڱė>簠Y$F;qX͡EszvGXӐO ѣS ˝A5Z}wQ-ހ5ج-c]3֒㸊Ah8`ȮV;slN]؀3@v_9G#ƗVmؚ>PqHVbH̅9gTOZǛLJ|In.38=? !3ޜzT[hA0A*[k y)Hhc}Dޤ mgb_;NLZeW3b|9z"5`IB5˫k@Nf'$(OǩBmif2Y98~=JKղ p}K"cQÊβ70jܫ-*Ρq yrpJzu%r4,֑r9[ǒ,|ةoN_$ L`U5)UdLdJ7dtgӹ3Bz)/U݀SY:p (Aq1!Sú|grZEA'Ҹ? 4p6U g {עmt{1+1@ j4he!ysڑ ɾ2xQV%st!k)Xd>pO_U^ymX>o` ,`*[Wmeq=/5Ӭ1Z*gY3מ÷]wS[CGqLJN2<=O`=3v J:קK|X:&mJGylt -J/S@k0 E'bz4JX{پHEX ;Cl"ʫ/ހ:E"$PKS3[DX([=s, o&@ ']n!"?MgHjŗcՠ-);\'5s$,VP8,Fп[(LI$q@NJ5hb'}͵PYOh:.qֺNdl(np}Z{[Ž9kc*29&t^9fM3?5),պ\y`8?J t8P:fxd6*.e| F9'+By1r] QӵsjR4r}EP$ C˂! }c] נncb] g,-n~}S[;d;fF=:E0+/?j=׬T\H2zT;NB,h"sUX|dI#?-eDsc-y\ezә >1]MrGkʀ2[=).4t )2qԊ贻]3=`HmTV-2 :@u{QjĖ2{P r ((6teZ[<d S/Wx ׭:NL$|wL[,i@"In)F_ &8mzg[$EhQ9vFxh* *ԏ^SA+^\=g=*{$dY ) ft+#F3ZZչWz!/1oni48_Ct6zJiC1ִ~x-P҉sq)%C ڍ=TmI6s9.ٙd{Ö)YD7=ZOd6Ѷ@r(ՅRIrD".x8W;\$;9^+Wwcz]ScE"B]rGLMjZ}R} Gzs_\nZQG+קMj4Wq>l ~^_ݠ9;ztĎ1pIs-Ǩʑ|^+z[K#=J9gj7h~T3Dc9p+u[h%y[dh>֪җV*'@_BX rBj~+kb!.y2p?.B[hiRъ)I^eP2E\HF@MӭbZ!./ŵS18>ws^ըi\Cf,PFr]AR/?Zּ|3kN6ψXZM΍ .oNUeqZz֤۪In˶ubIDi}Դy Ttw:ҙS 8z{._&Q˩>VU dH),ܡo$j1ou$Zl:jطe1vc޹;v[Ȥ!H3g$ѣOu (z ݄v`p5s\%p%eᏱx>we\>Cu%ҩRc=A !k=Օ½;U0ʡB0x!#Tԛf{ex*v{XW͕zi]ML*Ǽ!`z^(Wfڔ3,j9,8x>tN+;cb;и<My~#c]β?y?YIĮ$+ŊLPŝȂI`mkw@ d\,sC=op6r=hR IKk3DF䵽v8P!YA9#?TqiWq&I*G${տ-"=F/bb?/=hZtV Fn1]o 1*q\޷;@"l3W4[y〻J\F(m4W3IZK05ۄ۸tT )aJR9ǵu0-s+a#NH>;$=ȼ+lobHIAץj%^hu-4b%]ٰWڥrI!q=;]c920*H*}G^ӛKmf'r$?@nBpniZ݅yZI7BBgOY^,!Iq@E-)"nאRM.%8m- +鱿ȖC$ӭ]’z4pW!a9c\`::푳gHczmֳ3YuP+x^]!NW!nrG\w^)Z'[fA UM(i/}*M7zRMŎBc5M.c^HU1@ E(8˜k/-P0tP_fPeK7MPJS>ucD cJڒ59 2j;PQjpx4!S)FRмቁac#x%p s18EfN 9CvuH[p6zo??ҷ@X˩y>uGy%HX@|a∴:U7 ?sC\csq3aP/5ܵKu2琗b8y4a|p o_M؋Of3VnoΟ`hrOXW;41\ӟ5,n£q}rYErh4Tv(\ d]$6FJ*Ƌa5v)߇#~omu:5.0yψsW+pwFg>? {Dw2}od![6r xE>4xkYWP1|=:{cۜ.8>o0lfǿ^>@x<߿ ; nF~hOÕ`e: ?(_}ʇK$Yu a.4$qEؚȰv_kyfBYg5E\.7sM$Qd$6l%j>_r s!NK,!l3+]K3 cùGe)\mc˹5*WP!(+Q&iS椋BmQXTrQZk, zc0LY,@V;m XXάZQ7BVA8p0Ln @/WQ:4`^X l,|Im).,^2`LeXEEPOWvGj;p9pU+:Pic}mUd2"k|t\h*Q d,mhG=; $"xBxpfJ$g,+li@a ҁT֑4qq`ZnWr\1 Md\8p>vŁ82D@c Ձj)2 =jЁ`UWa= [He9ʀZ,SՈh\5MQBxTp)E\,G@u9pi[ #c΁'9p|"S4/ict #B7Ҧ>PH0AՁ#r`xd5ȁaρK@z X<4G1́U+ pkgV/20p`߆ qJ7 ۚ㦈p8p~^_!`?C &0:W"f_ E0@?5aÖhuۛ\؉' W9?ޔ I;@o_.Pl9\d&KpJ 5K}ϒ Tbx:b둠g[LN/ۭj^V7;[蝠G*?_#XmeIl0jRCs2k;5<8Cp /yհQB;i/A_<#j0w3<Ăzo 2uaq 8A?2?xXv=kn E @xUrKrs F-Kt)VJOj6 ZfAWcL.o\ B ƃpKr!rJh* L ;Þ 3*d{126!r9~ :Sd:",Ch҇_J JťBu˵$藠#@=DNF}E|@O $}V H:P/"H &3ʏX W]J^ a%ʀ`t#=fǰ !whH4́Iul3 C됎9= KhEue(-d'AL:pŸ_)#fJ;2f@Ձ>1,}΍Qz^Ҁp?Łk7k?գ&#LUp`]Q!n"]1pYwC Pchm kU%ZZo"(!ϡm "Hm9g,9: n*9WKq#~܂0`1sy|*۳'$.>ɵ1.1Z7IG9GX,Pqv͘uj"?dzp힎==wtʀh%/[r],\w?[lwh`isł;n`ysӍ 7Utt`p^~,Mw-DsֈL_L|*yY+˿o[v pYU/ɒi߱K rCx㷷;P/:q0|^PKXx½=O׎]? %_.@KI,({o_ UX|I%9Ldy|k`]O.C-zd!79Jٶ/|T^~P{(@},G=`ACOhaJrh9O~K٧A pux``Ӏz⧫ʡhPG_ ; p op Ox, L0~qt$H:_,';) 7n   /"_L v&v$N{%Q -+~}:@l# F/B6`h"#8)@jxK"7#-@݃ `"z0^~1l<1V_wG>>dW 8OE])ȔdJ2%L @ S)ȔdJ2%L @ S)ȔdJ2%L @ S)ȔdJ2%L @ S)ȔdJ2%L @ S)ȔdJ2%L @ SIENDB`Dd@t   c PA ,Examples\LATHDEM2.GIF b P2x/5jma*!n$iYx#XpkP2x/5jma*PNG  IHDR@FMYPLTE}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}a,,,< 8Ϛ͈RJ)RJ)RJ)RJ)RJ)RJ)RJ%`08Di6ؘD +Aal?LuTF6ժ'Vn=l}^pl"U j]t:_+ZY'#u\#0} 0 0 00c0]#0}0ވ0܈0ڈkX#F10҈!F 4b`f0(#F10Ȉ1F 1b$`lw4 l!ڏӎGhK@oy/ p~?ʇ|{u 4@kz [{h Uwcg2O^m~111111111111111111mz3@fZ}~~Up/ }~'l3`]>!8IENDB`3 Dd@t   c PA ,Examples\LATHDEM3.GIF bkȽ3(,u:TG*n?v pJ!KB<Ƚ3(,u:TPNG  IHDR@FMYPLTE}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}<<¥,,y<4,,,,< <<YY YYY<<<҅҅Y,<<<Ha,Hҥ </C=DkߏӸOŎI޿zJ_^i>OyBZ-zk S^@Oy=jW@O[SnhE@O=奭)/iM)i}@Oy6S0yʷoLr6`>.Ӑ`씻蔻LCrǀipSp`S`Ҕ73dʛLCS)o0L` ;NOq=):99yM`g l&S~3 xw;~X<T?3o.&+߁{rqq= +pw#Z!#&vGLݦ;bZ6rdGLýKuĴۻTGL1VIsĴZ%j$GLͥ8bl.f &ވi;鍘܈iFL{-6bk1\K1$Z˒14VKS1m<T5錘IgĴT]2#jS1TʈiDFL351bZ!JMIFj4QsQS^]HMH =MVjVo7F3G3xI3G37F3G3;03?s[8/֖dtEӬT_*~ W&_J~%JW_qj~W_Q~%JW_1~W_~%J~4 C#!@~`? 03Y(^Hzeo;??fIܯ>]U];O/#w[>m>m/6 0k` 6L0i` #60h ` Cq6 0g` Sa6L0e` cQ60d` 16 0c$` !6L0 a(` 60 4A^$/ǽ>rڞiq/+ia~GhHBHIENDB`A Dd@t   c PA ,Examples\LATHDEM4.GIF byoS A]볡RU3nM M Ӄg6zg$oS A]볡RPNG  IHDR@FMYPLTE}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}<<}YYY ҥ,,, <<<<<<yyy<HHHHHY,aH<<<<HutVpwQ>cmfNf8v7v*l0>0~O&]o:z@k'4fpИy=1#zBcSGh>`a;~Mi#`)0S%`~ӎKb/fv98Lw [nA~c4/' B067`Ks zL{ L 0D "A:;j&`B$PwY>9ӻxNP0[sc:B`'[ jZPE!9:.V:.X\*d߼Sp`lz)~1~O׾69ӌt['Es"ҭɉHw)g=::?t[N 4=!ݥ C:JI5غL"Q0K ]~)t:F\ 5 8j7`kCzm*!=ycA9S7j37~GOܴ@kr~ׂIHkb⸣g}Q Axs5\ CZrY!MyGzF[$~[=G W/[s;CUkhٯ]{Y嵊<5XK޾^pel wdráDJ>@05Ϣgny1KȝWrH'}!›P +3:CUܾ:D52`'_] tBYE0| 3_4CIp0|1 c:: =щ'CG(YmѡVc~N%tUB7@Z!\J׺a+tkq,tD Z;Ֆ]q6}H;n"NvNf1mW/~.3T<)<3Tbty53P"ux)>:$^+""""""""""""""""""""""^}mΝԇͅDs`btVxFL6 fIENDB`QDd@t   c PA ,Examples\LATHDEM5.GIF bT.2k(y4Je5=n]*c+ ~T.2k(y4JPNG  IHDR@FMYPLTE}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}򥥥 HHH,,,<HHyyyY,HaⶅH<<oeu25<+d{m:JF}"]u8T0Օ:!>+KklD>PG4W/Cu{3zy.C!<%-ivzֹN'T9gO(*TOn7z:<#ZBL N@K-7GB4 9Y)rq#T=BE9͜ hdJ@~GfwxFjI̎hc-¶O"V\|c|/dq|SoYW4{J f FNMPO7oΟ/RO8_dzSΓ=)v^TO$`ݜzZoǃ7˨ظR8auCC]„W/Q̷{d֍d֍֍֍ˤ֍,֍,֍ BRԑD);-yuc=⻣OVLE/-nhioT]3׾ܴgJ >OhnO.M":9%3h+Pg@~yꁄlz*3z :NC ven[={_A5Ʈ1IENDB` Dd@t  c PA,Examples\POLYGDEM.GIF b& l&bgspy2E# En L\5A9Vel&bgspy2E#PNG  IHDR@FMYPLTE}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}(YePy<qmD0#xbKGDH IDATxv:E5-MIwܔb%Fx;֎-|R0d2L&d2L&d2L&d2L&C^/Oٹv{qew)?P#}a9U᧔>J'|ilsgq:5 NVw3D pEzfHF}-ʍGq0LU \l?Zn̥ p%Ұk9 q Ga0H1Bp6u4;Jg];:׀]Su@åOp:rn N0L?}?=~.o&mn =|V|m8X0HXAn ;E v,kAY @0S^S+" S &`0h^X}.$/9a2}u<iSh$"6_SR-Rh^bO똓) _G|9Hž/R<9y=IX.D:R-ra$p? ޟK +<_gzIF {P76@ij0JCJs аp "H® 1 +qz!bR-rQBx90JX/D,<@E4v縣=Ζpx ? V*&<@\Fv" " ]qsΗpxm (Dl9h$[H똃i Z4bDO|h%)Dl[FB6oӏ}P0JSR-A8W11n9w ]m "F %l cwB @E5>>@v m`M(a_!bS[E@\b-Z2-uJ}m "(a*fqv" ;m k%,Dz_R uZceĻ  q3x2@0h\P8@kQ­T qC"v@RGu}į6v"vwP}=ʨu!ge#] *u`4qi݅ A "EFv'%:_fb-rHy*e7Y.eD™L&d2L&d2L&d2L&d2Lnr+tIENDB`e Dd@t  c PA,Examples\PRISMDM1.GIFb r^Jry tSnq 693"5r^JrPNG  IHDR@FMYPLTE}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}U,},YYD4ڶ<<ζ,,iuiƥ$ L m yYYii0Y,@,HHyyii<ƕHHuyy,, } ҶYiYii<ptxvFlױh ;uoLOہglnͳgi`kGӎuLaM>X8/^fKuV| gZj9N /s#pn ˗[&?Y:@O  7MV/s %ȷfSzB`pQm*EpE~z=F z ?>w)#nY#cÆpM~S@85'>~u['~\sB&O o n>mI~ gH~Vil7Ro nw[͟1)NP74[jC~!)ݍcw.ڕol o|Oo  myv3X&ƠUr(Z Ơ `-F]+4d1=nl@kjLLGgTP0n:^}~;V+XRHl̷l&\\ӂ&Y?[@_8QP鮏\!8;xտ^z,P+瀪Fϖwo<tиzpptJ_TO iz1>NJGcLЅƥ#͠ _ެ'Ѕ_kM;i~s<#@0#@0#@0#@0#@0#@0#@0#@0#@0#@0#@0#@0#@0#@0#@0#@0#@0#@0yNf.IENDB`}DyK _Ref411675936Dd@t  c PA,Examples\PRISMDM2.GIFbV nԌ0Աk9f=2 Van* RVu8:nԌ0Աk9f=PNG  IHDR@FMYPLTE}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}H4ii y 0 <}<,@,yy}I߯n6 pZn_[;vlթXK?^}_ =`Z10f[s[׷dv#?z7%/%L|6Cj+Vٖ L\U͖k; .maA[]Cp*rΑieXfKu6>vvge#`|rAM]S~Vk ?N \3WN49u[yP@W{_PjfK:MѩYU X-Smgu6 &LudA嚉#f;Ȉ"W44vZF,birm/V^l̜d'7 h5AKN@jljMRm# vVרľ:|sj<9xKQS`g'tIy'P"k ۹nmou;xmbC.`i'xV(`t ]! |(of6Pz% ?Fx4*I8xガlf Q1f=?|:X"S|5CDz\de3xFRh#U!*sSXJ /ѨvW|+ߩNfa<}n%z q%s0),-㞀٦ /( }SȆCX/ͥq@?qK2?LΤ7EF"+ &0(pE,@mR-mh>=qiݯz#@Kd 1 |z:^xOÉڂ[NkdwRMRzO`$J'7rl[fQZV O JK)z}:#| { 'Yn"Lـdcx#' V?.cR4gـ_d|䰔[&06u@F 7:=7g8ܹ{X/dRӚV~@PZvDukTǖa1 0?l=6~| ݋6 =vθ\`Z X & ?-|K˰O͉GB!v؈$kLI=Toh1A^l<>6Yrz_~.@[( '6l$Ev,&`,Fr /|A孈' Ͳ;3~"H lkd㱸'v/Chc0M`A7 2k|9Ư aQf'T3y"v`[Nh6+?rRh#.x L'ZB(v'is1)b^lKxtzT,t3$_Ǫ a^I@e8qjj-АQE"hU gwAc˞?:pDͬk=X+wB;/7݋͛E6 N1#,ž\.m/ t *~t)1m\N\58nynf9k)9r+@.Y㬂Emr-\7 $RYG87 >^1Lj?bLY`aGJǘ碕CEWYp lcI+ Y6_(]ڎ.b)n\O5 XRLye"xubBv^ZI@X*ep}!XaxJKdz +) 90a;/kȈNN|6KjUoe[@ Ȱ9fKd< X;/(\x4]؉rKvjv^UA ݷ ,bwԩ\4 VW^ڹ@@RūR;sch`#] *߻YG^ک M.[=I:2> *n,spT$ Px-`C.ak^O d~J~[ {.J&2 Yј wp:y7Иq\@ eIh:\xGPl? B@V.9ͷ/E) uG@|E# Ict7 ˩^"@ZN0y ݎ*&Fa=#D>+iY3#\\ʒsi'n S~jxUZ=&M7 ޳ۉ^ݮM :ܹT[k.x6/ `^(b_zqxGO*"Dc54_M~OWdH-o vtوX*m+j40LfW1ۣπ JȻtq3r?~t{[& S0ힻvq3 o 1,Gz޳E.*a\ܽt08qk]Ϻfi/fS}@Ar"h kQAOq!&㝴/;~6%٦F@`4hSٻ=k|%oO#ڊ` Cjk+yu?'bSgjA ԔRH\^WgRL..Pof5Oý?c:}AOн8~~z>>%B{40cZ0a(l(lD7KxaA "CC`/5R^>=IaQޝ00ANED d vnF}Ra]NuS׿h'ۻhhۣ^~Qiu!蝜Bq@k!#⏠77o〩EpDӣaf%bF_9\#}<@$(h`8&oXwx80tHsGV}*d%:_= {ހ${?x$.@ȬHnu~A[j|TTL=r8ƶ8oޝmXp5DOJϽ:FSIҳR{|y^ 4POzM<~;4}5FiQh` c_CoiܾGTY`(uedro&/2.g5?HNn¯yρ1 i`_RLV_Ӓ'~۞=n`V3RB2Y.Ml`K>Xnn/rOE8>0K@@7/᧳nWՐEw2 k6Y^At}ӓϽShfK QE'Ð9Լpʋ3.f|UmOT!@ L͡t3Y+o4RN@//@WaR/0zgOe_Zo5q9&> 5]CAΟnX9 =9szk0)ϒg_A@`A@`A@`A@`A@`A@`A@`A@`A@`6mIENDB`Dd@t  c PA,Examples\PRISMDM4.GIFbZ2kp-˜znz2Z2kp-˜zPNG  IHDR@FMYPLTE}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}888eee000⡡ҍ楥ʶ겲DDDiii$$$]]]}}}444yyy aaa,,,LLL<<<(((UUUqqqmmmHHHPPP@@@ ^FbKGDH`IDATxoȒ+Q{{wzfO#*"lFd$*]T+NdO$mo_=f1Tbc3@Ř* P1f1Tbc3@Ř* P1f1Tbc3@Ř* P1f1Tbc3@Ř* P1-tǛ\8Mt{o+_Sxgߧ~/ka5i=\7b_oڍGY\.Zpϩߓ0,8;|\1{<B+㤯OƚνWZDƷ5 ~2\,F/N~QfUFL#wώvuLT;ʢR"Ft<;|/Qn]~&~P8/&i%oHk;XO7J~+_KkwEeh0~>aEκ/TOzۈ72+s;BʰsqTDT@ͅߋ/H#MDB*RjJoˈH/6i%=D{^YH,2J;[څ2$.\^"R}KɄ?\8r<x1S== tᔋNHty&v'ݨ\x⭼U&[ TIELxhՔ [4H* 'v%S9$01oYY@ԾwYn9IބzZ7Awe}\hlXGlJH%ԝd?]av[pO#8$ OucBc>k}<HL%F9ݦf@d fNn湥^H%$'!\L@N4U \˺%FZIv &1axhawcr h6_ƜvoT-َ,(Zh4Wul&JCWI~3,+[sQ D@*!4ʪEh/p &VB7X.RiCjt8H+ޛ/u_p";ҮY\.0h+!J~_(_ pԣukSs;)~g2֭R2CegeuҩX.W?^LZ TBXNkydi,H/u|6/:/.9ĩS-s"BX7ʄ,q,zTw5 jn-Yu1W؋X uĨ+>nm꿮'X̦btPDw"i@T Fy*, ș[0ђI r~~F/ͅk-pjBűe "h#O[-JGK$5xfck Zp'WZܭ.ĥE?W-QXkWv!J+EzZ{Єn߃L@smK;׻9['%y{-Y\ZSs^o0swS 9y^\O@++Mcu1/LA~ͨO p{%tϜbkqѷs\C2Z{l\ᮞ0"mQi/6 5y9S~c7rJ/9;Ѷ`sfg1]:[õIYWX_YO+.IF--fi%wf|H}}q`i+PV$ i{p 1? A3C+8)}b&'xӄvI?,T/&`*Gq1rܟ؂& nNJsZ/ K* 'hps@l~<>!b&`o}XL'Pva?no`XqXtP `O)k`Le`aPQGf,ڃY3E r pMj +Ĕ.c>GU Hs[V)J'WKH  xh?iߨM ~Ct**ڐ^`/Ʊ#'iӐG.nē%W[d) ƌGAcqǷ;^& x9D|f~`9Bn4/jJn|'V(7@GxXL&b!挺  @0`dJ몭L~JB;rpÉx}0/S4qW1o#UPڵ&5hMi~8HV 4shTL1z9r{r tD@ >B8+5'*;5,фI'?ʁ.5:}_/H:HCFu5NԄVqrf aɎ/U/.6CB+/%a= 09~,GI?BTC\L>sXPi!o`/fr#4|\d.BJ=,]j\4!JB!ryaˍGp,&0s(7M*R\ TeͿ}3| im`E.@7 +xJ{ۂI|ёI-Gl8-ؼYcwluL}E[N~7aõsh%vPR#) @+@(z}19LN|$^ -h~nu7˾HzrÓ#qSg߇4d0cF{bbO,rs\d-v o%ݏ\ј_[Gcr%;<Ա9B9QzP:&&GpC s,}E0W*'b#J9XK<; g(fNt5Bbv9CPUߢGkT4 Pf듚Tl>;WagjB`xgZrJ n bYͅޛ C 1%p;h*OjP+rpĜkQ9hã_+;gjyU*:lد&5<:قQwKL=Ioc `5(u!*:9=[b4JNqWvwZ~B$/ ! ~/LNlc5 c]X)_iWt;ӛf:0[ZxŃhÉ1SG}ٹ촫jhqyYS,X6   vQ$m0͞2^ { !G\V%љ&(`mxjs8}VXa%\֫Jsra4؂7W Tpw'l^V 5s!PёPG6 inDV 8Ri 0r1b/:-T;$ŧuJV)Rbe.U7lq٠$85? kns7+cu)]RV m Avgj72{,K_5=%, $4ʋ@ §ߘ SPRv6Im.T ۂXڠ)N,=AKC[]=nxe%1n@ jգQ0eG</uj>XJ[bRu$Bg0Jx[T&d SG*H &+:h%uD1ó\3u`GppNb>Oa"S qFHggtR*E[R1*4^9G[ 匋΁mx;Qv@aZXJ.x[̕AB͙r"c)F]-\с"AMyU[Ýb;\[ks{hf;Lr+`C7OX7M3m/ܥ _<} $8@SA7nG@~) rM0e0ɾM̍nPⷈpO ߆ bjE1oI^-:Қc-^z^,'H^2kq_&ȁ,A\z$Z2K-5dT Rʴ_sLl.Ohj-EEXU[H3`i۴^9R&Zf Y>Iw\TLP3޷ iÝoK"$_:Dvt"`K CLBWnlI.ffuIet&nA!o`N~2 Dvcg(?Ntw6=Zi0afUzURߺz%EҘ1C_WR E7MY?V2;KEv[Y]/ta pk$mo@2KKcJ&1_nTq\m4WhGּ0Lad o~@a#zJeE7tYdӒ6{VG#]߀|8K ?1fd5wQILU7t#eHM`ݺO`CGG:F'遺Of$]>6,>ԷƇG-H~d_[Bے JǶBD}%~N3;R:[m+ߡq4H5 5i9O@PKf%B_>,f1Tbc3@Ř* P1f1Tbc3@Ř* P1f1Tbc3@Ř* P1f1Tbc3@Ř* P1f1Tbc3@Ř* P1f1Tbc3@Ř* P1WUaIENDB`y Dd@t  c PA,Examples\PRISMDM5.GIFb6X_`m:M0ΠnGG:A!{6X_`m:M0PNG  IHDR@FMYPLTE}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}Νޙ򶶶<<<(((]]],,,yyyLLL 444DDDmmm}}}UUU000eee@@@888HHHqqqPPPaaaYYYʦbKGDHIDATx{89}n (7'$ ==` `6%Fb*vκ=vs®>3g)νYzdq8E+Y#[韂ozpx_dCRiq6q<7}5 =t>I5W_V4 M#c(d]W[?*< Mib8u9ԝ**[u|Ԭq rynu{ X<PВx8l..)槚(>ƶmXd~sB:`[=׻^鹒Dhqa:2 vڍxʭS^(E8PxCg9q/귛#pJb:hw۶kgqvѨn^ɲ ^n?bPmP<̦ ?t21L@ut `DnjVyAgY9h8TpgYxb _5 YOw@$ %2Մ:bXD܎Ynn4M>x=>%@ٰwx"0+yAb$'SE"MTyebsyD/KӀra]r`0^0mJrnPl76@G i)O*/r")w`XV h*c^gP5ќ`SWJikkك4$hEW\y-ܷ*҂$(Ça;fN˲m&ݝ88%Y T0<%Pꕩ WY[@W&M}E0pM =Hgjuq>oM4g˭vb1wb8QֱRw1+-yY)êt$FΘdй^W#s@ٯ[5.Ecb)|"<悉:T xݡSi|8Drq#k5bb67UyMS2 j;PNa PbqCQ[7>@i!eXWO;22q& Zp| :۝mك2zg` ҂*9,UaLIDXSֹ K; _巀v#¦Jly]plP43R*2/ (Hݸp݂ P_QΒ dW9jX=Վ`V0hOx{Ծ.FNeXzEvnP p`"Rbﶀvqr;P2Ϟssve\V0{K& KMVx`E`JVgZ@8* 96p(ѯ\e;@@oY:J*%AktwKЩ 01Y5;"( lɚmޗ_D<YS"o' .1| HVV!bf?aZkD?]u!kfRQM|y^qP0_\9,~W5ŞAW25.{0y϶[{? Fh(Љ @;UoTw0'$4I6R^ kr-[AUep"mF.#f`EQv*-F(ϲD8jmL@_MfW|FV*ٞ"U$O"}*f;lO]W5x! HQ]ﴇ9V0h3I;1̖5w¢Z@Q+ |ދ.x> jBF2 $Cs"hfՊ5) j4CNpJZduD b#-0VE OoW>C\Ï${p+Zo L:MfR `Ӯ]AS*&A: `[הZ+;nD&GB\\z]`an0 Ԟy,ax}@ l<˜ڗ1l*ð|͆0Jhd]#5z'(/1 D~E(*1td,tWWfʭ:LeʰE6ZT`wrCg# 1q2"U} VE$> %f}VHM! &ԘxgI[,cLֳZx犮b.wwck :/|خ" cI`3SG$ӑQʛYѡ5?mߪ/ryMV fwd5)3_\l^WUD"wWegyp# 3-nz?/7a$C if'5$Ө== T4Gr:l!X0+<ؗ 0gI/-?I~a(՗@<FF^f`dj0ˤErqEFNvVc3hae2M{4Kg`Ycʢ cGWvI[#C~Θ>(ּSqŗH  WMDp{Ķ ?%k/_Z{1?nߨR'$ R4v Ƞ8.\gUX a<ύ#6E]>fqXDеC;.U]f*V0ZE$& nu{3>DqNa38I&6- 2w#*[ RsY$:co͝cMd'|2P+. %Y)Y}zK2V*rptP rK 8f-3z˟fLtF0L0/2U)~iGezY c"Qk2Ù]_)ZIȍSl  -]fdj9G0"LdUD`Ng9,ҡ挖$smfe\lc{fp^ U `[q@Bz5ӸK*O fU 7+ [AoK=&$iì:VeؚdyZIh~BP5ZA=3҇GzĥavRa:,dul &v kīigBU*L-f˱{ w,l|VÜE%^}Mg>mVEiփg88jPu/0 1]tk Áw(aO!k{U &A-w-b| ;̽oў "vkT}WFg#U&AR{K<H0@>@|q=|8{vVs vpc|qซwnUE, m.xǠ !$7+ać38oIx;{[y9N|]*I4kw?Pc܃_ 1#M$1DX`αr0"$A(5- ܼͯ+U0)|wv.f_{lv<`1ny!Cz*+Nd<' b &5},QG$A`҉PO?" Imw'[IT*U"/ ),GԠ[ߎ.6$}:+t c&LQFHoULfAթ$H=Z丣`a9Pԣe:áUI 8{XйgI<-:?#I~z3ϩy$B40eqeѦ * /.pReI p&=ہM5*s=<^\,&tN%PE,A}ŭ`#z}b(W_}F/(0DJ"/Pp|OV=dxIu-2ϫ:C|Pd\;HtE/짯$=ͣ>^>#Ś<ΦqbI-&aPrDP m>/*vyjF}=mKdtBV/Sc>jiI)Zf/L勞R5y`| }9٬SI}}[}Rzy׷3lPUc}2|j/sEUOj|D c(Iu  f:x/k w ~$JъN|]l|q","ccPlK > ː$:<ΩAW\PJU wTL%%1x~ O~W*;qMd`Jz#_Q^뉐+!شqB_G+jkP 1?|_GD]&Ҫc9VqXIۺsͯܗ4pa7܆wdh# R,Tnb ZH pu|l,_ҥ~ ;`+V(KzqP%^+IgPʨRl%[uw5@'|s`\NZPQ<-Hͯq \5zv1>\܇x\g_+t,e͝ƩOޡ>=\ !~%CW'`1VF$ZVL{x.Kw#M ߩ[+Hra1r =<~ pVKAh'@C|t4[ ;_| /XPL:J*J/!75@ 0*x ?LRlvX(C¦==Q,rrmrc>V ˷NX{ck1$߶ۧ?~TQV;N{:fr]#YI2}6l ZeXJ#UxY2n;ɘxx3 ^<7:A`ZY<6QdXLd 88wn tzf&%TFUOz=dYg$Deһ wY4ǷMlhsReb6 Eiз++`l E83CuFjaA!' <T%1@VVw:c*erָ82w.n"@H ivX8`經H6ڐLUaASkuH]BqۺzmHo m<70dX8Sޡ iWG78Xavv~ י@RBEJd:oˢm;$ xA.I? c|_/ $Dͣ݁TCEZBD|`Ԃ5ݒZ SBm^ [Uߺyo9! e=>ov -Z1z20X9Ǥmb9- E z1nn&&bXO~>O`wZÚ_m:&l.' !Z Nx;5{LJQkoцS ?Xp|DD$} 4/{Q9Gho7@G$ t9 !IEf {ٟ@Jw:1'+ ,)q@#DCcbqJ d`/&Іj&$x< tE ~25;TD)ez&4 le3x:'T; Bx.0o5>҄Ғ׍399GXLq \Tɛ)U4|d&BI(D%3՚d I`Ak?wrRZ[6bx2ӜB j0;TmX 3T(DfaoCtrbL`*@Iُ =v!))>Q=x 5M4` CI=x+aVk=E8.PPNrW0oqfrtU;,3y}-+'{5$փCMɗdD9M Gl?,¯׃}g ;Gv.2GTn.@!ʉX҃vwI[nr(I<=s-=jj6 _]P('`'O < ω %8Nu0'Ugz&=)3qU(cԤrܖ8 /(`/^ZT Ԙ#s:7&1'Zl=ho'I+A1'"aH􎨚)p;D|+\k&[7n P9]9~,?ꞈpo\~=nz1xDRl'o.+ntTJZ?LИeETtX|YbN4JN^rH@l%啉%^19؆t:]RniW^[ %5( {0׍=vJ.hU*Z:7vLX;)V,5Htv™T$W(̾k=#.p7I$O}U#ljMuqY[!Dɫg Nڂ8 {.؂7PVjmXG#/.EE͜}H>W`t%OjMeڄ[ rTnt4mrD[0iPR8S:l]3Nme!a aE(I@ &9IC6s!Z[*&%GS[&xC/jPSUhq{E!az_4%'LAAvgv?roKb\-Ǫ]-զn zNv6_zRD]^kU )+6蠕 ZІϏH:HlE7;.@G6W(2g;t,}@!UírhW蕂o3U`\qѩ؆~`BF9!G5X "Avd:Lq6:3ط[.G5.H@LDp_i) @}ɹSo;8p^=%2[0`bgQ$Lkʨx,.2dn6}3ph/< O 2 +0tJ_J4Lk@ “N wДjSF톑,mbawɴ>1ґ(\rݬ0e"fuH-s|fy/Ӟ5eV&OU{Dk@F FE M`47VY'LՅ(y`Op1&6,pOM|%.&|Q"|tcd'![[nIp ~'IN iD[zRv >{1yQa$vr9aZ:]g 0{`hV Y~)n0vM nOm̆Dz 6,vhS̛7c _"$XmWSșPɯ6%qseswf2G=@e/}xZmX~9 #g0')ŅY[Z*Q]GcWa4 f&@E7Ki錦jE\F>GfY-@QHȿBY݀@_pOAz9 D&8?U& e$!&vOmNH|WS$@Cip n` lI'L~`#:O|Zm?e\ScS +H윤+EkۖnHOMM[Rsğ2޷ܫQ 钌 4cη vB"Dv9t_E"i#_-gLtJ.Saosğ_\ sZȮ6G/lҫ09O!.n1R<6ڰjsUJFʋ#u|5ffKꆴ6ھպݱsRVpVwK5:Ӳ7~6lWN)wmi?XݯsGZ8I6#ZQ9}RPL̽Ifط_І%WC' /ZM+? 3T26`J63]$oG6IrYI ͋Bv)y3od&.ΗqGfü|&O\!6 OӊOfdH6/umYEI=vodR Jg{qG(Es9=ґj?|ܢƤ^^$崜 ||4zf5AJWw P3 @05 P3 @05 P3 @05 P3 @05 P3 @05 P3 @05 P3 @05 P3 @05 P3 @05 P3 @05 P3 @05 P3 @05ԌaV,NIENDB`);Dd@n  c JA&Examples\TILES.JPGRg:!J!-irF+,=C:F;:!J!-irF+,=JFIFC    $.' ",#(7),01444'9=82<.342C  2!!22222222222222222222222222222222222222222222222222@" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?$Kw;Hԯm*ťcOE$uK F <&Q.?Z]NlqjvIk;1+,F}X`1şw8s@ E)>U?84E5rƀIf/}i.䕘gSwSS[ѸM2 H$oH5i8epy@N,ƚ>e?:.~Xԩ?;O''5+\@}UIUXC8'9fʰ?cqG, ?Wb ) %vPe%^OX̌X2Gr bxuFC=gViGoC*աFO/wC +=y2GOR%<}JSliYF [;ʳ\\Jʑ5662 Fir#a>dD S^͉P ʢpqn95fjWg*40Q}|c/qY#!]v$VFMkF7F7ZStL+`E'@Vn 75z-- Wֻ0 #Nv|eu\*K^T)J)*!W,EumI`WS;{6MKbcOW6x:MKmPlQM R0odzym*周^xdTG5D>@{hշudL$)f?⪱T Kw>~":,ogWoԦh[N4+ծ%[d{UVgbŘI]Ѩd:qDR!╍INd5w Z̺<dy-n @xB^#BI+Xާ }t,Qs s/SΗWxt|J%Y/ǷJ>B}Z5^@s++O OraArS+lϧzam+"u>^sy,I\< `q RNOT$:pH36ȡU7bmqswܺݑ?5\6RA&TFaSA++ڥ&]:ݜN^6 =~\1lkG,.Gs6?wazgq)yXc.1 'AKͯ+7X MM-kۈY#]>Di+ k'kn?u~"鲺k:Tv'tq9 Ĵj.tv73g#4]DO4jkJ5eJКWGh.MHNJGq\8$_oC/sJ-1ip(.Fv-y)58d(F->/s5"c^}sBFx5x$$zTXRבʍ b©>Ysg&j_UN>7Vr7!Kc+Фٚ)//#=F:՛ܱ,k2Q:ke]4CQvTrO_EufȰL5}OWՕw'=wo ZX@)T:Yr6(:Ͼ)˨X_].ow'g?M!2Cκ2BpIQJdLc`t>X 'tO@w*3TZD&֥9gM6xN;Er5xJs0@`sWus#ޛrت3](RR{.7OY:ӶE{]9ﭙyݑW+FIq}tfhRX͟ϏT-^8Pi&iHc^~@Xc閪#o_Al{5T+CU}}/r揸kv zZ׹IwLן@| ? ,:[3Z߱Q/QVHISEu3ٗzcx&R?7"mH>GԵ6Ȓ8O񲑟w_0(e7\AHq-&4QѨޭs[f[@QNOfE?ҳXW+DSdQXH>dEs]c8 k,lɔL`LvFm$U<Cqn~ fv?ZetSZ^FvA< ʻZ'l=[$Ͻm\6dy"VrR0~? CYl?)?ST&H<¢ǰI?Y8AZ6nǰx܅Aֹn=iy~4vYGz֔N=kٞƮ9$=04Zfj- 5xVM1*N'nGW/?C^F9Џ$ﵣ]:UDqarjUңGqO\\l!}t/daB&u/#\VW{xN$ܭcqv8|rn.AAZDPwPCⴶ$p?S\_ުPe?*iQ9dؒHgHOڶЛH^]؋ahۦ?3@9@zT2J~{q])[D=[jbm |%̬݈g84F? TQմ?؆Sk*i_,#bبKb6T1CyRv(jKx\M5k&+N2S]A Hj)5 hңMU cDhᕲ7O; B'\t;*I5p2ފ)-1Er&ju~ R}P0*k1S%\ԚOp'{;-dqPOe2#0?*&o'񪏧}F|{w*vID ǮOiѲAǛfXs?3o`UVӬb2?? kA _^ӏJ*Y.k6mnK+o|V<*/GQOIh"i% !S>??JMypJG.buQQc8 -JQO@v\}*/OV">RXBhKrG>R(љJ́RG%ܻ7jՎ( 1h=>#EFO?P bq̜Nr[ԚQVY<)LzT/c8kit zLhyvNgVЯdc_VPY;U;i x<;\?u@ cڨvxr[!D&ʁ 3QؠqQ_h\֩#>kLVRmmޑ 'J⹭6)b@q^2wlaGպ зѴV u!ԮGm'1y\,Kbv_Ƙzlh:"Q1#kwQV=uMI w\ٕ%<£V]vFE_uP*fl4xTR\:Q :İ,&[ &$q}E6*F9=+X[үicaY}#+.;aZWX~[X#̒rWn}AomU][ۏ@ dBFN< j,Ĩ=twfu0]d5v8sԃ 5MShP/~@1';ր2U?*U|w{Tҭ}ҳ yJPq '@h֮ zk+,( dDZ^ՀlOF/I;-k>mB=}V-[Yʣm>ʀ*/#PF?ZKk֝V%qČ_""Й#;p>im?&M<7[GRqתP./)V֗GacAި渕TmJV^twνVT^j .eQ byY~͈n%TO [ߒ!$E+*&k(?)XJD=]{XޡT~\9\+[$ dS豑Nú1ַ` KM~bcLmF~\cݩ @~W^]co˦+"k{9䟠x^{dU;x.@9jS3w~U,R&<4F*6s{*8p-| U,@ji '>YTFYBNEԔ\E<=W\ӡk}6wUoǵfj.URGgl:vEf0Jy?o5ˎQ?31Pq4Vыx&~M_=?*UXOFUú}hg,3%E=@3V*jPHNGlwȩq5;Xvh j-$}=? nnc&V8/U; W Ǣ)5Z9%W8)KTټ>p#'Ut-T0k8+РTԈ?wpje֯5 ʛ.FvrѲ*խFgècF8=w?ҦO>SܘF6ܧң7'?-]IiI oc *{g5 e<4x m;cּpc>?:iSXh}-8S\ԑL䕾G`-鴆jCa.ѫPqNUL`=ԬP}ۀ*Z}A~v1?hՠvÙہ՘tؼm#S[#BEIo;:FI(i'1+_N?夣Eu3 *_~bH-#mSX-n$!/ |,ӈ܁%FV8YVvy5 UӤ"((&\4k \zbXɫ]ar$S^p5H[{C8 dZl{ ILzMΊ+Pj2ޑ{FmbT[B#6;LHT^M/O>oV5&vv9Lڮ$n?,>=s\3.ОaڿAY 62v+S t5dmbY簐ӡ =9ʹk@FQ^v02=!yt$:늁R ?g=q)pU5%J(㊿g^I\Co6S³uN:VۂpseUjs巼k-el1TA |ZƷ2b8}7ԥ4Ǭk6;I@ffx"ޥM]X<Ȯ!oR2?JA_F\ <[U2d$w68Fp ׃Jg`іSљax~c*&Y=@Uwԭ;#UkU5bg82 t&3'\VcUT_ ~Q2[^w7@! U2]iOE[E&XV|Jx~VNy>5/T wf#P"\͖SjrIŸ Է!rJ#_΀9֊N5,W1u5װg sMl&)3-H;V\{HOɴM<Z83Y"2W 1CQ0t*34{} LKr8ꡚYpA^+:)5/v́Yh6ak+}|q*|0#ŏՍ]Mf>&`?KlTD$nzuU%2>>kI$QsQ~l-jA5kuQ苲Gy8?Zul:E#7G7!Z=b,0 ~u\ۛMƥ+H#K}jWCj<&>9 !=ӗ\X5]]I8-)mO [+~8ު=p,'7C k`#MBx{o-xqZl!CI"ʳxhiEHѝBURP*pibl_i1?26OQȓϥ\9t1Lrk*+9.Q~aҺbtcNDz3KkYAk#?EtRD<.+*]j}{(vk #W-Y~p}G5 =MB+d5N+dAwr ?d;F5Ѯ.0J pE򱏺}NM 8W{ŸQK6r&QoO8&qanLS'BVּM!Z@jk'PfwS.TNE D8>خ"Ēm;(;{JdrzU~J|oY K H=YUW5IK\w&F2CQTCHGOʭm>°VKlDžg5 >|7=W Ee!{W5j]#3V,kҲyǨSJgnUGGeh>cPbweģ"om(r;EcP2/oZ_q#nImtctNC2:TMc8+FD9 \=E;V*|k6Vk$ iخc2OcUnV6'T~|stB]Keں΋ Ȃ I !=Y\a-R1M,5#TRxI8sMm>ݪj h𞢵46\Q"!=fp~c{(frp$a[Hf"Z[D{f8Ca4tTB=r42j7gSqGTtD9\\E=ukw Vv׭lbE]2J/y 0w. evїbs[tS\I4waomM U2/$Pvzvr#EAҡ:c늨,;`v4ODbu ĩtX\X۴f1c>\Ey}j+HdXe\OnhL3+0p@e}e\>XX^3FxH47Sˡ.t4i]_]v\7`pS~5&.fK/Qinr~TF/Cj:G\{*ifG !g#^H͵ic 1-PxMYKX\L(z MP 'P}B%u\ ڲH젚KۙxHN(mMZ' q#q~w<ҟpb$TKF?Z=*2Jҍ%IROt_ʹ (ֳ?$Q]1PMh ͤP<@+JcRwք3J@zVƝJv"DyJaQu8T汬ԛµ\+h"2E`]I~:VO(@jevR0NJג"&e`?c~f*q-:rZ,1KaƜs[iOZmᶺhckhN#M4u~>tF^H' $ ;4U.5 [flW?&CMqu4F+BY€:-8W?QϦ\5 lW}EYQ8$Wܲ~Uw< 'n9<\n5żaLg9sur#e,GCYv9Hpe}gW#e4>8 I>M -ru7duSV-&8k[Ţ/s7<=Q?YMXQRf'ԟ n!SJFc!XR+"Ug3 å>g#>ҭIt=ڧ5,E84ކb3&C#k (dGmlP1jڢjI3m= ?i[= UzƜ/ TL[_UJI( F}Znp_`VXbh0&N8-%b,mSh#([b2~ӟV`?]-$*21V̈́Mp֩#s} LbRYWѩ3U&OuPѪJ}jFHlV|yW$(<ާl߅:=Pr>GK{).jxr>loV5B-1i\r0jɽ_P1N])U-vlc`+H5҈T2(5o Y#!SG_]/2E{tB=7@~ku>bF@Ƕ:VAd4 Q.u70xERI q"qTV9lqs5q.C3yÎFEW}^a?5FkH,TVsXXPEd.O&0GN V E(n$`Ƚd(qVƜH+.m9do΀)[j|cG5!OAih138"1 Ҳ)NKfMAKu5j6QO֨-)s;6l_\sEs)^t(?lfՐsX~VV-zP#lS$[Xd$D`GK pag`ZLiɦɟ@'#Ddf  c BADrawn\SOR1.GIFbm"3 =eG0#^lI"nA"ѥ je3 =eG0#^lPNG  IHDRWmEsBITO0PLTE!!!111BBBRRRcccsss}8bKGDH IDATx흋,φو(;lZ;J3V I ꊊ&BWT(zSM7 T(zSM7 T(zS" 4v4BBdP,X",X, FWH!,UAߔ>uO\/h}t*N]u>L F =f6OEو>a)%f,k㼃Ya idu*)FUQyfwlTk }~eYKwcY4r;N ,$ N`I@PT+rf]8+{p1D"اtמ{V1C ]}g&O ~[7E#S ޙscyA  v;yyse nr ]WdELy*;(á媺+(@FXTݺo:]5֢H10Ҧvk 5r<Si51nh8%C n?Cx:$z{+-J]rjN$}dq3:TC z_Sqn'廹TNre<-{ Kk\Dw̮!@\=cJD.?# /=jTc]NC- qfG/uujiOz֛!16_]U@B^rQK)")6Wodt"N O!@QȫsdO|3Z~EQS<Ă[$tNN=qJ%jw/z=vbpvMc{2jn'G)8f=c)'cN1S~ѓ:ED/;_"f @XNe2D)"A$,.ROY; 9%ן& : a@; \O.5Ӏ`ID]B)S!iDZU"W}jLJLy@D"xmZ1s< $-M;v yNO"NYLDr9A"l?;Ev1 DB,BXL b"v? !ː(}Cvoz"w=vo,b/>~*c{ 'r]boE@)w A٧!e2&v1"!@mRb. LIڔzWjטR<!v"v!f& D+\ ?(JgDl5L}OT&1( 1u5V;`K/2LTuCVϭJqQw+b$社|` EB:L:zHdEl "t%4 T o6x C¨v"HQ#_?8SngNJv "کB0deUP\[brf+b+vWf# Enۤ )bSmMrSkPВAiqAt9G6+ЦR@|F#j1KZ`0#%\@Qqi1/M:̶ uG 26N[(DRAT8Elr;딛x 6N[0$Ѽ 0El]"+sn2mզ7Xea4cm PKKց# 4?߁V9Gi} CJߢm];5?{?!i_dXK8?9 Ig|̶į[SoW ~QP -cF=^rTqd@ ~ "lɨ2NuhFQ* u 2N%x{5p. 2ȆpV`F %yr= џdIRA6;@Xn6B{s %>@t*;4amdgrq#LT|'--9'JzQB9cU1!} q_rFf8!1`g6ّ  -1 e©ohp!fq@轌fI !#l;i+Hi 3-ķ Kf_*6|} .2 `Fd[aY Lt s;]boX-u 6r8Af"fFQp,&<5c}/NrzП=UA@|7gW )KL*|eߎr &w,]bXhA&RDSY`A< TMG{ ˘" bCjj:Mk+(RigЪ=ok**)umι$^#b |e"7+ ]l1¶'@Ďp /)l(x[]"ۄ-K'u3nmن)(dj+o $Gl<./kϗ%j?*!,@@/2NMj?l@󍁀4O@@{^TX e+FbE?מ8wRрG]26u D`(HM@䰻y%Q&COs '|{Yn'B'0nE=p0AQfO2l$[T7i / `A7'߾G# gvrNa7L(@1k qSō8D&! ݠKtV̨@4PgnD/K@Vn ^C1Lؤ|MY2 Yn(MgX2D9ǔ;_{Àp<KRa`KjxcD缗T ]\!x7+MndYF;͒?rX2*tQyhoYl \2'jpSj*@(E*@Ha 1U@2C USg(@!yٔ^ɰ Ue^zsB]P"@z҂Ѣ-=S"D ѹ?D]Q@ yȁ"uD DڐXzcSTvw>*@ȄF1e B b^*@,m"H9ĿND"@Y1.@lU&@D́ H bX[,@haYUeD 4 A  z)I"S@{fzާ,fnv|}Y,ao>P@5j !zh (@( x1U! oϦ0`efE*@is4TSDMs_ɍ[x ´e8 ĭTSmUU@Dr e $ 4Qe 4˘,q!VDT & B۹'Q nD ? iĭ 9ޱ I_Mrbq[_@HW^@@QܲV tw*=̱.}oO#Ws(#_g:Rw[)ZgNh!n iVxv[;O&V3xt:^X2/I;~5d|Y5 eg ;p B3C,4o FqTwpɂS3A M"@Y1/K8%,@( fR4PY {vY)P"HN4G"PDZ,́p-rBQUD;K@ * Bν΅Vĺr )@+ š7|2b-Cj'/Ӽj(@(pjZ,.&`W[4$gxZ*@(4YR"@d ~Q k!:z*"#| ov!~ hN ZX׬h4Au+5] ֵ|jsvY1kGѿDUXWmWZj(@@'yx+D qo$tpJ ӽnyNoaџ*<W;ba0&ﯺ!Y) 0,D̈ʿVMt"/6ĪE  }Q>Stjq'c$E"4]c4u? Ф7 kh-K2JҷEa4$j|%Ċxb)t 8;)PJg P-z@trx}EfC8U'>DPb*@8a D!j N?OfxS T/@|p !9M#LxD*@,HxK3vX n'LPQ"=n6]!T}vDAIa-9sUdo I5-EyeTX}B0u/?.@D5IJCLC}j֫U#DU`t\LeH=, Y" aP]. /25d?I5xDL PHD@h:k7␒`?4 m B(\) o> cT6Vv;Vun{0a77,eq S  B1)c\A|w;G0-D ,R@+M0٬2kt+;;jhDk LݔS)62`i`eo39AqqFM4N D VM;B&_L[¡MUQ2&sZߴTڼ _'4W oL_]z0F8ɦ'MpKRh $N.ys8+@'K,i%BjẴ_+Lj[1n9=`U,|L ;xT` @UUB۹mh<n۝P3NF;z^ ?^ͺj[ٸsS1[},!@pD^Mn!} &V@Qy3űT.U[Ҿj 4I;|Eb]2{yEఇ#2_7CpJ_Z:D'!ۖJq杖֞( >\PbwR f\)WynEq;9ºkKEquZ)1-ttpT>lоljTrB*82az&]ч`!T8GJH1n | 2oaw]} A_|dj{xl"H[}鬦O߯ɨ$Y.?]FBb/_.c A@!}W\!!m'n_| ĈJˡo o:E歸|< " vNUs5R\\HB}2\"s~ ^*@z 5Fك'k9]UlE |o=Gt- q AzaT=GOODap n ɟؠDa[`CojDj<2Q7y I6 ~]2[>N;K ,@lVf@ *@lUVJ c9p1@\~☛\FeԻ./#|O"Ϛ?=h!#*Ϛ;}oF„nÏ3*~y~Vq Q Eo*@QDћ Eo:1wm}9RQFq>lePt Z4"Rx,CIE8G<݈1Õ? >@#}|QB&v4oԷA $U?)ӣuc !PLҸx!g~eT_A|eD\+3 ^i{OOaԓ`l|X *jRصEm]2K_(+fU%-uv.>@]<&QF}{ ȷ,{RZbkS^F*:Lo0j]QL̎BX4 f0o^-#m"_|kxto0jϬlD8y2 "z a:^Q%YyF.k=ّ/hǨ=˪[+a4\DuD0 gaTL/T+$dDt 5|%&Q>+/ioriȐkGIϩŬ2Lq(n43.EIz2.*eTQ??G"^6>|Hͭ7 T(zIDATSM7 T(zSM4 缙tTә RS2ƪy7M2,[U>Gn!sҹ9*@ @DJɹ+nmD[d WKlv.,CUlU$S5 *l0!]#L J!7H }zX2 jbTDkLhh5ُ0UGqyyDԈq Z\ #V6DYt"Rߺ]sEm-tY=4m[7 T(zSM7 T(z{,?ZIENDB`}DyK _Ref4116800432Dd@r  c NA*Examples\SORDEMO.GIFbQ1IļSqA-1v;n%1 㝖5IļSqAPNG  IHDR@FMYPLTEPDui aqmumeDua]eiHL]]uP]a YUHe]PYY e( ]$$,HeaPYUY} a]La$ Uu]H?}~?O;+zޟYKr<}~|*_PiKѧpDKTD|>D0Ǥ>b5or*<-z-Zʉ4s l8lA K@8?L<Gx9x$'EIAK~!xONpÆO8?S& ;WӮIϬrD4c[ Uz%I'xԂiHjn+`ٸ>aX(KQE(Wn/o1 :W.vFvd%'*GlA3:W<(Y'b3 x,1i<|dP>FFb+q9lj©P啱htQ}fH!BJPÃZ"4 w6Clw f46d{C jn!ud#I3,98$\v]7Xd,X:}5@K.>x^>!@1v!"jT>4NHht}Rqڏˆt Z)ςsѤEJQ p NmNzQQLKXe uN!*e@7*k"Pxdfکer IP\{Iqzi)He=]"s{-H@ IbC{ /;5XuB/%h.p|6wS4Ƣ (M^n1ҫ˗h{ ɇ.Ma:3ž yw9r;w _c>~(R҇q- @΁I8o~:pUV㯾x؇E{xX׌Q~R0ՔB.bS^'}[x >kq 2pL :/\"J,vşgZ#!R<~)  +s4'/^+Qp}\u " @\ûd#}WƅY ߷(b6VH id.uOn$deq߬{jϵk5'O9{?EF W Y~؂3"JM;͈FE1Փ%[9M/\ٸoі|ƍޑ*y\ 8e@o|GEzΝiM']64)maB52Iay'x ϶  ;R\وp=E كI>Qqթ,:WLkw P@;5+?1T`vi XDrD!(HD 7KǾ_-{Vɢ崨՗w+#d89=Q K~^gɒO -ȷ Lm$2೟_|B|E)AR%\( PH 0kh•^QOK},uBC@@r|lի`qfճjhtˊ-◝MS  W"=,P{.FXaІ? c |7} A0@AHS0D.R9bO~Zh#x3!r OYmD Ͼ:K` tF0?ҋX1-%!v_?ѷGkGABP63GK#pB^<翼hn ܾ__+&Sn_ t,Mz6ZW+駅E}Wr5̵aA[a =# 1{}uGD4+!?BR,j:!ϫ̳]SV?t7'}~6CP l sS|~#u'::FuX˓ǧ8?en,U' qܞ7;ެ_a,Ȅ ׆%|(@??s뵍NN^Q;Fk#Iy "z 9V,u9f]v/_ye>[wSY[f^jl:O2$?SOlzj o A] ׬y_~d',O _=sglyV׻ muO"cUPHvaYI ULOpSs ȻƊ6T3FWV 5aUX] = .m싱NaFBԤ|3d55k6^ݓuu C_H c[&2upI]<ɥID&%f%buX_5}@mky~VtdĀ c]II9% 2֕'+4 ᘝx/CJ7‹y;h=8Pg3@ؼx~;PNZS.y:>YXS Ӄ >q ˀg Su ej":JL1n^sn9zGYIn^Y;4kfx~pDҍr?i]ڽ8KKr&ux~AtOa+:Po3 ؅<<ӌB t0ɽD"&"F|I7a&AAGdamȖ0%ot'so4@Er :~~S X*a%>BQ k{07?ė0n!5dwuaC t,G(Qҧ^ Ekegɹ/&IdZ \v/w6 t 'U^"~NT٪'uNɨ?˒ F_- An嚔U3&d@uuBA~.^NL#NZ`44;ilՇ;G80UQll%$#VI";PSO~@*Ⱦ*ٓȆ"ERmm^dAJ9L c3f>^ .˲?dIPEFW.9PѪ6~uMvLi@N1?<4h:5]V Ίn#|ߟ1jÇ۶Ou'-?dd2Z43a &F_vHѾi&~,%h|@XB1Z Cѻ%zW9Q;۳SѱG p@ŀv\47&zL˄Ⱁo|>z@om>Vf$a]8 G_OQ2j`0HD(Vor[dSJ' . @NgCͦ(Q= TT X}/5M@pLݭ)Ve!|ocWOW΁~qK6*:U0q~jpL.fx# 3j؋b{A8L>75oBj ^G4JH(VrqA dDs2;pSߪ ~DAX0 gco G\i:vm68Hfp$rE_B *%8 >40EnAcOm'@8DY @郣gnl)?mT B6u<-BGJ#EꠈBܺS]U=ݏq P8Vnr RZ7W42b^.ݼ؊| G"Q@s$rFG#03ՠU!&@a3LX(,/ O7kA"J/Drp? @O)&LgO r @%U ߱lBѪ vNbc,8t>r$Ȭ>̒(`q#_,8s[ZzJ I@]4'@n!Ae{_DA"ʶOQ"RD@{ HrP.qJk*pOb=!F7GTv7ߔka7hI͂l&:^ߛd Ï+ֿSpj}J?'rH;tPB 4rɓxI~րX"|P'P-d sȃp\g0eK@%7.?_gw8S/<+T(| P~Su׹3~:⦕B>\/u~ϬxIȺ2/A00}ױS T:!r/sG!;qmp{ `4$J0W(MwiM_ ܃>z X0=4[q>g{/ILW"W8G+3,Q 3؁`?=Ahc8}5T8#фgC<.8]׆O4DYjXNDcE3KƛSΩVB)µ4%gi4.cIk9$/R똫g"\3x~ՠTQe)@)# oo4hEugvW]8mZ t'OvMvOqn+5b6j|p`% XT<9U]=jR,8R CK%*H4^q~Ռ 슛]hI%9~9dwQW.hS) IDATPt˼]J| di'v"ȦY녤Ke@6Ug]̮D١z4xuީlrF~莄@a&2\v@PyH}= e)P$ƦMDk(iCWFlwݵi|^|88zb,r,~xmU&ZP '( Ov_}=9'ċ|0gj-@{rx;t 8i_ @>r[QqqٓSLD{ͳ͚/ۼU`D%O${% ]X.Gك*ؖE7{e7j +{TVWݏGd7|jϒف{\_ԗT} r$mbQs}û-}*y<؋x9`ܨ( 8+9 gbDEedO>r 8O#\OB~= +?ѣc;va=UJ0v $TuE4h~oӰ+=مв643!-\i:?`KB33]  ̪jHjS +ā1:J4!=h‡ʉ6b*mw:5{ ߍ<^WUWWwe$41q@ԊBhЈ޼Im؂ _  ΤUzuVE ZDBK39#4˒<Q*>bKҝ_LWu2a1a'@4mTv>x[K9Ba O 'viXPN,3¯ FeB,Xj -z&jD na *.1/t A0/iBkKa#)0nIm/tϞxJ5s4TxhV0MOÐv!(uZ ~ zg$Lfc{xzA݅ \ ڍ8~.Z;x 6,)ЭLƵ/:3AB0=0X3t A Y6h"ʂwmǏSҮN5-p4|?J2uĻ l-ʖ9xJpӅ*J8%c9nʼp3ֆ[?߿|?"h pC2;|&Q8+6?]Saia 2: }`+h/0`ÁN@~ {y@m?X](kw@)ܺb/bX@:VKV5~DځHn잂L\.=3PUs, 0CsBp`[ΥhaD^h * )}A]z&Cs*!Cs.t+^zI9UM㰒,EZs+,N+ZAP3x&4#KLpb;W!.f$ K}/@0e{v`!x : <"` G6Sw2v`G =GUtg|Nr 尼zP2ia G|5ߗ̲) SA0g} ԺT v`ilgL<ܻPCw3/PF,RL*^CN l~wUHԻ8?XԸq*E q[ c4|ڨFɁXVƸCXN36@ lai bvkuʞ:XHrz؁3KsɁ9D|#&0iX4>Z9@cx8o9ޝ#6b*nfOn&.cSAz?|.D(X()ܰfrt-rl@ (c:zC1NJq9g1>_( x'1:h[y;O7b͓Fv@3+LZȳXNā:6GWv.u.'~cExϠTхƁg!zj#답Yy!)"koo`m)q*t2Qi nX=cnFEt|xAz@:F4OCuQhGRh9v(wѫր@'>zxȣEpF9 .^|`RkeVQ$槷 h'ၔIxӈFNҢ v*jSqV~V,- yQ JI*@I0ͻV.Uڤ*EuC&hR]|e O!kE cIENDB`#Dd@r  c NA*Examples\TEXTCSG.JPGR"W8F1 j@="mF"W8F1 j@=JFIFC    $.' ",#(7),01444'9=82<.342C  2!!22222222222222222222222222222222222222222222222222@" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( )5,GRNj|?o?ޙG TVL) 5-yUJ?ݣ#@W'/ Uׁ7J(>OPz-U㧃8Qqn? +_1/- )dBqEPEyw^ JG6nVVMy||pİOe}2 +4Wr|[̻Ck-O Cb$;YWA\,}eE|2s`ro_wjMw!ך.>ŤwXԳUI8TondU-cԑ.>ГSǛ}le֩I˯h1־9%%8s)Qz ^?'.snчj|wxno+ a@9,Ѩcy>-6꓏ᶙUW}_0I&ᐭP’8$aU>p|!AǪۏ©I ~L@_>ipJX/"?ޥq>?i#V~ED)?h8/ 19F?^PpY IŞϽ>kbHZ.;93xmw@LT׎e#vݶOǦ?ҥʱ ŏEcbo^4UqH=`c?>h[ʎiw~"^<ҸXOR59K}׮sIu;]]Jæ$0"ЋDHI.A$YNNDT ϥjڀ]I2@՗fFQp[}1FMkg<Ue7 Im'{ .)uTI1 Ldx]P*sTQB70cڀ+$o!r0M?HJuWi.Ȇю1Oge"IPj, #*GB<b ҼAC#qݩjdn<yK)?ֵ+M> "bg4QEQ'z4-wҩ={78@B##lx鍇kMlYb%ZI,"=Ttԡ_GB) N@Ə ;h@Z2YI kEgcv2,\3LdC{B[ ^,L㷥^*.e *5z $)AzeY\܌Ց`PQ6,9iQ7ťLLmH9d?^씨|ROta.H-u 6hMN`Gj/Ng}MJxH\u8bz:yc ċ:۞Xxv8ᯤ2B߱U{ҙ?<(!=NqQjrRIx` q6(?7rk&Nϓvj{[yBO5{I5G-ʼnCb 3Мڧt+>kILd yܷ zcCsبR.##Ñ]Wf0ǜ;!?lJ?0|»߉ڽŇX"}MlrO%5KDmg»Gu;ޡӡhppjwG,""3Ƒ+o385\ه`aל$cV`tU^[ I kDiv}݅ܭ#`/aV4[i\]%2O/Xݪ9-KII.I#ZV~#[&éB\u*k?r[ҽ'~+, ͡iLq1t+ X¹\YI}?.N#GcOij$Eۓ\ @WOߕ9_0dm뷑-ſ5ż\gs1Ϯ>cRZZjL-K"+3YR^>ŌFV vD6:+v)9,rGz@p}5#nR]ow?q>&831U[Hn 1PE'gmZ-Nu[Bۆp B2rV^njQ\98ʨOKiW&Y 8vlƕ]軏xfdOHH[Dwc8ulv$6G4lC#G kzl&Sxۯ-LЏ^U7X?IUM-!(Ĺ'U{4v:!Qq{$yXj\$d  I^ReVMV ?d-q\AX8Q|ou8f%,.z[{QVfpb>>YDrįZXd9}?>q"A9ȭ+V#)dιNEl<} TMO֯lOR1Ҫ xcq.ܓ8Y9,͏ xYϺx^(xMg]\Gx$K@d[+>S Y2%gR݁\l6D -`G֦Ѷ\t5YT/0©rkAZFFZxI<}ѡtc9z1MM6\3e+h3M)I]obK~u= V#l}Fj&&FWӠ.'?.Oj+X ӂ\wrZGsN_qW4u\A⢻1d"^H4*3* 'XNƍ8LED9er95?#m{X`- $qחxal*L f|Aq0cOJkq=g*0koc) Ocd&ֱDg/m"uM|$\ZgPُZH|q}b{ Z!yܴ?1=3S.Zx &æ)h$8€95FH|n$n\7M΄Nޔe#Sp?P9IU; qU%Y]IjQy=Gz zmmR89iItҩuc!y ;#6R4Jڝ^P {ԋj$s#8!<1H6#ӠK!bp6=jco|>6OAuE EvwPn!efy]|#[1ii6 `߲I#|ӶqSDm^? {c %ߓWq 2";SWM2jVx$ljF?1q[ѡ_+ 4#K:a{J$ (sސmg?֢d1sI-=? atJ =qϵY9gl޴|HJM639n##5%V@eAjfH :{ *7`ԍx2ѓ9#&CPyڑnar89$Ȉ#䏔UvQܤdEF3,Sr)]U_)uȍCmk>\:t>٫Rå}M.%ׄA[zEQT@Ddo_"EAQ n}w_#O[-~H&8n$ 8LKOG$ ad0GBk>9f 3Ү Y7T ĊUOL cMbfe~s*hwBa<1&FT-т)][ErǒG&ya-qF09:@ED ;S?άx*Q1TGT,NdAL ##HCM&DBj #N}p+U2) p y*r_ uue8Wɨ$D ] tր(-B9<*][3#G?_J[Q~f=8In%2!I2HFmd$jS#h 8گ@g]mM9$00(e\UҪ$r11z_ xsVvah0} ֌? oxZKIk'6N!.:_+@Ӡ{"#0QU mbk'.}1b)n2~UTPTt` Z9Cc-RkvB0*͟¿JAÑ35m_OQN|>xvm@~jJ0ךb* asۮZ,vx|_u'kkvб ?!M'k"Vol]XQEwbŚg87rZF6<;i֍3!KN)5qc(#Y2ryU=6+"c}g08Ƞ*([$0 qk!{ Yp"S8lF$WSs7~4(iCM> ʴp?5uY %,w\̣3ѫ{q^EAsmȏ>vOSO [NBF2Zz( =̽>劻BEBA<[EAva FF=Cit|? )jF"*QuPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPDd@r  c NA*Examples\TORDEMO.JPGR1B|w:8q ;FB|w:8qJFIFC    $.' ",#(7),01444'9=82<.342C  2!!22222222222222222222222222222222222222222222222222@" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?( ( ( ( ( ( ( ( ( ( ( ( ( ( ( (n౶{ Oϵ V8!yepf=sxPO!S-קü/5M]1^+y2v2ày.nȖdU19qb՝{Y~JާhZk\)3;bkf%|DaSMGA5ZPLsEcSYH?j쬡,rǫܚXkS_+ŷYYCal@(9fcv=XՊ(VDQL((((((((((((((*+m-{8eK k4椡Wd")6kW ]NivKvӗ)At^sw˓V'A\jSw~~^-Ξ85m,{V&|;/mo6Iը9Tf,ǒ;µ_yF3u[P{)/,శ[{tڋOrOr}jU4~`'+(((((((((((((((dM,,q,p@ @ 1=kKwRTE2 Y轿3PM> ʰv(Ey?yߝtȖZI>\)3rǹXoMښWs~%nhGk$2yp˽݋g:b!9m-34*苞N{q[oAJ~PܭoJGA?l`V!Af9gcՉMBqSN~c}GZgn@#^'$VDQ@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@TW70Ks;5,{ KlF}y/uH"GNBܖF3H^kPA[E?޲vt :y) r~gs&)o_&կ.F rz#۶r+tּDOqhM}S1sj&/ VJHWS7UB(U(J*ߕ Eii E9$$'֦IYQE0 ( ( ( ( ( ( ( ( ( ( ( ( ( ( (nayp cz݀.nayp czוx7iak}>'C4 6qU}qusM{jB(c[`d#տ4{Ocva<6z?q*-Z!Og%д~[7U 2?\'+qV^Է6bZv2(r<3Xym[c1i<t`$k}MaBE)?q~??1Zen@#^ܞަ(((((((((((((((+gw Oچ-,,qVc\^}SEGȩm,̤u-g׎jksRWr=R;tQ-w)̖2;OV+ߐyyuTE/s[XhPd`7 d'&\@圀y=vŮJe ʹ:`Wii mEI=='d`w KHlmj/I==袻RIYQE0 ( ( ( ( ( ( ( ( ( ( ( ( ( ( (n౶{ Oچn."w J]XyW\-=~ ?^oZψo˥ .5n޽ U:7i+Z2(-t<+ίV^U'=Ghzo?ŝXι{uw <zz4u{R?7"8,r@z4ע>+d@R{zմooV" JF0IEHQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEEss 5Ă8ש?Pݵ`%6qp#AW,M5!Dr[2֧ۢuз 4[DT8bpl'9 skҬ$ 08tY"U5bDJsqVӵOy) ?Ϫ-lk{{M/4Mmޣෆ(aQ(B((((((((((((((()O+5.{2MGyy\>$w'ҹPoS??mT)E^(DJ*ryw8N{zM~??2{-OjE2-t@X:ghfc&^\ kz9]gX׮" j%2ܹxנ ׈u!peZp$2~~B'.p LO-8T*Pχ'v]~cnޤvۤF$U-WEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEqpc_ēܚM[,{Fg''>$y2;ڬ;!og# Fq V^SI"=G"zR?+VhnIkΪba.M!VF|EL) nYٺIϾjjY9b8$r-;H'o ]n|6G U-$h8SWu+i-maK{t >ަJ"B(((((((((((((((*lF47mXX{R(es\4N,eV QB;kKLH$e`Ӣ`AaS 6쑼&e>C^f"+{ZVg%<#Uygcz53,đȷ_Ys-5 5 ̭#O9??u%b8aTV2ĽUwoP-ă ؐ(((((((((((((((f$i+ssأ]kqxRd([~ Zľ$f_>HR)VO+a*/ 8U%W 72$cbקs˳HI9o v=~JV<' .V,n=*.]ɉc8$r}d=oWcii[$3}TJkoRj( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( (//mWaYyy\>'@}0Dv2|<{CQ ol͈c?}OO»כNv+tE^Kyp4ݠ[u+GO ct+P>O/؏V?9Ue4?H8tQG}P#`%ND!{~B;[XlG *#5շ-- K{hq G>ަJąQ@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Se!呂ƊYu4}ܾ'&X.g}$re["jy!65\TG+KiCCj"c\\X|״+oSi% re,VE`:ߌW]hW^3kI7pG O4C}=FW BG>5=ݸ BU0Xƴ7~N~~nv[q ªKEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQE}DyK _Ref411751086}DyK _Ref411683931}DyK _Ref411686157}DyK _Ref411753015}DyK _Ref414259498Dd@r  c NA*Examples\SKYSPH1.JPGR1F# NnoT9 FF# NnoT9JFIFC     C   @"3!1AQa"q#2BRCcr)!1Aa2Q" ?jq)qE#7ZJj5R3q%0E"IThfLAjD8VZ.$rJR&r̦US(Q(vLFРTUMX*U0%eUQ1D!ȥ6Cj&F(jTVfZ YJ&(jThJ̜Q(5fFGS4aA4S3q$ƬhLė$LE2IqLZ$F*S!ĀVPjdԐnFX* c`7,e¦rEaVFPƢIYIP!̥TMQ4%d9*&CJ$f LJ Y&nel(ԬDLqhS:Iq1() i0hC-Y%5F)(U)IYn)ZQjde S&̡ܚ Hw (.$FB(ܲʡ97&ՌCMɹD9HIejT Js-Dj)bVJnf%Ffh)1S:L1TX4S!Քf8C.&8eQ-Qp 2Z.ՊFer\ *Br2UQrhfFM6.'#%PPB&P0K 5+*Z9fڳrs)@ĨjIZ5f@@l̵ Q5$s-DM%3]YE♎%ƚ-LhU p$Ip%Ed̲p'#%P)LL,B.YB.rlNTɋKg=Lgܭz#/Vs8' ͤ6Lrcǖug?<{ih㊣Ӈ珪YvR3'ن3%(y;W/j|Eq~I:=v>KѿX<sϋ94wmU|mlC[wКe^B ɴnY/!J4ܛP$mQe(VjBs-@̄7,ܙU1TP8T*ˣ2S%FdK3,MK 0eBAP] I\8ٸYf}Y9K\gn<=綱_ǖvWWZ^~7;~P򌟨MyA(y@G?,ytvȗhCKPiR|]dWs~ؾ3:5vxr__ۭ\]|oD5+&eJFHPAБE ^BNY*!̥rnQY%̪T 6s)@is)@2p##,E)BiEAPY5*ʤ2*Fe2WA{PqMrޗk"8gnlF>wvR矧_i9rJsnSm~˟Z_u3JO;F۔IeeU ee'#%et 2B22^FEp9+#!t'(e\(h,;*@,¤\t p  (@,@ڼ_vԡ)}O#_?b4O:/<.o3QQ^(܊[¿_ l3?+7~Ov+}oȟ~gY9;gCLƽg\8x߾.?w|&mV߼}F XucL1I,~=@,@\(@,„  2LC2Qc,.22 Edd]Т2 TiC7(: e t  At$2PVPBAYC(: e * 3#0UPVFBBhQYAPVFGp9C(2⡙C(bBTen&2U e \(NFJr9+,d Y9+#":VMt 2tEd:/#!T##%dd: YAPyfP',e@w p;Bte!(VFJΪhʩirq 7 ܡ9BAT P$p5bM (AМP@9c,P&  Pʸ8 3#S dw&ФVYʸ 69(⡹6c,S*Y%̪ m u"e\ʡ9c%n:@:2K) 7,e㩔 \t0\(`7#!p229C(CS ɠeq8M WՙH2jH+##SI+,S*Dd@r  c NA*Examples\SKYSPH2.JPGR2ufUt7YFufUt7YJFIFC     C   @"A !1AQRa"BSq2Cb#Er3D6 !1ABCQa"2RSq#b ?W*c'çhD c\hLd邴 kd k 1c0h=$e;$s 5纎MWխ&Ƥ9S Yj ;Nж,p_8[Bn%`Nd'%`]dVN XY |V![ XY 12f11;Bh1`*ر;CE/xh#L+sk`s,=$h:vC0;F3K$"n-4鮔B7;́!4$FNX8;R/ xϓΗL澃Xvlm|['L&cLs:rŬqņ䭯>|ɖr9sNZM3< [X'3枣4|i͹7!:$ݳHL"l`lt,ء+ +tݱd0ntnZOx{ b-"l-AkT錝14]gPJtODN#@ʶ.;C'hg[&2vNjVlMfhƮOu$m.i4]4_Fګ9tkIó1>V|R]cQ{жY>oUsEr7B`ʃg-خT+T{ ݁6eodlV)T[enn݈݅ l#bA,#b7DnnEX*tN: tWabc'c): ::*RӠVAv&2vVV2LJNY)ibv2RɃ2eINj%[n352M䕳ͳ!}yBm:hy|UZD!ABBB8Go`S=Ly߱?ўuYŵ[/gŴ:O͹PV}V T{Hح T{B [ TYi\خAj,#  T`[7b-S*R: dWijc&Tɂ k::*R:dijc'eJV22 kHe**Rd%S!ԁ\X2¤f`]XVRCwB+t7dSjY5hiDXb͛MU=-?ɋfj5Х-?d9 ,`ۋG{?c>{~qJӓO~佧/x"s=$-$2y?M|ejrA6!zA'_^cwzۚ<_U2zmlg4s{S[e۞R+ށ\zGK]F.7ʉOP?tOnhn3DgxE.)rj3HI-`ŐtYE),N̦ & :3(R)0R`)+șx)NR̹.,<'5RwA˒kpùm*4{"mV\}SG8r@r=Z~kn+FX3b .B@r V/Pʅr Th\W 7b Zb&5aJc)Q_0TY!e f@He" ՇũT2aybc))JڰԼHe" QWIl]ly65&.g[dgl3xAe[h U+ݴw4w~So_a[_ j}Na $I}f=cYXu+w!5s,mhlh=|t:+NN-R eIT mʑ[ q)cRZk^nu#Z{#2_(ӬO?}F a6{Piër>1,S'm]k2juYLKu#{4>'^٫t͍G?B `rgkrbXFX#3r!k{lW 6+B9 +a*pBB%P `"Th Cr[vB4{(Mq>O_-|H*б=koˎz1GS#2,{(+bKOÎ㊙}e,$|PQj- ؑ~u5/e#$|PQG~eq9Yr:G<|8&j_̇Ԃ8$~h=I<8Y3d>a#El(P}%'H#GY3l>a#Al% +)^?{%:Z&|hsj}3?,dz_R#{$v=Q<(&;SCF׫Kc܎sM?:Ɉ$|Pď6]]HG܎S?:Ʉq#WcDv=iSr:Lx?~>"ot/8%㩔o7Nۏyhvo |][g㩟1>u0yhvNZ"z+[g޴BJ]ƿ?qO΢L *5߸+OD%{y2V]ƺio&J'K˛OLnikl:E<_0>%$-pV>vZevSܞk>RO5zIBЧO1=hr:O'Բ8dW.3|L_)hWPV5k8VudyAZk8OVn@ Z{ ADB Z~?ȎH2.y6HJD@lX"n'Q&:>`.߸m%}"LUP}~wo$zDg.G.k艾H1}m#=&L5'WWtEy2a5u"z5u#wͻGo$zLF.OEɿn"NOd<۸>m܎;Ҥ+XȱO9X pW2Q#)>elQNfzLmN5ER./]gz>IxukH1wUavXf#%ZRnxαf|Yc[):f~k4qдv^#Bq 8MQqdzZuڜItC,=/ޖ"]a_՘1jj>@罹Ͼ>Pw:/*m-Ve׍?6gj9E7oGȈf٦1 ./,'M r إDsP(Cb+V2H#bE$P#1W&ArT SɑcG1 c/Qb pV2DO$E@*sQb$G1T;T{ØA,⇊#A@G$dc3W͙m6~,AH)w=R?jO78Zck*Ƕx>xގm=בݦn߱~?#z+qPD;|:Am?1嶦Lc£k輔=+O$3͖hl* ϸ,ݵ}g˻l&i4₍OAH_--9S<2"pTGI(L Q#$dE@*42Di!UT2TH :TR#%r"T%Y; Q RH(B2F@*#$dBǪ XvF9@*4?FHȴR!#"(2*%P!;$dZl*! M2*A THaQD)$FHȊ#((*D2(TlddD5D dJ•+ @dd( + y# Q TBB%c%EHl)PBGl)Qq"ODd@r  c NA*Examples\SKYSPH3.JPGR\NIj~1I 8NF0NIj~1I JFIFC     C   @" E!1AQa"Rq2#BSbr3$ECD8 !1AQa"2BqCRb# ?/^YϻSy 4yH {5eMAuKIi9deHR3&+f!iŒ]Dvc=ү] oi O_+$ű>m(I‰$]]hmƦ..H!( O4ؕ$nf3i+Ưx!Du]"mgb4ϤkĦXe#P O]VL+c. vêQD닃_b6QM{#),Crc̲4V GM|Ƹ4 yFu.() ǥ}rJqiN{Է Q㨤2T6CѺf #1QLj`XrIR̐CR;NzP;|ufe k^|B=Դ:Zdfj0Y[4m#?Ki&WT5ٮMW3 +-od◾]S!-@z(u:ȫDHs/')RH8U FxH}b>jyDif55seJg?G0œ( W7>JS*T=ÙpV:P# $iN߰1-/ggatߡ- ,Pr칗VOJ'Kk.`Cm}+jhC\A)E#|/Zߗ9v x_: "'ɒ_ GaD J_N@T9^_`VyU=tx/L\bl`<ǚmEhBBSsDdʩ:).}d$"18G1J2D'U^ܠ=M!: +ZR2MJhP$r26iai9 @Jjbz# T;:55އl\cIַWW*J@PN`ާt+3F$٧FcJ.~+X8J9IꫂRSj?cM9( rzUnZHRtQ&DRS(Y=jٙWdqAVҢVU69\ܵFY۳HbYq(O7uI'ΛkNk=;$gfw֥ ApB:jzdH M8ZQp3֫7;7Ou,;2r:tkU["÷G!rqj lS=/f{W?7,Ez"X d<)WLܫq6=#yխz}G_H a|c_Sp!Mb s֬VJdFoaXwB󰐯=sϭ0 mE**AW'4'dEca{ųz>cS8U!k_A,d{$%`;m`sVqɄ/em Wl2ChZzԟM]դ[$%@)) ThW ԰ 8,o*?Z+o3]['lI?sH-JQm^ǔ*w4Sҵͺ Il8eg9|+5rrt@YV]*3N}벴.*fK5:mΖ'7Y:hxx 3% Cʐ]mlx'$ 2{ wL#N>p#FzU]Ǜd{HfTR GOe,]7d|r1JKI-px樭ae3>;!mao999޻8[WŒ%G*L|Q덺 _'I[ 0[Hg! ZEXuA(IMA٥Ξk>kuVԖ҅/4KdOڅ<%-(N u#PmO˔R?WmloOzP_?ŽiK*uѥH$JF.<)I6S!ĆԸ6{{VQ7UƸEed|9\,Ҧ߃"<F9F7qN8"h;[agјP4!K”S#Wrowvårl(#=)M9hs$c=Sm;{,&;K #uδpEn_5Ln&?ܸ%aLni9=@F1R)g[SxaYVV0ӧ~qi^yH888#54ӳ*QNmrkqT(`ҳ'GSx԰ @V s.eW鷑ްw4u6BmDRY.W5uVE%A|n*i<衿3Μğ:06Aՠ4LmT9e)U!mͤtTDfk٣7+'"= c-IH[,j%n/2Gʵ.?4ձ6$|ӿ8Sz~oU2(Sƙj'.i~F)J$+ZW6ݠ4m6 ZN:+.vUOxRW%ڙKm((4XjSMj=vz\뎭KX2p܊' ;Ώ3K Y8RI9VPp$-J^DECpVq'ma >GAWAଣrtޫي덡N^H oHb)?4a`l=㑱VK3i=%.=d8q#AZRJ+*aEOEG33Ù7im `渾/&F+%)ih]1Oxyi)mZ )nS)*lV<[b-Tq+煶Z$3GB+TpB'\&6̴J۔nyWJeKvI,>z۸tZr{)J1B(]nfR!AG8֠Jt%٥R(+AA ?!--(\IJqk_%S 6\j d{v#mn)4_qN߮{S\jp[}e6d/s޲ˌ 1$I4CsvaHRQOzƿ{ 1~}Wk!m@ s]:m|[ލ2~KÝN wΨw[- %+ has*ڂ Q*\q2T8"+gponzK.8TI$y?{^ҼpsIE*д +:T̀C\3UÞ*+T@aI l+OhԷ [_aF ڎz:ĥ%`.#^o[#/0Csr9ڝZZaJPYuyUهY:1^})9KRН[wurl=VMf{ġSsbd6qMSKO%v`*iMU4xaKWM-+PIÙ}Nz4D![ԟ:xň>4wOJ2v`mQ<ǽ[oNf} vj.k&54w-+ڜmBZԮd%Cl_*0FV\R]Oj2۳-nJFU*I4O0Ҳ{Q;eV\ɏ8B 790|5qNKEJtl‡'GR0rM;@whp$wgAp|Xh6g$:>g$W^֟5+/K䀼vÝD(&9m!N8؊fX}{d&?pB( J˜b( Sgx NmӻR:{IJ@z ﺈXj'3R1J;}2$T$[fVKd3Tt^m%Sr^K!A QW(+4۩:% =vTyKNB3͏ʸqGNs*uBuoyII%#8;R K}).$>VQ/enp?MB[sZR) HÛYM ,aPj]ss!⠖0Rӽ=j(EM:{%W}+`rϝ;vꪋ'uoilطM믒xLkR2t>]Qip65I[+?nThxUrjtώ`1 aWEZqZ\A!<6 W3&29rUt•l<, (aXyu.q,JRBp$gj(^h˃nv]D!շ1Y065pTebK-9qՕ[<]]s$騲`oruJPV0 cnsR+K*l~"V@jekk5@h. DrX~:D˼ŠUˌ*Up-9m^ `2=EDz))qqbQl\ Gi u@=Zu~vؘ2يF+HXF']YJVgBUc֜FKIK)K̥Gld]jN,1̨Xf終x֮$ ;]8'ȑ֒oU%Zt4IUWLwZ[ l!x[eG\rrPo]r/Cm !}+A Ihr {955JWQ(I=ƶ釼 ǣ%zJ$mq J&&XL1&Z&Q7 gt+O$3aT܍~ovr*_ 4"[-+m%J  Vm">/8II>wW_wf s(TIceiIU$o$ JZKHQ*>Yx!. YCcSNzO 4SPIBG^ `^UCN'q'uusyM^/ҷs-Ŷ6ֶyw g&Al|Z<spmGkXyZ"qEjkZkҬAwea{(t:0|MMAqa)HmeP6Y~c: )yΈv:3M$JhR-ѐo6o{_879p~21cr! n3#䲲=$Z6M<ːcOiM$/P6(RRp3V3 B}͏+֤)-Y{)O¥hyﶻJq<)V6Ȣ%%C&9t]?q;}yFTWaZ}6 }~UU%;6pZlF 戕gYfE셄urlݺ 'jtnK a׎h5SYty+ȷN)aai$i׺:=ܦ1( x-;Z,$5snqTkZ DGid!1R yv$ q.ouD~??ʫEvg^[R]2p>YdYmP.M\•yֵUvL.ˏaFquunSܽY$eД'mVoZ 6*Z{kpfig-d4ڒTf.-] }[e|>ꪮfT%('rIõo\d$s6ʴe\-8mQ_0PsְW֣o#Q 9܍ȩ8ҋ|AKZ+ǐSKXs}MZGlږkR`Kإ#K |ZG>}+!i ^ՍvJ#ui8B]{*2`rueA!gR[U56W*"\sul`YUdu R9Y ooDzI1ش7j8NM4v̮iX3xWȵ#=yI)  )!`li5yMeGKE5)L<*P*mE$-сNj\qn+Q8i2V'!I8"*#ڬ[|3rj oImכz`nn;"JZ!  ĝ?O9q%-Դ>s|mR wWyAy]qO#ms61":QR K8JJ) WoU>zdmA($e!ddd,Vp问R9a2Vvzeȩe}/ 45-heSͷsC^gy2>ěܮ<6ʁ#9Ҧ:ӄ]UqLۼu)Pe2HjlR[1ZrA8$tPmxTƸܖׂI펇PzqT[eӄ(Fs:/8QݷFv?ڃP HVZTʛ1M%)f3ͥ|NHGEzvT K͝/w@qئk6{ ~K`:$wQ=[%V#$UjGi\%Qѱm=N(k1|eU1;}Nw_C rwK~H;S6+Mbnͨ{Z y|HgQ =}xhi<6I)H2ڛnjyYX0Q=6ek oΊ?OauLe8V)Gg+qWxPqتcSifSIZ*$5 y"'p~f'5r_tf˰&h d0PPo|؂QTWKtED)H-ae IG}[BW_@1X5>߿\Up!&ec)%.l:ߕS.) JT:pE3 ۺ] uv+o$7sJKM0#^ )qCx4HַqZeaLdft9Qa N*6NRpu*S/L׭q@M!sC4n2Xy%JH_)B)h5 ]=/Q\/ #m )Rp~u&cW!8Hm!=sm HRlՍc[uT'&ZԐU֥qqg2po\[: -v-{ˎC.BTNҙ NuuҔS*(p䩿:# ֪JN09*JJO6f4t,@A;TG1YG"mWkrhLGPRir1{jq~-Qc! :\c;|매!8m+tmSzOԓC-N@Sԟ4p !$쬮j)PRHaeHm]|ЙO3hi:zcSH&2fןuYV㴴k5*ޞ`S8IЊN1*T1kX8lW7*Gڤ5JةG.ug=&=O:v"sޣ噒}@8Idʫf{j(i#Շ}Ӆ6%OΒUjN¹R{u@`Te l`䨫9X( $6`{8oQ9R^sbGҬ4W)Xiԉ^ ˔ЧpHq𧖵dOR֬-5RݽB%jwLmkk u\K1VV++<ۅKdFE3I;{ǹ>B,ףL}FۑQK5DH,2RR1^ /&I]jh dPQʚeCz0jmA*:n>\G->VA TjUXᖮIB`RVC籧\n,dw/MH2皁?2>*IReJqNosRu i=`:SpW pISd"U6/’TG"AOeyu=k]W~qٚD֠ Vp~u8ihY\ʢ0Vi#-im(-=RAjM;wmZY ͹^"*zE^} Ui8RsGqZARRS2){umNg%- '$'ax| ~ah-r#HmO4RkN*KXT$M8R]$BQ@ɥEGPLj3Oʺbm7c\!>U1UL+OP"Bs+LpReTHVP?9rW P+A% '9MaUO gEDGRA8>D[zp >Cj^HٴP;+̊kf5,0d RVlpqF (ʕ $ +JQ )9"FV1ʺg<)\'E*P g<ΒBFaIT0O<3cU+V(W1X2T9U*:5`ɓk8BBq;w=c{t8O2:ZZON٬9rR[\^PRBױI'?JVT`\S<@a57wi5ڏ½*kxG.) {Qݲ8^@%;7ydR<5hi踷ʷ%[sOMiV)ͽ,Xix%O\yScmxy1 ~TbUn撵n/q8[yCehq!]%%xG~A]ht]Dw픏5ճ8x+.WiRʖ(G3y@|X.nGݭ0( 1|Es)Edy?nrҊ' KĠ#3.q8ü*!m-9%}9Hޤ-75.H[$Fj?J K8\BBb 9imXZ,RB RKqxé*J={Y4]'ƛ<6^9(;m_crLƒa>'*1p;go%eRlqk!(KND#)끰MpMɴ0OaԺgr ;wSW/ڧH!!/GpĂ U6꾑`mC}sgs读W ,C0dy rԥ@ԟjw6nhj+}'<w H(3nhJ%KsmSFnLo-*ύ[89͍enVzJz7,cUeh6Q יmI+҂!G oz#6y/rRBR rf<H%vgìFqg;11t%uqKҖBN.qWnici<7㾸+9'kC8@zDqem\TK ʥ:bN?:JV}ml` 7U\ -*:&a6-iKA#WΡ4nUs*Zyc p6#թ/6rTG@ޫ[$ĒĬrhsΞ Pc.v'IzGo8[)}=F69 YTm&R:}|V&;KڝByHR0IϥOoRd0Bmca/aXb~zlϪ X. \8hIZU4&VMξ2VI!=S`&yk*HQ <ֈ"<ReD-R&9yG;dv x x 9: GkT+ +p8bڀ;%n-*y-7SvaL n˃8R{_f= TI,[()~ҦZ8vLD!F8PH<9%OٺZJ Оes c ]sL-mAP˾T m_Dl<\? F ^Rϡ8k[i=?HeIAiBO'[ kt_:Dd$HO1y|YxЗm[t miowa`[ZCo}C2zDw-+ n0.J$'T/_üۯj)")!Œ╍6Q]GهDa7i֦- 㰴b3(wIv]ے״BNZқ8VE{]dsJONۜM_\ܕ!e3$T;p\#qo/0O;' ?y-]S)q%J;{{cy[|19Gkk 0E$KrnJ I" (i%QҺ@+`i$Fu`(y#*FTe&BmL.N0[o>U,R\NRqP kwe(>y|Ð?eUz}͂ºʷ<˱[je\SoIm-0u}I)"cnB2I>x1է54+rDzܔ~ A)8##=:cY}Q$8$jQ2:^ypr6yhZT();3*[L)2sq`mQOPoT$˜V2JQVO(HZZӨZ0Ysr+.n͵Ȃ$HRҤD:.Mս,n -g*)#lYW>ģ;iܮޏȴ8x0Ӕr$$7֨i5Yu  =kDKv\-myUlmJ\S:PNys?8E^S͞ڶ\K` `(84D.cK u 3˂9O|Tzvts`=r &I7\),Rr t?8ڐtOx%I>ѩTgCl8{ٞT3IRw)v ۲#''*h EX}HyOk;DVYq$ iK%Ͷ9&_'0ȥ%:&T䥤%U)vgy:ŮA`$냼J!LoVݢ2Ȗ)R)|.=T v㌬% $w8q蓲tΟ-z1yE,G$! />wOURh$dXljXjLԆs%e!8؁6էL%)KJ?sӏtJyfm>I1؍!ƛ)*'|vZ8}c$F[v"<(Ϲ]A)Got@?ZGʙs 1Bb\;,61o?ZID$9() [ jù-]_:G9s6tdz^p܏3eSg,ek//$ӿ>%]jdCnA$~doR3 ۭ DE)K*RAcjc qbm >BFz )ΩBrLZk3Sh.Hqm@O ͧimj@W'[#(Fw s#ʮq^.# +#~9e+ϏX8m9Ÿ(0HP>jbS_!}ayR?jJ)TΡ$IQAy`Ս)3 sb*.`ӧO)MC#m:&")0qF5NB̐ !T$Y+@UI:\C)"i)==U)ء| `Si(ANCwkmR(nGaTԵJ9$4"12.:!+$^ir^;W=ʨTp= 3T!.ª#.UJF-uJBOzYG4JS/)/qJ$ vz͍Cp['iM j:q!}*?ׯ}jͲ|r2wk)4,ҳˉ6JC8MM$j~f\.9H Ia?:Bq z$2ThDt@g~}2h[MjjDJrLF;JI 3yVYQx"?qhm!Im51F3*oBR2 O>Y-:)\ɑiBהh$lYit[eɳ-8̞Qf˶c;zT|OsZ%h9*P*8% !œ q @?Δk&dת؞suxW2S H_ii}H$ݙx1-J۪ZZz|W\+bӺQ뭣 %axWqf '[k澝iN9p$Okm/JZ `;mϹ4jG>"v1Zi@%ɗxD?W_QʟPBCA}`w6i *RS{:k~3ioz7ev=ٖT d:r"ʓ"#,7<TG'ƽpnIQV>d6 3)wEk5M3ց:z`*O+p'_2Ag0yqkhG<emnvJT9̫f@cδֹK<'9ڔAY2Ҳ*?^?T x-EU,/cKoq+mai97Duiq^'eɡU^4O?i  E iwu>8272v ]\YRJNJI/55s3 ,q\cΖN5-טPj0O55'N?CC̦)xP-h wO^OJDghyd?*Cx/@q-pR5::8M;\c+Si3>S!Ǹ'򩶞ּ<{QG[QGsa+}E:<{q?~0k5\:f8>[hW>%sõqiNz=|O+߳E'!5澇M㞑rRqI8>TZ\=tcϛst~ҀĹv`^Yv8nn"֠jknGWWm1uŲqw%GQ?:p|Hwf14?UVO8oq[/hm`J皨eߞ&ZK@: GJoǚAC(D/JwqB#W-f ҄BNB#P3ܦ;"=ؤ4@@N>5HlA®|ֈ{ $va҄A./6CGхZ9Q/>E ڽ>ډ\8L>Aԟ]MPR據ltnAT"#;"8v6j h(DN=GOnS8{PC)&qyP҄GPS@j*x  ICxx0jb)[Ǖ*x ڍؤAL<~BDJgܡ3 p?w*zJrp}<1҇nPŸGO+6{Ws{Jcy ݣSzPC(zI~BXi٫^G`|5 oJfH+ޔS?tJds` p_nmKu*XI JJ=HFGsQG UyqqUNyq OMk4]&BB]&'4|^t.B0NhBh] PFfn(4!4.@ &B &"^h]zqCBB.tfFP@CPЁB鏖#4|bV7D ׹h] (B]$0кA+&]  t.1BBB"8MPD ר!uW3B^Є+.] fMЁ0Phqz ^Bh@zB/Wf)(]Nh@ N+7^ W}DyK _Ref411773210Dd@l  c HA$Examples\FOG1.JPGR RoW[^x)0kVus$[N< ZH˥[t[d-m4&U*o(,ʑmt(Rsm0O(mi9=u8[/O; MUWmF&)Ӛ(.'kޑ]]|5.~X9YrmYFf. K7:^K?^P.ZFYǹvO>4a?Su_kWM>VIy&bOW*Ϸڛf̍cծifX3SB.X1֥EJ5IIgsu8FآWæW,娗egڗ vKܛmgEuӄoGaiss3x7ؼ8o՞IǿV,V2yb7uw" < H HF 0R R"O'@Xu Μ< :[X,aEK*X>a^듵 sG] 3r8RZVqTi=++y`Y rJJx!<t19 Pဋəir%Ǒ4e&]:i=u^8I(;6-:=3dQcRݼ{_ڗו68W?3ZT`KSt^{ 77?W~$At͠JDͥZNq2T0׿.ڽBY n{r+>ujJyy4tQ6j#lO,*#aϐ| B"OR[ oVI!ȠC ))0qBE<-=l.\Zjb4*c$%L4BVt+[5$U:r79>U83Qs),|/6wI|&W"ɕF\$D"C`'G /Q !r$&<Lj<@Lh-ʣ̲Ȳ&|QsΛnؑG}ʄ_,)(軉$aL37[/,bI9656yl?T:yc'! .m0t.2X&|uػx7S0?S+@owMcOK/[)g}$ioQVsRJW=RN|פ&Tx.%E3X7Nk y,1dEmaYBk(QȒcZ0(JwX(Y dd,K# K, Hb"K,Ɗ[W]@73mV×烷kcҳw85rkK>?q9$ه>JV=DR*8Dai.RiNֿxtg.SkmNΊMb+;͙GeԮRqÚJ3\HpQ䊤2NLO+À\% n?Qq,SBm%owQÛO 4j^>9Ӥߵ8ÉiԄˬ/u.r%7%V)&wJj.fT-W9ҸУR^fM -A=QqJ t8EnٳVUWJx7|YҏRe G%w6SE[ӧ4ajmbwB좾o.]E/Ԓna$fmZQOVBGST/٣]([Glŵ_D[~zlbsNi:ԢRQKٵ{R)makK=fbzYNIWʩJ3sM8$0xM]<7kW3>{+zCmOi4\IԊ{ЗUC>%}w5fX˥J83gkVP_(ٴE `%i XCe`;BwY `*$ 9"TIK ` dx"lF9,B1i;VZY(œ[dI["ٙzmiZRRy\{p{晦[ҴBT`;^6/ŮQJT^1$t+g5% Dbg8:F+{ЪIeUO!V/ɱ#hqrR*cn)pɍv% kxS*.=yTJkqӧI54pZrrdnEKiXɯթŴM5M[ZJįJb2qyJ)Ji?]5ӛSM{2*-ڜ{=+Zu~}$gX\rM[IAxkeyyҌ U_,0yg7hwOhԇRWgH*r2#ZRIw)9}g2ET]˵22WVTڼ1xq.i.$ڊ(q)u}eSQ[$M;[%5g7qo:fona'ƹKb.9(83o.+dҝ1c䆰](VNKHqMcnbb %DV"*#( bhZƿQUj)TW{orm-ٍaa_RmmFu{&{FQZ4+OU}iWf~l6Щ Bk.^Wb{{1իI2qij/ ߿q2.V -B1KM0aӸ4ө4h="[Zo/1qKG㼚lm.Zs6Lv͚eN_˟czu? ckjѼ_9m y6+k]ի:2q0*w?Rs,*Jy'<$&jHut~Fڞlm?֕|F)џVhni_yg^9O䌫{ QeNxs~('HyrKE_w =3r\_r!NEΡe.d9Qse.0Et5)9>.Tx,-Ap%̃vu=Ḁ̇24]E9PQlڜZROWy/43Y*m,ZFY^/dNX+p6jk ewN2|;ҧǫ[\ [It~r%ɦFc8{q'e;]Jp ](cR_W$\"Vb Nm$o ZlWӖ{fR +]rʗBfKGNj;8.MI(-rkyXf-G,s9u35ocv?ieE\7Y9ǿ:a[Ej^Y=L Dў P/ܵ< 3 skkU,J=}Si{JJjKvpJy.gUT-~O&ٞ|JǓ~Hjn%u`| iH0Y1;Lp<B˨N^k|ʋ辒v"d%G}^>|zW.*3z"cITQYxF=[7IqT[RR]$>hrm{/x^^( }˽|uՔ9w:gܿ#e;[=M$J#[2[WyN9Ӭ_[B9jմd@CTu ]lzHM?6e⥃qƎ(e~,XsܝGJx)y}wGx*DxeYŦяZ$ZWt?cdTeva"o;?ƽbiTM<4kWLuM%u)cUӭlSŕl>4Y$3+Wtxp?/o Ǽ8}R/eL Jڕ;jޫQ.︢ޅ[УF՛݌"=Oe6JZJREE+GU4-}r}Ь#Уn*~Ӛ)vt6(g /fEݧ*s35CNw0N&P[_syQ?{ĉWT# c|]~$Oh? btZ*E?)H>SGaSR֊_D?ĉMCJI!7$\eM34ZssjMv;2M:}HmޭgR|-~ƮMr}O*ytَDd@l  c HA$Examples\FOG2.JPGRsTju ݼ?FsTju ݼJFIFC     C   @" A!1AQa"RqS#2BC3Tb$Dr2!1Qaq"A2BRS ?␄/(| BMqmmx!V4;6'a[ǚ!`^s]42Ƙ!LB!B!B!B! `QU'migS˨-)7` LݎȮ}MB16ۡX&#-3 cTU2_,lq96q+Q>/3AL.+tLjtbL4M=K&-,ȖA=D.I); C]Tu=9^u$s\r^*Tz|zx _d F u r ,k;UObTBT4VpֻMśySq ƽD {=$S3Zk9\WO@jf˖y=ObW{dqHMʒGMu%6JM$)7Aք % 3(S1@r((d(`n`*&1kX3J@u6YZCb>$ e o_0Ncp]^㏥8*sG|ּ"8bdxgB͍tUiZQ'n?3wE%-vzhI&Hǀo:kU!!@!@!@s5fu13_\.yOLz =6Mۣg_OouʥXRr{+RlrH ܩqPRr0. )!Art2HrR t Ct%2@pKMX e%Ic 3]&]8]x譢,q:5 KZeDn:=WBS9}3mt+t괈DOf2#z4ӷ466q!|\iob]#H?ߪа}"r9BEtRotwe Du Zn(JQB!@!@ߥ9:8e 6'Rk+';eϿ'䔻/ 'SyU;b=HILv$qԤI !qJ Hܠ @!B07JlP *lPE !D84N݈"a~Rt%kZk& -e +' S:7}%eK:ILi1`%.>kF#;\6 xU\RlG} 9 "hT!:—  @B $B!B@ 6! @A! KSbVNnkmح`QdT-iC\fj0msG\L3I94>bI%H6O `llLtf0v( aoSvT &#}w\f9Iežj̻[o!o9fǔAbTfM~^#uk$]r?_%O*5irre]ǒl):(ˑcPC :6ClvZY(vVLg5doc:JH92_S6Pl u-X:&(pu/U3p eE 9Wq~<lxnw Mq }Y;Z;6Cmis-w$w ɂ̂FsUx**nͤrC'V>݌%iݤ7"Jt.xYH4Z>y6-jU9tLrIhd&܀h5% ݿa$blZָh"|Mms T i9sBGL4r*#3eN:&b,bM?˔J!JQ>ݔ_%'ܵ=JtH>olp;CMtZMLv&[w}8@:}W}PAi?I0T9#Aq֝$3[^c{.snsl_K+b>+ͺNբ,cdSLY)jAjc'!)jB*,e9J) R"n!@ )ۤknkPfa|dT:ipk#`%A-7MT\ƍw{SIN45w3ǚ FpI@t2ֿtjB4~?FCQ>XuyN#SȔbS&cCOuH{Kn KVnsn),8ϓOؐST`AXB. t v@@ǧE~\Rhǖ2krbѴbx#q*kifTF|QC :k>W1Kz95ӛSMydJ!')⥎_cO ,z dL+Oߗ};[-ǣ͓J2^OxH4쿊VF^y/^۔&јjfN֍)4lTd6g;p8pTE2)Qw.KGx-J꣭Btĸ7!oJoII&U5DG]RxS ^,B賞SSjYg}m KbݗCsUnm}Uݬj+ZS)+F9mesVNuʌ6R&;)FTE RR.50jv+rLl, ġ%:Gs$BRPNR{"-1('Ī!.\WѓtV'U[?rA Sǚs/śX>򙙻B*Ylq 1@_ftr.>Y2Ǜ~(߷GbpNqqg-5%]]A -4'f)ܲdyvE|;Q,ʧ/s{ (F @=಼%ciq>h*~|~  gW˔\\dP^/P^"] FEUhnCU% ٮwe4]EK?((=8xͯJt$X*ZFY^/kaU-xknEiShǫ[ĥ18n*ilHK1^YFNI Wd3C+ݱs(dw巊D\P숼$ a~MYFE9.R̗C8P6Ȉ,&br:ʮg.3Q)Kv=CؓM%KPv<{y .=CI[67K`^c_aȜz3=:J%-A9N8 Ƥ!Cwi+bIÆr+Z9D;+Y3iM=4'z~9H7Z/sa@H0Y1;Lt%C,*z;[5U=5= ~!tG>yƟu>Z!J]ArPZ  hX AI&IQljhUiTP\#n(3U\gܻ;Aw5}uNdM$JH+OQЗ0QÑv\}ƥ̌ȶ4).HRgWQrs#xx|\y{sduPٮXJ|:}53wM#cH ^1CH~5F?X!s:qƎ(ҾG,9ru?ؤ`CH7R 'ݗ{q#`?1H迗bR '݇i1F`#a I;ml9 ,^M+1q8Q ؃a0Xq G8rtPcqGا*n|i \Ijg/Zs-;#zK/U0`x*dMTIO''c/7'&dj24arjA%:(.Uy@rj3ǚwe4rDŽ6iVgrvmoe3QqEQWw3zfdfUfB3!FVa#8Av3%7ڣ_5yh|̓_4kP.x (|+"lJ:hY TS-T̆,9ZƋW覉;$NudаQBW5fi\Dl*4pCNlEkE+ۈ6Vv7\0~Ҷ8-dmX.KK; ||ѻT>g OxwEU }=0V{8!ʟY}jx"`t_SWIl&99-gjx&BoHʚg'`aĽNJf]ᨅ$ds 5Ř|>S~OฟX.zw٥Dd@l  c HA$Examples\FOG3.JPGR] Dv DZb]F] Dv DZbJFIFC     C   @"=!1QAa"2BqR#3Crb$Sc&!1AQa"2Bq ?>^xk>俸Y*.dj%.޻.~-Z2pׁF\eÚ1ݘܓh;Gm3qqW zXre7QFXFjҴ4:uOWu[YrJmk||#ZIz&aTծڨ0qB+fQKl)4qVm;W[wqLJ}&2h`0-I7]ku."5&+cSu:fLr}':Fh^B5_EL*3Ruk]F4kKO43O&7;YqS 'xL|HJ k)ɀitj/ a Uq\)xZ2]|£2έYƝ8,sxIuf5:֥EJ5II\vѲ(y332b,{[ReiJThWO?ukJܥ')IRȎX;GqB9`W,f2\m Q43n28& BR50IOQ+merYg;ᙖ;Zclޕie6hj4wY.O'⼙ZG,tkWQzѮkJJ B5F)rO'\rOO;?ڄԠٯΏMԨ궪J/d\F\>>W(wW4W8ӣN.S$%P탾kSm(~k_'[Q7[QljƞiX?rBR+G(-F* JB9x2$\@7[$.D6D7I2 6Pd\*Ei іV*Y amr%t=eќ}Yivq0d!=;JixV`i.U#ўmvT'kh;eNm<+]Rl,/jV,~~) e_piU^~>_#O++~(הk͏05I:Ri/ͣ*MM~,{-eGKC=Ȕɓu#dĆO{, V I%̚&w2T IT*@O'2`&<''`ݺr\NӳJ>絛;NK ˍIl*K' ax}՝ZU4ke6*~IZNF|uYi<^Wza՞-pUhօU%*sd418k?}mQw4\3YC~yo&/8:Kx_64dH͂$yU6<<ң,Xe"dœ$ Y("\@%$dJxb'1V:c'$XxdiTqe1xc'E͕\M/;Xo''Fis5 {ƭVӖjOg{u:~5Ooغ Okzj㺤N=dpۑꡳ+|hl>/-?o_ƱM5nhl3?3ק^;3]bVP{D4PBkug*N.R=Sww:%?WɳW&9)hT5*s$bouWo8 ^#-Ȅnj8dM4Ok͝}R:z/S2s,Tttв$!$X(+\d,@)"8 W!QcG<LjGd 2s*ʙ4Ѵyҭ_GRDі4_Fc[S9K &ʀ׳^e%G&X +<"4N/XgT!/z-lݏi*Maw^R{J$tto[$U%#, .C#X(eX`\ %bP%YK FKQ$ [4LV1yx=o1{;5 d9(ߐfoRKHyf|!?BV ~_EKW .3G-^+7_B֜_ q<2-!jrdԹ4yoi9h)7BeN^]>h^S\#фT%)[FD%5ͦ49?||*Y*LOd;KY+5#k?FY*0fC?Qԗ+>R&:9$J'gpb:D:wi2vCbl< ,fOzخ|L~Qj2s12N$doLj^&<_S5G;qo*qGBR1%rk3B[x2%%6./PW(MɓڍO.O2wJDS$M~Ew%f[7f:)FW[I8ԑ\5E/B.k+R^˪(f8Tuu w2ɡEHJK"Ywx*X)S uh͐P(̡̇1B%$I(˝L.b:eCsFt\^̭ɩ,5LF\Tʟf\-xN̊Iw\M* y Q.&YY? |m"HQ,''̨Z{Ȃ1sK68YjJ)E.{+3nFۗgO=W\$%M;{u':3DzV-N5 Zd)PJjnIz36hԎSɧSiSbRPY8}/*^fX.f:q^TS N1=QR-S%H&3 frENY#*,rD9ĮU2(-DCRCj(\꾤:Sb[ްuK̍oĎ)JE)eq*CH2mE*'j-!nLjnω"ki"3wn%O 7M;ԣ7#'lNC#ae1ߒ(rfS\䢾G[nIpόO'sQ^SQU"T}?4 %QQ dl~*PD ?*C) h-R1>Q?yIWUkQUVyK0S$SLL~z*f**e7ŕLJgH-Ey!̩ȇ"R\s*r …9W"h9#Xtq EWF0Z\VFqVn݂wy2wn+72ĩ (Rhӄs)<ӌB RxIxN; [ZKx`ˑb_floٙcB64!NžYV5XF]oUҩ=p-9Xrf2rRĽIGZb*E]IU"W-U?zzȜUHK(T]P*D:jZ)_ľ5z~\+z Dd@l   c HA $Examples\FOG4.JPGRI-2ƒ ǒ) -3%1uF-2ƒ ǒ) -3JFIFC     C   @"?!1AQ"2aqBRb#Cr3$cs(!1A2Q"aBq ?>^x6c+@=E]1ت"輢F5O]{?1teuR2Mv)ˋӾ 7EE?3xǼ+pOjZrJ0EYtb(gƼ]8k[Q|C<׹^y⼒l> [Zeg|*RU5h-uGM ڥQ^.:gھs^onV/QIB[J2 tcfF+9WCQ5ST\9tIw-Q,_Eq<ڋbyeH=+ Wx}Ozg=M/,{^dEEF'Dy[^la )6'FJ2er؅-C[$g%PKV @P{Ya%Kb9(sa&2KMs[m8GD#j$9cRDdAoWW6Wr8 j˙?>_&yqUn~ͧy)Zv?p!Oש\t}bFweWGiw O9t̼ؼrx3ev5ӎ~?_n3xW sih&=Oy|_SW>Y4|PnxlRhJ܎#bC,9;Y8JdAa =A4)l,XcuDDIdd [凂ɈMBJodaiYTLQEZ W1#S[q)ŴIJݴoүt` SťՖꗯ2%x=tj)]RFc{o oz -ey7W\]aN<qy#(J=4cK3gKˑ(3>%z^Ymܤ nMfo%O/F;țĥd/qdJYOJPȪYd9r$В{F1ܰByb)aP0-MY\^YlVDK V݈,C1FQEte38U\eUzm59Y9NOYt+hlwhj,Qő$կ4rB&MTҚCF0\2Oj3drUQhu6iRrx-nd%2ܹ@xYZGcik[xˢM-W sv3 5z-x-rx3T}?uqK-4ϖH=|᫡"h `kFs[9af"D`" K$r5M1ح,ȗQd2YdCB%Y%$'naQ+,4F\$CxB[ $G10ݒ,rɞEtJ|!lF,~iSD=S^ G&~9u_no (<&Г)6婜W+[`!-CyeВ-&Y D଄Ia*jt,^$׽l}V|-Ni 25ih_2G4Sb-)7YVl&ce>TZC)S[d}IAʈ @1O):,OB9-"D+whzK:1_,dX IhE{HO ú9YJMu֣X%pHԾ"[ͱgiCt"Y,A`O/h,Kt&ȳy2;15 PQn:o?OQ5T9GgrNS់xfv9I5jk/I<,ySfDx35R4f*rJ/)1M1cyBX IK,]EBHhG-ĒҋĨ$TlF6ǭa9epEx ȲK%yEr{Cm!-yFX'UK4FGg3-x;zIG(rEnpi].HI]qGd_c342-q.qpU)ELŸs0`rˉjia8='JC)EDjr}[g6\<.ʧ: 2/1]~g-;Fo=3> r=PpnwD}>ƮyS5 r5\(ѕcy~Jخ5#pN1/h`yh $5A\au?qҭ2`{U E^;ĮQ}eVrIA a6Dk&U1 -\pYdpM1r ,~QdE`=KL%!$2y,IlDVQ-ԑ"ȬDR)9f MZ,ꫦN({B7e\JQ\*/tseȱɔd\uP6q*پijG]0|ii51^ "ǣ90f-*Yŋ DڞvY$Hp7M%4M% 9/9t^mAt"2n^g? ]rXR=fVSz2]+j3QTU+m,%8 WtL{%M;97)}=L Ī5K{WH{'7~FՍg/,ֺW'ļr+Ov>TqEWa5`2pitkp p^!(%=Ry|Q_߳_bWZO1~ksNb靘dO:$W9$4UbKGtyYTJȜ`2&,DJ-0O(L -0K иl!ȸ Jy&1@BIK%A)y׹C,97\pkE5Ǘ&]LXEnf \F5{esяv{KVO^WUqQg St*2>;g{̪"43ԬҨ TT(S&2If 9cɅgKṟT%8ұq~%k#&mOx%}r2=[Uڛ$L=2a%%AW> !r|y{E.9M$U+r6o5ѲZ,u =6)-4HM>S}pdqE5[MܯhFS#/ѱcA/WhGjKnni]nexokّ5ZiW7IXDST15i.q,ǑLJ%^$ 5 S-Wi.:};ԔEj9'am;w 20e 7خKבK++lvI PЃK{¾Q#bL"Uxy"\_c"Е1Ct+98`׶ZXq]eOǓ[sm$[RG\<3etOTד+w%ՠW":V(EyK=BHWU|%#H= IU=DZ07܅\{PM.ɍ1=F y]H,eΗ:,_TOCHw)T?Q`ew+sYCюPxkk[:˔9S$hNvZL (Xq{ْ̣&Ro.t,Ȏd,X,y{kV=Ez)cuM\zOj+$kFnitTFm?QYu7BP)CK\Ţb/Sn]n]qW^fȭ2.N=6'w^|wfN{<;]3R[=ucOGdx~|jcds8}5sR^TuaG4Y0ѩW,?V^Em8jQTzV DYZzie-Wo*)4Qrv3v&/230Otjm.x+gT⺙r$bi#lY-ǻ$Ki$b%ɱZ=Ȗ.7hw6.OȘ<(j٢2Mn]RIR`%ٹo,0HHr]2o"=4ߩJS/ N梽dQU_ >+rme^8}"UO"U5?ʊTVaxU-ε62"E\#Zjl#rIy9,IaFVXet\6jlke c)mG>%Uw(kY=kt4r{eѩ4 죗$ǒ,,7dl$[&ԚD+EAFw w+]ETmB ݐʞQ/4&պdh#OJOJԩO:vi[14{\#^5=#}, g*2T'}71|T)WRlg(A}vi>9_eAҋq>-?p_h9!iJTśB(i>[yv~JKgϟ6#v0~|1鿖Hߤٮ3*R鵕sA;2Eڌ鰞:0jF_MX/YCvXKu)٘Cc_ܻĹvhҥj?]'F58*EQ_U4`} Hi99g0uSD>g\2ɂ[2F`a,YE9i$5q-(ZIF%V%x4TP>C_ S&ka]8JɾkGqIo=3O>b鯒G=idWgX䮎,,TzoϏ}4!k6c1ـH X4Md҃I-!`i'f+ &U-xSh;nOAYWKtYq~pH ?+\}7=!Nj8TdMsD-4X6 =Ӹfwѳ bl3{6},ϧi_ e{ QihT>řb`,O`Щ4dYF)7MSgOtqnGYWiZ|LFTKNz'+co׃޿G{,N&aF=g$tۤx^s ',jγ̼{XfZ|k53k===>Y]wiU܃v0ؚ8kVL[5]ص^X2y(1nQ%rouF*qRRWMph[)V8:&y3CQ?^?jtco OnGi_A< 74=RuIf GY7d5_Zޑ=rɻ d݃ԓ@xGs9(n`Pc@ Ӝ\ZՙIѭRn/OϞ3*MYm$I_GOC+::7M2In;(ꑗMb%6DJ 2[ ڰJ*쐒 ].DVE 8#Ҳq[X(]K>CgSa):\e%}5GBIpFw55@4qV 'a܉8>ke mcF_q9˶XPVu q:5>C38I]w?I->Ҳ/ʬUad+q_KfU60KnDόIo/**"ՙ9+22WE"ȵfY%tEI B%2S' ;YWVli]JIY IQ$!-+.*ʝ a~'7xӼߧǽjyl`bWk\mf2CI+40j-QQGG(^?2IE>s鰴(thϹ&Me%*˷^IT2.K`]^uYmnL{B 6U:_xFY?Fz3Qj(iͫL[l":yO)Yd8~2HGJ-ԢԷ8u2y Ó$$$l"ȵfX+jKj&ɲ KJlH("5ar,X$ 6Wd4%pHV@(J*UQV4b)ҦNrQDb{zyK1R-[ߡ"&b5=]Fv[C J((٭~y:SwpxlJ Z/z+U.m3|ݔ%X{uS*kц^ŷl0 ^6 E4K{6O$6&ߩۆ*VSIt{Tʣ{']׽.  zR"ɯ0u+zS_\}<Қ'd&t\6`Y%M"3h'dx7I}WR+yPD^k˗b%cKBKrĮYW otSc/brIV()JKG|O&Ǹ 9vj~f|_|d_Tl`S/6|=JqxYjʜ՚4&%qtY2 X`AbXADX6a+ DiX(ܒCQVҸ%rqaܲ1ƌ&.(уRnьxQLqtJv<OElSs|9Y AXԜy:zB*]#JHRm}ƩI=ұ\#фTƷ)[FJkL70d!L,_O q3KbƤo_іJ/+|YԋRPjK$S ?&MQV%c[!:wi5:N[cS6iڶEԿ3>[AEN}Nu7Ci]ugb;Hi? OJZk;ʄd]BE(bai-\QGGHJ67bp-ɮfiFvn&(&\r6-ecMY+0"a "45,I\j$I(؋ J7d&ܻ-aFZy;$VRQVʶ, T*&Hφ!ӍjK%  RZtGaUTp5:_͕O]^tR+ Z*K|Iz̪k3G>:_SmpcF'xQoB(Iq~FTF4GM$QͷrVt5/_)֩M4j׺IF6ܡNbJIO00Qn:\H:eCsG:t\][ӓRVje3peR3G*}DkEn\fE$fw\,U TX*Pth2d[̆!%٪XQRF72itSGey] SIE(Я]ȹ1kMvz|4xjԊ'/u<>"DILj1앯Sơ+^1)L5 qR=hԍӹS'Nv)(_F,>—ԻU[)hJJzj)SqEo(Ju_jqцxanHNHzEHNEnvW*CIʢRNEs}J(eV)shr\7[GԧXԮ(lJx6V9\&Z Avۡ9"V̑H!^=^᫸J뷰УXF2Wԣ_kG%W{VǬPѵagSCn޵:i]J+՟@(mi}Ku }>w5b *4 ƟDTsqƟCTi%1l}'QʢWԉ) h-R2|UDTS-EUW.8ʜ%ʚg/,2cthb~6eRjF <3TTs=Gn,sʜZQkʜBWND,r!jIbiE*uwz-EBV-~` EZPUjW50j BnV (R&i7iUf);$)+֒v0eȱ/*6`hGB;5jiUїaU7{ES,?t*U#}K֣hHjE[U{TȡhHjEZkhLSI]Qu^⨇MS3֡*;EJ}HzЋ73FW9@&!Dd@l " c HA"$Examples\FOG6.JPG!Rf R;)P5^QrXCB F: R;)P5^QrXCJFIFC     C   @" F!1AQa"2BqRb#rDT$3C4S8!1AQ"aq2R3SBb ?Bmzt9 3#2BN@CA$e n&bXos2#q.^D Q>kݽ'j exG2 m=1^goksݞx-j2&GmG_gŏGAKi 8f{AZ$;{~>!xk_B k.47vW#ZFOeè6BlANqkY|3ְnઁ@wOn12~w%\3؅ISb.bw+~p>UO폪Gfxq:K%uk9Xj7dvhymioZ:4v]j{uP>3I}W) ٟh12«ݦs<?#cu˳ê3 +WK}!XBtB. $\T&(:B. ,:"Ѫv*"tQi`JǴi!>Cw]\a u8Y,,w` d|:Iq$$- ڌ{/i7ƼߋO JeX\PZ<OʌZ4<3TXԒu0Dǘ$`qjui"^ŝ-7k)R.og6a./O;sM4um4qU<<Cͣ*̷i8AJ?5Og3j)l;0G{>`O/^%-h/#4cܘwzhlw%AgŤ/M|_zu^?H̓߆O~Fd-U %". "d`jwJF+ s,Ven1MtT;23$B7 (ФBv:ʮ'[KUҲ8XdI}ִ U'ck Τ[tQ O [ ]6/Z=vp)6wSX_x \!Rx-^a,Mtǥ8ESX6(2*xmk e T%! XI`1$B,Kâij2X'GQcO8辊90/)|' t]fϢ8(IYsZ?e<Jjpȩj^h\WCn[jfhچq_x' =\ 9п |T, 25̵o}8NXfMveFKXJ/_M c+ĬK\ 9ȂYw?ho{R~`H)˟o\!n0Oq ;Itkg~p)M_-u.~'^?:"$BP".b%ј"B&d Fb3mt]72\n̋(Sn /=p^4xl@VRۋ4P}KW%$Iԓw1])3RMJеW77nɪ)z'p.Ez jLbˠ1j,謋*L|2"r)SY b,,5*~OQacB*2+"Aj*BȈnP-BYj@.-I; V)0tQ ElC;y=WԞ 6<-3'WoI%!XX-3ں/6FZJ #ג {|N$HsS7to_T,)X"ǒ_A #p nP>+_hidxc /uST,I|E/q>,6f 6|vj.O-,$N-#>8dJy&^8߻nˈFJ cd^^ED+F?$y7t>^d~/#:MK|WBW ߆մ6a+Yܩu7|7N)ߍ}JN4Gb7 R K,&E$sl"1; "-&R茷D;)2R)mtu DXPZ@Y# sZ'r젤FDT d`mQ4Y`!jF^m,m {`l>`*ޏQl^hǫ{/yGHԣĪs~EmH1UwrB#<0KWғwtB?r_!r1~4KX?WX/}<Ojcwp r_x5J2 á_ǭvŶE1)cz2GoGW¡ 7n8an(;(\V2ұh(mԆ=R) in #9mm+0+.`Qjm"u)eK; (*2ˠ6ʔ5H##@!bǢC: N RNJ9R2Rb1J'XS2+8Nh/d(XUm/)(_W[ {X>d}(1h{j,/$R9RM.m&찬~xSJO%0R7 ӂlm!e!跙S Py/G`DuM8uåCAsiĭ.`n:/6;# 8CwG07'BsGĚn6Z,V,G+b_^Taxڣg 䫉같Sl51fA?F<4_Õo  *Ers]X"bMݐ;$,V ,[r+vMsSKT[tYt [JbB˄Xm*];+=R'aF"%JkXĚbViUvF0&UC<.?SPtw?y- Z 4pu+ְxip:R0GxqIU7 䥑t_3$U0N'%;M5;ΙؖHq.8O8pqN8'![WzZ`H"+8D-'*>@}d仄ȶvZ qx/tacT.nI5tW)>^-9i\}:6b̷AnJ'eb@U^XYFY$ZLZG,VV-H#bC9b+A)L6VVAE f+&>+&ncFXvNh 4))wvF+Y"H屶T,JҶ5.XYʳDʵ28Zx6>/SQ3y<667QGlm\K=o0w7g;46-?2I]YaԻ7T4-kalzG.usISI"yq ;8h0ht9\}l9˂W8b$)m;8L%k`d9߼s#qy$isq 'Kmq'{k]~%Oq-UO Ӊ[*l8M5.'oy.2S<=V3&NM8}Qls͒9qX4FqR9Vs:jQZPx۝;9=Mww?˪bՙaϥV< XD,91n @Ynb\}TLܯo>NGe4vT26Q*F.=)K`FE;I'-v;$,V]hdl;j! $% S;%C@q=U0'2x+B+uRQqkV℔CeAC-mDpACfRT "lCI1]l0atPRS4E- c{vGf!ٜ8Gp,fs=`Vq&ffqx%>C\ J6T=SaKuQ^O0sbo@sN+V>ʫ>5!s,s)ͭdw~I|I[9cT4V,TDꫩݘܨu`5Y>`I ꕂmt)Aǂa)X6sUFꋞ+$ T_V+47tT[uH Nȶ1{8rNe؆%,F~kT hq=q 5/3ΟP;2RQ8rđKwpktG$> T1ꐲܕ J4B!jb4ŠU PT;"D1L#{"FV@*f`lVOɧPvNlVS61~+G [`|ԶЊTVNȡc{Z.J]X~1<}kAi=R`1]IPgJx@|~UYkhĔvz0X7DfsW84F!~¶kBwBZ*5TI E(qT1m cH<3D/VblZ%9"%]@0}ǹOR5 q#R.ceGj@9e=JVrl5@%47tFH@3TՎ'Ճfy[/:JSʗ{e"iwqHj-TqF&Z5)URWe&l-pi Ǭã$ VUa)ʖbNjwP:8M!3\-RLG%"iKV= GnH !$Z:%Ẍ́++Q9@~( -ELHgJ+B:64GchH[^ ktà"8Z gaxi⤙M& d\lF}Һa'r[_CQ(J׉x=쩉%X77_ЛqoE~:۶a1ue'8:=X[uV찹5ћMM\Yc13R{8ULG ; Y0%[ydp,9Qʼ9G]EM[!)$\t fgL^3LtȱY(TPd )l_pTRH@I(乂v>u5<]:(#c{X\]N:+xۇe.e{L9rr~%qA պzqQp x:S.dvX&__SIXv}slpE{}2|mTlۏ)6@7*3~}R~&lJ1Q O=S4י.dcdq& [Ǫ7U%&풦Pu9עIlG]5|.ov_VH4}|O}DyK _Ref412028393Dd@t # c PA#,Examples\RAINBOW1.JPG"Ro,nV}?"Fo,nV}?"JFIFC     C   @"@ !A1QaBRV"#2bq3CF$4SA !1AQRaqS"B#23br$Ts ?~gӼZX֏YzDrjꪕVR~dxxͅjU6{,+Ce)>1NYgE7-VkB843m֜"p0dr2R*ߵ }֖PNkR+}PYsќGԞG )˹_wB4mwZznvFƯ夹AK5T?3іx2Q'UGxι{Z dkW(~ǼQ['Yr6RWSK~iE:5tAT,.0R3u+-Eڎ͸d{}MOV+ թ?DhθOݳ8jcաxu$Zk>Ryum*SU~{ԓQ{#'% zt|ƵLGnR=Fʍ8y$_hi`Y3jV=Fj6#_Y'.7g}qSW/lRr|[{$K*V~K 'Eq/Ř}b$N;L ޷^6#{?/ˢK=Zp}Skf՛q6Y ѭR?b;埮?UVͯIц/Zbvv٪k.e[d \WUO5{I'- EUPUw*uot7T!5|_~7?^BL4a{pNQGzCJ%k)sW!ոt{n97rrulu{TK$c \a>O|!0;ܥ22ɞ3QqvU%-|fw/- \bF\WI~Gӡ4g|Nj7o- 6i|,,S\_u4Yz7.:-mџ+umu\.iJyM>͛QSU_p{sV:;t2_ǣY+!Rg.%4g-t+v\^Yx_GJCV]K_6?<~guG/kWt^x}?3a֣=P|NυcXWS,`tC<uGuH돾]\6€թEԺyo̵L6vU'mw;{RgT+ԥm'Œ\hk%:5=b U"UFViĦyEz'ԚںNiz;SGn.R:6t'\=ks}ϱ~F)9G1j& =t ~fy+ r[RUd 4nsw5J=~ӜU%7f^I+p{_3)9ɹ7&[0Ym { s@l7Vg?+V5g)wt#Fo[U7Y;T]d<3^֭2~tԄ#ZvW06\oh'Ug^}jSisoWxAEѼU%v/3EbUH׹Ά 95ykҽjk()њ76m~'k_RڌrNpp[GV>DtkG~a_p{ #JK[^69;6$kmK<9:5Mʣ[E=i=|ϿmUVJ}ܭoiv{&hޜF옎-Y׏3tW [g輗Kkǡ -p^(ԥ58K&vHM)E*S)uRZzks@1Xuxy+xƥUؿq._OVmQ]5f Sm)nu/~/ 9zk>/_; 5ywK-jZU)IK}V5-҃5n?:VˬW^B/%"3QJ_VF<R=+'֖'PܣW15rqNkG ZgwnTV#Z?Uc=SIq[ݒ̎^NRoC]ܳ}B5iKx\g9X\-o' Grgj/}Ӝ`o'$SMsܼ+ɧyq^ϡ֡|H9B+ZτkR{]2SS=U*58zkj`XPf2pqm5#vwq2~9Sqi\e:%(±j]FPEk5i}dE{ׯ-|],n*7SXԆ]ρp]~O_ҙ,9IOi&]0J:_hF5 Uhi,iq%ڍ AP<;ңZR%h\NҲ T+iLKm)=/A($kUxqykMNY1q[f; f9E=\cCXFqJ _٣_ew;+Շj]븾iP^KWFzp_UV\Ѹx GZ{yHw~')j,VniAv|.38Q~Rjk3:>֔w+ב>U'Fq\29N?Kn[5go本n[Up~6:THlR~Rc]> XVdz87⹯l~ǯ*!3גّ:a.;JiV/|Z*uIΆ{OUiB;K=;*}+z8Mdד7\xmL&\//}j466mTKyat)ӹڶ*;2]jXߑד.߶p'.:YkH y>g: ҷPڽѲKW:%idݾ2^'8_a d~׊7T+kSyK4q*uK;_8/>t0jBo /9yuK w4{LNZ\e /#].XZS/1{P}n5V::K95XǪߊ;]jyiJ$>~B}xω8G|1i/ۿ*w&/mZ~IJeryս)k9uI>R]xtէC3ڬdScuJUӎ.OO@e}cI뎵a d/N$OXYo:Ｋ|EjÇac~m1g^Q.HＫ|CefwU"*w:t| $ՙyVＫ|Acec6GYG!;*Y{WoxXucuh$Ce^wU#+_k'Woc< g_>l^rE^~/j?ux/Ȏ6CG¹#_d?5yyVߑ%ߑ[>l^rFڼＫ|F|^g=[6'oȎ6Gh\޲9*Y?Ｋ|F+ G{V#PHʷ<~=[:?2+ ";޷|ؽrG7ϭg^sU!ֳ9*X^d̛$woT<+9^}k?j>yyV{#'{#PHy{ʷ<~=[:1}6rG'Ͻg^wU!޳;*D;|v>yVyʷu^;ޯ|=rG/e^w5!;x=R{޷|=rFzC_%vzYWi󶮫ޣ\NTzҋ{Vo"^Rink^t24NY+q[FJZWЂ=Q#Y/GOF/ Sz~}5~TRyna;*?yVׅfeOk|͔v~k/k3ʷm<3L<;\Z1d<+: ʳ:mf]cuR$m #m#VV['%umM[.f#g!X n+w a#bq#ʝ8Ȝq;1[FnEn*w,"q&mWqdm| *w,G"qƧwFw;TŽ1>DOލ-|)wO)wX} mV]N唻ՈO&>6-k2y.' $>6k6i*wlo>QaWI`q]ő[%O2;'+V Gxx&<,z3z#o#eW釧dՎ1>AۥĎy"=xeˉO}%.De2cR\O;xAvOD!?DXtXG`x잇,:J^b|KV&rJ4 Obj{.fIQ62j9ꏁdhTs+s(TIƏta5"2'E r*s*-#HD0+r*s+/,xJز4%"܊\FE"eq*lRűF=be{6R8"AYlTdc1IF\ #=S̵Db+B2jؚEQ8̭T-T$bjD]/1t5j".>FrT*%Ԡ:t)Y\0J\ ʭSZ%3k)G+:'Qk0MT:;ʓ­S)vq^IҖQ4Iҋ#U[yeԦE% z7@:YMY;8 u~]UH3pS:^o*Զ4eM_/v)YN֥?z9p>dxi.v.;)K|Mk/ڶMRΜ=u^~#ˉo4WfP"?+.֜TWtH \2KSF*i>2ΙN )~X 7 B- P."=L :p:%/ (M\_A_ꆦajjk6%4gEȯ"lH??1f{ԫwL}ٞ*ka+6ǫ?fE^zn2f{ԫwXD%_g3Z"Ozn2f{ԫwq+.Jm(-{=UyRYe܉YmuVqգE<^znViמƋ,J92{=UtݙQnEW}8c՜u2ޥ[yLמ*Jʯozv|V{=Uޙ{iޣ[GoI#i/[gw+DyO4yQDtL߇JmǤ7y^^h?G->9mҼ|ʷq}%=3*ǡF%^JӫjAU8|~zn<^znMe⵽VwxGݙRٞ*SɟCWzz+Dz ȕz ȼp|ˬ~yKȲ=XG ȇX, p=hXeY 7=xl43X [ }DZ1xl!fO9}_}dz*HmfO9r{.Ml=WHyC2xxS^9j{v8U8U3ŽX{®§Y>p.UGru%E?CN9d4X|~rشir:;T~.g:YQ:2Ꝉs3s9Fo\C^4yF.ffeEH0x99F#HD03r2s3.Fi-992cHӹh(ȈH4U٪Z̛2acX+if-B+fic&[/k#8FV2f 1k-Fx\2/Zf R2fm3&eMv.\s7r {R!ܗq>#dݣ7A=^p7b;§'6uTgKܲlX,Y+JĶCd(Q%DW!!GYxIJW%6E Y!-J섬Ga Ͳ]ZX,2f^%"'fC3fv.v/6S4Sdhɣu"F˩ћFG:e"3q:c;Fg*w3q3q:2ȧb&n'Zrg*rv%ćT,uP7U,s9KKbYU8Bʡ.8j*9Rʡ9Ip:OU Ue'!bV%F"6}bĥ`$JQ YJȖlb,,]-eVi$a ͖ṈBwDKŗN;2-ѢdfQ;TKDkL2V!5Re+rTKD4lrF)R-Ѳe+\-lbf EhL;E!ėT,eCЧrg2e;o%ėTJs)ʡ\NP3TYL*zS9SI~~LUJOvAh#JWe$XXp(Y;ȋ$ 'tJveb8,wA;2ٖIƋNIٖNCFزw(6$;R3R&%TJYHѢw,c4Jv%Z5S,bJv8-)dbTMlJ*DؖT)H.g,KFw,H#%H#"T&2%Ms)9O$O`Um,qZ; !l$,-EZ,-T˧fXh$@$ħb8ӺSd)R)ؖh;&JbW$)Re#5+MNjV%H剱)ܢ)DhRv%HXL̓N,M FJV,MXĉO)XH#;OX}DyK _Ref412028912|Dd@t % c PA%,Examples\RAINBOW3.JPG$R4;8WF4;8WJFIFC     C   @"7 !1AVaBQR"2bqFCS)1QRS!A2"Ba ?!"~dTiRԑi[.ir4Lbʄ#1Nc&u(Ct[,m_ezDb㴟>s:VdV+o>#.c.gG!dIU7_x{9Ԧ*^Tx5&rSLtyZ;I14iVZkz#)03SS1bخLZ䢎YWSRW"'r&8\zYyuR7ӓ)[&4c[axN]\~eYU$t>#yǤs=o,bJil!p9<_a8zH+g%sxk[,>hf_nt_xJ¼*q&b⤵)䰓V|p96l'\F[SvEסIˣ{TVÍ0y1St]-&ljQo"qָ\5:u@(,̥7կQ]J4R؉ qt8Σ%6/zi:!+l$s"PRZ ov0t%MI#Hevv/܋VPRZln9٥R7viFSk^Ft{Y:ʦ^xK-?xo?qE-̱2 'ft9n2mW0$6`IRwסqKV+ ? eKnd uoO)Y;Sc3X \.ʯqgV f'f[i ]`I fX5t*"WaD67'v,'UcJpX}nZeYh'hiyq^;ԫw ?.+:nJoS/z˫𝢚}\W*Ĭ'5ȕr'ާNіJps7X_" =S_.v}='UgJqҰ,3uާɧxRNcJqְE}z{yZw\Yu*Nzn`i+V/z1ӼwVu|Wu*ǣ_q^>gC;GYxR4<UQ`~ )^Z<:>+:nYxRz| G}giy^9ԫw :>+:n>X/zyNJpӼwV=o?izƯ{h|gh<UwV=W|z{^gFpw=7CߴW/z3w!yq^;ԫwߴe[8vJpy\W*ǡF^ {y:{|W*iyqf;ԫwk/U/z1񝣏Oˋ1ޥ[<%U?ikq^^>vAdY#Y7"ɭw],e=X܍#r"9"_qxKr.eE֨Ey !M.GVH܈wdA}DZrm[5c4Km;\^,p{qWr^G;W+׉5=ㆧcCHxx'prUk=;_w)zXJ>9*HxxՄ'.u>9"{c\c&X*Qz#OquO D #+"wO}S]d ЋT_e_F,=zgY9{CՇE Op{Բ7״q{xRT^^o%}o KqYa{}\^x O\ﻤ~w,_QZ9`g,{NwʣbѥT]S.osss%S.؋Ψ4x2.nw6 xmXseEH0x\lJ摤hiNW6q4#EU;FF7fG;iTr"0iUk ! 4WR5]#+i5RFQH*wj^1W3DW+Ub)Fe3SL;U.ErTIz/Bdާ{ *eoto59sK%OqW':٩_(Q.r>趫\%rXQjK(Y+j-B1dMvH%dZ(QjщdJȴv\Y+[+B+H/e"֑v.v/띍S4SdȱEԌ#+R";v/Ei~s]QuPSuP֪\ʪ\U *"]T"puNg"rTɸUK*YT&U%TG"YT'7R񜪡*~XQHĥ`%6+D%d]+"mE&(YPKYUJja!άb^,wFIٗ4L'tJ65be+b,jrV3NXce+R1L6R,c+R&\[)زe"lEЦJu"mqMЪUu2|ɸSe3HqMҪs%T9ePˊn.P3TYLT]*zS9S9SmҾ%+ EYSRrEEXXB;2"% 'tJveb2Ӻ ٕN̶YbEve6"Ɖزw(;%v,fM̱65NXJŔ64N唬fN؛R1R%;bllJS;'*FJDljYN*Ds3dN)fɸR%HH6ٜTR3<$޾֢ic*VH[ 14Z,keINӳ,P]ѕ$r)XBwXӺSd,YHN؛'rSDRu+Pf]JŔԮI;'fW%;X#6NNNX'bTfR3flL̓Nl&YLO%>fjDs6fR3Dٛ?}DyK _Ref412029139}DyK _Ref412119618}DyK _Ref412212281}DyK _Ref412453576}DyK _Ref412454596}DyK _Ref414188528}DyK _Ref412464620}DyK _Ref412464789}DyK _Ref412464870}DyK _Ref412528893}DyK _Ref414188528}DyK _Ref412535627}DyK _Ref412623075}DyK _Ref413229845}DyK _Ref412625191}DyK _Ref412631781}DyK _Ref428280785}DyK _Ref412632666CDdZF# (*j & c FA&"Drawn\Adapt2.gif%bC *ӳBnB6Ompe닷 *ӳPNG  IHDRZJ<3VsBITO0PLTE"""333DDDUUUfffwww{ bKGDH IDATx] ewAxC-m9<%50WQQTԪ(JBԪ(JBԪ(JBԪ(JBԪ(JBԪ(JBԪ(JBԪ(JBxjiwq+=dji=P_$[sw{%JEE+PjzAE:pgR+ ׻aY'I~;vPoʋR#8p)2k\^R4b;54kڬ W+nȭwڊWjzZ+1Fi}_Wcx-+1)Itgx)p`c5-ӀoV0hUVq{<g8 RD+ sݞ|Zj) (_ݕ_mnnＯ/0,EVY7<',f~X9먐i̮n¸}8jY-O[j)qe%+wW$ P-mK@G=~#+8oE+#4a /aPK`z@R 2՘a,fJ;n{P8A@F24hz >f-lD`5_9LxrBZAئcDg^NJ\7~^m[ pAOpؒ oLՙ a>CgtSɀNn$Op+tҰEX?<~.O-\O6/#Dh 5!x4d$/z42 K5|!ņN2VbD'F ;ܕV`r^uPFC$qݬԸ[Ln`_Pk,HRkEZ׆@BHb3w&pmSw/ oxz$5O-= \~\;O uɫZjIt.pcVRD0{7J-'1tA!4,210;pZ~ap2tsenzjE156i`typl! x2$;dQ1 \4H4c9@Z侇Aǡ.ÒYR?vcF`H-`Lcyʃ ]6G5ozguW 7ƃnOG=()3tMV1.?[d|U~'&ξ31L1g#Z.땡3Ŏlx R7鞳Ir0ԯMwQf\|'ik$O4f IA$}r!j%%jVRLsR|>y+'^ff]R'!-[?Z%~"T30ɜ~yYJaDI *Ry؅UΙz;N`8_)*AN])|ܫ\J-هW<i+`LJvS^a/U$4WTOD|ZoVRd}'ċݩh=* B,.+,F䭊 s\PQ5v vUZQk~lz*<Օ n+yÕJ@),hibYx d΃vTL,7[njB;QveJx5G-wcu5FPkK?9_ڪY_+}YE ) bLOL-cWE7>7s}S `D^U3Kmi_ndKL_wv_֋=L fVC(\x$'fysvjm'Z;tV.ä6LP&JVtWkQc;q\MA1pZZ\׺h3D8 i$j]ϾE$X)n&ۅٗo7o=K7 ?Cy*aje{=\m;J0edGB5uX?ZE|.jɯuc0]ED#DkB$\#X ۙ0=Q.] 4^Uc]ByvW%?ڷUWtlfXS HEH𧸛=- XQ9]U4a֑Jq h_Qkd7Mv]9鴬|7U\hII#0kZ$O>zCˀޛ<52v# v v7Ӓm̮j.}Z|NV˥)g]4@-(iRzrME=)7e`wk]Z4lE% LӏVk"QURV~``H-Rh>~ 1ZSh9RPO~+E:QgՕ~WH12g7v:n|5z')k`3VΫu "vtESng\0[4>ZZ7Z ]hjCR+lvۄq9E|t4d 5"|bxAHtŚHAMZr2#5aK%.׭1Q.c>^AP@܀:.2WJZ~r(yڅN~ƧMM"&19>-9BMKPȇS;VqY[lʏxn}c:$_)u}=Zwԛ6vˬkozGS=LZyjY]љ.Ƹ=/[ &!nۿSn@ ;HZ}FJ7ZD&!5ά:58 $5 o'? W;yiѹy_AMjNeC/Mx'7w1+Ed,>S5솓iL^ 9 8hʛ"nluHj>߿R+{ =Z ctO9SncBhh`N=b%Ls[SAړbTr }w:9$gijPrg%?Q)irGOPNx`vw;%rsN9ַVm3㼟g yvnoQKrL֫]|)=$}'uR$5SKհwQ_FkY׺W-SP*?+o0gؙӿPP=o}*h)vZj'JUJ VjmwRXNjҏV[P+uu"VڻWcZv.U[1K%RK5fa @ +7ޯ9$boVxPKKoxjcGϯSv-nz Ӓ"P7Z!Ȕi L<_Y!)9n}}1~g*~vi@vi|T$e 7 />$*TϑHJ@^jCWfծTkNjEOY( lU|IS-h[ VclS+sI kz#|Wj-:nK9 -i7)dۿ-죃[_ O~~iEB7!Wa汥V.sKZhbOll(35+8Mԡκt8/@qZ;d+ƣTXUqJ ֠mN^HmgV:'C AWjR|^NKK5]뒼Haӯ OQK/'`zXXx7>#Sx `T`zPnB:fȇr'j~~56Gr nZ`*tvjy_jw-TNA zYs>r nG {xd$KyO羪iGÒ=sGem`QӺ9S>%X|AVwWhݟY?®~NaVT먔~{#C@uQ%l<~Y%5?%`lqHe+i҃9#yF_jI$IԲСIZw<>Z_JBԪ(JBԪ(JBԪ(JBԪ(JBԪ(JBԪ(JBԪ(JBԪ(JBئVWq5o6=!yϖ/ժ#bZz u5.TEbsm4F+l=23߹`/cZCz=L.ӯ"lA-+6q"(6m' XRk ;|-aj+TG1iV#i0EZx̭>4,MNRcbNm]B1Cլb R[P˭SEQec|-b?e0]:0{)B(+|uJa$fT˗Ĵ]!?T?=_5 jCR=j cRtZ %rlk: $P ;/V͚ jKh++8]b䐂q#xlK_Rkekr LΝ ZjY#l'M7oOV4=[wgTح/:ԲOGe1 tI-pfE,tC+ѣS3ܱA+={N07f*ZQF%9&.إ;` ԘqeH-PU3A: +}cyXS8V)ĬvZq2nmځ71xVuKɆbtiDcүb+N241_K׆vъ]R ju*g IDATl#ՠ]/4{X#*2[_P9_LfPͨҞS%GRt?J9 UC%kaeI-7$1v6k/J>kѮ!m:C΃ [RL,}>VaJ=bZ;gja`U5p8A^O^+qVj6dcjg_ӘmK1&y̺5]d^ 7vʜnLҽMqW%u/zO=4ݘۋ[njo;p@ֈ>TjUBVE!Z U7%8SEVE!TjUBVE!TjUBVE!TjUBVE!TjUBVE!TjUBVE!TjUBVE!TjUBVE!TjUBVE!TjUBVE!TjUBVE!TjUBVE!TjUBVE!TjUBVE!TjUBVE!TjUgSKqeE7ᓩeX_$\j-M*үwSSUѻۄԉ$ׇR+k(U'Z܊ϤVY^z;b,g5 RnvPyzр6(}i vjhxzUǰEkjRZIWjzZkcn}9XQtޖvg|jT w>BEA8UYL+% J8~jms1zG: kǼømɖLk W;%(C\ؠDȩ ДFew,LbLIB[B ׽?֭{m̶6ZpKVuQnՃƧ*TW"WX*p!A[7g$ n-jZCRn+jez!hO ߝٴa/fj#C@@ ˴Z_ŝOy-4:nI4u3J_7jAJR3L7Of5@|aL)/J_^$@RgjZfJ jX k?Z7b2 lAK$dAQ}Q{ApZ/D>*Pȇђ+dKQCJCtϧVRJ a{R]ȑKU{@1mf_OCPWj%I,<2 w!T,,_äE<+ڷ3|hKRImSWj|U̪qX_O?JQōO>>+]*t_h6Z/}rg[Vjz~aa"y<u)~ˋ:՗'$*+VI2yk#4y[m|XPPkZm-Yj[6/+B4ZԺk{/~U)\H_V1 K W혤{%aqjB$ Ttx 31 +SSgnO)G䟁¾8,kOsr,skZW u]Ϛ5rD!H,1;j)w;[ yʯ5~ D_Z4dYDgoDDKUN(mܶ ~{XZA<ӕBB٪t"c3ڿe #(23aYӍS+LxaA%f~ !VV∷éTfy)jGD:ZW^2 g5|r!R}Cϯe9Lggƾ<NW}K>񵢒=|gPͥh}U代i~trC1k )b W~z5n{nRR%[}<;vq%dmRxL`߰,?74ɕaʟ;_)x<R+2U{5W]ST*VuTJ4ea/.@gp (#CY?ցF+k:V.}Hrd*+]~f%|]BݓiTӨeuKm.jJݶZq&xYO0^+UPP_+&n# nquȂ}]Ժ y2ϚL{|#J]qJokEkUjҽԺZvIޮ[Rq[|T.>2nh|1yv%R+}ckێ%6l~Jo FUֶBDآnt~Δg5p˗<Ĝʟel XMr[B6kܦ3$ȗ4sP@"S#:MhZ}Bo?^&Bixl5TZ{_f{])+7% +rjILВ"D$J: etk{z ݀Q%/'Ӓ}? |’I9aY{\J`x~, )oS$?Grk'-gxð!j̕ӯTk!86pfY.^Kz*XkBdRuK3~ZKD&%]Tj׺>pwf+̺R n29ɍ~ `~O &A<]0ϒ̔3+; VCL$pR^ӗXV!uV۱)_ff$r'6 bG!Эu>-a=xZZ^kjp~RF`%-^7|>[._5_">D+꒞T۰(]X; LNگԲ׺¬ n񵶨x5~#j AZC](Ŭ+f%t펗xkOkW~4*nUf}+ zê~{n"X#Ҿ/tZڬmjes>:/K.jfo.=@q_ vf%ka|V oSaϒa_ޜZRzDAj)RYtuҾVQjf|J-5zʶYԺ_!*T>K^ nl,iͯ9CAzzYnCu;/yR}̯媀/c0K!9`ˣ63Dpfƈ0[ k6 D/%PDy֔?+11L"jr25@,~ j!tQ4g^q*kpȏ,'!&o;SΣ^MVD8,Z堂iL;a_TyZ6֐ίMZk jm~g;smWk? O`}4^)W˗">>_䔈+0) 7D'/kN):x跧h֔kVZ꣙XPRAy<]HpFy4ZQc<̯Յ@zC屙s-__g+]s/ Fg=6 bP?kXߊDPk`Y"V gE ޜU+R+x~V|~aU) _G3n_xfL]D^Zײxs/_kz~Tȯ5-<_+_ր\~-itLЕU~-VsgMagL-;0QĪ?`k4s'܅ ?;YpQY_]?~~ntV3hƩx0o[~tvj0OY~pp˔3 ),ϵlj(;N,G2BxΏ6uK mӣ:\Fw=ϒ,{Aa{yo$#%`dq[qP:A ٜ.qUss(dZ+jeUYE;N_cZt"հNնʧu?v>/ƍqOCBin}Sq#h`(55g P)T7u zs׺ VKY09^j̯ʧ|O),vPſԘ8Mj)Ӡ㝞*l(kv.\]ZM|5k hRԚ.b"p,kSȊv=ӯm*f/PKV1+6Z䨵1ⶏZ*EDt DZt]ޟdt enw`PT#I?Ӊ@XbbZ”R=6**{OLرDy>t~B|V?QoubIz(.f._5` Qӣ[ t7}or o:DZMKGEXΐ 8gXz;˟Ayb=Dȿՠ6u~!Zb+V"&Na[:_3 eբZZ/@4nj񵔡WAf&[b9K)e?N,~N|1`Mlñ0V1x-CHj~ZZ]_]gx V,]%c!ZZ远)" #E2m7d 4ӆwfrw/ݧ0 * e\G% )Vh+?|Q/b@$SND5˯%!gk1w9zٮ_d_V' 5_/4NzZPwznɴ?A-x&7@|<~* $ 7fcMP CiFZC'IHYPK#I)kDϯ2"*nh|qJL\1"[X.۝N+0ڙRzʗ'J׺/ȇ[WX9fvT}-]a|Xw"ɳNjv<ѯ]*7"TYՔ<T 𫩵)>j4KR}3(vjy_o(ID$VJ%^\%:?a,׻$/X+:i Zq/Z^?׊߰ߛV<˭;%`ܙ_Qn(߳ O4inZZ1j"#kfj)iƍ@5ei J|rkYZƗt+0:p LYp#[NAuv5~%E{M--~s'R) IDAT2IF3xoʖ.e$.Y1>jMTP˭,(4 +j^۫V(b[)^97f#nۏ} VtTwcf婛%`)C@yWMrdM-CwRˮ<PT} b~2xw7QkU aU4(Q<4aIVY"`{1d?{=_[70S EJ"pBXU˹4Ϯsh2T:9\Id;+)9W:K`dCtl!q sxtޘ7w=:BXFmG v2}&K}I-{e3đ2OG$zkѴHӞm걑WX{&2kٶ|:f=t-%-m+9iy1xKkJ,,cQ0&+l)M(CafT)re:iWa2wUiuu/t [b9%&`H;&Iˢh3bs{Pt0 17*Q9)E֒g]Vܪ)œha0* S{>E-|A&],atTv #Kù촜F4-5DsP|ɿk *Qܖ돎vg p!~^0cSp~mЅfH"pZpʜD56}Fpbl3ϕakTX/iܥ qkgAi^U: [lLH "_@1V-\%}N#`p4$m39cbRb. ,7=^ZZ;NlW1ٙ['|bdYEݱnx:WB;u#bc 6e3F'saEEw6L$ܘef1Hv 'j&Y]qY.~%}}BT%^( Ά#E/P?!ʳRVw?]p>_`4wD9 {(bsm'y杪`/ ea{lYv=@ź_6-e -Jk`S:g?ܡU`]qBr2B]%ɴ 4p7o9P1Bjd-j}40ZƺٯMq.&2?d8[rf_ІϙHH9f!j\@ (Q77x@Dۏne"̹@w0ClD;T m`L!} Z ">!J)v{ ԆѓQmTIYo*ig C(vDEMxl$WBg&"sQú>Y+γa x ,=gt ʬW}'NǪ1OpnA0O qY-JNs@m)heY$k^ńTob<+!uIWv#n͊m]۠I7Gļ8*P,2߫G$5yYX LVȱa)0r `$ܪ #H!nIF'F Y"ʼnde'|?jm ?X !q%jV -' -V !QH^{/C~eeqd /h; b*Pyd"Q-I4*yByAxsd_p]; 1T~#@ M0jT&S 4&9M1w8%*5]v8Wv7m7wpC|'rP^IW@` Cܖ_;y3|A4[q|'x/q/SIS8?j<{2v~9a`[vuo4Wz,e)akx5$T> qqz; ȡ ]l'߉ 7 15NlH@oP%iE=fi'z2(}%:,T%>( dö'tA0#羠0і9783L1qgCO 4і9NTb(7 ʴČu,X"AI2%ԹySw~eru8%[ͣq ` mcI92c&qp!8>A}fN?8#`yTI b2I?Ȕy>275|h `h;< ^ ;(tK n_xyNe`!~ǂ2ZX 7?_p|{7Zm DkH?|/RVuCFQY ʼ!(zR_?!~+fOwzKAlx (W~fAw8'/-'8w~C8 (߆2@Pa]P_ ݟ.66(#M0H $ZLw]W@up(xr C.jǵ/ȓ!@G?ZN|1J'P~Kʅad`*%,)~݋H*Ϫ>(D8X|IQ :7Y I ">jJ8= fqG |k qT'mNFl#h/Ci1&fP&r(mZINJg#8_t[6F(V=M |HHd\-ԛ#(q@uQć J~C!A&m 0O/hWܹ %϶S!a4UGkn?O\vd,Bp19DEwٲӏ#VAKBv]О šMJs3bMk `Чw]m (ND}zզБX|`ϧ "oӱl;2 ?P  qW=>Of6C(?gKC'( |4Wt-_0>jhE7 1ӻv4uA*:Чw]~ьoMú!^P"~ |~5Y5ċB_gImרf#BߦV=M[u}3J 6eD |7+e&X&˄MIeV#Cq@u᪂i:2O`U =4UA੦3!OP Jذe4BcL!(242x4_8֕F 6ie*vXĴ#N։[_*eifD2Һ%v@YdNEg:q~ Y-_tlPa0ɚ΅M,%|(X6S +!;q~ |" ,x 16ENւeApKem_Xts_wy2BZ_R*׫@HwV-pKliu'!ը7,},c%-Yy왱 [8νZLe@xjvpCn?Ӭ88; jrµ4APU&F CY˘h8AU0, aL'moQ{(Zk$٬jFtC>ka,릂@wW?w~/"7<) 2FJX 2XX6m@?y}oE2v,$R{B:E؎bh` nj0OՐ2sh#{tQʼn,U6%p[zݎ (#Yoz!>)'w]qQ /h:`K"| \qgwm OstHs|: `p}₿v: O0#QeF5q2 _۪ ^GqA_phe(({2vZ'\~;Js@ u6EnYp_YIipwy}ae~`(q IX>q}2)4? $js1ISVBѥRz|S'u . ݤµ_ȍEzp\f4%C+v<(~v~ZS[,rvRs x+"H`=ġ OQmڿ+8LJ𬣩0M,5E<#Nm uO>\!/Υ;f۬PE/}=ΔAG]'5zVs.a-O_w35w෺hkԪu8Y|!F$KXq-fŨ'(MF/J|<''$8(MF̩"5 i  "o7ь;]V]Lї^s~Q{mbp]g <)߬Џ d/2ApU-A[i딠]\*5]9W\ꮄ/Bu&̉ ^3ċ>݋tx]*1?`25^,XhyAYk/Mǟ0J1}/̾E7 b'"Y fOtI;>͏RiUpoAzm,)~iFp soQh97;S}{t`,&kzGEv3O Apd̸q+"x5RtNo[G^tݴ(CLB7N'W?-$CM5]^dfWu6|GmaKJ1 IT+OaeUC003:|E4`dYƦwY0 X"6 d)RiZ#fx|_N'P¬elQ5{K P,v8|̃LF$2`W 4a~SMrH i3w2/\q ޙ%pcV[Jm``],Dӄc5U(o%uFS&2KJ᧱@ >x79[3l / O/&POjfQ iͺ-ˠ-)ܽ;DPfPۗB+>xon`PeM2d᠌.햡H@H%zs$a㛕ʠF; ;H^3! _A~\|V./hվ"Q{u7IDAT9t;0<(#*7]1} tfѷ]!AYqvc&w8|OpX[8'Re; fȥ `?(iQ&N_R2 T^N`/Q~x&Y G,W6e ]AlKZZ8={k&;_mZE%~1w-/)r lbx7xfmpq5ێ 27 ͟'@ѓoFSm 7WGգ6{[N{9m]}^(6E0Vi/pc켒 ߌoa4}WePjTx.g&0oJ{2e WmݳPu?Wlp}U9MQ(:ss".#) ; vn2͂n;S>g/YCc7zR,c_Zߐ|ՑgX_I|\2r|zf6nZTт!294 28Vt|^-!ya9T0 n-@iű (UFѳ 4?9UֹٵOq D[f 6-)E3> ͎{[ ,xJeRMVmOq2h&2XC` e0,}g$k5$z~x =F yN?OgM #{`GfuZl}v=0LHGhN7zCRPfpVpFv+CNFjZAXP6V0!rgTA&TWvPФ` ̀WePy(|&qIH|cf]N|vmɮ0r$g =)4#97R`mCJE`jHؼ3}.F xHBEݾ(f&גfshnf@}K߄MKG}2OPPTs(ժ]~qX!R9tM"5PZīmOUWtL~w&!i7ۚG),sgj,~z2ՎjWLsXjԓnn-N\dBGxsgcDJm Fgѕ,o~%d\;2HK 1\p:Կ~ G)Yț'smw ÏlX !Ʌ&\O`r!>!Ʌ&\O`r!>!Ʌ&\O`r!>!Ʌ&\O`r!>!Ʌ&\O`r!>!Ʌ&\O`r!>!Ʌ&\O`r!>!Ʌ&\O`r!>!ɅA|J V![nU V![n&Ui+IENDB`}DyK _Ref413593367}DyK _Ref413677066}DyK _Ref413677452}DyK _Ref413681462}DyK _Ref412711267}DyK _Ref413745376}DyK _Ref413745425}DyK _Ref413745485}DyK _Ref413745531}DyK _Ref413745643}DyK _Ref416274068}DyK _Ref417128795}DyK _Ref417128833}DyK _Ref417128880}DyK _Ref417128927}DyK _Ref413750547}DyK _Ref413750710}DyK _Ref413759196?Dd-2 j ( c FA("Drawn\blobeq.gif'bC>VHɉ !B>Un>WgE/Gp$VHɉ !BPNG  IHDRbKGD#2 IDATxy|UUf_ $@dQh!P\QD80 (~) 0| 0%H"!$doHg$TWu?Әʂe*{uӧr=r@ xPt%A@(QD!B> | A tqEYkLoE\7]4-'(7K-[2 IX= K'(7bD>MH! A ܥ.B=݂atK;40k?V:yH%Q@Ʃ A=݈-3%3wy.ɐIض|H!}笋$2p<$vœznDogkyɐILVy!w 3׵]!9zi-_v4 MrnE4?7} 'ɿtQEf=Ӎ],(Oi'\{%/\{KBɤ\nD"7  }7w&;r5p[mU~Ōs2?㋵-I7,~R };2)z aE>^N:Ӱ&y7e^!"R˰ oSz 1Ez?ɎrMH ў!LdM+It{[@11ԛ@e/{oO74ob{0}P(r9Er?pu!٩:aKηM QŲjp|{ yx9,oOJdH$ TG|.,##dckR1"EW*IB219߿>9 'ϋJwLT1]THBTt޼ӡΗ~y:Y]'ݿ-P*d_~aG| R ]ڳ2O _ѯ`R8,RbV(_S}Uu @ƒ5VX+VɪwY͙3.5"DD!`"[奵^D' R/e^j)?լ!n̚.*%C&bܕK;oD;̝tS74S)bʤQ#c˕d1dF%S.+2l> JOl$RIuUBlhPOxyMz /'Wɛ}QsA@5GE&QY5BX/Yl e(etzzn,oMdƽ>l $.$="9q}2l׹&Ȳ }56Q\yOGo9#} 2wu{0;mK0ZzaܬWx  I2Q!*# H,`.3tLG }wMaxM:bQQERd8yj.uzE]iG b>22(vELs!<5otcFJnѐgI$$cߊʈB(Fqp)| Dc7deVtLCLB]IULݢqꀘ Ym?iqӶ|;pYW\:[rF Ž*]q˖ZVmT^x`g~bZLGMOHDXbZgJ>ak%tsPmnم"<^uԱ}eC|mlk PI#y}5.r+y1Idșң]kėB(g +O*_1ہ9?HM7iUȳra‹ÁUY_}m^(ɶHڞ : mE>xrێ[xGjO6>;Dz1}E`ŦD!-@zru0)x"c-2;hds&r0Z\ 0>FaK.ySFa@'p|U/2N{bv[kSi\y~ڷrub A&ՊFsaFj3Eb8oX]JNPz -ܲK>&. q.hNSH9=j 5y>, ZAH#DzEUޜZh)b%rRCB.Y15FuEVV? MS "Y`uPT'(Bm[ Du))|I2tb"  "8I>YlzݍLk .OB(#/˘ʪ1^SWTU<%IsX1yhi5ͭai0aUW ktasG+G9 IKy?]v#],OܹFb]\d[`*i6ȹgFo*@u{0cA^EzӜc" -Ef 1}WWS \|"lB25þF(" -ګMabuW,BA)@OʌA3pf/LysP3Is; Z$Ȏ^c]ŧ#0*.¥gƶuQaB(cKiF4q뾝v%o:׀,gnzZ0cyuޜ;X{E`ѕ-'8^~[šk4U<@d;Z ZCB3(q=3s=vA4_Jk&ܙ5<< GLfXY@YnQqlb-p>`3k29:7-i0o[:d@Fm{rяs<^-z=;o蟗Ī.U)..jԯƪٔ}v5ia x}/q*l8qzb9}TXSUQ'ah1+64u6J&2UL!\|/v*Y\q6><|KgswQTiW}+NҝA]QDGT]9_3 ]<|8# Q I$IH':]]GU?G${Jz]( p &oai *tuZv;VM(iuWH4o dH| 'C^mzD"9[L>73+Öj۲J-*ßyڷĊ3^Or +󪁦OS(?1Fn5Q1HZMQTA >-yk |[캾 609 {-kE#ѫw/}66׍Y[Ofg6L} h:+>`ٞQ9%zoe-Or;_,ڨ~]~|ڮ/ U/{g`@PYp`%#9ޔб/{oQ* "J<LF)8Hb?_RX|/p,-o6` obl#i_GuϚ>Z?J [T=3i̩e/CTgG{kω*j<Yt֎>g 8-ҡzc%{ @Kn\ ftod0ix cl|(\ s_\Xܴq=#CLD "O*̸q}~[MW7Շ4$ox2(0lB4GIcN ҂HqbA hfm9TkRW-@K,[lXRVSWDh0&KR '9$~l1N$_u$i-4b~*umw\~oϻl80q:+I8J̪^V09\OspM;`G;My͹>FaM~DF&&tZµp{wiX GT | %M N$txVG;\nCqв~f)!DIDATkZ[-|+d'1CKE\=8$bw3!b=d 0ϧ97Sk%exeOӤ:#,41:ϵh>wSZx#[=cQMj4iΏ5dkޘ+ic(=mi'/֜G4;i13䡣]uO5lI$ܥ[" I);}`kzl ֕e8o2a6WU'C稍 z: J!5HO=aahxš;<XC !Ψ(F'|k )XGBQL_ E+}!A;ErhۭiRPb]nA-$3Ϯ s D`smq*#CZR=O[ݗd(|Dzꘒsڮ+, YUs NjL[!2*W JEj6#a7 KPJ $M?1w0P]~D&>dP;I9]ߣ]N|E1/༳*3Qߢu3ߌ̐"-\Td8ƚ'$<6oP].0=g%C-]:l=CcIMΛ"`'"ljvxמզu1U:[h~SkSFCG_ IOX?jpsyշi! Xw^n٢P4q^oL0M3-+V.^īby8Ι\7X JݲPT&k`E݈R-]=å^t4j] ]1HҕylD,w< Pi(rQ=@QQihD,U5y3 [г2 dzqUP+b$Wg pZJA](W̹N WB#9$ͮi z3EoAuj*bSAS$E|ޕGQ駺NWҝ!a rIPPdF`\qf炮]uWz( w1AI!C.sӝN]]G $Iï{6 6 zE5+» HxĎy";f}ϏKOr~wP4MzZ itEW`NȺ@Uڌ-8IІwбML0 D 鈳4C-6FLS- hb^8ds^(&;'՗ UtbJ6nu rVa%x6 ;):8H%6ZR 8l5%R΅pS&f%)|lid'2oh2qXq⽿Op3d.-MU:WY{ A@Lnn_i9@I)aW *J!72E9K]#`xQb8otI;5ݱQMR6h!~U!O<)x9M%&Gb䏃AdPѱ>˨ԛ+P(*APH`Nwajb~ZS6= a~H.񙛗]WCj:zH%KWb#6RaNkF@ރno֞V>/a=`iF S"6^ZM N[.l8EpBMߥuRdJlYĂJV"0$k پ rnڲXo6܌NnՌG ѩ"^z\1a\ 9 ѻ!?Tf#)U{xI6xz@ǁ(\*>)ɰ# +Ӳ\#i}k98&`GLa|&_FvLI6*W VZz^:Cm!+KC& ^J{l*(_L$@.R/օh {V8|y-IM] G= `[* gn5y[hֵ ݦJʀNmqF\l@SL;|j 8E߲zB"&*WC#p܂W7QPlf+$vnm~F;-ȬϕSBz {w\B)Y6\!^QR"wI5'nEQ$wh#-m*3zдVl,XR _ FY5rJn/!f91|sb+gm#5(Y3t> D˫Ԍk(FЉ&L" U bCaȸq&\- tԘG뚱u6̯*i?9HִWmNYToA]ign8YS222vFqGg۽#]?Uʒե}nABJOK_h1SAbKgA]CH0tZbǝ!k]x.ELM?Xz 3aΕTLH]!O-J~;p.R6avYڝؼk5SBg.#hn頱?x EUd}jwд?U6[I+oe6'!>{ig# W#R9Ϛ-^7lXs\͜kDXz?ۀ箼ĺ.0uyCFڍ)se?z)+565 KՁzchK)ׇ;Z?*KƓ7Alx_?[>hj}A^!w'mz8Hvqϋf`rf9^!OJ.H|Q0s-`,E S^ɁZR/aڳ]ԉvQ=Ā?"&Sr܁6~A KQI{4e=L\iX]tՑfE/-fS 6ȈG^2p>v*\UÃA") ~B6S{Go)zC`DC^s˦W5C7HG0+hÒxv[ߞ~|}kv?mmȾbLh8`,'t0H_wOQds?>.DW%qOb#j]'#w1g8A%w?*[%(xR抧];AiВH ulL9,Ӥ|7`/cl@ĸNU }?ENA@DS azńGk-3dpfld:RȌHT#XgSCOnSm}-Yb HLq1\:Z ߑvK7r1JňD8]mn& Eb:<]?$%_Z=p8,fvٴ"fQ?f8ˊA_ Sغ5AҨ;s ]OSHO-hVeD bˆZFЫfxe5ȶ𩷶FPiڎ:)Kml&r6kdhYk/{RnT .\NjW; % `L|a΋ ,Tl8SqOȭ Yuzy'VM5MZ^?xqW2`Ձ3:RwqZXWcE?"m6;} \/V{R&Njދ>IOKz".3!؍5u%`P`.%FS:cEJ=ʍDmۚA`˯a.zRͲmlfdd[[bΦwQOҲjx&ial\Vnh+ZXo+fQ *YL 2Ë(>VrM i:!ԅB'JvdjHM'D"{W Ck[lI9ȭw~T8qYAD%"S$-0'b‰Zwx鐤,"ko`;V@Y:9vd5)\"A({P1 HH᬴ҼH1BJyD=J2eL%?koӍ L0S)!To 0͎1o8h[D~xGPXC"\Jy=\\)9\·0<=4{Ҧ 7t8&Q(H!ՎvQ \z|Vݢ=AD%&$bcd|wz.!·RMS7&oMFhMYqHY3ӇID=mEJٜp>fQK*Vvwʗz:x}E$PUI~O43p9H7.aRuҪCxu$ƨ]fc*C1}H~P;4 ":#e2=[$:H/ֲ WBDeHAR'9#6O/ 9q6wד@fWK}$k ![tѠ3ĔiŌrqRN^`R{Re.8_^ !MOo^?&:9DT t̜ G"FkhEaŲ`58YQPҴa1kma #qb[8Nߣ=|??BcnefQ(G33tf6á`\^㔽ZnoPt;}WWԺ |8`G.y(fWjPk-Dz+(-GmmRT#zÍ3.wnˢSFjj&Jj aLKr[o}a05h<4aT \uӓ0 fs/=y7? ] ^tG]hj4[C@yasi[]!ؔoXP;Nq*_@Q*Ͳ(̽mM%+G4*s["W*9$ 0s/2sVBO=ˆ/}(`iiL. 8eyɤJmջ691nٌ[-wk>^nY<g'W0# vw~XIKDr,WQp5DL.TϮ5&7I>,[Q1"_[ g%ȼ,MrfU( X)[UT!$ vƀ_7dP]F&V`3eb։=ҞV*|_χVȮ #M1+fAB­]I~Lvu7&.DhE!y' tHZߊM]N4B0lN/KRu) 袚a+G{fzV2rӽ3GR]ӽ 3K&&_2ғgAĶʰJlJAO>y?b'E`.*8M>>LPRcҩ;W8VZRޯye~/1-8KhKi1yMUrׂn5Ɍٯ_ WA[0c2!tUdL$1qsFqIro6dͅIr5/e;F-b[@L5J^Wij6+{YlC&̫Td7uDud\liW{[*Vl/\fܞbY+¶fei{uA91yֹ_[϶.MUаEWXbƾ3mܙ#&DOSlH_icU'oר[,*QZ"&O[" Q)m۝6c'=bm0?!&ǒA9%1y$0nv )&b\g1yIc{r}Գov%tgAْt*p۩T:-=}#,KN9ْt*7r1~qܘ\͖NN1,i4vnj)UXRvĘΖN's:[opJ>ZL̖TbEg`+&'SN G/%hgKĴ-Iljiْ1-6[z!iْ15.K #oOcZrsSsZAkVYcT]1\;q#T ZGOZQ@@:BL|ǡeALŠ1%@LҊ1$bR!&TI"&bI$bR!&TI"&bI$&*$o( &iŘ|<8$bR!&TI"&bI$bR!&TI"&bZ)Z *$ 1IĤBL1DL*$ 1IĤBL1DL*$KLҚy$qԀ 1IĤBL1DL*$ 1IĤBL1DL*$bV|9%["@L/DL*$ 1IĤBL1DL*$ 1IĤBL1bL9pbxmN$P!&TI"&bI$bR!&TI"&bI$΂BLORϤ@L#&TI"&bI$bR!&TI"&bI$bR!&iŘ|F1I@$P!&TI"&bI$bR!&TI"&bI$*$II!&zUI"&bI$bR!&TI"&bI$bR!&TIZs~['$NBLG DL*$ 1IĤBL1DL*$ 1IĤBLo(P!&iŗSbϤ@L#&TI"&bI$bR!&TI"&bI$bR!&iŘn|F1I@$P!&TI"&bI$bR!&TI"&bI$PBLO|bxW$bR!&TI"&bI$bR!&TI"&bIcʋ~zI9b8j@$bR!&TI"&bI$bR!&TI"&b8 1I+ =bI$bR!&TI"&bI$bR!&TI"&bV隮CLo(P!&TI"&bI$bR!&TI"&bI$bR!& 1IBL/DL*$ 1IĤ^L1I-e[n,ĻǍn~5B=NE?n4_:jxpc1㱇3^=68TLaf=ǝX=nn,}xSM<|OmoUCT+5t LpKNJKĔ_eV,,ĴcR!&?0EX:*1JTE&|Z8<4anN>,0 OY4&,6`}Lelc)-She{LͲlIZ0&lIsLvYxx4܋bjwqLE`bߗzz1[Keb*֚-I;$iْDL[[ F/ikcZw$\ǴlI_L/6-v{}|1eϖt;lIrӦR\N1[ŴN`O1pYN;ͶNp(G1m,{):T;it@ELvYj$'Ԍwq1mMӆ#Ĵ5eL[ϖ$bښ.= 鶟_F41iY-v,ǔ^N:[fǴْaLedΖ1mY霯7/-Kv1,fŴْULy7#v'nfOs<ӶSNz΄_clI"wĴbRǭ1U{/1yY׎) .t2Tq$S3[pdk_ǔ]Le^5g˘:[V.KF#y{Y׋y%ei71x$Sr·~鋘v7X)1,K5C}YHL[|$&cw?[ik15#ϖEc*Um}LyX2[`ow1ab7te^0'_!fKB1tْLLZ:/cc=qS~Ol\fe󗱉5~rk1q'n$&I 2Ζ$uLUKl"C/K>&վpr 1s$)c /п1e9r.y{.&,s$bYژ#u:TuBY(Lt𝸁˘.)~w5~,Kۘ07ǣa_Rr{s')}j)`dyrL;pv x.jpX5R G 6o888l8i t !&8CLp 1b3g !&8CLpf{AL)ezjBb1.ucхx]Ler^kQzpMG햷5wAY|&~4M'6撇9O;?qb"&_t5Ǘ{%1a چ_p?Eleqtƕ 1yj4' 7gSz+Tto wU{!_)dѵ7U"&_TeSEoU5?ὕB.?e0[SŌ~1j,lxjJkݵ(OQ_v mVMEinlML)z@\.mpI #v1c?|5SHnMd»]dck"m}L1ӕrd516S'~2bCL'37||>;bza !EwV$UV40݊t+nnE ӭhaM7LV40݊t+nnE ӭhaM7L[ғoT0-j9cնsϨ;o,0YնQ:R7^Y ?(em*헡&k;)(qdBȩkJ*da2i0mc0XhiQwaъZSjU.7a] 6F9A iθH9 7LI=^iO-IRFRc߁JH0XXIw4)]N0yÔ]yS#o8 DuFF?L 9ڊ?XђVQmsS.IVJZDab~;|iE&ɘ_ h3My%.=|&NlÈdjBD9^E ^@!K8^ T[@thtu`!c'D=L>`/Gj#$2~ϥ5#7LyazE GN}`r"Lp^&t}j | qю| =L/M~9&VшQ$CݸyDߦ㓹@wka ~0:έ}DwIsD/U-~T 4s஥c.wÔWfLvD!=Wb5alg SV)W[4y뺢V>>h!0ioMhn= X^dӄӅ&1eygF[l١ͻؘ=w7LY%4^ qr~,p WrcKv#DVqE}̨ǿK!Z֖֫tי֐]Dm^UjT4u_\ 9L*|M?Qo,ϟÔSO27q=Q\pMBGY wGrwVa=DMC{ˠޕC{lb7uԦ05n#NF4ݱ]}_ m}jaZ{N-R`S;GKA&^ȅM 6^7opc;6,r+3)ZU"}S2(.o@[ z9uɀ%ơuUN} VrGuhl~8VOL0.9ZuS |CpJ^ ^?%jV0ƨw_/ITne4[>HeC/U±"{'v^D&?[;l'X1B㛰AJc"75{3;X{= Fbx3&ǃf n* EN#Hşɝ,۶*0šօO0XUaUX`bHF=[6BM51a>`;W#yNaze}cЗ2)k{Lz(K7VrȎ`5payU=3rS PlLH\ Yq 9 ,-_7+老k/0 j~LGZ:zJTM&aN v)Y|0(|rLZӶ0̍QcQQ(9a꿓aқKYL,4hӡU>[[(u`0ofW)6.pۈ ́95L› 2 o0wdZif)'8~ow@a{>x6+Zvp̙nU*?#qHw0Q_8~~ Gg͘ԍ 2/6l5ݵ3Қؽ9Lֶ'16I/~:Sui$1.oi&Ns+C)1BAUkQxb[]0:23LfY.ԪjIuݨ1ɍt_  ?_r~Eߡ79WiɇzB3ˍ[pn_w%5# _P5F[-lK & 8Tr${m !hDhpN 0=b$$v(xM w`yt뇄^7HOi7(\ &8<}_ k-P`?ʾ}kek{Ͷn]\ӱ3O(~&V=/(*a}"GƖ}uW0|oUZp22Нw sIN(9`]Ϛ?S1% ĊIl^Qa0J$={aNXؼdNc*L_c,>qƖ`Rmێq! o ~~vv),M EeB]NnVCW5LޖfQ{, 1`ԄT]/i!g[' xAߵ0H:](L!@{/ ~<W~3]o|ښ[L"RD/NTIa. SG̘Z}jL_d~GC`àL]jb% [3^jVR^vNݩGfbS}Opr"&Luʤ&o^n9i% .>0y} iON 4{w6 J ӦyEzrȺ{=õ l/6X]SizZ~-4 z+ B;Wsq ^FlÍm(1L%[ %L2"L o6\qhU0]=2n25L`En^TV0uX^F!j!a[rO\d͡L'xvƿ`wێT ôT^4 | aLS L SdƀzY5ϴT^3T8GvLdnS ء!Y*[2d\NRn&6gY Clf?oueXS?S4^L>ׯ[WCo{69{DW`9JVцp@ /h )#k3z. SzlLh>`u~{. Czhk lCgB[tJ݉ m?{ _wLbL/K+^Qfo0X<~;7<StNbqtqpn' U=NتSXaXׯv im0Lތ#r;S(-L&>/N-YH(+ǼL!)qkkjHKG&N(haJ:yN}s SBɴS0#Ɩ&19L8Pto)q@rpp”zH=Ha" yR G[Aل&J\$0!N'0aL)>ѫL iBٯuTn)Ju7LdƉGk(aꮼ5%V.0!~&KoҨM]Pkۺ 0FP$h́ .)ue L-1d^s2ы#L?,0ᛱb)ml0”g G G0VY`焂+9`7L)ē怩W@![Z3,$=10„?c!E eo&"jaj~&t7L yBjtc·L焂LtY>d$3|aȐ opS"#L+y`jTg( g [A L9ViμL9 ] :0 eZ&c7L* (LؼTش {:l'K}s\%f(ll0e 6'l0 Lf+wo;a~)d l0a =.d`"2 A@S#ELmq8,lkq[")Se LP)#L e WmLy.'\0nΒɴ>L-q%#LpgipL-_`*40Qd~`T(TƖ`;I-q*"T~`}NA*k &}+TUKT0Z%*pT&'T0eq@ɬ;#hO*uDw<['CBS@l?431irk3֜0! J T0UIZ .=}v#L>:@N] 0μ$L2ŏUL0؆j=wLJoO/7~&|UKMs„rw&ekZUDRC{DxQj[z 3 hj\;*&Ipv|xaJ_u)lfk&qWy4#o?yp+y.)%DzU~&4+0J*WZixmLK*XI*LHcq{ܿ:Ԯ`E[ U2֏r~;Fhߊ-|nU}讫lxZ;D$@4U$)hiyy7xӟPq@'l6LeCu$Xl;4>yu,2a'/50ai0};̹[+/ anOf"k3V2!iMY@cj-{?G\oX{`6mKך_w? 찡^TMW׸a*_h:eu@Q#Z)&3LX&h`7L L"g@f S\e=/3LIm4La±}LMϟ yF5c{J<ӏt^$Lӻz8`,dQ'!٘slNv<&cLNʚJV Xݲ{ur&VԐ$ iHSo휼6'"E$0y6jsad %Q"oEE@6&)DYV_lzi-r̟if*#LoǸzLEaGpz$00l}$z=mD h6b-wtL!ϺVƖEi Wrib륇k2 tLZPٟ_~s\a}M0-Evn;؏^4{dw0v.!2E&p:{abk; CnEy|"  i &ܫ3g :\D5Z9a=$*X0ïoy/8+ 9d?&$2 Ei&7<hY"'o6vVq QԮaL1Fm)wz0z{8 7ǚby+S2 ɽ/Sܧ.j0޳C`oF 36?R07](&Ύy< D&ij= Sdrvn0*w۬V0 '>8{dYERaL{RaroU,[3cd`jY$'lnk n}d)deK̗vXn!O0zb#'Xn=y`;cG 4'jx3>.7!Kk_ $7 ŀuM!7mj>d^ieSw佅{DU3я &7_eQM٬I?8* KَU_OxO[Mh~so4M]{7ْn ^L,0/Ufa8 0t!ĝXxzvMNN1ƈλaWmm[F}d;3B˔e<~߮0YDU=ttgx>3ٌ0ەibW`= Cks"b&|}341qN,A~JHam`GE+B)+KYars*0Y#ﺠv X-aH!nԼ, Mhjd:!zHjAQ]Ͼ2302gꍼIՖ&ί}_ qT\4.)kaY_]*7LN*Wge}%ȷi(O,eOm^8m]G==^TKarsW4(\Kv\TuUF-azhᰴC;#j^L/7T`)OZɾkcmɔR096 |Ѫ - C` vm=ȟ6PM=,9 ~lRw3vV%*M )2p G bMУgPa*b`ڠ-L*_/(O,&G>&+pLQzGU|#X*iZLOՎh8_6(3+XY,'$_v)a_3.&UQ09it1H2Fw~&c09!(C)]k{C=jKc4 unq2V$Im}}sztNV0M<dE[.ad%T Qr@aS|QPx HQ(KE߅q5ORZW\E9 tSzft1?PȏJrTZ.qhDS5e* >[/?,'P,o2"S N8TF0S]dNVInT[-z05<:Fe!J_\ %~;.?ZztDC(W?͒%b]{+Geǖۏ8+ QK+qn zP#2a[K K!7pJiuSU츯$x).q&:IqPNǜy| ?wx`HX}mlUskrW5NYցX$\R0S^5oGi"Cqt@Pxv!x}r4*ѠT0L]Y4ū8j⪋  rk|PK jHEċ.(AV-6uщ$ē.Cn>nB40yv߬@0QB^;z[A& q5 *e؃J}I*N8b;8 ӧѹq:=lEbkl62QڝnɊz#JinC;b6e>*qaXzb7z-kZI,hɷWmY?:`W=$Ǒh8/Ipp+zPVrQ򱶓&>;riPO?U.gw*ǵq~j'g)?h&\C)o[mxM(´ X wk4dgr8f,M&u DuWg1Jba5֧qOة?MG~ښĶN`N0֏u->7q1{*&A=w_rfP~cxF,ፆ\rJ{|b\h#Ię1vw% !{6;ӮPrҝA>RJ=/z-Yߑ򤮛w) |B4 /(؝M$],CT*,*P0YJ?!o}P9tY^QZHQ;-?U y[~#~6S(NXkXV@0 c#e/;Һ5д*RQV5m t;z_v(g0qo>*kR!keނaŘ+fEq+=\HAsv/`jY 6V!'L=S0ƹt-m>l'a*ti&PWɔ&]WTML8HsJ kH @SW Q dL^otue|ܥ"kF@rqjJp'r+m'!>V("@2as@̡Ÿ?7`ٮ) >VfT''Ս:e5pD?VuKXLu]' noq0y-'WZN \bVrJKZ ,L^NJ1@\ fJ<< 馋x)6Laj gaZK+P_lS7LV40݊t+nnE ӭhaM7LV40݊t+nnE ӭhaM7LV40݊t+nnE?6 IENDB`DdLt" n + c JA+&Drawn\CYLINDER.GIF*b^]Y>9m1n8}ΐ]pQ^]Y>9PNG  IHDRL`sBITO0PLTE"""333DDDUUUfffwww{ bKGDHIDATx흉:E@!7Wmb~k*+Y\`ByL ؀L ؀L ؀L ؀L ؀L ؀L ؀L ؀L ؀L ؀L ؀L ؀L ؀L ؀L ؀L ؀L ؀L ؀L ؀L ؀L ؀LS:6~ fjQRU/)}Qu{Ab&ޥo)xj/g3<_ֺ|Lεu]8>3 |(kd֦(OX)]3\^U֢{o)6%F +1ݩ59uk^2om.b U!,SpY$>̌޻y2*;K9L)8h 1sn8Lbnvi R yr@|rHjEH*dW&1OO8L%7TZxn:Axzad ^6n'&X RV-n){S8@8LAO]u7<dT"HNܑ)T}/MRx_5͝g^e uR_b!/?s2uRC}DFG]#pSߕs~\|puh1Raquu`oEUz!:)Aؔ@yut85PiNMzjĵtvj4aWt*&#UДecڧ%VBfkkUِGGoKWRe7|m"i+ x^lf;ʔᒍqTgh2TRtM.I#u)}![-}mTU''R?Do~ehWږ.nLNn]E _mB"MILBJdg$=.)_3elWT QLaWlNX;Dr($B]c/b){LY>[ WHQle\;ͼٜhWFIAXr2DzDڿ&S3K ΗL6HR5 kBۄms4Y*չFL&' rogfROe!ʑHu8,=)hWdrd2?/S8x?4L{sZfRMuexpj72wtׅk"2-oPk{oZ)5饚m4BUuLC"u3"yukl-SA`4w*Ůr,hShZr6)Fkrm((%\5(PCUu:47 ufHe)T=!N1W}5F]L(`a~Z&oYͻ56U wʹAh1 _5ʔ;H53FK:+6}`SBM.=i;ɴzPq-l4ߝ&pjAM'>G&Q>CϏg]J_1r[(}sV޿tO`PrHSZrqirU0)*UAOZfd|_KMk^.2iz_sp/hetd4P~7m_ ms;+|3{V`qx6$9m1׬vbL:k7?(g6_\LMk2$"MS 2umue $kZ9T"Vܨe={LrXqqCڤw)$StGXM=([L3"Eospv)66޵یkm nd629dڱ<ն6 f!T@=S:yټ/\ XFdڷ7M[L+Xh)iQ4AHSHȴ+Ԉr iokߚY`L˔gmV 2dd"3LGCnm|qt3d:Lkvk<o϶L)򞸚cQL29U٦SdyK)Lǔyqi>[C͋/:2W %}{eer*2GZ=\|E$2^&"xCMPBVƾ;ۖw^RB))yH-cl]Ѷ,7ƚ)kdK}Ej5H]2Duu]k T \\vXV!̻ ug^B'{T^WbUO^.hA`WL,H)0.h? Ǽ!ڧ N!Ӕk2OL ؀L tz<2]V# db2A&6 db2A&6 db2A&6 db2A&6 db2^&Ŧtv62A&6 db2A&6 db2A&6 db2A&6 db2]nd:LdLl@&dLl@&dLl@&dLl@&d:Luѝ e؀L ؀L ؀L ؀L tz6tv7% ؀L ؀L ؀L ؀L tzN2mdLl@&dLl@&dLl@&dLl@&d:Lou'tv7% ؀L ؀L ؀L ؀L tzѝ e؀L ؀L `3&^.l<6 l2AO%$2q,S-؄L\0Cdv]ٝeFN. NG]e}90v97/X&m$%V4.< M3Q Q6&Y:g@&.T%c t)DiUȤ?VeIG 2qX&ɝI䄨SqI2E%j:8HC&.$bxgTz'2Q!U -S)՜?"S5RLIAL\,O';,g9SR0(e d~W|,Lc =BIu̶W#e$RVt *x@&.*ƑLIdOK2я]JBqtvfd 1׎6|u}R32m}UXoXu4\C]L?#Sз_Dd%y2پ-2pP{-dLMj3Ȕ⏲S-+Ih;z*y e:F oKh@&.)$+P+ݺ)>h# Uyat:? L[lJ51]-)p)Kj3pGҘzJ db.Ka鯎c3w{z!L\dJU_z@&.&2͚)U&jԭ;- JTӑw 2Kri>e2A7n]LM2 w d:L*BN/:}s\L w 2A7.) W Te@&"år dz x dL/ dzj.2L2]&Vŷ!dZNTO߆Li9K 2-Ɗ 2-% <2ALi!d@mL!dZ{etz<˝܂mu e[PA dZD3Y! 2- %B&ȴzNݐ 2=E܁v5 dzFG ~eXЏ 3g?2=KCþӂ!dzBjq-͹&΀L`J\HoՊ%m2}OQMdg>2At(.A&.K]L1AF4]L1)eU%[dE¢6j$E ӏZ=I 8Qn.d!mL~e͘t&]J(ӆqd:L} xH)}j݂1Kt* d:Lΐ|xIwkk!e VH$K#Y./*@sn$1:gLݦs˔d*g64>-;|Is')gΙ/i hMUE$ߐp Qi/krT7C2Lo5%8x Gfd%ИSħt;@_)?έ /ʴ2e3(LgiC db2A&6 db2A&6 db2A&6 db2A&6 esާ@˄ L\@&dLl@&dLl@&dLl@&dLl@t6[L2^L ؀L ؀L ؀L ؀LYr2onK  2  2  2  2 2[)nN.ӆ,)HѬN.jx<2qL&LRTwz^oŁdj̽Z!VD8LkxE@x0>zKG%P} ej*!?@áh[a\::BMlvzGj: WB&.Ԉ"x)zloəMJT]BIb?,ֶ9׶GN5pǔ5Ye*A&!3CXOXeR/Tbʤd&)ei ԆV^Sp{Y(~$GdK2JcL.%NҖo| \eʞL" dZe4K5Q,@Y u욀.\#_"BuW[JTʗq/r6kȩoY/-Jiv)Td(^eRm뾖os !5h2}Lv'xQ.L%*ݿ0 : 11=~x7wOo2^67f1Lq4t+OgVowmqm"Dbz9#Z:*qV(IUQxy+Ql]WٕSB4=SzQޡqoI2yRizi2TJz26zC']45BK}۬[\c7tTrI 2 yU^".87atl{S:x$8L&BU8I X2[@^6HR'SI$xؿZr;Z1t4B֖-\泉2M {oL;`!d0gJkwm d:L̬"Mx J71dLCSHW !dzĆ]jFɅL2L4VIhG[ ɩ5mpmרz622-S K`)ZM-`nt>AeJ1xd PK0ȴL)am{&z*ȴLpMRne( c ѷyz<ȴw~Pbhrˤj"H7#8/Nit]'殫|l_JC%,d:Lm;5?4صJI0w өeWsP7RHhw'tBaBej+U%Ӽ*}ԩcnVIv}Ч\]W%AR|L$Woa3?o1L."xVd:odg2KQ]#) ],d:LAdƏ(T/zAdZ}{'![֦2}dj֯ݗIkK+_23#_[;VU2 -Mw1"S>d^[j6 }]dJkYunQtvx뇦ɢlSh?:ȔWETXMvtqy`-=۲LE'Z=:Ԉ-Idә>~BK&*v˅AMd<ǟs4H tB\Q玷.]S헷.*M8{Vw#a)wzl 7>F LrʛE@&v)Od²LژD:mytdI.~2џtfEד8&y%"ǑjN14hJ7]8LZ4+3хQ8L g$|Ϊ߮x2ݞ)ǭ&.eP%&ڽrR'qO&?%-.l;qet90ذeh3fir.ӥ,yZw'9Hl2D_F˲&*uypDTВ8QU9pZmU,搭\_TѶFL4>3*:%_I)ݶ[iu)9q3nrX5]K_F7ZzhkՏ)Ng: |LBOk 0[26 `26 `26 `26 `26 `26 `26 `26 `26 `26 `26 `26 `26 `26 `26 `26 `26 `26 `26 `26 `26 `b$.u8.IENDB`\Dd j , c FA,"Drawn\HFIELD.GIF+b*\~ʐf|-ɡ\,Pn[br#<,k:f~ʐf|-ɡPNG  IHDRI=0sBITO0PLTE"""333DDDUUUfffwww{ bKGDH IDATxׂ( ^oILrbLؘ !h.yue#G/Ə(_Q?|1~Db#G/Ə(_Q?|1~Db#G/Ə(_Q?|1~Db#G/Ə(_Q?|1~Db#GOzk é_a9*CϧEv/#_Qb={h{i1:v_9Xtm/ڶ_lm[};/JZZEs0·|W[_vh!j{׵=nqk|wc0:c{<:С/v` 톩݈EapoqO5c |{hN[)a<@m=\c*;Ì1-]=lw',⶜?#Qܺt@lNBZ݇ej 6֑}7c wU5.˧`$t:!7S"}M\Nu zDb+._ FM`;lG]ɢg`B_dQOmPThή(Ņ#kHLxo=>ic ӤRYݕY4n}5@a{:^[C%(k!\tW l.ۉy7_]1.&zl*R,HU)ԜNB͉b`u%4gl%!q{I~-f\ vOJ1mj7@YD:5]2v*کk>"Ć _8a` v/Aqho@YDTUJenûDȉ: (| *ycW \QZc_kvh빂e뺬b:("x6+L"I8j|N8vMө7Rh"bYjMm;tO:TtON"2O훳t>0Dw8mp;=Uj/,m;Ծq3O$BQlJZ ,Zd3ם1nd_ЩUH0ZItOG-_JlIuHCw7qD{^Rr9AJ"EML3U\&BިmEKkoU7+>U"=`ۤo<< ٸU\9~1pg;+Y"4-lFWMCcsuƱ7[m&MmeF'-y#ZyL0g$ vz1M;W*Lq=&A7$s;cn=J~,<%i_Cg7b TKl]港NI$cw%*NI1hV@0{V2n2HƭRκ9"I_~5bW34GY76+z gwnҸWY8Lz[=U}ˠާ翕\f #\eQZ^lL# nopmHsZ'$"Z5F@!iUOۇy -&an<]ܨo_Tʭ"ԪmՂ& 8PTc8(bkBQb\N3w4=nEtǑqlCUmN#j]auyJvf Y{Hqַߓ;ҒIoBgob<\z쓳6QEqF*^5lǪ${J] yԀŠkXvX[76U'nEWTBrieojPSō8J.|SR/v3k56Vtr}Zpʍs9Yk=O\ݽ 7! FE8Q?իrYtwsLd?p'b$E؍ve q1-EN=.WuY b,D7TNȄK6s]Kf&b3Iml0}0:duYL vtJBdD"B[uxx$ lRH=VkIg i4{dlkPJD3/V绉.;Ʃiq~œvw$c/ږr[֒]B>SB#',S/cs\C;_F O8$e}O׌l!dyZUMHGXz1|>6xvqEfGjWc8FkҚ3^LX}$~|Ƈݯ|7N(C"DKdC2X#ڪZPm-uB£Z3q䮻1DQgYڜ\CDe)'K<2:&tBxEWm_;}7c|,Y)Gp1v*`OZ[4‘I`;nѷx|ipgs E> MCt↷{ȯ2{D`\[5׸߿83uڙIrAZ_+f" P 9,C3٪k=" !xQ$ ,LjgG7b=H%!=0۪0]=/K _4BaW["wHաyƹMUe "4lq#\+v*8满KA 4A#3`4w&,EyEe*FS@5 'P-Z7pBG hՠ8zc1i(iVUO% na;p:lEL Xc8?-{C="G5-5ۈ>eF4vS@+}%36岆hZ2[qҚF% 'I;G; xO<9g%z> ]#* 9~!jkdh˾\sA)&+UL0{yn.ͲhsƩ\O~TJdJi//ި/ FXםz3n_#_uNMeФ<7dQsj9+zug/e++تI}zDa}1KӇT7"m9n#Q QQ+!0GUKep%G?3KM<\U0WGݓKL嘛p-GX $v4G)Ch#tVJ7*(u=OV-12"ikWt'v*8Ry꿎Q} o/u[Jzt1'92xct*Mp2*c92)V& [:Y_.Y^ST#Q㞙\ O,! 4=G FbbeMy;YH˟J?AwK*V@3o`ϙ~DU h0ާQJehW(/7fM5F/U^q'Աħen  ^3 `30)5qi{ ;v><0D hU-]t*Y7T rhU02be5?ï)M $("T[l"Eͩխbdl,Q:!z9ɗos3㽲HZ,!Er;e8jD#,ugUgK!W'tfD xwy%v&ýŕA1Ǡ@VT/;K:Ǐ(pWo!{@ xȵѓȴq-U wRNF3TQۯ!׿x^v QӨSȨ`/- @[-8B^< [UnXE @ԗHvz/1 4D1Y;565ewC(n:JZ?艀~\&Cl;}RfkgL1BGdLxҴ w5<$Q|pѻZW6x0e<]m#\w.iv;Jߍ3 i#Xw -ƻ8p՞RxЊϚ:;ӫe4Os;w=ՙ¾=O1>*-V~3Zu[E؆1?S*FqۯbR=U#xئfOj,k4̌oǬɵ@z7_-bthڣ,VMaޣ08]U` hyh R5)m;PEy~Q?,1QncqQT""J&&lΕOg.'亇JkNgUqRWgEf(*{]٪CM&kGyO#fgY.4nDWWf?7EQ \9f6[`&bS(3yr/b7 фNQm+ȢЀAD *D,ȣ&r~T,a֏F3DO[r 0>K7>Nmt{n.`ӜR2G|ԂY8َc@yXKL5;o0>K?-u#ipZ.2Z+V|GSEE<1{ࠏ*N:/0>'+3KCE^ޕϙȚզz'SM±Q~TV|BZqQ9 үI2k`*ĩovy<@:2G Z5;'.A_./Q~ Ҩ,`iUxI wR585 +\QXu+:1>+#gEy~0ԯ2 S8ʕ)k괭_Ђ۩yZl2$,䇯pӍvP6D qM}ӟqF9Քb;]ѩyK*RF=Qtvw9H)3^zM>qU'awh&xs)׸ĝTjgTk۵vBvk3M'?^kUнJy5n4E;DL6!g V<zX{ׅᕽUP$;f]߼/~vbC)hϸc=clM Y7C۪YuQOUi&yj?~^PLH⠘2=w"lL KaqQ)IbDڪXtg0Q܈qY />j:/oOMbEd&lќSI{SY >ʼԔZS, fff 'V۪1b>f^R1DW1}4v{cjQdxs+SʀM13c㋌< 0rÏ:1.([CKQjOxo|f~1:_ _0 *p[;cʄc+1\pP:6T1BWALʵLM|p!H`oآOcO2ZaGCWٿ\U|(*xᝪKIuHlU8"}N}u+I` cz`/: 7}w:-զ <|T@Uf b誄< Etycd10F0F?EO2屫eaav7 P*Z6W/Fjwgjdj 5/SƱeW Mg QTXɏ0V[G0rnodʬmKaS8l* !<$ڌ"Fh7W׊)1[nt΃b="sBiB$E?NUXGl+}1Nz9/`9?Nh5~J;sގU3ȫf)pFD+c~߷Řpc_c`f vn75.K8kw  1 P'+:F=F=T^p ްQzE:=m12~$$å{ƅG;+oY?NwPc!mPho1Qͦ!j'tF&^.=ao/F~>Lotd1*X.w#,}/PS=F%=bUГa|xK-̮b#SQJR.5Xlc`Psk[&uR0y;ka*e I89hky2f*?Ni{Pdijڼnvɻ`v&ij8A6bP%C(s5gx, Xˆ$HϔXMFbVLs^FngLE]@o'uT[?N ѿч9--ב#/)HzSĺOMj4ozC#˷Z8oQ&ng脕ǯ̲xn v_vT&9OY.T.7c`jbnp#&/#/uXd0ce]v;w3]ptq CyJX齠oQ 5{Kth2HӖgC$st5vV1_~:V ]1 Z8Q[F["!߇)C=(tg##, oRץs)Э>w([^짮\&zTJGWDZY@zV*87[8JTja@ j8X]& c?`W.RܮeWzGfQVJMm$J4`=%>d}?6Nɵ6ܸJuy[Ա-0HUFU)@|qnU<*WRɦin)F=(Us-$1: onudt6p$gorӻ=Fӛ}8Q!ð P܄Q 7nSYS&j37Ԑc{7@N` 2bz[qxb4",rJާ csPnܦ>w8挼ߜv7p0gB0&}S-lVM6=zc# $ßxkyGVZnQl0&Yl Ǩ@@%d i{b4g6c$nDE8i)(U6q\kX[fL++#FDo,`R-1HHnhQםt~vʋS4';/n)Fkga)KO|˘16AJx-ҩcbC3aH&iRC3vp#:[ЇłFDr9xe՜JI\néWX6Q@!?$-1^_IT;6 K K_U7wwp# ^ωhC`$Ĵa%;?o~򘻊=O_qKy?Ph4[a4ZTS,KuĈzaףW{p'KtalSqPrM2Ss1';wp#Hs7^}sHStjBcPgTr>C{jsu4S3lS* qyCBNŠ1SI\`7k©)qQ|yM8pw~WǔœRDqFlg9ܖ. Fl#C75E:v~ h~uβbPvﵶp1OMWp~ Ra9IJpL%dL7OO75;Z2g?4ǚY1g?Awj_r ryG\Cmhoۧ*n7 k&;bZ%I,Qc >7X7vO3W v#:4gOGCά%8ưJ"=S[S;.b^o|"g1v=ũڎAq[ǹˇvikqF, \V0 h#1 ұ9XLU%DN5qy-Zn{at8 g:ɔjġEvnjXHԺ盆ȥ33?p'Y^<øz=B$>g<^)՜vTMc|5sӈ?q˥9ga|AH@N9kCmcCGwC5wp OQsky$Y삑 ^Z(+Jy8Gl8&*9EѴ#ivPjlj$ՔK_?p}>2GEf+ N#ih=y6[qzI Ao0J@qW=V9c#GFѬ;]rakRG(kYN╲Tj=ͽƵ}| 8GsQy*%*]W `)3.{wbT;iZE*_q9E}w'80Taׄ 9^3s_`{_-c1((Zv[5(ͬ]OCV+GlQ\p>2'-p+0Nu,jddlK{>SXkga)TAxV% 0GI_ GehJI*qKMO!]|19Ϗw&Yy&ovlFV-eN):휾iu"7UKa}Xz=ƩvN'gZ^4#Na#|Jq15eԩkۜ<ph+R^xp~#LeO ʝq8IƸI^Bᠹ:q.8H{}ʏ9iA6Rᵱ J4U#w(?؂X5*/O h/NaB=uY;"['_iٳ%e?Rr嬭4#rcQ1;ǛI1y tj0PC{hR(*8)OgcOҏz #N͋1&Y1'a}NӼ ?q*a>Uo0CV w{hI{& 37ʫ1&BGxfya!yr!`DFKiG̏4W :ýcM`f=q1L&[bhnmԤrWT.L[P+yp^PjҦ OqY}N(m#󭘈 ǤrȈ1ǤY!$My9F~: A$V%Q_GTT}h:8mNi&kMp&ݫTc,FU_`*ܛQ@V@(*:p XQ$/̆cp^[0V}(r 5XnȎk^8cP yNsJ2]u.ѝΫ1U S# k:DMsoH:G݀1B6BIlU.ޕ'W۪4~jjm$NѮ1b( kj?rkLY0*[Y˲=ǹMYWb]٪L3I-8Y!,F0Ʃ]Ӊcieq V#>c٪ĊF!3'5R/AsmʫcPY+dʖG~_b! e1[W# dk!bwm{p"M T|J8諙ie15{S>8nxćZPkR+<5ʡЪOЩ L!ׂ1#G `i0|+1jmU1PRA#v Sշ1¸[\B*pU Jẋ"Y #I?r=G|8/h_N겸&Xsr>_b {8(s,a6LeVp^blo6Cn)6\?M7shN`PLe>?bg#dW\1 q]T\Z gDfd |c45qtX% F)(q`=6J #z>$hR 2jkngG̛fV0C89Zb0z #zOox6kYG8'Y{|c=88d_z yh@6/'s6vU = Q Aw={ gSĸ;0 6QT\@dYOU|*=:*)Ʉ]I>xcAvKE*+V./ĈǎRYԶYJ)F?-RE' R`H[_9M28)ւp*.;MvzX[oKh>yFԵ!8ZjޟJuV־}8lԱ)<,.a,;~۔hbUVqRε189Ǩ # $f4@hgq&$,R5֔g*Ì11:TxA1>Wa$pTJ:ys$6'7C69m=ʂelZvξq{  ?8=ֈcJ1MsgvZ }(M)ҏ3Gk b+1a΋0zIuM%x<Ӆ#2=4Mt]d8I/|fd+_L߻/IK{Gv_~o8bLmA=2n9]Qn^Xm$F&ܐ9{ TMVCa 徉CY]gGyt-s1Ch] % u1P%ׂ u-Qht[쑦~'r(2^tnOq#Fq7l)6HɆc0ƛkUT#Ń콸V;adT ӤV\;8n~css#.ND!zPf[Mh<6`m_)QB KLW'F5жN4q[*4IDATnHsa8>@A%07~1н=x?I)%ɞL0vH~wHqt.z74`M*aCr~?]MC8$NkލU;vUR ]sF~E `#}$ ?úoW198n2#6_ڦؤ~R 8D6 %KCA!G< mn]6ԬltE; %x{aSLIFݨ/g= Aq'Z~qr+UZ¨&%0CMߤ'mɧsD)?_91:g>xթE{Z|cYU52ado4RE|Go9l9'*=,Nj_T~qjUw;iY lfQzUKFva&p$Н kP:**xyUw8T/ wVK<@m tm-|ZZ͊7x;am-_:.[F&lG/:ASԢISx](QdȂGDuMl0#uuW y֨-tʜl.!}(t4W*pnxUKIp+m` ֭M8$mϸDqf7\ !Elh`( ]#a)g䆟CZ_䌫LKM}0ڼRѲL\x.<DZm BSxPnh@zpE9a7`;ţ߬LF,.L7.y~7q\cT(%0AJWZpSڱ97β]0>FٰgjDzNu [>;,x4ʏV]ks%9ѲiI O0bz b’VT0pA4_$mGfIG 4q*v׌,G(f2x6SmY|cEA1,:ÑkGP@ #K 9jɼ0y|[8V8Ck!)P#Ҫ^)-EpdrvZ N3YwƫU&/bLq N5x7P 3EG|̑X@}Dε .+re1,>q'1l1@Zp$v[4L3GvO9qP\۾#FǑPHeY.OaL2JgZ/2Z5IGDQZҹpcnL%Te#OxOgozXy cjAcfxǼJ>0&bQMV"2LOJ xw <nT,zXy cjAc$Q&Y,E(Kg^N\☞iͤɫUP+_ʕΨ/_˜_MjT"6t[7\V4~JEZP8h%_ -q%ᄼYg'%a,"d{6W&BUFb({9 ~{[If=Nj4Pdqb!rSgƂBY&Z1 gf>5ic:ԋ tekUbxhe)_N }cg r,RA@lewk wH%I_yɠSx+#g0I$R(Z.{(Yz)rM#BMO %Uk/'4lXOƸ-\6nJy 'n20Cim2ENpS)v^) oRb^ۚ%jJ1cbhyDӕef ~dH0K7Pt4!wRH^%[" XlI2 Ue zTbiteJ3&Z}=IbZGpΔ2K3\-"4ϪTQFg&Ԕ8*`χS/piA$o Pe(Bȳ5O2KXI^#e| ԹZ)^5%F3*jyd+ӄd> D'X]վP/O8z(I?,>.>y28I+:wzWvjfcl*~,>+|,C@ ]'cnš\8Pfo2`BPLY|#j?/U^!1ƾ VpMfX7 @hw+X[/wp7GzE%6kTo&UE/ 7K(cTjѽ(PWx:f_?iGt֡"A Y(+3O=Mp ֌qFM1e(F<&vԲx[BW4aTy7jyGt2W]G tl*e]jJ,#y}F w L< Dw /dI[|&LZ*li[ pQ& (>q| fO~~<iUׂx @6}^\uUy L CH9RZ߂#|k+l q!tG܄A]m￨ x&y|cM<({P|jkt"4~hUBA^-U [Q"1?5·p.oB1 ./{-TDZ73ۯG\"~>*۔!9 0f9i&@Uڐ DRkPAZplk,g,;5m(>1U,6jlAkN@1r[ڰL%elUa9g0)߇K!|Ǖ8*YRH֪VM!UG$BiE12R*,BWTHg#(ޏ15zjJr-h0-4jҎ&jzv[?#{aE{!^[ŘU`lL1L8dÍTVvK2ǒXO&T][̕Rއ MY"6r j[6gh2CDJURAtfz-6g✻ VƘܷVVk%xZxE3ehfR/Y5_{Š ChUZh:`|ӸH^-s,z1u2aRVIJ2~(֊ijnLcl(ދ kJZPkAUY VTy+s1/CSqd C|ZOQU|qv\ݰ 4u4tw W17Lh|F7}3Z59Q#A ύ'v2CŹ-wJgBGV/ ճa6ұG.oHNL $E rB‡΅K UfI=AJC3a?}'|wx'dcHEc_ Yi3'M=fkٙV!Q{&תُ<%;14d~̤-X$M AunS7ӵ8b0-',pyWa:56-XdHJU ,Ƨ#[ZtP˗섺R8noJ>I|1VU-D"#z=tQռN{1ycxSwa̙hL#i+c'Y3%JZ\U+5#;M*@}ut({R cK#%3*%k,d<|JaMeε׾*Ե&_ӿ-Ż0f~ԶOOY=ZXkSvpZi;ovۺq ,c㻎T4qMP )HYK?]Gm3 3vp$|+Hp<¿go{A16%Ha-J,p-Qw[: @pL31a|k`EotЪҿrьuL-Kr6?CYEqgc>)ށƘ}1`st~Z4GA,ߞ&tR3PTc"ǀYϿvvֲF?ejV! =D >o;UrG5^|N=_Le$cŽ";6'9]r;c rle=Ҕz1G`h8|lU&%2GIɣG m؞ o{5?wT{l$[8vԱ)mxngЪ&mjAq3<&:7j4/e(Y8teg9M("c-Bm2$2YnCPW@Tǡ:M,h M'aK#ՠ,WNpϩ'{Yi P^Yqf'U +nZwJrJvk{-5Ӧg7Fwd)>P,S?frmCVn?(i_1SxgqcN-znN v(7c燲3³S>KW(cN^ڟHqڥCc&C@'c|1Pn8uth~'C厱JqS-cCo/G/Ə(_Q?|1~˟/Ə(_Q?|1~Dbr>e=5_x>.]sb˺, eb#G/Ə(_Q?|1~Db#: xa#G/Ə(_Q?|1~Db#G/Ə(_Q?|1~Db#G/Ə(_Q?|1~Db#G/Ə(_Q?|1~D&^<|qIENDB`)Dd{5% !"l - c HA-$Drawn\HFIELD2.GIF,b(/"\nu`g%I(n(V{ ,}M=/"\nu`g%IPNG  IHDR{[sBITO0PLTE"""333DDDUUUfffwww{ bKGDH IDATxb @w۲*( ՜{gtjO!X{@,=  pbX{@,=  pbX{@,=  pbX{@,=  pbhv\bPe9@ͫ,'tE={F4Q 5D=Fv?'hg U-{`u(eV g ^gTUV~tx"o2@g{?UeDoM_p l7sYQve9vBr9 H1+j|7φ؟ {uƈ^CaQ{p4q[ I>pGaosonހ{TdG+YEA$ sowv;3XŠdfGÞg3xemg8X!=:ɽ_ {;E=M㱰w=c8|z:c {HQtn\B[C7~{pv:/۹T ٍK{:C{?tkݸfs-hwn\SbT =%|'={pvpOŪ{=8 ˶6X݃k7 )=8 w`]gaO;Nr{pvpoϦ Uzp poǶ؅NܓٛL /= a {F"LvaWj݃' {rT'eva{>{Vu1^@=4; c^cHcU1Qp/(_us H(]4e<_^=EM\rO^g(/^@^5½:C:Mj:C:p/8tȶ =enӽzʰ'ݛͮ:ChhM}4Kڦpa'mGrЄ=Z9{Յk,;K)òIս:CXzܓ9w|D'[O'{mW= ?PO~tsڰ79{3BoYto:Z2_migg mb7w t7oysz.7EEވ!6/^׹ y]FŦ--ݶAO7eGdz{u6Ew(9c.}*_'zlщ{ *v{DT>D( ?$V*V ?c_^Bn{)9~{,I4.=dJ=mCT8uH2M@]1'Ҽ po;>V&'yaa{FtOЇ=tH#|DN@㟳T|uڷIYc󺒨]>տ=s{=#%>\u!uoFCQ1*mHsը{b& :$~WpϊnQ3 aUFrgh|+42lʾ"'{uUdH{fzdˏ0bxcrRظ^ 7@LF=C>qQ3LasFbi:roJ_E׍(OK/C3!!Xr6{/zsݣ BN겕 eyPdjg {¾"N%_t^ [Rwǽq{U{͚\rpϝiKʘޚދt^agju~؉[b Kc욾!s MOT:Fɞ9vFynYU5<ϸET Jï&tJވW6<y^ u,jjz+Gbdw+声Ո{n}b`/t-u5PǢCy>wbPѡ| Pm¾XBߊQUN%yNPed%赅_r+#Eww{q,wwuo3${c)0$Kerʗe"w{cюN|ɽ"C$en/7r g<{\z=aCMmgEp$m)oGuӔZ"qo_t,{y˱P;a8jgao{hmqiKfꏸG'E>5/:{A{h]Q]4GNޖbB F-in q"=p&^z!EP9 M|m[upل=p.^$D!='T{Ay{\/E[>JY=r {ے+DžbBZv ]BZAY_{Zv e*GޢRسHfȑ7k7lÞb{áfjV0?ˆӾW36,ݫUSB+LaگMW{ن?ڄ7|i.tyVᔏgotd=7H#4_uO!W>^|qÞX9~>ܫ,vRG+xbuؓ{i7g8#{FWX5a xeu>޴ϸ2cy}غzvD{Zg~ҵD =}CីiO<{z{ao:.R4-z*ćHbKoW4ݻS=p/ B#9DݻU=p/ 6!9=r4U H3s {Rh*ݬ-Bs {r% V d{Na/AnWO垸'9i2/`jas {Rhݯ=-QG'UbU.i]Yn%$1K'Xz*ֽSɌs׉'|/NʽGk֡z%7dz r/wی)-QOtoXkZJD;Meҥm=arpo_9{H Tk<-̋ߞ{KBHaSyu?\(%r{z^xEn3ԓcYvtϰmF;4HŽ[ԳpO^'Xwi ˮ{dܻGs.-=L{c]we)DܻIs] g6uŻ}S7wz.%a*2,/p6혥 s)=3/C3,4;L;Us˰pqP9{wKO~Ͱrqދޭ'cTq q ޽Ih`S?|Ҍ?+ xO+h b4'^H# g[y<+6 ZKUm+Vu;Vvv~ (*;r{zi[VHEa{K=r\nz-zd$.*_ɰ6Tx+uˌe9)^Z6~;=aQqu hK"tdXjU"chx{8â=E ;eᐧ{N)^@^ΰÞ{Qp/(6-U򹪼bBMspObBb62Y>h4MʽTZUQγFQօ=p/![,})CuI񻸧HՂ{[kn~XN9+^M{Qp/(vA~W8CL.=Uz {ZҐKYC2^:XZ:&52-qpOKhKnCfڰgr {tMo%kL vgk)p/$ȠۤہB_~s\z=<4f呯4IS]~ϗXkqZ;k ,R9-x_A{7|Y|*[~u_C.c3/ŭSX^ŗu(跿^D _j8oނOqoi {]<,b_[׏ICڻ[Nʽe: ˱h8;p%{;p|lݛUigL:_8+vvi)n3ٻhroGi8uObI=^a 2C~ ؚއN{A'5r|qWzjāv/MuUU t{q`{CWoqT]=c.+YF)5\so:ʶʚ5wzF^%Cyצ`!A|)+GqB=cIÉ{%>SIyW?#WuxrJKĽ3WBWO͆e\x{Ksǀ3Z1 Då˚(mZܻ+iE?? f~g鞺r4 ,zRK4)ܻQ=s<">[N{wViبm!UNwSK񑻧[oX>ݻW=C-AKܸk /7#XӬ7,SWFwfh]W+ܵtPX 4YSO,ӤX"wzv!%ܵ<~Etky ~ vMi?+=S^3O=RUf=V3/ Oj #\oغKg9׻>ؾ_\𰠥d"_+Kn]β{{kTg3qTid6ػdSҗErOްsObx/]JdS>p/j擞]ud{`^{νz= {@L-j~a瞦r xb$ v ;t=p/$n} ]lLlۏ{KYS {uOZoX-K{AQ'7ӦXغ3̷~(^:bvoY[{uwL}§voʽF{^hNqo]oXM{!uzK}§s7y2p/l{xغ{LO}:{>]ս ){/G-ț}sE{Q8kk/6QlӧXz bsJui^~cap7=#t/4lZ5N)r qO WDtok+^o\a箴<-rޫ+SKwϰ֖jd,w=ZĒ/6?g㥭M̽<#n,oþhWg]ug?O%(;[M1l[\>wI?C妘硞XU{ʽ%ǻs̽<G[9{D=eeeі )XӴK#CcNթ{uIF_9{wgNM " g?^ԏp|6G{g\o:,X»{Ľe9wzͤ=<.鳳DG ?gݤީ{^7Tm;>#j!L }h"ݥމ{d-TcB{{4R,IwzrEH&pk[M̿=/qSϸVҌ=|ܻS=yqU ݿ37 wzr-A!s1yKtU>>)a{%n%@;7~[Z}=z#eV'tydxx!/+ǁ)ﺧ%60\VƋcؾܽBa֯MyҨP4udj<8 'lR|w{r4{~eqBX49ȗS7Lwi~b=ŷSM ^PBxz ;7zp)a=ۯ7L^PݔT9 gL{!v p10U{A0zc6_dlS>s GXܣ7zM%pCO7zv{*T/vkq=~pC|#/p8u욍rܿ{G{3S +:_ s=X9~`2kM"B-{-^BpO7N_ e|oUC2k#} K{q6y3[3\Ñ%ZO( |J{ wJ-q snIɍ.+g^Y{Ϲ7d9Ka_s_9ho{V$[!'{ĭsÜ.ri |f[Iƽ-_&}=w[^džo;qn{%>/[)R([GTny7^ez tu+Va\{0;! Ġ5⮈)sqO{I7HS3wEpO{*NI=\7qEٻT=PMZ=kYY=CJ!F=ziԳuԳ!Cb]өgN=K@=+qWWG\V=;ٹّ{X=Nӫg^=+@=Kp\q{l3ggK Q{Ϯ#LYgR=PϚc#.v2w^iR=PϞq~lbR=zzDwoU7{qʤޙ{M]9۽M tX`0W'ש- 9ٽe{F2=#q ^{=^=PϑWɕk ztFH^=Pϙݡ{4NrKy=zO\ts=P@= Kv.\=P{p/@= >^^u#5u]K.ɮ]Q ޿Pr)gpqP\cwCӔU3\1b5m;muBv*k⳵5BVܴQwE^b7BŇ8Wc\Ewcln]{w+}uMlsѻRĻ m:)L՛CWһh_7KʗF*_\˹p"zAԛ 0HK b>DHJNQ^eG>)͆K,Z8\ [>>F*L{Ϝ|9 2ܗI_=e^ 1BxSՉ}SO0䭌iR 楝R,#%F__72ZS$%yIEՓQZ/xѤSmO)% F"%^T{5Ƥx._ ^F2&oLI ͫl\@SzMc7º0?vdA{kӼST \lhV/ /6 )V/wBW{z e2w#Zh^@sӪ[QRhΠ=ym|E{*գyw(uOz4 :S7/RG{c'Bԩ{,ԣyQ2hOsOz 1.exTU^-u&n:]k7Y{z҂8}3$Q^wz@kC6ԨWӼgeIzl<+JYb<˨e?,1gP1ա^f@kJKxNAX 53*2|\iRaM2FnK=t9uL``uzG\J=C[ Ȼ+AWTI V[I*Htz,2җpH=Se\ XdD.z3>3*4pԳ` +di`32ЀQa=&¨|{&㢨|{0E=۳P2.zϽ= I@ɸ 5D; 9zIdAvHN3@nvPd?D@A瀖d+!C1؃P z zŹa  z# D{Ad&Plf!zO p5z#s<:@=!7>U?7 yB]ϻz3Ճhof@_^=П!uzrɏՃhg|WU 2DTY"_g'˓殞+y KyXdI uz3ބ=fs)MMb'Vo~kXeĪkcf[K\iXȪaNps }bWAlzt6}:ٸXO9<>,$ܹmbq]_XK-ol*cW Cnˌ\fMWl'W+WΗYƶ}gE/!ꭦy7[ckyuV^m ZL tBQ;GΚg[2-i_oMlte{8V/Ӷ^ſ㸅ͭH?\#]zxY*gq_ wz Cu YPU_sU_e^SW:[Uoq֗)^\= իvV=]`^LӼ|󸩯csQd/Į^mU+8p}/6UoYvwnܪ^?pT[^ſ SV/ɌGH׾^}+P-͍zg7۵jbuː}׆kB0KTZ9Jvm,quWzZqc۶uvb ͕.856l=~\\Z)WTO'[](ƪ(;0EjX殛£n{]D 7IuʾZ#͐zJ'3fk\wissTMl˕Q=\halqg[BFsO? ve;HnMKz iwv#v汍GU ^ nlWS좞*PVlK5ᚢy'p%m; ]+|SτyKm݆&>/ cm,Vo myFVŖQL#M˖Zۉ$k\=+Wn|r eQ=L6F( =S뻮A3rF򅫔Tz.[1Z\7 /rt3׃& 1 z*2W/sON#st>qd|QVv}z=~q@X,p}Nd l<Oiww/]W6:UoZ(%R=kkM6|ծ=an;@֎@SFM?] ^eVaQe ]+>#hy GFyXo{ Ϣ뚰hpmqv.9qKŌ]0[7to"^w4 !oxx/3bKd=barVڿ6^sp=4_Ҽ|ҝHiIa F{T^c^4'\% _z[~91v:b͸ܫDc%z;)˫7Pn_ջ"'[Wo%#>VO d]~~O7\&+@=f.MYʗzU=W^d{'2]Le5W,,Y=nzuFy9`Oꅃׯ5WZʠz a[& { GU}rDHn^GE 0Uv}h/'}So==( ; P zu^h6rێD135ODF@uhk*@=5둣ׇ/?q޿({oBud0G^=w!;f+yPq*-uR z#hԓAzwbzs:0ԃPOd = cq6M\aG91ԃPڞ PC=]}sC7A$lp,^90c{LwC=R}WX^9 z8|3i[09oac= | b`-zK2&nj{0Gܩ>8HV|ɷ@8DŽ)`-zK`O^Rcq85PH=g%C4@4p ,Xh PRYdU z,4jBG {1"L=C頂z"ߒl%8zH4So4 {@Lb;q4z {GQ=8|j'V;9hTXP=p h<% qpǁc0pD> dTa`=L|}E=AT= X>DŽ@Co mT=1A[z7L z!:S~aM>z>x]UWe?oSo R7inY=7 6--S[`,h\-zh-} V) jg*5j6S; נYCvWT՛-d*=| [Z{7;4= HeJKxq'z Vz~GfasF@oQ^ѽgQb,5UQbԨSz!U^ص蹧@zm{k)1"Tc d.[Wa'yGzZy=Wj6Oz<\ט\ensW(4UtG|_mW/7/VlI}%B9my;j/0VRPo|1u楡^-yD pol%RQ/ lIwLļtԋI7L#!4 6Jw( )*ݔ~7_m26z>4ߙ*dHLnM2BiϓzayIJO |}r?Q A9NxjS yK#TɶT/K1zo|²$Cޒzk;`x,/.$2zw wJ%FZHS8K_Ջ m] M9FW/4ɗxYK\D==%8kL!_Ne&_C'(RZ-%|.4ˌL%N7E}䦞!I_ }xuf^ /LzOھ)&To'n %wGd޲ge[˧[k\.z H-;7t!Bn>V7wz [V)mNPwEh1MԮ(t3T{~<5Mev̲PC*PK]ӫmi:jlK| = ޿P|qzZAe50=8z@?]q|__!{q]-޸g_X[[=](}zDGzDGzDGzDGzDGzDGzDGzDGzDGzDGzDGzDGzDGzDGzDGzDGzDGzDGzDGzDGzDGzDGzDGzDJ>6IENDB`L7Dd`A l / c HA/$Drawn\supereq.gif.b6] 2DNH|h6n`6(S֚cKskV] 2DNH|PNG  IHDR`obKGD#2 IDATxpTս?$ 4I@! (amhBB(QG #:(#>e*( + #)L&Ԥ$5ynjHjul=sz>|%{{| h40h4hh\CFh4FѸ60"[MhҁR;bC/q[MRhIVgv˪h§43y)Dx΍jIm`4mG}u:=m4IHiq$ &&IF8C Uk}2$#j}aBwt$h瓿k2p^M hQغEzQҺ̔7MsXMJhQZ~}}Dhf)-lTghQ$W"3p8тmH]uôfUm`4 STIE[#WAQ_wFV,R{Uo_2ޠG0u9}Z6޳t^!).2MkoX h)]s7\q^!U=m?Nr =EҨK_/(haEmVj i_IFGݝYn)zQO>ފc!XH^4kA+~>iyheK ?љKSqsF$^nޣ[}ntU)F,բoљ,|>rGTqd_Oh梓)FUբYX(vPjٗ{W^\'6W溫FUf Nv/OnVY켍EE5F \`WK0I#F*׈69#}dR{.ߛ6;׎8(0\ ѨJh7fM{LV)Ea…DASFHU1pa7-{)QsE"`(3_ZiӨo w4D(M.ÓKe_iu1Qۂ D95.-ċ'xZcß,%T6ZNFOԤhQ"SK<$5v*`^J,XyJ`~LzV+FM\\TWyNDy)%|\&SKi60JG% ߵRFct9&/`EV 5knXÙm`䡬ޱݻouIE-9LGVi(0/Nl\_7ukI9&`v}!g-^%t*4P$%f}suV&9h"[ >R; wyꉠ/20:1dM{2FnkWzOm`Rto$kq1^r;uy7\V Ln/8駡9M;7 X)gё)QZΛ.}~Fiaj|"q I*n~0]-CjeP"蒸4\O1ZWO*z} kBkvih'ҫ#M,Mr"ucvlqs2CHEҊڵ;tg⠰CqTbѵQy^.V_-Z]7iWw6'#kWwi60I` sMt&lWEza$ 5K^;xxPnMY Z&&1x"%G7#5\=hrk\ 2Tn1^j$ "uVM](|"O>+~r񻪇7 gڄ{ JX 嵶k&%ՍP;~p(]HwTO8]=YcD7? g 7r+G$Zn)U9'[[?BWpP.+aJL r260I &:xx sę;ک+M:f"zcp̠$TĆߙUz(9#Dz!'GR+C`9# y3οg!@`Z"7m~jybw~HD{HʹΘ}0IQ\twGć:`neWTZQvAxn4GfD\Ib3HX.>+o7ȕJQtIO*zk)<]@Sgz$ʨ% 9h~B`H|w4EVhc sإBqc%%g^-}dl4>224ICZr0ذneM܎д l>&uҢ6m4&^:¸7q[T0zoPd}0"qRe6{(*\60/HΟpu]'h x51G6ג\pǐǫ,:e)O1-Z;C=C>bB3*ERw)A[:+pZ~do}j4"J`nUHrnZE#k*2wOu.g=<qܵqB+/h9>N*`JZ] h 㓫2AdqsbJEdhc0%UqeľV$ .9KEbS9J٭`>tW8V" Xz4/!vѬOޔ V pԨʩ0 M@~萬lHTs;_ԓ]e7$<2z6e3৆=:_+ѮC2Nvw$B3zvUFPp@6"0.dfOk2~Fo%Sn:DdtT2~G`q'@ebKabg<[p<`o@]X|K'96hX㎎gn4nL+=E2sj+;l/1`|"nטo`]U}Êu@buc3< vSaC35y¥Ex6jk!{Z; ON' ޕכx ر@(S'!5;3ZڲuSDּ%ƯfM^#Iw3 ^P{lor`##sn=dCL確̤J`fp&tdWux P(]/|B|7zL9ELxq;%#=lj< +;"yJ.ZŊW^;dk{o .T H/KTЫN8fKgj3j =nKBH%NN;uBHKn#KYusD?x7VRgJ9~= ǀB#Wo[ k d@=?(K \&1fĤo!X+8 kθ#3_&=:0RE'U0 %7C_;1G[Bln%  W߿SM.`!٭._1+Kc+cLZ2[S . aԽ?x#n<=tj.B7 D,[ Q'É:a7o$j4`̎_l{uue 7Rs<03dqcbGGdr`6pȱI6r>N#8 T3Q`O3iCxU+j=VpwOk !f zi+!uKBȨV-ϵSMڟEiBIB:{LrѫmE>sĆe@SF hVste^-2fphu" fQ'w%Πp'tLb{,믽>[KGxޫl[D8ϬEm%s- : 3;]|D5abIn;?b.1,~dS;I(ηIPǝoEBp͑ F7hNU8- 3CBf~iP/XG# ^%bz*IG;!̰1 Ų*o.Ç!lV q&u꙰ m0i= H\՘gS}2pN(*݁tSAyG hݷz ]Aԛlq  .<}͔Y߭F}d~%PtayI+5JLX.ջ d>-X)_r,\  m҄⠭rPT^m'Crc@P' ŒM|JϱcXX֦eRAFI ͺ]5kpxwtM<Foq5;P?7гRmFޑO̚/p:1Mn΋-yO'mxwn?S/Nrc=WcOO(O_y[9y+4E I{wo+up6'|V` %Mۏ+'q,N$; K.hlz$t74ЇMȒ*Xvj˗db'7(ʼnfMl%K6YFmj-BH!م tNeVdwGm/$ V*+/*m _Rei]l7|K/1 fQjp-ّ-1ANUHgt7; Hր^F+q԰+x2P10:"Q>G :U* fKlT+A?]+]I]U0edo% ϾZ+24=j}A Lge5Y`⬃-"Cؓ>vR:zA?)~Q!F[HUrJ@?κQy̬nCgN*=oT4 jA$0,a"$[[! {Lsً% CZXV~pu+A2[2 QrFǬ)`薍;ȁD)ۢUvP@JW#VaX2kiSOJwm_nN-Q1j/N]CeQf?~{3b@-BM"Fd(Nᔉ͔6zY{mןWAI{֛HO^e8-5؊~IN> ǚfnyLpmE07Ihq^|}3X٩/]/HsTT:.\072O<fF~0>LDJ-yv J]pAz E3A2y5 ~0Tv;?k '+ yɼkU'"Ц"[7\y\ XaRxK3~R嬕0r1"bƩLoBnJقӬ)7-Yqp8E^; f[x7qqw'rȘgr7Oo8(X oe4I[>fuJe?!zOul8`VХqD,o88>'s}s's?! {*Os!UN|NMUId Um}0ߌwÖABx8nh  veȼ yc9@k/7Xnk>s9]dGXym/=2#$4-2$Zo˳nưUgtO031;7p^+C~H󻗄ms g9V%mygڗq)Ϲ0(n"3^Im3E3 kpAJh.LlPgUrm.a7775]y@]`ܱΌFyCY , (3?ص2)s8KIj!4"9VBY٬^c0D뒹\|.QTsv\WrͶ)=W_}eӘ~^4j}CKXT1ydB3gOnk?c$z8b}H P ϕ'@lT#3(nowFcY <bּ,%j'F/tSv8G%[bhTOn/=#S0]X퐜{!z8ohϪ^vtayQJL?8K|rk7sh5CG'۾;2q_Ώ9yyp̍QWO_ ;"#q] ƭMM̖Wbjhw7؃2WTΤ;v ;1sT:~^KOpݸۙpÉ|>;vz;=+lS:{)xX-+'3|UC(Vmr  bJ qQ&]j I]ÑfGvI)3wIfd?oGcG'$ߔuFlIOrp7R䚘$B! `|?K|C(>!@Y.$_\Zi4 )t; H|-9jcWYXfIW f؃e fy20[x\3n!K2u XjP/&<_c1Ցz㿰$?O~5=tC)o R rAin l; )0r\Rnu+pV9/9UnEo0):i'WgS$|^@wF=PXht;Y A `l4T S*nG-%>hq[%wXvzoyo,'sg/}o`3BX0☓SR1p2@PّBbUJNY7̒hNY @0O4IQ5iZbEc[CtSHz I<\)FEDY7L'%(a4ylQ{X%isl1i8ʢ.;*Ւn*DSO@??64M,ιsͰZ֮@Vb/}Hu_$νSz<fjQDWlEy-<ʡ J6Rj޾q}~%Ƹ̎g>VES#< +kxd~жǗ '3f> o|` n_iY0o,% SPH[L{ݙvwwy73ߩyIsaj՟دt&b0{kh,{9EC<^2+"?yGum_p Z[VE;cMG n/`^?Ljx!D V> ڳ~޹=%0Z$8 1~^^*d`v\?a ;0\CӊtX{az0 H`ѹGV;^w7f%״NN~A}>Ma Ud` fS/8-jc% Y$E %ޡoLdۢ-XтV ޖi$**>peFٛEƨUNܖ6x+\9tJ!FIcTb.r]n/asx*1NŴyW$ŠqM"cv/l)}XH5&͹6T-V޸"O&\{#-yh=RnrZ-Y6_w0 c 8fLQfp6Qvqs6G9 Jv/e>?ʸm7s$%մ`*"]{pT (?Jigr@ AE`8,NaxfDJ0#!kNö!=`8˂Fkaf}Rc(V񯳴D'`xq,IٞD =%NB}H(@ bFi.HE `>:"M6i;/oU:Y I@f(t5ΪHF#gBO5CE;42vذNuڲ]G`4l~>: "MlZfB?=@ Q14Ԯ: ͼ\L0:);N#oAhe^͏tE#a,TV)>?mnABOHB^ݥ: J0*8B7w} ~)+9Qh`v*IE_4q"YG5-[AQqRu;5^uO`:'(B|Cy !C %Bo(B|C J0P!qIENDB` Dd= }{j 0 c FA0"Drawn\soreq1.gif/b>{Se )nզ+M~o>{SePNG  IHDR=BJsBITO0PLTE---JJJfff͛AbKGDHIDATx[n: ㄀dSUQv[10_ǫ!o:E'rt_N ~9:/G'rt_ HɽV)G&Ρ~I 燤kPR !M;wTs@ȇߋ&* F>EG7ڗZ>gãFaS%cI mk?k~o $^ <4O-pChqFf7/2i1&! ]Ȃ+VBloۀ BĔj'sD/BDgD\{)%IBbP"|㭇{ _ +)d2 f8d^JOx>A/j'Ensd :jTd<Sj@%3PiL~N2jepc$CJRhİDu@ _D(>$+1p>1,xs|'㔣8Tq[| ;xu2Sb RcCqD91IX & I91S#!dWUz J/-@jG 8RPK&\W"*;t(jp*2(XȆ,& Q̵ԥ:]h|b4/5oI㳶JUy륻5V.I |ck-\A0I<դdzHuuC9acJHIHHQumKOSFj(wnic(H/P*_'8u޿)YhPkQb p9ߤWv,pl;A^ -v6d^7(lh_z8I#H4uqـv,U!)k'1<Ʉv`KK0P͗5òJ-F`.7kY c3$#XGg"xI E%nB&Dw-3ue\iQZV 'E 7 s[G1,Y{N*#.LRu01\}=y0%X¶H#'| i/6ohu.@TUk?>EfW3f=][=j4+U4G^Hܠ]I! ]aF#u ƸqJR4Nf =,3zɝgƴոoxKsrÉrv=Vd"Cj#:&EjƻcPBj_(5Yjs2!{ !'%5]r,3pNqH-~BPZw;~")sX|o9[m^ʘtti~dž,D7Bic}jMQR]nUr2vQ҂>g qteW!8sdYA^ݘ΁5=+! J0e%(d`JB; %1wm* 6 jQ"{Frvf8u9-aBqk/o6)hc@^r;"zunF3/ vWbJQO 6?}0HzH VTND9O" R}SАp uc``8hjk $~eR) 4:{ýh\TȽT1&\!ۙ0;k3,q G#[c>we4hHLVeYˮwjLJ_%l # Vp}T2qAwPی+9UgrYmOYbeFd%(Q񖹫+$`˘U[274##β -&};,!R^+ =9Ʒ$^^i@MSi= u#ͧuB>@U!)2Y)'90QeÚ )Dc2L$gQpjtm0QȽԁ1I9x 7qiH6u δX4jN؏ f3*B40˲ 9+JOcRr 4l\s)iEiY&ɶT3-Јr$t8|>絋J))ir6*VvEUQo ZL畓>oF?ᦀJ Da A-otQש&C|i0YjyoJD ǒ1WP '7ce.(J1&Ū&O7d óMI5MXcjp1ތnt枊Ml㣯)qm*6:BO'W@;x&mj~= Z5%GōP#,]"'ݤI|1 z<##8#JtY†vdʂ'MrGq*_-æ|9AvѤ`1܉$nF@ZH5܋i_ýHaÝH!ĝHA HD@¥ .p)KA$\ " R HD@¥ .p)KA$\ " R HD@¥H@ I ]V]GMȏPE5+ds~%9!m)D1~Nb m c^2$޿隁srČ9qAH?=9wDa@dRMO1@;YSsD@㭲熇JS0<SS9x"C?ccRLAnـE쾽v%SuZ|C*Ufٌ#VnIy&X/DH@KN˲,O Z)mc($c|xS@SfrlJy$ I|٩g$]d~3 Xo j Fܟ;-dL$ ߧlOgH '\ep4и+45xS@. |h\Z 9?L0h6{P=$ 5,N0P0R+Qt)}S8~T  v}.#501h}Q@\3'/EQ~'2P I'&B |x VJaÄ}VGD2d]U߳67@~/2`DXHĀ((ޙMPE %[r"ObҔVa%"mQqC 7rds*>Re~ooxSI_qw$ {'׸W$- yΑ_#=ɬ5VE!U{v)Fa~OPr_SLSes߻i%BTR{„L *Pʅ e6) !8wum++GN3~@ %OV|ְ|T]͟!`(T)^@i]Yr9,3PȲ{ZR+y}*H =y=4I^Jy;O>Hc(O\'@eG:XӃx9*f>54 ˍkKJ@2F&0fFϯ.½G h_ ' ꗠ<$ o_#%`4$Bux(cxo h(gFtum=+“ x T~7<wd T-G/!],ێuO|noBx ؆ 0|e@$ x0&d)x;qP&bV܊0 SP#GR\JrOH(t4CE&F᪨ [q6```]1za& j{%Z,:GlĊ !g-1L1c96xJ$kL|fm?ꀀUꀀb~\_SjjhMQf>F0a䈕% 7aZ{%Wse-*Sbڰ@;!nu@icCzc%<()P)X `fb7f EP̻U{j, NnނGNH9*oL)i@T;P"Xw/gkp !{?L@^]A/:z*/܈ O?U>UwB0 ;7,[;" Y 60A3r8 pNq)܉(  7UD` (>DRf8!npU ԑH,CWa|y6/7eJ*XMo*|Bc MB#NHD&We*atM6BN>AgU}8mq/Nn`_!k5(f]SXmLc%xj> B PAET6b@ #3P~:3a6̊eT8aCRgÄT]sXQ@.@y1 >)!a|9-Vŏ |@T?..8p Xz!ط#=4ְUU; e9&rgMvZsZJ Ql "2TDJj1PZY|hq]W |vD\@ٷ`oWվ1!*Zq:uC 8g*E,eZ'lhM{׷(֌jv׸5h<+K7 r@×#^J}3H"Z+8M?kCU6%Ɠmy q ;9~ x2U ! ;L!h#\5ӭnu]Inߟ6 )4 nRv+^UJ =2l}|>֡眍!*XHJ{G?%Gu [?}}0} }uapG9gv^FϽ _8?vqg'zմF═x0CO":y &bYlx57O&`mlV$gp; Urg0i:2Z߆euY~MK$ }MVr  &͌G!MI;~JDMwwv4ոzAkfI^aKPHϳKiIqg0(-[3 +&}[ל})MMMr._]" TNIHoƽ5I@<V }= AƯ9N.hou;~zǖGWmĐ"8,F:ie Z,$6QṒIm0_#>RrieP$SvIÊ+G0=[~ȚXuԕPN5ֿ= wBիf]/^Bk{ G\ۣlƗz]KT>dݸAb]@w <՜ D+2F@Grom ExP {D0Ҕ>褪XGkX:$iiFySܟ^@L;- +u\і\JTf .z0$`r| +k25f`;E XFک}K EWO Ic+;±|`1 s}؜OTe"VЫa%H?tχY9 ޡG%9#y桥li p#;5k.:S?"ߘ:Ұj@RfJ}QfhNIq_V彘+a!aW0m@pwo>G(^)CwnyΊ%4`IчpPF:Y@I`ƀ5Pm/.*Wv_ 8k'@4$-kVY x <$Tp.pӆVD[u4cm{ q$?GN I8LtPJ(*^=W~6?qd+7TNܦ8Z.ڀ N,;U&O*=!)q 8Tr3dt0 Kd9aօ? Zڿi[W|~.GC`W~ -?b˾`MEԋڅ#AeƐo&{OmOƖrx fOh$;$'H}TĚx{jK};1նq1ձ0ee{foouj(XY >Di];I;i;])$ICa\0&vmuwR{6އ#!Kqq쟷$wY؎e=~N'Q;~8I, O'2H5O9aվs-"kZ>~5^kLg -4IdNS3C40LB!S`HFW4L%.77%dsN+KI~Dm>t;er׆X异5! 5T;thX]w0VŹOId3L'eOha oOfbK=ߨyc~$e(2eT"I7^y-@4(M[J`ww/c@}}cdEEoȗzᎀ D] z +flOv7ʨi4PjSuo|MfT,8$ 6 i,|U;h}t+]l9"K~@|Ө?/l[sD$+ eS.-X. ؾsEsYB ϿY|W:RfKrF wq/3/gHNc.W_ǒ1v"|rӬ-֘DĊ5Y 6%TWBd};d3B-Ct~Y3-#vey= E>D@ ~z2@Oլ| rG|; z+M󹃗sus\JZW+)U]1kgJ;99J@Ciq/DӥDǟB@!2:#X]Ӓ{5g*%4Y%yk$6??e7ED.Ow#23"v K+FW5[v9Xz'@{68P(Ty\7*2+i⁔e+۫ F-l/Q>kEe&<Вs>5r^j_u-X+|ߎO:z5pIӿw(?ocwZ>D,[E$ϩtIbqLg{kiGR:C|r~ K[ۊy{Be3iB1jsvM? ?Si0lp{~ry(6l0S"5*` " EW73+r_(pwss" b4y+TQɑ_S> :ˢ0+dD'P+E*qH$$$\xZt* & ?CVu׶j]5vnfUn˕q֞*FWv[OkfP,,+y[uK{*%};Nw)x'1GuO_o[IiY5~YmAUv拻}L 'BHv8MEg /S|:ٗ&0~aQ !~.!$@<JQV0&əWx 2b9 끮5r-?r5޼ hr6{ܚ '\=IwsXWYv~Mޑu-e|04Z<,i5"coGXy]5g)O!Jytϸ-FGxJHm'E-pM@5yX0U]p +Gt?Fvw({QPZ' u^ *>49Do0/ϓ>|zm ^`JLuWI5 X(m.$Zw92À-eօ΅mG%HYH&X2\ë.ڀ~[4?M!z qس&H"O#1lq2mO fl2C;Stw$ـii/l\J@\r,dr~aD@ ƪNe6Y}#BD#~!Αmِ>02A x cPH@7TȰ`"Y}J4;2y@C[-dl_#y3"6k_^1 Yg .$!`ݴk0˘ ce M j:&2 p0r!=/$Ps>XkXSBԣӣXE}5gpa81%H q&L`l=c_үPLfpJULpn14XiM_4\?(1)׮įpV՘KB''#fGmݸPͻvq&`0sBg.1h1Ёj*)ŴyO;=Z`W\k*J~->k[ HO<)A{WM{4ioD8i[8 |KLI?t9?2ـI&e=b/+r&@p>eO=/A%$[$$TpV-.oڲPsT/Xt )w?:/ȋso'Ɂ',HD@¥ .p)KA$\ " R HD@¥ .p)KA$\ " RDP׍>hێqD%I4S ݗu6anR)UݿT ;󉀄@$\P10[>nĻx y!N* Y'`v&MUNaufpcz"8H է/x<5NdQya~YH&~\ruq'R*UT9^G=i?4n>t=&*"Cgph!XuX7KnmB3Ƽ`!0Ê=UlŋhKֳ\ ɼ5BU\lȐxB+EpwI% ko@beQW)[:IaLd,vPk 'nYuV05>VEVs h`uȐO>@㉆w#lG$ p:إ,PI@ߞ 3 GT5_6@@  jah84_i؂jj Tk4(81 Υ.(p.?3n4Tt0vb0r@~:o5r 8L|ppG@ ƹjfS+Ѓ)aB̰Q= бmڜܻw[<͍5PM_\M7 :iۜo݁H>jwH S)P L] Oi2̷$ՠN!9I0̩p9"ܦOӐW [cpq.dz~gCLRG;6l+թAÈ51l~2̄qހ U A4wC'?42s6A<_僜4;b|5N~/0$>ve!rʅm- ]Z׹PnGa0w(.u+Po/1KM:Il^o_#7  R|O#'s)Zg,mGtfI7s0{< 1He+9Oqyx8N%n OB~wH1E~*Y+p\s v讗ʘ2nx 2v90c`mgBu܄e'7PIv?J+!,Wn`*LSvy *_gv=IET 3? (Lwogǁ\%_<Hx!" $ H }H |'sm{xnS x%'Mp wIRm]~cH0*X٩C0ήy}εwH9H;(u'1tO ,y\@OI=lWڀk :u+R)0ٹi͎5(]bԜ!`)rEs+V\eý (ŷPͮBHw-4 n(_VіpaMTrP { r {EQ ?TuA(m..(YJ͗/ *UYDq6ns)Awe 8蓼a _z/LZeV*8&OA-Ed,raޥPW/u ^%(񦃫W{t>? rg}~Vn,WlP.I@ ֞ *X+P]/J4L摣oLe0Dʛ.{KLPaCkdPix;J RDez))6Vb3`PgM?KTrgX'=[y 7쯂L 3 ;j#y vOS!76?vNHoVW>ĢȽ[ EM µ2^y]MM(7B@W!`ݒe[X͑BbDĚ+팩M\F$`ŢDg1䪊zuߪ9br\k"=} k(asi~ # .`p'K@i T Fw! &#1j'C#khZ-w{qWEU7@'b Y(/ ڿ)om # ֪y&P[, 6k}@jB$`NR:Xb8%Rﰢ*XC֥20FAxBU*8~âx"rQ"6j]y Ǩ M,.{@t©E{8x&F=KЙ2+FyRe0DX=z+7 obܵmZUGub +(_n!`9>j@քa[,PM%/ңbsTX ;+rxl*"a|OX G7*WLmʉW)b Dt=wL3]-!g[Vpw:ֽoԸ$Q$?'#MiLWv-$`;ktF8$ԱYCjբ+ւٷ T0ذ`a~ڲ 8^Κ7 BK k0/ w]8ߪs}poG"')2Tp5U 1w+2*z>ys5,h()B%|Vb{:rHBc[+)?کkm3q8#" ˰r}ٞ-"vx 9{l,Ĺۼ 4ڨzarOZ_*)T6=~6ml# +Y [X;z붯Fp!#M0+M8fdܥ~G ;V}S!2k 7T%ϱjaD -X/h+o7߽55ZxT)٢\sw .RN2{JJ}桂jKƒ[@ *ɽ[CA<%w}| A3@!hVХN>lVLwZO d\43?tsi665m`s*4]{1mALn-I/SיIkTOdǘ?lU%Ce]c-aড়j7f=|R*S9^MgoQ4Y-ɕsYLVWX$ q^Tedk"Ǭ#U|\{D ^v+@m9d9;*;,Z,[V*7Aq>sCB7=pxY@l|]L:ĽG&1tFϵ7pQ1v`krl)dSJc}'Jnߞ-![pj>&7k>"hb ֩{,a^'yP“y3- X k Qi`SI,Xo8-!Tpp"ኻڀU-_<$?kNQGX$IDAT:o6zF" XfhQ %` Ha*jZ ku'x' zmQpdB;Ilj%_9M||9k!'! `g;!nFF=Do\U@†+Ȯh!/kg" q{yw5L豀'oC0x4 ^ AkM26$jVN^f֍1E1*G5^6Ur{-/PO; 882P'Ȕ8.p84&Lc0btfp[dVAC?93<%ڷ <eIYCjWfc.pwtKhj#ez@f<?105sc<ۻ9!aB+1ۓ{|2{7hxVhQDW@0mp P*G~* %Nĵ,_R3v!=Wp|l:@@vO<JQ0NZp7#`]aY J yz0:o8T vs 7l# aQR+o'PzeѲÊCE9WJw %zU@Ri'']wbA)x)V ]I%wCRGpA_\$@h?RBW\P61Ui| ,ks4 A8uI雗64pi[ l#/U|}G$[A6 8XŰqںok&!8,Gu֝;C|J9TRM?M,f^Q Ȗ%XsIx3xBngjY@ܮԶ(e@䁘c/(8|jJ~2B% KorLr^gz0 6@r!*X8Nnקc-~J0 K 9ã)+ !gz.61K@+Cj'Diμ54Z|N!ϸUpŗùŖ 9b(2PK /V/ZVx+ D6\"83y_3aWk^֐Z#wSPnޡDE N>O8!.AWKVqJqY1}xk6&O -/fg5Hf>1 4Ø}6zbJ^RH=*f4#TQٷfiP3cmpDY ]' ]ft]|UWUj]vzx/VmMgQo7_ 6@_uv6G@? .fmzѺwRI/TGl\r8Gׁ/-VB6bCMw MnϟV&3ׂSӻ尌%'B]l{R7QQ+H\'*xM~Uӳ|Q'?S*h]rR2AT&\hT{\ĨMCenB{"zU|e"փ0N1M8,ǐQ+!jlWdjbҴ+`*Wip*s|$ zC(a2ـFثb]t,E$戀qNwj0OAQBo0'D8Drr`*΀MH|7"92M1 | NSfB LRǖ~.v|5N/| k_e`0MgVB^ X90F s:MD*ݸ+AIp8c[f@% @_KE#,Dw d{z#r䔎j\D '7#M>h-ո$jܟ_s TIW$ R)) H5I76Wcmix5NiӰ DW# Pamбdf\<*D7# *8VSbAt"ˑFo# Y`U ~5.X !\CH#؀51x H*8 fy0 Nl70Le"݇&i$`4s@XbNҁ$ixzE4`3+ DW# ('y7j^ڂ|b%:%isB$((HGf:Ʊ" jHisBf2 SWA|5] ɜ5sW6+ԤߌC 8Weã, `)g̀H|5&i!-9j_# h<!w(!7"@f$!`Y]K4eFa)`UlB$ yƑ,dc9x)8$ 2g L9X CӐ[7:\dxah)HC@,w+G`%JD"૑s!GWk0 ∀oF0 v' ]0UmH JD"q v T<a_4* 8VψaB*8|JZu0/؄DW# PpLwSu=#DW㠄ԶPUuSǰoL"qlF4vU>D78`ʕqAp8x[&6^Zsaq"RF>JpeXGV6 팮Pa*SĜ1pH}?"ˑ9• j[ΐDw"aU5 X8Y!O>qdC0B@eqȦ(7iU-&NbsFR$ (aS ށgHj4E58VK ~3"aj^đ^0IW#B@Eq"@jPT!`C x~'\Uc(pt*$ È2S${=:VH J—HH䄼F-a3G&ƬD7XM}g\Ĕ=~C|3 )-67r#)bߌ@ωrE-|rBތ4Tp|B\& f\u 08nFPKD7hByQl7XJ>45kjUao%ձ,}S$0 6ߌK$6'(%Cx4P"L)Sތ4$p)KA$\ " R HD@¥ .p)KA$\ " R HD@¥;4 ړdIENDB`DdC! ssf 2 c BA2Drawn\SOR2.GIF1bEYpzN_0^!Gn-\zk78"YpzN_0^PNG  IHDRCtsBITO0PLTE"""333DDDUUUfffwww{ bKGDHgIDATx낛 FEEmˠ油T|GM] Fo8RC 8RC 8RC 8RC 8RC 8RC 8RC 8RC 8RC 8RC 8RC 8RC 8RC 8RC 8RC 8RC 8RC 8RC 8RC 8RC 8R! N]!gVЭ~hU~ZۼCCt[z vC7,uUtwhs]K}R}9UO(! !F|8>#!>=ph;p8.p8R)2N뺻`{?g):v]EC8T6fW#R{B "b?{Ƌk**"HkF7ZVb&jr[YV$ I;;4KeMe]M u}C)4;RI=YcԉC1VP轢Bc#靨īJW0کƇ?C_7rBG&b|^xɜ>j3ubCsK/+ M yx쐏p(S8M5rlڱvR+jyPI&(P/0mU7:r#iHKY݄mp B8З=y.^69}¡tBew;Ai; 8T={$#7G߸魁C%yr}8^iG/Ȟn0 !0Vw!FSbc{?tqp>q`li8RT|NCJp4'Cx\ /5p:}q<3p9:C|!G!8d#Gs(Wl8ǡXq$Yeb8Ғ=~-]8l8z p#r(됙&Z!>:D<٢kb&Z7!HTA2Wh!dqgc8Pa4HG_v"#v}ٗ:Tiu"PI!> wکsn ȗv(ta78CΏa sy:T6=ˬ&!T(,؅e_W}!%.!>vumE[ !רЅ!F{ZU[j\@#:7CK]X8tb(م]C=@#b%ڕ˧4w*va)HwQjsts8H&taB+)舯 :F_J BhLF8ttҁrVbx#Q pMc{UQb'ruaD@p!>8d4!Nԅ90C~&ٜPq!?Ц8؀C|p# U͓kvV?::QMv6SO0 [g CS4;d9S]N}CAbǾLgUC}&z*MV]o rqC +hB萎SM m Biv]Gc{'/:v2aO%\@. l.њ!Fn[,'P&ȇs 8ǟS?l_ lmv(p(Q5o}ۜ) C|6_㜗 8pYi8t!*0)QԼB; ޳# C_eA45yC|+١p⢩*ηC\zĮ❘C|;"!_JE; e!>r81:/YC|qhT4}D##C,w]V[&8GFFVa*/1/ccv4j5[8GN")L_`]?Zp!U'mt5 8U0mcZMޚvKϤ0yrԗio|:) J4xSd7Cb1ۡV&DB}[ƗCESp$sŌá_U̡˳юӵ|l`p LR}c[YnCCܳס>kU CzدC žЎAJ,ҟ18d?; SuGpN|>7T#EJj{;R +)G$WIo퐿/PhZ-+c nt)? -qpVv_sl +߅{Y{9j6|(mc3yƦ!S(Ctb98D1HYuez}1 6H!,C;F_34ww4Aذ}!^TB5CUUKlh[bV!U~4B2D -<q+Q;K>bB;;aГIĒS68Whg:!n%[F8r6O18T@Zz黕bj~4B⻘vjfG`p?^);w6=1䠵sځ橿L!Ɠ=gD AkJ ڄX{1Nޱ˸{yPOM,pٙd_(tHQwSD&ͬvuJ.dwp g4wRllcC0hwk?{:szQ"#P_U7v+>QUw3(Л8c&(fV[BaۍaA3a$'έ:ɇkj￵q;Zn(`P,q}Tn׮Uc7P5l6h*xXɳRp_/n 5/ѠZ(M.rX~4_\W7-^}IGCCI"ZUrXjjd"!S!Op73;9ԗ(qCC[D>)n*ayAZ5;d9mNUk8 2DX^ԢdC=J4hcys:Z8ꄨܟmx?ޡҥ?uh:<بlZ F1Dk*4|.PzvCl6h2讇%_e\D-B-4Cg|P Z\*z9:d 4fW&o9/E ='\Rs RP +!bJ??TOazˋ_p)e+ç 0k6Ukգn۲:=g<8te⣸CgmC;@*p~~ú~ .NOq:=p88tG`xy#Ss3Pqb:#UЏV6էn:YE:ӶTЯѶz9'8\]12Kᱽ 1hGfOc*= ރ T&2pږaξCtrU-/x( P_LpY$8⣐Cި b~l?f)?>-Q!2H.!濆HI?|8G`~r@ϫ !>8Լ5eDŽjpf\SCs6RK(ixp+dzCҠ0K>5}t_!}!̋pcj!{m!>RȆ=Ap]r $ٍ );v~88r-ыM/ cp#=Ls8HwKn}\ [Ϩ8Gnj!.`6PS"pT38h7>!S$ZC|qKq8h2q^9C|9[#ԁCAN -*}ppX*щqq :{sm1 5ȠbRUR/'JLC+e~Ȝs+MtUEg\mh߈6=wG7CS9juyE4BE(^ɡIV]~ͅuA"ME62unMt>N 9A`s_:Pk\In3ўO[4BƘ$CdZS @1 HqYv`l?n1Zc=EwV̡ZTD; p&>gC A};m.4'k|lA !&C|lcl8GL}}Y>?Gp53Ï :1Ӣ78ty30zl@*p$t각5b$G2!>~wH?tX#O*:是 sa+:VGɱp9It-pLg-̗A;_ЩC|t?P}+8GN4:C|tDG8GxQ"#T@^!>Ae$ <.}!Ĺ.X^1?V']yvCķ:a:I{18~\0:3":#^H 2:7AL# =CmKK{|40C|?^vA;=\xGM;dYBSM 9"8H1c!_]hա̻<|gC[p1Cph ͓B{pmC#lx+p}rSSSE8(C!_łC|P[ {v=p( , ^:8tv=h/q뢄Nђ}<pC.;59+8N-PV8CB,2'6P`CفCOCx16puh]l{Ws; 7A Z!>CSP j9_A8C0֜Au1ߔ' 6ci,吧IbY>rrӸmxJ9D) fѨUvosr&af[C^RФ}P{+>Z=+h{-7EuSTXUn?Zy^DDGFvRѡWwMFFWmPh'>;rț~-[]o=&>x{Lvh:Ϗ:D/*tPG"Ms9wdqJ>A6tg(ulOC^Rj| 1 u]N>!!+@(ca_ [AN%u8Qۡ1΃#+ Pi\ \GY.bosY.J\/U9CF9Jժ2^5~%Q5^1;eTE#]VNr^ phC^3DU: ]"Ơ9urnàWyg\yg!qIOyKW^7~itB#8ԇ7C2ϕ0+UL,wa5] 0q(US!7-EKn/WH]̽rZy`k{rherՎz ySx|Y]zxvBy퐟[*@(ԜOeB\5 @U0zJӜ2{1OL] n 7fl9mEzOr\RdSF/~'!OKC- U;#X_5LW pVxn2_+Up!|]w{>-y>.d}fO?ߦ:Rg_8 ! ! ! k۶{υ:2p6Q:y,G`Jv} up f$mchw[;6}z٪;UӀC/!_+E^UM]KOb\ -i^68! 6V2DGiB6O>^N&ZTF?'9cqC/{xmbY#jDc\vܑ?EC/2JUR!H!/CMLݨއ٥VCZ9m:CbL R}:hdcZ[FZLP+tCu}lp8'4'm߄ouLK?ͼ"⛟@*p@*p@*p@*p@*p@*p@*p@*p@*p@*p@*p@*p@*p@*p@*p@*p@*p@*p@*p@*c½IENDB`}DyK _Ref415649609)4DdLt" ssh 3 c DA3 Drawn\TORUS.GIF2bm3`"GKI3înA3JQΊ6]Sh`"GKPNG  IHDRL`sBITO0PLTE"""333DDDUUUfffwww{ bKGDH IDATx흋,eAmmj@Yu6VTD'PtT`*"SL"2T`*"SL"2T`*"`ݧwu=ħwu94>} ?UӧLm|~VWi.>_`ҟ>_`Le:!] &`?}S.f&f>}?w?zOƏb0ISFׂ S [~Fׂx*V`a*aZ05L%#Lrxѥ`K.a*ӹR0u3L%u#(L.TRw?K LՕ`JL}U`S-?+0O/B0T–Ѕ`RR%u7.SSB0'_z L'Dq`Z8F/y&zV<]U%W]$+bzN4ҭ.0}Z ?̮Y~3/,D-Œ_+x^]WM%u7.w޼P̬$<=:a*^6E`E[Uۖ,LSL"2T`*"SL"2T`*"SL"2T`*"SL"2T`*"SL"2t9[c~$QGC^a襔EvR6jʶBOUX]mk0ET:}L֪c:m※w ]>mU!*&ƛ.~ڜ }#I10tE= {͚Cz輧%* Hu!Ln&)߱+z0Y˙l5{>hiͮP4:1LfmX7}6'&I}p?:^q0ipŭNztDI@Rc7z׏)xn #bI0`E_SN7J9` /)J'JF:Ϥ{%)*BI7Ar@t8$ MX N:LRM*mB7Y6Ct{iBj{ @i}&򾤫58u%`CaO,MJYTQ +;LH&baP;eɶcK(Q0A&858*+L,%W1N&7prT"|ԳRppӺs\09[uN{K`GhM9C[g偩X*'bY(p2̹ѲD0_&V,•PQԸ xd/ݚ2r2dm5]@h(^98G7 Ф2:IaR@j/0ǻZBJ  {~+0}7m wYQҜJ oSu4Ja)4MJ Np ɿ5M WU8J `) n~˘vY񓬝|&K&?u%S)%縒m'f#t4Ɋ; ٟ|fqs '²#hbAu ~w| KI` ew>z1XL#_-9f/o)5L:0ilԈ?3&>N0-9cqLv43y8с229@*zSĹ4wԎFFd=_yL0ݺBT0u,&I$>K;@Go`j}k繨H{POb U'Xt".ݶL";i'e5ؙ80=%L`zߏ<"_1ӶD='"D;(2lΆ<Vrȳ}[薳>XnPWB+0 5l>0&B*,4 9.pUrmw]0ݑch&5ο"&KXrNcSH`js,qř -u7+x;̱y<%)E'p"a6Ư'0)XP-V}ʗj; rpl dLr?%(Sokw9Gr\3eZOxOI0iB؁n-{z,űV'l:([*]#F a$Sfxx܉9_ڿ |)֐etA h\0qc`F~ Q\JN{:vt!`iֽzr]+y9{Ӂy&5/ 1bu 6s㯦m1/> Qox36 axRT_W%_p %0i] &~5CP#0p7U-Enjd/K`|%n8r=Q:v dzp|_p#4093 KIZu7+t^a 0u#~]r/Τ{{إ#|V#&jg1Y e(4H+!R7C'k̈́0Lap}C0 Dxmzx_ `fz⦅P$Dr Y8 t+|Rg֜2+&4XÒl߳5 Yde@ Z q V0 aI[1qPe쭋j^} S.A2ϊ˴jq+vJ$Nt)7.Ħ={FR\#ovEd^H mn*jίm|H& [`C{-iWmQLIɮ:Y*`{`Mtm-:,_^p'U;`IChyy[vV~]&Jda`ڏ "{'Oo<0, WڢSb.[L0a)alRwat2"u9L˄1DVe ^i&脱^ډf ZDҥ6¤fs e 57mKЭ@0a20Q\0aB0_LT0LK`2\fLTaF0}x󥝛]a_t`ޓ'G0IPDPLa,Awv ߷^d9'.L(P-NiX5d3L]p&hL!L_m5A4dy8 agΦi S/tIR}h, G?#ESil/D%Sh_בɫMÔ0 ]@{0Q&a`vuln>L$1&)ai{[WLt&a"ɷ8&Tw!㞈bnz%+.0!Y*y+09 va{Ҟ&/Vw6&wOcqğ>WOW6Q05c hw" #wJ4G9Ts#Vbiݨ>LR/:ua3-w 鷭e&OhSQ{0aV]Dkly_lLn POuXɫ(ΑS?]ۮ1+|nGpڼ=LލݙL/=})( LR1*pڹ:E??]JVHW[l] 9"QUq>N_]׺yg _'m?IξuQ?LF.ܸ#QHzUSBz_8~@?LBy14]B^-I|&4!3p0E&.{\TV;bZDvbݾj#V#D2Ot9@th@7 C\amPXT9Ok%8Vɟ!pL!&=mYdX鱏o`3J0 ɺ?lY9"5ś|[B0 G,sO,u'ոgɳ-8Ůgqٝ$N)g]&q>bzzT& fS&ϗNP0*L 1X9wʵ7azor.̉w&IM',fh2}Y`K1+XnӾ1 d Vqb߂ 1gA8Lž [g.q {f:1LCU[e@C` /Km`{n+L@t3`<=O:LC ,8tM7?l (LO=)->[Cu=0a—s`ne1T{mģk& #D0Dl", &ׇ^ֻ\< ";ޛ,bEӼce3` o^Xs=_kIzXO$az3L_#,}cubn00QM24eE@^ =N˴Q"^V4w'S\}[~o|Y!pA.'L:> ոn`z1PN⹲/Jq^!ڡ4>y LDSd<0ajONV-EIm ]>L7Ne9mY`ɴ3>hP>!u{σBD1e)"ߍ0g(eзQ#Z9ar\,0EuѰ!N.˖lOz^i`zM?"T@*^a&z-xonp0=۱J 05oy0$5Mia&C E'v!aL=IaBv*UB„RrB&Q5[rgU_+$L7IȞ2֔&\{GJxHѐ"JB,x 8fԗ rӛ­\VBZE._pCÄqҥsdS)lCEEzÛOz,O\.Vh-]>rOuϓ&`_\BhS0iҩV2/ OB:bB*HϷN]3 Vxp4D0uYR\"N}tLIDATE^&44E+d-rM[]n2 k{d8֌&7D^n:2wę&U"k/ kP)\}=)&dN"/ )`Qa03v4]lFyLfl.a6%tUuަ:1 ksO?랳(4/MEC}ݚ0&tN1;V^j )ASra³,70/c`B@ȍ!u%"0ed25VO0^ h`;bX[x]*ya09CN^D IU>7V!yfC-$ rwnmsaqO׌Dk&&i&J´5ClX'Pu%Ц)d@ BȼLj08} a#L:BaBW[Jt0%aicn`S#)&d7px˨wd0aikuziPʿ߬Ւi7{z:QpLεV>iwam :_),I!g氛!Pƺ)εUUf'+|; 𳪇wk.M'kAz$4l'_1}t lӱ oy*` /9Pnc `Z/^a]DKֿ>)>Y|^}6ͧm]pЦA!&Y AWQ7vTUn*;h̜ λŰaV>Ǔȡ> 7{qÄ7M&l;5 M$04`X/Ͻ]0k7h~Ĝьpcճ7cױfnIld4cWE7M}XyuESyFxx ӔP6tmc}?\_<60&7CLMɇar bLx_a7#L=edxݰ| + ݑ|==M&kZq<(L0mj#Vtgd6a28I+?>3yύKQ0tÃ0A/ܰ'E?* i2)Q%ELs<\YGԹK|Մ:RY&F9GAڈ4] uG`{#kyL}S;>~~Lv6- 1&'$ܐD%-#0AjЄ kW ie6$>Fu6oa7uzq)A6AbϊoܤM{=L)߾䡁Pi LeE,L=>?-J:a0c =+96)1C\dƷA| Zas^m⌅Ɋ  *Uq0A6Q e<7`S„rx4Fֳͳ~^K qw<&ojt*ca W - F&mNnشqAv}z>flt;]j, Ȁ~Oʡ'%1?UG"o)Rv9pSE^Tߣ.lMO_o0߷x,z~ ΣPw+x.P$M7TӈR1C1O0n7 bB`|dN)u&:5~|['-R$J;I ]Ezpt cFGF!7?2),1=pIaF%0{Q0y:E4JR ,:SXC3%w&+o:S@G^nݛm$` cN=OaJRtzyp&38nRAՑ{a709 16L&o+GiꞖWVw5l(-?LJ))؝p -&>0%먳#;HλNIn/$ad759L7 ;ZAҝduK>gE%˾כ.{$*_kuZ]S_aϡ*> nՎدCgYELL1R%+z)Y09c65 NMܧI[\C$0xMSz>vXYFEUͬ%귖 {,V[7ri')53||DSL'p[Zu &wyia xxIFKw;DsJOE+ζ`}Lnd&g~0)Bj}LarLv@˸_rԗ+B`!&Kvo~%REځrT&h5;y/" x#.# &7 O}FqI8eޝA&|s~{")&qx$410K0t&1u$0kfmIyYea"&tK"8Vnia:@()y&@e%zMbZ_f)LhA>`3SY`4ei Sz$_)'L<6wJ hT^ ,y09o 3VZWTf tZ&[ؽ'i`t@JTkI LIO 6c=彞 &VzF L~Iƺ40٨JqL7#ݼ.A4&MQ(c6~>Tދ09V}cd'a{ȯ4}Qyq,4 ҇=0iq"(JqZGSs:2ov,Lʼn&@CZ@lK2tClȼTBPtqwxgQYP &Cmpaʨ3.D%'^6uO<_Y~>o`rG]2ä9`@Dj >B3៪{n}imO2i?IadA1WuY`r/ HM̀)Qf&(<㎗nn%/rd^;w?SK 1$k&fbzH4&h]gXŒ+HWϱVǶN[6.\:O` ~7U/=S^;L~ k_EXT0ݦ[GvpIwD+Г΍Bp7/N69vbwf3g=T?AKtQų++uJnӈp)&\@{tO. o%xsʧܿlLt6 m8SB *:H1A~cLӵILKôt]=>`ZP2|`-x[ dˆPl5`k}>lpf{ϧ&1{a&[{~&Ɨ3}&{G>swk`>y3M`Rm=Y_ hYI nfMao-}_M{kY70{Xi?d=; ~_i< \N QJҙn׼e퐠XSjjZ&umV!04øÚn=`e/1XMd줮񽌵moN(Tê)6ks_hq@俤BXށŸIHf~DeZ S!_ɧL1p Χf^K5bc1m CS?x"h[WҼȫTDS LEd*0TDS LEd*0TDS LEd*0r0(]ϩTDS LEd*0TDS LEd*0TDS LEd*0TDS LEd*0TDS LEd*0TD?P,uIENDB`}DyK _Ref415659046}DyK _Ref412632666}DyK _Ref415664580}DyK _Ref415663975Dd%f 4 c BA4Drawn\csg1.gif3bݣ(`]n][k$BnDYݣ(`]PNG  IHDR~zsBITO0PLTE"""333DDDUUUfffwww{ bKGDH2IDATxb:@1cn6lHϽmʰTWE!>E6*B * )*B * )*B * )*B * )*B * )*B * )*B * )*B * )*B * )*B * )*B * )*B *Cyzb>Dfi@]Z&K}iޜfmt @8ҵ]o,t]pq4i.i_\Ʊߒ/ʛ]'X c)9kf~u!kX^ _ߖCEQߍopnϧ|rYN"02irmrb2۷3/6O8^IUfj yҾ[M3P}+fK8>2<־(l,uxq=Rt 5tN5`(0B\{_oanY1Tnyx :H"`ۨ5ʳ;p`hҁ;qϾ""P85/Ua/ zC@_|4O"$q!!P=oq*㇁ Cw4 `a~Kť;ϝ ӯrADB{%;ɛs o3i{ǚi8>.E;s'~Mt}뾻bi8+\Cv5S/ӱ$30' V}l0DS30Kۑ !Y< <&,hs8Յϼ5Ly|3a8&Sb/KO_& x:/]{ce00g~KS xN3C҉w$p:[]ÓgoI;VD/y0&I/c; L)Y;]['40gnK U˯V몚0R L6ęL@ל߿PlFneB*'Ͽ+-Dz|d(6sP20Gl}`{)UsP)>7 6}9tNRl%B{n$Z 1s}=PP5e`Z)z|G0<$YF$(tOms PNhk -ɹ e R 8?'\12W@F#@TZB@Q:2SYFv$e bF'` O͛E,e bFPH^z,FD'A_} Q~h 2:aXk "> X^ds#T I@) ͩ@[$]BFC/H}B:N2%(aCPځ<؞8yp. ć}W|ч#b(&mЈ}G {&U}.  *1!0^@ ~VCŃ.-?!pj|w+w?!pj| +`ohCh@ {1~ (dlH-Ƹ!Q:0]\ȒH ҂\aؽ~` <C% ЉiA`e:&"?\42rӆʸAAJpp AEkD8H۵)_1C Y:A8p o12rpt\@!v|FDi)@N@J8\XQȥe鸯cC JDcP<}"d>P#!c_D+d\A(> )-4CehZ  (suZe# )>P@!% r*-?PȎC_ƧO4^"&"0|N"0㖈NR.TRj |  !E`VEiF_8"o a]H@Vęe Ze&X9%5"z41s ko! i>76"UI\!mxa:4-擁' ƚ@,L<ŢvHTn >z[>GKX5Vj5Ki7{s֟-}-]`'=B$ldzd wn'3L2vBXK ˏ: j8 .K@no`ŒkWͻ2p%" Mv+.`(Kg QU>1aq ˌ&pY[o(Zۨ^HU@4,[ږMh9xAe hnhM|r07ȕкVj-Gx^Td." t!s|S83 iȯu i:o vt x,>X N.  p-pr0hGu-{ KX NރSx'q R!1* Z|V;* F@Q?9-q_3xoMl0 # {T@DրQaGD~ E@ tr)fZn 2 *q2 C GQr `";VD⸣bp_0wT@L;nt;Oؽ;ގ言~@c ߐʝLoHeht#;r9%;ޒ/e0G`M@ cNQ227#7_#p,2yOh⭫a "5[;QIƸVOe@Et!XjUO#e҈[6%+,K CQ:!q=( ٻ)AΈhC`L\', L-Ip$;'cwF ( 9R$md)m(&F^dLNbtBe BCM^5#Z@ ~X^g5$^@ cd!b(' kB!L"(']y.[,0 rB .d%RcDЇ@D \j+4P |_(q6IX+M 8"c;FF6.$}lЇh +$/}Ȣc <: !ȥ",Or ưU\hC9@.2C\7FBc Ixy ]xD!Z9|: @eЁ`@pD)_.Eod$7Σ VJ(}'kxp+Q`BtlpXw2Y2kRv@-` ( |\X ]^@ Sr<@/)R>H'l>K {;Z O1ӓ@@)e;'5` 4I:&P= B 42Pf_4J1PD/χPDL"2 I}> §7:ם=tmÀ}piBOo}*)K*`0Qwjr&TwwNA}'60 4vgv^my잟8xnJ-I FsH. ll k/,:5U6۞kuևjLڦjsD,mtyO/y- N&<_9cM5mͰQK|p)&cn oEl; 1 wݮ}SoM9 `/MmiKN>e}fV+g;UOŦaL4\w_Hu0opKÅLH4."^iێŮM S^ːwUhYÓ?}WMz@0jzp; #{4ilmaY`nYlW#׻2mJeioq P!ߞ~:%cݹKX}?yܖeG2>]0\r,7 ~ oooTuo w>֛qu}s?~,F@Qޘ|Fnnv7z릙R{di9NSIm( O?yKi?y?n,-Q"pϧYbXs * )*B * )*B * )*B * )*B * )*B * )*B * )*B * )*B * )*B * )*B * )*B * )RܥOIENDB`}DyK _Ref416092785}DyK _Ref416092921}DyK _Ref416092986Dd%f 5 c BA5Drawn\CSG2.GIF4b*i,^<--t~Z\_hy[ACr|- l `kh98 ,`װ2B׹۫En {O뺽:/аnIqx,uashXܗ{z磳 u7˥}X(Dϱ5<N]Cd8tQ: #Bd-ˈ2(<m r7ʅ.m8( ȷ!}׹-r|g ֣̦̾D-kh~cZWi/ Nb':uN{P̈́r}:P;p'Lz3ۡY_l2+O:d\u$,Mzmnц|xA6Ko>ע$ Ww̘-ǡW{r/' |>[̽+cNB\{AMׯX^(fb! .#s9JW QF~ȡ`z(.r(`65ߍGt%HqwĴyx|!k`3p ;*) C`PaNIi>/qOD "N?sDQNM $E:6Y;>T G'/)݁nJ>Nw" lҎ 4ﻁgϏT ?^>Lc`'/)<x+} = L(~{k"]N'ޞۿ/_^8_ťx~LK<D$$h}W(H@%mk YCd i\ {N V=OP<ȓ0Z}(8 %/lku|&aRתqeդsQb(tJ[- TfvJ.˿J0B'-[~Ԩ& 7IN@e2#U3aSJ. 8)E&"oԲak~ u !GS 8)9-#$Q@"!fp~M*.oi"GiaaxCh\JHc>?3;_:g봌B Z6!5->&$ 'Ww:v庖bC `4Nk1K!@@%3h׽ hןPx͠-4 B`t/VItC5 hk#ut-ӽQ A-`W+ qԪpS}8k U"+ Ut4PkD^P6ӶaDop<[&c:km0fSL\'m5ȻCuTQRP /p^M|شZ 8( 'Q+Q:z\ƅ )R4躰I`p#(IBB( >t0[% ^QE`{hbT2$zήQtȞ@ULf"s\7E ثFr''5 E -xJ%EZpot5D-.]!*A\[V"`(:L@_]C#3Y6.1!j`eh $$ږI;@iG@'\{J]7}aM@+bT<S6΃*dO@W}|ht[0 <6/U5tÀoàte €|3Qq-ٮo9LH׺`ʭDUҞO@qŇ4q: ae]TDS0➾2 j@ f`!UbsF}\&dJ啐gd(r s +(p)B`ӭwq$ GgRIq-.,}t&S>֊jW*!pm(nGC'5Q*ܟQFiLC8=T4׽ Ҧzĸw$2aM ӗR\.K!ZB6x8-1e64ߙߎu[?D\ \@{JQke 8-c#/j֎"X>O\K1 $ዄ(ly'Vy?-߅DHhc¾؄DI N2o!$Db (]tL@B$c"Jt)"=~F PK8ϛ(~G UdRV;6V& pVrZo_0T@W+>+)0T@%E |~-N% pT7^F#}Դ\W@5E`d^k+Jk2HI/Ԓd0\EGw`%8p3jZ &.C&{̪d Oj.AL\֓jr(4G9XFK{d8J%p1ނGyNK3pJ^~=XI]V*20]8Ay2 \ %b+Q ږ3)!`Q!mH!`ІPŔ Ch4<* QCh/:&]hӧ'ڢ$F ҆ 6WR&dǓqhbj g#Cfh/jYE0^@%!Zf00^@=!*0~B* P]A l`6\{?Z S@- %͛۫&:R&o' sP@@/Zަ%`Ipot-- H#eS/;4& D^:%}ȟwAY!r "]f[E#g>A$ !*DՇ4:fkC$G+_; N_q>[\ ] oE^'`0N%~-@!ؔsW2 ,U~_h_B3U@fM"N_>z,XJ3YҖXhژdpyG~c|w71 Yȟ~<^^AtKyUQrzrۀBBD/te F!=UU#X% Pװ G<27B6#se)qd:y :?{! yX^Տ[e'#|YΧt-JC~$ S13&rJ}qP]г-UGG%Ǥj:箩 !/96)E@AE}y]?yu7")Kζcoz[˕: 0f9W$= ZxC~\'k II`k\K -$}Q ym1+NG=`GNy%RQ7_{c:,Xʇ0٢(\@tL@`4X1 VL@`4X1 VL@`4X1 VL@`4X1 VL@`4X1 VL@`4X1 VL@`4X1 VL@`4X1 VL@`4X1 VL@`4X1 VL@`4X1 VL@`4X1 V'IENDB`Dd%f 6 c BA6Drawn\CSG3.GIF5b8_W_9snǭ: ? 8_W_9sPNG  IHDR~zsBITO0PLTE"""333DDDUUUfffwww{ bKGDH:IDATx낣F$;DB[=u`Dq XXXXXXXXXXXXXXXXXXXXXXXX hGN\{Q{TY<>~i oяk~}.|.3 [ek K|=ׯzN$2M^4|#gї }:-peEG&5YnQYcf}ԏ97oN!o30y[.Zv>1O!9.7Ql:jMzp$W:o[sB/ү悋P_v X|o/o*pZ5wt7r>?D0(=Y(lJd0K;\v(!a>ml~'0.V$hbC@ma3]y\) ?.'KRF5 QEbghGQM# hbQ M@ XB5LU `ZPj {S9߰ ľ)^MNN#.)ނ['>؏wW8CT~_O''{ƗN!\}]i03juopqS`+$C5cЛQAH(Az,8CpOtW? {V `'D)tJ "z3-dme+PX.*5nNů>V{pE/*Tzn|m˼Tza.8> /YUqVmѻssaFԖtr`0\L~SOL[6>T˅bM~H+/6pc}+R SqXyFa `V `V_&ۦ,oO\u`>u1N+lN>+E}.sy|m1C<~8ϗ |]0*=k= @tf-SL& pS ݿh`iN ˒%N<tM,XYZ@0^9d~PuQxCݐpP2- Ja9 b9e܍;ݸn*R.v-_uh4$Fո4Bv!ОsݸY‹!Q B~IOe @J[!`YAN((9?0k BG>nZ;=HB&r v6?o!p#˘S\|7z .>GQ w} | !H{V=FQw?a, `!p$"~}m% Þ#A!(䥰7TiʹI 5X!G1 Nu;!h!0_@):}cuf !25lON+&? P^Сւ\_¹Z!_N [3 ܍re4]weYˈ s-W@?XC4YhL( /NkhzSK.넚_ܳgCB hkgԑ ΐ ~7 kZB zVcQ /R ت'XO+ IZ,`;T}kG@oH$Y9 "TcpHH9`@@B*'a# sTqY s΄\ 炯|Ga|,|,|,|,|G_vF" sEvq7+v|]FpRo!Z;)'$($>.L!Ōp')V1 ZD@I:BPSIIS1vV\;+ΒD_5p'C28/x'vZDNwҥ4,5VMI,I& 881=4pcJi0qH׵CFH@(t+~ ?`I) H)' 'C5FD4 *5G 'Sӗ^h'*`'A"%L"Q@E&? ljxzqW~(%LZ!` iCԣ;SdlcsDRWɧ  o2c2R)UEWwZ!tB'kB s^#FJNNΫmHP̛6Y1XHN{#FTшɊb"ѩ5]@!,%tm>.yj5=D 1XJS20 ʜ:"49N|M\'qa 8TX-c< ܀)eA LFrfe 6/+GL #c<PJ˨eȜrh q:ﭿL5^:!"י[2V;3 $,W@+^ {҃0Beg"$ ]f (% 4j1BJ-fܑZ [PN%02 赌u;Y8Ж` :1x(ft]d#lf1Oϔ23)I@) $@MbĴ`h;ض(we-C ]@]wwV Z0;p[уd 8h~SXvDtOL@ĬyCQ,l.B~ B0*o I{}Cn` `d a)0amôƒQ.Ap2ꐿ& IH <"EUpg"W(d+Bޟ}iBl9W͕`}ykJ%j0'_ h69ܑOd0xڥ>Zr鴫CݳpޚUCLI#۽%T9 _a*n!k>b LJAl܀K9cpY `M+%UwtlpQfN ՗]{^q- eըĞ X! zO@_L!6*v+7QQ}u9U"TkVt֔gk)u>u?Pq=x경i;hf.\XB;5WۇTF?Uэ;Ur8՜!u[&OakQS6&Dq] x7DKen^ۢ ?v]yk/3tЗsiu kTmPB^-'g;kR|x(m+.qpx*0871-C 5G;=?iߧ^v3dY,σ8/fC.Y]OmfFN u+p&YnD۽DIW7ܙbW~W.Y5=Z=7Ͽw jMtYqUv{48_?)>N_`"XPX~GjAptpY#ޢNq9Ap|m9c[ k r"qn0Y$xEr9v_v:@X.&`Lo~>gN\_. 0v_:M ( eÿu_~M1^0(Ռ)"`wcG1\Z)!uh) [ ,(82)}dz*0\̿@.Ks漢Y~DS7&W- l\8WxM03_5^ؿ`%%WͿwwj`E>}smxu֍ jCrx}M^<{'8Ouk.$)v}" ĿjOQGOhTeZ8,^pak,LH!l^n„dCfeT|ݳ V\K GW-t}qϵO : r7*¥!-_ LLL N2Y ]F 22$Q@.`%dXL{0 GE1H0, d,ELB\Y$pn`֐(yDsIZ؃I.Y$  di|$E@.M aC>"c7{ᴔ!I:7 HL2҂;!sNKNX6BƄ h:UW' 0 (<Cf$ w[d` (XOB (Xb= (Xb72N2.. &˖ϻ`l2ph\/3TPPQǁz PYun5\+Ф*9 PpBȟ"[aGQvyLIA^- `N< 捑V@(P (2ǞDC@F@d\SnQ@s!< J )tY+ {z6S&AN#8]J@oj9JT !2AN ‡La>tfD@+E[Jo-opvA+}dRij\QO-qa#m+nńKnM9 70-"p8KVwN[F@g,gV!>/c+< & F4(z}*Z"FSWlӸAdX,cA]R CEpXK ;oȰD!@*0Zϭxq%(8+]U؊pc0 ^PDi|kD_"_FlՇr0΀H;؈fMu}h7PGB1+p6K !V؅ T(+k,V8Ƹ"T/q*x6wtM@D&/!j p:B^$|//\@_b*<Β"쌅̳.5 9.`kz> #> `mj> .>5l*4}x4W!'bS$SPc;X +Јf#`}q"悳 " bpgB XD2QsW `C pE@۳1o;0W;Vr)!/K>8Lm};r20jE/65>Y9dE@1 TxNHkA5wRR;́m}Q7Ί2W NdRy)v`dQ~yAR#/گ$aQam\20B Ȧ YF* 7 >B+ P@ Yl`е!o ed` v8U pb24;d9cX,d Pj2՘ qa p7Ls WN #&`T4u׏)j$|yIشwg B`H|A 5v ~⡤G>WY C1 bu"  ыֲ  0pѲot}:j;JڧB$|xA0J2%(D:9 \KȻݠAPG/ZDr:0pA=CW0 tҡ1,uVQ, `Y);#Zp0M WN{&o-[&b@г0|`[UHF x}ݴ5']F2 xKa.]9g3 x톴\HV xeOKR+8f]U{l`V xUW]$E]Pjtl %axt9c{LW'R@I\#݊bs"\ewJ8Rc\hYo~F)f.JE2^헖vz(%`  \srN_ qVsb;ݔŰʜ8Q\~"A;OFu*_Q53}9/N{dWA}YLb^|Cac>_Ym\:pck,/fse!p $A0?Dxs:lj"2j{o~8A-B~INiG ؐy[8R| GaᲕ2+8}mW02vǡpm)3QhUlG4/ʢpSOA^B2]@i *5"O*9{A-* n,K N=&rL- >r[VRH#f AA}#T!CAr ?DMXSAg{}5|mMke0")2[|  s/~6OkuEUq0X2#?ӗ~Kбh[vkVb E w(ةh٥Y1QhUuє)ireRn]oFc&t8^vKCߞ ]`+ԯVo9T _\ޟ:vvxFZ#C]&vu-myOTla?["ߚw6ce3$}0[vd;j\?KnJvo(߀kSlǏK롚7'pe?Uu0fP{*95; 1StUg0lwnsO^69PO낽NflodN'Zp&Wh&b7}q62tO6驀>0߫qc ;nNܺywktz 4<= )5OzCo5?~xq_\@숀)"@(" )"@(" )"@(" )"@(" )"@(" )"@(" )"@(" )"@(" )"@(" )"@(" )"@(" )"@(" qx4 8IENDB`Dd%f 8 c BA8Drawn\CSG5.GIF7b2zo![3Mn۪A5$O#lzo![PNG  IHDR~zsBITO0PLTE"""333DDDUUUfffwww{ bKGDHTIDATxb@}qoGMt@z3²PE6*B * )*B * )*B * )*B * )*B * )*B * )*B * )*B * )*B * )*B * )*B * )*B * ) hM1/vφ=kǟ-gKNw.]u] M`y|ZWOu>X;T?u> ӚZVaJ 8\E_0@:Uê.Z4^7۳xu~Cösi{H7?Ωc7*p7Kޝ1S1]2@!ghT2pwMɃ4>0X 5G8 GҠ9m 2r[7́Ŷp xLJmHs=9 8xG>qn@T@7a9lF/{h;,J8 [_v&4F4P;6yOav wRfR}]Cm1p-&65׋]aNEf +wf_zOͶކr+6~} ca)nY)H@_;Ԭ~S۰R #1p.W%ǑEA&1G5)יY ),mj`>W@(@@_@?ϡ`Ơ (H.cP0Co1~7 R KटǹPJ^ n>B+k٬xBE93ট Y:L)aQ2ԓgÂ4P{v |6s .ef>9#>DI}50=~R2}1[jRu8$l83#Dmnf'Ap|I}>4l>8@L=w6_ܵJ!η #Cll8_b ᯝL R$ .W@C1R.-TѬZU/Åt.DŽ02NVelCOuNf _A-FRTwaX~l oD6߁&0)'Թ[LS^SL@ߑToqř1m ?-[_86m7`Tf.#O&6N߶-"zj_~^öOXB?(e`_0ylI! x6B~:2f|Q 870>gn`fS-KW?+s hSZY *9sn e70'= (~WG/'ޟۿ/_Z8_G&x~Mik<ljd$?24g.rn$6*L! < >oddY./t"is"9Ҷߔ[ L` pnm374=%4`P~hZR,|w"K).620}h4 KE|zh*D@lg!fn$D@9A6d/"0b`Lȋ0b`wF6TH0ȽL]p>my"!("hb:EO@,".xBΠyN|"&"![rk$os_wF,R;KEƭU'0`@$!VfxhelCĩCe@pC V#t`O'e /zY:)"Co@I!pCpE@!о(&91Z1.2nٶJkezV #!^ȷb<A@)=h. uHf"P`l& P2Y`CP,pVƓCpB6A%uG8Q@1`E$Ipԑ& @s(& IPAw>"\`!IBn0m3{hvb2;AE r)HPHĕV&ubR҄$#n@lI#'6lĕP "ubRqr@( lӒ(d;@]/mLNP W."58A@!E^=F".д58^@XtkpXyx{)+tX&~ PW` XcXD +rOXu~_cX됺ݽN6a {B2_$XjوfwĞ XMa%\׶Ku/Zl)$"tk ATccHe{ = ݸ87]@0 !'*#R@<bXO F x$;n{\o706 L"صH#[Q dd@s&0R@⬝"%( adqƶym)NnyqWBj3|VJ@e.11Z!Ek)5~"pwR22dmS;zvŨ>ytSꏑ7ٔNp qiK4.` 2elf⺾ 9[E{(?oFȴ 򭘳zS߮Uwna>LmZ?+hk0QzA@n/' #IM@85xE%k`BߝYAeLQ6p +# }PDzH}au /mwَscwiP,B x48v~5ޖ{rܲs$~,3?!swva|{sGbxclo1 ,B?p1s/Jq_>>MN~;-UǎZ츿''Vu̺ }3RT*`R7".Yzβ7!N]+dw;eS0Y@Rr'sJ~(8tTQ1ax_0w +'!=;4bM%Rp͖О\WKD >~%&Q =#zjd?W!'m'zMBLZb/R>ػm0`r/dW>#P` QEpB6-fվ9*R##G[~ {L3-VYd蛺1?{̃+R# !7qB"!Fz$#Q5HB؅GWG JIl;~s k9l9HoNޜDFPJ80~G ئ2)R@1I`rB} c"SXW!uKݨ)`]{җ=҈FLc*F 8x܎|(+$Py0Z@)IMi i( kE| /^E4QڈQض(^@m(W` h) .z$I@X%L9s&NpQC~~$IBzo_S(J!+u&^\O"/4QMd׍2.PtwMuĈHQ iB.!wqjB0U]F+p3mL҉(A5 * !"Z1.$K妄&`{\vTn>ADL"ӥIZ0]@!e'};DS)g`JA@ I ^<[yFzLPCd`( 8 C@1m7{ bBǫL#i]rPJ|x̙? 0 bB[b"̆QQ=9(C 8%%!xل |M!ж(I yywdu@е2eE+ƴ2և $ ulZ1[l uM# h!@%$Iw"݁&e TZ<^H3P%6C./7 9(`0?o`{ )mc6g60OFNl`85PsbWe<,Y Y 1lY֜@f|9 l|[@HNg_P2l_`=Ulu W@v֮ܿWB߹ ̺vG ȏxKm)_/zRęwx`T¿B7&A)/Rdžw7c+'U_1PSy)ˏrV^ ӿo ]KW  UX@ WTpfE|X{B7^v_ Km. ffm_u_~cT%_Oiʞebc 15=.Ȧ,5A>}!vA>^~o2\Q4/^C"Mo UD{_}?hs ͗,"]g z,]i: =RT[~YP xϙqʵY* J)B1*_^Z\pV+tRЅ%hAP TЯom GJ r oed^?  m6-^A=g:B刳 ~ W6PWTSsyt#/*bm\ ʇʷ`$Qd~G:x+{X  dJ쎌&Me:rҏq 3H`_fx.rHC8@wBY{E78f~9i|7u@X?z|MZ "AF}N?jOM; pS =ŮpzmDOG |#an7|v^R-s޲[JNT,P_FqL>VOMCFM6.\qapfo9Ʃ]q*^qhZʂfzFIvx1#Xxqd'tJXqK O9 ӵ$]}߾ߓF>s'MFy5qUz$.7N- i _tBLʽ19w3&dhНj&A[.Jٿqu'ITF9PAjIW㡲/pA˥϶MH*Ⴙ ә{<5?A)9w"\xPKU˃/~w$U/( S879\" YQFWƥMdPˇ@0ґu8s`*7<,?NM .3nd(/T7DTePʋ);;PA=*?N=,0YԆy]a dh ZBYȋS-@ Fʠ'V`84(gPOɗӀȠ4QYbY)IN@Aj@(&:̆VʒQ}ȓK0VrE9_A=!N*H(_h_~'MT85٣ `WA-ONr$z (s.Nw@Ľ!gsQWQu8qN:3,3[I!Sq--LePw*Sh9FQC8dSn\>5AQXJԏjnP:ըI w23J!_Nj 5Ǝ .qGPR>ȓQUe*ЧY7ȓSo|ߴ-,CFmX(3;i35RVK1D5 nj4+7P90^@R?QTjroȠR+]l)A%V Z\r`"|bU̕j&JIe/zL(34:ݪ.2YWV *|9U#~54(F"g/fr#Mb4kƧ/'6V j}c3d4EukRH ^gPif9gT^HLsPIiܛ+_NO!>yZWg"eE{.4`k%?ijtxO@xw9 'g BiQ06vnn]b{Twޜ\كn T[l_TE8%sBO@m|+((Piٞ\y7EsbR6ߑQ@]?5(p=b-칂W@ udȒWaz9"-C`O,xsjDjߠ k5E[]D%hK΅북 ¢jY>|w6Id n[cb5dF? oN75WPtzZTUr/~[R4nZ/}T)Npjգe-NG܏ jNFS&0bke1|4ozզX n8zN ZNo/z'P|:KZ6 Njbꕉè_kH"̩]c+tג9 p:oi0Z}[NU9p_p4%?Ε̩g*2^0qZw$|ŧiy4&iԈCg5ĩi<|H~'Ԥrg3uvJI9UAmsPI#%K?hƍB7pq:7r*לxUv{tNj`vvPxvWez.9Kzx+}Zϱ= \[Z.i"e3ֽV>on2~z/JqV&Թ|{\޽䴟`YhWNTm}/"9C|}]GDuF)cȟ_69v|mmN*fL6pڠ1CoTt*c*9(Sy*c+)opf(?%c?'לL#(cpV_t%N0)G þP%1]*&b qbI՗1]+ƶK\eȘpr i 8uej19)n2;D]xNNsPi|bjOmxBPjr wц&Aqq"V8 m@ߠ&ȍI+@ eP. [%cDEux] 8(co48 xv2:kP:з\A!YR&jOdP rVI'Y.ϵ.A xȠiTe{|n D,ddĊ氯M.hW'GRGk5j-4jIAie"C+\TѦ$쥎f Ua4M *GN‰m9("[FkYi%NsP\:Vt()Qu N bSBaGǢ t65UP=.aν1{*9(eh Gv5k7 D j 7E MX(2+SX nP}Q"Ҡ"5ZHeR"NjPUQ mpT`[~i>qi#o^SrJ37[0*6zf,_Jmu6sS;ɫT76RW=Aս8z(lhgtE0EjEkbOĩW#jt~gFq*)udN2PF*1h̉jنTXĩ-JDB9MO#&*VӓNhԛ9IwOO^B9rLS9rdrdNbiҀ9ɦC>͜ '~G ͆,g!lGŎדroa m7 i2ISȣ9ppDJ|XiF__>ftDFW*8+,wCKG]|~"V5Nq*x|yX`|3ph;f@NkuN'r61 ?+(7J_.ЍC% 5l|q`'9(-PbN#(uw- wP" ຉo KϥApn?$i rOÎ. $0Ji('r%לlZkշe1N-s:qNZ}BGJԜK9tGb*ʩ;?54P/wB9g &ӭwXow9&3PæVxظ_RrN I9HYIJqw9;}_JB9 F܊2`1QWI_uv tֽ(IҹRW;MI)='GNh-1%|@7pr 8@0f(;6c9P?ł9d #(M:rH[MO9CfڠV@i^Jsn"|lƫdN4kj,5c{l"i(-aS(V [.P/x(~Qe)~Sb\'KonZ{[`xE C{89oXxhօmeY}@ᜈEج9I:WE9f yjn_h6Nm t֠9Vo6k@7qk \"ѶEd9YQp/A1l$JKM%ަpNtAʈbnRGT'kH32b8}Vϯb8Rc̙q"bo.N!5Z 4A]U;M:wT[cjsPNt0{kb8YI6r)k߿0Q6Naɵʾ_Lt}jE *K eNpz_wˊd(h'+G{g 'ʋ:̕Ηiw!Yͼ)OE lNPUM}^(KP )ӀgoYAdHQTY^VgNZ'5f(2b+Y"D\6"n>Q JP2xԎNE?N@LX')bE/Rg4I,*:k}MwrJ3 E908|"%&{+'Յ bX"]&b8WQDH~_OsTµHJ@Nvf;'cP 'qZo&d6j :Nyp\}T ̰=| hPSyS\AEq6?#TV@R9{| $`K&a?9=%gp u/o>EF?b}-ߥi1$ZvN*!dgE_<[x8:&5-ngN Z+Eq"[9(qtz,rnjm% BJ$jIUw-0ZQuԚ婘Z{"P %"4'8Mˮ(NC\ #I.|+yG_+NN WD>) TV# 0IޤErr_L|35eS.ї:xn9p>]S^8iX] h$&W_9]LǬQ>C8`L jqI/oI1.GNlz^StlCޒAcc|;91R-7u:>'VʓМ4r}%8Ҹ)W$q\/ yi SKPS >BEkON(s4VNN]h JT괶w9'[YW+'AmPl9uӦi8z{>-:+ qz$P'l} 6+ՙq `4%=8b<*Gρړ*W~jFxpDim1d9َ^i흏ݰW~y}cs$~L/FqSjZxd3!nj[V (Nm7AaI+v$}Sm8+Ipy^WV5@.Dc'U@R~/ ^[-Ao,7q^9z>1m#q(+:T_iⓜX[lM]Y3 *rӷ5W:4.:}`+_]04b:>;8+[5rr˶(ܲ/^zXGn\W?*662$S΁!j}ֶ߰$#Ѯe]uln].'q{usP'k TiZ:FVvDaNAamݶsgP$'h6"RVvЉ+FM%aP˄d a9-%r\%(2UrHn')s3Ŗ1Dچh'qC \kɉqᬊb-uqbtlK7 3LHt"91m%i@9K7\\dw¶V:_ZiJ)۳nn״am {BwwZk|_N6E$}*6_4(5[U{Z"9qE_=(:\C k4xYoj*Ӏݾ-(XA98tF!\SJmh -O`*fi.Jxr^Oy/'=\zm :P^,D|5^.qLᷧlJsphNsڃZ \w;k%LyW6[]>8byv< b-̖!&jW|ʉT%.6+S*Bu#E*Ek~_[/P9 rOo17DKa8蕠9>^:YJtWfם1W QW*VQ=)fUsQ;KEsry{ 9f^*G/uӋgGu!DvIDAT gɽW{3{:%$wd91~jn,jwֵ T"A/ɣ'3m#DV9&e]zS*VIM 6 1\ɣ]ќcL跣A T<#= +@_-GN*Ar*4)qIPl;/ sj}2 msQRω.~rP 8|j=xN^C|Z>[1ɧxjyQPNI2U >'WNfA>y?R)84!P s}@=)Q1/YGҹ:W~-!>-ϵܥ Ji\@9I^J~$s%Z}I8ymoR35σ r_7Y})8՞o;=H/K:\7 <^Y,'̰!2'HF>|R ;|MM75@ |TNK B|M[=j(ݝc%C}?gd]3*(Nꢦc>.7dOW!pQ(_w ]ؒp|kסDɞl(_]S\N.b%5PITSx&Sd]i$(vgd" tԥ5Pܘz=3L!m@AJ碮$A~[('Kb(S"g|$9qzڔke]j-_N&5Pu1e(Ѥpb'N<# MҠhR8}r)mDWZov|nRؙ'n_|D!>IdLￖv!(yIbFE(dx]1繨iTNPܼ uL M4]@.5%52݀@:w3gqNRPQqWY(ZTГntALr4.@EX:cP+7fokbKٗcUHosU*o"fKOѠLTR6)q9)( ՙ> /8d: 4ą 'at?0g$ l"{9E|'ؓ'N+fIx;r v9Lqq'Jћ/M)ΕPw~tBFU*9)sI")3̒Slڶ'=>\ȉVhdߖ$ ?sk #91\m~/ 7]Ԋ̩h4? ݅\!M+EFT1CJ)MSRUdI)fc'O=Q<*^h7r'VdOBJV8N AITr$5. `#V*uaT5B ǯ%F[OIWuZҗX.Q/Wǭ񈤌T$кSؒ5f4X j52|%kO]`3=zD^Y :|bR+9uRI[Q5 t FMYv6Np(뢦( 7mCҖ񽏓q/[Vu=y̩$v%޼>N-PnѲ^[+mSg~'{9Iߪiؤn٩vN-`[ޮ(=!uάpYO覍 G=)ilғT7K7o('IAR7z夢~T?9Ik6K~IҿJBz)),U wdn'N4hTc =ٔ~IJO*inIZuvzz@jV }Vuv?dz'fk2+e@}Â7Fr }/^RNZX-z5'%9qJ~2:9i 1e?%^7us}(隉C\^y3Q?N'ˋ?grI:BA7K ?f?+s2o(s2o(s2o(s2o(s2o(s2o(s2o(s2o(s2o(s2o(s2o(s2og;IENDB`<5DdC! j : c FA:"Drawn\SPOT-A.GIF9b~4n*P癐UB!{SCZ49nR4+D}tv*g3UXVn*P癐UB!{SCPNG  IHDRCtsBITO0PLTE"""333DDDUUUfffwww{ bKGDH IDATx흉e6I QdtLd{ΉC?(b i }CC j04ԫPCC j04ԫPCC ! }J"!B21:Ao/i˴ːa =!h͆"e!39HOI{=?yݼ!ͫ;u2ʫ3$[&/1wی;N XO6#~ۑ<~Q3"a~cDãIf=V2vw@RY\  h$UQ)ٔnFљLnMon'lr=O!{yRe%6TQۛϘ9,ɴ\H]3z^ Qgڞi{2.I@Wkm`Qg 뗙{M֯(PF92j. 3hď#>*`3Z̷'~T3iPBU9=h.CTWb4&^vX%c`(*w5^cCe**ߘqeea/nVEtmϖcfJ7 :!WS!t!rЩC/:@llr_>LzЩC/nM K pbUDl0/:euيo`%q/C.h3\-kl;17C4t"Rg6BAq^tIs Y(s5d}_q q7wv]CA1F0 4J :ׂ4J TD `(՟2!:C-^@鐩qTː>Itt0Ip->z j0rFCn R=C 95 #N"CC( Q#5d'rqvh+dr>ЍMD#jr+ Ȅ395>P#Uu 2 ; o?1bc~C? ĀbNPa 9`P xleܽF q(DLf+ReҳlY{Q-`̠ޙ|zOqfͦbw/!u_o~ך,⫠` *ux$*3rS|9$v% sȷ3:C5웱q;w mKJu=zª;FȍSpGTdHlN I1׺Į 4N C.KgZe4Jz@8$Yϟ!FnLhK*W}fm ?9 ʇkѩ+s>7)* F$XuMy6:>?% 0T 9;2/|33d*}%.t uo8*Q&$ .&f"l6.Fz 5ec"R\y,: 63:3GL#aW~h^ba]Nb?n&\Ί+Mt[ܸ&4i v`DE<8FK hJkeswϐ K,?;$8!C}=5I'C9Ho-Cq=q͛\.1i[f7![xHvz mѶe"cYi6vO !w532$zGGdEk)2@\De"&sݴ~+vaUgdv{#7xq xBi')7[:%C+fNPD!B4JQ"IGc{C>P4ӳn 6:: _XXr-t+\>{gP+Չ5U9g t/\X^]zGy8hڈcdEz Џ0QׯivUzHs/'G XXbi-6/+C5޹33tj6IS8F׌y5 o Aav4;>#R xzj`==)PbeԒbG 1WgcFVM.85C=>"8 YK^3 BzHKZ57?7CP7? uTD/Q>P8ڸ?RZo" fk H^}>gtr+"G8Jt:*":f6OJxߧ3^V7#kO1||OqehMS}5!:Իntznu]6F3vP@lE5OlJU~4®5QAko_6 2~^صSV |#WӮA8#C/'w@^~^lVfE4yaK^؍+P vƊHz}>~ +XXi ݎ./,j^aqZ;!b>\!:2yaY[`®5P)&C>/,] k^ʗ-;O^X&đX6D3CSoyaÌ4 AM^X#fw27u7u4@|i޵hV>*)fs_Qo~v4-kyۼǾﰇ+"ѓ*xLPkE֘if]<F u3;ƹF_Ð6uqKc&CtLQaCNPU[2Y^FCǐlK{ޔ#1,0| f11#m`( jX`( j7m %:!C{`ВHCP[EĚk  %:#CmdtÔC۹oZ#wLS2gT-+VC_mnibh1524hx_ Xqj2*"ИDVxFCk[}!j; %?cecn_ND1Ch[Qd^DI[J[-~l)Y`(QR-UxaD-|\ecp~53|e4S_VYI!C! 6eK"߭2 &ɍuf JŀPP!(UX,HTmCT́vUX!@GP!i ː:EbU7DkV߷7WD!ۛ d.ST}G(ǟLj,kgjϯmkV* *cH#b$S;(C]0 َJCJʪ' V;ge3ܼ 7!pcT?h] KPշ}T/󪏉7P z0dqDS5VGCǸ>&՚ȼ~u0ٖEKpޣTD6f>c0:cb+f8~ %:y[0:MD)C0a65J04ORtzDiuVA# vCxCYzʾ:/MC^c?8Ug' /c8S+uՄAC+`xk}ժ*k˦ _Pڀ:خ8Epܞ?UXJŶ[PnzjW[^ު̍}=7oUCTPxRzY EcoރDikXqz%N-UU<ە?FL~an)!kL9uN5>B rz`(QnPHpFЭqXb咜Di6mPCb0B{H,^ >UCe/"5UsU=DϖK/UZ?1J2LU2̌fPo_??%U u`(Vj?1h|ռ¨CXXtr.Đ}r1")v:U콮heT3hFˣ5hXNb*ѧY~C5q _4ڲX۟-j pMO :no{o*O1ֱɿfL⿙1Ju $#-U`(1˭_e]dObHWYW'ʍA?ЍsYP_VCq;`hGC U=R`(QO-g0qf?SE\uy %z$GQZFЎ T<Ĕ'"(R[ JHiw mpe4QzYqi#G JR4|*O̗4r*T(N)C w6'1Ui~F5aZt*'by*śKw$(KVYeyKbkp4o3>Py\##<,0(ױq؈)<1Zv6-Kk,Y>r?JBpRdQRM}03dy"PeX CA`@|^YS9Sެk-0}_5.aH\enix񊗣*N(y\!f}uۛk3cM]>/5 r yC GM\l_n30TWMJp3hC~$OM -jD>Pq\5*,M0JίN ܐ[?PtzY-^Nq0!cՑCF埄Rd Dif=ʞx \'F6s#f3>mP0Xu_PqNOj_约2iȫ4mxMW|SeaC9:s҅ _Pi\5*auh0e=V56u\*&Eh]6Jdv!‘i #@tQR= v }aDe ,B`(QCP~*4CESqaކP2 ׌yYr*y31D鸽A|y+X7CbT )PbUuwV5.+*Sc1%Q!vhCeԀ((%YRYUH\N:Ŋ7E^VEmuTE}{# T\̊LuBUP2,<ؘD_ɐ ?']9TlE^bDOtwԅ S8=h0ɐQ)#?e@Ij\Жe/`(ژ?4K2xC:&|f.آg0%&~ULC%*Vh`(wUdU - %M낥lhQl0c*V(,0cҠ M(k[*'Pɴi9rzUȫoa5Pe8W/h=yyJ} vgϐƈo).(8e~rc/^%/} D҂7JZf?vmPb '{l@Ab0('t*Ho3<PX;'. aDz?]#*F҂e]C q'7 Qb D+ ֯~* ڏhC~^?SA~Co߀e~Ie //Eӥ𳪚?+*g;nw'x uU%~< f73+\r* l 퇢IS3~*`H)dm }7Q+.XU3)ئ.E{*`dϩ M>uy?%;Tw3Ю=CAh   Jach7D;x<ZU!C&x1moi-w P$pm%&J7ݎW9 bUHwi7Fݜ޽Ptęe$9]na,{`(Vj!!lKz^|yaAކP! )v<#CV5Ϳ!Kr-c*U Ia@)XWm[kO {TIhuT0^;gCf;F5)\Nb*Yk;Sj/Y2d.hx74yн"eKTjR_M2|ok/[sU;hf b(C;Iw?^=5 ,{A? bC?L90-9I"NL,XPW"YXXCGldX?P>9ʹCk C"۽(Ca;T b.C;S^kVGz|)dFsb "tIT{sw) H֪eZ0r$CD20㋖;a\$C|9 1~lE6&{)}f( if;)b6C4gxPf(;K(DBБPf(g,Y4oCX?P"͎Pg(ZOf@<`(֯329C~ty"ٰPg(W͖OC~܀$ +^L6"7o0CxFaT-b+NL3(sohms'CLGd5X_b~->NN~ԅtEnIDATa輍`(G3.c6u h5`ibb]!ψYK|;4d0 eV4xBTg(g[Sp&A`(5TDxaTWgh"2ǒP0]mY/"]D5Q 歊hgZj0V>{= 6C@ ژ źClLlϗn( +"1 HlÎ~Y 1Unm+9u!63VP7Z-a{`(֕ڪ ^ge5u)*"*Xbh"b޺Pk1$Ӟk[`(ֵjWK6f1P1Qm0CC+"7c#ڨ(Xkf8st56*"g4k"Zw3y) ڪjq!+"_(E_z mTDdr= m0 mUD+XlC.zE ź"C˼H 3uE+"`(%Rkrepi5-`(%kՋ _C׵j6zh0jmW ֺk_v`(j>"95uQJ0o~if%59k0"Zw8xg ˿v9 ޴se~# M\Л{j ZO[Mg5z~u$~j5]ź0CWb;0h-`(օ+1 `(֕kj5O`(֕Zq4CO]!kV;{˵/0 u2+óXfZ/EJP3dyqCEɮXg;"{`(WBKdYdxC[Kژ\D j0EЋCC^MbVV"TmF!4լ~[WֺyPF jRA459:Ebo3CC7oV'J7`(`%ZÄ!  yfi[M̺  yYLbjl[5v%5ڑLG)6a`"za_DCCwdr?ЮTA9^<`h_)`MZνC A&q]aWt< \NfVaۛ0}!1C7d;eSFZz._H&v5regb6f|M`=362T~F#> c"Y>>n6)<2r2ѝQWQFC;V2̀gs)2zF%ڪ{;2B7)BȣdEhoW6_s;N5;[)RF ֒2'?n;u͎nGUmٶ}:6Cetb2$|33 }yN21bls?6~]UeJ. bCcCC i #oH!KP!v$ϫ}⬛==SE\Kܑr;ƞ>alGAćen> L(qJ|Y?^HI J5z.ˡjbuDj/\=il'j/ ==a #cKN NFN\͹2D&=[:h}gf Qڑ.n;EBmIG~7n ViB gtkbHQK 7OL;fw.=L~,d^wqEgra_ZV)9厸ȧLIÅߍ2Ži0:ˢɻ\oRo/Z^a?ä=o&.U^mJ]8NC+3oq?&rc Od Tm$厼̀R-`Z'=) MPBʝÚ oaTn0D [}8z">. ܹ[Љq3(oӉs~G=#8͙btݨ*seDr5|yFCj ]kNsMpD%tvl3ޤabb+1d-f w'Bݡ#q,i]`˿r` 7dt`4{bNogoOpGј-dfrrK'sfMe12^Jg[2I`؁*PcY'aclW^ z5`hW^ z5`hWccs:eHΊH{/:դ1/?1$mF;_=ƻ$"=lvg[(=gBq$ ;ޣNk!rɏnտz/1'"f1)0y$݂qql(߻v+d\pq ٟHۄq'Y)& vmog2k= b{΍2^:aG5W͖c|Ip*ܳ!3Ku R%mKbOw3mۺ&D9د\ :@ˆK9OT I N\'O$lQ }ܞd t .|%A ps+Ba(KȆ=a`/~̀r5UsGOIiV2\!w&Q.l H“C_Bz ksAQEpaY>NBأ޷. 0-aO#]xeܓ8H|Cd,ްq~oWYdޖ~W0D`هN:W K `9 wƃu6dv_|>վ6,M%pqjJ5)-@Xf".]3IÅN mvGD].qJTMRQl/u,Y|pG? 0dΫMq^eHq!⎖?<bC~2_!IRg*@b{hG,N#žUÔk!znQd -Ag Ed{+ F MgkǎubB=C8C}&B {c(lCbAw,%XuC }9Ķp~ޟF_?ݷlE^_X{x߽\'c/ aҼEw},}b'ŘoaQ7 n>F2essʽqu_ܒIwUJ}r#ឍ?  h)wd ?)W5vgZr~*w iOdv(Ag+orc ^]r `J/͹g~[ \^ z5`hW^ z5`hW^(9CdZIENDB`2DdC! j ; c FA;"Drawn\spot-b.gif:b177vS)NjiCCA[of .иnVh7}WG԰iT 8dSDD.*iED=F2ϐ׾+&Z{LKl%'׷mo\ٙNFy.;Mz]cT#=c*{>^!+{%Ih,ؕX!m ã,;XR %} 0J1κӹM !*24qy m!DuMhZƖzo bQ]&GL]~ C8D؉趑˦B,O*ӬS-]bQ7X|"uBD !ƐelB]!D=0znmP.Dn ͣx{Y!D!/w*D Y~o6AT85~jC346H ?8ND !3 +& O?9A !ꁡyZ=E !J?WQZB#CP-"jnseE !!Yӯ5!D=ۡnfkBCVȇ?#6"<_jCzfH<2l4%7}bQ iy2Dj~(*1q $~oF !!Ǎ|d89.͐ۓ˨Z/ ݣg#Ȅ=gʐΧ~xU0bO /)Ő+0Wi*a< Cҿ۪23W!ÿnx'MC^|#G&_OŐgfCKڵK xR]Wd cʐioë!r/OМ3$CBfԺeK*li^z2{ߘ7;Cr >0k:63ow"ΐFӣ]Skº6۫Z$ Z);Ciŝ@.X`n|`ߴ1qjo `^; *$|ٶ_ƭJ#{]aZ% iɅpH@.;]I\]! >N{ CS#&i.D7Z~ c)дDxeCt.Tܿݿ놮?K=.C>ٮдr~emܸ\ GFZ\xT YpꡆM#_1S>ET՘0.:=cbh^/;`s|aB1͸0Xl!PC=eֻUr>veh]S6In^u`uZɬv 2n14͏ڨlծ҂q!\oyc )_X>7迊ٔbl1yZ 4C!zC'{YWWq3l11ۖjХ:6쵏;b!Dm2&7]b(D !j!nءu~^G6[j;K.A !JoYöjn2"Uf|JY%_!}'͐2.v;d{EK34k;2cmжS\V[ M.鞮xi؃/&FՆ)|L\_-̸[ gו,YoWWXw9anya2;>e[WfkZr3# uͼ3%;15`+3q=gcCGgC!B=DiYm2u+:C1/}o>F^X;a^ѣDz{ϦFc)0nnZv9S1Xڇ߆֨6D|aZa&Q=;禶fN5[cȸ00Տm2dTfKw.2 NчuZOnB=:9sg[lZ4DWgkF; CC[S]6E-,Ve~Ϛura!˶cG ѥr}z+ko?p\7heIOh yK3uC*:~,u~tuWPgXf.{6E3Dvݎ] 1&6}ӼA CO; 3^LX;Ì1}{s?n$F椳C~oJf)/ѩo koK"i!;QtV]!vv+iq/ehϕ1MOs SddBP ۿʆm;yaiJ| /.CjN]'Uz]>z۷5yaې慍 ͌Kovu٪UNS1dd?}蘉+( v=[>6жМJ:C?uCw7{}awS^ybm'w6GU_Et.2(nTu~Ob/bΐbOqs;kvacE&lz  ϐaF O1en!/<~?/>C؟\x8^а㇊vz ;_7~'/]o/V~әeBeJ2psP\|.ge(ъdKxyF RJ ?ҶO9&<^ݧeOQ骼l2bg!9S90k?4CCzG_qO0$IW dP؋ ئfw]%5[<;OM@ MC/;БJM` bzD6wiTpEcb%:`7IqDy(!CF!ƝE:` Qf=ij 4CS->+z~ZQ*L~$ ii 3Gf:z )ЁsĒ#u}힌ژ`g":ft7Ё!d̨.C8 .g肷Av(<ckdߋoLbhKV:?##|MfC[:ޘ""uiڡî'4١x#t5w7Ϸ=Է͔cC[Uլ\`uYs% 6%덈iiCa@c:dh:~hjtQkDq֣̗ m3Pu!Csb)M~Tu?CAq3>DeG0tXSe\#DVP b@ ٬̱ 6u3/1#~f)LJBaRS8ǻ:f}j?}C03u􌀺܅ߟ1C3%=L34jG9+,g˜'b#O6zMNUN H ! O4iQAe042(@tlj\rCHv@sz)'e?-CC:f=cַ_uA2 2|zSxC,ĸځ@ ֺ!5I jSj/K׆Le)!X{Fu,^S,%_ߟ1ao~ZF)&̀rbHsegXַWJ{Z@0@ a@jwO|1b;=@\I>,bS f jD aJ"vu]tٰcCM>t@٨?&0chdT |/fJ} aq?DjD&Fо㤌9hE?ԱF4N} C{CdC.j}W3d`YC }PJ4H Xױ:pΕu;j^PBP H}HXO6 dnd7q)q|`y|Za^ C1 9_ h|fj1chz:j|Hf>!(C CVxʻZ ʬ>1K3g˷eH98Ǽ ?겔&dGðiX{hbu "6&,73b0< `2.m\khVٲ:.1(>|YC PϸOSxPR αe:S:hbFOFJ )` E<@`sؖbfhv7;i=?g~r}B=EΔ;H`.-(}c@9 M9`nޢ/&|L0dV;۪&|L04 aZT4ؗ[䓏,';?]jO$|drv'SY e5q|ݜi-BO+!ͳ89 b&(#:fȎ֎Qq,8ytX50er»jf9.”i2s6̾zl!L1῞U;}/'1<:o8{)>}Ui1sb/u`sG~Zy }xzk \eT)!3ye}_`h3<[5z9|H $M^1W4`lqj2DFkٷ1$i $e>yMVt '_Ѽ=HmCcϔG4FUC&'DZs5XC ezH<+!F5[ db >9: :>5io+)w@ӝ{Hne(g5Eݟ?`Qr,{ypCgw!?*/2WU <lf9 iq~l;f 4a;iF *!,Mcogs Cfh`X:IϳCБ+w꣆ӳ_%#e3T,Ѥ1ƛ(Oy>C29d&RJ Y{bU 'CSWbU eGz20JPє,>d!T04gJ>{O F.rL=1JMC1DJxV~Y'f!T04~>S];!T1>%bUEm,N1" \bsV2bD% z *\~_BUQ=ey,GC_jI>GQTdH\~s»+]EW{T!+PIz"PU,ʦuY=12>޳Nr_OAt 12VvJZ:bUe e/^bDe Y:.=12,/s.D1*YfTG9BUdzi0VV,`G Žܖ`"PUPa$gfXbU0R;T,̌ y7h!T2T\he3 1҆,86ṀC*e/]/hRZC*C AhBU)Cc[:U;#C*eȈq"wC*eH7sW2hC'TswBC*fH/yC*fԕWI(bU ,ʲzТC*fȲbP6#C*fhEa(fPEˤ|C*w&+Q 1rjSeŀ3!"PU 9}-A'PUQگzCD դ0T""PUa] #NC*g5*A#PUPUB,1;+tax#1 fQ RMMy=IDAT*&}UʠWbUUvso* 1DjR1fA3D zbU5 u\ ECM1!Ȋ@ rn6]XԔפ% W=j-/N !Y5JS1/[N QV\U.CbHFcQfBUCW5mymT'bUU }Ga@"\AieUq^8dBPQbJf51ʉωU2T/4nhն6ħz9>BbU ËtRY!T2$*;V51ZLM_BU-Cт'L!Tۡkޫ. CbU ]AX7Y$Cfފ A"bU Ue Q 1!+\ep"6#PeY-C_Ѭz6OCgI6!TU34 34ZBU=Cc^z43XC!P`j?'pˌBU=CsW${PcF Z (2CB`hd(WCB`hZtkD !^1 ~P PPQŋH6>1* , P'C``t̝49ӀFbU , Ck66CBa:R1k*#01*?RA#B C3(J&bU8 iY3a١/ !l6+fp߇LhHCBb0G4T51*,C!ĉCBbXv $ 1*$\55'{hCb:%E+Fm|CBCJDdFHj61*440Ǒo\CcH-$ȍi v~*l}XAp܃Ŗ¯h>,í`#GW2ƲWKv3}zÖJg\Wbe1v=fAcȸk[? s:㲜voNaSTM&S")"0U6шXS;d(LؘI8GWBȸ`v6X;N; n޺B7yoQ0 g[B n+C[?L7XbӀ~"=9U2d)݊P{Ɛ.!]K:nS?6C'+:dht-hͺv*v9NVcLZW/!]A2=T0Y ns% 2-EgDjCwȇ"ɛa}t\k14;4z F2S\ZG\\**}w~t ?–.^X"B3׋X&#cuu]owg6G;MfV/O lLj79Izd]z~$ܵ[PzYLPRl<;2/*8V P_ K1 0iTo24 1ء;P]{` &:CbHPpuFȾ!bHn0=xf~r]F}Wv(``8YYRڗ@7k2⍎hЋuw6>inn+ 66r0XX%[kzm< _?[x|K.S5V3{PYM㲜ͽ0:/3 /Ku^Lh=i O`A|ȮW2z݊\b1^1 _}(єܧx+1ܝ./ onlgfLo{_n+c&]q<ȸ4-_uBnHh7'wspKr7j`}!Jo7CWxqTScnf5j65T5|X[;[OܝfMlj,C5uCMZ(VƐmoO6G'S+Rk6z<)|yzX!d;Fb7Xyui=_^Q+Zƴj#iK1틭w'qf#i)?dܝ}MR "Vփ:~,Ŧp͗jE jE jE jE jE jE jE jE ju>l3G=OuYYPK3{k]A,^aR-:Lp(pɣ<Ž5t.ݿbjd:CB3R-G1^{UE6z:L3FN mͻN6)$jV4kKl7z aKf/Ѕi4qm;Y$[_gzF/Q;}xnk8({:zus-NSj;k wg5[9~cc;Մ鎵)?1x딺lMrpÿ́@˸T,:SFvM? |~>11Hox#.-2V1n~'{Õ^$hp ř`lwUlhwڝ_iw`SܱzG_R*pCc]N`ь6kOy,DŽvgC/.2s6kT,=CȄw09݋G.Zjl?wo1Z3]k:|K$wk]:h0KFŖm5)^o-oC:CJҷ0^ud Y\151ߡMx;.zfڠs amb)]PRXB˦1xڦqG3b]<1?ba#B!˔U+C. w+K@3)j}yGonl0%rue]DO(ʡkilh(.#TQj>h 3H _\TyYtz*c.Һ.4,ʈ>[}87t`UI-6)Ah4?gQl;X+fe|aʲZzT Eyҕ~ _2DDzD칗Ҳ4d EG]beaأDJuqj(:E]S|CKS^ڬ;Mɯ&PuߖFO|CST\h$Z ݵX$N\0_/+%_5<07ʒYLe;~F9$WV撰bSY@leUF9IT Sb\5"({Ӛ!u6)v~70i$p5\/Wszi!~[فjK J7TORKt=RYeP!,r/)4 RѼrG[p^wJT1GlV5i'HD94JHr\֮N..G*a8ڧ sHD2mo'2 ."!I+3duDI+ZaA/mx{ϡVQmyΘx]꼀V,ad 0ШX+m"TBgb.v'x>R 2~t JV)NŃhD|ZJiTeYWbzY]LbIY3W)HrQzRhiF-BSDޙt.<ذ\jDqW<,8 /s4UT<,=U=BMö_ kldHĻq>gT[9qwk" ((+lh*Ug0?! NR)a&rкdoYLG@rQ,38euV7gۼrv[UF/۩+>`6РCFگhjIE-dԲ D?A!E˻Λ+-|)Ri jh:",4_ly,2$eyz83F`ey Խy22X`e6$<_?q!$N0^]^1l^ У(*W̢iG iB|[P7E6,#M,3ǎ3hϘoB4󌲟39Y@R.n) E8pC հrTQ-; 8S[k9 l73KS8d?N$hQfylul,|q:͇20 0#j~m <ʠ~j Ф^ZQ~N#^Ѻ-s8S7ak$š-d|Q>á҉v\E? ;3GZ֋IDQԟ!p2Q!GQ@58O4PUl`֟-O"'qZyL/2C0 ̈ 6l.BMcpz*6+y@ (QXhJ^J02qjjW54``_ЌYRwFD8TdqFC*uxmFSzCn845_%0bHf6"Q8C+yQ+Xq0|BLեE|9! N "\Ȋ("eD@=Xq֕]SyX-%o"lsjz'YfgF{RT06dI֔ӓxM4F8 ,^OKDQ#^?pUx/7ay@ڋ#ziօܗ:z#@5|?,#.4NyWfVU͙ R8Cj1W3֟'(lw[ơq;`}j @"7 sKΓCSY ᐙ-@˿GplI {'޵Qf)ǡ-e?xV>p_$N0㙥p!aMTHzqL<2KL훺: HA `Xڀ&2K<Q6pkTT}x$T0r̢8Cy<sxb.܈KQ=(8NV8yJ7_N6D{(8Nаr( 2T97 I4בa3'ǩ2KLd tKfw&P9AR=,9;%z;z}E"Qvѣ̢8C|7r{c0:7;TOJ=Y'rh}~,Q O7`H$ʪWP%%eÉJ1D ̺ľ=ƸZŞD2\?|5V<6!eÙb/4[2%c(%eZfϡ) qS dB*o39g2K8{ H"8CfY%@ tȒ(!e\mx0R%cѣ$J ƙzU}4&C3!Q|'gT{ŏ )d D < ĩ=lFԶɒ82+hʡy"d J l& y?`9C+'V0,8UfDљ>B N+Q.G 7#zkG\ZZS)/ ܏|f38CR 콞an3$f5aPIo>2XY/MnSdM؆JdxDMO c+P5s9'Е#xv,N UDQ'ɻ8C|B%GfnP,9:ޭ5os9#̡'{̤QՒ$^BšaZFWySmA+ÅaDq&j˃!)VɡQ/^!E8<Ŝ5zP!WtEqwO+V/zJhR2b_!gUꌒ}1<޽9d͠ȁdS?AKFĈS!+C+?'V#b&y$L8CqXi~ݒ;!fW1ÞB4CbA%DbRw)yk8鉄y-#3 KjbH3m!Fqۥ~ sz^$b@X7N- 8Mc9|M='a' Bd-!K%aO}9UN#""^6\u#aFλo4B4$"=~u7o@(#xUNb$;'DW|?kưMi"6<8wCmٗTONU+( +g'Hz^*tPz^g"~$-VױՆ.x;PC&9>?IV Ͽr >XO~CRKM՜K ƇpָwcjJy] ,! Qvѱg63DfCV!#qKt;ql< ؽVOz6>晤!8YKRuhrCy]} #xfr Oe/s\cr\eaLsh=Cp?9$f!f!C1ω۴qu·)x1.*$o0+ 0'wB;jCłXDԻ%q@5AC@2A!qc@e .5C,R2g8Vf֜HUYv 2phDdEܢAՙeÞk8mG_y׎F{#Jcn&mLړ@~菵UIqH ac(HDG9`lLxNDd[;$bF21}ȷw6sc@&j/u1nC}8g9Vv'9dmHgD`#[d Poq(uJ8=فV많 "(ŧcQ ,9q\ p4@eDct'1Fp"p "Tf#?D~6o#Nm"vx{ŭdF dgzts|;PԪSQ.p cSrs Ywt+(sl|spv16$q!^[cHS>p^ '_TJ3?&x=HBx~9>f * k G`@G#tpe"x=(!C":Y/o -K "H@ŕdFLOڷKI DP 5T\twbڳ/(/\C9behu9.nE0{] /SeH)i}/wqPA)T^C0ܥ 9M;5 T^o6uD05ր;i|~EO%KѤ!uxwo4,l!l bF5.)w6x +_ik;M>.MK ѹZZit؜O`*">/s(=$SrOP_-} 4Փy8AŌ~w4-zH+lZte-HEк p}ETE1Jb!evoic5h~p7c pG'`d mja© sV7Od#FZ'ށo%hٯàvVv7ﻠߟs:5b0evJGλ4),7  RzȽZWF 'c@#H@a[DyEnGP>o.]waPo­Ju$;H7" duS\Jl O=xoGv>Kqг,;OrPC#-=Aì {.g$yq;15,W8iT;.qQ"\RVH\I&7xs>]j"뇊H<\Jև2@GX 7sW8E5ˤ;sd4s>Cevܖe1r^ȥzC|˺A+1Q^ЁܧYPFD(evSʹIXPo i!&TDO!Tf@d}z]W;b !Gx XP׻kwb1h!#?kDWt}sIxILv_w^娕ka~MJ5 jk`rl)VM (->E2tY-sta\XА_j41r9 e6~8{h.'^nUk:pt_8MHO`;|5 Ce&qҟ/Zїw/&+E\NH3vs1lmƯD$O<4߳= P_Ve.X/*YzIZ;'hAȝg~CB>A?̀F$cp{a}L ~'Tf4p9bhK.OJ/aD(k+DAFBe&D虞=mo ]bİBXQ@v\@C=}k3t14V?:;F{kS#Tޞ(|?J:>lQLDhUQ`ш[l>9;FP3(ڱ1P P1t 纄F&ҌPTR&d_35GLxQ(Ȉ`ezD'SH+D3_B"Ve%A0XqwdMa43A?Nܷ[ Fn!UG6F"PfC C >gry0&X̟@rh+>Q=CǙ&Bx=r{̐0vݯ /kJ|Y!f!C$igGwOKx=_ m/9.dcPMC?| #:mL[ωDA 4@Ʃŷ8#7&I s偦 U˖U\}+XV-D+Y Hv=C(ɡPr<bLS YP2̩ۍ;GbFsȓm9XG@>|mn?p#9AF#%]lUW*]aLai' IDAT#O@pOC9d!.L}x#3$R& ͻGph(6|ަ2u1+R.(X,׀`S4>q^ffUqBL'/dkq׹w@d׈U@e͍1ך?rW R Ɲcko/}ClGAD( D5 63!t}eRw_kEg ڔZF~({uwךL~=*EDG`<_kD:S !'_fn J 5wj`S|A1p4enUk>=SJ2 يGsb"ӌYoUby 8?x0|2U\4@flt Kd9$&!&u,/FD2C^9B TMPG{*4[2 p!pZ8gւxÝ?;DЗH nZcCs7.BgGPX‡|ҿMDphjR:>o?} Ȳws~h:PfPת&e!lj' A$!|,p9Wzy0Cab[N D|eF /_Sۺʌ:HMwCeP!d&+*G_\f&ZɗuMB5߁6ŌzQ% )CPnBw}OWfCt>:7QB{{7.!8MwtɁ9 MVrs2K>!lM rdlr}evQ6a'99bc2˶^_saХw@&uTCuT:BHA3E ::*-f7 9T4m~) Qs/m`Pqrlamme4dTpˈVu#3;/:ΎSVWZ݀"P̈"yO)C !_L=vDC4MjdYx,1CEўyzµŌ8FEEص q(CxF ֿZ_bv6>DJڧ 6@{f! vVff-qL0uDk43y"Pn' "l$Ox5oP_f}vSkChjPt^gVp Ya=#wػ!nAJDO_ݠ¡/ŹJDZ(dAͲyWf7?\x$J7!p(?J_8RKȏ{=E+W);VHzzuLo01ӳ~C6f 2uOqx~{3bb;0'`ʥA]"KLzPxf~rLc' SJ4u r2&<` "F?_&99o2#O+;Ϸ*^CP'E#l ></f!dW΋,i]MZɣϟoU 6+֤žhGhdK>}E8$Jd ̤B1?nٯW_C0AnM)Zf{޸d]$ܐVf>*w ʌ* M_kB5] =X :v?^c~:T} iZ](=uۯ*4`QJDHU2_/!H`fˈY\E )fջ=2R{F+4L+X3 r7AYB]|mz乹r({nß8_({';c=lLdn4mxݪ qIHʽФ\D'ܠXM0W<ze,-p'w z_Õ8$d \ 9[1ƪ*cE "/Ĭ0CI\CQM،K\u:ODpȥռ8iM_ɥn@ "w@+z~u8[.n(kUB]CPoQYMPvi| ev)J8f&lP=nPUm?.!ϔw{FHcT[=?:RS6#sDt{7RzQ:R}+1ȥcU4q("ISY*wll(A9_fu1Evq%l8Mc2c[|fbZ"IS?ZAiT9}lHtNSU$~P]CP-8`[ t.h({LHTfWP$Mk#}ryW7qߎ &rPl)jvVZm?D{G̮ơkJS! ;TVv|8 'UY P8F95)qh>Mf|jPb1ÛSfPLUYM=Y$;\2NMxttE$_KDOp9:_*@ԥr#;Yq<|gkGgP\CQsD9s΅fF*7h MHNΠZ58+8{T"6H }Û܊zk>3-F+rL hۺ̮!xbe]738 dA$̬kàf CprDjEAdϓ> r(8S=e^'ta!䷔95<&+os)tAOgm=کRfZ*%wqHZ.fB=G-[1RfWP4j9 ]P6P%/bh` ?̮ȡhK妶1eSe$hJ5/Z4+S@ȡZ8=Gfs_RfWK"Mx !Ӽf _RfCYi4$7z &E!JveݸCfTu MX׫ ڂ\HM}L7j'83[7IJj"+;i!Fŷ$o!V9<yZ;Xm "5Pߚ9tj_Э/g\ܐz!?h-@QkXtQ㻷7 6V叶g%<:2j)0{&rR(E!H-9eeqM%TqBP`n5/*bá2C wA3`,/W6V+݀.\W xHQF/AD_C>ʷ @Ddn \rqcESXtqeFۃ|;K ?rHӚ7K:zIkQu!{z$iuqɜ뒜G)rj%ʚ O$!CÑTS I>j+)>^P="$!iIeq-ut0&Z6UZ,cF+$-&ʐhO4lfLޥpmr$Z>FnӋ{c1s()8iV_'Q*G?n]CiA4÷I{W&kvu-FqI4)]mAtueX)J=J!g<{ɝqu \PZxHc$zŨǟDPFIpDcQ48ѥl$j?,!N4Py&]Omv~,ϡ~sqf<`Y +_Gl*vsZf5x:ujQk2rX5 !vn*rҦ8>@*eudXe\!=;$._ՀE}BfM㑶kOpgo7tZeZK+6U7すf">-),j(;ܐFQH?0W&H:<'^<:# J%>⣝D&x #Rs;|-JiH5ձPF5G_P6 roLa(r# -a1)ISp&٬3w:tdKDДĔ(nNi:=IP7;ZD\BAq>ѫs-  &Xnb?!^5KJhwE pw!5]CZgZX$O Mh5sNiYܝu5+s jW_L4)DI=-Lib, N=j+L8L"c|h3uE.As Uٸ2j89IؿZ&_4%K F!圴ؔ|!Q=<~1.K, 6YQ:5U[^D-a8Q ^׽G)Қ~ׄ{sPt{mbܨf ގUU,)=nj0`p8Ƃ-^Վ\qh'Ȱ?)bb֟ pOiJt 6ޙԵy364ua<][:+  J#G!{쎮TxCa3WD p2[ib?Ƀ!oSfKߟrh4+EtqgTY߃ cJm$)?m ēLԅfMUULc",ZU.ʴ N/[KtUˡ>zIfkv7bRʫfH>Lڟ@'~: X[*L=a8l.Q7l*seyw&$VlCY1>)`EǦV=J¦t[U~ofV=lY[.D]kJiTI8f.F֥zpkKtB%`ajٸMe' t$ĺ5ihSݼlv&I>l}B'r{3@zN:Et.M4H\:w kPAG'R~+CHkEoej1}UFBh(R؇8u}BC.뷷^_aTSq*J;j\׃8>zuěЪKլ-3fuD֤VU>`Cάd0񾑎D7+ՓYI:&vOF,9ׁzuy5֯X0#͂IΙqȼ5[U5&EmFJqqS'D+@_C2^*Ik Cr/vUeee][ǚ6*u]6ퟗwۯX!ͬDpn1%DZ1g{C!'6C~ \.ʀCh9o) R! I0w6/y^.ݥ8$QdHii V?ġUOMI+9 Vw5]+)j $8 s+ d^Xq/p{+5XҞ*qHF$n^_AW7w_Pq. r^")Ô,=no$ozFvsTYvc 2h0r͓7WLݣ~:]/o1t1Gb&۾]oM}u;ALjMD]䃌KӔm`e7hU(nَ*U/L =~UjTA]/a zioT5Oэz;ѹP߆i?6 H?0iX[oy[l}:BNnKʼnDY)c&֍:6p1^>fgD~L)7mP":tnMFW?^[E:urF{'U,x2)tڴܯ>0m߆7lfaL= 歹AקSS~:u{_Y_r{eáЃwpx8]<z.=xC8$HsS]}gZwF͢O C좼=[9\C:RURf:!-z7;*IDATem(JiUUJS~5*#UVj֕HWﺬ.IE8bjبi6\k͜j]#nIcejQ[J4۾.Ruꁬ\r{HqRN9}øBvt|5|qpjCJWVFm%E?U6YZCz1TyLW$^vv 6J 1ȟj!:RB[ WE/HkS,˙XhWB?}CkL}5uEUqP?l:S-A'TKo~ދpGT_o}jڲivIjQszq\ !LVdq$N0JD9y8!n7um(Y%. eV{!27uII]$a$šRےF\tC LOCxQ C) /.ry=3p1N/8-XQKISHLd,7X)9LM=Ԫg?m5[ ,fqZ:5?Blm{(vY\AF=˻V\u  ꮻ1 :.ơ=l<"q4&䋲ntTZz/'g=kK׎ǸRk5ƻRjKspuͷW?Pk*}l'H!!&%s%kէ8E[%_]%}u;R:IAQ?ULiu0*kҽqg9 0h?ߩTd2įS2;Iwz1LpeW˽G.ꅍy6oCDSz <%/n>ֿ,ԞYg?OĹR÷$3WgN-Yt܊T/t[e鎛0t+>T T$ u3>]ppx8]<z.=xCáЃwppM!IENDB`EDdC! j = c FA="Drawn\SPOT-D.GIF<bDT,S_DF nDH2OC ˜T,S_PNG  IHDRCtsBITO0PLTE"""333DDDUUUfffwww{ bKGDH IDATx]*5Gۥ@mmzyogzZ \bxrE(^ˡx9"/^ЋPzC/BrE(^CtdC?tWP[?u[U4AX9D_.n^ҋCl]5@xW`ֲn+@3Ŝ^Cy$P_oPNjzp|2֔74SJj1xi3\Ȥ0q4aDhQЩSON(48">r:9k>̠È '#z>s4XÖl^?;KIuhf2O5JiY䷱3{L~2wgJԕUٝmaŚ8Yi'x,CS?Um7O{^]!dFT)8Y~Y=teQ XT$=9k{!ʺF!f07?w2x_c,N `fN҆ӉU\ի3ȧ^ldhWu3)Rm,DP-g\~QQَdu2W6I~,$P_5Wi]|-~4lڸsBC*Gj׷iUT1mf):4as/l+Rbgqrb"ЌFI9i¶5imlOMC1eaZƢ*t+],SW4%6ɍ((,CHYH2!PQXK4\F~ъZbAZXU+N"c_l҂tePu4w{v$Tt,A[B(͜D+vZF(X/nhY,Bʮ h} Sَ/@zȻ2|Z>\- .Um#2-JYmժ "19qTR BW0rv`H{XӚ7 )"b޴ WAb.&KDQhNW5 ESsUGx9w^_xPDNlִiA`mU1ZjΛ6~KH!l(&wiYU#7`$(DVnơ(?nW=Sm9R6b3H`94rslo[6D0E8R֚^CrB/f|e[m/'2AVL"7sӆ^''QY[W|w=PE 64HGpoVѷC#f_̦bk_-M{9D`3}̏2vh4,sh)Rͪ)ZW(kʤ}C j:/n{ v`TBF{ ^$Cs(DӱɑCH87XHDB+r l,y8D>ޙVf!EŊz7ۋa8 j$2ŰA,E}\!OO5+>Cq`ԡ p1S!WeB TrW} 0qR5QȢ98Dg]uXgrnR#-rp l> "#2x! NSɐCu/}*4Hq"ލ~d0>Oij{ =Db+W-J,񏂈N .RcԇAZMыX¡I(8A9Z}eL_؛k=#jEptÖ~M_QP*d a#Cۋ0d`L}0AwG)ovEvh-G(T/!q|$vG[7gcu{táNa:(A\>Xno7Œ6힏mq+x"phz -V]@\8!D _񍇫_kQ Nd93Qk ׾áێۨ8czfH'+"#@iVWQ- iW@[(*2qW>CQPT1E V8U:Ҧ=K jA),tBoZRV[QO bT!Hy3,rrh?݅Ӎ1z{l)/2rh+P=]&v`Ϋ|ϑC!r-_̨M7%X{CrSV,fgf~3XߑCbF J[t$`ӤU942K}Uk"Q6dZ1!ƴDEiLզ|zq ZZ}y!>m|i*4~}XE9 Rx;4!8_i—D̡O4,=*b ֋l7f9Dz̵v }s4>jsWEߓ(;G4J⭹(h4yeICbC0WhMX2I͡vgJ4|4$ pM@L۟@~mT{ڶ:A4C9[ 7>Ve+?6+-WgrgoD@n\)}n[hс$ ]9t0 5_͊4a3{ ᇑC#}ahB+Ԯ ;*?|h#e2LUhӆj4@PCfCTo.ڱ1L~AIa쌹_e''VsPvE4DܘCg͹Vm3 &Zd>H:(J 5}A $ .f e%֫&]US|k#TAƠD9D>I'+s?:pRdH/ph߼B/$ UD(QS;aGZ"@a1B={qhu3͏Xr)aߒ`qkY0"R#EK=P!` s$O5ʳEl iO3>4 Ewol>Z&duf H`llA~}k7g_hV*-:BZuH k`o!֕\IUFᨋ,y? D8e_R6.߻8',j@HЊ."!R,:" Fe,`agw7dC$ʾXCQ /lE-~Th(q)ɉ|Z秱6f:3GI uicjJqϻ+e Wf,⤌8Dk01t0xࢦ>Wǻ#B !2N+aA!D8VE7=PQbdEq:`#j*4@Hu";HEN We^Dv^_s͌qБC:ɻ_Dīa+B |q9@HQɻ={P Q߯BXC݁EGD,(;vq9DqC'/٨.2( $Zv\ L3j8|%HUYv."4B4s *,FCD8uEq\^2~4Qq!c$K"+kì8ĎTa~0 3SEH~$B~| pS .):VŊ$!9S2"QZD8}o(ŪDF{io\SA)Yiƛ>J{{ ;=)^&V"1k5Z9C!e]ad)L$K! 2AqNQiCvQz;" :_uՅ[ x_"ڷm,;EbR{tCq툂_j$H1SR+ЅYʚ2^( a-u2Qb^agD$f?B"}(R4|䐲K0j^: 8խ$ơXL fc3 Dċj\*_o@|*zZC.& -nzF %ه!e~ͨF$h`Eʸ+NA V-a_r_ʜ~8D+筃+D1/Q|kؙҗ"5Z 5iC+Co*¢L$cbut"lg >>֟1"CsIDZ~I*ԪN xaҠ35q%6F"M2jqj۬ 8-~Źۋİ8dp^YtS\H8ak 3L-b(Z!gNO:=8_q@ _cvuj\Abz_a%h5U_4\5+#b " $.YekW$9t%Z mxP 7Ĭ)# m-a8tz:sF3*!fM1fz9Dò?rր<_C"D%!k uQ8st+G\2D=qi#su-TCY5Ew; 2WZ#lE40Σ.% q[3kd!ل~ئ afβ:ݼ lb%K}̡jM ÕC-1 &`(bG'N~!{֞Veso6Zw 0Z|+^mWHP}G6UEL 1VSCkыmD-"+$Bک=cv]}S(^\1-+\\,+.BT5W֔tg\{ozy.;LFOD-fYe|z- tz"܉C, ǾBfKE{͠E|ۙ0ډ9:r3 XC!F+E9oG!fa_5hUm-(iCEtХڇ5BqID<,7%; pe}#kOna'chǚӈsN1/uw,I1zuu?TuW#P_VeNX_báౄ"%"vDCPQjH@=I%(1A_bX3;xp,N "s-+-Bݹ-2ޑ`Ɵ^M]ӳTFĎ{%=Tb`V,:$B|8d. clU,{뱓$d6Xccav 2^P2!Py jJ:"C7%ZU;"W5/SY;p1pN̬Had=ydX1V->i-݋~>ߪq..0#Eݣ߯iK,NѶр !9tq֌HEt5&qθeZ1ۗе#9]&XV>?^ǩHWh8`V4t궃AWbWnp[UײE'=qC+gl~nj7_ ^+9.<J=ЇPWtry8MV"Ds}zN"_֔4.ޙ=v^V!:Lc~Z*B=_$.?n^qA}İ /W+cЈyYr'Hfs_8bh|#4!,.Tc7^d{P6AwpeKyɡeh'Ķ->>$)aؼ05H0Ke=NH|Ƚ=iFsdȌx~HehLPdy^YC.0mV̊6YaeePN"'߃So ް->ЎHb|VEbC|橷)ը19c X&)qp IDAT>#SMb{5Yٴn{>]6¢3$r;&Qk)[qEi>E|I/\5vněђ|L56&O(J6avNV4$P5&QV]#/N0Pǧ~5&QV1c p E[REl@2v+_|5&QP^UCJ@9$ l다jL {Kx!7H@lHo/v5D ⾡N)RM`ݘEfo. %:{vsx)d_Ee+"{mͱg,fKbȌ [B{ڶndD#~aDK %U5\HdqPh֒zl"Å4ː9]o/tºd\n'I1Q@q^ԇidY81CY;3" N@ZFC 㰰;NRdj쩀"}mыDn0;DBӬiX4  /蝙G)&i(>ƑeUa0Ψ]L--i9#2iB0TrtJ ")KHu"01 S [8RϾcFSW,9"Q|߮q.(p(g (;3TlβrIP\B-VSF |ě b\ڗ H<.vP^+YRVK} "@Mg^* *8^.婚JʗҚne&C$ta3ezJqhD3J ٓC% ӹ%J!8Dg,̺ i 4DM~QcUlA]J_*9!XXҔccܑN EMߴ s(m 3c\5Tb0"Ѯ;>4e/MS~HEȁIZ\s%!%cMޓ[H=8Mc3!wY%$H}r8LD!aS "=^ҫi4v!E!A;4w ]n!bJ6%N~}8ivXK9KbL\69*NT p~KU3 M 갘|\p a!2]͙ś4)bPBT^%Iڥls)4`s9BK R[01R->C*>^uEG)TDթd}c8,}x, JP׽hӲ5)H v,2U㼟vP2Z%gҵ+T NW?C&Ocܕ")W%K);a̛D`-_l!(M;,Cz"/6ҋ(NBdF~Y^Hٹ^F26Q͡Ao O)'qH?c-D+늚@:&;D$=)>CJbiUs"SQS0(>[:4yxuy[fuP A.\5~}TuC*4A˦UbX66]\-(u)I6;AR_,D ɎW)$+ x"pjqnhQ=Cxȱ̓*%3VIR[.m魨4T|$(ݞ!RW\} N H1IZ ܵm bmx:LR D&5MR9(DM=Wu7Q' Uee>C܎S Q3lQpݤk.lsE5VIQK?Vpɣ8*S}tj'XVcCH)gQD忔B'Rl(CJxDJ=C0#-yrH!9rh( (i!巭(Cgjg DQ =C7wGIQpG H!e5$H $*9VgIHԆJ>C.c*FZT6G3x؛&%U$PY'wʲ8B ( 9W9@ 0sY9,VHg^NB+ -ʟT4!@N};WGp>:$(JˇqHp ݱxRS4HtqZ㐦Cs#.(83M (0aZ4 9@1M_w'QX8RpZQ>nITi4wO#:šY_Ui@}vDmYht_&D3̹J1+'f9tD$Tr I4|¡y<3`UX-]S=]Z=e#|5KԮE$oP Ѷ:xc3Yy$|$`Z&YS]ɪ-G7 "bizD=;ʡ<K#vT o'p^"tJ̺ÏN"_#8$听wHem1Ib]g kO"DP{+ ꓦӆIWbb_ߗLԒ+2H>?O"!JN5Lp P)X$6L_$8Dʺ[+KY-兼Q<@|$"B߲SbF˫NNGŨqI4?\CkC.Ǩ$"Zܟ9UQe.Fpj| A>(JFfMr>CZkS4"6Je 5e!mFhųIY-E\8D$jЙMrLf3e2DRo߃9dΎ<g4vJ`qaXs%iEh*#,/.Oɻ7^|76X759{2)%q+Tj\YU xC's<]y{+xӹ,UkCUGsXj#CHH28!>aUAs搱ot"?.DѲ쀩 3+̺gsȘMC\z!4G )֭ ,,0 *KsQ"֗>Z- 8dMˀZ)%JFdl.[X\;iuRCP9D CvvobA^-7;%0D у0cHhe0P&WKyszCֺ@"Ir=~֒Sw¨hFӊv48o\E,*M&~IEьP\Xt#GqH ,`1* H꧃W8d5"ěSeIQ}Jz.fBYcƟ=y S>;m CF\&a\4AkM , [6oƳIhU3\\ȎIW -f(Q<l Qpj/ǽ0=nL52 hƹo;_7G!"]'_f(L{|ж,Qi:IXaKzUf5PǟCcAn C1tרtD\#|˶y&m9/UXʦrڍoדC(qQVʺu9Ԃv*4L ġa z__ 4'^#2kdt:SEU"p\ӭɑ86V%p7qh?Q v}L5*@~UxlFkrH8)FbbMe nz,lJ2wgF*q4pA+w9t22#4mSQ|&*.4<] (F܈ AD@눚=u'8 b(0l3T z !4~t-_@8VF0O:!.sLh_NCqJsNz'aשjt kb]şCנI-F |`1veU/gK~&/BV/v\_mjϾ%$h{8t*s\W2~?lRU|[pB+a>K0 n˱?ahJͻbld鲎OG} q\vKV7d*mɃv$VdCI1d) EGqO-Š/g>']jͤقՁ5^1wt7s1'V kv>-13iajɸše1o';t[AҚR h75ü84! 2KC3<'a\,L<:f X3z;shj_lw#.1m)39Ä:҆e3\9ੋ^_aTf>0/]Ei6aLgւLlxZ8f Lm }<&U%;9JrG> ޤC_Y=əaZˑQ<ڼkS1Wp,yrBz#Ÿ0/ɷf}1+5^Hp0.g׉ h}ITc4C`:䍭J?"XҒ~ZZ׬MMy0>jVr".K3D1[ |DđCʡMr6\8rޭI*84UcL^87et|^gՙ8Q/+`ZHC:>qDiS¬ w9$"bw9DLja8kC=nro " [`\YU)q*`X鶣| *|+'U 9%:*v;ҖڒS.ljKYU UR[8yJ)0/a`]ƸqYP1~S&_8 oI)Cfo$PZ d$Úa}Ozܶbpt}xs'4ov48)U6 kȸ4M9phß)5QE !C#e;/4=~~5oesh> v 横 E;ѹ!`ԂO1^# Nqw4z)UYAzbJfv"VVaٺQXæbP!עASe?&ʴC8fCX6~^[um ` ĹaNæVv7_\#pt 0OGFqSS ~#2\drYr^ЋPzC/BrE(^ˡx9"/^ybGޝ]],oA8~l2 b!k߄O-8t s 0W7=NJke-L{yD3kF˒_ ~j+!==&cqhD?#?]C&갲jdV[v~+HE`\֣h[]0l5Co>#YݡD"ȧ[.jr+J~55Cl~)eCޱ.g90I!+ZqգCNAh]| ,xb5;5%!d2BTZ\'9$Dd" `EOPʰG\FVCVICAAU?IDAT/1|}-K= Tl Lb5D|$~Zf:k3YNAx<5Zr*wjx悋vD+q8ԚJDVm9笀u(T!1'NU=IM׊D]\B̒.S!R3_*qe $2X(W8!5 g&xPQ'ZXzSMsS%{8$φV-8$?*z#9ab%8$!n7uM(%$P+K>duC!1yr$ zP̎mN#*OS "!u_$dN YgѨg~ՐϚ̡Rqh|mxVWd]ԕ|D|T"w/Zy-ݳ%bc\?FCm)LtınB7.+~g] ߂]g6D 'm*Yph+ྐྵt₊rI~vw<ơ4ˤY#DC}A҉ XgGeSe!WďSvۼ@|0 z.ܳq\^ȸ7i:@ԏ W`N A;<;8x9"/^ЋPzC/BrE(^ˡx9"\IENDB`}DyK _Ref416105656`6Dd%h > c DA> Drawn\ADAPT.GIF=b546AՈ52 nx5D ;ʅ({46AՈPNG  IHDRUnSsBITO0PLTE"""333DDDUUUfffwww{ bKGDH IDATxע łe(B"V9d*o!BQY De*U *@TV!BQY De*U *@TV!BQY De*U *@TV!BQY De*U *@TV!BQY De*U *@TV!@)eg_.!j㷝}., gE);|*I1l8,7]9ċbS(7'7#R-UPT{6_zY4jE(5h|10VM)3Gڶ,^Ԯ Ʀ(o/P0%i>T16+@IU\8D#6=3+]=x1dǦ/_4 ֕;(JU8HQY57|yQ2Hu[V\{@לlo4͹c+;dp=u!-;S)692J0k sjzeשtB UB?oLInn]~,]2WI-hm:=אZfE$24%a $ʚ*yiuEPYi(u~qFtvpj0ճgePH0(MTB"O͍zMgZP@؛v&^|s`J]g'ap͢t% k:WCpv^Ϲ1Yp2.o4ڎ~)UNq=3-"%TbxH>ΖQT2iompFdĖQ3S"qp>aZ@uƶhU 79e/գ; ?H:Ȉ6Nlh٭mq bhoxTհvnt'pY=@pl^~ήm4(G:kxx2BGnDEտ> ouLJm=)czk{4a\\ k1.YysDD@m՟n`f'>#| usEݪ\zjAzi>͡- RΕJ;gq^?Hԗ&AMjT-'@*U *@TV!BQY De*U *@TV!BQY De*U'(J)+oԑ&kFIv:B7UZ푌Wtfײ(5G2w4/#۝km[ydl lʊNPVaR90-l(%ykuBʶ _jzrmٺ*YT(8ۡ4{ >\NŃQ73mٺ*iٲcok|y#KPO[6nl)S|vԔQN)CG)׿??5Qe{xeTgHH6m}u?6f9P剔&71lw4گPVG ovnKzz'uX6.߲Dg+ SpTkSw:6@~ͩ3+ݒ,|t(~E{„@ `be,49[j;Ӑܖ$SMds97>fg;0+աTIcy0@opWsf!4>$@8onqtM1;6-U˖.̓12s8+wTUL>q@苘-+ !nFRi=a磷6EцV5/gH*U vɍʵ3VnvhQ3ו׫`K7EQW揀svh]fnvwY78@ hU}aB(M!mnSѕp6%-)r. A$m"UK] {kV^nvZsln*VÍ}g5YEBJiiϿɟ Spk!STE[:Qoz'UUw _ UazJyujC@&Cm6|4#`ժ7tBEm7?U-o>U1 /i@I%9YzF7qKL0 C C 2lh~Fq{?Qv76."#n@0M'ЇLԕ 'Aóz#曜ک `6`aDHbdr.5k|mFlp1.6πӂR:p[ҕz'EۍGԻ|{5EvNh\{Λ !J*wbƤ ܹ3/6&mPk!>@Jf|6s4!lbT>^W)qό(߁TgJ%F:)=7/x] > @6+ٸ905+ 3 m#dE&4f V:͢]]-C1#vv/{LP/M،V]ovfnC'aU#ŴPW@7m׶3̈́W*Z`pz2ҹQ[H"́Bw]of76v|opJݟ{Gϡ[)tu?ݤkI DCWGXFC-LT'e#Fx}%3`Q7ъ1#lui%& &*`ӬIi7$0}8YvŤvs`#L+-ֵ;ڏ7w~zn1QHuH%M9tM՗/UgzW/kstGS'LQ^36T}I,F0xGZ5KivUNM>0?ξvEz#zt;+4yblilgnLd)?e_4وD'Wiȱ\yvv?WUX00بoW`'IB`]~aEMZ*ו<&!^(4^a۲g{.?mv&<ZP|<>Qg<cDJ>T^0)\|X6n3> GIܒIfu^m@/F[£rq1~k&{1u٫߬o{ yFy ݏ b%ex=(>c ׏*ًE<_V_mAmɞ(CƢx|/<#0![&Px^n|&w*O!W&Rx^n|:dIyS z Y2Ɵex6~*J t{&Wx^nݶV45s"!'>3ƟY9s|K%|57g⹶O%—xkI<9m; <=|g6gf`yxsx x7>Wp7xsxE^m}xemx7~ ]ե ۟_ _?uSjNļW:hp7yMy0~~.B]'f9֊a2xuݰxfWV.LPhٗ{ }6 bk }U@UtqSE#uTjI]){ FϢ.,LP0ZVeհhAۈv^NgTo}t+iyؖӽhJj=-QY]D)- $/XŇ^V ץiߊhH~/g?-mJ A0)Feft V~7*394vW  6ķ%ڠ.̅( :֔uiNȜ?K,~RJ¨tJR~5!A R-"w0W"0xRl:6$yߩ]bZ ?Xo1Y&~߯`)şkXS0+ZXH<7(lL{Mz=v&XU1^+z iy-ML(=dQʢU$lN͌?(!=aVVPy \3jWv5´")i_O*ANKy_|,J*>Li $h\\֌b/;eTT}gH.D7>*OEis8@֛SAK!~8,-NX-Q45,lM=Ȗ2PrמC54cr} _^ ] 1u/O/C7V&UU3M2UJ(,u8wۀ nIcNivKlaE!A6.,Z5|` f+C/x4c~?eB+ĭ6Zңz혰“%h\`BA Ԥ#26ܕ<YH4a&.5oҳh@^ɏ4]Tdq9%?t$iY :bܨ'0 ΄ o]}I)γ/ &x\ΦgBC<< V6#J8@UzX'm: GV_O悃)a,}JW&˞;7Pwd:xPr.BNO屢I^ҤȨ_n-4 H]$Ku U 1整ܲ-MP]3M% ZeO]AaF`"U׎U#ի~^Tu/X]hN0WJnmzVBe<Px˄VG,'Ϻo UŤӥg܅MW.\7c+R/VtlBR"L` 0>f'vHNxwW_`|on0%{187{'O:m~%7 ?u` >;vzUX#,Jzj4o!d1sqZ>{ํ۹>dqBL F\C>)P}I:[K?Jϲ 7Q@SxM`~OۦNŝC Z4[f|?l4V|U ѿ3N{+Ƨj|?EL99.VVb%l_B%jcC 'UU;Ƌ.j_kZ9zg@\&2?H!ϳ2\H?]?<ˋܔ?dI?sL~Ny+SH&O1 xs^m E *+a6PQ0^5[ i/_R_*? d̈́ߵuA\Hm Bm[e^.Ο1~{bj|V=(z Q_}/۫߸ meq8V n2|BlCpPn0Ei~-ӢkfQ6LMZuPQRdQ|f B$HG \a|>aW/Lv(0 023 B@sWN!_x6)Fk`i\tYVh|fOKrihK!U;LO`AUK@]8E'0 }Szay"-34>E+L^4eSQ'MabJ4n@)}8D^En\,-mJ-j !CSʚQ2|F;}ylIL4kb/%FLhDP- ~=) T`1}Q;7 n>\XFZї7sA灺DL{ pߣf xVf&&I|GGwVvP() Y!&#\!/=.2@7ID^ln|n0֛{T PRE9" ?X9m[L}WBy,/onA `s hPWXv. |HHD/ZPt{ӍEI)}l:b{%L\g0Lqwv9˱6 rZVޠMMJr.Pw[^{6 X6NMz1 ]`jӲBͭ͌%s $ujNBv t-ŤN ,[gi7*lw ݼZ驆@9I]C}ՅgGw\2\)GBB) f)",LՏˢ\U4z]NFDޡ]}ˢG?~ V:yP2R*B)#?a_b{]~>}#Ze$նۖҮ'[/kGDlذ^hnZ^i[H'dφO3'U_Uʡ0K8S1xpS};oW&?x3 >% j/ׄ De*U *@TV!:6G{V=*%X2x|)yE/k9S$sĊC.*U *@TV!BQYu 7cVo6^M}}b훧Zˢ^r tKje@TV!BQY De*Uov^mx3l@ywvk:x][W]5*ߊ$qbl`IDAT!轏^w}^(U#PP7.[QY<ݺG­(h}fw9n.7?O-˚d7 >-G M6fK1tшa[?Ƕ\Țpa6ST?2;6IGh !+?CTx%’".+ nV]W`nOI,d?"efCģeȭT?sDw$To,}($<@ :8M И}ӃxWA01IA &P"c[|-5̢s:$:c5yAkJ.H`͌?4 %~i]j͈Et21x%mHg8]{FFE2R")/"˔bV͉!OaanVia/p u{aV$<ݧHacA`1=8vt\FP)9v `,Ƣ JpWd,)ς z˖G)-,vjxLJ7xOp(/#A(#'@Y{Q ˋ,hmE[RXrKrq6@mX C[~>{ ?3-׫7bJA}M+TZN+{kl*1 jcz,@³۽"Z޽"M=Ds-Nc۶WD]=z˒9&UՇ շ${pB+7V׋psyO^_ͫmV7Wd^D5!BQY De*U *@TV!BQY De*U *@TV!BQY De*U *@TV!BQY De*U *@TV!BQY De*U *@TV!BQY De*U *@TV!BQY DeʪVyƠ?5g@Y\,ɫvNPk՝E>: %y.ْ|o;̪](ڟHB}a)ǫEr#fo}v-ߘ \[B.nH{ `QT?[]Q^3ii][mQ7CQ4爲P5{[:Ro(;:y^ٴՇns|Dk:ծ|o@-:ͦ-e*FYBRf 2a#*QgVbu,-fc?ۻꏖ [Q! Tv U4.6@0 ڌ~f.BÁW9|pHJEnHAoVUQss[t*EIR1t#NhI(|Pr@T `30}5<( 8?fPVLceWp6,5Y{)hNxи- dMUK8# P*+7׍8ڳs = %ZfQ]};K壱wPX+bQU1ufnkue ڧU~[Bݳ ٳh/F*pW< 2Љ@ .U= RZlɍ񀪷&Q j(mz@{h}Yc50U T_q t[8!jMpj gWIZF}7D/֮6y aZͨ3Sy\F`8ֶ@8g/$7ސHN4@Y*?oݐ|Pj35 ~ՓXT^j>@b`T(4T}{Čp2 V`#x-F0(}i8TN,-lX]X3?{3~!~Ү̶WN^o(曢20\ewЯ][Ŧ\20MՐTsMdO ek,9!nM_l.њ':J33T9ykRG4*x9؍g 6: *ZdD_^~+VӅy*hnW6Sv {rtN2O*mLOҦj5ۆS]O bo{gVexL ADB}ͷ&tfӚ6V@_ِ)*JuZ0n&а9Dn烻[T 49#wU7J&H6t+U{z8pR~dmOՁ iN\ ` @j9i 22i4mn4kB=6ԃe Zmn2P`&&Y^:oms1U~h_pC: QX{wJR"#[u<!ܚ{w3쎅rn0YhS2m@r51,C׹)|?'t);5Dz%B7)1g=HèYx>ii`lPM{PO!K\XauԦ\gc[ F6D m@l48ٗԆwApp!g)gK W!AOkCl-`kuȏ{5X?)lf7tlڙ³\ CQAұq.zO? c/E| mz*c,&mx0RW? LQuc<u-&r@]$Ei %D~eIcl˝ioZs"|@t?TgipgP̭ y0X^ H' `ZF:|:Ğ :!D?ս;ѥHNRMt^j`@9݄@я:[}Fc0[fH|'1SU!~",D$K*h>@ Rz@:X1sC+ \Pnw'rye.<`=*p#qQU3%X7@=^jC }!QAB2 H"}C gPݶj%zN#Sp6Ʃ8)N4|L?@QkSqԍ @\Ӕ*pjÙcHCiŘMٸM,8f &F4ԍ f)gs{z?Ns|"/u qmueKz:&Y ,؄C _YbTrC n)kD$˜TrCPNG  IHDR3obKGD#2qIDATxy|EƟ;LnIL}pQ -+xGuVueu A.-B@BI L'Nׯ!H}Z@%hp='hp='hp='hp='hp='hp='hp='hp='hp='hp='hp='hp='hp='hp='hp='hp='hp=G:U*h4FJGo _aIw5|ɣAz@K5&sř+rWJW7 @-zZKp >f`ב@k`#>BXm+\ZNj$B|'hp[ZY5'{с+\csꌿFV0"|'XEה'Mf;AkH3}-5 &GrZ  [oJU='o _k0Ό \cJ\P%S%XXۙ ̣44B: _iφp|5*B;ZvGIHK#C&~84I}k| #u[Qh\Now e2=҄uEM؜y2qر`>NHv?r}C9CDgbDұv,J`L'"n)Y*"Z`^+ S2/6Hs6*VNVҧ'lųÂ.a&"59@!uw ak5EDDgΚf͚%SO.,,uL%u&,"sTp7 #,Ör; *^^:8K'Z (3sRI-҉vDa}BhVLDD/^SK w. en ~4ޜVi[Q``b|Xg4 0J<2 &ӛأb')p׹tўX "Hu:ȤsI ӈ$F`L`881\9#- 1\X7r+*U:F sP=*3P BX̋pRQ:i ,0tc,DFpL:~dV QL>J]-< j$%)~ŜbS 5V#֌Q@#;G1`6qg6q*}}-Cܝ ю}=;)i \K:+;d8gtxdM))d*c6IwrU.H!I^, vMtAw{[`I5p$4@Q5atJ /yI7 FҘsi!.T`UxeUp+$a[ .p0cqemq&,V=<ˠq(HW'*^IdTRE ׈y#;C<^1&;{.@v벽iu:k/i*M9iw)0$ވvţOaXFFD/F_Xp@x ^y+zfwG }'+kh̜irs@qyp[jFgZY=*kq|Q[uE "8:0є EYh0A6DɶCX3lځT3\=PR%8^J{P 4܂ N i~^iRyE! ̠iщ78 w3og"}%t ZmT|GL::ͅa+!a^#ytꙨ`ݲwT慕ou1Yذ닇6ŔjŅUIZ1m`a`7 1{ntW&V߉sFr6⪿|e~ '_8_O6z[PɨWg;( CcYuX/ A# *}3M<":\}xe!m۷D *s"r9ư싽ErQY]Uw]:ѾrsD>zxڞM揿;]B'쵾+.ެӅ'K׎((@=ꠍ^zgUf`V`ӺlRl3^V2:Hw)_R[_ec`^7^2k]כu6Xܣ>Οm_=.C]1#`KtaOujw2t]Y_|13(1sqyM|8FV?G#^or! 4;ͩ:lpߣО?>:9^A~ݥ?Gk0s4m+V`E\[cA?Gk0toL͕ވy'B#H6qη86~!:l_ d#iXkKCF6[nc̃H\SdoO{gEᷖ^@`$ DfPDEwp࿍ |jp* Osя%§S;S 6V-ʦo;Ti._~6gG%972t ,]g=)}o@ ^LPxGZVi\{6unq rm=k?ғ 2RQW#WS}TIhx^kp`ɨw#1 j=!;J9{㹊4 ^/mŖVwf|Hj6g-rcƯE"5K<ͮPZ`us<iv'4(G:e:EmwBE2.Y5Lt)I?S.aUlSLUuڪh0`uvwIlmw:Lɤ$jʊۭ^JpGui(0,fhSL䱸:@.CP \-ae]\_$͢m{aEɐ$*$Yt$)h*0$P) dP"TÔpAtT:- tH,$S6蒢4%$bdB'i( TSWSjQۋ7բ%\z)UG׾<[h7o3z؋n궔-1FL%z:<*NyΚKA0Dpﯛ5^0Au.{'q)QH sz@'Aduz|iQ<^qMm1xEQ=|-jkX:?ajy%xW3ڊ_t'Iht]\qy+zw< 3>)t ߾!*tG nkR#k[43Cm(FTJ88SEV6 }e^Z MXU l_ B-~p@[Նw&7QZkz֟M*n,"+}G]= |fc狨j:Hm|mMK^ H]X7hܺEDnhQp S1zi} V$t?wh`L]}@*cSQG6[v.dTn|{ִ(/N;2./6NB{;0p}:_ is{U mwW:0 I/β)e.yb֣ Ro7+β,~#) bt]J? ͛SuᐦkUV$-&)vOH"0 STM;uw8ziK(m1ܯ'D޿i hJr۵( xrgc3;Zѽf^+3* /&GLWM0~s ivn=c"9ɉhha;oq4F ޾~-qU5ųWMr@~و\#MW&WY4sk(%~[inT1]9C^br`[G uzkDy6cxdMVdyYVp$!1O^a_8qkKm*xߣO`J8CDA]_> #0|%N.OC:k% Ч/s"t:pyTnnd*et `[u܀^1sN"~[;+w6+6Ic]!A| 3Nmf~59o߲ OJ{2ߕ/p[靖##MV] $v%AYA%+9C?]꯽I6Xnuz:NsX}t/_#/9P+^ɣŜM#32g ^zN;&x 8+"ڧN(,}.s bֽyuSв?Y 3}DgFߝo_'83S,0LLI/8ܿm֥ӓ1ՊSQ]we Ni`YJe / !-0_66LBA^A8=K;/ߘrfṮ B}Ύ~!`|0D>}y*tΈs.5T!CwKDm,gQ:mimn/ǬO ږ4a;`p/3) =|ڛà Tu͑l|I @?Dc=%C_`Ma1baBHw4MXfNXfNXfNXfNXfNXfNXfNXfNXfNXfNXf(5bXIENDB`>0DdC! h @ c DA@ Drawn\LIGHT.GIF?b/Kə&[Jnu^/U nV/zU[84AR_Kə&[JnuPNG  IHDRCtsBITO0PLTE"""333DDDUUUfffwww{ bKGDH IDATx흉b $ ` ZD+d2 d=!d-!d-!d-!d-!d-!d-!d-!d-!d-!d-56PLrfǟ8ŝo5$Yw$&1Jx!?ԱG|, VCl1H 鉦u!Nr/lH?`+y!M*Fk='2?A/|7Kc>.}?¾GUBj(\2GJS'? ϟδ=_ ]tZӫ9Iho?bIYCN԰$WxIBmXSlUH1&6F,row [i(4ZAS \w~Я$ˇtICͳH`?d`4*%6!O7A~(Q '쥡Q6ň^R _#j!CYaiKC)밄!F#O geq 8On cp!e+ ?+iV bOn=b} Sc^|Q0Bv$u7$OClZjM׈"d#c[pXgXRI\Nqst? [bdbڽt*{ HˢȿL!'^~wCxDyLTEbXLxbdC2hZǎнWX ŭ~`cz֒(Or-v5x 2'4@!(e*Q4 [:V )РM9E$ZGZEp 7O|[`Ss*ny/ymߍM=! "ܻߒt'>X~oƧEMX3O^V =5Dݡ88MpxD^쨡i99{jH_øpPCtBv. 1h35`"{B?7SC^֐djȇxJVD7SC(c[~F!mO ]A<ŚN [zlCFc02>`aZ[PM3A1ѥ1ZPr mp;h9 _Py.#&_<9+a}`凨S'%Nxʓ!+A莢!LeK_Iwףa.+щ&_m)h"?2#׸G&ʫv οL ,?;P5$/D8,,UI s2F,]@C1 )YW`w@ѬY`Qyp`ʔoG,M)R24hӣQ(H0J(%qŦ6yb$"7j54KM"@eKҼa44mMǐFqQCjLd̊0YCf8RC_Nm|ha``![ F{ܽPfC3B b_H}P А")0,QNjQC' w$˃puX TW1A8=f 3<'˹qJ@+'xs(jTh Kpn)'?& aݏ/S :c51"Mp%+qJOCɹCvАu08;s=C?}kQh[xpt쬡ǰ|д,ǍZӛ>Ny  ٚnXX#i!w-5誧"*ǸQʃư͝5ՂSIkX!xja*{Y#cpUm,_J!; Yl@$e3 {I3&&? ʦkF!+HʨNe#4(2H/yM/կJ?;kh^>2#=R=HĤ+_baua/%`%Ԉ#z ~sГzIA_|D}MO*ly^^},,Ho?40mk,M12RnMlOvnbY*b q1OI-@ >ff4PM2 ~ ebxà> p 9̺lafԼa{ אbNIhsy¼j`[CIά섑D[pAW-aD]5rD1|W -,/`m ₡Y`ɭlPXXȗA" E}d!c /={khPK(aF>a wZ9r~*+Yr`~Z TQMׅR !h^sYvxTo$T5+ŽCSK˱Iǔڻ/!3[GKH8pe<~HYYA);+=M54Y٪]aϑw 8!:5ݎ3<^H 3,/VWŋ+Tc~jv $cYk 2eϺ yy,#J.l(.+uaOާqM_O.XFT+:J#-}lm]p_= ^Յ:h$\xxj bQê㳑4օ\VօUi(30{ Jq[yZmWԅt Cj> []ʧuaKPw{oh=zX1[KC]X.l w3o Yj(X|5S]X\ԺR6ԅxj8h =ahT +P6H.HIuaXV.l16Յf3W%Àc(t_VCG5;PV^vnW;fSNu<;Z#~Y]=ϯhh S1<|ECvZP@w4DaO×4'fʸO=GCйX!wY1?ܞϖan,ˈ#YXegױ󆙆b+ a354qw5W Wu=+ơ&REwcܝwQ< ;/Uj1NwUt.Er[NY8$M4VfӤV<]F#2y-fӓ]6P\:/?<~|h M`̃T"V? 4#6ⵏg"!}JC$qB1v *^X5?_sf?j4~9 _,:1:\J qhfI"$9'k ~9 u,E iyݪ;|OCކX|OCxX_N4u*K<ù|OCì A;_".؉|SCWb]cGsE S9J[`L8_e5bh؂ |SC41;Mx7UO:,"Ҥpyz^.&$e\0wem,xz^m#S}!c=lve ^13Ц(fJK@$4>-?oRH[gDJMJCu-O%1;Ma6 a춼 B 6 z(- ?>F31؂ i(Blܬy$Bj .:6yf'IC)?q#&_ ,l_6@cCyS ơAO)ӥ;p fcaϰ9hutҐͲs^CQ]XR"雯eG04jH3Jk k Q6 )"Kl_bĴ2cBpe;0`MCO@sfyd6r6U->F4OA=E1PDOA\F4.~yVi蝶}{{uKYG8uM aU_MC^QCӤdSmy2.|+i/!ʂBj6ðsxꛛU-!E$jw6/<ނ,= r24h"c+ig NИfXwC۝">R^4+G+( w⩯CYCu 5= sYy+\,i=;,vjz[06]@XVdI[ۚ$b(c,"$l:1*0sCA21Z")?`9aYJ57} _(sX"a뎾iTK6l`H}X'^ek4CqZz30$4m_)cI_4x4CzZz3 + Yoyg2IJ1klVbP$qq3-9ŠU<3i{XC3}B A[߯J` Y_yoYq@)"'Y4ߪ-؂k0_k*&Z'= B4:;5m?5!ML}.ubM֚"^bQƞi"|5'3=O%mJy=nyIi{Qa"f E)TWX[p`[x8%$r0\DC,*)\ZڞM60PNi[14kc4$Yh3,zSeb)|OVV %b5Tm^ eb e+}=Wb$a.伯H0x4ԃ\2,G uIkmec/df bBVWD]p|]v@cLFL~Aό/Q pٴrxlpe`Lc48/kr߉N2 Շ罆KU(O}{5[G)]}pfyXS272`78iuhݛAvhR ܮ6<4kU}Dmo֝ MLK?W)h9߾?4K,cv\_ 4,P,rX\| [f-u_6}6p!~,&\[E2 CYqqvLc͗c|/$.ɱ⩯$)DrDơ`k(X:=_:ٍ xM\nzfE%/^CR+65Ŀ¿ټdwb D_gD&q$:G۷,hӐ{5hVh(Q3#ѱhR?͑<]9^đ`Rzz MkcםX=mb &0P4ۗiZ$X4F YC=ĝs55&߾NWX6@i( 0lX\)+r#ah-ڴ $Vyp0y.lp"]cа_FXqZz-\j|>5~;&':q~;' =K4QHv^*Eͮ]X{q^G~GCF62Ӿ*{c7'A>AB6*1°QR, I] <EICMO=!ZٜϞ v;rj0h븰yWxD t;_tMX8.ؖ!%EQ5d/ƾ/s;Q5.1f4j7jhhm@e9mD vKGL`>ՐxCD}j(We9yZ1ُjXfؚWCzWߜX$:q54/me$O0HWCqoo:ly]v3<\NXBzÁ547F%A ]|'4T8"7yBqܝUmcԶE=T{{BC'09АkITh_>P:*;vf5MX҂Jʶ mO>א}8>cul-Jaw=\CVa*fOmys QLuq"g_mf HI>ǝxyjHϋݹ a7aD[ 6ٜң3n4TP3e＾ ZD8h]osQ ZCw(J\Cv ?)FvA$]?$P)|'rk$8.盲OT$4B줡(֟мm;Eaw@v؜+)xBI߆kVt2Zpt =tUMZzբC R0m%אobb0Hk(]<8Fsx =뷰;09C~bbD󜦗4hC._C ޣ>^q| R#/9>47QG9aaI? 3?}*j =!)EN3NeDQjhoQ}hyӍa;6|>4H:\32Դ_CCONAsIMzZK/Mc D2zNJِ㷊G{Qy4Re>4~6`KG#5DECp4 -1F!֢&ѐxڊ ݒg IXS Kt!b5GU;ѰX"h@g"x(JWGC1h|ApiI?<(ȳV6#7 ue!z`~u:';tёH mF' _`:[V?x{oQ$4fؒ%ƦsGgw!O_Of:{J NBNw/<_+ z(" 9g}ޟqߗ~6N̓ߢ0izMo <'P6kZ{9/(#OQ7 KppuWN_5~7zq'8ˆIDAT,Inihpw?P";QSQHa*sKv^Oɋo=b7? %ҟ*q&H&Yyף4^%t!aD15LeRQC!5NG4$A:ϽۯAho y.~8!Pj m:]!C# >Wٗa( .BzJ~>{FI%)P#L8Pb {IMٷH)jm(QT @'P+6B)y$9F/z:i-Q$9n#S1˪r9w~UC"b%ǹ`D0²͉0RySCxcb{nC0ymbPɘ`j\k^f7b64 ipͶɮ_ -+E@/R5VVt'cmj[CV?'樢9y| a S!.Dco &UHy:s&eI0ͳ?B yigl~#[Cv+У%2 V9+^HlVgmrԷ@D I_ &8B֒1el82>i >Hup()9ih*:8,|]FAR\P `ЄZW-]`9؟ u@Rڄ?yU)Kk?RP HC8cN6uyfO? [!5gev0?G{[M}'e8`BQX/m,`]j%üxT0*q˾E)g?Jڀ?[G$ׯez$e[_V~!MyKl֚41#O:~wd8%J-q,]~&s'5ULPJ8*׭SjHRZ<Zlq,JK/a=q:0í3G d̝[Ӳ**e]2Hu?Z(qM!ɖoO-xeKU[5Hb'F7θ9fIEۄgX4D ͎InrUa& >m|֘ TP{#f< z}xzԕ56"IC׳Y fg,~&auںGgt9#a.xh>B*j>Qٔˏ%?ښ=L|<\apOgtv8/Wj(Ed+}wg[xk0[{<%QμslP]UC/xoSϣ顗ȷy!-@Ր 7bU:d{ʔ3>pr˂w[f? ȅ{򡆢`LMu5)2IaZZ}g4$xt4QNг Igm=%^*39₤nlAGUa:yj,,TїF/izX݄STp@" l| EZ"vY㫋YQiM|S?E^SW )׹޸Yc5c[;B6&5NECFǡrơ>^!o5z*]eC-}D3F7)&9&!b%G 56@HshLK4} wb0u 5dI`?p2"Cіoƻ?k|' ~ȿyfgz/OO_МGC䐣CQ[Njh7`'C ՠɢnIENDB`}DyK _Ref416274068}DyK _Ref416591760}DyK _Ref416591806}DyK _Ref416591872}DyK _Ref416274104}DyK _Ref413750547Dd%  l A c HAA$Drawn\CLIPPED.GIF@bø?+ˁ. nPxTP!|:ø?+ˁ.PNG  IHDR~zsBITO0PLTE"""333DDDUUUfffwww{ bKGDH2IDATx* F$c@2ο#XXXXXXXXXXXXXXXXXXXXXXXx!?ya \]ei>O,g#b+_drUbvzzq=Ma#i뷯?:ƏɅbu|Lon_շX?BnbW_#J@>߭\cI=%4<~$NRq?c1!F9{01.~f P΍OIkZHrO$ ~] $֦Zc fǗ#}? o6+"b{l `S]Hp i- gI~}Ϛa &ǂ`|*H1k[tep G >220Q@ƥw^2y|Uǥ;1Xu0werݗ'DO.j\*zD6G@1 |{oՇdWȍ9Q # nap n`y X\D+_)C$/R #,gϢӮԛ6 k+j>JZ܅Mx 8ew'&󥗅g1[ L)` b;6%,?xʶr>L@_'Y\_ L&`G:RTN z1ɞDNͿ=˷xL8m5pbX~Zt:=)ߓ tR~8Tuzhpާ Z#hjۊ!H-"91UCQ 8ȇ7{ 6\*&^O+ԝ.G*4V@%pW%#4TEGf6JVZ<ҦnMg򌗸4pP(O'p1Z:tn ={,aB'`dq6[= #$ٴLA%53T5SP 8ꨀ;G @A{$4*; 2h҂9¬cAƍ$.%"$z|q)BQǖ2#Nw҂$/Vu*Ao!+^@@PxBDT AP3!0ZVućXO+sY@- /}.#2 l9JC"W2~MGnM(>$,$N@,~uQD F-pA|Ì rE w'1j 1:lFIsXQ =B<|S~PMuM$* vDv?8o;tЌ{^@[pQxt4cp|pyEp,~A0 8wZ` UHn z)7c V?&ظ,\vVgۖ%>ZtGi 灀@@@BHBs6j !6=_hβ̄,-j |I_Rʞ(0h%@9A Ol!YNF(ml :KǷI8R+(|@r(_(.#ziEZ/!<%$5 F~z'D zQ 5ޔT"!ya:sao˔w_ Ix_Kd{_jt?ޘ F $` h.smUz57 K("=Ɗw % pq܎| $ 5z(i 0prOLΨ.:"=*bjC`lu I4b[?*iL.)|EJ#[Gir0e0.U1 R E8訃#FB^UVI/:-vB-B[KJQ2#p2$-ӕC̚A4##V` фZ6%V` ZJ8JZa4:JHԳ0`,cjC= h+. [:$f,~ R@-e6?j#&"VE;B`"bDQD $ *'яeY|/,!x A$P˲QF:H!xxޔl^(&b +YAI20rl5J ]TQD:@H#6-pYG"ߘ&S> ;x4 { "]F KA% UJ [lsx2J ~5F.rń:mh[, N@?7!6lB(f` 2R@%@W) &\i?RoJIvʁV@kT' ?|< ADžVwj. S ըh“'FEx܅No tD/:%Q<Ч*O:-A 6%% Jnȝ2Zi=')Ե`d1xz)Jfd*T=vQQ"Z t/_: l+{ґJ@iH% ;g_Yn2xo*hC&V:wK^{+~"N(7s*> ,3/E|-5IzDR 6w? I+`@'_jXZh_6@]Q5=%m\r(=ϢK/m-#bAADg˹\p7mo_g"N"߶X:y,^Lվ5lвC\fsbj:Td]ݑLxtL/ W/Xei/ަYm l4ËGjj2,r nzנ;y.tynփ x`UB3 *~Uv_J mg'{2uӳK _O~}?#W YNvdRAЇ?ï Åxۚ岿z֫yf+"⒅j/`Ŗ&2gt/6\(7;V\W_浧'K-F6_||6ܕ;ۑwbS"׎"=a_bxtyV-!. F`[M&nP K̀z\Zy_=<+-{ӌPcIRӹ'!!݊mZ%xxW☌`L&&B?Ad/Ϧ.=M ȋ;N*}ЏNn$6yG:^?9b'2ɳ^7 |=}`'m^䭬'1ii [N~8/I׊IЏCr￣~vn#S@=<M`/J y88Ls @)Rf]>W'?i$v?.;8VӸNuԏIދtf4\eFSSöfa{n8|;2EFlܯ\u,WгM} a/}S.% =Kvǵ[Ϲ;{̝fu_u?]barYyCg4M?W}^O}{vZ7|)d~_\T߂s3Gm/~v]O\\@2ڿXXXXXXXXXXXXXXXXXXXXXXXX';a_AIENDB`}DyK _Ref417286060}DyK _Ref428017081}DyK _Ref412711267}DyK _Ref416607008}DyK _Ref417128162BDd l B c HAB$Drawn\fade2eq.gifAbB`үU|^- nV:QM~YڈB`үU|PNG  IHDR3obKGD#2IDATxyxEߪ>[NF `&AAYA`n,ภw܆W@xqG%(8(B@B@vr>]#%9'O:~b AꗠNP'(p8 p8ANP'(p8 pNb`.MmH0 0`-wp-to/!x ̙ 0,@L0o!(pHs \+9@PZ38 \+;`A/VT rtPZ)}05yS'f%J^Hqv 8]Gz#Ew?Wy8u\l 2fvWNi`ϴ?3>h ئ+w@Tjw0 @e38CU/Pcq.=Uv[o_w|dk&vZ5vܸ~V:N W7}'?l}>cl(ߘv_ܲ9ʭ'F0㮷d#&;{ɤ^-9ɽ<IG`aæFȡ>H`ͧk%5{DX]* c=%/!:#O!m*]7dx֔}m$"ҙE}CDn3(HRC`&4MҝDradJe+*J(F%aM&OA$!$v ӥ/AZNwX6U<'+b3ܛaPqH*&"]]0o9LSXp:$L zADmXN$)g $!MXzsJ[|: Z)  "w\n62"{r-ЪQ3gpʛsC@j/KvjdOl45Ptpa. t`h%<5A%Zwud@qm(_l$ أ[bOKO[8Q*7 5,Χ#Ceg .A@(L'I`1A q p ƨq cgVA8#AU[Pu1P?UFϿݣ*SUXU^_&MSd.(:[e ",}p;g!1xOʷO~Q_ o=dJba 3xra].tl*|s͐ C D\qMBc, d3^ M&%]=>p{ K^RE( ̄a[T&+$ f! Э8I t78`Qu> ]VЭ˜.$T݀Ơ M8<ܦ{%u"$ Wr[LKcvnu .W.1R4Y2l>a[2X b⅍S:޽n4'ѫ9.vd= tx)VފX<q0C(@ġBpo uJUEA< ] 1 Z!na\. 1`RiDO Ze -bxU5B<0æY '$P4]X`|f'G>2|6tf RI,qT( KR\NxP\)nI:ga^Mw% Ca$F$CeHSC(\'cU&p>1.B<5䰤9INGSHk-V#"Z^<X1F6hSai4Ak1 Bucw%!m'"4ͳyj4R<)shٲs͠0z3 τ(xQ[>'Drwё80AX ?@4C+f2diT W.?v$x#:1|Fu)G\̢R$\_}eX5+?۪F/i30Ph{Y_1S"TS gTlE|Ow^o+_gGjY&:kݬ}ͳ })=F&_ p߽8MF\Shk<֮Uuqz.­c>H#\O4F,9*- D_s$ jy3XN:ui2dR=Kh3Ac_|%%ht j9O'oQ[s<h ^kD?Yy3DԓYDcʻjP~a7sa(Dڟ!.k "7!']hp3&Pxc;t*9͌] t86вOĴ 鈉a)݂⌰͍ 7veO|owv#{H]|lh ˕>/0]]_m)K.;ז+oX 8ҲQ~3 (D6qT-*6A%u2s>;4 ׊&ۅr.f_Qҷܛ@ l d۫c{ 3C4'+lw* =>f YM/Oh6(8WW^3W;Bs6kHv%Ṟ+wDu{QXo)1e+ѦPG̢WH{?a"XVxgM•Ua D (;qIϨ^SW#>[y>yZ~~ِ.H^q Vmiep-1{qlO&]b&o}~yoڈզkϝO4#tlg &-cjLS$ȘI+4"b)yDt3Jzͱ:3o#NH̳/óH/T%nA"rR-$doqե-Z>"Ktn5Y;w]c˧SZOgoɤ;$Qem6>WuCD1Q_.խt, 'xpՏڐzbەEK솺w¾h 궙[nڬN.RD3 >/&;C1+`]D\u X^ٙMжVz-ݐإkga]+tNFfӼˁ+FiG)dtd+;BHwNpTMnv-:ۇwPlɦ{Tbˤ L{Clq/k1L8hˤ #WþE& 0#t(Nl2i3nn ~#cle f dcYjX>Ԁ< l>&bMTEBPߊL¤q9㆛ҽj.hq~{M545tc/1+M& g3%lp-2IGwתJ:z^}p.є$5zR5Gdx=q[zw ëw,UzP[֎ \AW;r<*l+p^=H}+2|t2[ bhYVKr0ndp6uTI,ԭ{@Z4Y|=$`2";a"vStf_˗*6])\d^dU4y;M;'j'P}&fIV,O!9hi==[ѫ֢oQXui?'Tٍtq-Kn&=X7\|#i3:ZwYG-j~mXp\n Jbę!g?]F-nu]˼(?lzuHdox7@_^д|ټHa, g׫ r4Y{6rsl7@܅c#,Guόl. j9i:`|\MܶZ_萦k}r$&)=+ZCP+wriŷBym~?*cHhGcNc%!NFjnHݳ)ӽ!^ܻ3a*'_O}alhGeH?[$rS4`fH!FXG?bFvGeFK(^Dk;OAWYMcZ2P8?D{?0\EZ禅ĝg^W#J2#WE a4 !1]"٣&;rW`P|NTO" Oj:e,PBW$^2\~eԗ]`K1H%3Bn0|'N.._}$;%<צi.QbŜAy@Jc߶.Wv=⎱ In 4gӍ !As7Fұ?!I ?Q)2M[Ukۆ.e+M> ⡳л=C!Ǣg7C¦^9I+G? ikrT9[G.iGm^ʤlԂ}$@˯!0|o @eS=L;6tB+@lsBN~k%'"NXpZ-3_u am~4t;D2-A=%!3DޝEt'2s_Q X+~-n269\s5vdvEEF)ɸYn)V0/htEWBUtN/BynV:ǭXr ^sצ һ/Z8+Hc|0ig&憾5}x?_ܷtmv96xUݹ*ddn]sKL:ċ[`41un-:K>7~BdjO>Iޔ_dV|w?ӯw{ )m}M5Nx[S3e,V_S@Nyho,e;SNY~eNYX9;/`Y+j ٗ2ɟ%h ٛo,DܛhHu]ƖAt3%𝲷M(d .|ru./q+Bvz K)dJS8/v1xw3,ӶJ%<-/'(u=)_)I=)c߬n~'e ^黐=)__t7pJ*PT *@UR)RUIJT%ril>[L)vC4|o_N-Dݩ po}׶? VkR'1lZx=M?V_~o\ڿ[4qxluV[Ǘ⑷Pn?|\cZm3[nmkkڶyixo׽y4▧#jr3s6Ͳ T.kqKQ/O WK;͟|>$s퐲}G͛7>YK1.yQ=OB[мu}VEfb^rF_ƠCYߙf} uyfn:NE kp%E_ KKu~`96ѥyz ;^OG[,EW߰Aa>HCY(y"'S}~7u}}v.0Ι cØtqNj\g Wݳ.q,`uM]$&0sO ɗsi_@1G'EɋB7'Ǵ+z.5^ >;_w tFςW-* &lfcˢl._^)PfP-Fg_,@ g0 ՆͺBY>8,c[`8'oMƦڮOhcߦm4$G_!1Y&}h{]@+ pgHXK1Q&cgZtκ }ms2o:A%g̪C2X'VagLP>l)@FY< nWYzPlc$E-pS@o  DmXঔY@RL`2R%e`8vB)ŰJ0җb6 Ϻ@^ fZ \,(@--GQrG `! du!T D(5_@\K^|AKwi*1>Kw,Ō"9CU>vG[@bau_0 59D]0n[eVMK G8RXD6'4\F #)@z)F*"/$[ ~"*!jN @z)Fmg|ÉRu!@K0k Y0y ? Ɨ c1Zd,0%؉6 'E),f lu!G7(\6=|~ ׌-_6:v*!WPf%U),ʟGp?.{?>P<w()xYbI 2aSuО8;0\^7/ח]y>a]m0ٿxYR? ܮ[,[m'_͉>eN=!J fօoq })iAOS|h>k8 0Y@$r$^?.kk4\.FKޠ5]_noab'k z;h-a:z^6=簌OEjb]X5%p%oGi8L}eW9 %Qlpma#m(K~XRzwh;2c[ Xrш: q~aHRz7h+Vݒh/‰-^ oM3p mvw vܛ|KY \cYŜfUl{Y[e٨+` V 3nv^n}y`]K""`FmR3ny_Lٮ'*445OW?8>C,mI@t fhb!$3cq}]G_96E/K:~&d,H5@ [R>8Mu說zye}ՔGnǯ7z1BGPHnI $? 9$㯔.K'@J0@0@FN[s 9,a dsH( F0k,ǒgɚ?>LM2["CYYq`V,C*%|b> W›@F fUy`["Ca, .>2gFG@&tN/XKAd'E!(! x>RN<%ntv"}.CdcX ^FPeJ1Y!EȬ j ,0]~ ("9Da8 PۀOfFs0ğ0myB 9~}C`.õiB:B%U> (f|h|Mަp__ ::7;O@>bD+ݮb4_ٝ1 dyZ1"$̶"1Ncl[VPT`J9+? x lmG_в/q ~Clo!o/]]ԟ{3Sd^<^#l³Q#dq`8Toa..ώ]n=0B-0c@y;iI285<9]q߷3C߯1G1@`sX`C|Ys@Y `ĖsHj~zG+K Ɗ znӭ:l&wA80ڟ> ):LfCpgh3^KnxM|uj@ʖ@Y),x)^ 8ݖe;+kRj>cY!>}%3mP|zLYtZfq?-cn55D0Zѷ#u;xXL)D[~qrpPo?` M{]8N0[,740W6U?_s2z7>1=B08vQ,_>AȬl_Ery})X QRqN}ư@|f1vy>w򲅳tm_ScP^p_3Zʏ| ^jƲAe `Rcw;CpS~+GI9;~-lMIQODP<2n 弆o 9k?lK $BSh_?zPYZ ;D^ (, P6D<2~ ((0K1bsY!t%ǚ_ ((J1R dJ1dr=p@GU5#X @[!E c×zYc1Dy*^!(]yk` i9$\`־&e1r8@񺇿!>Ez 8yr†mQvC(ƻqyWs; |z!x>6ty[!J7e%#:@r7U)O aD{!%}3 7e%#l r9in|d(hN (6q P@[=큉@) %Yrݤ\i)@n8!eF>j!@ N!JX ;ܛ+Дc$?II"9$8AvH/V(`p-u=Ve}coPCfN[L ƟoZI:W%go}݈lVI^:% f8R;@IWHIX~Ҵ)i %D&15螚؛% y 0 |M<My!8f}WMIDY @rC-0os5{$FH69K` K@ ``b5w~2@B$&E"pvgHD  A(ftbeEqm\ۙ%{{6>? 4و 3, v'@l$6g+WqPy@!@y M17)[! jpt#>jP@b(@&_ @^' z1q3+ RP݅|BP(,(@-0Nk6>5W9ZR^ C Ƭ2lʢȠ9^5@4@f`˺~^z뗠Jv@l@y[3OJݐ &E K uYx|"(76@Y F'`#*aCB!eHBD" d3rm`HPo%T1ۼEN0-0bt.鮕E0FO ކO漘 `A`<#5C1i>cA`^ `$$ $y2q L0ǽCSF%f{a"=/Q"c#}rt5i.Sڏ5`jxccpfCC'M`ϼh?] `D 0.Ƴ|jzV^hnKH4#YUu ,|U.e8௔r,Q>ٛr+0j2Z> ` w$!jS6e:H@REP $  ^UH9D `@/DP4Se='@VIDAT@5* *P< (Cn ,6)&WXY0@RmUA< 'R&eUQL"92@8R`IH/J0(9D 0D$[ &o*qTxH%RAH!j$ 1@J0H/dY , Y&TC`  )& &,Wj$   I @t @|)FkEJ@-)_J bFs( D&oR`懣ޔ@ ^UX ͪW%n(5lJ)[ j5L ^)P pcJ PƔ@`)`s@-lN0Zٜ @M SjQbBRܞR.ԨnOĬ H@+ဴE4' @M TwHJ p@`,(h٨PQ ;nUy.h٪2iZ٬2U ҥnldb4lX!ZٰC4lYH@M [VFie -4馕$ m 7$5+/ѥM [W^]GOyeأgm^:@UR)RUIJT%J8J2/IENDB`1DdC! _^j D c FAD"Drawn\QUILT1.GIFCb1Vq  0h n0&d`eE<$*Vq  PNG  IHDRCtsBITO0PLTE"""333DDDUUUfffwww{ bKGDH IDATx] + 0*=S-pCDȡWDE"r(CpEP+""\9ȡWDE"r(CpEP+""\9ȡWDE"r(CpEP+""\9ȡWDE"r(CpEP+""\9ȡWDE"r(CCMz"uZP֖bMnztPd,@A`WI. 3c$&1$n G?ʓIp=q@@jlB ұ.z`ӽs^cɃ :pRcYbYF ltW=IJ!,OXv9TXsF:ħpbI>Z6(?"~\ܪݴx!!f8oVKDYx1bB*Lo9$iW >4fiangjJBt߃6z@!=^|9 i9M!*tU:}Omɓ`ю7wRAcBmfeg 8dDW!/qP g8rU^sq_lE(X_3$]U `A8{Z6ǚP+%]萌 ⳢDkʒ61R~o³%,My!&s _;>*- Ņ5bbr;bq ;0C}&( .MY7e%eERiJQo:F.liz^M;'v9ڥ(9'8$KP]$)CYI'Y$i$cZ\󫖗37)T3GXhCX,7;*0N@tG>`t=D,opkΙfJ͡!ѦR >"Os ϭ:~\:oɰT_@Z8pO5Rg (~4rCPXU~F"?$Dɋes WY}`x#5!`83dY\ٚ19dUz5 Ʌ4 8sgP" K2-C$y!UR!Tsh тj9{?@} :cD>QF}(3TPk|A ."$?};vԐNs@d`U/m. ;kߩaF<!<_=axϡ_ C0혌wa)@3.v>sNFޯꚮmoy11DsIޜ=ƝsQjS_ضFI—)zF=d~{< [_ئlkol؉e=1SIxM ;c8TR1hzƃm0'C|TF! GP_]!oTc f!nдɄph ѱ̧Ձ'n_2u[ݸTPwHTH:V azG[?dB]|K(74I C= 5j84N$qH}|c̑v|Cf…阩6 Iz!l2K7 > Z?ɡYv69{< b{-x> # 3}*D3Ƕz_'M7aHkCh-i -jk`(Aph "_K;L uŸ1rAphwp!^Qf}*Đw4Y{BFҔ?l9M0Mk!n [Z'k $w' ]G@_X8đ$8oKvaphIzʵED *nqDt}Tv/u~A2g C|n ;tYp^Cc ~ OkTH3h5?1 `b %H8ъ(P+ e+35LCtL;OAԖѼUKZ.,Ai@Rbmfl̘ #<0i\?l CJ#4MLy487jB2 %g4cn3ǢAqHqqQx`o ^r 8fty ɟF9Jy+PY6"()-*YGP gb+R27v۾Ѽj<]xjP!,:5mT/t qH@,A׀;$`&73XyT%ZE 9Z#8 Cj$ p~X&ȡ_*28mHE]C->Dm·_Y} P#3 " +6 aNT5l>DmWH tNiX, VK9_>y@qh+Xy geysm!C C^5O7gM|9mdzEcUT/1 F2h3+P{q.6,9#@mg(09`GVH C9ÿ`Kgy^a9` Qz CZbRw#ݼǺ C @u~h˻lX>$M >HG+͐9Spqֈn5}T#EUV1"Hi╁80@@FJ>W &j}3N#(`i/`gX+:o?yTrH+qǴ/nZ0՚tCarH[ⴿiġ*_mLarHOD:Ò7mpk]͔i!X 05,s,@94I[V #8qBL[>10N,0=~+$T[hx']r_ IJȴ%*]NF?"_^ CVg!Of{`9YL|^}fGvnRmk !C( \/ݿt#Gq`9u>]?w<9dMF&{|a,rm{2q~p^5<q, hطzʼnN2,1x noǾy^?G!7W'SH^5ID\,ӄ.>d1tV>ycjC 5Ryz:/p9nsحܤ[L6F;G!s/d_h o8CFǡRh Żmא9{^%ZiZ^%6DneAs*4` 90p]搱!V`nؠ9dQ`,^yʵzvAs̐8X @k5(+ي9d'al}QFzCC& (PȰC͑Kv@}1@>+>!"?ˬ,ճ!`@$o@C[cg+ԭ{܀ ӷ83דϴI?x*Of ˴{CfPpgA8UYL׵!))r5h|CG0QYALp%8ԍ䄨EL|RH @^]9q{>u\!dM+O@yH*Ly>82ݾ6֑}Nިy/ i#U{T~C<ͤckh^Y`R̪hKynhƪLjj8s2:4ߌnTʩMQj [|3R 3X;s7GpVp~ Lhl63^Z5o3@`mks~ 텊 8IL AA~7p΅(m̋|AkQ o[ynѭ7j GA%2>4X=+^!(u!)xMn>b E( `2= J8;ϛ y(&ߣAX '%,Ra5[P1mנLloU3N@*ːrH.L P )T`c Tl<>3%,j8 MA%Ur>`U}8NeuCp1"~x.!t8eoC)eIS!3M$F}5[ `%p}^!B{1C S@cwKϞwcB,tdZ>WAc'$;x4W^VFlg@Sȑ}OCp8C!7Dc@2)O kd{8 bjdmdYi'}d/ͭ}80P 9"Xd3!oa6;`Ƽ+r*P>7q̐pЌ>CL utCeBbN HA ``( ƫ8e /R n3g#!D)=yO|(<\ Na} Ht Y !?.aTBo)y9sv^!$E{KQo:}C:4CX 31T4S蠖:;8nQ _ui鞗98Ş Rj:glh2C@>4!"[Y`jBԒqQ96Ռ?7 ׈jBQChy kG(?~ yHC%r+|<XɗQ?^ .W}T.{Ǧw=.i(y!9\ou&23\; ,Ǵqu=VqaP9Z!T.r5G9sʗ޵ 9L=b sx#М3Ejs,xoڗ"?fRl9%sx%А"y_pfVUc;jhȜWb@}٫tP#a J0H:B=vTwrϨR,oqEMDSlf q؈\p1GnC87P-+ a>KR_!' g53J?lψkᾔCx+bS/Ǽ_5.{zɷrﴌdZ;GlALx+.sKurҕƔKCxwB 'ڢv# ڈLF^&½oz'ثST/)?x-,3lZVm`B`Vv % P $ʷ{8%ፅ.j^+ "3o^un75yjC%bU^\h `%|UsrY B m&pšZr2 m"l0vb?N8FQb5xj.8"]!^ UTP5//qG8$M6!%̱7asݐ  W#=2xTj x#CᐵWo@jzCGpa4k Em*nؔ?!\mK/{< SxbX'|C&P{;`^Qú+Iua; ?fg׫c ^U R.mњV²Y]Wںw8dDcw+SѴ Ԯ~pȞ' 8vXiIep޵3>!xU/PNCphOX=Uwvn3]9_""I r1r@o76mġsMLW" #L )]l47yyRiDhiiw{q8$֢M-%KAAq֐@1RV P#l:j?'c+΁G|CvM̀ ͬ:^li k#>! D:KxRF^*92SlWC><#~ƮZl~ lE G#eB"PҮ9U]Hj +}%-Pv3e hpU A%5{iCgg0Қ%}Kr臓nIBC 4K {9#Tmspz  ~7N'?2c[`LIFX '?46cNR> ^E[|CVgՎrVdU$f~m'AfadS(rhM$t+b͕wXx&9jX= E$0.~ҼM&AЈ_vOin׶ݶ uQVȡ 6[Z#Bk=% DʨUY%y\3./BBBsnGC6[=L%7Yps?ap"V $6NkSlnGlRh[#Q(rHůDKbd1n9 EmFin/ .46i:> +Mő[;9/bXJ_/-WE[9 Qnm-i:쒸_ꈗ-s aS>Chnӧv͇zQe;s?J8$ߌ!Bd&Q^Q79 5 y~tyD!l9#%f7d#r'XXԮ;e2)n8vJ9rC1ʯ#J̦ʘ;Mҫr<ʤA rh:!2 lɷunlM?kd"QĚT"vzlV!otvpM0,EQޕDo,Jж-BUe[D4q5xfX4 z CUF5|t I~Hb$ڑOԊwIܽH`z'xɠȡ`PA$chB]1ly^$Nu}wFS{7Gx$OUט{FRA7We!Y'U F:k9{:iJ xeKȐ(kIWReC[eiL֤6_N+J(#IZ2OEOqLڤdqsHB[xN#+4K*JJh[&i-ޕsFRG;%Ј8W·tB'##Tb/JS!Yuz!Veb7kա(BlYWKp܇=ġnw7zORxKb$REUwTBҡtDcϗX+;A.A\3mUHY#P;p?:q_9l0ԹTYB+tUS6x~N\~.S>euM.Cg-K!N!M5b'(w+%N19~uʿsΧ!8r &Y1t0"4ڄTڮِAq)\9DӼ5t<_8:9Գƒ=Rs'dь4vדQ\>?/v*g;up/C<ˊYJe:Z~LYAL Nt6ơ*}7pvJb293Pqh<@0²}a;aW)qš#yڬ-ĩeQ}d'xޏrOaSrh MhHC|9s) CuW͡QNU1b1ԝv^ cbFڼCj7\z0\u^6P%k<ϡnTGŘ8H5M>!i-(3>cnxGsaZNީspEP+""\9ȡWDE"r(CpEP+""\9ȡWDE"r(CpEP+""\9ȡWDE"r(CpEP+""\9ȡWDE"r(CpEP+""\9ȡWDE"r(CpEP+""\9ȡWDE"r(CpEP+""\9ȡWDE"r(CpEP+""\1+IENDB`T0DdC! _^j E c FAE"Drawn\QUILT2.GIFDb/( v(Zr/& nj/&K4I/v <|( v(ZPNG  IHDRCtsBITO0PLTE"""333DDDUUUfffwww{ bKGDH IDATx]*tW 8]2Ibl^@$"!D(CP @!BB9r "!D(CP @!BB9r "!D(CP @!BB9r "!D(CP @!BB9r "!D(CP 8CҪD;"B8hjB3r+|# CgҰLjUp?4sdjb?q=xu 8fEQE8CD*ry !,$@CQy*ˇfe_[c7.'}ԥ+$ϛp39$"V_L>6}Yq#č䐼>E3=f,т*]>ՒyN]ŗ#¢8CuWL{JȚ"+?yC+/:y ʜ s(9Z [@Y!9Tl~βrT6Vr4S{Dzx#y :v@6@iptuZ2.搤|o*#(B|9UC/FY~BN>qG#̨bCg\:mYòlk;`e6۝qՒFClT&WcSgWvgy%Di59:wׅWh6pbH5fN"˷>̅LmRPzOtD曶g*h9eU-T|OC\(3-H=JV^sq 4CC<RҒnDXyzn+e,5VIoV@F\[w)X"KN[}; yX9$=4|h'l,SA%>bM\쥖]3餦Pɭ;O=^"W'ZIozؙ}:{yJZ W9P5ۡ+Zp4DU޶ι:Ip\#@G!י訡 RsT/ϙcF)U߬f꿸Q)fBrH_;-V{DΈ|0+Ht*%%*wdx9D3Ϸ޶M4Vg[Y5"h dyUF!J/XVMFY"*tMJ+1|mK/x˯2QƦ7Aa҈]hok1$# Yh'PJ/Z&+Kyy NvfSI+6WS&,%AtB剘CdfT[X+/8$J(6r)c:-bYڟP nRbZꌊOsg(*ؔ8Tf{I'ME̡kI, ^u-wQsHc=,ey$zUJwb搲}uXB1WN-s!9ĔR[=ƞL]AC"ON?XTG 7,3$zG@O$@WmGQ+'  UtQxJA??}OK ̧FSCWhc\cdJ„;1Dh~=ݡ94Pu$O+=$1}B8r9,-|[QshAf]:PںvuՍ kͽM-l*TR$]7_r\Rb$(իȳ<+ʬLgYeBY{A^P4=DN&Sj'VE qshXsF[K9?O6gmf ލC|a+G6É4uSUzXU1F{849DzI>T[qo.nEXcuW5r a Sw9&3`EKCcJ"WQ(VqC5,Tj*ƵKN$mE䵰=jRACbQYWݳ$T ,c6VhDΡ {vxr6 n]U!:GC-UMfw;U6tFcY:ZLm@ xCshړKՆ Vs@wsWҸ$4/XǸ\JhzQ`;&nz|VM=1fX.ގ_]؞\~R\_𻃟}ظ/ZM'3.ױ[q>RӮci" O"TVN!RjaWaFhta'˩˝gg ?;~Mt 9V..8q)Ճfk٦Sϡ)گGJpk . mGNߟS3>$Fh RҦ3~+뭘+_*4*ah>Ra>.lCEG%} [%QKxlCbkw`ʒ˻7~}8V&j[.lmOx n$۵WxϞ\vo_a[:uG|\yhwWO^ԅlVb]8uDw%r8v=azm# x: 6E$|N%9y|"eCr![*Q868QwL!!;VjB|r4 z4C8$}InRGKmH.e#뚵KCSxt#ZQ[ͳ k &jTGGsA0ɧv߱uUl{Cȡ έpD<^f1]Mf)@b[f`1vԯ]6yD84+6(w Ι[}nQV:Or9J>g04_UKFM^taPh4[7m FO`J{'Z5 T=~Slхo2CƓͱiCp2uSbCtȉ4AY6]Ql/F*FPn)_b{74&ȡl:B=PZ/Q֐X6!6!Ӧ&isƞ 渱)QQfnZlgX"9D8נSay4r( ¹I0ϦuzCtaad4UN6=[JC:lNtyXv|BFB3].@ɦT8FSu=Z_ 2BMR1mPK7O]LZ)gۥC7fgIkIn;ZƓDd"jfgQ#N;dk "jCA3hf|ZͪpHhqvWHt+ylZ} 8S?/6`S,WaL^!͎kF3S;-epHoY *.BŃt8ٙ͢{9T>lVIXP6G'P,cNwBң¢)woqlut>vyM qSѢT73(8n.Pwhmi)qHTPu?zmöIzBJZt1EWEKP%~*D%R2k|Xّ3z'\Y LRZm5`j\59S(ژvBL6ri6C%IC Wm 4!_~_;7)-G@e)  (>L\gj-KC~Ec &fBgGa=kiqh.lͼ:3DZZ*aiqhok5$i &]šբL4}#*xe^%ơn| &'@8*C:1UzZ@6RBf)sD&&!G, (8B.掎OՀ8.TvE0Rmuv Vv[9 q}5 #l%?)U}[X=M i8^̀EiMG@ATJY ef$ǡb7Ӧ?/~s.5bqHGA&b݂١8^AoH#aMe:pgzZGZ`.?>ԡ6_(P+r I4`ǡa-zC! yJ*z}5A3ˢh{ x!b֩XRI֭mcAc)KCwٰWƸ{,erԭB6ųv=^20,erȴ9g:` CaR. A`1`W6gv|w,]\ *MV366Y,L:qy3^dfbGC>e2}:s~Quy|2mA2V8JM=mBp[&ut9dI:Z clzJ[H~Pm"t% y@7( R2ePJ[CcL5s0:gU`>-%شr(V xR2,e`$7q=9Qp(1V!:R9ؚ7g^mKX[UθŔ9d^} g xʆQp, K\_ I]+˾0n4IsȜ.\??dQ7>IsȢTWpй47 2D'h]j?!KŐ#oӇR˾d\UE ײX]h)g(10 D is&[Ir >7]X8?ixBࠠ琥h7@^ı&hu $![st[&ZUC;>J|ܕ! `-SYz")ŵ '!X 0J{.;i,V!k\&OU|س!b-{pW0˅Ŋ;`HC֯ -^g6`]žO1-@#_E"s,p֔,F"3ѯqE6?VHCѿiACd]ᛊʱ"VRsȾ4 .غHhkoY+fq;Tg/nKYcfX,xCj`+cbFJ:Cʳeڗq7Y `lp]-}se »ҭPGK2ue;jceP~%o܅4ycgzn|a(WP!@>l[ ;n^!g汾, ŎJ:^!ch npdҁ(z369 QWBqHN@Obch %]χ4C*C1<ਥwsuխx܆(V0x{ 6b6y} wjur` uƁL\WA/^!GV3C1 8l }`w`:XQ}re _o }88ǵPZ}ΩO(tut~p.^y:j<'J}Y:r]]BybD[y KÝsnȡ_(m)V-Ѥk|Cɏ*&kbe\կs[P d Q ?~Os!2cӨ7rusȥ4ؔ|o$<ȢWfz8[,Ljrȯ$ *.IhɩtC8SY`yU_D.GC VYEf1t l{ gٙ /?W?blgGuz|fк*H +cm>I[կn3:CWsȯe]ǔ꫱4C@^]Řn<@H=jm#r?o琧/vK/Po- ПKKYEZ歇DGCUu{-6Vcw+85bvt.XZ T`CT}9;̕pHz^* ѓ>@3 q"iK~N x=RCmݧxXdFy~Iuᩭhq7Ҍ5J|T>0?p5Ec&ڿtgO ! C8ו~({XGK'!yyCvPŪ]媝9μÇJo_4ڷVWkZwk]`kO̐y)ڭ/͕KDmG[n}zZ ه!$FPKq>'ޜP ]57;t/!5\[+gˈ hs]}]"o8r~G+$IDAToymMVHpۯԦ~\Qh[޴%ڋT<@>'o 1{6,ڏ!I?eNWm<d3Œ܂ C`c![с[~Di䋯 +WW*- |s5Cc849$/'c~tKdkQ`/,gW5n4D{"Cl[|}}~{.CW7؛09![0jNMҪWPj8.] om/|*a,Vǹ&^$bf̫.k'()t+4944/zluSװ#jB6 R΄+ee|l`*/~VřPFȯ"t 4#Ax #E9J}7odWkrET`OESf+ǚjK!Y*w3C^`ƌZL;0t#Smrbcr̦? P1|ġ;Jm旭 6DXb-*WԘ!z[C&KDpCjERUcC{?VMrC Q!(VAehsky A(ޘçrCjhRͫ;ڋ$h?**mgj-RwTjC vC&RÇ9*ZBǦHdʃ:NN[d=S*b(N1Tȡ#P!G-pM*ش!NjSmN::U,MxEjQ1G @;ӊa={Qbrt DazT*^sd ^*l qP SLx4F$d}Rlcll Ae)Tz=eՊ62PIG92UƫC*wkGdeO":3ȡ@(յ*Uʬ&( 5QAS}*9YQ\d=6UJAcȡ` Pȑ22kz  ʊOp쳢/+S-: /rԴj$^N NZXmi$= !N͗>.CT@%W++; YhD#H S59t\mIV)C$*_jċ̽FyH$\Y3eJ7jD f/C'B3c5ґ*_Cgb Q+}Yw EƆW& ЩP˙(k~:_R5R29t.RR-^)/JU!mGuC'CnL蒦rtnX;Ԫm}_#CCǹܱ3R9t>T~^\P*UlB]IBLESNeslyCVv{G(:;OaA (A XB@]>ĶUrB*W[U,S]0 .mhX^B!ХhmBȡkQaS/*j}i9t-Ԣ-f:brb4UK% 9t1*MYZ00CW+C$< errt+CMȡQ/ф6-1 drp=TmrNTjG(ЀoG8$zRCro6d OqHE1O-rBq|WtqSs<}zUۏ8/а W8$rY.W C⮐\͚V;qNf7@lvQɡ,§7!сCd 7qV;dwrh )v!Am }V5}Vw)|<3{W23!>lɪq†-Y] HBjKF3aDbQ =B(X^Vy z}i$N:ex;]Ks8$=#FS01J\K.(QPUU%_9*}rn_-& .ruv/PO8.%R{6P|/RT)g^ơ!Z#1V1'o[tJ/ؑU1C ZU1ӌEC| Cc:MRG#F|9T@/HwR $i]O#ĂC:䝇wshT]&z!觵L;kX|ֲ6oPlgLbt9ԏn SF)fѫiͨ 1&c~x!v8zi;6udabe-byRC7Q-[>\JkJ\JyBūS2HY5"4(s^]\Ґ5j-udPlSˍO5P7DmBOUCuQKIޮ~GEޫB^5vۯ,SWI{5 7 x"]ednQW6gK~*Eh' U\pS/UQv+QALB+6Q og}tu|V=܀^y T:ZdBWb;骏磖*8uEU]` U 5To֐Tjأ]Wp/T5?jUNTb_ uܯpKUC]^Ӣ 9JJwj>!tDEEυqIUCz&yr ֳ{jHIߕ5.5k=AJv9V#]番>MCH dɧ; ŏYJ%!RT"nlPd 2KY܄LXCIb-FehSs7%iRS畬dYuNZPٶX !-ʶŤ!VW@:K}KX8T3A\SأDKWC!_Ə_wd7Wr:#)I-I.YnA6R ok_!R}9J6휚I/O$tXm6!dO=] }[rqOo6MꚬKH 657jHV姫:f@Ule. %QSޠErhCSLf)1N5HSEto%m\|9. 5_P[PQ~pYe>NZN\w^&s|'P6mp7Iks;q-`$!aJg&d ]gӉO(),ԧD9KZC2ʑ˙Z ʷmc0 ul^(=eb2u2Po.EIG%F@S"4Zȴ^θZ$~sQ4Y\&w(q wegjqVÍ`׮7u-l>suS/JB=UFe09P2_uo CUQEU* 0(pQT} JL/?A` uo&-kϥ:\$?=HO/W sGxZ便5W>{!HhUQ'>2ؽ`W5S.)q .r{/Q4ڣOѿ$2gEUSFf4UOnv鴎 W;|F]REE5[}rW5ԟ,c.Evj.'!-JJ 2%!U FCgQ@J^*/k™;^&sڮ!:ԋ%/+',꘺j.Dꃼ!ד׼{ "u OM7>1q< O_2߶Qb܂E3u }Sq|:c@*!aL6, U<̛pZu>G$ {fiO2<^$aP/Bo*$. ИqE6X01„;6G4>f3Y4-kH3~3H'ͱ/l:F~*3!Mp,khLPk'~8[2􅥍*j"ld,_۫/5O)s| G}a;L5ggָك54ffZ%*&FV}a~ZMc F}sq3} !e>;G /=`uFxTg̥C|ڇj lpg Ԫ|":{=/'6s*[C Uj+WD%Z=d>V1rI"5"t0&|kVk!`{:;!m0`wh4]d*G}[uk_@Cb/>G"I/kxZN54zs+cS +fߺ[@dzzjߟ۫%g8"afz=J d3y^?9hkDn9"`䷵M&| rЧ]A%1EPj],4GKH _jH[l ۳Yl+u; Mr7׿g_Q/lsM)9V߭)98i9靖Flf1 ]Gz9 _ӡf4桡wkOg>U2ؓSCCC$!iKc]j-( dwl؆w^{VR"ց?nݡL44s ⼉V^DGyk>y[w( ;&e=y$of 3R%^Ll2Ьsۧ:~D7 C/Y=^/;sc\AOΧ_jf{>tn;J5XL+>q7=0"dDDFZYș$!N)]y]@-HCPTL`kg)IC-b_K^.p@NZծ qDi#&:V-4j8p`o:n8-vƗA8K5~ONZW0rueniRy:jJC\Rk!icoN]V=b4$VWR;9'H&Oqitt<9`-?_,DCۮn7>ڧQ!h=5Yih7&wzz(sm#UdyKC֠l hp:LE]!չW4i'Yy3wڜ!繶*;45M$5~[}fkttAD73 mS6c,`ͽIwldh׎fc4=dU,7 m3Ѹ9swh[y ~h8zTsP 5}Oκ'l v\o|_i2=a*>;q26,; YB]]WÆq"vgי9;q^xDq؜:\Ӑ%(kJDG_zYth=\&Ϲ3t{yߝ%dq%? mwf:윿ɚr/Դ*< 0~rԐs譜42uO(7x)PC"oNrL|X+,d!b&cUsX},IOay(XJVd!jm73ăsG/Wd!i= z^Ł%#+o&e 5>)r?Jn:Q:=a2稡>6=Pѵtg멿vhrupd:="O=,5 WuY:`J]=/YRC;qӳ= 1)pA0$,5W*o\#k!>SCdyN5w+?r7:Jt2c~+|84RteݰYH7aR!W {w ]ڭ?.UCr7Jz4Iߝ!;wڳݶ: j``8*ٰ7#CDǢiK{ //\Cγ3[a̵xf~-pʤUajh㶂VYW/流&CZݕo3'؂ky5B&^XУ,mèAM iZe{.;ywۜ_m5tkkߚ{NdzM*YKd;tI1>ԛ7|2gvϚ ?f"CgU'F~F:"i{,/q5}wi<…5tuus&O#}|Z=y+ݏۼU9"Iy2FxOe~Wh]tD~`BqƵEZ>֞WhmS\,|uB CCG+( 4[j}TRθYVSk] 2]G+ޡ!7pmţg@_wh^1No7N(H\( u(KI4mt^0sCڻDC^VD[XfK6xdž+x4@ϥOSzC]&uPBa-r"r[MfYd4b '_Ok_Cr<ċSWb!,N2MWLCm[~hȧ i,8c8|Yi[r!Ґ(\^ҐZji&~oVE)Istt7d_Z?Ç>!# +} ۻң=guG>أ0 yu0q~ӳeq~s<GfGA, ZtԐ ^Xm I|'HCP_'jTj*OzS/dSBr \=Аwg>P7R T:mTEGnfol!hmk}=T]^˴Bi\6eIw'_grr.֧63g5 dҹ½̻]!f+~GwiadžV{א,>bϲn\{2l᣶~cJ5pY-*\54V\6y^6Gݛ L =|UАStm^chr޿w,ikr#aiݻ(ԷIVӷhE]h~G?Ь՗@x0Njiȧ5ݻ jYxfkG0{{wg^!r Y0!~W6l __^)ЎT\jgDL؍P󦮃>MQCޞdrHfe'{) e+RC PcrZ&_C+a;5$sN Դ[ՙQ4̘\14j{f4Ĩp&ZnR^R~l0]~[2JK2zR^p`4P(Cw %=]vk5t@Ѵ8iG]Xq;ytO8|YCsj|x5Okc?[5{֔ ?K^!#JV )_m'­5zB{n'ox[;I7kk@ IOhptXTB/אr!EmBOS+xYuzDTn;2͘c *5\*kH('j7o{h5^fC;rޯ!-&6L:F¸r*XB@C1qAQ|*qfgj  ZMLfL7<m{B|;ZBBCZDU]jL]xcU[(,+V_h#!=|2=α8C岾&ͺhT9>~ʫYwY6̻31hHuh{U9h?޸3e38]ֱFC^v3Uo5EQ٢AFGg/c\hOkty~ƿՐz>}w}rb&t^t$ի~dЧEE.Y|O E39a>zGV!m1ru3ex5\Iԣq+j>1Fn2bnR7˸ aMfH(w>5B@Czn{={cAN`:ak5 QIDAT3nz#А8us|MKZ?3Z|hZ 2l*21n]B4;љ@1H}:$^j5~X6OzO|9͙о/`;3HjS zh2X;cܾmc~5&hh =1Fd,HؼSM&3h(-lHwX6-Yh}Ψo@C;HN#u1Khxe.Jhhі{"cx"5h:@UE3ūRl+6Ed  ` D,*h㸳6- s3:6)u#@C~] W3˜lu0C6ދ% А4rim{z+mtD< А\?Kc3l_;sK](I !7Bg%Cq<>\ ۥ7;q?А+pP;4 <ѲR[ !w)ZxEiye;:Pj6i*<xG4&{Kb3ۦ<:yАKc4s\uvgX@C~hd40c"4D %@C& ̨GH3~@Cס"-!00QjWhB-hLO{"J ]I]j_u4t%o3^S79U/ ]J]-`..Q;d|)GeQnٗQ ?yW ;QB鱨OHbc @߲E5ݦahVYgd_&ACv̯EQڀnE-1j h^*׹ 6@C­/4t;Ό'8 y>͋!X%F'K~!f >DN%Oj=桰(z}PD?5":>Ǻ'*'5@_b4$ } ky쵺o0⑟ RClPW~q ;pbzKFVlVX7n藀Z!^֨lDѫ.D:1v#M'n͹4$ zFEy_gOs-MCdjP-7R_]4d<6WO3xR~|z$+| ֙/S!4dRWXX;XXmUr(!4cڋV~iǢ5iWh#69!2LO^ 4%z 56V{R @kHn OXCaZ6{ϧa-e6 ճU{^dr𵢇{lò>^N&ڍĈ+'c[f6y3ni+3$or<;ݦ!QWDҢ**+["'[κzG>NW'ucR}-œ8cɢλq^,]:O r@,!  h4b X@C@,!  h4b X@C@,!  h4b X@C@,!  h4b X@C@,!  h4b X@C@,!  h4b X@C@,!  h4b X@C@,! H)WIENDB`,DdC! j G c FAG"Drawn\QUILT4.GIFFb+ Ϸ%+s n+E{G1fy Ϸ%PNG  IHDRCtsBITO0PLTE"""333DDDUUUfffwww{ bKGDH IDATx흇8EeoG"`P{vgNnxHTZb X@C@,!  h4b X@C@,!  h4b X@C@,!  h4b X@C@,!  h4b X@C@, 4dW"^C5/9f X qj[3} 'j(5F#*%H`Mocf!;Ӑqr4i"k chBq7E{@ Q}zs*2 'QhT[Þ9sP#4"X y/}r5PC85o1 9Ak L iEV=V1X FC4u35 "ԴрሥDo#N1i8"S51fK:/iHcoIJ|8 > HN3ByݧTѱ!@&+V,b!vY:[ BQJ"mS5dݧHGech_ҚWkT{Z,7IUBF[B/QGle Esj% ;TXZ_X )DMf ԯh$b` 5]c5d1n>a4Fpc4Zl NNՐ۹t-Ir=6"%Vh^K)oVqO(nQLJ >μ|fnO87sPV)} e逥$rfUI|Yh=[C_*ɪmHMlEmL}#&^m])~uDBJOR3vBv9Ӈ08Az뗛Ձs谟utzvkceY2QdÇѸ;:}:m]m$^U}1T'^Yբ?3FuVj֖VnSV,ӱ]3ҹil {n'NROƈPDB!3FuA['ki+Q+xj>Uu<[CRfP"K/1ڸmܢ0#{9p鞖-ygѳ5DÖ'(Q8Em~p͒;zE%,u~{*'y#i^p Űf#E~Qg+I ׵㷦UDoSB-rvR*E&8I7-X5_7zL|K̝IP_Ctt5Ź왓[ka hvH39{Otgc\* LCkHg aX>kMCnԐ,tF/ 5_랮vpSÓNDq}зua3 uܬ37CcYni -DĢz5gͼkh0u#VuIZ*a'p54*_-ѣU^1(3PoV/2>Q ̥4an=^CSJX:?Tެ -N3Uw_"sY9Ya3<XQus+<ق'8j|#Dַϒ} ekvlx s yʳ/ECn醆ƒWm^bHu:'ixE*ECB؍_sxSXDyjAjoڸ&j̫:޿眂ؚl5Mˤ!woY%mmeVw8Oo&94w4՟VuhSC_AIx~G&CЃe~hueg++ICM4/ T $kևu XH5 j)0eihɍ^C=lLw-CIfp'NmeEihc3sK֕"A(fwo4kt^m[6[Mwu^Dlzgv^ X)yi4ןD]_GHJcNfѾWVŒ2rx`>J&qw+MC|Zm*b&]-Z6$M@-rP.nu=fVѶKaEvMķ5txFCeDWs͂Y/ K_$_"Jq£VS:R1#𔨡3'v":Y~ۯ-,z*rTn$%jhzan):5~*RCƖb6ddG RSGɚ#\9G-RCgƶvn~щ]59gZ~jHpcD=,B]}n]=DL ]H`50ܲ~4[i gN\jJ*Wus6p̪Œ?O}P ]sIRS^l>s)HZ&XJY'ZW5S`[f YcYW~TR5tcyEQQO2})!qߢ5;P@ԍQ 7j|9[VPQAHK˹ nDvhݓX PpY1վ?PP׭?=OYj(µ"N3݀ S3h{ǂ.KĹK\b2鶭1;{d$;aezњ"J ɮjkHE!\5;iy Seg9"LFuZ=ke*,s?.M56(OՕ!|0ҹiURߗ}am")!Ş>电ekMp-FhPqOl~fo&mA4" 6ýEk(ͼ#z ~3sJF:W^p?Ek(Y5f2/BD_=UlkuoR._.ӯxt,ԀK-֐*vڕ'hjl|+IEVvoPϟw*;$_i]!$}2za.\Cn L~bT e KCKP/;ny Gdf'YTuH1sޠ!#q,=&%+j^Tx@};Kb}DN]^?D y%CЬ= э%vwgnhߡ!gT+lȄ\HF2VJ4N,4u4rah,e=zcR_,i= r_U/DYujz\Dm]EIJ-ښ]BݷԽ-z>VX] u䟤 ^ʂ3 2bZ:+Ѣ- Q]WTPLu*u1Ai^W2Ux.*RUa4O"DyR#FM*tȹu^ͧ<`e.Kd~y.ߣv4l!R4i e̺n&YٙB,a7ivӿ-ɭQ0s8 v.8F4Mu6uW<# Tc ̯9*Bs%{WƳ˩5~@5 qh:,@;ح3ӆ_*߇M6K>4k;3m5[e9pmeMЙjӠ 9㼪{ZCgt2ڸA'se>f QC<~f =ZPS^>dbHgT;v뎮Ęzjhq44ϗ)DSGlH-UBad3ak eK h(-?n8vĉѧ '8=P uT ]۟޴{#h(fSLu̬M56V|bv׻  F ?nm2|4QSee PUwL-ƾMqYLWl8Vh wHN3qlwEIX}*'Ǔ/9e.mBm.Rc"_(TgVsb5 u+t⨽-&wy  n3i(b 4MNձ-Iyש E\PYcK}R\ IDAT&kP,[lwF05r[be4MgI?BvFFlzThcd[914 X n4=4 Klp|C#Y+@Cp>E;U4 0m[#4%JG4RE:-h(% y)ϕ % FPB8޽432TH۳ Zxkh!RR!ΗW;J슪/oIܭ 4A3@CIqEFΟ{p@CIQ %^bGh(-]xsLU=]4$v?Tf4HF!s %]7m]2h(1=?Qjp % ] Xhh3 {Yu a,78Ԃ63/;VRc[.XD4@C % Ow4׃4 t앁2`FrUv ]IRVʀ2Pz]\4sQ·2PܕoeWEȜ^LPJHjHMvַƄV`^v@_|&h{Yr[9ue9T`'%,syTSv1h( ͹N0bPNyV9vՌ2ќKݳleLS=,~V9Iʮ eAkxLH=VMm4 uÉR\Яuhtȳ et <{P>26 ~mF}<瀆Q}Ʌ٦P62P62WVt%|CyA 9 Cʖh(ШHt@%;-h(+?#=ʈ88K<{PVAX* PN~RyPNk=瀆r"È;rPN k!x̐=טC4{Η|K e9f[-h(3z'uo^qu4zK݇4j{3{Klh(/b;(^,kAC1v nEh(7V|uvC2#=ɲ4Fe-h(?d}Mɲ4 Hvʍ\e {9k !h(;Q͋4 ^3f4'92 4jvuڻ~?P~2T; G/j<Xn^j<K4tb{E@C 7E{@C7`P 3@Cw@fLj-\1K^U 3怆@|1:4t QC]5-ɨf4t 3VC{"mI4tfj=[Bj={d=}[Ҿ d Z|a4t_-h6zCzI !s"ې>0d4f4t[mǂ:@Cwᷱu5]={] 4tqgR/y9 5dJ+5 }5_iB,N Uhe*l[1^RF;5$uHC#MLEMÝyJحNGR]TvISC꾥hRE# NC@ɭ/wg{;5ZdӐ6}4t{/!ӉǶ DWf:‰Ԑ\2%o, ַ.D-H+J!)õE7o,4+#D:~֡pG֜+_OCV2B̾+#󒌇&ߩ{I6 YB:CPX rů0Mb.iƶUc1yd 9^Ƨpd^ca;X.~m"v(!\꯱#duOctV]t pjOzzAĺT@_nޞXC؅PPJkH5eOcJ/ ^6ob*^f{=\>x ތ} 6fb?&DElmTuWy]6;/㞑H7эvf{Rl2P #RJb(ݯ#nwb҄\SeRbgJYԙ~yy#Itj;]@P$"%) HIEJ(R@P$"%) HIEJ(R@P$"%) HIEJ(R@P$"%) HIEJ(R@P$"%) HIEJ(R@P$"%) HIEJ(R@P$"%) HIEJ(R@P$"%) HIEJ(R@_[us>yO0@}$" Z`;w/?. Q $o)Q<CfVn"8- 9S0?;l.[6$C1D r\s;a Dѵa8ve;fFTX9w0Hr]JaK{~aIOx;w?et̘g~\[gW$ J4H"3񗿺ዌy uk{hBE9E 8Ayu0ח|ʢa>~O陵[8@:S\!"ٻ$DQ15N-kw X-$g]v*MqA(.qF;a`8@xcH'5AxHReWhh,x݌9Z^I(GhAB1C.g+"^Z 6Z7LGb- GZBg KQAʣD;2_ =sc$'sYD,%#Ե gPvo_vOʨ-+`Bsk #*~q;\./^GDmZb K].@  0چb*eLVG7SDB1]E{JɮX&1lAB$O]gzh=|CT"rAGPz{KѢ^eJ2ʮp-$\9`2l0L"LY.d^d6H) ^KB1g\ F@s$y 1ot /fR$t 16öf%zX" q 6tS׉ b,r]wP$uK!z`@c| _gg{ 0@V[N`=83p&:K-\;B1T*vY <#T~Ro*A7TS'F"QClD)e^7T$TӳChPb fbXR BYkoĊ߱fGQQQz̴{2#=L)' @ aL?*/ދ@S3 )z Rh{aCĸoe>m ?>I}QюJLK_J2WPԇ|̐,VI Ѷލ#j_6}eqˣy"ЁZ=RD}~)k~t yTl)TTkFjDnXQ RdQKN 1,e`d.c8NAz L0qpv^=?8`m*j0em 60_R+ y54QM3deo* ܠnh4A`a7 +vyev5+1J?ɨ8#}QROE wg>}wj\AaW*iωbz#D}p7~98j[C*x#lAa2³ҪhȸiӼf>3d2A6t@6ENos_}}C&M(.V"3gDTgޠ`}3Y{K!_dSEށdZ\z&р{fRHᎸv:=M J$UC޺uWc\t ∍ _2W KX vJL& W=M>_SnXHKl ;{rq5́`fЏYԧrg=WZj4bG^B_*\= G0=J$KLW \́'imJ߻4rptܪ'\ȸ(Ɔmx|(w Xe t LW9Id>~6WgJNP0˧Ze!p7#`#vg@MH$$T`.xal&=PYasLXedl퍓1tK!:1`߀2/qw=AH">7Cw-'_ח`}h1iFFTܪ'@B튛 {z>xHDE:TY:Fokъ*`Ĝ\Sp{~< `4|Ϗ !cjH$]-^5>B8 p 'ȡ_`4mL ¾/߅̱5@ r#6" W}Ʒ_\gPx8 u;LGWԠ68`T0S  kTd> s`|Qۻ@wE;' FCFFp2KPըLMgl)J7H.@82+khhs~+###کݖlܺhP덢j4):0'VƁ':@Ub 8OGGh&ځ2!2mG8˴e  oOQRoSky2d0;0T!Z%*)»1!'6uk&́|b׭x䟂:NFy+kw{8i8-mЯx h+B_o/1LaGǟ(|\EK`268v#rqz~o|qCYY;A-]'̝rʡ+/rzWޤW|27V `Ʈo>c`'{e'VyCϝ=g 7|-I-@rMc&5 xn7T@50~>\ۋ/ sY+/`U x۲چ̩Q&+鶝۟oy8\4۟6 =x k&;?~5oYd1*,}k22;Pi7|M$jFn .om-Es?Z Q:6?sx9 lA'h磯os?A^Ey€(߾-df`h\OAd1d*V7 (ԁYPzgkә-%X%26Lش8tm56-k.+2ֿ U56Lj\sږG>,+(߶<8?iG_~(߬$i^{ Û&/ cfq-SV&V¿>de?LppL7e ~%'t y5HuJ٬o?FzzXEk))&MOi\LY)7i0m0Mf*w`@l &(kۯҌ{/USTۺKS /|B΃8"n}η.y"s搮FɲfMeYJ̹/:p]Imj?o}[SJG{K:R7YIϒ KBd;+$2Q k +ᤡ(IRC4! L4 q& iq܎ۤ!w[:7{;?]@Hy+C9{|^Erw#`O.S ۝o:;u rT[xbnX5T;E{#0x57it>j>g9?l~L/NEMBÑνYV8,#ڣ<Də9}vR<kb(_|gb iG^={ }ާx G}Q8y>8:-ȟZ?0 l։UF Jw(t:Buܸy 4v *e> g|+$+rj UMw"m$le(P+ M8L!gncM;p&/y{NuѾMړgxw _~-RU*|>kؚW+H`)&xI%4Lj@ԫp0VI, JrΧ%zH6,m!,/nfXz*3pb#.jPŒHMt1'J{JZD w4~,GL @F6YW0\3kVπ!ebXR>S2ӫ. Z "0ڝN81i=>t 0n)~c ِ$Alά?G"YiIl #?>թ~v9c O*};$l>TIuFX=ODI좃Z>:*`%kg 3=B h֣PآlMDl R d#xGY8΍.~|Lc=G@RjfcۑevY̫kO o_Ә &01iW_.E< &9fycUEj喡L=596I`__?a@O <nd=}ڊ#-eNu Mh|u*zb.Qj| $<7w6?~z!8mt S#рzĂ8Љ06顐mYw9w,XO/ن,fՖ062cO(nj"jL'Z*5*h0᱋oq g#GKay5.#ˉr `E8cG^;9'y#Ϳ5Tr'~L{[;vQʄl=tG^tnz?NHQW^ϟr-t ǁ%5~⦄(#=-VANڍ,xR?1:I %.ӺP'& SH¶R3N3EUeGxz0U W/#RBi=l z.1%H‘R'i?%HiPU@v#U RBd)52lz6lHN'y^7[&͜OOL9##:ʸ :( @u?we e53CaS4foi=cN,'YW,K`ؓ$MMAlZOhFnm XؐY;iL.ɢ?m:(;]+9Gt"5W!ÚkT?8rfC"Y Iƙة7j)_raT~K8bT֣xZOY:G[{ma6Am Fyǀ ^.op\^e\h=MW]zBTn <ǘrY.Lx-;kk0JGr IX0b\c-`zB,F'֓yI> pSW;WY"4f~#YG_lZoh=푹cAXCT+0< `'| $?WaHR:$I="tNBc;Ţ5uMd%fjos_KU {j2TO F%5qS5 2#)u\zݪr0WEG@o4F?S-PeA4Pi IDAT~9ټ-K( >[R;$ms?ڛ=ieGHLڿ2ثj]$rqFclUNCm:Ys@c.As୊>e }M\1, h`t8\@>YXՌ@uۻTJmͳTYgmVMo1L))clu 7\<ӍC@Kh'a] ?ߔH6)S{Mq #0#4Me ípu}k}cvu+7}$7uGjiQk=U3U))̢NhZUsE&v#a,#, dC}b G`eV!1=~ ۬d˅+@KjsDK2bq zc[!"|=T*1yy_ojD"Z4w,t}~E$.GcOi= 8٪TE{SpWXUp%w/SRW>i}˵A`M.TO`B6w UXDxDQtQѝ/ܽk su"E"=,LvDjCMa]4s( ų/u%%uǩO?17w|G`=ͦ3HCt 3D zCn;E@JAEO""!U1BnRDe̎l&ţ<<  /K¶B=5d_J)n8 θSX/_Vj:\˥Q#\E'!y5E5;""֡]Ap6+{"Dџ\r_R[;_? lG@5؆o᰷\tonuTd{R32W&znRg4 ^w4tiժ!EnF{K{9_tvGv\C3΄RmʞBK͠ϐ{8J\LixVl9 <jmy0?0˞">m0!)N\?3vv`Q=ł?jcjOϪ};=22lh;E⮧|&%M[.ru j^%%UI3^lU^X-D3qn$[--a[kЀ*y`ISpɎHxC#a' cgPm#dP(3d͛#ڀܲ"DwUvQ;wU4p91Hz"3)I ;J!axFrXwYjj(h ̍+;2jV&"X>{Tt!~yDgC^Z }DPŘPW|$ Z>I EX8Kh3J z*YwEsG Zj/ i!i9eZXt7Ӫ *mUX/TXR_rj7V]Z !S$-'" ģ$͂}}Yz7 wLhk ܁N*!ԘAԙiԉhJ{pUYh\ڈ38ϥrP=P yK=r ׮` H^X/M Fp X\*d"` r{_?oi܇}v:!X=D;"!N߸M賯"ׁ ߎ|[t6\&TKs])$"=&V1"&Sv.w>?x]QX=F ] k.}A=j  '0ݓ:mo{n[\CƂDJ ʞM3Hiȍs=maÎn(¡W\tw/)Aۥu,]]KِSr3"L$ Wmz,? ]64T㓬&aBEAJPhf!UT 0@'AI yy%չpAPfᎎab̀/'` >-'LPų?"\͞ CNRF\QZ38N`zp>Dha=dn{AB8'Vz27rBuCfLC-aDGOfvtuZϢyeQC3"ټcK;"47EWB>i~blh#J 4Ěea#x"b$YÄ=thlAʝ9l'! u+_֌ .&YӖW:5R=65[(J [5o(9^<|# lV`=$TԛY\2B! lAِp ! Z*~cwK݋!;W+D@^׵Z-2]"]E;_AnA UJ~Wz ڬ=ٹ|t(z)/ v W墷.nj:.1Ї,q(2*2^ 0nʝT8%փl0k3l\]a*&X1bl;)3@RәP!uuEXLr,·lćޘ̍FGd8XloP9(R>D?S;{K,<ⲳ#zAJo(Sz.lV=/TAWa;%U| zSM+}+ U1~tDMb)+R<3ț=LRaLӵBSLDcN f陫qh)RUx8\ m-[crCNJU,]QwJ])Mɜ?%?zX/!EL΍x.B3Za.W5LC. '8l13(tE8ԫgQ;tP$UV8cC1`Cf `7M 'T,z?Ǘ|^hJzL>qrIa=b|HqtG\>{lK^ ԣ[Y vB7[[PLZ R*j|<KXO?8Bw:BHvuUHKa| _qCXsN! Qq>DF=rkv6uV=g w[.)8L~SPUvbxH; (zbPC@g^“h&!yV=qCqCSG뎈Bne|CZb]eQy-KKV-g3Q20'y6ObSZ^҅/9ktY'~N&ONfL"7Ѭ@ 'j= Ņh@ohXRUvSZPXػc;}%q3񩫏]c}jbT Js_8~'Iz/f 27-Nܲ87ӵsȽ۹ IFVKH& ƶѻHvV*\Ky'[U1Ve0ZÆrP!I8ē# t̀ =\zpKl^jNe6T Bgz)]!#B i$_ ن;0 k{"CaShn7[bQ6 əј3o.nt ءKԃ3jsXLe>$-bPz!)I|lz"BqHjوеjZ!)znx` zPj,qz*;"U a$}*G-pPV}wSffI3O Q&Hi`73WƧ=D1E改&QiiQ68Tkp׾v} )[]\[u >Stg%m6lx *Cp=zYyA(UȻ v#I_;ڞȖat-H4>rb]6&EatM7ɛ=G*)|a.z P>(0ڍݭTO;瀠l>ݮo9a[ÎbrCtK;oȯ ~ ܂/:Adxsl3Ѣ ? *,頼f9@"4&shmE1=?2EoN<+HdW=GtL` F5^˂O+qW<\RU"d!B,w-m@4,Ѱ\? I5"v\̕ #jiΧ92~ĝt$m8'272Ȇ4? Ŗ!FxT{" ,v:TJw}u|<ȸ =L)qGd0OdH/Nn=34 P;%`G]zpxObɃ}CpkJWu1lkƛ;"jiNq:CKn7jWS -t-V]|pC6~낆2͈p%'i,iO1Z3 \ju;bq@h ïdGJ@$8rnJ^ΚM׫?%6moվ>;"l`ӭͧ6slŝzD/3tYдպh< [`_cu?dnaQZC/]8N`  Ljt†>DejWO"ӵaS" vK PUppdaX[iR Bh,ϻlZ3EQG쟹&-/._ؿ{w=[.]2ԟ@3i,n.uհV>P0j>IU;"L88ĥiXkI/<,ikVL*;S}զ/3sԮ,jRv@5 Orm:2ݖf ]CXT;QC[-j YD8K<Xdȍ*P:5@&i%HaF^L m9ÑBa:d4--mDZ.eM?mdH6dbKXA`,l^HafKsIppM\*"_=hyV2r\UWW;Ύ+Ku=9I]'p~l. 4bi{qNdbڼ;ji* sv[,J%bi%+OUrPi<{HL;(S.Y6VV# T)>;ļO> q}Q\v3|tV1>бclb~}rcJ:} N𝓯(th,zKWךu)Hr ,~uuY~m:{ ~lިzP_߯ygוoƷP?{oOR9n-GM_Z-x译%nR.w5եgo|usB~ iT,)qakYY~e @$0С0뇡:! t؁JՐȰC8(p$}gӺ4zIENDB`}DyK _Ref417286060}DyK _Ref420157351}DyK _Ref420157406}DyK _Ref428014795}DyK _Ref420911832}DyK _Ref420911866DdC! `_f I c BAIDrawn\MIE1.GIFHbb< <$WU]%y> n6R!O0J/)M< <$WU]%yPNG  IHDRCtsBITO0PLTE"""333DDDUUUfffwww{ bKGDHIDATx흋:EvJ("Egߵzۊۤ 4'*pPC T8!@*pPC T8!@*pPC T8!@*pPC T8!@*pPC Tvp ⠔ݡR ̐ڂeww@uȹ&8j/^ٛCR埢'4E۟ 5u7[S_^w3 lm E>#l&_aO ZP o65*;Ck8!o |*"9ΡKa9 sPS!@*pPC T8!@*pPC T8!@*pPC T8!@*pPC T8!@*pPC TN5vMz8tzK:N8teeMqʺ 5T8!@*pPC T8!@*pPC T8!@*pPC T8!@*pPCJ3aCMQá snjIu\n<4j /^,_4!0=+?8U١_k~|5EbA &D >PSԈ4xRt+ 5E $B/O1FmP5K,.TcR l8Ubןm7wHpj>Yc/ECUcտCLQ{4EL0݂IC.uԞ/3P5E ?24Q,\Qz5PS5nc&{d.`v&p)8zt+OE}7NCMQ!w,y8U:A-.ޘC_B>`CMQ ./FL8g?_B}0}?>`8XTdʗ1.ʺ165A󇖁CMQšǼF]b#p)v(*)-bn,c\58!@*pPP,l<4j*s`Pep10^T)?5EšBgKa%/c2u/BpƘg?.tݸXa~b$3[RákEYkJ4hE[3vSuI\iM_ʅyЧa,ʖ_=#A|mPZwRLT+v _BH+ߨ*\:ζo|=Y;C) DzQ IVY皣0O>&'uȻ}S*:=7Vi"RTʃvyzPfC$tN./RO8Eb01L-y~Ћ{cV.̆UuD]bJ@uv۾b:QEnl{kͪPjk0jh{dTr#Zrq*WmG?BuI1XΊNFFXsEl,UsB̭kwp(RmSjh18PЪ cTY^.+5d9q&ɡ w厉<^ow( T-* $ğ:lQU&/l5⡁ZwLzۧJ IEяJPߍw@H*|=P}eXpzKE WāYJ}m<*Bb1O1x>ƱQ觎3\S,2F0y7DIΞvs w !'zZkN]*;s2Xsm0Pnsдrh8t,W*s%tC$MPxC>a" 8t41WwC sQ L(*w4g|X::(SmC_a?3;e׸çX_gKn'^`sֲ8 S czEEh΀ЊS7O`>}rf:m8^Y8fG31L98t ěyFV"0,}q*t'{AԳ~9SPá(ǽNwkqgqwNUvS l'uC,հaͦ֯cX ;Y4Pm Z?$zPcu1U5Fbj#^U:":Ubk!{u.=З /NA}! \iLĆYqb%UzVCg.9Ygd9:q΀1^EgX5^\!: s?f96%^u¡+/}S'^>:Pi.lqXj!eN~PO"y8g ƖCcrX~DuQbI8d˅"}akIUcY=?4FpXS]V: ]r61u.ևW/!I-HƈV_kh=ʇvP⚅Q6ؖ8fQr{a1,;)7Rz@՝*cw]F$rS1V3yk)98nl!GaSqgipektswR=3.eөs!m/M0.ĨԪ<Xi4*w:e]˖4$J eif.<'pp=4@=3UM,3;S?xsGoy:z'W=mI-5^CiNVc[83kʎQTa\H1G/.]ϡK֨{e XIj-/*u^ C| JQh }3%~ZeQ68סףFOfǔ7H^ QlߡYZm%__Mݻ 5\-Ci1ک#W(>~~-h 2EH8(:wwq^ױ;@꿦#2x]<00C~mq! 9_.=s0HԈc֮}V?crI촏mM𲜟/l֯ܪљ~ٛ* a>vj1*{wLddcrԉ 1h2IVS_Ǝ!_ԔY}_]R )ט?K hp;ЗP%gt8m<4j* ާN3?5EL 52ߓ;\8$TzIT?ֆCMqCJ:˧H XGz'W\16oPS쿾_7}YZl??Ʃ"L bw; /W%TR0U]c.VY^ WL9^R+U8;xh8pPٽ.ۺG8Xo!@*pPC T8!@*pPC T8!@*pPC T8!@*pPC T8!@Y8t5 ..kSCp)8!@*pPC T8!@*pPC T8!@*pPC T8!@*pPC T8!@@fepc74B΄"\Q\_?~Cp G9+ysС_3G:q"Vkɭ{Ы恽74tCC;qphr~ ^־0U^zC|":w\A W Jd;^PHLJ, eTZ{>~ iFdsSq_Oa(_/M7);42lLLmd}|z^CLא/}1 >c.QӶO ceLUAnwA7M}:WBǘm|[Ze\e#OX 8!@*pPC T8!@*pPC T8!@*pPC T8!@*pPC T8!@*pPC T8!@*pPC T8!@*pPC Tg`jZ{IENDB`DdC! `_f J c BAJDrawn\MIE2.GIFIb*f8ϡ n[aviQ专*f8ϡPNG  IHDRCtsBITO0PLTE"""333DDDUUUfffwww{ bKGDHIDATx흋v(@E|Jo$NkGj{Z41wx @Fq @H!C @ )8RpH!C @ )8RpH!C @ )8RpH!C @ )8RpH!C @7VU/? ܡx8T-Rx8d _uOH!M6*j!!]e#>$dEǟ!o:wc85!5t>L{{CG:Tjݦ#lfRCl7G:d >F]]fճ*DTgk 9>Ny5r/pC߃CYC @ )8RpH!C @ )8RpH!C @ )8RpH!C @ )8RpH!C @ )8R>!k88k/M69p38oϗ˲#2 )8RpH!C @ )8RpH!C @ )8RpH!C @ )8RpH!C @ $ތ4ʊeQm"ʊik+8 pfժ n"C.8VK+rCY!u+WLpeR_08|2eEPWԪn "I߾JfM ?6>0z P|XPjLWQebʊ$m^:UU5V$:>ܨ{TRMg37)겲(+ObRJ7CeY!MvDcbs:4E yZuaGf?X eEFÛlꦏO EM,7NġH-JշOH2ܴ95p(+͹8t1z7 ʊ$C2b.B6uTM}G4PV6$tmUkqPV$YQơ8)~hʊ$<ʊuY8!Wi]]:8;`-q Ƈ@ )8RpqEv2#IL~YcI.`v22&p(+A+!8)j E{0}dq(3hS$1h󠭃CY&"Bpk+HIPe-hġHεPuơH5eCY(틝\CYC %Y]u7A'@7F;flڱ>fϗ[_)E2h;"IQ8)uiC;CY$8KdFc;c[CYqCrXkqxԅeS:FbaB gp(+)8RpHIᐻvm|!ɜREv0ۻf;'+@<4䎩.P;aCrx* i:"SxPSƝD:+x*~!L(F_/| C7Pt!@1stS,7iGo_u^PWrj&T qbƓzd<u/%?_pm9?8_k;1_MiZg]oժ$-U$~/1$6m.bd9 ^8hnJK Y{q42|C΍cATU7a}*$e{dCtP 6Ccs SS4s=:P)rۢAh+O1QgA!UVaVV&!1؛|WPZǷ}٣|:![Uh?ņR, lwr=U2;4zX]< ~ܻCءu|g 7φĤp v}^E]<.C k+~}waы66u{bob&IBncouutQ/ZfoC]sU}\FJ'ual(qbdۥaRvI:_ÇOUH3aKFAS9(&lu5-;llՏ eT?c}YOKʺ홠3P/Iof4u5CU\}n6|Oio7DiJ﹅ʐBG&~)41uM77QICFc0 ji7~}Ҍ VroJ3%lL $|-g~~Mt< &UMt{Dewݛo[ph;c.>AmLmw|s3BN&nݜaɒkN:Ng8y+/C2\¶vsqo=n؞jƷׯ;+j10̗~w-+^ Dk{7ev|;/l}=֚..a8CKOmBδcV_E^fqj&L&ԿȼB}c::-(ZקSʢfg4ړ8499~!ߞTnz"~Meo͆ 2߁CYl|HҨáHׂ'q(+RRM8t )8RpH!b.eEl(!PT~up(+whhy۠O8)tn>)rn]aSt}w|Sޭ@2#I<$^=WH K9t)2]Wa^CqCaˠil[CPf$Ƀv_B8)kyFPVpQmWeE=Fʊ{)¡H7іΕ8t 9tao04ʊ4B8dC O=94ʊJĠ]2rCCq(+oˮ"CPf)8RpHIl# ʊ$uZMq(+_V-HݴuM5H `ɥw84Ir6^w2#eqڒ|!Po$ eEbB c.E k"$zXe{PŰ6eYUj;e~)eEN}чS+e}ӗm/[e0 p'+/bv+]eQQIqҡo2g G8t:CQGVy)P kgufMKptb֣|Ys-2ZTwC,x˲lcPŢ~\O#p(+ϓo;kښ [[t+eeE06ZzYPVP?{N8'!rx]w%8)8RpH!C @ )8RpH!C @ )8RpH!C @ )8RpH!C @ )8R>!C9%11}ڣ|9견r@ )8RpH!C @ )8RpH!C @ )8RpH!C @ )8RpH!C @ )8RNthahozs/ t,B 94k8!ݜ?^ȡp g9T 358䶝א^2pcϑ6n~"y;!=9T?) 8ur3c`=M_x.;n9ԩ+'O҅6^!Sj f6|G9E֨J-_BhB!; H: Tzh[ec|q dy*9!|zNA~UU?#_O':d}71Ek6ygӮsOf']:m5[)(^}L\ڦz6M PvjQ;lSu} *V ;㊽~g55m %:F +|>?6Y;4|Cup~M[D%<jU6ϦMm} ~ _C=Qd}{1J;_~}d]^CV61.Tɭe7ZO?m5ğU:xr뀿)8RpH!C @ )8RpH!C @ )8RpH!C @ )8RpH!C @ )8RpH!C @ )8RpH!C @ )8RpH!C @ )ʠȔVaMIENDB`DdC! ?>n K c JAK&Drawn\RAYLEIGH.GIFJbۻ[DAɅ nC!bY(4=ۻ[DAɅPNG  IHDRCtsBITO0PLTE"""333DDDUUUfffwww{ bKGDH!IDATx흋v*E""@HJ=m){V}zHTHTHTHTHTHTHTHTHTHTHTHTHTHTHTHTHTHT28$[ɹ"!ٍo?#!ANkүr':]٨ķ!;4u6 `>8{8@E,uhb>z$c^%b^4G*WżHMpH:z2Ǽb^UsT{?֚!YɽP sܫb^.!μ}!IT->nfCq9ECq9yepZ&b@C$Ca8t(.=V}}O:A>'C}8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8S֡QxtHKʡpt=_NCUqXj}8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>-S_rH;~󘟜 (uWi) tоJW/OP9zKb(MkE_8<maV Q;Rxpa T-ClX_5=_/tY{Wߜ8)&(Jo;EtNP/z;IEBCuhg鞐{=~Y!HEqega# ݨQieB$ͱy3] J%:Uɢ~Rn;ե|OR8u!8]J&g8C9mJ6C0NJJ%ZHX̙ eQ„8Fn!.@6g:F-GEe~\F#: 귗]?n1ꘜzɣJvhWb jK# 2I+"ب_xWgCΠި6»P7R]!?]/R'Jp-GǠk@+Aw.~cڜK8yG̩]4qqQyUCT-.;eu sM/ԥ8d LIJ8>S׃ c*Zs=iC\f^A>7~8${5SC&-2\pIK87C1G-y0o)>zv S!?M5;EEbK-:du1GEH.;d{/C:$5rE];eIoW!7[m0 )}RCn >9&]x}u:xH*|UЛeըСr\jTmc/&-GC:mesLu!!;ЪȋBe\BBJ-EOFanB>s^uvIThL~'Uf:t.Qu* AJTfPI[P UЙD%;խPHTd Z?;rC&u;DAFQCJT$NxTB;d$bK}KfRB;EJ9S^R>Wͺ_VEY~)3WZPXrHgF٬ק(jJ>PqǃZEk= Wl} B4ГY>lkX)$ӆC&a*pWm8.?[Y22o e>qnKcˊ9u?HUKc4e|YHI}+!L4;~"}!J$k!ǘڤ|pf|;ޖeƠ1VECcATd Zm&C-9~r#C;u@W띖R-zMޢjc%LqJgE?)YFviZŽ?qo<V?T1m9d)RO;dOc[AtᱰC9t/.PkPs ;+sV]!Z1ԞC\f^N[Loc7Dh!Mܘ2}vBHi99.(1!%G uZjyq:4QJm0+v )nvqhMѠCI/2~ ^\hT{Ef{_d [e2hf$҄2uj`GQuS1&" ɷ!]Z UơU HcbEhZiLP!e6{MX*PqѤCƼ7ְocIu;S0r:͍3WZz7)}kzC5=W_ܮ-bz-: Yʬq Ȯq࢞-:$;~u\`Ak :vC 큷*. K鹽8G^r[ph!̼yB߻u}{)^zU'Sکgk==1 & dɇ\SDaZdewHͫ7R?HZ;d9Ǡ@WXCK,Cu:|c?~0\aRTC4CcsL5‘5:$gwhy9u_ 2k̇,|:QYKQu's!f񲔽9d2Ԭ! jƺBEmU1T吽o& J 2o:=*LƯɡ1/ړaH#դ8d Zd,,_2r=kqHaCዌAcv\}fX cd y 'xa!%!i>,YܣCU cCS7 {i:dGNv﵇};dYLHlp](;]f>~eї9._!Eퟢ'ri.PA|,hv}Y *'0̩(kl/CX|kA齫k#Sb2/C_WtH۫E7:9xV>|\8-bj!z^1qXqX؞v }z }dtVHCz=F˶{+7ciضsdV &ٳ1y㇌\ȡe6j<'㝓nkiNN=8dEAm08:{K[!mwh!5/szv/h,e6igٶnLY4#=^(Q|e/gRUKB4"|Ti8!a?2<;(]lϔ[5/?c{+uDXv?,qN͎E7w(P%ogB23=6= 繾g-u4kaYCYGq̈́i<YLٕY47Ii؞a*PUm8+E7IfudamGX/rĭ['9]7r(GptM,vvP4/;'8i 9zn7ж(S~#-I,?^Bp8BQʤ0lMNrhT7>o670Ş>E٭lȊݻn0f;Qr\a>$!SoCvbjOCG7¯OxNm㤁83Α&d>CvCZrwލGlՉ0ɒ99r.$-N24ΡF5ދv/|i6+m5Ϸf}8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>eeI|ʡf9j}8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>p(8C>R[-r 9xvO:O:4[͂u9]W=CsC}G/Q-Ρ9'CCqC>oR*Uqr(Ά/Cw&Ejz'CQ+U!=JD*Uq'?OC 8di вCUX@%ʇdmaf"و&:̈́n| rh]) J:=Me:>iRJv^^'*ڿrhSҏD8#rpJts^X0LH)'\߿|8$dw4$0)<ې4k7͍|bYǣ)u`+,d~lV*b*= Sn`H[Rµ~bm`鲵_je[KƁ;vнw*_9['ømBdcb;]iXgrg ]e|/ƮH9ssP]ڵܪ&ܔ͇~8Ր!}Uevv,ߡ^}^"C`Rt-3а?r(%#{,۴Cꘗ=CcL!ו=?quޒ qhCmb9{,x847(q6c\53eέMHuqYui(CԳUץd3zsHI.R_Gv{#`F\I(#}kdzJsrmFӠ:nZoOqJ:䆧.n"NPPٖZR)9>ϥ,:e@ۇ Ss! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! F PIENDB`r&DdC! ?>j L c FAL"Drawn\HEYNEY.GIFKb% zT `*c%L n%@@ p1kzp zT `*cPNG  IHDRCtsBITO0PLTE"""333DDDUUUfffwww{ bKGDH IDATx흋b(Ey@o&ۤ۴11f7`>py {C`/p!8^ {C`/p!8^ {C`/p!8^ {C`/p!8^ {C`/peC VH?XLxlv((EA3b P,MǛe3N\8Cʢڜ CQq~c8*-P |X8 C~R즣(qQOptԖmbc(;.~m9jۧn9hQ*~Q[zoF&qmavԖ¦ٰͼ-}!K{ˢ:p^盹͡mlsh66>v8$ [ s5ths#VmxnՅft@tH2pRC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%urI[ϡO:9> Х8g]:8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%p8TC%? ¾.E3`鮉EpR4sH('j$Хh& >\_h搸C^,=^yN3s1]Vy6܄ yEpR4kb M,⦊/>~q/8t)퍌Rt%z)oi m_1<$S5&rsp {.E~٪Tmq\Po#C\?HoT/_sC(ʡkӬ_&P:jx5932?zO¡K̡菌,8:{݂B!mn֥Cy{)!p@H>8t)9d;vp0Ө;n>*.E3&xw]fC|*Хh7>\y5Kr1:{PϺLXIA{*ѦIKѮo֦͢|8t)78PL+[;.E}'(CCC徎fKѬ.SMj MRJCCCz*P=pJP=pJP=pE,̾KnM`S\Ǩ cpR`8P tK.|pR4sKMjAC%?Cl CC%hSJ~A-CY3Nkа=pC]Fw%pR`8POF%n3.E}LtC_C%?\ekJ^A{8t)q7uY=UvS7 a뚱W|$9_bߞBˮEqg208t%͗)+n^ZZd]vkаq 8T3M`=pt(Zf_CCݵ g¡¡d獃ů^NzLzQݠ=$Ytq{;tj Uζ pM]6(1)ca֚sŹfL2&Su]>1ҽXhJ)|:dI1<9}@qFA%˄+5m{t6^ RsB''ǗFx\$л7S! Xt &jomWuN;? C'cI3P4&6"wT+?dWv8}{>[ߤ[RcT j@v{!niVQ&eoC>\RAγXT[eCJDibMH3 HP6CNz]k%m  maVjX՗C! ʡ:v$=cKV5ykcS X7lW=s9W`R.5\Hӹo-yO/kk c'=oN,C1:-8}Gq}qb#Ė%:\j?kKJk7>]Mo%/TUŗVZdY3C!TLR]י5!5G?'k'CR"hv4?|-3}"6YKӭ'{1nq\nIs[G BRc=:aH}fih]gh!{"#iFk\ cǸ~~0*!a$EjEr&𢺢8:T ٚBF!ujg9b#="GOЇ2KdWN\~G|-^.|8N1$Uz ˟\?JдzrLC.]< FnE{u͍ >L+S94sҡX[Xşߙ|VŶo |^.uYw kjy]6V`4)~ wiW[?yRZ_ojyEMi좯iSpY#½d0SW^(LgSU G0lH=a6F}9i݋9װf<uS7}ԋGD-jyG[v xMH9}1-wi#֠ޢ n M[N9db('ִWZ?Qؿ$W61@ ghڙX}34N^gk p_vOO!@ccP0PSt4G1׻qeEv~. 8C=)j_eDNk5v!n(@ٍSWhaPi xhb)RҮJiƑQM{BxѰU[P&hi1qj{"o0 vF`!^wХ|DvNx܋i9_&ͷ=;P+"?:/k{.g[ߺz٣ʡŮtԲDvsCӣȸcz4hE!WlMph2ٱڡԆqcTy).얮aCgj\hCk[Oݩ5\O]w0* ΍޵qk9tKRU0j n;qmAom;>;MU[z#7V>?P~cCw&u7}i0{Q[Z2d~}Cx&wSZA pEW{Q_\e).\ʹ&~;ZcMC.ARhWO0&v*Y+!W/nuӱ,(!háX/?5[qm Pkld/ˡNJopCI61P,n@^@҇θxJ2B+C~B#:cT c Cxa1k} LM_p8N>N8tpCK!#k]:4kТ=b J^/mC]2O(sv|MrŽsrءVHa*/eW`-[K.&6vfm<.1S{ߨvRIH¡8B9Ļк+ ,nȫ6-opH3ݯO{:F?t즺mI=vZN>ױGoT/ xv9/n~:dN_:Mrx~۩ JϞud>ItϦK(fRDgBm44C (HCQ̎w~?,pe )#D%pz>X!1>tQo;)9R F<!wC%CCG2vJ?&ZRݬFP~8:OQb԰mZ b-p7팴hj)ot((_0! /GDerp8ttH ,{!G^r٣J]ez8t®Qdkt_9TECE,K­0$ХjLρi'3v-AxRpMsyhJd=9Gp/C6'9ؐhΉ<y ׋Ō4khWW'C1y?qsc?p8P zP zP zNyzy9CKxm^g8t~{-LŜyC]\ؤka Xe8tOw/丯Asy&A8tyif7_,u#Cp@>[8*8t eFCյ Ɂoy¾U\Ԧֹyr\:..en !eqac-Қv !k6v\w]?)l#á8\~q8T*C8T*C8T*CJ>XjGIΗ֠:".A :-V#ͨ8t_X -g:C֡~_kkФr0*qʳ<s_YY ˅^#yX\X7yA { ˗_` in\XJ.7ʺ,DžMvɴš˗ºqa_X &Ӭr:/DžoŠy\X!k>:oqa/9:zP zP zP zP zP zP zP zP zP c0IDATzP zP zP zPf)_'dKqC{D*kHfjϑ6sC_Ȇm, !|8S@[|HyFg9!mC69t|]fuYhgmm"y6679͆:D%O&;m:6mnmzYuhu{Ca~UBig^Nl}f0R|BBl܈|X|e¥V6kߓU'D|.ؽDu uҏi۳O]Cti?P~";X؛+ICn&'g ⳣ%VN='CM~8y}xȃ:gKkn]es۩sYgn|ҙզd[MnwM^:>ReTJnDn>ǡi-;x)Dk60LˡyQ2eY#rv ̡}ס"Má4߼MX17BZ܌/*w?֦NiD^OuC=\?F}sP;wmo\ҟP5al} 0]' o>M./}\H.?H+>6>Oc*~<>T{jox>PZӎ3o?Aߑ`Ss._khq ?TY /œ+ {C`/p!8^ {C`/p!8^ {C`/p!8^ {C`/p!8^ {C`/p!8^ {C`/p!8^ {C`/p!8^ {C`/"`cs lIENDB`}DyK _Ref428014833}DyK _Ref420919899}DyK _Ref420920063}DyK _Ref420922745}DyK _Ref420923317}DyK _Ref417371289}DyK _Ref421003334}DyK _Ref413750547}DyK _Ref421004161}DyK _Ref421693483}DyK _Ref421693822}DyK _Ref421693928}DyK _Ref421694648}DyK _Ref421696014}DyK _Ref422128058}DyK _Ref422128412}DyK _Ref412464789}DyK _Ref414188528}DyK _Ref422141956DyK yK .mailto:thbaier@ibm.netDyK yK ,mailto:lutz@stmuc.comDyK yK *mailto:no13@no13.netDyK yK .mailto:redaelli@inc.itDyK yK Dmailto:100022.2603@compuserve.comDyK yK 8mailto:espsw@compuserve.comDyK yK @mailto:adilger@enel.ucalgary.caDyK yK $mailto:ram@iu.net}DyK _Ref449776419}DyK _Ref422831205DyK yK jhttp://www.adobe.com/prodindex/acrobat/readstep.html}DyK _Ref422912420}DyK _Ref423165651: [,@,Normal ddmH J@J Heading 1$$ & F<@& 5CJKHF@F Heading 2$ & F<@& 56CJ@@@ Heading 3$ & F<@&CJD@D Heading 4$ & F<@&5CJ<@< Heading 5 & F<@&CJ@@ Heading 6 & F<@&6CJ@@ Heading 7 & F<@&OJQJDD Heading 8 & F<@& 6OJQJJ J Heading 9 & F<@&56CJOJQJ<A@<Default Paragraph Font,/@,Listh0Z@0 Plain TextOJQJ8>@8Title$<@& 5CJ KH4"@4Caption$$xx5,O2,Preserve 2O1B2Scene  OJQJmH02@R0List 2.@b. Footnote Text8&@q8Footnote ReferenceH*`TOC 1(U@( Hyperlink>*B*.`.TOC 2mH.`.TOC 3mH.`.TOC 4]mH.`.TOC 5&mH"`"TOC 6"`"TOC 7"`"TOC 8 x"`"TOC 9!@6 `6Index 1"6mH0O10FilenameOJQJmHnH O2A Code5CJ*OQ* Syntax_Item62O1r2 Syntax_Head&d62O1r2 Syntax_Body'hmH&O&Value 6mHnH* `*Index 2 )8* `*Index 3 *X8* `*Index 4 + 8*`*Index 5 ,8*`*Index 6 -8*`*Index 7 .x8*`*Index 8 /@8*`*Index 9 08.!`". Index Heading1,+@", Endnote Text26*@16Endnote ReferenceH*F @BFFooter4d ! CJOJQJ@@R@Header5 ! CJOJQJDObDListing6 d OJQJmH8Y@r8 Document Map7-D OJQJ6'@6Comment ReferenceCJ,@, Comment Text9 : +;  ! F <<<<<<<<<<<<<<<?Co ^ <$P7!#K&(*t-/1 4L68l;=0@>BPDkFHJLN'QXSUWYX[U]r_vacegjmfoqtI=ƹg(ba&WwhǤ~+JNl!b6=C0OW`cFhm%sfz Z)W" gLhF Z) 0=BePZxb{~уd c [\mz5 r!-C2HKXcnvv:]jV-/ q,%%/5:EU_}mtHyъKt{%Pk #V2AnE\nelno^p(qqrps(tuu#xo۔̟I @}hBN  S! s/ 5< C L T Y _ -g m y v q ؒ   ʹ C r " m  $ q & , S4 < C I f ABFHKLNORTVX[]_degkloruvyz{}     ! # & ' ) + , / 0 2 4 6 9 : < = ? @ D E F H I M O Q R S W X Y [ ] a c d e g i k m o p r u w x y ~   y`$*?17>VD,JPVV[`fmsrFMwcjG $P(+(3w79CGtKWk"q}Kj|*8\!. K3&+r27;?CIQ5S]ltqzגLu[*Oxw,Z+v.? DEHSKTO,RqcBf"pta2ĎԠJղ-&^*37==BOYN_nab7imxBz=ӏޠfSζBmi R>`q%\({):,5p@AG4VqVafghijklbmUn-oop_qv$}T)A jK+6@`AM4a)7CP"Xhnnnnn o3o\okooooopp:pOpxppppppq%qMq_qqqqqqr"r4rVrhrrrrrrrs+sPs^sssssst&t6t^tnttttttu'u5uWueuuuuuuu vv6vAvavnvvvvz`$ x # ]@ rL T c p Tw 8| у   4  #   L, 3 < K IO [ im A D E G     "$%&()+,.0134568:;=>?@BCDFHIJMNOQSUVYZ[]_`acefhjklnpqstuvxyz|}~    "'+.046:;=@CDEIJMQSUWZ\^`bcfhjmnqstw|~                    " % ( * - 1 3 5 8 ; > A C G J L N P T V Z \ _ ` b f j l n q t v z | }     %4KDaDr4WFlM7G?R2lARrU? &i-H:ZtU 6Th V)AdPilo}*J)v (l bNn pNqrstuB P ,v - N O| z TB d  ) w а G  #'-27<AEKPX\bgmrw{ -7?GPYaipx  $ . 7 B K U ^ h s { 4D`c}  ">Af  (DG\x{25Kgj47Tps %(;WZn &)>Z]o*-B^a  $ @ C t  " % : V Y  % A D p   7 S V |   ) E H _ { ~ 8;Yux36f25Njm#&7SVzXtw %(C_bs 3ORn 0LOr)EHn #Lhk/KNe 'CGWsw8<h +GK_{6RVh/3Oko $B^b"&>Z^x  B ^ b } !!/!K!O!v!!!!!!!""7"S"W"x""""""####>#Z#^#|#######$$5$Q$U$y$$$$$$$%%%7%;%Y%u%y%%%%%%%&"&&&L&h&l&&&&&&&&'B'F'Z'v'z'''''''(5(9(X(t(x((((((()#)')L)h)l))))))) *(*,*B*^*b******** ++'+C+G+c++++++++,,9,=,W,s,w,,,,,,, -%-)-D-`-d-------..".<.X.\.t......./ /#/?/C/c///////// 0&0*0E0a0e000000001101L1P1111111 2)2-2K2g2k222222235393X3t3x333333341454T4p4t44444445:5>5j555555 6'6+6K6g6k666666677 7?7[7_7y77777785898c8888888889+9/9?9[9_9p9999999::$:@:D:n:::::::::;1;5;N;j;n;~;;;;;;;<<5<Q<U<l<<<<<<<= ==9===]=y=}=======>">&>5>Q>U>c>>>>>>>>>>??4?P?T?d?????????@#@'@H@d@h@x@@@@@@@A A!A=AAAPAlApAAAAAAAABB:BVBZBjBBBBBBBBB"C>CBC_C{CCCCCCCCCDD+DGDKDaD}DDDDDDDD E&E*E@E\E`E|EEEEEEEFF0FLFPFrFFFFFFFFGG1G5GHGdGhGzGGGGGGGGGH+H/H>HZH^HHHHHHHHII3IOISIjIIIIIIIIIIJJ=JYJ]J{JJJJJJJKK.KJKNKrKKKKKK L'L+LAL]LaLpLLLLLLLM M M\B\U\q\u\\\\\\\\]]:]V]Z]{]]]]]]^.^2^L^h^l^^^^^^^^___4_8_H_d_h________` `"`>`B`[`w`{```````a#a'a@a\a`ayaaaaaaa b b bʷ׸8Pb  (@\vvIass-Ad|%%%&&&**+*000>>>v???@@@AA5ApNNN:OROcOSSTueee)mAmVmwwwz{{{5{E{։ůD\~%=S(RPh   1CICsCLLMR1R>Rcccef+fg h$h)hAhYh^hvhhhhhii9i5pMpVppppq4q;qqqq(r@rIrsssRvjvvѥ $*Qiv~===UUU]^^ ^8^P^\t܅ ,F'6=F^et& > R    S% k% w% 2 2 2 75 O5 u5 8 8 8 w: : : ]= u= ~= 9D QD hD DK \K pK K K K K L L #L ;L BL L L L L L L S S T U U U Z Z Z \ \ \ sw w w x x -x 8 P ^ 4 L T " : K  0 B b z - E W   $ P h | z # ; S = U f   R j F ^ l + C S d |     $ $ % 0 0 0 2 3 "3 7 7 7 d= |= = h@ @ @ \ \ \ \ \ \ \ \ ] ] -] 5] h h i i 1i Ni Si ki xi i i i Ѿ k Y q ~   ! J b h   p  OU gU U U U U V .V @V \ \ \ _ _ _ _ _ _ ~ ~ ~  ۂ i   ( ы Q i q c {      / G W 2 J \   ƺ ֺ u ; S c W o w < T n  #  3 J  C S ՜ < ^ l Ý & A  5 O g  ) ; 1 : R n    : +;  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%44tttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttXXXXXXXXXtt059?!8@0(  P  B S  ? _Toc411405076 _Toc411405352 _Hlt414188502 _Toc411405077 _Toc411405353 _Toc411405078 _Toc411405354 _Ref411168478 _Toc411405153 _Toc411405429 _Ref413248285 _Toc411405085 _Toc411405361 _Ref411168056 _Ref411494857 _Ref411584453 _Ref411584497 _Ref411584509 _Toc414198826 _Toc449869233 _Toc411405080 _Toc411405356 _Toc414198827 _Toc449869234 _Toc411405081 _Toc411405357 _Toc414198828 _Toc449869235 raytracing _Toc411405082 _Toc411405358 _Toc414198829 _Toc449869236 _Toc411405083 _Toc411405359 _Toc414198830 _Toc449869237 _Toc411405084 _Toc411405360 _Ref412637841 _Hlt414180471 _Toc414198831 _Ref428631793 _Ref428631813 _Toc449869238 _Toc449869239 _Toc449869240 _Toc449869241 _Toc449869242 _Toc449869243 _Toc449869244 _Hlt411494886 _Ref413248407 _Ref413502638 _Toc414198832 _Toc449869245 _Toc411405086 _Toc411405362 _Toc414198833 _Toc449869246 _Toc411405087 _Toc411405363 _Ref413502879 _Ref413506445 _Ref413593367 _Toc414198834 _Toc449869247 _Toc411405088 _Toc411405364 _Toc414198835 _Toc449869248 _Toc411405089 _Toc411405365 _Toc414198836 _Toc449869249 _Toc411405090 _Toc411405366 _Toc414198837 _Toc449869250 _Toc411405091 _Toc411405367 _Toc414198838 _Toc449869251 _Toc411405092 _Toc411405368 _Toc414198839 _Toc449869252 _Ref411261429 _Hlt411261448 _Toc411405093 _Toc411405369 _Toc414198840 _Toc449869253 _Toc411405094 _Toc411405370 _Toc414198841 _Toc449869254 _Toc411405095 _Toc411405371 _Toc414198842 _Toc449869255 _Toc411405096 _Toc411405372 _Toc414198843 _Toc449869256 _Toc411405097 _Toc411405373 _Toc414198844 _Toc449869257 _Toc411405098 _Toc411405374 _Toc414198845 _Toc449869258 _Toc411405099 _Toc411405375 _Toc414198846 _Toc449869259 _Toc411405100 _Toc411405376 _Toc414198847 _Toc449869260 _Toc411405101 _Toc411405377 _Toc414198848 _Toc449869261 _Toc411405102 _Toc411405378 _Toc414198849 _Hlt423336169 _Toc449869262 _Toc411405103 _Toc411405379 _Toc414198850 _Toc449869263 _Toc411405104 _Toc411405380 _Toc414198851 _Toc449869264 _Toc414198852 _Toc449869265 _Toc411405105 _Toc411405381 _Toc414198853 _Toc449869266 _Toc411405106 _Toc411405382 _Toc414198854 _Toc449869267 _Toc411405107 _Toc411405383 _Ref413759196 _Toc414198855 _Toc449869268 _Toc414198856 _Toc449869269 _Toc414198857 _Toc449869270 _Toc411405108 _Toc411405384 _Toc414198858 _Toc449869271 _Toc411405109 _Toc411405385 _Toc414198859 _Ref415568254 _Toc449869272 _Ref411675833 _Ref411675890 _Ref411675892 _Ref411675936 _Toc414198860 _Toc449869273 _Toc411405110 _Toc411405386 _Toc414198861 _Toc449869274 _Toc411405111 _Toc411405387 _Ref411676227 _Toc414198862 _Toc449869275 _Toc411405112 _Toc411405388 _Toc414198863 _Ref415568292 _Toc449869276 _Toc414198864 _Toc449869277 _Toc414198865 _Toc449869278 _Toc414198866 _Toc449869279 _Toc414198867 _Toc449869280 _Toc411405113 _Toc411405389 _Toc414198868 _Toc449869281 _Toc411405114 _Toc411405390 _Toc414198869 _Toc449869282 _Toc411405115 _Toc411405391 _Toc414198870 _Toc449869283 _Toc411405116 _Toc411405392 _Toc414198871 _Toc449869284 _Toc411405117 _Toc411405393 _Toc414198872 _Toc449869285 _Toc411405119 _Toc411405395 _Toc414198873 _Toc449869286 _Toc411405120 _Toc411405396 _Toc414198874 _Toc449869287 _Toc411405121 _Toc411405397 _Toc414198875 _Toc449869288 _Toc411405122 _Toc411405398 _Toc414198876 _Toc449869289 _Toc411405118 _Toc411405394 _Toc414198877 _Toc449869290 _Toc411405124 _Toc411405400 _Toc414198878 _Toc449869291 _Toc414198879 _Toc449869292 _Toc411405123 _Toc411405399 _Toc414198880 _Toc449869293 _Toc414198881 _Toc449869294 _Toc411405125 _Toc411405401 _Ref411671219 _Toc414198883 _Toc449869295 _Toc411405126 _Toc411405402 _Toc414198884 _Toc449869296 _Toc411405127 _Toc411405403 _Toc414198885 _Toc449869297 _Toc411405128 _Toc411405404 _Toc414198886 _Toc449869298 _Toc411405129 _Toc411405405 _Toc414198887 _Toc449869299 _Toc411405130 _Toc411405406 _Toc414198888 _Toc449869300 _Toc411405132 _Toc411405408 _Toc414198889 _Toc449869301 _Toc414198890 _Toc449869302 _Toc414198891 _Toc449869303 _Toc414198892 _Toc449869304 _Toc414198893 _Toc449869305 _Toc414198894 _Toc449869306 _Toc411405133 _Toc411405409 _Toc414198895 _Toc449869307 _Toc414198896 _Toc449869308 _Toc414198897 _Toc449869309 _Toc411405134 _Toc411405410 _Toc414198898 _Toc449869310 _Toc414198899 _Toc449869311 _Toc414198900 _Toc449869312 _Toc414198901 _Toc449869313 _Toc414198902 _Toc449869314 _Toc411405135 _Toc411405411 _Toc414198903 _Toc449869315 _Toc411405136 _Toc411405412 _Toc414198904 _Toc449869316 _Toc411405137 _Toc411405413 _Toc414198905 _Toc449869317 _Toc411405138 _Toc411405414 _Toc414198906 _Toc449869318 _Toc411405139 _Toc411405415 _Toc414198907 _Toc449869319 _Toc411405140 _Toc411405416 _Toc414198908 _Toc449869320 _Toc411405141 _Toc411405417 _Toc414198909 _Toc449869321 _Toc414198910 _Toc449869322 _Toc414198911 _Toc449869323 _Toc411405142 _Toc411405418 _Toc414198912 _Toc449869324 _Toc411405143 _Toc411405419 _Toc414198913 _Toc449869325 _Toc411405144 _Toc411405420 _Toc414198914 _Toc449869326 _Toc411405145 _Toc411405421 _Toc414198915 _Toc449869327 _Toc411405146 _Toc411405422 _Toc414198916 _Toc449869328 _Toc411405147 _Toc411405423 _Toc414198917 _Toc449869329 _Toc411405148 _Toc411405424 _Toc414198918 _Toc449869330 _Toc414198919 _Toc449869331 _Toc414198920 _Toc449869332 _Toc414198921 _Toc449869333 _Toc411405149 _Toc411405425 _Toc414198922 _Toc449869334 _Toc414198923 _Toc449869335 _Toc414198924 _Toc449869336 _Toc414198925 _Toc449869337 _Toc414198926 _Toc449869338 _Toc414198927 _Toc449869339 _Toc414198928 _Toc449869340 _Toc414198929 _Toc449869341 _Toc411405151 _Toc411405427 _Toc414198931 _Toc449869342 _Toc414198932 _Toc449869343 _Toc414198933 _Toc449869344 _Toc414198934 _Toc449869345 _Toc411405152 _Toc411405428 _Toc414198935 _Toc449869346 _Toc414198936 _Toc449869347 _Toc414198937 _Toc449869348 _Toc414198938 _Toc449869349 _Toc414198939 _Toc449869350 _Ref412029139 _Toc414198940 _Toc449869351 _Hlt411321148 _Ref411169728 _Toc411405229 _Toc411405505 _Ref411168346 _Hlt411321126 _Toc411405165 _Toc411405441 _Ref413502672 _Toc414198941 _Toc449869352 _Toc411405154 _Toc411405430 _Ref411667354 _Toc414198942 _Toc449869353 _Toc411405155 _Toc411405431 _Toc414198943 _Toc449869354 _Toc411405156 _Toc411405432 _Toc414198944 _Toc449869355 _Toc411405157 _Toc411405433 _Toc414198945 _Toc449869356 _Toc411405158 _Toc411405434 _Toc414198946 _Toc449869357 _Toc411405159 _Toc411405435 _Ref413057470 _Toc414198947 _Toc449869358 _Toc414198948 _Toc449869359 _Toc414198949 _Toc449869360 _Ref412119618 _Toc414198950 _Toc449869361 _Toc414198951 _Toc449869362 _Toc414198952 _Toc449869363 _Toc411405160 _Toc411405436 _Toc414198953 _Toc449869364 _Toc414198954 _Toc449869365 _Toc414198955 _Toc449869366 _Toc414198956 _Toc449869367 _Toc414198957 _Toc449869368 _Toc414198958 _Toc449869369 _Toc414198959 _Toc449869370 _Ref412464789 _Toc414198960 _Toc449869371 _Toc414198961 _Toc449869372 _Toc414198962 _Toc449869373 _Toc414198963 _Toc449869374 _Ref412528893 _Toc414198964 _Toc449869375 _Toc414198965 _Toc449869376 _Toc414198966 _Toc449869377 _Toc414198967 _Toc449869378 _Toc414198968 _Toc449869379 _Toc414198969 _Toc449869380 _Toc414198970 _Toc449869381 _Toc411405161 _Toc411405437 _Toc414198971 _Toc449869382 _Toc414198972 _Toc449869383 _Ref413142060 _Ref413233147 _Toc414198973 _Toc449869384 _Ref413248722 _Toc414198974 _Toc449869385 _Toc411405162 _Toc411405438 _Ref412212281 _Toc414198975 _Toc449869386 _Toc414198976 _Toc449869387 _Ref412623075 _Toc414198977 _Toc449869388 _Toc414198978 _Toc449869389 _Toc411405163 _Toc411405439 _Toc414198979 _Toc449869390 _Toc414198980 _Toc449869391 _Toc414198981 _Toc449869392 _Ref413328828 _Toc414198982 _Toc449869393 _Ref413229845 _Toc414198983 _Toc449869394 _Toc411405164 _Toc411405440 _Toc414198984 _Toc449869395 _Toc414198985 _Ref417378671 _Toc449869396 _Toc414198986 _Toc449869397 _Ref412454596 _Toc414198987 _Toc449869398 _Toc414198988 _Toc449869399 _Toc414198989 _Toc449869400 _Hlt414180411 _Ref413248430 _Ref413248456 _Ref413502655 _Toc414198990 _Toc449869401 _Toc411405166 _Toc411405442 _Toc414198991 _Toc449869402 _Toc411405167 _Toc411405443 _Toc414198992 _Toc449869403 _Toc411405168 _Toc411405444 _Toc414198993 _Toc449869404 _Toc411405169 _Toc411405445 _Ref412720567 _Toc414198994 _Toc449869405 _Toc414198995 _Toc449869406 _Toc414198996 _Toc449869407 _Toc414198997 _Toc449869408 _Toc411405170 _Toc411405446 _Ref413233292 _Toc414198998 _Toc449869409 _Toc449869410 _Ref413163935 _Toc414198999 _Toc449869411 _Toc414199000 _Toc449869412 _Toc414199001 _Toc449869413 _Toc414199002 _Toc449869414 _Ref412721497 _Toc414199003 _Toc449869415 _Ref412891853 _Toc414199004 _Toc449869416 _Ref413233324 _Toc414199005 _Toc449869417 _Toc411405171 _Toc411405447 _Ref411667947 _Ref413150466 _Hlt413393945 _Toc414199006 _Toc449869418 _Ref413394014 _Toc414199007 _Toc449869419 _Toc414199008 _Toc449869420 _Toc414199009 _Toc449869421 _Toc414199010 _Toc449869422 _Ref412722038 _Toc414199011 _Toc449869423 _Ref412904357 _Toc414199012 _Toc449869424 _Toc411405172 _Toc411405448 _Ref412721757 _Ref413065577 _Toc414199013 _Ref415649609 _Toc449869425 _Ref413245145 _Toc414199014 _Toc449869426 _Toc414199015 _Toc449869427 _Toc411405174 _Toc411405450 _Ref413065106 _Ref413150500 _Ref413244925 _Toc414199016 _Toc449869428 _Toc411405175 _Toc411405451 _Toc414199017 _Toc449869429 _Ref413068936 _Toc414199018 _Toc449869430 _Ref413231149 _Toc414199019 _Toc449869431 _Toc411405176 _Toc411405452 _Ref412708721 _Toc414199020 _Toc449869432 _Toc411405177 _Toc411405453 _Toc414199021 _Toc449869433 _Toc411405178 _Toc411405454 _Toc414199022 _Toc449869434 _Ref413339528 _Toc414199023 _Toc449869435 _Ref412711267 _Ref413233211 _Toc414199024 _Toc449869436 _Ref413236810 _Ref413404001 _Toc414199025 _Toc449869437 _Ref413236176 _Ref413237003 _Ref413339194 _Toc414199026 _Toc449869438 _Toc411405179 _Toc411405455 _Toc414199027 _Toc449869439 _Ref413244037 _Toc414199028 _Toc449869440 _Toc414199029 _Toc449869441 _Toc414199030 _Ref429985373 _Toc449869442 _Toc414199031 _Toc449869443 _Toc411405180 _Toc411405456 _Toc414199032 _Ref417299112 _Ref418327261 _Toc449869444 _Toc411405181 _Toc411405457 _Ref412535627 _Toc414199033 _Toc449869445 _Toc411405182 _Toc411405458 _Toc414199034 _Toc449869446 _Toc414199035 _Toc449869447 _Ref413241864 _Toc414199036 _Toc449869448 _Toc414199037 _Toc449869449 _Toc414199038 _Toc449869450 _Toc411405183 _Toc411405459 _Toc414199039 _Toc449869451 _Ref412625191 _Toc414199040 _Toc449869452 _Ref412960691 _Ref413245176 _Toc414199041 _Toc449869453 _Toc411405184 _Toc411405460 _Ref413063326 _Toc414199042 _Toc449869454 _Toc414199043 _Toc449869455 _Ref413414330 _Toc414199044 _Toc449869456 _Toc414199045 _Toc449869457 _Toc414199046 _Toc449869458 _Toc414199047 _Toc449869459 _Toc411405185 _Toc411405461 _Toc414199048 _Toc449869460 _Toc411405186 _Toc411405462 _Toc414199049 _Ref419875652 _Hlt419875670 _Ref421693465 _Ref421693483 _Ref421694648 _Toc449869461 _Toc414199050 _Toc449869462 _Toc414199051 _Toc449869463 _Toc414199052 _Toc449869464 _Toc414199053 _Toc449869465 _Toc411405187 _Toc411405463 _Toc414199054 _Toc449869466 _Toc411405188 _Toc411405464 _Toc414199055 _Toc449869467 _Toc411405189 _Toc411405465 _Toc414199056 _Toc449869468 _Toc411405190 _Toc411405466 _Ref412708795 _Toc414199057 _Toc449869469 _Toc411405191 _Toc411405467 _Toc411405194 _Toc411405470 _Ref413677066 _Toc414199058 _Toc449869470 _Toc414199059 _Toc449869471 _Toc414199060 _Toc449869472 _Toc414199061 _Toc449869473 _Toc414199062 _Toc449869474 _Toc414199063 _Toc449869475 _Ref413590329 _Ref413677452 _Toc414199064 _Toc449869476 _Ref411611541 _Toc414199065 _Toc449869477 _Toc414199066 _Toc449869478 _Toc411405192 _Toc411405468 _Ref411762296 _Ref411762349 _Toc414199067 _Toc449869479 _Toc414199068 _Ref414259498 _Toc449869480 _Toc411405193 _Toc411405469 _Toc414199069 _Toc449869481 _Toc411405195 _Toc411405471 _Toc414199070 _Toc449869482 _Toc411405196 _Toc411405472 _Ref412708763 _Toc414199071 _Toc449869483 _Toc411405198 _Toc411405474 _Ref413745376 _Toc414199072 _Ref416092921 _Toc449869484 _Ref411672452 _Ref412632614 _Toc414199073 _Ref428280785 _Ref428631930 _Toc449869485 _Toc414199074 _Toc449869486 _Toc414199075 _Toc449869487 _Toc414199076 _Toc449869488 _Ref414188528 _Toc414199077 _Hlt414275045 _Toc449869489 _Hlt414183647 _Toc414199078 _Toc449869490 _Toc414199079 _Ref415568197 _Toc449869491 _Toc414199080 _Toc449869492 _Toc414199081 _Toc449869493 _Toc414199082 _Toc449869494 _Ref411680043 _Toc414199083 _Toc449869495 _Toc414199084 _Toc449869496 _Toc414199085 _Toc449869497 _Toc411405199 _Toc411405475 _Ref413745425 _Toc414199086 _Ref416092785 _Toc449869498 _Toc414199087 _Toc449869499 _Toc414199088 _Toc449869500 _Ref412632666 _Toc414199089 _Toc449869501 _Toc414199090 _Toc449869502 _Toc414199091 _Ref415659046 _Toc449869503 _Toc411405200 _Toc411405476 _Ref413745485 _Toc414199092 _Ref416092986 _Toc449869504 _Toc414199093 _Toc449869505 _Toc414199094 _Toc449869506 _Toc414199095 _Toc449869507 _Toc411405201 _Toc411405477 _Ref413745643 _Ref413750710 _Toc414199096 _Toc449869508 _Toc414199098 _Toc449869509 _Toc414199100 _Toc449869510 _Toc414199101 _Toc449869511 _Toc414199102 _Toc449869512 _Toc414199103 _Toc449869513 _Toc411405202 _Toc411405478 _Ref413745531 _Toc414199104 _Toc449869514 _Toc414199105 _Toc449869515 _Toc414199106 _Ref416105656 _Toc449869516 _Toc414199107 _Toc449869517 _Toc414199108 _Toc449869518 _Toc414199109 _Toc449869519 _Toc414199110 _Toc449869520 _Toc414199111 _Toc449869521 _Toc414199112 _Ref420911832 _Toc449869522 _Toc414199113 _Ref420911866 _Toc449869523 _Toc411405203 _Toc411405479 _Toc414199119 _Toc449869524 _Toc414199120 _Toc449869525 _Toc414199121 _Toc449869526 _Ref428017426 _Toc449869527 _Toc414199122 _Ref415664580 _Toc449869528 _Ref416607008 _Toc449869529 _Toc414199123 _Toc449869530 _Toc414199124 _Toc449869531 _Toc411405204 _Toc411405480 _Ref413748577 _Toc414199125 _Toc414199114 _Ref416274104 _Ref417128927 _Ref417290349 _Toc449869532 _Hlt421004129 _Ref417286060 _Toc449869533 _Toc411405197 _Toc411405473 _Ref412028393 _Toc414199115 _Ref415663975 _Ref417287889 _Ref421004161 _Ref421693928 _Toc449869534 _Toc414199116 _Toc449869535 _Ref417128162 _Toc449869536 _Toc449869537 _Toc414199118 _Ref420157351 _Toc449869538 _Ref416274068 _Toc449869539 _Toc411405205 _Toc411405481 _Ref413748639 _Toc414199126 _Ref416591760 _Ref417128795 _Ref417300511 _Ref418334424 _Ref418948513 _Toc449869540 _Toc414199127 _Toc449869541 _Toc414199128 _Ref420923317 _Toc449869542 _Toc414199129 _Ref420922745 _Toc449869543 _Toc414199130 _Ref418337353 _Toc449869544 _Toc414199131 _Toc449869545 _Toc414199132 _Toc449869546 _Toc414199134 _Toc449869547 _Ref412464620 _Toc414199135 _Toc449869548 _Toc414199136 _Toc449869549 _Toc411405206 _Toc411405482 _Ref413681462 _Toc414199137 _Ref416591806 _Ref417128833 _Ref417300541 _Ref418334453 _Ref418948620 _Toc449869550 _Toc414199138 _Toc449869551 _Toc414199139 _Ref418337380 _Toc449869552 _Toc414199140 _Toc449869553 _Toc414199141 _Toc449869554 _Toc414199142 _Toc449869555 _Toc414199143 _Ref417981169 _Toc449869556 _Toc411405207 _Toc411405483 _Toc414199144 _Ref416591872 _Ref417128880 _Ref417300575 _Toc449869557 _Toc414199145 _Ref422128412 _Toc449869558 _Toc414199146 _Toc449869559 _Toc414199147 _Toc449869560 _Toc414199148 _Toc449869561 _Toc414199149 _Toc449869562 _Toc414199150 _Toc449869563 _Toc414199151 _Toc449869564 _Toc414199152 _Toc449869565 _Toc414199153 _Toc449869566 _Toc414199154 _Toc449869567 _Ref411753015 _Toc414199155 _Toc449869568 _Toc411405208 _Toc411405484 _Toc414199156 _Toc449869569 _Toc411405209 _Toc411405485 _Toc414199157 _Ref417301436 _Ref417301470 _Ref418334482 _Toc449869570 _Toc414199158 _Ref417371359 _Ref417980909 _Ref418328214 _Ref418337408 _Ref418948678 _Toc449869571 _Toc414199159 _Toc449869572 _Toc414199160 _Ref428017081 _Toc449869573 _Toc414199161 _Toc449869574 _Toc411405210 _Toc411405486 _Toc414199162 _Ref417301568 _Toc449869575 _Toc411405211 _Toc411405487 _Ref411683931 _Ref411686157 _Toc414199163 _Ref417310251 _Ref420919899 _Toc449869576 _Toc414199164 _Ref419107451 _Ref419107472 _Toc449869577 _Toc414199165 _Ref417371289 _Ref417980778 _Toc449869578 _Toc449869579 _Toc414199166 _Ref418947705 _Toc449869580 _Toc414199167 _Ref419875240 _Toc449869581 _Toc414199168 _Toc449869582 _Hlt418339632 _Toc414199169 _Ref417376730 _Toc449869583 _Toc414199170 _Toc449869584 _Toc449869585 _Ref421689780 _Toc449869586 _Toc414199171 _Toc449869587 _Toc414199172 _Toc449869588 _Toc414199173 _Toc449869589 _Toc414199174 _Toc449869590 _Toc414199175 _Toc449869591 _Toc414199176 _Toc449869592 _Toc414199177 _Toc449869593 _Toc414199178 _Toc449869594 _Toc449869595 _Toc414199179 _Ref419875421 _Toc449869596 _Toc414199180 _Toc449869597 _Toc414199181 _Toc449869598 _Toc449869599 _Toc414199182 _Toc449869600 _Toc414199183 _Toc449869601 _Toc414199184 _Toc449869602 _Toc414199185 _Toc449869603 _Toc414199186 _Toc449869604 _Toc414199187 _Toc449869605 _Toc411405212 _Toc411405488 _Toc414199188 _Ref417310705 _Ref420920063 _Ref421693822 _Toc449869606 _Toc414199189 _Toc449869607 _Toc414199190 _Toc449869608 _Toc414199191 _Toc449869609 _Toc414199192 _Toc449869610 _Toc414199193 _Toc449869611 _Toc414199194 _Toc449869612 _Toc414199195 _Toc449869613 _Toc414199196 _Ref419875889 _Toc449869614 _Toc414199197 _Toc449869615 _Toc414199198 _Toc449869616 _Toc414199199 _Toc449869617 _Toc414199200 _Ref417983218 _Ref417983800 _Ref417983914 _Toc449869618 _Toc414199201 _Toc449869619 _Toc414199202 _Toc449869620 _Toc414199203 _Toc449869621 _Hlt418333402 _Ref413750547 _Toc414199204 _Toc449869622 _Toc414199205 _Toc449869623 _Toc449869624 _Toc414199207 _Toc449869625 _Toc414199208 _Toc449869626 _Toc414199209 _Toc449869627 _Toc414199210 _Ref418334512 _Ref418948799 _Ref420163369 _Toc449869628 _Toc449869629 _Toc449869630 _Ref428014731 _Toc449869631 _Ref428014795 _Ref428014833 _Toc449869632 _Toc411405213 _Toc411405489 _Ref412709003 _Toc414199214 _Toc449869633 _Toc411405214 _Toc411405490 _Toc414199215 _Ref417287116 _Ref420157406 _Toc449869634 _Hlt421004836 _Toc411405215 _Toc411405491 _Toc414199216 _Toc449869635 _Toc411405216 _Toc411405492 _Ref411773210 _Toc414199217 _Ref421003334 _Ref421696014 _Toc449869636 _Toc411405217 _Toc411405493 _Toc414199218 _Toc449869637 _Toc411405218 _Toc411405494 _Ref412028912 _Toc414199219 _Toc449869638 _Toc411405219 _Toc411405495 _Ref412709041 _Toc414199220 _Toc449869639 _Toc411405220 _Toc411405496 _Toc414199221 _Toc449869640 _Toc411405221 _Toc411405497 _Ref411751086 _Toc414199222 _Ref418066764 _Toc449869641 _Toc411405222 _Toc411405498 _Ref412453576 _Toc414199223 _Toc449869642 _Toc414199224 _Toc449869643 _Toc414199225 _Toc449869644 _Toc414199226 _Toc449869645 _Toc411405223 _Toc411405499 _Ref412464870 _Ref413835579 _Toc414199227 _Ref418325376 _Toc449869646 _Toc411405224 _Toc411405500 _Toc414199228 _Ref418325405 _Toc449869647 _Toc411405225 _Toc411405501 _Toc414199229 _Ref422128058 _Toc449869648 _Toc411405226 _Toc411405502 _Toc414199230 _Toc449869649 _Toc411405227 _Toc411405503 _Toc414199231 _Ref418945803 _Toc449869650 _Toc411405228 _Toc411405504 _Ref412631781 _Toc414199232 _Toc449869651 _Toc414199233 _Toc449869652 _Toc414199234 _Toc449869653 _Toc414199235 _Toc449869654 _Toc414199236 _Toc449869655 _Toc414199237 _Toc449869656 _Toc414199238 _Toc449869657 _Toc414199239 _Toc449869658 _Toc414199240 _Toc449869659 _Toc414199241 _Toc449869660 _Toc414199242 _Toc449869661 _Toc414199244 _Toc449869662 _Toc414199245 _Toc449869663 _Hlt411321158 _Ref413502693 _Toc414199246 _Toc449869664 _Toc449869665 _Toc449869666 _Toc449869667 _Toc449869668 _Toc449869669 _Toc449869670 _Toc449869671 _Toc449869672 _Toc449869673 _Toc449869674 _Toc449869675 _Toc449869676 _Toc449869677 _Toc449869678 _Toc449869679 _Toc449869680 _Toc449869681 _Toc411405246 _Toc411405522 _Toc414199263 _Toc449869682 _Ref422141956 _Toc449869683 _Toc411405249 _Toc411405525 _Ref411499510 _Hlt411499562 _Toc414199266 _Toc449869684 _Toc411405250 _Toc411405526 _Toc414199267 _Toc449869685 _Toc449869686 _Toc449869687 _Toc449869688 _Toc414199269 _Toc449869689 _Toc414199270 _Toc449869690 _Toc414199271 _Toc449869691 _Toc414199272 _Toc449869692 _Toc414199273 _Toc449869693 _Toc411405251 _Toc411405527 _Toc414199274 _Ref422830903 _Ref422912420 _Ref449774474 _Ref449776419 _Toc449869694 _Toc449869695 _Ref423165651 _Toc449869696 _Toc411405252 _Toc411405528 _Toc414199281 _Ref422831205 _Toc449869697 _Toc414199282 _Toc449869698 _Toc414199283 _Toc449869699 _Toc414199284 _Toc449869700 _Toc411405266 _Toc411405542 _Toc414199302 _Toc449869701 _Toc449869702 _Hlt417381966##::1o1o1o1o1o1o1o1o1o1o1o1o1oq}q}q}q}nnnn>>>>CCCCCCCC!?ðgggggbbbbkkkk\\\\nnnn    mmmm+D+D+D+D+DVVaapppp z z z z zPPPPPPffffSSSSSwwwww//++TT))wwwwjjjjb b b b l#l#l#l#CCCC_E_E_E_EjLjLjLjL@V@V@V@VZZZZjjjj$n$n$n$n:n:n@r@r@r@razazJJJJJׇׇׇׇݍݍݍݍߖߖߖߖ\\``¤¤88..????ԾԾCCRRRR    bbbbZZZZ,,8383JJJJI^I^I^I^ggggggggjujujujuxxxx`z`z`z`z~{~{qq44͙͙ћћڣڣKKͬͬͬͬ} } } } } } } } } } }          CCCC&&&&?*?*?*?*O/O/O/O/O/)1)133EEEJJhOhOxUxUxUxUUUUU^W^W__ccccnnnnn}}DžDžGGffnnwwwwtt((   WWWW!!!L0L066hNRRRRRYYYY [ [ [ [hhhhSmSmSmSmSmr{r{}}IIIII{++aalllMMMUUUUUUUmmmmmmm_______'''''''111>3>3>3>3>39999????EAEAEALLLLTTTT+c+c+c+c+ceeeegggkkZmZmZmtt{{{{{{tttt͐͐AAAaa````qqſſſ!!         ##bbIIII    PPPPP  0$0$((,,5555<<<GGIIIIII-Y-Y-Yaaaacccc=g=g=g=g=g+u+u+u+u+u+uvvvvvvooŕŕ****7jjww   LL%%%%%%&&O7O7999'B'BMMMUUUUUUWW^a^auu||||||||||||~~JJ]]uuRRRRRll55eeiiWWWMM++          o { {          n n & & * s0 s0 s0 : : M M M M M M M M M M [ [ n] n] n] a a a n n n x x y y N N = = Δ Δ Δ Δ Δ Δ Δ Δ Δ Δ    q q ^ ^   D D D    | | f f , ,   y y                 % % % % % % % `1 `1 A3 A3 A3 +8 +8 J J J J J T T T T T T T T ^ ^ ^ ^ ` ` ` ` i k k k q q q v v ?@ABCDEFGHIJKLMNOPQRSTUWVXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{}~|      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~()*+,-      !"#$%&'YZ./0123456789:;<=>?@ABCDEFGOPHIJKLMNQRSTUVWXYZ[\]^_defa`bcghijklmnopqrstuvwxyz{|}~     /0 !"#$%&'()*+,-.345612789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXZ[Y\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWX[\]^_`abcdefghijklmnopqrstuwxyvz{|}~""88NN=o=o}}}}MMMMCVVVaaaaۡA.Kʮڰggggggggggggyyyqqqq----kkkkzzzz 11. . . . 6D6D6D6D6D?V?VbbppppzzzzzttttttqqqqaaaaaPP==ggMMm m m m x#x#x#x#CCCCtEtEtEtE~L~L~L~L\V\V\V\VZZZZ4j4j4j4j9n9n9n9nQnQnererererszsz`````    )))),,,,uuzz٤٤gg@@FFFFSS//((((kkkk    ssss    wwww,,X3X3JJJJh^h^h^h^gggggggguuuuxxxxnznznznz{{ƆƆBB11ggججججѺѺÿÿ} } }             RRRR&&&&P*P*P*P*`/`/`/`/`/@1@133EEEJJwOwOUUUUUUUUtWtW1_1_scscnn o o o~~ՅՅɡɡ``oo%%%%}}---44> > > ffff!!!b0b066hNRRRRRRRRRYYYY%[%[%[%[hhhhdmdmdmdmdm{{%}%}ccc****::ss|||___Ueee))tttttttooooo''"'"'"'"''''(1(1(1Q3Q3Q3Q3Q39999????ZAZAZALLLL(T2T2T2TAcAcMcMcMceeeegggkkmmmmmm1t1t{{{{{{bbb||ʨʨʨʨoooo+++++ԿԿԿBB ,,gg]]]]++++VVVVV# # 5$5$((,,(5(5(5(5<<<GGIIII7Y7Y7Y7Y7Y7Y7YaaaaddddDgDgDgDgDgBuBuBuBuBuBuvvvvvvrrɕɕ*6667oo   PP%%%%%%&&S7S7999.B.BMMMUUUUUU"W"Wuauauu||||||~~OOiizz_____~~FFoouutttUU111     o            x x & & * 0 0 0 : : : : : : M M M M M M M M M M [ [ ] ] ] !a !a !a n n n y y y y v v H H Ԕ Ԕ Ԕ Ԕ Ԕ Ԕ Ԕ Ԕ Ԕ Ԕ  * * z z s s   [ [ [ ! ! ! m m < < - - 9 9        . . . . . . . % % % % % % % e1 e1 N3 N3 N3 D8 D8 J J J J J U U U U U U U U ^ ^ ^ ^ ` ` ` ` i k k k q q q v v @y y y y g T T ێ ێ ͔ ͔ ˚ ˚ N N M L L L L L z z  t t N N ʽ ʽ   O O Y Y      0 0 #: #: LC LC LC LC LC D D G G sN sN O S S S a a c Le Le f f u u | | | | |  H H H / / / / / - - 5 5 5 5 G G G G 0 0 0 0 0 0 0 D D D D z z z z z % % X X T T S S S S S          4" 4" % % ) ) a1 a1 4 4 9 9 U< U< A A 6C 6C D D lJ lJ lJ vJ vJ vJ J K R AU Z ] ]b e j u ~   9 , O O O O ] n t , , 9 9 k k M M       : ,; ssssyy}zzzz {{&{+{ نʍύߎ+1ïʯ$*mt8>PV!!111111BBCCwwyy@~I~T[mtć,2ouCJИ֘:@flԠڠԾ۾?EovKQelOUDJw %HOT[AHMT'GVXg9G x|l#q#$$$W$\$7(<((())))00q1u13333r4w45566GCLCcEmEEEEEFGJJMMi : : : : : : ; ; ; '; ); ,; xnnnnno o.o : : : : : ; ; ; '; (; (; ,;  Chris YoungC:\POVRAY3\PHS\pov.doc Chris YoungC:\POVRAY3\PHS\hope.doc Chris YoungC:\POVRAY3\PHS\hope.doc Chris YoungC:\POVRAY3\PHS\hope.doc Chris Young C:\povray3\phs\Backup of pov.wbk Chris Young C:\povray3\phs\Backup of pov.wbk Chris Young C:\povray3\phs\Backup of pov.wbk Chris Young C:\povray3\phs\Backup of pov.wbk Chris Young C:\povray3\phs\Backup of pov.wbk Chris YoungC:\POVRAY3\PHS\html\povuser.doc |@}ث~R.bH@Fd#\q-p} ..88.. OJQJo( OJQJo( 88OJQJo( OJQJo(hh. hhOJQJo(P@@.0..``...  ....  .....  ...... `....... 00........ -~}|  @: : ~: : op}~J K M N O +;  @t@ @$@T @X Z @GTimes New Roman5Symbol3& Arial?5 Courier NewWTms RmnTimes New RomanA1LetterGothic5& :Tahoma"0 hl4Fl4F{L)f E>g #0de POV-Ray 3.1 Documentation Chris Young Chris Young Oh+'0  8 D P \hpxPOV-Ray 3.1 Documentation0OV- Chris Younghri Normal.dot Chris Young2riMicrosoft Word 8.0t@@qnEܽ@xq@xq  ՜.+,D՜.+,T px   \Ee j POV-Ray 3.1 Documentation Title\(RZ _PID_GUID _PID_HLINKSAN{9A6CE421-9CBB-11D1-A91E-444553540000}AH[5http://www.adobe.com/prodindex/acrobat/readstep.htmlp_Rmailto:ram@iu.netJ%O mailto:adilger@enel.ucalgary.ca)Lmailto:espsw@compuserve.com"SI"mailto:100022.2603@compuserve.com( Fmailto:redaelli@inc.it;Cmailto:no13@no13.net[z@mailto:lutz@stmuc.comOq=mailto:thbaier@ibm.net$SDrawn\AXIS.GIF/ORendered\HAND.JPGKExamples\BEZDEMO.JPG}PSExamples\BLOBDEM1.JPG~P1[Examples\BLOBDEM2.JPGP#qExamples\BLOBDEM3.JPGxPxExamples\BLOBDEM4.JPGK5Examples\HFDEMO.JPGw\Ȇ Examples\LATHDEM1.GIFt\ Examples\LATHDEM2.GIFu\ Examples\LATHDEM3.GIFr\/ Examples\LATHDEM4.GIFs\ Examples\LATHDEM5.GIF5SExamples\POLYGDEM.GIF~TExamples\PRISMDM1.GIF}TExamples\PRISMDM2.GIF|T3Examples\PRISMDM3.GIF{TVExamples\PRISMDM4.GIFzTkExamples\PRISMDM5.GIFyTExamples\PRISMDM6.GIFl- Examples\TILES.JPG-Drawn\SOR1.GIFlExamples\SORDEMO.GIFq+Examples\TEXTCSG.JPGu LExamples\TORDEMO.JPGcLNExamples\SKYSPH1.JPGcORExamples\SKYSPH2.JPGcNExamples\SKYSPH3.JPGyUExamples\FOG1.JPGzUExamples\FOG2.JPG{UExamples\FOG3.JPG|U Examples\FOG4.JPG}U|!Examples\FOG5.JPG~U"Examples\FOG6.JPGvZO#Examples\RAINBOW1.JPGuZ$Examples\RAINBOW2.JPGtZ%Examples\RAINBOW3.JPGX~S&Drawn\Adapt2.gifA{&'Drawn\CAMERA1.GIFD'!(Drawn\blobeq.gifq)Drawn\BOX.GIF!R*Drawn\CONE.GIF(^ܢ+Drawn\CYLINDER.GIFA?,Drawn\HFIELD.GIFSy-Drawn\HFIELD2.GIFE( .Drawn\SPHERE.GIF k/Drawn\supereq.gif\c0Drawn\soreq1.gif\`s!1Drawn\soreq2.gif-;"2Drawn\SOR2.GIFy ,3Drawn\TORUS.GIF(‹4Drawn\csg1.gif(5Drawn\CSG2.GIF(6Drawn\CSG3.GIF(ɘ7Drawn\CSG4.GIF(8Drawn\CSG5.GIF0\&9Drawn\SPOT.GIF=:Drawn\SPOT-A.GIF>;Drawn\spot-b.gif?<Drawn\SPOT-C.GIF8ض=Drawn\SPOT-D.GIFx >Drawn\ADAPT.GIFK-?Drawn\fadeeq.gifs @Drawn\LIGHT.GIFgADrawn\CLIPPED.GIFM3 BDrawn\fade2eq.gifuʟ CDrawn\HEXAGON.GIF@pe DDrawn\QUILT1.GIF@s EDrawn\QUILT2.GIF@rڵ FDrawn\QUILT3.GIF@u GDrawn\QUILT4.GIF:MZ HRendered\TURBWALK.GIF$,y IDrawn\MIE1.GIF$Ry JDrawn\MIE2.GIF%TX{ KDrawn\RAYLEIGH.GIFX**~ LDrawn\HEYNEY.GIF  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~                           ! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~                           ! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~                            ! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~                            ! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~                            ! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~        !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry F m gܽ 6Data   1TableURWordDocumentg SummaryInformation(DocumentSummaryInformation8 CompObjjObjectPool 6 6  FMicrosoft Word Document MSWordDocWord.Document.89q