A mitsuba-based building light environment simulation acceleration method and system

Abstract

The application provides a Mitsuba-based building light environment simulation acceleration method and system. The method receives building vertexes, triangles, surface-level materials, sky, working surface sensors and camera states in a platform, converts them into unified solving objects through a Schema 2 adapter, and performs working surface illuminance solving or projection HDR rendering in a cuda_ad_rgb variant of Mitsuba 3. The system analyzes rendering sample numbers, grid sample numbers and maximum path depths according to quality levels, takes geometry, triangle, material, BSDF content and rendering setting abstracts as cache keys, and constructs or reuses scene acceleration structures in independent native working processes. The acceleration method of the application does not rely on simplifying all building optical phenomena into a single empirical coefficient, but realizes a reviewable acceleration path through input adaptation, physical material objects, GPU solving, caching and isolated running.

Description

Technical Field

[0001] This invention relates to the fields of numerical simulation of building lighting environments, GPU ray transmission, and computational building design software, and particularly to a method and system for accelerating building lighting environment simulation based on Mitsuba. Specifically, it relates to a simulation method and system based on Mitsuba 3, Dr.Jit, and cuda_ad_rgb variants to accelerate the calculation of illuminance and projected HDR on building work surfaces, and to improve the stability of continuous design iterations through process isolation and scene caching. Background Technology

[0002] Architectural lighting design requires iterative changes to geometric models, windows, materials, sky, work surfaces, and viewpoints, as well as comparisons of illuminance, HDR, and glare results. Traditional CPU computation paths require multiple scene constructions and ray transfers when the model and working conditions change repeatedly, resulting in long design iteration times. GPU ray transfer can process a large number of paths in parallel, but architectural lighting environment inputs simultaneously include surface-level materials, sky radiance, work surface normals, and projection cameras. If these semantics are not consistently translated between the platform and the GPU solver, the results become difficult to verify.

[0003] Native components such as Mitsuba, Dr.Jit, and OptiX can also be affected by graphics card drivers, compiler caches, or native runtime exceptions. If the native runtime library is loaded directly in the main program process, runtime exceptions may cause the main program to exit; if the results from other engines are used for silent rollback, the user cannot determine the true source of the current result's calculation.

[0004] Furthermore, when repeatedly executing the same geometry, materials, and solver settings, scene acceleration structures can be reused, and sky states can change. If the cache key does not include materials, BSDF, and rendering parameters, erroneous reuse may occur; if there is no limit to the number of caches, it may also consume excessive video memory or system memory. Therefore, a GPU simulation technology for architectural lighting environments is needed, featuring unified scene adaptation, strict cache keying, native process isolation, and explicit error states. Summary of the Invention

[0005] The purpose of this invention is to solve the problems in the prior art and to propose a method and system for accelerating architectural lighting environment simulation based on Mitsuba.

[0006] This invention is achieved through the following technical solution: This invention proposes a method for accelerating architectural lighting environment simulation based on Mitsuba. This method enables architectural geometry, materials, sky, work surfaces, and camera parameters in the platform to enter the Mitsuba GPU solver with unified data semantics, and isolates the native GPU runtime boundary from the main program. The method includes: Step 1: Receive platform scene data, including vertex verification, triangle index, material distribution status, working face sensor points, sensor normals, and camera parameters. Step 2: Create Schema 2 scene objects, convert platform materials into solver materials, convert CIE / Perez / measured HDR skies into analytical or image skies, and convert the working surface and observation camera into Mitsuba computable objects; Step 3: Read the number of rendering samples, the number of mesh samples, and the maximum path depth according to the quality level, and receive the user display parameters within the boundary range; Step 4, calculate the scene summary; the summary includes geometry, triangles, materials, BSDF files, and rendering settings; sky updates do not change the geometry and material cache keys; Step 5: Build or reuse the Pure GPU scene in the isolated working process, and perform working surface illuminance or projection HDR solution respectively; Step 6: Write the illumination array, HDR pixels, statistics, time consumption, cache hits, and engine status back to the main program, and generate a file that can be displayed and saved by the platform according to the result type.

[0007] Furthermore, the Schema 2 scene object includes at least a geometric mesh, triangle material allocation, material library, sky model, working face sensor points, sensor normals, camera position, camera target point, camera up direction, and camera projection parameters.

[0008] Furthermore, material conversion supports at least one of diffuse, glass, specular, metallic, transmissive, and complex BSDF, and reads at least one of reflectivity, transmissivity, roughness, specular component, refractive index, glass layer parameters, thermal emissivity, and BSDF file path; if the material is transparent, transparent material conversion includes at least one of single-layer transparent glass, double-layer transparent glass, and low-emissivity double-layer glass, and forms a material object that can be used for optical transmission calculation based on normal transmittance, front and rear surface reflectivity, refractive index, thickness, and coating parameters; sky conversion supports CIE uniform sky, CIE cloudy sky, CIE sunny sky, Perez sky, and hemispherical fisheye HDR sky calibrated with absolute radiance; Perez sky reads direct normal irradiance and horizontal diffuse irradiance, and measured sky reads the top azimuth and edge calibration information of the image.

[0009] Furthermore, the solution for the working face illuminance normalizes the sensor normal and outputs arrays of total illuminance, diffuse illuminance, and direct solar illuminance for each sensor point, while also outputting the solution time and grid statistics.

