A mobile terminal rendering method based on LBM-VOF fluid simulation and ray tracing

By integrating LBM-VOF fluid simulation and ray tracing technology into mobile devices, the technical challenges of fluid simulation and advanced rendering have been solved, achieving realistic fluid rendering effects and enhancing the graphics performance of mobile devices.

CN121661217BActive Publication Date: 2026-06-19NANJING UNIV OF SCI & TECH

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
NANJING UNIV OF SCI & TECH
Filing Date
2026-02-06
Publication Date
2026-06-19

Smart Images

  • Figure CN121661217B_ABST
    Figure CN121661217B_ABST
Patent Text Reader

Abstract

This invention discloses a mobile rendering method based on LBM-VOF fluid simulation and ray tracing, comprising: receiving input parameters and a scene from fluid simulation; updating fluid density, velocity, and fill level using an LBM model coupled with a VOF interface capture algorithm based on the Vulkan computing pipeline; performing ray tracing rendering calculations using the GPU and computing pipeline, reconstructing surfaces using the moving cubes algorithm, calculating mixed colors through reflection, refraction, and light absorption, and generating a low-resolution rendered image; upsampling the low-resolution rendered image and reconstructing it into a high-resolution rendered output image; integrating the rendering logic into a mobile application using the GameActivity mobile application development library, and finally presenting the fluid rendering result on the mobile screen. This invention integrates fluid simulation and realistic rendering technologies and ported them to mobile devices to achieve a realistic fluid rendering effect.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention belongs to the field of computer graphics technology, specifically relating to a mobile rendering method based on LBM-VOF fluid simulation and ray tracing. Background Technology

[0002] Fluid simulation and rendering is a key area in computer graphics, widely used in film and television special effects, industrial design, scientific visualization, and games. However, achieving realistic fluid simulation and rendering on performance-constrained mobile devices has always been a significant technical challenge. Traditional simulation methods are typically computationally intensive, making it difficult to provide realistic visual effects while maintaining smoothness. This results in insufficient fluid representation in mobile applications, greatly impacting the user's immersive experience and visual realism.

[0003] To address these challenges, several GPU-accelerated fluid simulation technologies have emerged in recent years. Patent CN110717269A discloses a fluid surface detail preservation method based on mesh and particle coupling. The core of this method lies in combining mesh (LBM-VOF) and particle (SPH) approaches to solve the "abnormal surface mesh" problem encountered by LBM during simulation. Its working principle is to generate particles at the locations of abnormal surface meshes to replace the original meshes, and through a designed coupling algorithm, integrate the mesh fluid and particle fluid into the same scene to ensure physical conservation. The drawback of this method is that its rendering part uses a screen-space method, a rasterization-based technique, which makes it difficult to achieve advanced lighting effects such as reflection and refraction provided by ray tracing. Therefore, there is still room for improvement in rendering quality. Patent CN112926252A discloses a method for simulating the interaction between liquid and cloth. It uses the D3Q27 model of LBM to simulate the diffusion of liquid in cloth and simplifies the interaction process into four steps: collision detection, absorption, diffusion, and dripping. The shortcomings of this method are that its solution is mainly aimed at the specific application scenario of solid-liquid interaction and lacks universality for general fluid scenarios. In addition, its rendering part uses OpenGL and does not involve rendering techniques such as ray tracing that can significantly improve the visual realism.

[0004] In summary, existing technologies either focus on improving a single simulation algorithm or are limited to simulations of specific scenarios (such as smoke or solid-liquid interaction), lacking a comprehensive solution that can fully integrate fluid simulation (such as LBM combined with VOF) with realistic rendering techniques (such as ray tracing) on ​​mobile terminal GPUs. Summary of the Invention

[0005] The purpose of this invention is to provide a mobile rendering method based on LBM-VOF fluid simulation and ray tracing, in order to achieve realistic fluid simulation and rendering on mobile devices.

[0006] The technical solution to achieve the purpose of this invention is: a mobile rendering method based on LBM-VOF fluid simulation and ray tracing, comprising the following steps:

