Virtual lens control method and device, electronic equipment and storage medium

Abstract

The invention provides a virtual lens control method and device, electronic equipment and a storage medium. The method comprises the steps that a virtual scene is displayed based on a first virtual lens corresponding to the view angle of a first virtual object, the virtual scene comprises a virtual carrier, and the first virtual object is located in the virtual carrier; in response to a trigger operation for the virtual carrier, the virtual carrier is controlled to move, the first virtual lens is controlled to shake in the moving process of the virtual carrier, and feature parameters of shaking of the first virtual lens are matched with the current state of the virtual carrier. According to the method and the device, the driving experience felt and recognized by a player in the real world can be simulated, so that the problem that the experience feeling of the player is poor due to the fact that the movement of the virtual carrier is too smooth is solved.

Description

Technical Field

[0001] The present application relates to the field of Internet technologies, and in particular, to a method, an apparatus, an electronic device, and a storage medium for controlling a virtual camera. Background Art

[0002] The display technology based on graphics processing hardware has expanded the channels for perceiving the environment and obtaining information. In particular, the display technology of virtual scenes can realize diverse interactions between virtual objects controlled by users (or players) or artificial intelligence according to actual application requirements, and has various typical application scenarios. For example, in virtual scenes such as games, it can simulate the real battle process between virtual objects.

[0003] Taking a multiplayer game as an example, in the solution provided by the related art, due to the compromise of the multiplayer game on the computing power of the running device, network bandwidth and other limiting conditions, the game scene mainly focuses on visual performance. When the game physics engine calculates the interaction between the virtual vehicle and the game scene for many visually rough game scenes, these scenes are actually regarded as flat surfaces by the game physics engine. This will cause the movement of the virtual vehicle to be too smooth and have a large difference from the visual performance of the game scene, resulting in a large gap between the vehicle driving experience in the multiplayer game and the driving experience that players feel and recognize in the real world, and leading to a poor experience for players. Summary of the Invention

[0004] Embodiments of the present application provide a method, an apparatus, an electronic device, a computer-readable storage medium, and a computer program product for controlling a virtual camera, which can simulate the driving experience that players feel and recognize in the real world, so as to solve the problem that the experience of players is poor due to the overly smooth movement of the virtual vehicle.

[0005] The technical solution of the embodiments of the present application is implemented as follows:

[0006] Embodiments of the present application provide a method for controlling a virtual camera, including:

[0007] Displaying a virtual scene based on a first virtual camera corresponding to the perspective of a first virtual object, where the virtual scene includes a virtual vehicle, and the first virtual object is located in the virtual vehicle;

[0008] Responding to a trigger operation on the virtual vehicle, controlling the virtual vehicle to move, and

[0009] During the movement of the virtual vehicle, controlling the first virtual camera to shake, where the characteristic parameters of the shaking of the first virtual camera match the current state of the virtual vehicle.

[0010] Embodiments of the present application provide a device for controlling a virtual camera, including:

[0011] A display module for displaying a virtual scene based on a first virtual camera corresponding to the perspective of a first virtual object, wherein the virtual scene includes a virtual vehicle and the first virtual object is located in the virtual vehicle;

[0012] A control module for controlling the movement of the virtual vehicle in response to a trigger operation on the virtual vehicle;

[0013] The control module is further configured to control the first virtual camera to jitter during the movement of the virtual vehicle, wherein the characteristic parameters of the jitter of the first virtual camera match the current state of the virtual vehicle.

[0014] An embodiment of the present application provides an electronic device, including:

[0015] A memory for storing executable instructions;

[0016] A processor for implementing the control method of the virtual camera provided by the embodiment of the present application when executing the executable instructions stored in the memory.

[0017] An embodiment of the present application provides a computer-readable storage medium storing computer-executable instructions for implementing the control method of the virtual camera provided by the embodiment of the present application when being executed by a processor.

[0018] An embodiment of the present application provides a computer program product including a computer program or computer-executable instructions for implementing the control method of the virtual camera provided by the embodiment of the present application when being executed by a processor.

[0019] The embodiment of the present application has the following beneficial effects:

[0020] During the movement of the virtual vehicle, characteristic parameters matching the current state of the virtual vehicle are obtained, and the virtual camera corresponding to the perspective of the virtual object is controlled to jitter based on the characteristic parameters, so as to simulate the driving experience felt and recognized by the player in the real world, thereby solving the problem that the player's experience is poor due to the overly smooth movement of the virtual vehicle. Description of the Drawings

[0021] Figure 1 is a schematic structural diagram of a control system 100 of a virtual camera provided by an embodiment of the present application;

[0022] Figure 2 is a schematic structural diagram of an electronic device 500 provided by an embodiment of the present application;

[0023] Figure 3 is a schematic flow diagram of a control method of a virtual camera provided by an embodiment of the present application;

[0024] Figures 4A to 4F is a schematic flowchart of a method for controlling a virtual lens provided by an embodiment of the present application;

[0025] Figure 5A and Figure 5B is a schematic diagram of an application scenario of a method for controlling a virtual lens provided by an embodiment of the present application;

[0026] Figure 6 is a schematic diagram of an application scenario of a method for controlling a virtual lens provided by an embodiment of the present application;

[0027] Figure 7 is a schematic flowchart of a method for controlling a virtual lens provided by an embodiment of the present application. Detailed implementation manners

[0028] In order to make the objectives, technical solutions, and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be construed as limiting the present application. All other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of the present application.

[0029] In the following description, "some embodiments" are involved, which describe a subset of all possible embodiments. However, it can be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict.

[0030] It can be understood that in the embodiments of the present application, data related to user information, etc. (such as data of a game character controlled by a user) is involved. When the embodiments of the present application are applied to specific products or technologies, user permission or consent needs to be obtained, and the collection, use, and processing of relevant data need to comply with relevant laws, regulations, and standards of relevant countries and regions.

[0031] In the following description, the terms "first / second / ..." involved are only used to distinguish similar objects and do not represent a specific order for the objects. It can be understood that "first / second / ..." can be interchanged with a specific order or sequence when allowed, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0032] In the embodiments of the present application, the term "module" or "unit" refers to a computer program with a predetermined function or a part of a computer program, which works together with other related parts to achieve a predetermined goal, and can be fully or partially implemented by using software, hardware (such as a processing circuit or a memory), or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an overall module or unit that includes the functions of that module or unit.

[0033] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the technical field to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0034] Before further elaborating on the embodiments of this application, the nouns and terms involved in the embodiments of this application are described. The nouns and terms involved in the embodiments of this application are applicable to the following explanations.

[0035] 1) In response to: used to represent the conditions or states on which the executed operations depend. When the dependent conditions or states are met, one or more executed operations can be real-time or can have a set delay; without special instructions, there is no limit on the execution order of the multiple executed operations.

[0036] 2) Virtual scene: a scene displayed (or provided) when an application runs on a terminal device. This scene can be a simulation environment of the real world, a semi-simulated and semi-fictional virtual environment, or a purely fictional virtual environment. The virtual scene can be any one of a two-dimensional virtual scene, a 2.5D virtual scene, or a three-dimensional virtual scene. The embodiments of this application do not limit the dimension of the virtual scene. For example, the virtual scene can include the sky, land, ocean, etc. The land can include environmental elements such as deserts and cities, and users can control virtual objects to move in this virtual scene.

[0037] 3) Virtual object: the images of various people and objects that can interact in a virtual scene, or movable objects in a virtual scene. The movable object can be a virtual character, a virtual animal, an anime character, etc., such as the characters and animals displayed in a virtual scene. The virtual object can be a virtual image in a virtual scene that represents the user. A virtual scene can include multiple virtual objects, and each virtual object has its own shape and volume in the virtual scene and occupies a part of the space in the virtual scene.

[0038] 4) Virtual vehicle: refers to a virtual transportation vehicle used to transport virtual objects in a virtual scene, such as including virtual trucks, virtual racing cars, and virtual motorcycles, etc.

[0039] 5) Cloud gaming: Also known as Gaming on Demand, it deploys game programs in the server and runs an instance of the game program (simply referred to as a game instance). The game instance sends the game data output during the running process to the browser page of the user terminal. The page calls the media component of the browser to decode the game data and renders the real-time game screen during the game according to the decoding result. When the page detects the operations performed by the user in the game screen, it reports them to the game instance running in the server. When receiving the game data for the response operations generated by the game instance, it repeats the decoding and rendering processes, so that the game screen presented in the page changes according to the user's operations.