[0010] Furthermore, the projection HDR rendering maps the platform projection identifier to one of angled fisheye, hemispherical fisheye, stereoscopic projection, perspective, or cylindrical projection, and encodes the pixel results as RGBE HDR, while recording the projection type, field of view, number of samples, and engine identifier.

[0011] Furthermore, the cache key in the scene consists of a geometry data summary, a triangle data summary, a material state summary, a BSDF file path and file content summary, and a rendering settings summary; when the cache is hit, the sky object is updated and the scene acceleration structure is reused; when the cache is not hit, a new scene acceleration structure is created and the number of cache entries is limited; the scene acceleration structure is the solver internal structure that is jointly determined by geometry, material, and solution settings and can be reused for multiple requests.

[0012] Furthermore, Mitsuba runs natively in a separate child process, with the main process passing tasks through request and response files or persistent worker processes. When a worker process exits abnormally, a pipe is closed, a timeout occurs, or an invalid response is returned, the error status is logged and Mitsuba is reported as having failed, without marking other engine results as Mitsuba success.

[0013] Furthermore, the platform can display metadata that records at least the Mitsuba Schema version, cuda_ad_rgb variant, quality level, number of render samples, number of mesh samples, maximum path depth, scene cache hit status, solution time, runtime Radiance dependency status, and calibration status.

[0014] This invention also proposes a Mitsuba-based accelerated system for architectural lighting environment simulation. This system enables architectural geometry, materials, sky, work surfaces, and camera parameters from the platform to enter the Mitsuba GPU solver with unified data semantics, and isolates the native GPU runtime boundary from the main program. The system includes: The receiving module receives platform scene data, including verification vertices, triangle indices, material distribution status, working face sensor points, sensor normals, and camera parameters. The conversion module creates Schema 2 scene objects, converts platform materials into solver materials, converts CIE / Perez / measured HDR skies into analytical or image skies, and converts working surfaces and observation cameras into Mitsuba computable objects. The reading module reads the number of rendering samples, the number of mesh samples, and the maximum path depth according to the quality level, and receives user display parameters within the boundary range; The calculation module calculates a scene summary; the summary includes geometry, triangles, materials, BSDF files, and rendering settings; sky updates do not change the geometry and material cache keys; The isolated worker process module builds or reuses Pure GPU scenes within the isolated worker process, and performs the solution of worker surface illuminance or projection HDR respectively; The HDR / illuminance output module writes the illuminance array, HDR pixels, statistics, time consumption, cache hits, and engine status back to the main program, generating displayable and savable files based on the result type.

[0015] The present invention also proposes an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the Mitsuba-based method for accelerating architectural lighting environment simulation.

[0016] The beneficial effects of this invention are: This invention unifies platform input and Mitsuba object semantics through Schema 2; reduces redundant scene construction through cache reuse; reduces the impact of native runtime exceptions on the main program by isolating worker processes; improves result traceability through explicit engine and error states; and ensures compatibility with existing platform result displays and subsequent glare analysis through illuminance arrays and RGBE HDR output. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0018] Figure 1 This is a flowchart of a method for accelerating architectural lighting environment simulation based on Mitsuba. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] This invention proposes a method for accelerating architectural lighting environment simulation based on Mitsuba. The method includes: receiving architectural scene vertices, triangle indices, material states, sky states, work surface sensor points, sensor normals, and camera states; converting the input into a unified Schema 2 scene object; resolving the number of rendering samples, the number of mesh samples, and the maximum path depth according to the quality level; constructing or reusing the scene acceleration structure in an independent Mitsuba CUDA workflow; performing work surface illuminance calculation or projection HDR rendering; converting the results into a platform-recognizable illuminance array, RGBE HDR, and metadata, and returning the results to the platform's result area.

[0021] Specifically, in combination Figure 1 This invention proposes a method for accelerating architectural lighting environment simulation based on Mitsuba. This method enables architectural geometry, materials, sky, work surfaces, and camera parameters from the platform to enter the Mitsuba GPU solver with unified data semantics, and isolates the native GPU runtime boundary from the main program. The method includes: Step 1: Receive platform scene data, including vertex verification, triangle index, material distribution status, working face sensor points, sensor normals, and camera parameters. Step 2: Create Schema 2 scene objects, convert platform materials into solver materials, convert CIE / Perez / measured HDR skies into analytical or image skies, and convert the working surface and observation camera into Mitsuba computable objects; Step 3: Read the number of rendering samples, the number of mesh samples, and the maximum path depth according to the quality level, and receive the user display parameters within the boundary range; Step 4, calculate the scene summary; the summary includes geometry, triangles, materials, BSDF files, and rendering settings; sky updates do not change the geometry and material cache keys; Step 5: Build or reuse the Pure GPU scene in the isolated working process, and perform working surface illuminance or projection HDR solution respectively; Step 6: Write the illumination array, HDR pixels, statistics, time consumption, cache hits, and engine status back to the main program, and generate a file that can be displayed and saved by the platform according to the result type.

[0022] In this invention, the "Schema 2 scene object" is a stable data interface between the platform input and the GPU solver, not a specific rendering image format; the "scene acceleration structure" is the internal structure of the solver, determined by geometry, materials, and solver settings, and can be reused for multiple requests; and the "isolated worker process" is a native runtime boundary independent of Django or the desktop main program.