[0007] The first step is to receive the input parameters and scenario for the fluid simulation;

[0008] The second step involves using the mobile terminal's GPU, based on the Vulkan computing pipeline, to calculate the discrete distribution function of the fluid using the lattice Boltzmann method model, and coupling it with the fluid volume method for interface capture, maintaining the fluid's velocity, density, and fill level, and generating three-dimensional state data of the fluid.

[0009] The third step involves using the GPU and Vulkan computing pipeline to perform ray tracing rendering calculations, and launching the traveling cube algorithm within the same pipeline to reconstruct the surface. Radiometrics are calculated using Fresnel reflection, Snell refraction, and Beer-Lambert absorption models to generate a low-resolution rendered image.

[0010] The fourth step is to upsample the low-resolution rendered image to obtain a high-resolution rendered output image;

[0011] The fifth step involves integrating the GameActivity mobile application development library into the Android operating system, calling the Vulkan program, and displaying the high-resolution rendered output image on the mobile terminal's screen.

[0012] Preferably, the first step involves inputting the parameters and scene required for fluid simulation and rendering via startup or program presets; specific parameters include simulation parameters such as the number of grids, viscosity coefficient, magnitude of external force, and boundary smoothness; rendering parameters such as camera position, field of view, and fluid color; and the scene consists of the fluid motion area and the external skybox.

[0013] Preferably, in the second step, the fluid simulation algorithm LBM is executed on the Vulkan computing pipeline using the GPU of the mobile terminal to maintain the discrete distribution function of the fluid during the motion process, thereby obtaining the fluid's motion information, including velocity and density; at the same time, the VOF method is used to maintain the fluid's fill level, mass and excess mass, thereby obtaining the three-dimensional state data of the fluid in the scene.

[0014] Preferably, in the third step, the GPU is used to perform ray tracing rendering calculations on the Vulkan computing pipeline. The ray tracing rendering calculations include: using the moving cubes algorithm to model triangular facets of the fluid's three-dimensional state data and calculating the normals of the triangular facets; calculating the reflection, refraction, and absorption of light in the fluid based on the normals to obtain mixed colors; and sampling the light rays as they hit the skybox. The final low-resolution rendered image is obtained through the above operations.

[0015] Preferably, in the fourth step, the low-resolution rendered image is upsampled using the Vulkan computation pipeline to obtain a high-resolution rendered output image, specifically as follows:

[0016] For each pixel in the low-resolution rendered image, its sampling position in the normalized coordinate system is first calculated; a normalized UV coordinate between 0 and 1 is obtained by dividing the integer coordinate of the pixel by the size of the high-resolution rendered output image.

[0017] The input low-resolution rendered image is directly sampled using normalized UV coordinates; a point sampling or nearest neighbor sampling technique is used to directly obtain the color value of the texel in the source image that is closest to the normalized UV coordinates without interpolation calculation.

[0018] The sampled color values ​​are written to the corresponding pixel positions in the high-resolution rendered output image; each thread is responsible for sampling and writing one pixel, and finally generates a rendering result that matches the screen resolution.

[0019] Preferably, in the fifth step, the GameActivity mobile application development library is integrated into the Android operating system to start the rendering process based on the Vulkan computing pipeline and display the high-resolution rendered output image on the mobile terminal screen. Specifically:

[0020] It adopts a collaborative working mode between Android's build.gradle file and the external CMake build tool; by configuring the external build module in the Gradle file, the path of the CMake script and the compilation parameters for the platform architecture are specified.

[0021] In the main Java entry point of the Android application, the native rendering logic is encapsulated by inheriting the GameActivity class from the GameActivity development library. This library provides a unified interface that allows native code to directly access the Android system's windows and input events. The native library is loaded when the application starts.

[0022] The entry function of the native code is responsible for initializing the Vulkan rendering engine and starting an event loop; this loop handles the creation, destruction, pausing, and resumption of windows by polling Android system commands; when the window is available, the rendering loop will continuously drive the fluid simulation and rendering process.

[0023] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0024] A computer device includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described above.