[0040] That is to say, cloud gaming is an online game technology based on cloud computing technology. Cloud gaming technology enables thin client devices with relatively limited graphics processing and data computing capabilities to run high-quality games. In the cloud gaming scenario, the game does not run on the user terminal (such as the player's game terminal), but on the cloud server, and the cloud server renders the game scene into an audio-video stream and transmits it to the user terminal through the network. In this way, the user terminal does not need to have powerful graphics computing and data processing capabilities, but only needs to have basic streaming media playback capabilities and the ability to obtain the player's input instructions and send them to the cloud server.

[0041] The embodiments of the present application provide a method, device, electronic device, computer-readable storage medium, and computer program product for controlling a virtual camera, which can simulate the driving experience felt and perceived by a player in the real world to solve the problem that the player's experience is poor due to the overly smooth movement of the virtual vehicle. The electronic device provided by the embodiments of the present application will be described below. The electronic device provided by the embodiments of the present application can be implemented as a terminal device (corresponding to a stand-alone game application), or jointly implemented by a terminal device and a server (corresponding to a networked game application). The following takes the method for controlling the virtual camera provided by the embodiments of the present application jointly implemented by the server and the terminal device as an example for description.

[0042] Before introducing the architecture of the control system for the virtual camera provided in the embodiments of the present application, the game modes involved in the embodiments of the present application will be introduced first. For the solution implemented in cooperation between the terminal device and the server, there are mainly two game modes, namely the local game mode and the cloud game mode. Among them, the local game mode means that the terminal device and the server cooperate to run the game processing logic. Some of the operation instructions input by the player in the terminal device are processed by the terminal device running the game logic, and the other part is processed by the server running the game logic. Moreover, the game logic processing run by the server is often more complex and requires more computing power. The cloud game mode means that the game logic processing is completely run by the server (such as a cloud server), and the cloud server renders the game scene data into an audio-video stream, and then transmits it to the terminal device through the network for display. That is to say, the terminal device only needs to have the basic ability to play the media stream, obtain the operation instructions of the player and send them to the server.

[0043] The architecture of the control system for the virtual camera provided in the embodiments of the present application will be described below.

[0044] Exemplarily, refer to Figure 1 , Figure 1 which is a schematic diagram of the architecture of the control system 100 for the virtual camera provided in the embodiments of the present application. It is an application for realizing the support of the driving experience that the player feels and perceives in the real world, so as to solve the problem that the player's experience is poor due to the overly smooth movement of the virtual vehicle, as Figure 1 shown. The control system 100 for the virtual camera includes: a server 200, a network 300, and a terminal device 400. Among them, the network 300 can be a local area network or a wide area network, or a combination of the two. The terminal device 400 is a terminal device associated with the user. A client 410 runs on the terminal device 400. The client 410 can be various types of clients, such as a racing game client, a battle royale game client, a shooting game client, and a browser, etc.

[0045] In some embodiments, a virtual scene obtained by observing based on a first virtual camera corresponding to the perspective of a first virtual object (e.g., the game character A currently controlled by the player), including a first-person perspective and a third-person perspective, can be displayed in the human-computer interaction interface of the client 410. The virtual scene may include a virtual vehicle (e.g., a virtual car), and the first virtual object may be located in the virtual vehicle. For example, the player can control the first virtual object to enter the virtual vehicle by clicking the get-on button. Subsequently, the client 410 can control the virtual vehicle to move in the virtual scene in response to the player's triggering operation (e.g., a click operation) on the virtual vehicle, and during the movement of the virtual vehicle, control the first virtual camera to jitter. The characteristic parameters of the jitter of the first virtual camera (e.g., including the jitter time parameter and the jitter intensity parameter) can be matched with the current state of the virtual vehicle (e.g., including the acceleration state, deceleration state, steering state, and collision state, etc.). In this way, the driving experience that the player perceives and recognizes in the real world can be simulated to solve the problem of poor player experience caused by the overly smooth movement of the virtual vehicle.

[0046] It should be noted that the virtual scene in the virtual camera control method provided in the embodiments of the present application can be completely output based on the terminal device, or output in cooperation with the terminal device and the server. For example, the relevant data calculation and output of the virtual scene can be completely completed depending on the graphics processing hardware computing power of the terminal device 400. The types of graphics processing hardware include a central processing unit (CPU, Central Processing Unit) and a graphics processing unit (GPU, Graphics Processing Unit). For example, when forming the visual perception of the virtual scene, the terminal device 400 calculates the data required for display through the graphics computing hardware, and completes the loading, parsing, and rendering of the display data. The graphics output hardware outputs a video frame capable of forming a visual perception of the virtual scene. For example, a two-dimensional video frame is presented on the display screen of a smart phone, or a video frame with a three-dimensional display effect is projected onto the lens of an augmented reality / virtual reality glasses; in addition, in order to enrich the perception effect, the terminal device 400 can also form one or more of auditory perception, tactile perception, motion perception, and taste perception by means of different hardware.

[0047] Of course, it is also possible to rely on the computing power of the server 200 to complete virtual scene calculation and output the virtual scene on the terminal device 400. For example, taking the formation of visual perception of the virtual scene as an example, the server 200 calculates the display data related to the virtual scene (such as scene data) and sends it to the terminal device 400 through the network 300. The terminal device 400 depends on the graphics computing hardware to complete the loading, parsing, and rendering of the calculated display data, and depends on the graphics output hardware to output the virtual scene to form visual perception. For example, a two-dimensional video frame can be presented on the display screen of a smartphone, or a video frame with a three-dimensional display effect can be projected on the lens of an augmented reality / virtual reality glasses; for the perception of the form of the virtual scene, it can be understood that the corresponding hardware output of the terminal device 400 can be used, such as using a microphone to form auditory perception, using a vibrator to form tactile perception, and so on.

[0048] In some other embodiments, the embodiments of the present application can also be implemented with the help of cloud technology. Cloud technology refers to a hosting technology that unifies a series of resources such as hardware, software, and networks within a wide area network or a local area network to achieve data calculation, storage, processing, and sharing.

[0049] Cloud technology is a general term for network technology, information technology, integration technology, management platform technology, and application technology based on the cloud computing business model. It can form a resource pool, be used on demand, and is flexible and convenient. Cloud computing technology will become an important support. The background services of the technical network system require a large amount of computing and storage resources.

[0050] For example, Figure 1 the server 200 in [] can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery network (CDN), and big data and artificial intelligence platforms. The terminal device 400 can be a smartphone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, a vehicle terminal, etc., but is not limited thereto. The terminal device 400 and the server 200 can be directly or indirectly connected through wired or wireless communication methods, which are not limited in the embodiments of the present application.

[0051] In some embodiments, the terminal device or the server may also implement the control method of the virtual lens provided in the embodiments of the present application by running various computer-executable instructions or computer programs. For example, the computer-executable instructions may be commands at the microprogram level, machine instructions, or software instructions. The computer program may be a native program or software module in the operating system; it may be a local (Native) application (APPlication, APP), that is, a program that needs to be installed in the operating system to run, such as a multiplayer game APP; it may also be a small program that can be embedded in any APP, that is, a program that only needs to be downloaded to the browser environment to run. In short, the above computer-executable instructions may be instructions in any form, and the above computer programs may be application programs, modules, or plugins in any form.

[0052] Next, the structure of the electronic device provided in the embodiments of the present application will be further described. Taking the electronic device as a terminal device as an example, refer to Figure 2 , Figure 2 which is a schematic structural diagram of the electronic device 500 provided in the embodiments of the present application. Figure 2 The electronic device 500 shown includes: at least one processor 510, a memory 550, at least one network interface 520, and a user interface 530. Each component in the electronic device 500 is coupled together through a bus system 540. It can be understood that the bus system 540 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 540 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clear illustration, in Figure 2 all kinds of buses are labeled as the bus system 540.

[0053] The processor 510 may be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP, Digital Signal Processor), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor may be a microprocessor or any conventional processor, etc.

[0054] The user interface 530 includes one or more output devices 531 that enable the presentation of media content, including one or more speakers and / or one or more visual display screens. The user interface 530 also includes one or more input devices 532, including user interface components that facilitate user input, such as a keyboard, a mouse, a microphone, a touch screen display, a camera, other input buttons, and controls.

[0055] The memory 550 can be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disc drives, etc. The memory 550 optionally includes one or more storage devices that are physically remote from the processor 510.

[0056] The memory 550 includes volatile memory or non-volatile memory, and may also include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), and the volatile memory can be random access memory (RAM). The memory 550 described in the embodiments of the present application is intended to include any suitable type of memory.

[0057] In some embodiments, the memory 550 is capable of storing data to support various operations. Examples of such data include programs, modules, and data structures, or subsets or supersets thereof, which are exemplarily described below.

[0058] The operating system 551 includes system programs for processing various basic system services and performing hardware-related tasks, such as the framework layer, the core library layer, the driver layer, etc., for implementing various basic services and processing hardware-based tasks;

[0059] The network communication module 552 is used to reach other computing devices via one or more (wired or wireless) network interfaces 520. Exemplary network interfaces 520 include: Bluetooth, Wi-Fi (Wireless Fidelity), and USB (Universal Serial Bus), etc.;

[0060] The presentation module 553 is used to enable the presentation of information (such as a user interface for operating peripheral devices and displaying content and information) via one or more output devices 531 associated with the user interface 530 (such as a display screen, a speaker, etc.).

[0061] The input processing module 554 is used to detect and translate one or more user inputs or interactions from one of one or more input devices 532.

[0062] In some embodiments, the device provided by the embodiments of the present application can be implemented in software. Figure 2The control device 555 of the virtual lens stored in the memory 550 is shown, which can be software in the form of programs and plugins, etc., and includes the following software modules: a display module 5551, a control module 5552, an acquisition module 5553, a detection module 5554, a broadcast module 5555, a playback module 5556, and a magnification module 5557. These modules are logical, so they can be combined arbitrarily or further split according to the functions implemented. It should be noted that, in Figure 2 for the convenience of expression, all the above modules are shown at once, but it should not be regarded as excluding the implementation that the control device 555 of the virtual lens may only include the display module 5551 and the control module 5552. The functions of each module will be described below.

[0063] Next, the control method of the virtual lens provided in the embodiments of the present application will be specifically described in combination with the exemplary applications and implementations of the terminal device provided in the embodiments of the present application.

[0064] Exemplarily, referring to Figure 3 , Figure 3 is a schematic flowchart of the control method of the virtual lens provided in the embodiments of the present application, and will be described in combination with the Figure 3 steps shown.

[0065] It should be noted that, Figure 3 the method shown can be executed by various forms of computer programs running on the terminal device, and is not limited to the client. For example, it can also be the operating system, software modules, scripts, and applets described above. Therefore, the example of the client in the following should not be regarded as a limitation to the embodiments of the present application. In addition, for the convenience of expression, the terminal device and the client running on the terminal device will not be specifically distinguished in the following.

[0066] In step 101, a virtual scene is displayed based on a first virtual lens corresponding to the perspective of a first virtual object.

[0067] Here, the virtual scene may include a virtual vehicle, and the first virtual object (such as the game character A controlled by the current player) may be located in the virtual vehicle.