[0023] In this invention, "native GPU execution" means that the formal solution is executed by Mitsuba / Dr.Jit / CUDA, without calling the Radiance command or using scene-dependent Radiance calibration coefficients. Radiance can be used as a reference for other display engines or offline testing, but its results are not written as Mitsuba results.

[0024] In this invention, the "quality level" only controls solution settings such as sampling and path depth, and does not directly guarantee a fixed error. Actual accuracy is also affected by geometry, materials, sky conditions, sampling convergence, GPU driver, and solution task; the result metadata should retain these conditions.

[0025] Furthermore, the Schema 2 scene object includes at least a geometric mesh, triangle material allocation, material library, sky model, working face sensor points, sensor normals, camera position, camera target point, camera up direction, and camera projection parameters.

[0026] Furthermore, material conversion supports at least one of diffuse, glass, specular, metallic, transmissive, and complex BSDF, and reads at least one of reflectivity, transmissivity, roughness, specular component, refractive index, glass layer parameters, thermal emissivity, and BSDF file path; if the material is transparent, transparent material conversion includes at least one of single-layer transparent glass, double-layer transparent glass, and low-emissivity double-layer glass, and forms a material object that can be used for optical transmission calculation based on normal transmittance, front and rear surface reflectivity, refractive index, thickness, and coating parameters; sky conversion supports CIE uniform sky, CIE cloudy sky, CIE sunny sky, Perez sky, and hemispherical fisheye HDR sky calibrated with absolute radiance; Perez sky reads direct normal irradiance and horizontal diffuse irradiance, and measured sky reads the top azimuth and edge calibration information of the image.

[0027] Furthermore, the solution for the working face illuminance normalizes the sensor normal and outputs arrays of total illuminance, diffuse illuminance, and direct solar illuminance for each sensor point, while also outputting the solution time and grid statistics.

[0028] Furthermore, the projection HDR rendering maps the platform projection identifier to one of angled fisheye, hemispherical fisheye, stereoscopic projection, perspective, or cylindrical projection, and encodes the pixel results as RGBE HDR, while recording the projection type, field of view, number of samples, and engine identifier.

[0029] Furthermore, the cache key in the scene consists of a geometry data summary, a triangle data summary, a material state summary, a BSDF file path and file content summary, and a rendering settings summary; when the cache is hit, the sky object is updated and the scene acceleration structure is reused; when the cache is not hit, a new scene acceleration structure is created and the number of cache entries is limited; the scene acceleration structure is the solver internal structure that is jointly determined by geometry, material, and solution settings and can be reused for multiple requests.

[0030] Furthermore, Mitsuba runs natively in a separate child process, with the main process passing tasks through request and response files or persistent worker processes. When a worker process exits abnormally, a pipe is closed, a timeout occurs, or an invalid response is returned, the error status is logged and Mitsuba is reported as having failed, without marking other engine results as Mitsuba success.

[0031] Furthermore, the platform can display metadata that records at least the Mitsuba Schema version, cuda_ad_rgb variant, quality level, number of render samples, number of mesh samples, maximum path depth, scene cache hit status, solution time, runtime Radiance dependency status, and calibration status.

[0032] This invention also proposes a Mitsuba-based accelerated system for architectural lighting environment simulation. This system enables architectural geometry, materials, sky, work surfaces, and camera parameters from the platform to enter the Mitsuba GPU solver with unified data semantics, and isolates the native GPU runtime boundary from the main program. The system includes: The receiving module receives platform scene data, including verification vertices, triangle indices, material distribution status, working face sensor points, sensor normals, and camera parameters. The conversion module creates Schema 2 scene objects, converts platform materials into solver materials, converts CIE / Perez / measured HDR skies into analytical or image skies, and converts working surfaces and observation cameras into Mitsuba computable objects. The reading module reads the number of rendering samples, the number of mesh samples, and the maximum path depth according to the quality level, and receives user display parameters within the boundary range; The calculation module calculates a scene summary; the summary includes geometry, triangles, materials, BSDF files, and rendering settings; sky updates do not change the geometry and material cache keys; The isolated worker process module builds or reuses Pure GPU scenes within the isolated worker process, and performs the solution of worker surface illuminance or projection HDR respectively; The HDR / illuminance output module writes the illuminance array, HDR pixels, statistics, time consumption, cache hits, and engine status back to the main program, generating displayable and savable files based on the result type.

[0033] This invention proposes a method and system for accelerating architectural lighting environment simulation based on Mitsuba. The method receives building vertices, triangles, facet materials, sky, work surface sensors, and camera states from the platform, converts them into a unified solver object via a Schema 2 adapter, and performs work surface illuminance solving or projected HDR rendering in the cuda_ad_rgb variant of Mitsuba 3. The system parses the number of rendering samples, mesh samples, and maximum path depth according to the quality level, using geometry, triangles, materials, BSDF content, and rendering settings summaries as cache keys to build or reuse scene acceleration structures in independent native worker processes. The main program receives results via request / response files or persistent worker processes and records the actual engine, sampling parameters, scene cache hits, solution time, runtime Radiance dependency, and calibration status. The current platform identifies this path as a Mitsuba GPU experimental path, and does not implicitly switch to Radiance in case of failure.

