embodiments of the present invention will now be described with references to the accompanying figures , wherein like reference numerals refer to like elements throughout . the terminology used in the description presented herein is not intended to be interpreted in any limited or restrictive manner , simply because it is being utilized in conjunction with a detailed description of certain embodiments of the invention . furthermore , various embodiments of the invention ( whether or not specifically described herein ) may include novel features , no single one of which is solely responsible for its desirable attributes or which is essential to practicing the invention herein described . although the methods of the invention are described herein with steps occurring in a certain order , the specific order of the steps , or any continuation or interruption between steps , is not necessarily intended to be required for any given method of practicing the invention . as indicated above , although much of the description herein focuses on applications such as action video games , persons of ordinary skill in the art will understand that the invention has utility in a broad range of applications other than games . three - dimensional architectural renderings , virtual tours of art galleries and / or other institutions , real estate websites or similar displays , and other interactive virtual environments are just some of the many examples of such applications . thus , persons of ordinary skill in the art will understand that various terms used herein may have similar or identical concepts in industries and applications other than video games . likewise , persons of ordinary skill in the art will understand the basic concepts of constructing virtual 3d environments and avatars , having those avatars interact with those environments , and using cameras within that environment to provide the human player ( s ) an interface into those virtual worlds . they also will understand that , although much of the description herein refers to avatars , certain applications may not use “ avatars ” ( or at least not ones that are visible ). for example , they may attempt to give the user the illusion of “ first person ” traveling through the virtual world . in these cases , the system preferably will frame the shot based on the “ non - avatar ” pois that are in the relevant scene or area of the virtual environment . some of the basic logic and concepts involved in the methods and apparatus of the present invention can be appreciated by reference to the attached drawings . as shown in fig6 a , 6 b , and 6 c , an avatar 10 is typically designated as one of several points of interest ( pois ) within the virtual environment . as further explained below , by “ weighting ” the avatar sufficiently ( i . e ., making the avatar of sufficient “ importance ”), the programmer or designer can make it more likely ( or possibly even “ certain ”) that the camera that is selected ( to be displayed to the human user ) will be one that includes a view of the avatar . other pois are shown generically at locations 12 , 14 , 16 , and 18 . although these are illustrated as other “ person ” avatars , as indicated elsewhere these pois can be any desired “ thing ” in the virtual environment , including fixed or movable elements of scenery , pathways , enemy weapons or avatars , etc . each of these elements preferably can be created and assigned a “ weight ” by the programmer or designer , to provide the desired gameplay or other interaction for the human user . a ring of cameras 20 is also illustrated in fig6 a , 6 b , and 6 c , as including cameras 22 , 24 , 26 , 28 , 30 , and 32 . persons of ordinary skill in the art will understand that any suitable number and arrangement of cameras can be used within the invention depending on the specific application , and that the cameras can be ( among other things ) programmed so that they “ travel ” with the player &# 39 ; s avatar as it moves through the virtual world . among other things , cameras might not completely surround the avatar , might not be coplanar with each other , may be distributed around the avatar at equal intervals / angles from each other , etc . by way of example of non - coplanarity , camera 28 is positioned at about the “ floor ” of the environment , so that it generates an upwardly angled shot . in contrast , camera 22 is positioned to shoot from about “ chest height ” of the avatar . as discussed elsewhere , in many applications “ above and from behind the avatar ” will be a preferred / useful camera position . persons of ordinary skill in the art also will understand that , in many video games and other applications , the user &# 39 ; s avatar “ moves ” through the virtual world , either at the user &# 39 ; s direction or otherwise . accordingly , the positional relationship of the various elements illustrated in fig6 a , 6 b , and 6 c can be very dynamic , if ( for example ) a player &# 39 ; s avatar is running , jumping , spinning , or otherwise engaged in various “ movement ” activities within the virtual world . during the interaction of the player / avatar within the virtual world , the view displayed to the human user can be from any of the cameras illustrated in fig6 a , 6 b , and 6 c . various embodiments of the invention include methods and apparatus for providing a dynamic and automated selection from among those cameras , to provide to the user a desired visual experience to enhance the user &# 39 ; s interaction with the virtual world . depending on the particular application , that experience can be customized across a wide range of balancing of functionality and aesthetic experience for the user . in certain embodiments of the invention , the overall logic of the camera selection , position , and movement can be illustrated as shown in fig1 . this method preferably includes one or more of the steps , methods , and / or apparatus illustrated in that figure . as indicated in block 100 , the game / system display frame is updated / rendered on a periodic basis ( typically many times / second ). those rapid updates / renderings can each be slightly different from each other , resulting in the illusion ( to the human eye ) of movement . preferably , this game display refresh rate can occur at a different and / or varying time interval from the frequency of the update calculations of the movement damping procedure ( such as executing the algorithm of fig2 ). also preferably , the movement damping procedure / calculation ( see fig2 ) occurs on a fixed / constant time interval , to permit desirable control of the speed and / or acceleration of the camera as it moves through the virtual environment , so as to avoid “ jarring ” the human user . such “ jarring ” or other negative experiences can occur if a human user is confronted with displays of jerky or “ too - rapid ” camera movements . persons of ordinary skill in the art will understand that , although the example described in reference to fig1 is “ initiated ” by each display frame update , other embodiments can be triggered by other events . preferably , the process is triggered as often as is required to maintain visual quality within the simulation , as perceived by the human users of the system . examples include , without limitation , initiating the various processes of the invention based on a fixed timer / interval , a random time generator interval ( perhaps constrained within certain time limits ), etc . as indicated in block 102 , each time the system frame renders / updates , check : does the current camera provide a clear line of sight to the target ? if it does , the time counter is cleared ( set to zero ) as at block 110 . if not , increment the time counter ( accrue the time / game update frames that the camera has been at the current location / point ) ( see block 104 ), and then determine whether the time counter has reached its preset limit ( block 106 ). if it has not , the logic returns or loops back to await the next display frame update ( block 100 ) which kicks off the cycle again . if instead the time counter has reached its preset limit , this typically indicates that the camera has not moved for a number of frames . although such a failure to move can result from a player simply sitting idly ( rather than moving his avatar ), it also can result from other causes that could “ lock ” the system logic . using the video game example , if a camera is trailing behind an avatar and the avatar goes through a doorway , if the door shuts before the camera makes it through that doorway , certain “ reality rules ” might stop the camera from being able to follow the avatar through that door ( e . g ., cameras normally can &# 39 ; t travel through solid objects such as doors ). to handle such situations , once the time counter limit has been reached ( with no camera movement ), the system logic preferably disables or turns off the relevant rules ( such as the aforementioned prohibition against collisions or moving through solid objects ). this is illustrated in block 108 of fig1 . preferably , this disabling is only for the current update cycle , and the rule is “ reactivated ” for the next frame display update cycle . in other words , in such embodiments and in such situations , the camera is permitted to “ break ” certain “ rules ” and move in ways that normally would not be permitted by the system . as indicated in block 112 of fig1 , the logic preferably next selects a camera . this can be done with any suitable method , including the exemplary method illustrated in the “ finding the best point of view ( pov )” calculation process illustrated in fig5 . in order to avoid “ jarring movement ” of the camera ( which could disorient or , in the extreme , even nauseate the user ), the system preferably includes one or more means for “ dampening ” the movement that might otherwise occur . in the embodiment illustrated in fig1 , an interpolating damping procedure is used ( such as the one illustrated in the algorithm of fig2 ). this interpolator preferably uses a “ 3 - point ” iterative algorithm , using the following three points for each iteration : ( 1 ) the “ current point / location ” at which the camera is located at the time of the calculation ; ( 2 ) an “ ideal point / location ” which is the point selected as the “ best pov ” ( calculated in block 112 ); and ( 3 ) a “ desired point / location ” which is a point between the “ current ” and the “ ideal ” points , and which is used as a dampening link between the two . for certain situations ( such as when the player &# 39 ; s avatar is still and there are no “ targets ” around or enemies approaching within the virtual world ), the three points can be at the same location . once something forces the ideal point to move away from the current point , however , the algorithm can be used to help calculate the camera &# 39 ; s position and movement , for an improved player experience . in order to generate a more “ normal ” sensation of movement for the user , the camera preferably does not immediately track or move to the “ ideal point ”. instead , the 3 - point iteration allows the “ current ” point of the camera ( the one being viewed by the user ) to gradually accelerate toward the ideal point , and gradually slow down and stop at the ideal point ( if the user / avatar ever catches up with the “ ideal point ”). preferably , the interpolator calculates a proposed ( 1 ) movement of the “ desired point ” of the camera toward the “ ideal point ” by a distance determined by a preset “ desiredspeed ” variable ; and ( 2 ) movement of the “ current point ” of the camera toward the “ desired point ” by ( a ) the distance between the current and desired points multiplied by ( b ) a preset “ sponge factor ,” which is another variable that can be set by the programmer or designer ( see block 114 ). in addition , a number of “ movement modifiers ” can be programmed into a “ modifier stack ” of factors that the logic considers during each cycle of fig1 . examples of “ post interpolation ” modifiers are shown as various blocks within area 120 . as shown in block 122 , one such modifier can focus on whether the proposed camera movement ( calculated by the interpolator in block 114 ) will block the camera &# 39 ; s view of the target . if it will , that or another modifier can move the proposed camera position sufficiently close to the target so that camera &# 39 ; s view is not blocked ( see block 124 ). if the view is not blocked , the system can proceed to another modifier such as block 126 , which can check for camera collisions with geometry or blocking volumes ( stop at colliding object ). other examples of modifiers are shown in blocks 128 , 130 , and 132 . in block 128 , a modifier logic monitors whether the proposed movement of the camera will place it too far from the target . if yes , an “ auto snap ” or similar logic can be used ( see block 130 ) to force the camera to “ snap ” to a sufficiently close distance to meet whatever parameters have been programmed in that regard . in block 132 , a modifier can determine whether to push the camera up to a minimum distance above the “ floor ” or other surface of the virtual environment . persons of ordinary skill in the art will understand that the “ modifier stack ” concept of the invention can include modifiers that are applied after the interpolator calculation , before that calculation , or both . if after ( or “ post ”) modifying the calculated position , certain applications of the process can be described as “ massaging ” the calculated camera position . finally , after selection of the camera , interpolation calculations , and application of any modifiers , the “ new ” position of the camera is determined ( see block 134 ), and the program preferably moves the camera to that position . depending on the application and the circumstances , the “ move ” actuated in block 134 could be a move of zero distance . persons of ordinary skill in the art will understand that the foregoing modifiers are merely examples , and that virtually any desired factor can be incorporated into the “ modifier stack ” to affect the camera movement . as previously mentioned , these modifiers can even include some degree of “ camera control ” by the user ( although preferably the user is never given complete camera control , as that would remove many of the benefits that can be provided by the invention ). moreover , the order of application of the modifier calculations can be varied to suit the particular application for which the invention is being used , and there may not be any modifiers at all in certain applications . as shown in block 112 of fig1 , the system preferably “ automatically ” selects a camera from among various potential cameras . an example of such a selection process is illustrated in fig5 , entitled “ finding the best point of view ( pov ).” for each predefined camera that is a possible pov in the current situation in the virtual environment , the system preferably calculates a basic camera score for the pov ( see block 180 ). that calculation can be accomplished in any suitable manner , including by way of example via the process illustrated in fig4 . once that basic score has been calculated , the score can be further “ adjusted ” for other factors . in block 182 , for example , the score of a pov can be “ penalized ” or discounted based on the amount of rotation that would be required relative to the current camera . because large swings in camera orientation can be disorienting to a user , typically the programmer will discount the score further as the necessary “ orientation swing ” increases ( although the example of fig5 illustrates only a three - tiered discounting scheme , persons of ordinary skill in the art will understand that any number of stepped discounts or other approaches could be used within this step of the process ). once any such “ discounting ” ( or alternatively , “ enhancement ”, if a programmer uses some factor ( s ) that he / she deems make the camera more desirable ) has been applied to the camera score , that score is compared to the previous “ best ” score ( of those calculated during this cycle of “ finding the best pov ”) ( see block 184 ), and if better than that score , its associated camera position is saved / stored ( see block 186 ). if the score is not better than that previous score , the score and its associated camera position are discarded ( again , for purposes of this specific cycle of “ finding the best pov ”; see block 188 ). one of the many approaches to the camera scoring discussed above is illustrated in fig4 . for example , for applications such as video games ( or other “ target - rich ” applications ), a camera &# 39 ; s score can be increased for each valid target that would be displayed if that camera were to be selected ( see block 190 ). other “ modifiers ” can be programmed in the scoring , such as the one illustrated in block 192 ( will the camera be pushed closer to the player by terrain or by camera blocking volumes within the virtual environment ?). if yes , the camera &# 39 ; s score can be decreased , such as indicated in block 194 ( by the percentage by which the camera will be pushed in ). instead of a finite state machine approach such as taught in the aforementioned &# 39 ; 841 patent , the present invention preferably uses an approach such as a “ state stack ” or “ modifier stack .” although the camera has a “ base ” behavior that is determined by the state , that state is determined only in a very simple manner . for example , the camera can be constrained to be a chase camera or a rail camera ( fig3 and fig5 illustrate examples of such base behaviours ). beyond that simple base state or base behavior , the present invention can use a modifier stack so that , for example , any action that a user imparts to his avatar causes the program to move through a series of modifiers that travel with the camera . this provides a much more dynamic feel for the resulting video display seen by the user . preferably , the present invention also allows a programmer or designer to tag points of interest ( pois ) within the virtual world , and uses those pois dynamically to calculate and select a camera for display to the user , the position of the camera , and other things . the present invention also preferably reevaluates the camera shot on a virtually constant basis — such as every 1 / 30 of a second . this gives the user the impression that the shot is constantly moving as the user moves through the virtual world . in effect , this system virtually constantly evaluates the camera position , the player position , and the positions of the pois , all relative to each other on a per frame basis ( approximately 30 hz ). for many applications of the present invention , programmers and designers will constrain the camera apparatus and methods so that it cannot “ remove ” anything from the virtual scene ( just as things do not spontaneously move or disappear in the real world ). among other things , such changes would or could disrupt the user &# 39 ; s sense of continuity and immersion into the virtual world ( for example , if the camera were to suddenly cut from one location to another without any action on the user &# 39 ; s part ). in contrast to the “ cinematographic events ” taught in the aforementioned &# 39 ; 841 patent , preferred embodiments of the present invention do not have a module that ( a ) determines what kind of an “ event ” is occurring , and then ( b ) passes that information to another module . instead , the present invention preferably depends on the mode picked by the game designer . the designer can establish a number of pois ( e . g ., things about which the game designer has determined that the game should know ). typically , these pois can be things of relevance to the eventual player of the game . in addition to “ mobile ” items such as avatars that can move through the virtual world , these pois can include other mobile items ( such as enemy targets ) as well as items that have relatively “ fixed ” positions within the virtual world . as a player navigates through the virtual world , the camera preferably takes into account points of interest , and attempts to frame the camera shot appropriately based on the weight that the game designer has given to the various points of interest ( pois ), using the programming logic of the modifier stack or similar tool . as will be understood by persons of ordinary skill in the art , programmers and / or game designers can use any suitable hardware and / or software tools to practice the invention . these include not only personal computers and handheld or other gaming systems , but more broadly tools such as any suitable programming languages , platforms , coding programs , rendering engines , and many others . at the present time , examples of such tools and languages include c , c ++, and java , consoles from nintendo , sony , microsoft , or others , pcs or apple ( or other computers can be used ), etc . the specific algorithms , hardware , console , and other “ forms ” of the invention are virtually unlimited . in other words , the rendering engine , platform / console , and language used to practice the invention are arguably immaterial . instead , some of the main features of the invention that can be practiced in many different ways include having a three - dimensional rendering engine , points of interest ( pois ) of what you want to display within the virtual environment , and a camera view into that virtual world . the logic , apparatus , and techniques of the invention can be adapted to any suitable programming language , platform , or other aspect of presenting and / or interacting with three - dimensional virtual environments . in many applications and embodiments , the present invention can be implemented by the game designer or programmer selecting a single state ( either programmatically , or through use of a game design tool ) from one of a preferably small number of states , such as three states . although certain embodiments of the invention could include a larger or even “ large ” number of states , a small number of states is easier to program and much more manageable than having to code many specific behaviours . typically , the state chosen can provide a base behavior or motion for the camera . for example , in a wide open area of the virtual environment , a chase camera may be preferred , while in an enclosed space within the virtual environment , a camera that is constrained to a rail might be better suited ( might be more likely to provide a desired gameplay experience for the user ). preferably , whichever of the states is selected , that state can handle and implement virtually any action by the user within the scene . the camera preferably also can take into account all of the relevant points of interest ( pois ) as part of automatically determining the camera view , by using the modifier stack ( the programming that “ travels ” with the camera ) or similar technology . regarding the use of “ cinematographic rules ” or similar concepts ( to achieve heightened cinematographic effects , for example ), the present invention preferably includes some or all of those rules , but uses them only as guidelines . for example , for applications of the present invention involving an action video game , the invention preferably will not remove certain objects from the camera shot or automatically “ move ” or otherwise cause a discontinuity in the virtual world by adjusting the position of one of the people or objects within the camera shot . as another example , in many applications of the invention , the programmer / designer will attempt to avoid “ cutting ” any of the action within the virtual world . this is true even if such cutting would be more true to the cinematographic rules . thus , the present invention sometimes overrides the cinematographic rules with certain other principles ( such as the idea that you don &# 39 ; t want to disorient a player by having certain objects suddenly disappear or be moved to a different position , without having had any relevant input from the user ). thus , at least certain embodiments of the present invention can hold certain principles as being more important than the aforementioned “ cinematographic rules .” these additional principles can include , by way of example and not by way of limitation , not disorienting the human player , not allowing things to be removed from the camera shot , making it a priority to keep the player &# 39 ; s avatar on screen ( in the selected camera shot ), etc . in other words , the technology commonly used in movies ( following the cinematographic rules ) is different from the technology typically required in action video games ( such as ones that can be created with the present invention ). said another way , action video games are a different medium than movies or the video technologies in which the &# 39 ; 841 patent would be useful . in certain embodiments , the present invention can use cutting or tweening to define motion from one camera position to another . cuts provide an instantaneous transition from one view to another , but tend to disrupt gameplay . tweening can be accomplished with , for example , a 3 - point iterative calculation . in a preferred embodiments , the three points can be : the ideal position , desired position , and current position . in such embodiments , the ideal position as determined by the rest of the system can move to any location at any time . the desired position steps in a linear fashion in the direction of the ideal position , and the current position steps some fraction of the distance between it and the desired position . at rest ( when the player / character is not moving within the virtual scene ), all points are in the same location . during motion , however , the camera of the invention preferably automatically accelerates from rest , decelerates to rest , and smoothly deals with a dynamically changing target . one embodiment of a preferred motion of the ideal position can be described using a number of tools . in certain embodiments of the invention , the various degrees of freedom of the camera motion can be independently constrained . in certain embodiments , the motion can be constrained to a point , spline , or plane , and the camera target ( viewpoint ) and actual camera can both move independently using the same algorithm . in some embodiments , functions describe the possible paths that can be taken from rotation around targets , to linked positions on geometric shapes where the camera position is derived from the position of the target . in certain embodiments of the present invention , when the camera is unconstrained , it can use the aforementioned points of interest ( poi ) to determine the ideal location and rotation . using a weighting schema ( for example , a schema that takes into account attributes like the location on or off screen , angle off axis , unobstructed visibility , and / or other factors ), both the current frame and a number of possible frames are evaluated and the highest score is determined to be the best position . rulesets then determine the method of transitioning between the current and new best position , choosing a method of motion that does not break the rules of cinematography ( cutting across the axis , tweening overhead , etc ). the resultant camera motion of the invention provides a unique “ cinema style ” look and feel to an interactive experience such as an action videogame . in accordance with an exemplary embodiment of the present invention , the present video game camera system apparatus automatically changes the apparent moving direction of the camera and / or modifies the apparent camera angle depending upon the controlled character &# 39 ; s circumstance ( e . g ., he is inside a room , outside a room , on a ledge , behind a wall , running , jumping , swimming , scared , excited , isolated , anxious , surprised , etc . ), the position of other characters in the scene , environmental features , various special effects , and the occurrence of special events during gameplay . if the camera system detects that , for example , a wall exists between , for example , the player controlled character and a camera point of view , a calculation is made as to the required camera movement to prevent the obstruction between the eye of the camera and the object . the camera is then automatically moved to a new position in accordance with the calculated moving angle . the camera perspective is automatically changed to select the best camera angle according to the character &# 39 ; s circumstances so that the player can enjoy the visual effects being experienced in the three - dimensional world without having to control the camera him / herself . in another exemplary embodiment of the invention , a video game system includes a control processor for playing a video game including a game character controlled by a player . a camera system apparatus communicates with a camera and determines the direction of movement of the camera and / or modifies the apparent camera angle depending on the player controlled character &# 39 ; s circumstance . the position of the camera is modified during gameplay according to occurrences in the game , wherein a modifying amount is determined based on various factors , such as the character &# 39 ; s circumstance , the position of other characters in the scene , environmental features , various special effects . as indicated above , the methods and apparatus of the invention are useful for a wide variety of three - dimensional virtual environments . certain such video game environments can be described as having “ targets ” or points of interest ( pois ) that the programmer / designer can “ tag ” or otherwise mark or use for possible interaction with the user &# 39 ; s avatar or for other purposes . for some “ target rich ” environments ( such as shooting games , for example ), the invention can be practiced by using a specialized weighting system to determine the ideal camera position . under such an approach , and as illustrated in fig3 ( choosing a new camera ), one “ post ” modifier within the “ modifier stack ” can check the area around the player &# 39 ; s avatar ( within the virtual world ) for targets , and if any are found , can evaluate the best camera angle . this check or sweep is illustrated as logic / method steps and / or apparatus 50 , and it can be configured or structured on any desired basis , including by way of examples , checking out into the virtual environment to a certain radius from the player / avatar , checking for certain types of targets , etc ., or even combinations of such criteria . if there are no targets within range ( and / or that meet any other specified criteria ), then the camera positioning system falls back upon the other postmods in the programming stack ( as illustrated by logic / apparatus 60 ). however , if the sweep or check locates one or more targets ( or a predetermined minimum or maximum number of targets , for example ), the postmod can evaluate a number of possible alternative camera views and , if the analysis of those views shows that any is superior to the current view ( based on various factors and criteria that can be established on a customizable basis and used to “ score ” each camera , as illustrated in the example of fig4 ), the system selects that “ better ” camera view . typically , the alternative camera views that get evaluated are generally spread around a circle which is centered on the player &# 39 ; s location within the virtual environment . for applications other than action video games , the arrangement of potential cameras can be any suitable configuration . in some applications , for example , each camera view can be scored based on the number of targets the camera would have on screen and multiplied by the “ weights ” that the programmer / designer has assigned to each of the targets . in passing , for many video games , it is useful to program the player &# 39 ; s avatar as a poi and weight it very heavily , so that the system will be biased heavily toward including the avatar within the selected camera view . as mentioned above , the evaluation or scoring of each camera &# 39 ; s view also can take into account potentially “ negative ” factors . such factors include if there is any piece of virtual geometry or a combat camera “ blocking volume ” blocking the player . the score is further reduced by the percentage of the distance the camera must push forward in order to be closer to the player than the collision it detected . in certain of the embodiments discussed above , each camera view is then further penalized based on its orientation to the current view . camera views that are facing forward are worth their full score , views facing to either side are worth 50 % of their total score , and the views facing backwards or opposite to the current camera view are worth 25 %. the best camera view out of the set is stored via a vector from the target to the suggested camera location and is used when the camera updates its position in a later postmod process . in a preferred game application , the algorithm of fig2 scores the current camera view , and if any enemies are within range it calls for the ring of camera views to be scored to find out if there is a better camera position . otherwise , the system determines the camera position by evaluating the remainder of the postmods in the modifier stack . in certain embodiments of the invention , each character or avatar can have a number of dynamically - updated cameras whose position and rotation change depending on the location of the character in the world . this can provide to a programmer or designer a large numbers of potential cameras from which to choose at any given time , and the camera can be selected by the best point of view algorithm ( discussed above ). such embodiments are analogous to a major sporting event where there are many cameras placed throughout the venue , all simultaneous providing a different view of the action , with a coordinator ( here , the logic of the various algorithms and the modifier stack ) making a decision about which shot best frames the current action . the algorithm illustrated in fig3 scores a single camera view by going through the list of targets , validating those targets , and adding their score to the camera &# 39 ; s total . it also applies a penalty to the camera view &# 39 ; s score when it detects a collision between the camera location and the target ( which may be the player / avatar ). after all of these calculations , it returns the score . as discussed above , in certain embodiments the camera &# 39 ; s movement is controlled by a dampening system such as a three - point interpolation system . the “ movement dampening ” can help provide smooth camera movement while track a moving target ( the player / avatar ) whose velocity is neither constant nor straight . as indicated above , the interpolation algorithm uses three points or values : current point / value / location : where the interpolated value actually is . this value is always used in calculations to achieve smooth motion . middle or “ desired ” value : this point moves a fixed distance at a fixed frequency . for example , it may step 10 world units ever 1 / 60th of a second . this point moves in a straight line towards the final ( or ideal ) value or point . final / ideal value : this is the final location to where the interpolator is trying to go . preferably , this value can immediately snap to any location , because the system protects the user against experiencing anything other than a smooth motion . in many applications , the designer can manually place “ volumes ” into the virtual environment using an offline editor . these volumes encompass a given area of the virtual world , and can provide a means for the designers to give information to the camera system . property volumes : these can allow for basic properties of the camera to be modified when the target is within a volume . ( such as target and camera offsets , fov , speeds , sponge factors , etc ) trajectory volumes : these can allow for the camera to be forced to face a given direction ( but still aimed at the target ). point of influence volumes : give the ability to specify an actor ( the influence actor ) to focus the camera on in addition to the target . each point of influence volume has a point of influence circle . when the target enters this circle and nears the centre of the circle , the camera will progressively focus on the influence actor . an option also allows the camera to always keep the target in view . as mentioned above , postmod &# 39 ; s preferably can be applied in a “ stack ” form , allowing a designer to push and pop various modifiers . in one embodiment , each postmod stands alone as a single task to be accomplished . this allows combinations of various modifiers to influence the camera behavior , and also allows the camera to have a sense of “ state ” so that transitioning to these styles or modifications is transparent . examples of “ postmod ” or other modifications that include the following , although the system is flexible enough to allow a wide variety of additional modifiers beyond and / or instead of those listed here : cornering : this post mod will physically rotate the camera around corners . basic properties : this will apply some offsets which can be read in from configuration file styles post mod : the camera can have “ styles ” on it which are read in from a configuration file . each style is a collection of properties which will be applied . point of influence : this will watch for volumes that the player stands in which have a point of interest attached to it . the camera will rotate towards this point to show it . ( placed in editor in advance ) properties volumes : allows the properties of the camera to be changed on the fly when inside of a particular volume ( placed in editor ) trajectory volumes : forces the camera to align to a certain direction along a combination of the x / y / z axis . ( placed in editor ) camera aiming : this allows a button press to cause the camera to snap to be behind the target and allow a “ free look ” on the thumbstick to look around in a preferred application , the camera &# 39 ; s base motion uses two interpolators that track the current camera &# 39 ; s position as well as the target &# 39 ; s location . typically , the target location tracks the root of the character , although as the character animates through the world , this motion can be erratic . to dampen the erratic aspects of this motion , designers and programmers can apply additional interpolators . in certain video game or similar applications , when the camera is not constrained to a spline , plane or a point , the ideal position of the camera typically can be some distance away from the player with a target at the player &# 39 ; s location . in addition , there is a target and camera offset which preferably are specified in the camera &# 39 ; s local space . these are added on to the base locations to give the camera additional height and rotation . when transitioning to and from placed cameras , the generic position logic ( including any postmod stack logic ) preferably is applied . in some embodiments , the camera also can have the ability to cut immediately to the new location . as mentioned above , the system preferably includes a means or method or dampening the “ virtual movement ” of the camera that is experienced by the human user . although other dampening approaches can be employed , the example of the drawings uses a “ 3 - point iterative calculation algorithm ” ( or “ 3pica ”). as illustrated in fig2 , such an approach can include accumulating the “ unused ” delta time for each update / rendering of the display / frame ( block 200 ). as indicated in block 202 , if that accumulated time is at least as great as the update frequency that has been programmed for the 3pica itself ( which commonly is set at or around 1 / 60th of a second ), the system preferably returns to block 200 to accumulate further time as part of the next update / rendering of the display / frame . once sufficient time has accumulated for the logic to pass through block 202 , block 204 illustrates that the system determine the number of camera position updates that can be achieved within that accumulated time . this can be conveniently done , for example , by taking the largest whole number y that results from dividing the frequency of the 3pica into the accumulated frame time ( or “ delta time ”). for y number of times , the 3pica then iterates or cycles through the two calculations shown in iteration loop 214 ( blocks 206 and 208 ). the logic illustrated in block 206 calculate a line from the desired / middle point or value towards the ideal / final point or value , and moves the desired / middle point or value “ desired speed ” units in that direction . it also ensures that the desired point does not “ overshoot ” the ideal / final point . the logic illustrated in block 208 calculate a line from the “ current ” point / value towards the “ desired ”/ middle value , and moves the “ current ” value along this line , by a “ sponge factor .” this sponge factor preferably is a value between 0 and 1 , and is selected by the programmer to determine the percentage of the calculated distance that the current value / point ( the camera &# 39 ; s current position ) should be moved . for example , a sponge factor value of 0 . 5 means the current point moves halfway along the line calculated in block 208 . the apparatus and methods of the present invention have been described with some particularity , but the specific designs , constructions , and steps disclosed are not to be taken as delimiting of the invention . modifications and further alternatives will make themselves apparent to those of ordinary skill in the art , all of which will not depart from the essence of the invention and all such changes and modifications are intended to be encompassed within the appended claims .