[0068] In some embodiments, taking the game character A controlled by player 1 as the first virtual object as an example, a virtual scene observed based on a virtual camera (i.e., the first virtual camera) corresponding to the perspective of the game character A (e.g., including the first-person perspective and the third-person perspective) can be displayed in the human-computer interaction interface of the client. Among them, a virtual vehicle (e.g., a virtual car) can be displayed in the virtual scene, and the game character A can be located in the virtual vehicle. For example, player 1 can control the game character A to enter the virtual vehicle by clicking the get-on button. Among them, the virtual vehicle can be driven by the game character A (i.e., the game character A controlled by player 1 is the driver), or can be driven by other virtual objects (e.g., the game character B controlled by player 2) (i.e., the game character A controlled by player 1 is just a passenger), or can be driverless. The embodiments of the present application do not make specific limitations on this.

[0069] It should be noted that for the first-person perspective, the first virtual camera can be set at the position where the eyes of the first virtual object are located, that is, to play the virtual object in the game from the perspective of the current player himself; for the third-person perspective, the first virtual camera can be set behind the first virtual object, that is, the player can follow the virtual object in the game to play the game, and the first-person perspective and the third-person perspective can be switched arbitrarily. For example, the player can switch the perspective by clicking a specific button.

[0070] In step 102, in response to a trigger operation on the virtual vehicle, control the virtual vehicle to move.

[0071] In some embodiments, taking the virtual vehicle as a virtual car as an example, a start button can also be displayed in the virtual scene. When receiving a click operation of the player on the start button, the virtual car can be controlled to move in the virtual scene. Of course, the player can also control the virtual vehicle to move by pressing a specific button on the keyboard. The embodiments of the present application do not make specific limitations on this.

[0072] In step 103, during the movement of the virtual vehicle, control the first virtual camera to shake.

[0073] Here, the characteristic parameters (or called the camera shake effect) of the first virtual camera shake can be matched with the current state of the virtual vehicle (e.g., including the acceleration state, deceleration state, steering state, and collision state, etc.).

[0074] It should be noted that for different states of the virtual vehicle, the embodiments of the present application can pre-configure corresponding characteristic parameters. For example, a mapping relationship can be pre-created between different states of the virtual vehicle and different characteristic parameters (including jitter time parameters and jitter intensity parameters) (for example, a mapping table as shown in Table 1 can be pre-created). In this way, when the current state of the virtual vehicle is obtained, the corresponding characteristic parameters can be quickly obtained based on the pre-created mapping relationship, and then the first virtual camera can be controlled to jitter based on the obtained characteristic parameters.

[0075] Table 1 Mapping table between different states of the virtual vehicle and different characteristic parameters

[0076]

[0077]

[0078] In some embodiments, the above characteristic parameters may include a jitter time parameter and a jitter intensity parameter (or specific jitter parameters). Among them, the jitter time parameter may include a jitter duration (assumed to be denoted as t), a jitter fade-in time (assumed to be denoted as t_in), and a jitter fade-out time (assumed to be denoted as t_out), and it is satisfied that the jitter duration is greater than or equal to the sum of the jitter fade-in time and the jitter fade-out time (i.e., t≥t_in + t_out). The jitter intensity parameter may include the offsets of the position and rotation of the first virtual camera in the local coordinate system, where the local coordinate system is a coordinate system in the virtual scene with the first virtual camera as the coordinate origin. For example, the offsets of the position and rotation of the first virtual camera in the local coordinate system may include the offsets of the position and rotation of the X, Y, and Z axes, a total of 6 sets of configurations. Each set of configurations may include four parameters: amplitude, frequency, initial offset, and wave function type. Among them, the wave function can be selected from two types: sine function and Perlin noise function. The offsets of the position and rotation of the X, Y, and Z axes per frame (assumed to be denoted as Offset) can all be from the following formula:

[0079] Offset = A * f(tp + frametime * F)

[0080] where A is the amplitude, f(x) is the wave function, the initial value of tp is the initial offset, and subsequently, after calculating Offset for each frame, it is given by the formula tp = tp + frametime * F. frametime is the frame time, and F is the frequency.

[0081] It should be noted that the position offset of the first virtual camera on the X-axis and the position offset on the Y-axis can be different. For example, when calculating the position offset of the first virtual camera on the X-axis, the value of the amplitude A can be 100, and when calculating the position offset of the first virtual camera on the Y-axis, the value of the amplitude A can be 80. That is to say, although the position and rotation offsets of the first virtual camera on the X, Y, and Z axes are all calculated by the above formula, the position and rotation offsets on different axes can be different, and the embodiments of the present application do not make specific limitations on this.

[0082] In some other embodiments, following the above example, during the jitter fade-in time, the value of the position and rotation offset of the first virtual camera in the local coordinate system can be controlled to gradually increase (for example, linearly increase or non-linearly increase) from 0 to a set offset threshold (or called the expected value). That is to say, during the jitter fade-in time, the intensity of the jitter of the first virtual camera can be increasing, that is, the jitter of the first virtual camera becomes more and more obvious; during the time obtained by subtracting the sum of the jitter fade-in time and the jitter fade-out time from the jitter duration, the value of the position and rotation offset of the first virtual camera in the local coordinate system can be controlled to remain at the offset threshold. That is to say, during the time of t-(t_in + t_out), the intensity of the jitter of the first virtual camera can be fixed; during the jitter fade-out time, the value of the position and rotation offset of the first virtual camera in the local coordinate system can be controlled to gradually decrease (for example, linearly decrease or non-linearly decrease) from the offset threshold to 0. That is to say, during the jitter fade-out time, the intensity of the jitter of the first virtual camera can be decreasing, that is, the jitter of the first virtual camera becomes less and less obvious.

[0083] In some embodiments, after obtaining the characteristic parameters (i.e., the appropriate lens jitter effect) that match the current state of the virtual vehicle, the following processing can also be performed: obtaining a first amplification parameter that matches the speed of the virtual vehicle; randomly obtaining a second amplification parameter from the jitter intensity range; and based on the first amplification parameter and the second amplification parameter, performing an amplification process on the offset in the characteristic parameters.

[0084] Exemplarily, taking a virtual vehicle as an example of the virtual vehicle, after selecting appropriate characteristic parameters according to the current state of the virtual vehicle, the offset in the characteristic parameters can be further amplified, that is, the lens shake effect can be further enhanced. For example, the speed of the virtual vehicle can be obtained first, and then the intensity value matching the speed of the virtual vehicle can be read from the "vehicle speed - intensity value" curve as the first amplification parameter (assumed to be denoted as s1). Here, the curve can be a function with the vehicle speed as the independent variable and the intensity value as the dependent variable configured as needed, such as a piecewise function. The second amplification parameter (assumed to be denoted as s2) can be randomly generated according to the configured shake intensity range. For example, an intensity value can be randomly obtained from the shake intensity range as the second amplification parameter. Finally, the first amplification parameter and the second amplification parameter can be multiplied, and the multiplication result can be multiplied by the offset in the characteristic parameters as the final offset of the first virtual lens, thereby enhancing the intensity of the lens shake effect.

[0085] In some embodiments, referring to Figure 4A , Figure 4A is a schematic flowchart of the control method of the virtual lens provided by the embodiments of the present application. As Figure 4A shown, Figure 3 the step 103 shown can be implemented by Figure 4A the step 1031A and the step 1032A shown, and will be described in conjunction with Figure 4A the steps shown.

[0086] In step 1031A, during the movement of the virtual vehicle, in response to an acceleration operation on the virtual vehicle, control the virtual vehicle to accelerate.

[0087] In some embodiments, an acceleration control (such as an accelerator button) can also be displayed in the virtual scene. During the movement of the virtual vehicle, the player can control the virtual vehicle to accelerate by clicking the acceleration control. For example, when receiving a click operation of the player on the acceleration control, the virtual vehicle can be controlled to accelerate forward.

[0088] In step 1032A, obtain a first characteristic parameter matching the acceleration state, and control the first virtual lens to shake based on the first characteristic parameter.

[0089] In some embodiments, when it is detected that the virtual vehicle is accelerating (for example, a click operation on the throttle button by the player is received), a first characteristic parameter matching the acceleration state can be obtained based on a pre-created mapping relationship (such as a mapping table), and the first virtual camera can be controlled to jitter based on the first characteristic parameter. For example, when the client detects that the virtual vehicle is accelerating, it can report the acceleration state of the virtual vehicle to the server, so that the server can obtain the first characteristic parameter matching the acceleration state based on the pre-created mapping relationship and return the first characteristic parameter to the client. After receiving the first characteristic parameter returned by the server, the client can control the first virtual camera to jitter based on the first characteristic parameter. For example, within the jitter fade-in time (such as within 2 seconds after the player clicks the throttle button), the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes can be gradually linearly increased from 0 to 10, that is, the jitter effect of the first virtual camera within the jitter fade-in time will become more and more obvious; within the time after subtracting the jitter fade-in time and the jitter fade-out time from the jitter duration (such as from the 3rd second to the 5th second after the player clicks the throttle button), the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes can be maintained at 10; within the jitter fade-out time (such as from the 6th second to the 7th second after the player clicks the throttle button), the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes can be gradually linearly decreased from 10 to 0, that is, the jitter effect of the first virtual camera within the jitter fade-out time will become less and less obvious, so as to simulate the driving experience that the player feels and perceives when accelerating in the real world.