[0034] Example The following is combined with Figure 1 This invention will now be described. The current platform identifies the Mitsuba GPU path as an experimental path, requiring users to make a selection; the annual matrix path is still identified as experimental in the platform's functional graph. This embodiment focuses on illustrating the established Schema 2 instantaneous illumination and projected HDR processing chain.

[0035] First, the model geometry, materials, sky, sensors, and cameras are read from the project status. Vertex arrays are converted to floating-point arrays, triangle indices are converted to integer arrays, sensor points are organized into point sets, and sensor normals are organized into 3D vectors. If the normal length is zero or the number of sensors is inconsistent with the output number, the system returns an error and does not initiate GPU solving.

[0036] Geometric transformations create a triangular mesh, and material selection is performed for each triangle based on face-level material assignment. The platform's full coplanar face selection occurs before simulation; the Mitsuba adapter only receives pre-determined material states, so the GPU solver does not guess the materials of windows, walls, or floors.

[0037] Material conversion begins by reading the material type. For diffuse reflective materials, reflectivity and roughness are read; for glass materials, transmittance, refractive index, and glass layers are read; for specular, metallic, transmissive, or complex BSDF materials, the corresponding type is retained and its optical parameters are read. Reflectivity and transmittance are limited to physically reasonable values, and the material name is converted to a secure internal identifier.

[0038] In the cases of double-glazed transparent glass and low-emissivity double-glazed glass, the adapter constructs a layered material object based on the target transmittance, glass layer transmittance, surface reflectance, coating transmittance, and emissivity. This conversion is used to define the material input and does not imply that all complex glass systems have undergone the same level of independent verification.

[0039] The platform displays the actual engine and result files of the instantaneous simulation task in the results area. The adapter only sends a Schema 2 request to the isolated worker process after the user selects the MitsubaGPU experimental path; if Radiance is selected, the Radiance path will execute the task, and the two results are kept distinct in the metadata.

[0040] Sky conversion supports CIE uniform sky, CIE cloudy sky, CIE sunny sky, Perez sky, and calibrated measured sky HDR. CIE sky establishes a resolved sky based on date, time, location, and sky type; Perez sky reads direct normal irradiance and horizontal diffuse irradiance; measured sky requires hemispherical fisheye HDR, absolute irradiance calibration, image top orientation, and edge correction information.

[0041] During the working face solution process, the system reads each sensor point and the user-specified normal vector, normalizes the normal vector, and then passes it to the Mitsuba illuminance solver. The solver returns arrays of total illuminance, diffuse illuminance, and direct solar illuminance. The platform generates a mesh CSV and a color distribution map based on the sensor point order.

[0042] The projection HDR task obtains the viewpoint, target point, upward direction, projection type, and field of view from the platform camera status. The platform projection identifier is mapped to one of the following: angled fisheye, hemispherical fisheye, stereoscopic projection, perspective, or cylindrical projection. The rendering result is output by Mitsuba and encoded as RGBE HDR.

[0043] The illuminance results on the working surface can be displayed as a grid distribution based on sensor points. A high-density grid does not change the sensor normal or material state; it only alters the number or spacing of sensor points and the corresponding sampling settings. The resulting CSV file retains the point-by-point illuminance, avoiding reliance solely on color maps to interpret the results.

[0044] Calculate summaries for the geometry and triangle arrays, and perform stable serialization of material states. If the material references a BSDF file, both the file path and file content summaries are calculated. Rendering settings are also included in the cache key, so old scenes are not incorrectly reused when the number of samples, mesh samples, or maximum path depth changes.

[0045] When a cache hit occurs, the system updates the cached scene with the new sky object; when a cache miss occurs, the system constructs a new PureGpuDaylightEngine. There is a limit to the number of cached entries; when this limit is exceeded, the oldest entry is deleted to prevent continuous batch tasks from consuming resources indefinitely.

[0046] Platform scene data is transmitted as structured objects; geometry, materials, sky, sensor, and camera data are not transmitted via concatenated command-line strings. This allows for separate checks of data types and missing fields during the adaptation phase, preventing the platform interface state from being mistakenly written as the solver's default state.

[0047] The geometry mesh must contain at least an array of vertices and triangle indices. Triangle indices must reference valid vertices, and material assignments must correspond to triangles or default materials; if the geometry is empty, the indices are out of bounds, or the point set is empty, the solver returns an input error.

[0048] Reflectivity, transmittance, and roughness are involved in both material object creation and scene cache summarization. Changing only the material parameters alters the summary, preventing the incorrect reuse of old scene structures. Material types are preserved in the metadata for easy comparison with different optical models.

[0049] Glass layer parameters are used to describe the conditions of light incidence, refraction, reflection, and transmission. Single-pane glass, double-pane glass, and low-emissivity double-pane glass use corresponding layer parameters respectively; for materials for which no layer parameters are provided, the adapter does not fabricate complex glass structures, but processes them according to the input material type and default boundaries.

[0050] CIE and Perez skies are analytical sky inputs, while calibrated measured skies are image sky inputs. Measured HDR must be hemispherical fisheye HDR with the optical axis pointing towards the zenith and have absolute radiance calibration; ordinary renderings are not considered physical sky inputs.

[0051] The direct normal irradiance, horizontal diffuse irradiance, and location information of a Perez sky all affect the sky object. If only a normal ambient color is given without irradiance semantics, it cannot be claimed that a Perez result for the corresponding location and time has been obtained.