[0025] A computer program product includes a computer program that, when executed by a processor, implements the steps of the above-described method.

[0026] Compared with the prior art, the significant advantage of the present invention is that it provides a complete technical solution for realizing realistic fluid simulation and rendering on mobile terminals. By creatively integrating LBM fluid simulation on GPU, Marching Cubes-based technology, ray tracing rendering, and upsampling technology into the Vulkan computing pipeline, it solves the technical problem of simultaneously realizing fluid simulation and advanced rendering on mobile devices in the prior art, thereby promoting the further development of mobile terminal graphics technology. Attached Figure Description

[0027] Figure 1 This is a diagram illustrating the overall structure of the method of this invention.

[0028] Figure 2 This is a flowchart of the fluid simulation algorithm of the present invention.

[0029] Figure 3 This is a flowchart of the ray tracing process of the present invention.

[0030] Figure 4 These are comparison images of different rendering results. The left side shows ray tracing rendering on Windows, and the right side shows screen-space fluid rendering.

[0031] Figure 5 This is a screenshot of the ray tracing rendering result on the Android device. Detailed Implementation

[0032] This invention proposes a mobile rendering method based on LBM-VOF fluid simulation and ray tracing, which includes the following steps:

[0033] The first step is to receive the input parameters and scenario for the fluid simulation;

[0034] The second step involves using the graphics processing unit (GPU) of the mobile terminal, based on the Vulkan Compute Pipeline, to calculate the discrete distribution function of the fluid using the Lattice Boltzmann Method (LBM) model, and coupling it with the Volume of Fluid (VOF) method for interface capture, maintaining the fluid velocity, density and fill level, and generating three-dimensional fluid state data.

[0035] The third step involves using the GPU and Vulkan computing pipeline to perform ray tracing rendering calculations, and launching the Marching Cubes algorithm within the same pipeline to reconstruct the surface. The radiometrics are calculated using Fresnel reflection, Snell refraction, and Beer-Lambert absorption models to generate a low-resolution rendered image.

[0036] The fourth step is to perform upsampling on the low-resolution rendered image to obtain a high-resolution rendered output image;

[0037] The fifth step involves integrating the GameActivity mobile application development library into the Android operating system, calling the Vulkan program, and displaying the high-resolution rendered output image on the mobile terminal's screen.

[0038] Furthermore, the first step involves inputting the parameters and scene required for fluid simulation and rendering through startup or program presets; specific parameters include, but are not limited to, simulation parameters such as the number of grid cells, viscosity coefficient, magnitude of external force, and boundary smoothness; rendering parameters such as camera position, field of view, and fluid color; and other system parameters; the scene includes the fluid motion area and the external skybox, etc.

[0039] Furthermore, in the second step, the mobile terminal's graphics processing unit (GPU) is used to execute the fluid simulation algorithm LBM on the Vulkan computing pipeline. This maintains the discrete distribution function of the fluid during its motion, thereby obtaining the fluid's movement information, including velocity and density. Simultaneously, the VOF method is used to maintain the fluid's fill level, mass, and excess mass, obtaining the three-dimensional state data of the fluid in the scene. Excess mass refers to the mass that needs to be reallocated to neighboring meshes when the fluid volume fraction in a mesh is greater than 1, in the VOF algorithm.

[0040] Furthermore, in the third step, the GPU is used to perform ray tracing rendering calculations on the Vulkan computing pipeline. The ray tracing rendering calculations include: using the moving cubes algorithm to model triangular facets from the three-dimensional fluid state data and calculating the normals of the triangular facets; calculating the reflection, refraction, and absorption of light in the fluid based on the normals to obtain mixed colors; and sampling the light rays as they hit the skybox. Through the above operations, the final low-resolution rendered image is obtained.

[0041] Furthermore, in the fourth step, the low-resolution rendered image is upsampled using the Vulkan computing pipeline to obtain a high-resolution rendered output image.

[0042] Furthermore, in the fifth step, the Vulkan program is invoked in the Android operating system through the mobile application library GameActivity, and the high-resolution rendered output image is displayed on the screen of the mobile terminal.