[0090] It should be noted that for the acceleration state, when the acceleration of the virtual vehicle is different, the corresponding first characteristic parameters can also be different. For example, the jitter time parameter and the jitter intensity parameter can be different. That is to say, the characteristic parameters can be further subdivided according to the acceleration of the virtual vehicle, and the embodiments of the present application do not make specific limitations on this. In addition, it should also be noted that for the acceleration state, the offsets of the position and rotation of the first virtual camera on the X-axis (for example, the negative direction of the X-axis, corresponding to the opposite direction of the virtual vehicle's travel) can be greater than the offsets of the position and rotation on the Y-axis and the Z-axis, so as to further simulate the inertial experience brought by the sudden acceleration of the vehicle in the real world.

[0091] In other embodiments, refer to Figure 4B , Figure 4B is a schematic flowchart of the method for controlling a virtual camera provided by an embodiment of the present application. As Figure 4B shown, Figure 3 the step 103 shown can be implemented by Figure 4B the step 1031B and the step 1032B shown, and will be described in combination with Figure 4B the steps shown.

[0092] In step 1031B, during the movement of the virtual vehicle, in response to a deceleration operation on the virtual vehicle, control the virtual vehicle to decelerate.

[0093] In some embodiments, a braking control (such as a brake button or a handbrake button) may also be displayed in the virtual scene. During the movement of the virtual vehicle, the player can control the virtual vehicle to decelerate by clicking the braking control. For example, when receiving a click operation of the player on the braking control, the virtual vehicle can be controlled to decelerate.

[0094] In step 1032B, obtain a second characteristic parameter matching the deceleration state, and control the first virtual camera to shake based on the second characteristic parameter.

[0095] In some embodiments, when it is detected that the virtual vehicle is decelerating (such as receiving a click operation of the player on the brake button), a second characteristic parameter matching the deceleration state can be obtained based on a pre-created mapping relationship, and the first virtual camera can be controlled to shake based on the obtained second characteristic parameter. For example, when the client detects that the virtual vehicle is decelerating, it can report the deceleration state of the virtual vehicle to the server, so that the server can obtain a second characteristic parameter matching the deceleration state based on the pre-created mapping relationship and return the obtained second characteristic parameter to the client. After receiving the second characteristic parameter returned by the server, the client can control the first virtual camera to shake based on the second characteristic parameter. For example, within the shake fade-in time (such as within 2 seconds after the player clicks the brake button), the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes can be controlled to gradually linearly increase from 0 to 8, that is, the shake effect of the first virtual camera within the shake fade-in time will become more and more obvious; within the time after subtracting the shake fade-in time and the shake fade-out time from the shake duration (such as from the 3rd second to the 5th second after the player clicks the brake button), the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes can be controlled to remain 8; within the shake fade-out time (such as from the 6th second to the 7th second after the player clicks the brake button), the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes can be controlled to gradually linearly decrease from 8 to 0, that is, the shake effect of the first virtual camera within the shake fade-out time will become less and less obvious, so as to simulate the driving experience that the player feels and perceives when braking in the real world.

[0096] It should be noted that for the deceleration state, when different braking methods are adopted, the corresponding second characteristic parameter can also be different. For example, when the player clicks the handbrake button and the brake button respectively, the characteristic parameter of the first virtual camera shake can be different. For example, since the braking force provided by the handbrake button is greater, the first virtual camera can shake more violently. That is to say, compared with the brake button, when the player clicks the handbrake button, the corresponding offset value will be greater. In addition, it should also be noted that for the deceleration state, the offset of the position and rotation of the first virtual camera on the X-axis (for example, the positive direction of the X-axis, corresponding to the driving direction of the virtual vehicle) can be greater than the offset of the position and rotation on the Y-axis and the Z-axis, so as to further simulate the inertial experience brought about by the sudden deceleration of the vehicle in the real world.

[0097] In some embodiments, referring to Figure 4C , Figure 4C is a schematic flowchart of the method for controlling a virtual camera provided by an embodiment of the present application. As Figure 4C shown, Figure 3 the step 103 shown can be implemented by Figure 4C the step 1031C and the step 1032C shown, and will be described in conjunction with Figure 4C the steps shown.

[0098] In step 1031C, during the movement of the virtual vehicle, in response to a collision between the virtual vehicle and an obstacle in the virtual scene, a third characteristic parameter matching the collision state is obtained.

[0099] In some embodiments, during the movement of the virtual vehicle, it is also possible to detect whether the virtual vehicle collides with an obstacle in the virtual scene (such as including other virtual vehicles, virtual walls, and virtual roadblocks, etc.). When it is detected that the virtual vehicle collides with an obstacle in the virtual scene, a third characteristic parameter matching the collision state can be obtained based on a pre-created mapping relationship. For example, when the client detects that the virtual vehicle collides with an obstacle in the virtual scene, it can report the collision state of the virtual vehicle to the server, so that the server obtains a third characteristic parameter matching the collision state based on the pre-created mapping relationship and returns the obtained third characteristic parameter to the client. After receiving the third characteristic parameter returned by the server, the client can control the first virtual camera to shake based on the third characteristic parameter. In this way, the driving experience felt and perceived by the player when a collision occurs in the real world can be simulated.

[0100] It should be noted that for different types of obstacles, the corresponding third characteristic parameter can be different. That is to say, when the virtual vehicle hits different types of obstacles, the degree of jitter of the first virtual camera can be different. For example, the heavier the weight of the obstacle that the virtual vehicle hits, the more intense the jitter of the first virtual camera, that is, the larger the offset corresponding to the first virtual camera. The embodiments of the present application do not make specific limitations on this. In addition, it should also be noted that for the collision state, the jitter intensity of the first virtual camera can also be related to the damage degree of the virtual vehicle. For example, the higher the damage degree of the virtual vehicle, the more intense the jitter of the first virtual camera, so as to simulate the driving experience of the player in the real world when the vehicle is hit to different extents.

[0101] In step 1032C, the first virtual camera is controlled to jitter based on the third characteristic parameter.

[0102] In some embodiments, after obtaining the third characteristic parameter matching the collision state, the client can control the first virtual camera to jitter based on the third characteristic parameter, where different types of obstacles correspond to different third characteristic parameters. For example, the offset included in the third characteristic parameter can be positively correlated with the weight of the obstacle. For example, within the jitter fade-in time (for example, within 2 seconds after the virtual vehicle driven by the player collides), the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes can be controlled to gradually linearly increase from 0 to 20, that is, the jitter effect of the first virtual camera will become more and more obvious within the jitter fade-in time; within the time after subtracting the jitter fade-in time and the jitter fade-out time from the jitter duration (for example, from the 3rd second to the 5th second after the virtual vehicle driven by the player collides), the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes can be controlled to remain 20; within the jitter fade-out time (for example, from the 6th second to the 7th second after the virtual vehicle driven by the player collides), the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes can be controlled to gradually linearly decrease from 20 to 0, that is, the jitter effect of the first virtual camera will become less and less obvious within the jitter fade-out time. In this way, the driving experience felt and perceived by the player when colliding in the real world can be accurately simulated.

[0103] In other embodiments, refer to Figure 4D , Figure 4D is a schematic flowchart of the method for controlling a virtual camera provided by the embodiments of the present application. As Figure 4D shown, Figure 3 the step 103 shown can be implemented by Figure 4D the step 1031D and the step 1032D shown, and will be described in combination with Figure 4D the steps shown.

[0104] In step 1031D, during the movement of the virtual vehicle, in response to a steering operation on the virtual vehicle, control the virtual vehicle to steer.

[0105] In some embodiments, a steering control (such as including a left-turn button and a right-turn button) may also be displayed in the virtual scene. During the movement of the virtual vehicle, the player can control the virtual vehicle to steer by clicking the steering control. For example, when receiving a click operation on the left-turn button by the player, the virtual vehicle can be controlled to turn left.

[0106] In step 1032D, obtain a fourth characteristic parameter matching the steering state, and control the first virtual camera to shake based on the fourth characteristic parameter.

[0107] In some embodiments, when it is detected that the virtual vehicle steers (such as receiving a click operation on the steering control by the player), a fourth characteristic parameter matching the steering state can be obtained based on a pre-created mapping relationship (such as a mapping table), and the first virtual camera can be controlled to shake based on the obtained fourth characteristic parameter. For example, when the client detects that the virtual vehicle steers, it can report the steering state of the virtual vehicle to the server, so that the server can obtain a fourth characteristic parameter matching the steering state based on the pre-created mapping relationship and return the obtained fourth characteristic parameter to the client. After receiving the fourth characteristic parameter returned by the server, the client can control the first virtual camera to shake based on the fourth characteristic parameter. For example, within the shake fade-in time (such as within 2 seconds after the player clicks the direction button), the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes can be gradually linearly increased from 0 to 8, that is, the shaking effect of the first virtual camera will become more and more obvious within the shake fade-in time; within the time after subtracting the shake fade-in time and the shake fade-out time from the shake duration (such as from the 3rd second to the 5th second after the player clicks the direction button), the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes can be maintained at 8; within the shake fade-out time (such as from the 6th second to the 7th second after the player clicks the direction button), the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes can be gradually linearly decreased from 8 to 0, that is, the shaking effect of the first virtual camera will become less and less obvious within the shake fade-out time. In this way, the driving experience that the player feels and perceives when steering in the real world can be simulated.

[0108] It should be noted that for different steering directions, the corresponding fourth characteristic parameter may be different. For example, when the virtual vehicle turns left or right, the jitter situation of the first virtual camera may be different. The embodiments of the present application do not make specific limitations in this regard. In addition, it should also be noted that for the steering state, the offset of the position of the first virtual camera on the Y-axis (for example, assuming the player clicks the left turn button, it may be the positive direction of the Y-axis, corresponding to the right side of the virtual vehicle) and the rotation may be greater than the offsets of the positions and rotations on the X-axis and Z-axis, so as to further simulate the inertial experience generated by the sudden steering of the vehicle in the real world for the player.

[0109] In some other embodiments, the virtual scene may further include at least one second virtual object (such as the game character B controlled by player 2), and at least one second virtual object is located in the virtual vehicle. Then, the following processing may also be performed: in response to the first virtual object driving the virtual vehicle (that is, the first virtual object is the driver), after controlling the first virtual camera to jitter, control the at least one second virtual camera corresponding to the at least one second virtual object to jitter.

[0110] For example, taking the first virtual object as the game character A controlled by player 1 and the at least one second virtual object as the game character B controlled by player 2 as an example, assuming that the game character A drives the virtual vehicle and the game character B rides in the virtual vehicle, that is, the game character A is the driver role and the game character B is the passenger role. Since the timing of the virtual vehicle triggering camera jitter when receiving the player's throttle or brake input and when the virtual vehicle is hit first occurs on the client of the driver player, the virtual camera corresponding to the game character A (that is, the first virtual camera) can be controlled to jitter first, and then the virtual camera corresponding to the game character B (that is, the second virtual camera) can be controlled to jitter. That is to say, it is allowed to first present the camera jitter effect on the client of the driver player, so that the driver player can obtain a better vehicle driving experience.

[0111] It should be noted that the jitter timing of the virtual camera of the virtual object driving the virtual vehicle and the virtual camera of the virtual object sitting in the co-pilot seat may be the same, that is, the vehicle driving experiences of the driver player and the player sitting in the co-pilot seat may be the same. That is to say, after controlling the virtual cameras of the virtual object driving the virtual vehicle and the virtual object sitting in the co-pilot seat to jitter, the virtual camera of the virtual object sitting in the back row can be controlled to jitter. The embodiments of the present application do not make specific limitations in this regard.

[0112] In some embodiments, refer to Figure 4E , Figure 4E is a schematic flowchart of the method for controlling a virtual camera provided by the embodiments of the present application. As Figure 4E shown,Figure 3 The shown step 103 can also be implemented by Figure 4E the shown step 1031E and step 1032E, which will be described in combination with Figure 4E the shown steps.

[0113] In step 1031E, during the movement of the virtual vehicle, in response to the virtual vehicle driving into the target area set in the virtual scene, obtain the physical material of the target area.

[0114] In some embodiments, game planners can also pre-set a target area in the virtual scene. During the movement of the virtual vehicle, it can also be detected whether the virtual vehicle drives into the target area set in the virtual scene. When it is detected that the virtual vehicle drives into the target area set in the virtual scene, the physical material of the target area can be obtained. Among them, the types of physical materials can include asphalt roads, gravel roads, and mud and grass roads, etc.

[0115] In some other embodiments, the above step 1031E can also be implemented in the following manner: in response to the virtual vehicle driving into multiple target areas set in the virtual scene, obtain the physical material of the first target area driven into.

[0116] Exemplarily, taking the virtual vehicle as an example of the virtual vehicle, in the case where the virtual vehicle triggers a camera shake effect when entering certain specific scenes (i.e., target areas) in the game scene, if the tires of the virtual vehicle come into contact with the physical materials of multiple different game scenes, the first one contacted in terms of time shall prevail. For example, assuming that the player is controlling the virtual vehicle to turn left, the left front wheel of the virtual vehicle first contacts target area 1, and then the right front wheel of the virtual vehicle contacts target area 2. Among them, target area 1 and target area 2 can be two adjacent target areas, then target area 1 can be used as the target area driven into by the virtual vehicle. That is to say, the characteristic parameters of the first virtual camera shake can be related to the physical material of the first target area driven into.

[0117] In step 1032E, obtain the fifth characteristic parameter matching the physical material of the target area, and control the first virtual camera to shake based on the fifth characteristic parameter.

[0118] In some embodiments, after obtaining the physical material of the target area, the fifth characteristic parameter matching the physical material of the target area (for example, assumed to be an asphalt road surface) can be obtained based on a pre-created mapping relationship (such as a mapping table between the physical material and the characteristic parameter), and the first virtual camera can be controlled to jitter based on the fifth characteristic parameter (i.e., the characteristic parameter corresponding to the asphalt road surface). For example, after the client detects that the virtual vehicle enters the target area, it can obtain the physical material of the target area and report the obtained physical material to the server, so that the server can obtain the fifth characteristic parameter matching the physical material of the target area based on the pre-created mapping relationship and return the obtained fifth characteristic parameter to the client. After receiving the fifth characteristic parameter returned by the server, the client can control the first virtual camera to jitter based on the fifth characteristic parameter. For example, within the jitter fade-in time (for example, within 2 seconds after the player drives the virtual vehicle onto the asphalt road surface), the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes can be controlled to gradually linearly increase from 0 to 6, that is, the jitter effect of the first virtual camera within the jitter fade-in time will become more and more obvious; within the time after subtracting the jitter fade-in time and the jitter fade-out time from the jitter duration (for example, from the 3rd second to the 5th second after the player drives the virtual vehicle onto the asphalt road surface), the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes can be controlled to remain at 6; within the jitter fade-out time (for example, from the 6th second to the 7th second after the player drives the virtual vehicle onto the asphalt road surface), the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes can be controlled to gradually linearly decrease from 6 to 0, that is, the jitter effect of the first virtual camera within the jitter fade-out time will become less and less obvious. In this way, the driving experience felt and perceived by the player when driving on an asphalt road surface in the real world can be simulated.

[0119] It should be noted that the fifth characteristic parameters corresponding to different physical materials can be different. For example, game planners can pre-configure the corresponding fifth characteristic parameters for each type of physical material to simulate the driving experience felt and perceived by the player when driving on different road surfaces in the real world.

[0120] Exemplarily, refer to Figure 5A , Figure 5A which is a schematic diagram of the application scenario of the virtual camera control method provided by the embodiments of the present application. As Figure 5AAs shown, in the virtual scene 501, a virtual vehicle 502 (such as a virtual car) is displayed. Assume that the player is currently controlling the virtual vehicle 502 to move along the route 503 in the virtual scene 501, and assume that the route 503 passes through the set target area 504 in the virtual scene 501. Then, when it is detected that the virtual vehicle 502 enters the target area 504, the physical material of the target area 504 can be obtained. For example, assume that the target area 504 is an asphalt road surface, then the characteristic parameters corresponding to the asphalt road surface can be obtained based on the pre-created mapping table, and the first virtual camera can be controlled to shake based on the obtained characteristic parameters. For example, within 2 seconds after the virtual vehicle 502 enters the target area 504, the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes are gradually linearly increased from 0 to 8. From the 3rd second to the 5th second after the virtual vehicle 502 enters the target area 504, the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes are maintained at 8. From the 6th second to the 7th second after the virtual vehicle 502 enters the target area 504, the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes are gradually linearly decreased from 8 to 0, so as to simulate the driving experience that the player feels and perceives when driving into an asphalt road surface in the real world.

[0121] In some embodiments, referring to Figure 4F , Figure 4F is a schematic flowchart of a method for controlling a virtual camera provided by an embodiment of the present application. As Figure 4F shown, Figure 3 the step 103 shown can be implemented through Figure 4F the steps 1031F to 1034F shown, and will be described in combination with Figure 4F the steps shown.

[0122] In step 1031F, during the movement of the virtual vehicle, the interval duration from the moment of the last shake of the first virtual camera to the current moment is detected.

[0123] In some embodiments, the lens shake effect can also be randomly triggered during the movement of the virtual vehicle. And in order to avoid the lens shake effect from being frequently triggered and causing a decline in the player experience, a cooling time can also be set. Therefore, during the movement of the virtual vehicle, the interval duration from the moment of the last shake of the first virtual camera to the current moment can also be detected in real time to determine whether the lens shake effect is in a cooling state.

[0124] In step 1032F, in response to the interval duration being greater than or equal to the interval duration threshold, at least one physical material contacted by the virtual vehicle during movement is obtained.

[0125] In some embodiments, taking a virtual vehicle as an example of a virtual carrier, when it is detected that the interval duration is greater than or equal to the interval duration threshold (e.g., 30 seconds), that is, when the lens jitter effect can be played currently, the client can obtain the physical materials contacted by each tire of the virtual vehicle during the movement.

[0126] In step 1033F, in response to the list of physical materials with priorities including at least one physical material, obtain the sixth characteristic parameter matching the target physical material, and control the first virtual lens to jitter based on the sixth characteristic parameter.

[0127] Here, the target physical material is the physical material with the highest priority among at least one physical material.

[0128] In some embodiments, following the above example, a list of physical materials with priorities as shown in Table 2 can be created in advance, and then it is determined whether the physical materials contacted by each tire of the virtual vehicle are in the list of physical materials with priorities. When all the physical materials contacted by each tire of the virtual vehicle are in the list of physical materials with priorities, the sixth characteristic parameter corresponding to the physical material with the highest priority can be selected according to the priorities of the physical materials in the list of physical materials with priorities. For example, assume that the physical material contacted by the front wheel of the virtual vehicle is asphalt, and the physical material contacted by the rear wheel of the virtual vehicle is gravel, and both asphalt and gravel are in the list of physical materials with priorities. Then, the priorities of asphalt and gravel can be further compared. Assume that the priority of asphalt is greater than that of gravel. Then, the sixth characteristic parameter matching asphalt can be obtained. Subsequently, the first virtual lens can be controlled to jitter based on the obtained sixth characteristic parameter. For example, within the jitter fade-in time (e.g., within 2 seconds after the front wheel of the virtual vehicle contacts the asphalt road surface), the offset of the position and rotation of the first virtual lens on the X, Y, and Z axes can be gradually linearly increased from 0 to 8, that is, the jitter effect of the first virtual lens will become more and more obvious within the jitter fade-in time; within the time after subtracting the jitter fade-in time and the jitter fade-out time from the jitter duration (e.g., from the 3rd second to the 4th second after the front wheel of the virtual vehicle contacts the asphalt road surface), the offset of the position and rotation of the first virtual lens on the X, Y, and Z axes can be maintained at 8; within the jitter fade-out time (e.g., from the 5th second to the 6th second after the front wheel of the virtual vehicle contacts the asphalt road surface), the offset of the position and rotation of the first virtual lens on the X, Y, and Z axes can be gradually linearly decreased from 8 to 0, that is, the jitter effect of the first virtual lens will become less and less obvious within the jitter fade-out time, so as to simulate the driving experience felt and recognized by the player when driving on the asphalt road surface in the real world.

[0129] Table 2 List of Physical Materials with Priorities

[0130]

[0131]

[0132] In step 1034F, in response to the prioritized physical material list not including at least one physical material, obtain the default seventh characteristic parameter, and control the first virtual camera to jitter based on the seventh characteristic parameter.

[0133] In some embodiments, following the above example, when the physical materials separately contacted by the respective tires of the virtual vehicle are not in the prioritized physical material list, the default seventh characteristic parameter can be obtained, and the first virtual camera can be controlled to jitter based on the seventh characteristic parameter. That is to say, when the respective physical materials separately contacted by the respective tires of the virtual vehicle are not in the prioritized physical material list, the default camera jitter effect can be selected.

[0134] Exemplarily, refer to Figure 5B , Figure 5B is a schematic diagram of an application scenario of the method for controlling a virtual camera provided by an embodiment of the present application. As Figure 5BAs shown, in the virtual scene 501, a virtual vehicle 502 (such as a virtual car) in a moving state is displayed. During the movement of the virtual vehicle 502, the time interval between the moment of the last jitter of the first virtual camera and the current moment can be detected in real time. When the detected time interval between the moment of the last jitter of the first virtual camera and the current moment is greater than or equal to the interval duration threshold (such as 30 seconds), the physical materials respectively contacted by each tire of the virtual vehicle 502 during movement can be obtained. For example, assuming that the front wheel 505 of the virtual vehicle 502 contacts a muddy grass road surface and the rear wheel 506 of the virtual vehicle 503 contacts a gravel road surface, it can be first determined whether the muddy grass road surface and the gravel road surface are in the physical material list with priorities. When both the muddy grass road surface and the gravel road surface are in the physical material list with priorities, the priorities of the muddy grass road surface and the gravel road surface can be further compared. When the priority of the gravel road surface is higher than that of the muddy grass road surface, the characteristic parameters corresponding to the gravel road surface can be obtained, and the first virtual camera can be controlled to jitter based on the characteristic parameters corresponding to the gravel road surface. For example, within the jitter fade-in time (such as within 3 seconds after the front wheel of the virtual vehicle contacts the muddy grass road surface), the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes can be controlled to gradually linearly increase from 0 to 15, that is, the jitter effect of the first virtual camera within the jitter fade-in time will become more and more obvious; within the jitter fade-out time (such as from the 4th second to the 5th second after the front wheel of the virtual vehicle contacts the muddy grass road surface), the offsets of the position and rotation of the first virtual camera on the X, Y, and Z axes can be controlled to gradually linearly decrease from 15 to 0, that is, the jitter effect of the first virtual camera within the jitter fade-out time will become less and less obvious, so as to simulate the driving experience felt and recognized by the player when driving from a gravel road surface into a muddy grass road surface in the real world.

[0135] That is to say, in the technical solution provided by the embodiments of the present application, the characteristic parameters of the jitter of the first virtual camera can be related to the physical materials contacted by the virtual vehicle. For example, taking the virtual vehicle as an example, when the physical materials of the road surfaces contacted by the tires of the virtual vehicle are different, the characteristic parameters of the jitter of the first virtual camera are different, so as to accurately simulate the driving experience felt and recognized by the player when driving on different road surfaces in the real world.

[0136] In some other embodiments, after controlling the first virtual camera to jitter, the following processing can also be performed: broadcasting a camera jitter event; in response to the camera jitter event being recognized by the audio system of the virtual vehicle, playing the sound of the virtual vehicle.

[0137] Exemplarily, taking a virtual vehicle as an example, after controlling the first virtual camera to jitter, a camera jitter event can also be broadcast to notify other modules in the virtual scene that are concerned about the camera jitter effect to make corresponding synchronous feedback. For example, when the broadcast camera jitter event is recognized by the audio system of the virtual vehicle, it can be used to synchronize the playback of the virtual vehicle's sound. For example, the virtual vehicle's horn can be controlled to sound.

[0138] The method for controlling a virtual camera provided by the embodiments of the present application, during the movement of a virtual vehicle, obtains characteristic parameters matching the current state of the virtual vehicle, and controls the virtual camera corresponding to the perspective of the virtual object to jitter based on the characteristic parameters, thereby simulating the driving experience that a player feels and perceives in the real world, so as to solve the problem that the player's experience is poor due to the overly smooth movement of the virtual vehicle.

[0139] Next, an exemplary application of the embodiments of the present application in an actual application scenario will be described.

[0140] Currently, in the vehicle driving experience system of multiplayer games, the position and rotation of the driver and passenger role cameras, after removing the rotation values actively input by the player, only depend on the position and rotation of the vehicle itself being ridden, and the position and rotation of the vehicle itself being ridden by the player role only depend on the calculation of the interaction between the virtual vehicle and the game scene by the game physics engine. However, due to the compromise of multiplayer games on the computing power, network bandwidth, and other limiting conditions of the operating device (such as the above-mentioned terminal device 400), the game scene mainly focuses on visual performance. When many visually rough game scenes participate in the calculation of the interaction between the virtual vehicle and the game scene by the game physics engine, they are actually regarded as flat surfaces by the game physics engine, which will result in the overly smooth movement of the virtual vehicle and a large discrepancy from the visual performance of the game scene, making the vehicle driving experience in multiplayer games quite different from what the player feels and perceives in the real world, resulting in a poor experience for the player.

[0141] In view of this, the embodiments of the present application provide a method for controlling a virtual camera, mainly by adding a camera jitter effect to the driver and passenger role cameras of the vehicle in a multiplayer game according to certain configuration rules under specific circumstances, so that the performance of the driver and passenger role cameras when the player role is on the virtual vehicle is more in line with the visual performance of the game scene, thereby simulating the driving experience that the player feels and perceives in the real world, so as to solve the problem that the player's experience is poor due to the overly smooth movement of the virtual vehicle.

[0142] That is to say, the embodiments of the present application provide a solution for enhancing the driving and riding experience of a multi-player game vehicle based on lens shake effects. This solution does not require adding details to the game scene model. By adding lens shake effects suitable for different situations to the driver and passenger roles' lenses of the virtual vehicle in the multi-player game, it is possible to simulate the driving and riding experience that players feel and recognize in the real world. The technical solutions provided by the embodiments of the present application mainly include the following processes: configuring a set of lens shake effect configurations, selecting a suitable set of lens shake effect configurations according to the current state of the virtual vehicle, determining the final parameters of the lens shake effect, and triggering the playback of the lens shake effect on all driver and passenger clients.

[0143] The following specifically describes the control method for the virtual lens provided by the embodiments of the present application.

[0144] When a player is driving and riding a virtual vehicle in a multi-player game, when the virtual vehicle is moving in the game scene, if the technical solution provided by the embodiments of the present application is not used, even if the game scene visually appears to be a mountain or an uneven paved road surface, the driver and passenger roles' lenses of the virtual vehicle (i.e., the virtual lenses corresponding to the driver and passenger roles, such as the first virtual lens mentioned above) will only smoothly move or rotate following the virtual vehicle itself; after using the technical solution provided by the embodiments of the present application, the driver and passenger roles' lenses of the virtual vehicle will play corresponding lens shake effects according to the physical material of the game environment where the virtual vehicle is located, in combination with configuration items such as time and speed.

[0145] Exemplarily, refer to Figure 6 , Figure 6 which is a schematic diagram of the application scenario of the control method for the virtual lens provided by the embodiments of the present application. As Figure 6 shown, it is possible to display a virtual scene 600 corresponding to the first-person perspective of the first virtual object 601 (such as the game character A controlled by player 1) with a first virtual lens (the first virtual lens can be set at the position where the eyes of the first virtual object 601 are located). Among them, the virtual scene 600 can include a virtual vehicle 602 (such as a virtual car), and the first virtual object 601 is located in the virtual vehicle 602. For example, it is possible to display a picture of the first virtual object 601 driving the virtual vehicle 602 in the virtual scene 600. During the process of the player controlling the first virtual object 601 to drive the virtual vehicle 602, that is, during the process of the virtual vehicle 602 moving in the virtual scene 600, it is possible to control the first virtual lens corresponding to the first virtual object 601 to shake, so as to simulate the driving and riding experience that players feel and recognize when driving in the real world.

[0146] In addition, when a player drives a virtual vehicle in a multiplayer game, due to the compromise of multiplayer games on restricted conditions such as the computing power of the operating device, network bandwidth, project duration, or budget, without adding more model details to the game scene, the technical solution provided in the embodiments of the present application can solve the problem that the movement of the virtual vehicle is too smooth, making the vehicle driving experience in the multiplayer game closer to what the player feels and perceives in the real world, thereby enhancing the player's experience. At the same time, it can also make the game performance more realistic and natural, and more help the player intuitively understand the specific state of the virtual vehicle they are driving in the multiplayer game from the game screen.

[0147] Next, continue to describe Figure 7 the virtual camera control method provided in the embodiments of the present application.

[0148] Exemplarily, refer to Figure 7 , Figure 7 which is a schematic flowchart of the virtual camera control method provided in the embodiments of the present application, and will be described in combination with Figure 7 the steps shown.

[0149] In step 201, it is judged whether the camera shake effect can be played. If so, step 202 is executed; if not, step 207 is executed.

[0150] In some embodiments, the camera shake effect can be a function of continuously performing position and rotation transformation in the local coordinates of the driver and passenger role camera at regular intervals according to certain rules, that is, the camera shake effect can be randomly triggered during the movement of the virtual vehicle. For example, in the technical solution provided in the embodiments of the present application, a timer with a specific time interval can be enabled in the vehicle object to trigger the camera shake effect through this timer, and the specific time interval set by this timer can be obtained through the following step 206.

[0151] In other embodiments, the camera shake effect can also be triggered by specific external events. For example, in the technical solution provided in the embodiments of the present application, the camera shake effect can be triggered by vehicle injury events, throttle events, and brake events, etc.

[0152] Exemplarily, the configuration of the lens shake effect can consist of two parts: the shake time parameter and the specific shake parameter. Among them, the shake time parameter includes the shake duration (assumed to be denoted as t), the shake fade-in time (assumed to be denoted as t_in), and the shake fade-out time (assumed to be denoted as t_out), and it satisfies t ≥ t_in + t_out. Within the t_in time, the offset of the position and rotation of the lens shake effect on the driver and passenger role lens in the local coordinate system will gradually increase linearly from 0 to the expected value (such as a pre-set offset value threshold). Within the t - (t_in + t_out) time, the offset of the position and rotation of the lens shake effect on the driver and passenger role lens in the local coordinate system remains at the expected value. Within the t_out time, the offset of the position and rotation of the lens shake effect on the driver and passenger role lens in the local coordinate system will gradually decrease from the expected value to 0.

[0153] In addition, the configuration of the above-mentioned specific shake parameter can include the offsets of the position and rotation of the X, Y, and Z axes (assumed to be denoted as Offset), a total of 6 groups of configurations. Each group of configurations includes four parameters: amplitude, frequency, initial offset, and wave function type. Among them, the wave function can be selected from two types: sine function and Perlin noise function. And the offsets of the position and rotation of the X, Y, and Z axes for each frame can all come from the formula

[0154] Offset = A * f(tp + frametime * F)

[0155] where A is the amplitude, f(x) is the wave function, the initial value of tp is the initial offset, and subsequently, after calculating Offset for each frame, it is given by the formula tp = tp + frametime * F. frametime is the frame time, and F is the frequency.

[0156] Exemplarily, at the beginning of the process, it will be judged whether the lens shake effect can be played according to the current state of the virtual vehicle. For example, in the technical solution provided in the embodiments of the present application, if the virtual vehicle is not started or the time since the last play of the lens shake effect is too short, this process will end prematurely.

[0157] In step 202, the required lens shake effect is selected.

[0158] In some embodiments, after the above judgment, appropriate lens shake effects are first selected according to the trigger type and the physical material of the game scene where the virtual vehicle is currently located. In the technical solution provided by the embodiments of the present application, the trigger timing can be divided into four types, namely: randomly triggered during the movement of the virtual vehicle, triggered when the virtual vehicle enters the physical material of certain specific game scenes, triggered when the virtual vehicle receives the player's throttle or brake input, and triggered when the virtual vehicle is hit. The above four trigger timings are independent of each other, can be triggered simultaneously, and the effects can be superimposed when triggered simultaneously. Among them, the lens shake effects selected when the virtual vehicle is randomly triggered during movement and when the virtual vehicle enters the physical material of certain specific game scenes depend on the physical material of the game scene contacted by the tires of the virtual vehicle. For example, for the case of being randomly triggered during the movement of the virtual vehicle, the lens shake effects corresponding to the priority key physical material list and the default lens shake effect can be configured. During the movement of the virtual vehicle, the physical materials contacted by each tire of the virtual vehicle can be read, and according to the priority of each physical material in the priority key physical material list, the lens shake effect corresponding to the physical material with the highest priority is selected. If none of the physical materials are in the priority key physical material list, the default lens shake effect is selected. In addition, for the case of being triggered when the virtual vehicle enters the physical material of certain specific game scenes, if each tire of the virtual vehicle contacts multiple different physical materials of the game scene, the first one contacted in time shall prevail. Among them, common physical materials can include asphalt roads, gravel roads, and mud and grass roads, etc. Each physical material will be configured with a corresponding lens shake effect according to the actual driving experience in the real world. The lens shake effects selected for the cases of being triggered when the virtual vehicle receives the player's throttle or brake input and when the virtual vehicle is hit can be uniquely specified.

[0159] In step 203, generate the intensity of the lens shake effect.

[0160] In some embodiments, after selecting the appropriate lens shake effect, an intensity value of the lens shake effect needs to be generated. For example, in the technical solution provided by the embodiments of the present application, the final shake intensity s = s1 * s2, where s1 can be read according to the "vehicle speed - intensity value" curve, which is a function with the vehicle speed as the independent variable and the intensity value as the dependent variable configured as needed. For example, it can be a piecewise function, and s2 can be generated according to the configured random range of the shake intensity. Both the "vehicle speed - intensity value" curve and the random range of the shake intensity can be configured values.

[0161] In step 204, notify the driver and passenger client to play the lens shake effect.

[0162] In some embodiments, after selecting a suitable lens jitter effect and generating a lens jitter effect intensity value, the clients of each passenger and driver on the virtual vehicle can be notified to play the lens jitter effect. For example, in the technical solution provided by the embodiments of the present application, the lens jitter effects of the passengers and drivers can be synchronized by the game server to maintain consistency. However, since the two triggering opportunities, namely when the virtual vehicle receives the player's throttle or brake input and when the virtual vehicle is hit, first occur on the client of the driver player, it is allowed to perform the display first on the client of the driver player so that the driver player can obtain a better multiplayer vehicle driving experience.

[0163] In step 205, broadcast the lens jitter event.

[0164] In some embodiments, after notifying the clients of each passenger and driver on the virtual vehicle to play the lens jitter effect, a lens jitter event can be broadcast to notify other modules that are concerned about the lens jitter effect to make corresponding synchronization feedback. For example, when the broadcast event is recognized by the audio system of the virtual vehicle, it can be used to synchronize the playback of the virtual vehicle sound.

[0165] In step 206, generate the interval time for the next lens jitter effect.

[0166] In some embodiments, the time required for the next trigger of the lens jitter effect can be generated to prevent the lens jitter effect from being triggered too frequently, resulting in a decline in the player experience. For example, in the technical solution provided by the embodiments of the present application, time limits can be imposed only on the triggering opportunity of randomly triggering during the movement of the virtual vehicle. The time interval for each random trigger during the movement of the virtual vehicle is t = t1 + t2, where t1 is a random value of the trigger interval and t2 is a random value of the trigger delay, and both the random value of the trigger interval and the random value of the trigger delay mentioned are configuration values.

[0167] In step 207, end the process.

[0168] In some embodiments, in addition to the above solutions, the embodiments of the present application can also, at specific times during the driving of the virtual vehicle, adopt the method of animating the position and rotation transformation of the lens of the passengers and drivers on the virtual vehicle to simulate the change in the observed picture of the player when the virtual vehicle's attitude changes due to factors such as terrain bumps, throttle braking effects, and attack impact damage. The embodiments of the present application do not make specific limitations on this.

[0169] In summary, the technical solutions provided by the embodiments of the present application have the following beneficial effects:

[0170] In the existing vehicle driving experience system for multiplayer games, the movement of virtual vehicles is too smooth and there is a large discrepancy with the visual performance of the game scene, resulting in a significant gap between the vehicle driving experience in multiplayer games and what players feel and perceive in the real world, leading to a poor player experience. The technical solution provided by the embodiments of this application adds a lens jitter effect applicable to different situations to the driver and passenger role cameras of virtual vehicles in multiplayer games to simulate the driving experience that players feel and perceive in the real world. The technical solution provided by the embodiments of this application can make the vehicle driving experience in multiplayer games closer to what players feel and perceive in the real world, thereby enhancing the player experience. At the same time, it also makes the game performance more real and natural, and is more conducive to players intuitively understanding the specific state of the virtual vehicle they are driving in the multiplayer game from the game screen.

[0171] The following continues to describe the exemplary structure of the control device 555 for the virtual lens provided by the embodiments of this application as a software module. In some embodiments, as Figure 2 shown, the software module stored in the control device 555 for the virtual lens in the memory 550 may include: a display module 5551 and a control module 5552.

[0172] The display module 5551 is configured to display a virtual scene based on a first virtual lens corresponding to the perspective of a first virtual object, where the virtual scene includes a virtual vehicle and the first virtual object is located in the virtual vehicle; the control module 5552 is configured to control the movement of the virtual vehicle in response to a trigger operation on the virtual vehicle, and is configured to control the first virtual lens to jitter during the movement of the virtual vehicle, where the characteristic parameters of the jitter of the first virtual lens match the current state of the virtual vehicle.

[0173] In some embodiments, the control module 5552 is further configured to control the virtual vehicle to accelerate in response to an acceleration operation on the virtual vehicle; the control device 555 for the virtual lens further includes an acquisition module 5553 configured to acquire a first characteristic parameter matching the acceleration state; the control module 5552 is further configured to control the first virtual lens to jitter based on the first characteristic parameter.

[0174] In some embodiments, the control module 5552 is further configured to control the virtual vehicle to decelerate in response to a deceleration operation on the virtual vehicle; the acquisition module 5553 is further configured to acquire a second characteristic parameter matching the deceleration state; the control module 5552 is further configured to control the first virtual lens to jitter based on the second characteristic parameter.

[0175] In some embodiments, the acquisition module 5553 is further configured to obtain a third characteristic parameter matching the collision state in response to a collision between the virtual vehicle and an obstacle in the virtual scene; the control module 5552 is further configured to control the first virtual camera to shake based on the third characteristic parameter.

[0176] In some embodiments, the control module 5552 is further configured to control the virtual vehicle to turn in response to a steering operation on the virtual vehicle; the acquisition module 5553 is further configured to obtain a fourth characteristic parameter matching the steering state; the control module 5552 is further configured to control the first virtual camera to shake based on the fourth characteristic parameter.

[0177] In some embodiments, the virtual scene further includes at least one second virtual object, and at least one second virtual object is located in the virtual vehicle; the control module 5552 is further configured to, in response to the first virtual object driving the virtual vehicle, after controlling the first virtual camera to shake, control at least one second virtual camera corresponding to at least one second virtual object to shake.

[0178] In some embodiments, the acquisition module 5553 is further configured to obtain the physical material of the target area set in the virtual scene in response to the virtual vehicle driving into the target area; and to obtain a fifth characteristic parameter matching the physical material of the target area; the control module 5552 is further configured to control the first virtual camera to shake based on the fifth characteristic parameter.

[0179] In some embodiments, the acquisition module 5553 is further configured to obtain the physical material of the first target area entered in response to the virtual vehicle driving into a plurality of target areas set in the virtual scene.

[0180] In some embodiments, the control device 555 of the virtual camera further includes a detection module 5554 for detecting the time interval between the moment of the last shake of the first virtual camera and the current moment; the control module 5552 is further configured to control the first virtual camera to shake in response to the time interval being greater than or equal to the time interval threshold.

[0181] In some embodiments, the acquisition module 5553 is further configured to obtain at least one physical material contacted by the virtual vehicle during movement; and to obtain a sixth characteristic parameter matching the target physical material in response to the prioritized physical material list including at least one physical material, where the target physical material is the physical material with the highest priority among at least one physical material; the acquisition module 5553 is further configured to obtain a default seventh characteristic parameter in response to the prioritized physical material list not including at least one physical material; the control module 5552 is further configured to control the first virtual camera to shake based on the seventh characteristic parameter.

[0182] In some embodiments, the control device 555 of the virtual lens further includes a broadcast module 5555 and a playback module 5556. Among them, the broadcast module 5555 is configured to broadcast a lens jitter event after the control module 5552 controls the first virtual lens to jitter; the playback module 5556 is configured to play the sound of the virtual vehicle in response to the lens jitter event being recognized by the audio system of the virtual vehicle.

[0183] In some embodiments, the characteristic parameter includes a jitter time parameter, and the jitter time parameter includes a jitter duration, a jitter fade-in time, and a jitter fade-out time. Among them, the jitter duration is greater than or equal to the sum of the jitter fade-in time and the jitter fade-out time.

[0184] In some embodiments, the characteristic parameter further includes a jitter intensity parameter, and the jitter intensity parameter includes the offset of the position and rotation of the first virtual lens in the local coordinate system, where the local coordinate system is a coordinate system with the first virtual lens as the coordinate origin.

[0185] In some embodiments, the control module 5552 is further configured to perform the following processing: within the jitter fade-in time, control the value of the offset to gradually increase from 0 to a set offset threshold; within the time obtained by subtracting the sum of the jitter fade-in time and the jitter fade-out time from the jitter duration, control the value of the offset to remain at the offset threshold; within the jitter fade-out time, control the value of the offset to gradually decrease from the offset threshold to 0.

[0186] In some embodiments, the acquisition module 5553 is further configured to acquire a first amplification parameter that matches the speed of the virtual vehicle; and to randomly acquire a second amplification parameter from the jitter intensity range; the control device 555 of the virtual lens further includes an amplification module 5557, which is configured to perform an amplification process on the offset based on the first amplification parameter and the second amplification parameter.

[0187] It should be noted that the description of the device in the embodiments of the present application is similar to the description of the above method embodiments and has similar beneficial effects as the method embodiments, so details will not be repeated. For the technical details not covered in the control device of the virtual lens provided in the embodiments of the present application, they can be understood according to Figure 3 、or Figures 4A to 4F the description of any one of the drawings.

[0188] An embodiment of the present application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer-executable instructions from the computer-readable storage medium, and the processor executes the computer-executable instructions, so that the computer device executes the control method of the virtual lens in the above embodiments of the present application.

[0189] An embodiment of the present application provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are stored, and when the computer-executable instructions are executed by a processor, the processor will be caused to execute the control method of the virtual lens provided by the embodiment of the present application. For example, Figure 3 or Figures 4A to 4F the control method of the virtual lens shown in any of the accompanying drawings.

[0190] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disc, or CD-ROM; or may be various devices including one or any combination of the above memories.

[0191] In some embodiments, the executable instructions may be in the form of a program, software, software module, script, or code, and may be written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including being deployed as an independent program or being deployed as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0192] As an example, the executable instructions may be deployed to be executed on an electronic device, or on multiple electronic devices located at one location, or alternatively, on multiple electronic devices distributed at multiple locations and interconnected by a communication network.