[0052] Normalization avoids changes in the results due to sensor vector length. Total illuminance, diffuse illuminance, and direct solar illuminance are saved separately. The platform can display the total in the results area, or check the components and their corresponding sensor numbers in the CSV file.

[0053] Workspace illumination calculations and projected HDR calculations use different output objects. Illumination calculations return an array of sensor points, while projected HDR calculations return an array of image pixels; both are bound to the same scene, sky, materials, and engine state, but the number of HDR pixels cannot be used to replace the number of sensor points.

[0054] Projection mapping translates the platform's Radiance projection identifier into the Mitsuba camera projection type. Camera position, target point, and upward direction collectively determine the field of view, while the horizontal and vertical field of view determine the imaging range. The projection type and field of view are written into the HDR metadata.

[0055] The cache key incorporates geometry, materials, BSDF, and rendering settings. Sky objects can be updated after a cache hit because the sky state does not change the already constructed geometry and material structure; if sky dependencies are compiled into the scene, the corresponding sky data should be added to the cache key.

[0056] The cache entry limit is a runtime resource boundary, not a calculation precision parameter. Deleting an old entry will only cause subsequent requests to rebuild the scene; it will not reuse the results of the old scene on mismatched geometry or materials.

[0057] The isolated worker processes exchange requests and responses through a temporary task directory. The request file stores the schema, operation name, and payload; the response file stores the success result or error type, error message, and necessary stack traces. The master process only reads responses that are correctly formatted and marked as successful.

[0058] Persistent worker processes are used for continuous request processing. When a worker process pipeline is closed, the main process stops the old process and restarts it once; if restarting fails, a Mitsuba error is returned. The task directory is cleaned up after the main process finishes reading to prevent the infinite accumulation of temporary files.

[0059] The calibration status indicates whether calibration is invoked during actual execution; the current Schema 2 pure GPU adapter uses runtime Radiance dependency and scene dependency calibration as explicit metadata, and does not replace the solution source of the current task with offline comparison results.

[0060] The current quality level presets include draft, standard, and high. These presets correspond to the number of render samples, the number of mesh samples, and the maximum path depth, respectively. Users can provide display parameters within the specified limits. Parameters are truncated to the allowed upper limit after being read to prevent abnormal values ​​from being directly passed to the native runtime.

[0061] In one implementation of surface illuminance, the system reads triangular meshes, windows, walls, floors, sky, and sensor points, establishes a Schema 2 request, and starts an isolated worker process. After the worker process completes the GPU illuminance solution, it returns point-by-point results, and the main process generates a mesh CSV and a distribution map that can be displayed on the platform.

[0062] In one projection HDR embodiment, the system reads the viewpoint, target point, upward direction, and hemispherical fisheye projection, and the workflow outputs RGBE HDR. The platform can pass this HDR to the glare index process, but DGP, DGI, and UGR are still calculated by the corresponding evaluation processes based on the viewing field and HDR brightness.

[0063] In the continuous-time implementation, requests with the same geometry, materials, and rendering settings hit the scene cache, and the solution continues after updating the sky object at different times or in different skies. If the model or materials change, the cache key changes and the scene is reconstructed.

[0064] This invention does not use the speedup or error of a single test room as a guarantee for all engineering scenarios. Speed ​​is affected by GPU model, driver, initial compilation, scene complexity, number of samples, and output type; accuracy is affected by materials, sky, path depth, and sampling convergence.

[0065] The Mitsuba path on the current platform is identified as an experimental path, and the annual matrix path also remains experimental. This boundary corresponds to the Schema 2 instantaneous illumination, projection HDR, caching, isolation, and state recording technical features, avoiding the misrepresentation of incomplete capabilities as established facts.

[0066] For requests to continuously change the viewing camera within the same scene, geometry, materials, and sky dependencies remain unchanged, scene acceleration structures can be reused, and camera projection objects are rebuilt. Camera changes are not mistakenly treated as geometric changes, nor are old HDR pixels reused.

[0067] For requests that continuously change the sensor points on the working surface in the same scene, the geometry and material structure can be reused, and the sensor points and normals are re-input as the loads for this solution. The length of the illuminance array is consistent with the number of sensor points in this solution; the old mesh size cannot be reused.

[0068] For requests that change both materials and the sky simultaneously, material changes alter the scene cache key, while sky changes are handled by updating the sky object. The system first completes the material state change before calculating the new summary and cache key to prevent the use of the material scene before the change.

[0069] The request payload of the native worker process is transmitted using serialized data, while the main process directly constructs executable commands from user text. Operation names must belong to the set of instantaneous, yearly, or projected HDR operations supported by Schema 2; unknown operations return an unsupported error.

[0070] The Mitsuba variant status is returned and cached by the probing process. If the current device cannot provide cuda_ad_rgb or GPU information is unavailable, the platform displays an unavailable status; this status is not forcibly overridden to available by quality level or user choice.

[0071] The worker process cache is located in a dedicated data directory, and the CUDA and OptiX cache paths are configured uniformly at runtime. The cache directory is used for compilation or scene reuse, not the results directory; the results directory is still saved by project and task, and the two cannot be mixed.