[0043] The implementation process of this invention will be described in detail below with reference to the illustrative figures.

[0044] Example

[0045] This embodiment proposes a mobile rendering method based on LBM-VOF fluid simulation and ray tracing, the overall structure of which is as follows: Figure 1 As shown, the specific steps are as follows:

[0046] The first step is to input the parameters and scene required for fluid simulation and rendering through startup or program presets. Adjustable parameters can be dynamically adjusted using additional techniques; otherwise, parameters need to be set before startup or preset by the program. The scene section is divided into fluid scene and other scenes. The fluid scene mainly includes the initial state of the fluid, the fluid's range of motion, etc., which are responsible for affecting the fluid's current and future state; other scenes generally refer to prohibited objects, such as static background textures or skyboxes.

[0047] The second step, after determining the program parameters and simulation scenario, requires utilizing the mobile terminal's graphics processing unit (GPU) to execute the fluid simulation algorithm LBM on the Vulkan computing pipeline. The overall fluid flow is as follows: Figure 2 As shown, the specific steps are as follows:

[0048] 1) Build the basic Vulkan framework, including initializing instances, physical and logical devices, surfaces and swap chains, computation and rendering related resources, computation pipeline layout, descriptor pool, descriptor set, command buffer, and other resources.

[0049] 2) Implement the fluid simulation algorithm LBM using the Vulkan computing pipeline and maintain fluid state data using the VOF algorithm; this includes writing algorithm-related Compute Shaders, submitting command buffers, and synchronizing commands.

[0050] For LBMs, various data caches need to be created for the algorithm, namely discrete density function (DDF) cache, density cache, velocity cache, and lattice type cache. The core formulas of the LBM algorithm mainly include updates to fluid, collision, and macroscopic quantities:

[0051] (1)

[0052] (2)

[0053] (3)

[0054] (4)

[0055] in, This represents the three-dimensional spatial lattice coordinate position of a fluid particle; Indicates the current simulation time; Indicates at time ,Location At, discrete velocity direction Temporary discrete distribution function on; Indicates at time ,Location At, discrete velocity direction Discrete distribution function on; Indicates the time step of the simulation; Indicates the first Unit direction vectors in discrete directions; Indicates the first Collision operators in several directions are used to describe the collision effects between fluid particles; Indicates at time ,Location Macroscopic fluid density at the location; Indicates at time ,Location The macroscopic velocity vector at that location; Indicates the first Discrete lattice velocities in each direction , This represents the grid step size. This embodiment uses the D3Q19 model, therefore the subscript... The range of values ​​is .

[0056] The algorithm first reads data from the Discrete Distribution Function (DDF) buffer using formula (1) and writes it into a temporary DDF variable. After a series of operations, it calculates the DDF data after the collision using formula (2) and writes it into the DDF buffer. It is a collision operator. The collision operator used in this invention is the SRT collision operator (also known as the BGK model), and the specific formula is as follows:

[0057] (5)

[0058] in, It represents the relaxation time, which determines how quickly a fluid tends to reach equilibrium. Indicates at time ,Location The local equilibrium distribution function at that location; The formula for calculating the dynamic viscosity coefficient is as follows:

[0059] (6)

[0060] in, This represents the kinematic viscosity of the fluid. The speed of sound in the crystal lattice is typically taken as a value in the D3Q19 model. Operations that can be performed on temporary DDF variables during algorithm execution include, but are not limited to:

[0061] 1) Apply boundary handling. Common boundaries include non-moving bounce-back boundaries:

[0062] (7)

[0063] in, Representation of discrete direction Opposite direction vectors; Indicates at time Location Location, pointing to Discrete distribution function of direction. The non-moving, springback boundary can be used for general solid boundaries;

[0064] Moving Bounce-Back Boundaries:

[0065] (8)

[0066] in, Indicates the first Weighting coefficients for each direction; Indicates the first Discrete lattice velocities in each direction; Indication and direction The opposite direction index, i.e. The described moving and rebounding boundary is generally used for all boundary conditions where the wall velocity is not zero;