[0193] As described above, the above are only embodiments of the present application and are not used to limit the protection scope of the present application. Any modifications, equivalent replacements, and improvements made within the spirit and scope of the present application are all included in the protection scope of the present application.

Claims

1. A method for controlling a virtual lens, characterized in that, The method includes: Displaying a virtual scene based on a first virtual camera corresponding to the perspective of a first virtual object, where the virtual scene includes a virtual vehicle, and the first virtual object is located in the virtual vehicle; In response to a trigger operation on the virtual vehicle, controlling the virtual vehicle to move, and During the movement of the virtual vehicle, controlling the first virtual camera to shake, where the characteristic parameters of the shaking of the first virtual camera match the current state of the virtual vehicle.

2. The method according to claim 1, characterized in that, The controlling the first virtual camera to shake includes: In response to an acceleration operation on the virtual vehicle, controlling the virtual vehicle to accelerate; Obtaining a first characteristic parameter matching the acceleration state, and controlling the first virtual camera to shake based on the first characteristic parameter.

3. The method according to claim 1, characterized in that, The controlling the first virtual camera to shake includes: In response to a deceleration operation on the virtual vehicle, controlling the virtual vehicle to decelerate; Obtaining a second characteristic parameter matching the deceleration state, and controlling the first virtual camera to shake based on the second characteristic parameter.