[0072] After the solution results are returned to the main process, the main process checks the dimensions, finiteness, and basic fields of the result object. If the illuminance array contains NaN, infinite values, or the quantity is incorrect, the result is considered invalid, and a complete mesh map is not generated on the surface.

[0073] Before writing RGBE, the image height, width, number of channels, and pixel limitations are checked. The HDR header records view information for subsequent glare detection of projections; ordinary images without view information are not automatically converted into fisheye HDR.

[0074] For tasks where scene construction is successful but the solution fails, the system distinguishes between construction status and solution status. Successful construction does not equate to successful illumination or HDR; the task summary retains the stage status and error reason for each.

[0075] For a task that exits abnormally for the first time, the runtime can restart the process and retry once with the original request; if it fails again, a failure status is returned. Retrying does not change the model, material, sky, sampling, or camera parameters in the request.

[0076] Offline Radiance benchmark results can be used for R&D verification, but are not written to the engine field of the Mitsuba run results. The calibration status and Radiance dependency fields of the runtime metadata are used to distinguish between online solutions and offline comparisons.

[0077] The above implementation forms a complete technical closed loop, encompassing input validation, object transformation, material sky modeling, illuminance / HDR solving, cache reuse, process isolation, error reporting, and metadata archiving. Table 1 illustrates how platform inputs are converted into Schema2 objects. Each output includes corresponding boundary records to avoid losing optical and geometric context by only saving images. Table 2 illustrates the request, response, and error status of isolated workflow processes.

[0078] Table 1 Schema 2 Input, Processing, and Output Correspondence

[0079] Table 2: Requests, Responses, and Error Statuses of the Isolation Process

[0080] In one implementation, input validation is performed before entering the native worker process. Vertex, triangle index, material library, sensor point, sensor normal, and camera fields must be convertible to explicit data types; missing or invalid fields are rejected by the main process to avoid passing incomplete requests to the CUDA runtime.

[0081] Schema 2 objects categorize platform data into five types: geometry, materials, sky, sensors, and cameras. Geometry and materials determine the scene structure, the sky determines the incident light environment, sensors define the illuminance sampling location and direction, and cameras define the viewing field of view for projected HDR. These five types of objects are associated with the same request identifier.

[0082] The vertex array uses 3D coordinates, and the triangle index uses three vertex indices. Material assignment can be provided for each triangle or a default material can be used. If a triangle index references a non-existent vertex, the adapter returns an error; if the material name is unsafe, an internal safe name is generated while preserving the face-level material mapping.

[0083] Material parameters are input from the platform's material state. The reflectivity of diffuse materials affects reflected light, the transmittance of glass and transmissive materials affects incoming light, roughness and specular components affect directional reflection, and refractive index affects interface refraction and reflection. The actual usable range is constrained by both the adapter and the solver.

[0084] Complex BSDF materials reference external BSDF descriptions via file paths and component names. The scene summary reads both the path and file content to ensure the cache key changes after a BSDF file is replaced. If no valid BSDF file exists, the system does not assume the missing file was successfully loaded as a complex material.

[0085] Glass layer transformation establishes optical objects based on visible light transmittance and layer parameters. The number of layers, coating reflectivity, coating emissivity, and refractive index of double-layered transparent glass and low-emissivity double-layered glass are recorded separately to facilitate the distinction between simple transparent glass and layered glass.

[0086] The analyzed sky and the image sky have different data inputs. The analyzed sky is calculated from date, time, location, and irradiance parameters; the image sky is input from calibrated HDR and camera orientation. The system writes the sky source into the result metadata to avoid omitting the brightness calibration of the image sky.

[0087] In the actual HDR implementation, the optical axis of the HDR image points vertically to the zenith, the top of the image is recorded at an angle relative to true north, and the edge areas are repaired or verified according to calibration parameters. If the HDR is not a hemispherical fisheye or absolute radiance calibration is not completed, the request will be marked as incomplete input.

[0088] The working face solution outputs illuminance on a per-sensor-point basis. The total illuminance is formed from components such as diffuse and direct sunlight according to the solver results; the platform does not deduce values ​​from the grid colors, but instead generates CSV, statistics, and color maps from the illuminance array.

[0089] The sensor normal length is normalized. For inputs that are zero vectors, non-finite values, or cannot be converted into three-dimensional vectors, the system returns a normal error. This processing ensures that the normal direction itself participates in the illuminance calculation, and arbitrary scaling of the vector does not change the computational semantics.

[0090] Projection mapping resolves the interface differences between the platform's camera projection identifier and Mitsuba projection types. Angular fisheye and hemispherical fisheye have different field-of-view semantics, and perspective and cylindrical projections also have different imaging ranges. The system selects the corresponding camera object based on the projection identifier.

[0091] HDR output uses RGBE encoding and includes software identifiers, projection view, and pixel aspect ratio information in the header. Before encoding, the pixel array dimensions, number of channels, and finiteness are checked; if invalid pixels are found, an error is returned, and an unresolvable HDR file is not written.

[0092] The cached summary is deterministic. The geometry array and triangle array are serialized in contiguous memory, the material states are serialized in order of stability keys, the BSDF path and file content are included in the summary, and the rendering settings are included in the summary separately. Finally, the scene is distinguished by the summary value.