[0067] Equilibrium Boundaries:

[0068] (9)

[0069] in, This represents the preset equilibrium reference density; This represents the preset equilibrium reference velocity vector; Represents a reference density based on a preset equilibrium state. and the preset reference velocity vector The calculated local equilibrium distribution function. The equilibrium boundary is generally used to set a fixed input or output;

[0070] Other important boundary conditions include free slip boundaries and Zou-He boundaries.

[0071] 2) Applying volume forces. In the macroscopic velocity vector... When updating macroscopic quantities, add an additional term, and then formula (4) becomes

[0072] (10)

[0073] Additionally, add a temporary DDF variable as an additional item.

[0074] (11)

[0075] When calculating the SRT collision operator, formula (5) is updated to obtain...

[0076] (12)

[0077] in, This represents the vector of external volume forces acting on the fluid; In the D3Q19 model, the first... The weight coefficients corresponding to each direction; Indicates the first Discrete external force source terms in each direction; This represents the current macroscopic velocity vector; It represents the amount of correction that external forces produce on the distribution function within a time step.

[0078] For VOF, additional model extensions and resource caching are required, including FillLevel cache, quality cache, and redundant quality cache. Additionally, extra types need to be added to the cell types, including Fluid, Interface, Gas, and temporary intermediate cell types such as IF, IG, and GI. The initialization formula for the cell types is as follows:

[0079] (13)

[0080] in, Indicates time Location The grid fill level at that location has a value range of [value range missing]. ; This indicates the mass of fluid contained within the cell.

[0081] During the continuous iteration of LBM, the mass change of the fluid between two frames is calculated using temporary DDF variables:

[0082] (14)

[0083] in, Indicates from adjacent cells (position) ) flows to the current cell (position) The mass flux of the lattice. The lattice type is updated based on the changed mass density ratio for each lattice.

[0084] (15)

[0085] in, This represents a very small threshold constant (Epsilon) to avoid type misjudgment caused by floating-point calculation errors. Simultaneously, to address the issue of incorrect DDF data for neighboring gas lattice types of the Interface lattice type, it needs to be reconstructed. The reconstruction formula is:

[0086] (16)

[0087] in, Indicates the location The location that needs to be rebuilt is in the following direction. The reverse temporary distribution function; Indicates the directional index from fluid to gas; Indication and direction The opposite direction index (i.e.) ); Indicates the preset gas reference density; Indicated based on gas reference density and the current macroscopic velocity vector The calculated direction is The equilibrium distribution function; Indicated based on gas reference density and the current macroscopic velocity vector The calculated direction is The equilibrium distribution function; This indicates the known orientation of the current cell. The distribution function (from the fluid side).

[0088] For each cell where the type transition ends, if its fill level is greater than 1 or less than 0, it needs to be clamped. Between these, excess mass is passed to other cells through the excess mass buffer. Finally, a type conversion is performed.

[0089] The third step, after obtaining the fluid state data for each frame through a fluid simulation algorithm, is to perform ray tracing rendering calculations on the Vulkan computation pipeline. The overall process is as follows: Figure 3 As shown, the specific steps are as follows:

[0090] 1) Light generation

[0091] This invention generates a principal ray in parallel for each pixel of the rendered image. By normalizing the pixel coordinates to the normalized device coordinate system (NDC), and then through inverse projection transformation and inverse view transformation, the two-dimensional pixel coordinates are converted into the ray direction in three-dimensional world space, with the origin being the camera position. This process can be represented as:

[0092] (17)

[0093] in, This represents the normalized ray direction vector generated in the world coordinate system; This represents the inverse view matrix, used to transform from view space back to world space; This represents the inverse projection matrix, used to transform from clipping space back to viewing space; This represents the ray vector in the normalized device coordinate system (NDC), which is derived from pixel coordinates; This represents the normalization function, used to convert the calculated direction vector into a unit vector. 2) Fluid Surface Tracking