4. The method according to claim 1, characterized in that, The controlling the first virtual camera to shake includes: In response to a collision between the virtual vehicle and an obstacle in the virtual scene, obtaining a third characteristic parameter matching the collision state, and controlling the first virtual camera to shake based on the third characteristic parameter.

5. The method according to claim 1, characterized in that, The controlling the first virtual camera to shake includes: In response to a steering operation on the virtual vehicle, controlling the virtual vehicle to steer; Obtaining a fourth characteristic parameter matching the steering state, and controlling the first virtual camera to shake based on the fourth characteristic parameter.

6. The method according to any one of claims 2 to 5, characterized in that, The virtual scene further includes at least one second virtual object, and the at least one second virtual object is located in the virtual vehicle; The method further includes: In response to the first virtual object driving the virtual vehicle, after controlling the first virtual camera to shake, controlling at least one second virtual camera corresponding to the at least one second virtual object to shake.

7. The method according to claim 1, characterized in that, The controlling the first virtual camera to shake includes: In response to the virtual vehicle driving into a target area set in the virtual scene, obtaining the physical material of the target area; Obtaining a fifth characteristic parameter matching the physical material of the target area, and controlling the first virtual camera to shake based on the fifth characteristic parameter.

8. The method according to claim 7, characterized in that, The in response to the virtual vehicle driving into a target area set in the virtual scene, obtaining the physical material of the target area includes: In response to the virtual vehicle driving into a plurality of target areas set in the virtual scene, obtaining the physical material of the first target area driven into.