[0093] When the sky changes, the sky object can be updated and invariant geometry and material structures can be reused. However, if a certain type of sky data has already been compiled into the scene structure, that sky data also needs to be included in the corresponding cache key. This rule ensures that cache reuse only occurs in physically invariant parts.

[0094] The isolated process handles the loading and execution of native components such as Mitsuba, Dr.Jit, and OptiX. The main process does not directly rely on exception handling in the native rendering process; instead, it obtains success or failure results through task files, thus limiting the impact of native exceptions to worker processes.

[0095] Persistent worker processes can handle multiple consecutive requests, but each request still uses an independent request and response path. Responses are written using a temporary file replacement method, and the main process only reads the results if the response file exists and the success flag is valid.

[0096] If a worker process times out and is terminated, the task reports a timeout error; if a worker process exits without writing a response, the task reports a no-response error; if the response cannot be deserialized, the task reports a response format error. These errors are not converted into zero-illuminance or empty HDR success results.

[0097] Metadata is used to audit actual operations. The engine identifier records the Schema 2 Mitsuba GPU experimental path, the quality level records the sampling and path parameters, the cache hit records whether the scene was reused, and the runtime Radiance dependency and calibration fields indicate whether Radiance was called.

[0098] The draft, standard, and high quality presets set the number of rendering samples, the number of mesh samples, and the maximum path depth, respectively. User-defined values ​​are limited to an allowed range when read to prevent invalid solutions from being too small or uncontrollable computational loads from being too large.

[0099] In the working surface illumination example, the platform transmits the sensor points generated on the reference surface to Mitsuba, returns an illumination array, and writes it to a CSV file by point number. The mesh map is generated using the same numbering and coordinates, allowing the user to return to the 3D working surface from the points in the CSV.

[0100] In the glare implementation, the platform first uses Mitsuba to render fisheye HDR, and then the glare evaluation process reads the HDR data to calculate DGP, DGI, or UGR. Mitsuba is responsible for image generation, while the glare evaluation is responsible for metric interpretation; both are associated in the same task context within the results directory.

[0101] In the continuous operation scenario, the scene cache can be reused when the model and materials remain unchanged but the date, sky, or time changes; when the model vertices, triangles, materials, BSDF, or rendering settings change, the cache summary is changed and rebuilt.

[0102] The acceleration effect of this invention is manifested in reducing the overhead of repeated calculations by utilizing GPU parallelism and caching when the same input semantics and sampling settings are met. The specific time consumption is affected by GPU model, driver, first compilation, scene complexity and output type, and no uniform numerical guarantee is made.

[0103] The Mitsuba path in the current platform is identified as an experimental path, and the annual matrix path remains in an experimental state; this implementation protects the combination of technologies between Schema 2 adaptation, material sky conversion, scene caching, isolation of working processes and state recording, and does not write incomplete coverage as a fait accompli.

[0104] When switching quality levels, the system re-parses the render sample count, mesh sample count, and maximum path depth, and writes the new render settings to the scene cache key. A change in quality level may result in a rebuild or re-execution, but it will not overwrite previous results.

[0105] For direct solar visibility and diffuse reflection paths, the solution results retain their respective constituent fields. Users can check whether the current result contains the direct solar item through metadata and point-by-point arrays, but cannot infer the calculated path based on the final color.

[0106] When the input material contains specular, metallic, or complex BSDF, the adapter retains the material type; if the current solver or input file cannot support the material, the system returns an explicit support boundary and continues to provide a result without prompting, without downgrading it to diffuse.

[0107] After the main process reads the worker process's response, it binds the result to the original request's project identifier and task identifier. Even if multiple tasks execute simultaneously, the response can only be written back to the directory of the task that sent the request.

[0108] If the GPU is unavailable but the user still selects Mitsuba, the platform reports unavailability or failure; the alternative engine path is only executed when the user selects another engine. This process keeps the user informed of the computation source.

[0109] Therefore, the acceleration method of the present invention does not rely on simplifying all architectural optical phenomena into a single empirical coefficient, but rather achieves a verifiable acceleration path through input adaptation, physical material objects, GPU solving, caching, and isolated execution.

[0110] In this embodiment, runtime dependency states are explicitly recorded as part of the metadata. If Mitsuba is unavailable, the CUDA variant is unavailable, or a worker process times out, the platform reports the corresponding status; the user can explicitly switch to another engine, but the system does not perform an unannounced rollback.

[0111] The current implementation boundaries include: the Mitsuba GPU path is identified as an experimental path in the platform; the annual matrix solution remains experimental; and the comprehensive verification of complex mirror systems, complex BSDFs, complex solar caustics, and different building types is not automatically inferred by this embodiment.

[0112] The present invention also proposes an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the Mitsuba-based method for accelerating architectural lighting environment simulation.

[0113] The memory in this application embodiment can be volatile memory or non-volatile memory, or it can include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the methods described in this invention is intended to include, but is not limited to, these and any other suitable types of memory.

[0114] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD), or a semiconductor medium (e.g., solid-state disk (SSD), etc.).

[0115] In implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are omitted here.

[0116] It should be noted that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiments can be completed by the integrated logic circuitry in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied as execution by a hardware decoding processor, or as a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above methods.

[0117] The foregoing has provided a detailed description of the Mitsuba-based method and system for accelerating architectural lighting environment simulation proposed in this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of these embodiments are merely for the purpose of helping to understand the method and its core ideas. Furthermore, those skilled in the art will recognize that, based on the ideas of this invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as limiting the invention.