[0094] After generating the master ray, this invention utilizes a ray-mesh traversal algorithm adapted to mobile GPU computing pipelines to quickly locate cells that may intersect with the fluid surface within the 3D voxel mesh of the fluid simulation. This algorithm moves cell by cell in the voxel mesh along the direction of the ray in an incremental stepping manner. Its core lies in pre-calculating the step size parameters along three axes and selecting the shortest distance direction for single-step movement based on the current distance between the ray and the mesh plane. This method avoids complex intersection calculations, instead traversing voxels through simple floating-point comparisons and addition operations to quickly find voxel cells containing the fluid surface. By integrating the traversal algorithm into the Vulkan computational shader, in-situ access to the LBM fluid density field data generated in the preceding steps is achieved, thus avoiding the overhead of large-scale spatial data backhaul.

[0095] For each cell visited, the ray is checked to see if its cell type is fluid. If not, the ray continues until it encounters a fluid cell or exits the scene. Once the ray encounters a fluid cell, the code executes the MarchingCubes algorithm to reconstruct the fluid surface mesh from the cell's voxel values. This algorithm generates a series of triangles by consulting a pre-computed topology lookup table and using linear interpolation to accurately calculate vertex positions.

[0096] (18)

[0097] in, It is the equivalent surface value. and The grid at both ends of the cube's edge is filled with horizontal values. Then, the Moeller-Tumber algorithm is performed on each generated triangle to detect the ray-triangle intersection, in order to determine the precise intersection point of the ray with the fluid surface.

[0098] 3) Light interaction and volume effect

[0099] Once the intersection point is determined, the shader will calculate the surface normal at that point and handle the interaction between light and the fluid surface using the following physical model:

[0100] Fresnel effect: Using the Shockley approximation of Fresnel's equations, the proportion of reflected light is calculated based on the angle of incidence of the light rays to simulate the phenomenon of water surface reflection changing with the observation angle.

[0101] (19)

[0102] in, This indicates that the light ray is at an angle of incidence of . The Fresnel reflection coefficient at that time is the ratio of the reflected light intensity to the incident light intensity. It represents the fundamental reflectivity of light when it is incident perpendicularly (i.e., at an angle of incidence of 0 degrees), and this value is determined by the refractive index of the fluid; It represents the angle of incidence when light enters the surface of a fluid, that is, the angle between the direction of the light ray and the direction of the surface normal; This represents the cosine value of the angle of incidence.

[0103] Refraction and internal reflection: The direction of refracted light is calculated according to Snell's law. If light travels from the inside of a fluid to the outside and the angle of incidence exceeds the critical angle, total internal reflection will occur, in which case the light will be completely reflected back into the fluid.

[0104] Light absorption: Refracted light continues to propagate within the fluid, and its color attenuates according to the Beer-Lambert law, simulating the fluid's absorption of light to produce realistic transparency and a sense of depth.

[0105] (20)

[0106] in, Transmittance (or absorption ratio) is used to calculate the proportion of energy remaining after light passes through a fluid. The base of the natural logarithm, also known as the Euler number; The unit absorption coefficient of a fluid is used to describe the intensity of light absorption by the fluid; the larger the value, the less transparent the fluid. This represents the geometric path length of light propagating within the fluid (i.e., the distance the light travels in the fluid medium). Finally, the final low-resolution pixel color is obtained by weighted mixing of the reflected and attenuated refracted light colors. The entire rendering process is completed on the GPU with a single compute shader call, resulting in a low-resolution rendered image.

[0107] The fourth step, after obtaining the low-resolution rendered image for ray tracing, requires upsampling the low-resolution rendered image using the Vulkan computation pipeline. This upsampling reconstructs the low-resolution rendered image from the previous step into a high-resolution rendered output image, thereby reducing the computational burden on the ray tracing step. This process is executed in parallel using GPU computation shaders, and its specific implementation details are as follows:

[0108] 1) Coordinate Mapping. For each pixel in the high-resolution rendered output image, this invention first calculates its sampling position in a normalized coordinate system. This process is achieved by dividing the pixel's integer coordinates by the size of the high-resolution rendered output image, thus obtaining a two-dimensional normalized coordinate between 0 and 1, hereinafter referred to as the normalized UV coordinates. This mapping relationship can be expressed as:

[0109] (twenty one)

[0110] in For the normalized UV coordinates, The integer coordinate index is the pixel, and targetSize represents the target image size. Subtracting 1 is to avoid edge precision issues.

[0111] 2) Texture Sampling. Next, the Vulkan computation pipeline directly samples the input low-resolution rendered image using the normalized UV coordinates. This invention employs a point sampling or nearest-neighbor sampling technique, that is, without interpolation calculations, it directly obtains the color value of the texel in the source image that is closest to the normalized UV coordinates.

[0112] 3) Output Results. Finally, the sampled color values ​​are written to the corresponding pixel positions in the high-resolution rendered output image. Because this process is highly parallel, each thread is responsible for sampling and writing one pixel, ultimately generating a rendering result that matches the screen resolution.

[0113] The fifth step involves using the GameActivity library to call the Vulkan program within the Android operating system and displaying the high-resolution rendered output image on the mobile terminal's screen. The core of this porting solution is leveraging Google's GameActivity library to tightly integrate Android application lifecycle management with native C++ code. Specific implementation details are as follows:

[0114] 1) Build and Compilation System. This invention employs a collaborative build mechanism based on Gradle and CMake. By configuring external build modules in the Gradle file and specifying the path to the CMake script and compilation parameters for multiple platform architectures (such as ARM and x86), it ensures that the program can run stably on various Android devices. Simultaneously, this build process automates the conversion of shaders from GLSL source code to the Vulkan executable SPIR-V format, guaranteeing synchronized updates of rendering resources.

[0115] 2) Native and Java Layer Interface. In the main Java entry point of the Android application, the native rendering logic is encapsulated by inheriting the GameActivity class from the development library. The GameActivity library provides a unified interface, allowing native code to directly access Android system windows and input events without complex Java Native Interface (JNI) code. The native library is loaded when the application starts, providing underlying support for subsequent rendering loops.

[0116] 3) Game Loop and Lifecycle Management. The entry function in the native code is responsible for initializing the Vulkan rendering module corresponding to the Vulkan computing pipeline and starting an event loop. This loop handles lifecycle events such as window creation, destruction, pause, and resumption by polling Android system commands. When the window is available, the rendering loop continuously drives the fluid simulation and rendering process, thereby completely transferring high-load computing tasks to the native code layer, making the most of the mobile device's GPU performance, and achieving smooth and beautiful fluid rendering effects.

[0117] Figure 4 This image shows a comparison of the effects of different rendering methods on Windows after the same simulation time. From top to bottom, the images represent the results at frame 100, frame 250, and frame 500. The left side shows the ray tracing rendering result implemented in this invention, and the right side shows the screen-space fluid rendering result, with particles generated at the geometric center of each fluid grid type. It is evident that, regardless of the fluid's angle, the ray tracing rendering method produces a more realistic effect compared to the screen-space fluid rendering method, resulting in brighter areas and darker areas.

[0118] Figure 5 This image showcases the ray tracing rendering results of porting a Vulkan application from Windows to Android. From left to right, the results are at frame 100, frame 250, and frame 500. The images clearly show that the Android rendering results are essentially identical to the Windows rendering results, achieving a realistic fluid rendering effect.

[0119] The specific embodiments of the present invention have been described in detail above. It should be noted that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various modifications or variations within the scope of the claims, which do not affect the essence of the present invention.

Claims