9. The method according to claim 1, characterized in that, The controlling the first virtual camera to shake includes: Detecting the interval duration from the moment of the last shake of the first virtual camera to the current moment; In response to the interval duration being greater than or equal to an interval duration threshold, controlling the first virtual camera to shake.

10. The method according to claim 9, characterized in that, The controlling the first virtual camera to shake includes: Obtaining at least one physical material contacted by the virtual vehicle during movement; In response to the list of physical materials with priorities including the at least one physical material, obtain a sixth characteristic parameter matching the target physical material, and control the first virtual lens to jitter based on the sixth characteristic parameter, where the target physical material is the physical material with the highest priority among the at least one physical material; In response to the list of physical materials with priorities not including the at least one physical material, obtain a default seventh characteristic parameter, and control the first virtual lens to jitter based on the seventh characteristic parameter.

11. The method according to claim 1, characterized in that, After controlling the first virtual lens to jitter, the method further includes: Broadcasting a lens jitter event; In response to the lens jitter event being recognized by the audio system of the virtual vehicle, playing the sound of the virtual vehicle.

12. The method according to any one of claims 1 to 11, characterized in that, The characteristic parameter includes a jitter time parameter, and the jitter time parameter includes a jitter duration, a jitter fade-in time, and a jitter fade-out time, where the jitter duration is greater than or equal to the sum of the jitter fade-in time and the jitter fade-out time.