Claims

1. A method for accelerating architectural lighting environment simulation based on Mitsuba, characterized in that, The method enables architectural geometry, materials, sky, work surfaces, and camera parameters from the platform to enter the Mitsuba GPU solver with unified data semantics, and isolates the native GPU runtime boundary from the main program; the method includes: Step 1: Receive platform scene data, including vertex verification, triangle index, material distribution status, working face sensor points, sensor normals, and camera parameters. Step 2: Create Schema 2 scene objects, convert platform materials into solver materials, convert CIE / Perez / measured HDR skies into analytical or image skies, and convert the working surface and observation camera into Mitsuba computable objects; Step 3: Read the number of rendering samples, the number of mesh samples, and the maximum path depth according to the quality level, and receive the user display parameters within the boundary range; Step 4, calculate the scene summary; the summary includes geometry, triangles, materials, BSDF files, and rendering settings; sky updates do not change the geometry and material cache keys; Step 5: Build or reuse the Pure GPU scene in the isolated working process, and perform working surface illuminance or projection HDR solution respectively; Step 6: Write the illumination array, HDR pixels, statistics, time consumption, cache hits, and engine status back to the main program, and generate a file that can be displayed and saved by the platform according to the result type.

2. The method according to claim 1, characterized in that, The Schema 2 scene objects include at least a geometric mesh, triangle material assignment, material library, sky model, working face sensor points, sensor normals, camera position, camera target point, camera up direction, and camera projection parameters.

3. The method according to claim 1, characterized in that, Material conversion supports at least one of diffuse, glass, specular, metallic, transmissive, and complex BSDF, and reads at least one of reflectivity, transmissivity, roughness, specular component, refractive index, glass layer parameters, thermal emissivity, and BSDF file path; if the material is transparent, transparent material conversion includes at least one of single-layer transparent glass, double-layer transparent glass, and low-emissivity double-layer glass, and forms a material object that can be used for optical transmission calculation based on normal transmittance, front and rear surface reflectivity, refractive index, thickness, and coating parameters; sky conversion supports CIE uniform sky, CIE cloudy sky, CIE sunny sky, Perez sky, and hemispherical fisheye HDR sky calibrated with absolute radiance; Perez sky reads direct normal irradiance and horizontal diffuse irradiance, and measured sky reads the top azimuth and edge calibration information of the image.

4. The method according to claim 1, characterized in that, The solution for working face illuminance normalizes the sensor normal and outputs arrays of total illuminance, diffuse illuminance, and direct solar illuminance for each sensor point, while also outputting the solution time and grid statistics.

5. The method according to claim 1, characterized in that, Projection HDR rendering maps the platform projection identifier to one of angled fisheye, hemispherical fisheye, stereoscopic projection, perspective, or cylindrical projection, and encodes the pixel results as RGBE HDR, while recording the projection type, field of view, number of samples, and engine identifier.

6. The method according to claim 1, characterized in that, The cache key in the scene consists of a geometry data summary, a triangle data summary, a material state summary, a BSDF file path and file content summary, and a rendering settings summary. When the cache is hit, the sky object is updated and the scene acceleration structure is reused. When the cache is not hit, a new scene acceleration structure is created and the number of cache entries is limited. The scene acceleration structure is the solver's internal structure, which is jointly determined by geometry, materials, and solver settings and can be reused for multiple requests.

7. The method according to claim 1, characterized in that, Mitsuba runs natively in a separate child process. The main process passes tasks through request and response files or persistent worker processes. When a worker process exits abnormally, a pipe is closed, a timeout occurs, or an invalid response is returned, the error status is logged and Mitsuba is reported as having failed. Results from other engines are not marked as successful by Mitsuba.

8. The method according to claim 1, characterized in that, The platform can display metadata that records at least the Mitsuba Schema version, cuda_ad_rgb variant, quality level, number of render samples, number of mesh samples, maximum path depth, scene cache hit status, solution time, runtime Radiance dependency status, and calibration status.

9. A Mitsuba-based architectural lighting environment simulation acceleration system, characterized in that, The system enables architectural geometry, materials, sky, work surfaces, and camera parameters from the platform to be input into the Mitsuba GPU solver with unified data semantics, and isolates the native GPU runtime boundary from the main program; the system includes: The receiving module receives platform scene data, including verification vertices, triangle indices, material distribution status, working face sensor points, sensor normals, and camera parameters. The conversion module creates Schema 2 scene objects, converts platform materials into solver materials, converts CIE / Perez / measured HDR skies into analytical or image skies, and converts working surfaces and observation cameras into Mitsuba computable objects. The reading module reads the number of rendering samples, the number of mesh samples, and the maximum path depth according to the quality level, and receives user display parameters within the boundary range; The calculation module calculates a scene summary; the summary includes geometry, triangles, materials, BSDF files, and rendering settings; sky updates do not change the geometry and material cache keys; The isolated worker process module builds or reuses Pure GPU scenes within the isolated worker process, and performs the solution of worker surface illuminance or projection HDR respectively; The HDR / illuminance output module writes the illuminance array, HDR pixels, statistics, time consumption, cache hits, and engine status back to the main program, generating displayable and savable files based on the result type.

10. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1-8.

Images