1. A mobile device rendering method based on LBM-VOF fluid simulation and ray tracing, characterized in that, Includes the following steps: The first step is to receive the input parameters and scenario for the fluid simulation; The second step involves using the mobile terminal's GPU, based on the Vulkan computing pipeline, to calculate the discrete distribution function of the fluid using the lattice Boltzmann method model, and coupling it with the fluid volume method for interface capture, maintaining the fluid's velocity, density, and fill level, and generating three-dimensional state data of the fluid. The third step involves using the GPU and Vulkan computing pipeline to perform ray tracing rendering calculations, and launching the traveling cube algorithm within the same pipeline to reconstruct the surface. Radiometrics are calculated using Fresnel reflection, Snell refraction, and Beer-Lambert absorption models to generate a low-resolution rendered image. The fourth step is to upsample the low-resolution rendered image to obtain a high-resolution rendered output image; The fifth step involves integrating the GameActivity mobile application development library into the Android operating system, initiating the rendering process based on the Vulkan computing pipeline, and displaying a high-resolution rendered output image on the mobile terminal's screen. 2.The mobile device rendering method based on LBM-VOF fluid simulation and ray tracing according to claim 1, wherein, The first step is to input the parameters and scene required for fluid simulation and rendering through startup or program presets; specific parameters include simulation parameters such as the number of grids, viscosity coefficient, magnitude of external force, and boundary smoothness, and rendering parameters such as camera position, field of view, and fluid color; the scene is the fluid movement area and the external skybox. 3.The mobile device rendering method based on LBM-VOF fluid simulation and ray tracing of claim 1, wherein, The second step involves using the mobile terminal's GPU to execute the fluid simulation algorithm LBM on the Vulkan computing pipeline. This maintains the discrete distribution function of the fluid during its motion, obtaining the fluid's movement information, including velocity and density. Simultaneously, the VOF method is used to maintain the fluid's fill level, mass, and excess mass, resulting in three-dimensional state data of the fluid in the scene. 4.The mobile device rendering method based on LBM-VOF fluid simulation and ray tracing of claim 1, wherein, The third step involves using the GPU to perform ray tracing rendering calculations on the Vulkan computing pipeline. These calculations include: using the moving cubes algorithm to model triangular facets from the fluid's 3D state data and calculating the normals of the facets; calculating the reflection, refraction, and absorption of light in the fluid based on the normals to obtain mixed colors; and sampling the light rays as they hit the skybox. Through these operations, the final low-resolution rendered image is obtained. 5.The mobile device rendering method based on LBM-VOF fluid simulation and ray tracing of claim 1, wherein, The fourth step involves upsampling the low-resolution rendered image to obtain a high-resolution rendered output image, specifically as follows: For each pixel in the low-resolution rendered image, its sampling position in the normalized coordinate system is first calculated; a normalized UV coordinate between 0 and 1 is obtained by dividing the integer coordinate of the pixel by the size of the high-resolution rendered output image. The input low-resolution rendered image is directly sampled using normalized UV coordinates; A point sampling or nearest neighbor sampling technique is used to directly obtain the color value of the texel in the source image that is closest to the normalized UV coordinates without interpolation calculation. The sampled color values ​​are written to the corresponding pixel positions in the high-resolution rendered output image; each thread is responsible for sampling and writing one pixel, and finally generates a rendering result that matches the screen resolution. 6.The mobile device rendering method based on LBM-VOF fluid simulation and ray tracing of claim 1, wherein, The fifth step involves integrating the GameActivity mobile application development library into the Android operating system to initiate the rendering process based on the Vulkan computing pipeline and displaying the high-resolution rendered output image on the mobile terminal's screen. Specifically: It adopts a collaborative working mode between Android's Gradle files and external CMake build tools; by configuring external build modules in the Gradle files, the path to the CMake scripts and compilation parameters for the platform architecture are specified. In the main Java entry point of the Android application, the native rendering logic is encapsulated by inheriting the GameActivity class from the GameActivity development library. This library provides a unified interface that allows native code to directly access the Android system's windows and input events. The native library is loaded when the application starts. The entry function in the native code is responsible for initializing the Vulkan rendering engine and starting an event loop; This loop processes window creation, destruction, pausing, and resumption by polling Android system commands; when a window is available, the rendering loop continuously drives the fluid simulation and rendering process.

7. A computer readable storage medium characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 6.

8. A computer device, comprising: It includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method according to any one of claims 1 to 6.

9. A computer program product comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method described in any one of claims 1 to 6.