13. The method according to claim 12, characterized in that, The characteristic parameter further includes a jitter intensity parameter, and the jitter intensity parameter includes the offset of the position and rotation of the first virtual lens in the local coordinate system, where the local coordinate system is a coordinate system with the first virtual lens as the coordinate origin.

14. The method according to claim 13, characterized in that, The method further includes: During the jitter fade-in time, control the value of the offset to gradually increase from 0 to a set offset threshold; During the time obtained by subtracting the sum of the jitter fade-in time and the jitter fade-out time from the jitter duration, control the value of the offset to remain at the offset threshold; During the jitter fade-out time, control the value of the offset to gradually decrease from the offset threshold to 0.

15. The method according to claim 13, characterized in that, The method further includes: Obtain a first amplification parameter matching the speed of the virtual vehicle; Randomly obtain a second amplification parameter from the jitter intensity range; Based on the first amplification parameter and the second amplification parameter, perform an amplification process on the offset.

16. A control device for a virtual lens, characterized in that, The device includes: A display module, configured to display a virtual scene based on a first virtual lens corresponding to the perspective of a first virtual object, where the virtual scene includes a virtual vehicle, and the first virtual object is located in the virtual vehicle; A control module, configured to control the movement of the virtual vehicle in response to a trigger operation on the virtual vehicle; The control module is further configured to control the first virtual lens to jitter during the movement of the virtual vehicle, where the characteristic parameters of the jitter of the first virtual lens match the current state of the virtual vehicle.

17. An electronic device, characterized in that, Includes: A memory, configured to store executable instructions; A processor, configured to implement the control method of the virtual lens according to any one of claims 1 to 15 when executing the executable instructions stored in the memory.

18. A computer-readable storage medium storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed by the processor, the control method of the virtual lens according to any one of claims 1 to 15 is implemented.

19. A computer program product comprising a computer program or computer-executable instructions, characterized in that, When the computer program or computer-executable instructions are executed by the processor, the control method of the virtual lens according to any one of claims 1 to 15 is implemented.

Images