A layered scheduling method of a virtual scene rendering task
Patent Information
- Application Number
- CN202611233112.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-14
- Publication Date
- 2026-10-13
AI Technical Summary
具体表现为:已经下发但尚未完成的纹理、网格、阴影图或缓存加载请求,在后续渲染周期中可能因重新判断资源未驻留而被重复下发;被遮挡对象或者边缘区域对象在不同渲染周期中可能反复在延后、降级和重新加载之间切换;上一周期未完成的资源准备任务可能与本周期新进入主视区的即时渲染任务竞争调度位置,导致主视区对象的绘制任务被非关键任务挤占;上一周期已经完成的缓存结果可能因缺少资源版本和显示窗口版本的统一比对而无法稳定复用;连续延后任务缺少统一计数和回写口径,容易使同一对象的模型层级、纹理状态或者缓存使用状态在连续帧中反复变化
[0046]1、通过在当前渲染周期内采集视角输入、视锥范围、屏幕分区、场景层级节点和图形资源驻留状态,并读取上一渲染周期调度反馈记录,再将上述记录绑定为当前周期调度基准帧,对渲染任务形成主视区即时任务、边缘区降级任务、遮挡区延后任务、资源准备任务和上一周期补偿任务,并进一步生成包含完整执行、降级执行、延后执行、结果复用、资源预驻留和禁止重复下发的分层调度策略,从而达到在相邻渲染周期之间继承任务状态和资源状态、区分当前可视任务与历史未完成任务、避免纹理加载任务重复下发、减少主视区渲染任务被非关键任务挤占的效果。
Smart Images

Figure CN122903149A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of virtual scene rendering technology, specifically a hierarchical scheduling method for virtual scene rendering tasks. Background Technology
[0002] With the development of applications such as virtual exhibition halls, digital twin scenes, online 3D displays, immersive tours, and virtual training, the number of graphics resources that need to be processed simultaneously in virtual scenes, including models, textures, lighting, shadows, reflections, and post-processing caches, is increasing. To keep the screen refreshed as the user's viewpoint moves continuously, existing virtual scene rendering systems typically organize and schedule rendering tasks within each frame or rendering cycle, based on information such as the current camera position, camera orientation, view frustum, screen display area, scene object hierarchy, and whether resources are already resident. For example, objects located in the center of the view or the main view area are usually prioritized for geometry drawing and basic texture usage tasks; objects located at the screen edge or with low visual attention may be processed using low-precision textures, simplified meshes, or cache reuse; occluded or temporarily invisible objects may be submitted later; and resources such as textures, meshes, shadow maps, and reflection caches that have not yet been loaded into video memory or system memory may be added to the resource loading queue.
[0003] The above methods can organize rendering tasks based on the current screen state to some extent, but their scheduling basis is usually concentrated on the immediate visibility state, object priority, resource dwell state, or device load state of the current rendering cycle. For continuous roaming scenes, the viewpoint, occlusion relationship, resource loading progress, and task completion status will continuously change between adjacent rendering cycles. The tasks that need to be processed in the current cycle are not entirely newly generated tasks, but also include resource loading tasks that were issued but not yet completed in the previous cycle, tasks that were downgraded in the previous cycle due to edge display, tasks that were delayed in the previous cycle due to occlusion, and tasks that were prohibited from being issued again in the previous cycle but still need to continue to track the completion status. If the existing scheduling process only re-determines whether the task is visible, whether the resource is dwell, or whether it needs to be loaded based on the current cycle, without continuing to pass on information such as the issuance status, completion status, downgrade method, reason for not executing, number of consecutive delays, and prohibition of repeated issuance flags from the previous rendering cycle as inheritable scheduling boundaries, it is easy to cause the current cycle's tasks and historical legacy tasks to be mixed together.
[0004] Therefore, in the continuous rendering of large-scale virtual scenes, existing technologies still suffer from unclear task state boundaries between adjacent rendering cycles. Specifically, this manifests as follows: texture, mesh, shadow map, or cache loading requests that have been issued but not yet completed may be repeatedly issued in subsequent rendering cycles due to reassessment of resource non-resident status; occluded objects or edge area objects may repeatedly switch between delayed, degraded, and reloaded states in different rendering cycles; resource preparation tasks not completed in the previous cycle may compete for scheduling positions with real-time rendering tasks newly entering the main viewport in the current cycle, causing the rendering tasks of main viewport objects to be squeezed out by non-critical tasks; cached results completed in the previous cycle may not be reusable stably due to the lack of a unified comparison between resource versions and display window versions; and the lack of a unified counting and write-back standard for continuously delayed tasks can easily cause the model level, texture state, or cache usage state of the same object to change repeatedly in consecutive frames. These problems affect the stability of rendering task scheduling, the orderliness of resource requests, and the consistency of the image state during continuous virtual scene navigation. Summary of the Invention
[0005] To address the shortcomings of existing technologies, this invention provides a hierarchical scheduling method for virtual scene rendering tasks, thereby resolving the problems mentioned in the background section.
[0006] To achieve the above objectives, the present invention provides the following technical solution: a hierarchical scheduling method for virtual scene rendering tasks, comprising:
[0007] S1. Collect the view input, view frustum, screen partition, scene level nodes, and graphics resource dwell status of the current rendering cycle, and read the scheduling feedback record of the previous rendering cycle.
[0008] S2. Bind the view input, view frustum range, screen partition, scene level node, graphics resource dwell status, and scheduling feedback record of the previous rendering cycle to the current cycle scheduling base frame.
[0009] S3. Based on the current cycle scheduling reference frame, the rendering tasks are layered into tasks such as the main view area immediate task, the edge area degraded task, the occluded area delayed task, the resource preparation task, and the previous cycle compensation task.
[0010] S4. Based on the task layering results, graphics resource resident status, and scheduling feedback records from the previous rendering cycle, generate a layered scheduling strategy that includes full execution, degraded execution, delayed execution, result reuse, resource pre-resident, and prohibition of repeated delivery.
[0011] S5. Execute the hierarchical scheduling strategy, collect task completion status, actual time consumption, resource residency changes, degradation method, and reasons for non-execution, and form the current cycle execution feedback record;
[0012] S6. Write the current cycle execution feedback record into the scheduling feedback record, generate the next rendering cycle scheduling boundary version, and provide it for the next rendering cycle scheduling reference frame to read.
[0013] Furthermore, S1 includes:
[0014] Between the start point of data acquisition and the point where the screen task is submitted, the rendering control process acquires the viewpoint input, view frustum, screen partition, scene level nodes, and graphics resource dwell status in a fixed order, and reads the scheduling feedback record of the previous rendering cycle.
[0015] Records that arrive after the task submission point are not included in the current collection set.
[0016] The previous rendering cycle scheduling feedback record uses the previous rendering cycle number, the previous scheduling boundary version number, and the scene version number as the reading index;
[0017] The collected and read records are written to the collection record area, and a unique deduplication key is formed using the current rendering cycle number, scene version number, rendering device identifier, and collection start point. After writing, the collection record version number and record summary are generated.
[0018] Furthermore, S2 includes:
[0019] After the current rendering cycle acquisition record is written and before the task layering begins, the rendering control process reads the view input, view frustum, screen partition, scene level nodes, graphics resource resident status and previous rendering cycle scheduling feedback record from the acquisition record area according to the current rendering cycle number, scene version number, rendering device identifier and acquisition record version number.
[0020] Bind the read content to the current period scheduling baseline frame and generate the baseline frame version number; when the read content does not have a pending verification status, a pending supplement status, or a version inconsistency status, write a complete readable tag.
[0021] Furthermore, S3 includes:
[0022] The rendering control process reads the current cycle scheduling base frame with a fully readable tag;
[0023] Rendering tasks are formed based on scene hierarchy nodes, object resource reference relationships, and graphics resource resident status; the image projection range is formed based on the spatial enclosure range of scene hierarchy nodes;
[0024] Based on screen partitions, view frustum range, image projection range, and graphics resource dwell status, rendering tasks are registered as main view area immediate tasks, edge area degraded tasks, occluded area delayed tasks, and resource preparation tasks.
[0025] Write the task identifier, task category, and summary of the record based on the task hierarchical record area to form a task hierarchical record with complete registration status.
[0026] Furthermore, S3 also includes:
[0027] When the scene object identifier in the scheduling feedback record of the previous rendering cycle is consistent with the scene object identifier of the current rendering task, and the task identifier corresponds to the task identifier of the current rendering task, the compensation task of the previous cycle is formed based on the completion status, distribution status, resource residency changes, degradation method, number of consecutive delays and the prohibition of repeated distribution flag.
[0028] The same task identifier determines the task category in the following order: previous cycle compensation task, main view area immediate task, resource preparation task, edge area downgrade task, and occlusion area delayed task.
[0029] Furthermore, S4 includes:
[0030] The rendering control process reads the task layer record with complete registration status;
[0031] Read the resource dwell status and the scheduling feedback record of the previous rendering cycle from the current cycle scheduling baseline frame. The resource dwell status is the same as the standard used in the strategy generation stage for graphics resource dwell status.
[0032] Based on the task category, resource residency status, and scheduling feedback records from the previous rendering cycle, generate complete execution, degraded execution, delayed execution, result reuse, and resource pre-residency policy items according to the task identifier, and write the policy items into the hierarchical scheduling policy record area to form a hierarchical scheduling policy with complete policy status.
[0033] Furthermore, S4 also includes:
[0034] If the previous rendering cycle scheduling feedback record shows that the same task identifier has been issued and the resource residency status shows that the resource loading request completion status is not completed, then register the policy item to prohibit duplicate issuance.
[0035] The same task identifier determines the strategy items in the following order: prohibiting duplicate issuance, complete execution, result reuse, resource pre-retention, degraded execution, and delayed execution.
[0036] Furthermore, S5 includes:
[0037] The rendering control process reads the hierarchical scheduling policy with complete policy state from the hierarchical scheduling policy record area;
[0038] Between the start and end of the current rendering cycle, the corresponding task is executed according to the strategy item name.
[0039] Collect task completion status, actual time consumed, resource retention changes, degradation method and reason for non-execution, form current cycle execution feedback record and write it into the current cycle execution feedback record area to form current cycle execution feedback record with complete feedback status;
[0040] Graphics command receipts, resource loading receipts, and cache read receipts that arrive after the execution deadline of the current cycle's rendering task will not rewrite the current cycle's execution feedback record.
[0041] Furthermore, S6 includes:
[0042] The rendering control process reads the current cycle execution feedback record with complete feedback status according to the current rendering cycle number, scene version number, rendering device identifier and base frame version number;
[0043] Write the task completion status, resource residency changes, degradation method, and reason for non-execution from the current period execution feedback record into the scheduling feedback record;
[0044] Based on the scheduling feedback records and the scheduling boundary version of the previous rendering cycle, determine the number of consecutive delays and the prohibition of repeated issuance flag according to the task identifier, and generate the scheduling boundary version of the next rendering cycle with complete boundary state.
[0045] Compared with the prior art, the present invention has the following beneficial effects:
[0046] 1. By collecting viewpoint input, view frustum, screen partition, scene hierarchy nodes, and graphics resource resident status within the current rendering cycle, and reading the scheduling feedback record of the previous rendering cycle, and then binding the above records as the current cycle scheduling base frame, the rendering tasks are divided into immediate tasks in the main view area, degraded tasks in the edge area, delayed tasks in the occluded area, resource preparation tasks, and compensation tasks from the previous cycle. Furthermore, a hierarchical scheduling strategy is generated, which includes full execution, degraded execution, delayed execution, result reuse, resource pre-resident, and prohibition of repeated issuance. This achieves the effects of inheriting task status and resource status between adjacent rendering cycles, distinguishing between currently visible tasks and historical unfinished tasks, avoiding repeated issuance of texture loading tasks, and reducing the crowding out of main view area rendering tasks by non-critical tasks.
[0047] 2. After executing the hierarchical scheduling strategy, the task completion status, actual time consumption, resource residency changes, degradation methods, and reasons for non-execution are collected to form the current cycle execution feedback record. The current cycle execution feedback record is written into the scheduling feedback record to generate the scheduling boundary version for the next rendering cycle. This version is then read by the scheduling baseline frame for the next rendering cycle. This ensures that delayed execution tasks, prohibited repeated task issuance, resource pre-residency tasks, and result reuse tasks have clear reading criteria and update boundaries in subsequent rendering cycles, reducing repeated judgments of resource status, repeated task generation, and repeated jumps in model hierarchy in consecutive frames. Attached Figure Description
[0048] Figure 1 This is a diagram combining a schematic diagram of a scenario-based device and a data acquisition flowchart;
[0049] Figure 2 A schematic diagram illustrating the binding of the current cycle scheduling reference frame and the formation of a complete readable tag;
[0050] Figure 3 This is a schematic diagram illustrating the formation and layering of the current cycle's rendering tasks.
[0051] Figure 4 This is a diagram illustrating the formation and exclusive categories of compensation tasks for the previous cycle.
[0052] Figure 5 This is a schematic diagram illustrating the generation of hierarchical scheduling strategies and the exclusivity of strategy items;
[0053] Figure 6 This diagram illustrates the execution of the hierarchical scheduling strategy and the feedback record of the current cycle execution.
[0054] Figure 7 This is a schematic diagram of the closed loop for writing scheduling feedback records and writing back to the next cycle boundary version. Detailed Implementation
[0055] 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.
[0056] Example: Combined with Appendix Figures 1-7 This embodiment provides a hierarchical scheduling method for virtual scene rendering tasks, including:
[0057] S1. Collect the viewpoint input, view frustum, screen partition, scene hierarchy nodes, and graphics resource resident status of the current rendering cycle, and read the scheduling feedback record of the previous rendering cycle. The specific implementation is as follows:
[0058] Between the start of the current rendering cycle and the submission point of the rendering task, the rendering control process acquires the viewpoint input, view frustum, screen partition, scene level nodes, and graphics resource resident status in a fixed order, and reads the scheduling feedback record of the previous rendering cycle. The current rendering cycle is a complete time period from the preparation and organization of a virtual scene to the submission of the rendering task. The start of the acquisition is determined by the timestamp of the rendering control process issuing the acquisition command for this cycle, and the submission point of the rendering task is determined by the timestamp of the first time the rendering task of this cycle enters the rendering command submission queue. Records that arrive later than the submission point of the rendering task are not included in the acquisition set for this cycle.
[0059] The viewpoint input comes from one of the following: camera controller, head-mounted display device attitude acquisition unit, or roaming controller. It records the camera position, camera orientation, observation center, field of view, near clipping plane, and far clipping plane. The camera position uses length units in the unified coordinate system of the virtual scene, the camera orientation and field of view use angle units, the observation center uses coordinate points in the unified coordinate system of the virtual scene, and the near clipping plane and far clipping plane use length units. When there are multiple viewpoint records within the same acquisition period, they are first merged into the current rendering cycle according to the device timestamp. Then, records with timestamps earlier than the acquisition start point or later than the screen task submission point are removed. The record closest to the screen task submission point is then selected as the viewpoint input for this cycle. If there are records with the same timestamp, the record with the smaller device number is selected. Records that are not selected are only used as evidence for the chain of evidence.
[0060] When the field of view, near clipping plane, or far clipping plane is missing in the view input, it can be filled in from the currently effective scene configuration version; when the camera position, camera orientation, or observation center is missing, it should not be filled in automatically, and the collection record of this cycle will be transferred to the record area to be checked, and the name of the missing field, the collection start point, and the screen task submission point will be marked.
[0061] The view frustum is formed based on the viewpoint input already determined in this cycle, recording the near clipping boundary, far clipping boundary, left boundary, right boundary, top boundary, and bottom boundary. Each boundary is recorded using the direction and position caliber under the unified coordinate system of the virtual scene. The view frustum is formed only using the viewpoint input of this cycle, without referencing the viewpoint records of the previous rendering cycle or the viewpoint records after the screen task submission point. If the near clipping plane is larger than the far clipping plane or the field of view is not within the allowable range of the current scene configuration version, the formation of the view frustum will stop, and the acquisition record of this cycle will be transferred to the record area to be verified.
[0062] Screen partitioning is obtained based on the projection range of the view frustum in the current period onto the screen display area. The screen display area uses a pixel coordinate system with the upper left corner as the origin. The partition names, boundary coordinates, and display window versions of the center area, transition area, and edge area are recorded. The center area, transition area, and edge area are only used as the screen area scope for the current period and do not form a task layering conclusion in this step. If the display window version is inconsistent with the device display version bound to the current rendering period, the display window version is read again. If it is still inconsistent, the screen partition field is marked as pending supplementation and will not continue to be overwritten by the old display window version.
[0063] Scene-level nodes are obtained from the currently active scene resource management record. If the scene resource management record is unreadable, they are then obtained from the currently active scene project file. If both exist, the scene resource management record takes precedence. Scene-level nodes include scene object identifier, parent node identifier, child node identifier, spatial enclosing range, object visibility switch, and object resource reference relationship. When reading, the currently active nodes are first filtered according to the scene version number, and then nodes marked as deleted by the scene version are removed. Subsequently, they are merged according to the scene object identifier. Nodes with the same display name but different scene object identifiers cannot be merged. Nodes with missing scene object identifiers are entered into the pending record area and are not included in the scene-level node set for this period.
[0064] The graphics resource resident status is obtained from the rendering resource manager, geometry cache table, texture cache table, shadow map cache table, and post-processing cache table, recording the resource identifier, resource type, scene object identifier, video memory resident status, system memory resident status, resource loading request issuance status, resource loading request completion status, and resource version number. The geometry cache status is confirmed by whether the mesh resource has a cache that can submit drawing commands; the texture resident status is confirmed by whether the texture resource has been uploaded; the shadow map status is confirmed by whether the shadow cache corresponding to the light source exists; and the post-processing cache status is confirmed by whether the screen cache exists and belongs to the current display window version.
[0065] When organizing the residency status of graphics resources, they are first merged by resource identifier, then filtered by resource version number, and finally associated with scene-level nodes by their respective scene object identifier. If resource path, resource size, or resource format is missing, it can be supplemented from the current scene resource list. Resource identifier, resource version number, video memory residency status, and resource loading request distribution status should not be automatically supplemented. When the same resource identifier has multiple statuses within the same acquisition period, the status closest to the screen task submission point is selected. If the timestamps are the same, the record for this period is determined in the order of video memory residency status taking precedence over system memory residency status, and completion status taking precedence over distribution status.
[0066] The scheduling feedback record of the previous rendering cycle is read from the scheduling record area. The reading index is the previous rendering cycle number, the previous scheduling boundary version number, and the scene version number, all of which must match simultaneously. The reading content includes task identifier, scene object identifier, task level, resource identifier, resource version number, issuance status, completion status, resource residency changes, reason for non-execution, degradation method, actual time consumption, number of consecutive delays, and a flag prohibiting duplicate issuance. Records with missing task identifiers or scene object identifiers are entered into the record area to be verified. When the flag prohibiting duplicate issuance is missing, it must not be marked as not prohibited by default, but must be marked as pending verification. If there is no scheduling feedback record of the previous rendering cycle in the first rendering cycle, an empty feedback record is generated. The empty feedback record only contains an empty previous rendering cycle number, an empty previous scheduling boundary version number, the scene version number, and the first cycle flag, without filling in the task status field.
[0067] After the above is completed, the current rendering cycle number, scene version number, rendering device identifier, acquisition start point, and screen task submission point are used as the minimum submission fields. The view input, view frustum range, screen partition, scene level node, graphics resource resident status, and scheduling feedback record of the previous rendering cycle are written into the acquisition record area. The rendering device identifier is the device number registered in the rendering system of the rendering workstation, cloud rendering node, or browser rendering container that performed the acquisition action in this cycle. If it is missing, the acquisition record of this cycle cannot be submitted.
[0068] The collection records are appended, and old versions are not overwritten. The same current rendering cycle number, scene version number, rendering device identifier, and collection start point form a unique deduplication key. When submitting repeatedly, only the first complete record is retained, and subsequent repeated records are written to the repeated submission trace area. When multiple rendering devices collect the same scene concurrently, they are first written according to the rendering device identifier, and then archived according to the scene version number and the current rendering cycle number. Fields are not merged across devices.
[0069] After each field is written, a collection record version number, record summary, write timestamp, and write operator identifier are generated as evidence chains. The collection record version number is determined by the current rendering cycle number, scene version number, rendering device identifier, collection start point, and write timestamp. The same collection record version number corresponds to the same complete collection record. The record summary is generated by the record number, collection record version number, write timestamp, and field completeness marker. It is only used to confirm that the record has not been overwritten and does not participate in subsequent task layering.
[0070] When a read operation is interrupted, retries are allowed for the same record source. If the retries still fail, the fields that have been obtained, along with the source of the failure, are written to the record area to be verified. The current fields are not replaced by the records from the previous complete cycle. Both the record area to be verified and the record area to be supplemented can be supplemented by maintenance personnel or the resource organization process, but the supplemented records must form a new version of the collected records and must not overwrite the original collected records.
[0071] This step only collects the virtual scene rendering status, device rendering status, and resource residency status. It does not collect user identity information, voice content, or business privacy information. The pose information generated by the head-mounted display device is only written as viewpoint input and is not associated with personal identity records.
[0072] Preferably, in the virtual exhibition hall roaming scene, the current rendering cycle can be set to 16.7 milliseconds, the view input acquisition interval can be set to 1 millisecond, the position recording accuracy can be set to 0.01 meters, the orientation recording accuracy can be set to 0.1 degrees, the field of view can be set to 60 degrees to 110 degrees, the near clipping plane can be set to 0.1 meters, the far clipping plane can be set to 500 meters, the center area can be set to 60% of the screen width, the transition area can be set to 25% of the screen width, the edge area can be set to 15% of the screen width, the single-cycle acquisition and recording write latency can be controlled within 3 milliseconds, and if reading the scheduling feedback record of the previous rendering cycle fails, it can be retried 2 times, with a retry interval of [missing information]. Set to 2 milliseconds, 30 cycles are selected from 300 consecutive rendering cycles to verify the acquisition start point, screen task submission point, scene version number, resource version number, and previous scheduling boundary version number, with a version matching rate of no less than 99%. For example, in a certain cycle, the camera is located at the coordinate point of the exhibition hall entrance, facing the main display case. The main display case texture resource loading request has been issued but has not yet been uploaded. This step records the view input, view frustum range, screen partition, scene level nodes, and graphics resource dwell status of this cycle, and reads the prohibition of repeated issuance of the texture task in the previous rendering cycle to form an acquisition record with the same version caliber, which is used by the next step to form the current cycle scheduling baseline frame.
[0073] Alternatively, the view input can come from a trackball controller or an automatic cruise camera, the graphics resource dwell status can come from the engine's internal resource table or the driver layer resource receipt, and the scene-level nodes can come from a pre-compiled scene list. As long as the view input, view frustum, screen partition, scene-level nodes, graphics resource dwell status, and the scheduling feedback record of the previous rendering cycle are formed with the same name, the same order, the same padding boundaries, and the same version caliber as in this step, they belong to the same implementation method.
[0074] S2. Bind the view input, view frustum, screen partition, scene hierarchy nodes, graphics resource dwell state, and scheduling feedback record of the previous rendering cycle to the current cycle scheduling base frame. The specific implementation is as follows:
[0075] After the current rendering cycle's acquisition record is written and before the task layering for this cycle begins, the rendering control process reads the same current rendering cycle number, scene version number, rendering device identifier, and acquisition record version number from the acquisition record area, including view input, view frustum, screen partition, scene level nodes, graphics resource resident status, and scheduling feedback records from the previous rendering cycle. These are then bound to the current cycle's scheduling baseline frame in the above fixed order. The acquisition record version number is generated when the acquisition record area is appended in the previous step, representing the unique effective version of the acquisition record for this cycle. The current step only reads records already written within this version, without re-acquiring on-site data, modifying the original fields in the acquisition record area, or replacing already written acquisition records with later records.
[0076] When binding, the field inputs for camera position, camera orientation, observation center, field of view, near clipping plane, and far clipping plane are maintained. The camera position and observation center continue to use the length unit under the unified coordinate system of the virtual scene, while the camera orientation and field of view continue to use the angle unit. Before binding, the current rendering cycle number, acquisition start point, screen task submission point, and acquisition record version number of the view input are checked to ensure they are consistent with the current reading conditions. If any item is inconsistent, the formation of a complete and readable current cycle scheduling reference frame is stopped, the binding record is written to the record area to be checked, and the names of the inconsistent fields are recorded.
[0077] When binding the view frustum, the boundary record calibers of the near clipping boundary, far clipping boundary, left boundary, right boundary, top boundary, and bottom boundary are maintained. Before binding, the view frustum's registered view input record summary is checked to ensure consistency with the view input record summary read this time. The record summary is generated by the record number, acquisition record version number, writing timestamp, and field completeness marker. It is used to confirm that the bound record has not been replaced and is not used as the basis for judging the content of the rendering task. If the two are inconsistent, the view frustum is not re-formed, and the subsequent view change is not referenced. Instead, a version to be checked is directly formed.
[0078] When binding screen partitions, the partition names, boundary coordinates, and display window versions of the central area, transition area, and edge area are maintained. Before binding, it is checked whether the display window version of the screen partition is consistent with the display window version corresponding to the current rendering device identifier. If the display window version is marked as to be supplemented, the current cycle scheduling reference frame can only generate the version to be supplemented. The version to be supplemented is stored in the scheduling reference frame recording area as a trace record, but without a complete readable mark, and is not handed over to the next stage as a basis for task layering.
[0079] When binding scene-level nodes, the scene object identifier, parent node identifier, child node identifier, spatial enclosure range, object visibility switch, and object resource reference relationship are maintained. Before binding, the node set is checked according to the scene version number to see if it comes from the same scene resource management record or the same scene project file. If there are cases where the scene object identifier is missing, the same scene object identifier corresponds to multiple parent node identifiers, or the spatial enclosure range is missing and not marked as to be supplemented in the collection record area, a complete and readable version will not be formed. Nodes with the same display name but different scene object identifiers will remain separate and will not be merged.
[0080] When binding graphics resources, the resource resident status should retain the resource identifier, resource type, scene object identifier, video memory resident status, system memory resident status, resource loading request issuance status, resource loading request completion status, and resource version number. Before binding, the graphics resource resident status should be associated with the scene-level node that has already been read according to the scene object identifier. If any of the resource identifier, resource version number, video memory resident status, or resource loading request issuance status is missing, the corresponding resource record should not be entered into a complete readable version, and the resource identifier should not be replaced by the resource path, resource name, or cache name. When the same resource identifier corresponds to multiple resource version numbers, only the resource version number that has been confirmed in the collection record should be used, and the resident status should not be re-determined in this step.
[0081] When binding, the previous rendering cycle scheduling feedback record should retain the task identifier, scene object identifier, task level, resource identifier, resource version number, distribution status, completion status, resource residency changes, reason for non-execution, degradation method, actual time consumption, number of consecutive delays, and the prohibition of duplicate distribution flag. Before binding, verify that the previous rendering cycle number, previous scheduling boundary version number, and scene version number are consistent with the read index in the collection record. If the three are inconsistent, other cycle feedback records should not be used to replace them. When the first rendering cycle corresponds to an empty feedback record, the empty feedback record can be bound, but only the previous rendering cycle number is empty, the previous scheduling boundary version number is empty, the scene version number, and the first cycle flag should be retained. The task status field should not be filled in. When the prohibition of duplicate distribution flag is in the pending verification state, the feedback record should be retained as the pending verification caliber along with the current cycle scheduling baseline frame and should not be automatically changed to the non-prohibited state.
[0082] After all the above records have been verified, the rendering control process writes the view input, view frustum range, screen partition, scene level node, graphics resource dwell status, and scheduling feedback record of the previous rendering cycle into the current cycle scheduling reference frame. The current cycle scheduling reference frame saves the bound content of the above records and includes at least the current rendering cycle number, scene version number, rendering device identifier, acquisition record version number, view input record summary, view frustum range record summary, screen partition record summary, scene level node record summary, graphics resource dwell status record summary, previous rendering cycle scheduling feedback record summary, reference frame generation timestamp, reference frame version number, and complete readable marker. The complete readable marker is only written when none of the above records are in a pending verification state, a pending supplementation state, or a version inconsistency state. The complete readable marker, complete registration state, complete strategy state, complete feedback state, and complete boundary state appearing in this application all indicate that the corresponding record has all the necessary fields required in this step, is consistent in version, is not in a pending verification state, is not in a pending supplementation state, and can be read by the next stage. Records without the above complete states are only used as a basis for record keeping or supplementation and do not enter the next stage.
[0083] The current cycle scheduling baseline frame is stored in the scheduling baseline frame record area in an append-only manner. Old versions must not be overwritten. The same current rendering cycle number, scene version number, rendering device identifier, and acquisition record version number constitute a unique deduplication key. When binding repeatedly, only the first complete and readable version is retained, and subsequent repeated binding records are written to the repeated binding trace area. If the first binding results in a version to be verified, a new baseline frame version number is generated when it is re-bound after being completed. The original version to be verified continues to be retained and is not overwritten.
[0084] When multiple rendering devices concurrently form the current cycle scheduling baseline frame, they are saved separately according to the rendering device identifier, without merging view input, graphics resource dwell status, or scheduling feedback records from the previous rendering cycle across devices.
[0085] If any necessary record is missing during the binding process, the rendering control process does not replace the current record with the previous complete cycle record, nor does it generate a complete and readable version using the default view, default resource status, or default feedback status. Instead, it generates a version to be verified and specifies the name of the missing record, the current rendering cycle number, the scene version number, the rendering device identifier, and the acquisition record version number. This version to be verified is only used for record keeping and supplementary recording and is not given to the next stage for reading.
[0086] When binding fails, the same collection record version number can be reread and retried. If the retry still fails, a complete readable version will no longer be generated, and the already formed version to be verified will be retained in the scheduling baseline frame record area.
[0087] Once the current cycle scheduling reference frame is formed, the next step can only read the current cycle scheduling reference frame with complete readable markers according to the reference frame version number, and no longer read scattered fields from the acquisition and recording area separately; the security boundary of this step is limited to binding only the virtual scene rendering state, device rendering state, resource dwell state and the scheduling feedback record of the previous rendering cycle. The pose information generated by the head-mounted display device is only entered into the current cycle scheduling reference frame as a viewpoint input record summary and is not associated with personal identity records.
[0088] Preferably, in the virtual exhibition hall roaming scene, the generation delay of the current cycle scheduling benchmark frame can be set to within 2 milliseconds. A single current cycle scheduling benchmark frame can bind 10,000 scene-level nodes and 50,000 graphics resource dwell status records. If the binding fails, it can be retried once, and the retry interval can be set to 1 millisecond. 30 current cycle scheduling benchmark frames are extracted from 300 consecutive frames to check the current rendering cycle number, scene version number, rendering device identifier, acquisition record version number, and previous scheduling boundary version number. The field consistency rate is not less than 99%. For example, if the acquisition record corresponding to the exhibition hall entrance view has already obtained the view input, view frustum range, screen partition, scene-level nodes, graphics resource dwell status, and previous rendering cycle scheduling feedback record of the main display case, then this step binds these records to the same benchmark frame version. If the resource version number of the main display case texture resource is missing, the benchmark frame can only generate a version to be checked and cannot use the resource name to replace the resource version number.
[0089] Alternatively, the current cycle scheduling reference frame can be stored in a local memory table, a cloud shared record area, or a browser rendering container's session record area. The record summary can be formed by a file summary, a memory block summary, or a record sequence number. As long as the view input, view frustum range, screen partition, scene level nodes, graphics resource dwell status, and the previous rendering cycle scheduling feedback record are still bound to the current cycle scheduling reference frame with the same name, the same order, and the same version caliber as in this step, it belongs to the same implementation method.
[0090] S3. Based on the current cycle scheduling reference frame, the rendering tasks are layered into tasks for the main view area (immediate), edge area (degraded), occluded area (delayed), resource preparation, and previous cycle compensation. The specific implementation is as follows:
[0091] After the rendering control process reads the current cycle scheduling reference frame with complete readable tags, it forms rendering tasks according to the scene level nodes, screen partitions, view frustum, graphics resource dwell status, and previous rendering cycle scheduling feedback records in the current cycle scheduling reference frame between the start of the current cycle task layering and the submission of the task layering record. The rendering tasks are then registered as main view area immediate tasks, edge area degradation tasks, occlusion area delayed tasks, resource preparation tasks, and previous cycle compensation tasks. The rendering tasks originate from the current cycle scheduling reference frame and are not reread from the acquisition record area. They do not reference temporary camera states, temporary resource states, or temporary occlusion records outside the current cycle scheduling reference frame. The task identifier of the rendering task is formed by scene object identifier, resource identifier, resource version number, and task name in a fixed order. Basic geometry drawing tasks without associated resources form task identifiers with scene object identifiers and task names. Only one record is formed for the same task identifier under the same reference frame version number.
[0092] When a rendering task is generated, the scene hierarchy nodes are first read according to the scene object identifier, and then the graphics resource dwell state is associated according to the object resource reference relationship. Subsequently, the spatial bounding range of the scene object is projected onto the pixel coordinate system corresponding to the screen partition to form the screen projection range. The screen projection range is determined by the minimum horizontal coordinate, maximum horizontal coordinate, minimum vertical coordinate, and maximum vertical coordinate of each boundary point of the spatial bounding range within the display area. The projection center point is taken as the horizontal midpoint and vertical midpoint of the screen projection range. When at least one boundary point of the spatial bounding range is located between the near clipping boundary and the far clipping boundary, and the screen projection range overlaps with the display area, it is confirmed that the scene object and the view frustum have a visible intersection. The basic display resources, high-precision textures, detail meshes, reflection buffers, and particle detail resources in the object resource reference relationship come from the scene resource management records under the current scene version. Resources without a resource type marked in the scene resource management records should not be automatically classified into any of the aforementioned resource types and can only be written to the pending record area. When the same resource is marked as multiple resource types at the same time, the resource type marked with the latest record time in the current scene version shall prevail. If it still cannot be confirmed, it shall be written to the pending verification record area.
[0093] The main viewport real-time task is formed according to the screen partition and view frustum in the current cycle scheduling reference frame. When there is a visible intersection between the scene object and the view frustum, the projection center point falls into the central region, the object's visibility switch is on, and the geometry cache status is ready to submit drawing commands, the basic geometry drawing task corresponding to the scene object is registered as a main viewport real-time task. When the texture marked as a basic display resource in the object resource reference relationship has an uploaded texture resident status, the corresponding basic texture usage task is registered as a main viewport real-time task. Textures not marked as basic display resources cannot be registered as basic texture usage tasks. When the projection center point is located on the boundary line of the central region, it is registered as a central region task.
[0094] A resource is considered fully available based on its resource identifier, resource version number, memory resident status, and resource loading request completion status. A resource is considered fully available if its resource identifier and version number are present, its memory resident status is "resident," and its resource loading request completion status is "complete." A resource is not considered fully available if any field is missing or the status is not met. Edge area degradation tasks are formed based on the screen partitions, scene-level nodes, and graphics resource resident status in the current cycle's scheduling baseline frame. When a scene object and the view frustum have a visible intersection, and the projection center point falls into the edge area, tasks marked as high-precision textures, detail meshes, reflection buffers, and particle detail resources in the object resource reference relationship are registered as edge area degradation tasks. If the projection center point falls into the transition area, and the aforementioned high-precision textures, detail meshes, reflection buffers, and particle detail resources are not in a fully available state in the graphics resource resident status, they are also registered as edge area degradation tasks. Scene objects whose projection center point falls into the center area cannot be registered as edge area degradation tasks.
[0095] Occlusion delay tasks are formed based on the view frustum, scene hierarchy nodes, and screen partitions in the current periodic scheduling reference frame. A scene object and its view frustum have a visible intersection, and its projection range is completely covered by the projection range of the scene object in front of the view in the same scene version. If the spatial bounding range of the scene object in front is closer to the camera position, the shadow usage task, reflection buffer usage task, and non-basic texture usage task corresponding to the covered scene object are registered as occlusion delay tasks. If the spatial bounding range of the scene object in front is closer to the camera position, confirmation is made based on the point in the spatial bounding range of the scene object in front that is closer to the camera position than the point in the spatial bounding range of the covered scene object. If the two distances are the same or the nearest point cannot be obtained, the occlusion relationship is not confirmed. If the projection range is only partially covered, the distance between the front and back cannot be confirmed, or the spatial bounding range is missing, no occlusion delay task is formed, and the object is written to the pending verification record area.
[0096] Resource preparation tasks are formed according to the graphics resource resident status and scene-level nodes in the current periodic scheduling base frame. When there is a visible intersection between the scene object and the view frustum, or the projection center point falls into the transition area, and the resource loading request status of the corresponding resource is not issued, the resource loading request completion status is not completed, or the video memory resident status is not resident, the resource resident associated task corresponding to the resource is registered as a resource preparation task. If any of the resource identifier, resource version number, or the identifier of the scene object to which it belongs is missing, a resource preparation task is not formed, and it is directly written to the record area to be supplemented. It is forbidden to replace the resource identifier with the resource name, cache name, or resource path.
[0097] The previous cycle compensation task is formed based on the previous rendering cycle scheduling feedback record in the current cycle scheduling baseline frame. If the scene object identifier in the previous rendering cycle scheduling feedback record is consistent with the current scene object identifier, and the task identifier can correspond to the task identifier of the current rendering task, and the record has any of the following conditions: completion status is not completed, distribution status is distributed and resource dwelling changes are not displayed, resource loading request completion status changes to completed, degradation method is not empty, the number of consecutive delays reaches the boundary set by the current scene configuration version, or the prohibition of repeated distribution is marked as valid, the corresponding task will be registered as the previous cycle compensation task. The boundary of the number of consecutive delays is read from the task layering parameter record of the current scene configuration version. If the boundary is not read, the feedback record enters the pending verification record area and does not automatically adopt the default boundary. When an empty feedback record is bound for the first rendering cycle, the previous cycle compensation task is not formed. When the prohibition of repeated distribution is marked as pending verification, the previous cycle compensation task is not formed, and the reason for pending verification is retained.
[0098] The above-mentioned tasks can first form candidate registration records. During the final registration, only one task category is retained for the same task identifier. The order of categories is: previous cycle compensation task, main view area immediate task, resource preparation task, edge area degradation task, and occlusion area delayed task. The category that is hit first is the final task category, and subsequent categories will not be registered. When there are multiple resource identifiers for the same scene object, rendering tasks are formed according to the resource identifiers. When the same resource identifier appears repeatedly in the same current cycle scheduling base frame, only the task record with the same resource version number and the same record summary as the current cycle scheduling base frame is retained. Other duplicate items are written to the duplicate task trace area.
[0099] The task formation result is written to the task hierarchical record area with the current rendering cycle number, scene version number, rendering device identifier, base frame version number, task identifier, scene object identifier, resource identifier, resource version number, task category, formation basis record summary, and formation timestamp. Old records are not overwritten. The current rendering cycle number, rendering device identifier, base frame version number, and task identifier constitute a unique deduplication key. Records with a pending verification status or a pending supplementation status shall not proceed to the next stage. Task hierarchical records with a complete registration status shall be read by the next stage according to the base frame version number.
[0100] This step only uses the virtual scene rendering state, device rendering state, resource dwell state, and scheduling feedback record of the previous rendering cycle that are already bound in the current cycle scheduling baseline frame, and does not read user identity content or business privacy content.
[0101] Preferably, in the virtual exhibition hall roaming scene, the central area can be set to 60% of the screen width, the transition area can be set to 25% of the screen width, the edge area can be set to 15% of the screen width, the consecutive delay number boundary can be set to 3 times, a single current cycle scheduling reference frame can organize 10,000 scene level nodes and 50,000 graphics resource dwell status records, the task layering formation delay can be controlled within 4 milliseconds, and 30 cycles are extracted from the task layering records formed by 300 consecutive current cycle scheduling reference frames to check the reference frame version number, task identifier, scene object identifier, and resource... Source identifier, resource version number, and task category consistency rate are not less than 99%. For example, when the projection center point of the main display case object is located in the central area and the basic texture has been resident, its basic texture usage task is registered as the main view area immediate task. When the high-precision reflection cache of the decorative light located in the edge area is not resident, its reflection cache usage task is registered as the edge area degraded task. When the exhibit texture task that has been issued but not uploaded in the previous rendering cycle has a prohibition on repeated issuance mark in the scheduling feedback record of the previous rendering cycle, the texture task is finally registered as the previous cycle compensation task and is no longer registered as a resource preparation task.
[0102] Alternatively, the projection range of the screen can be obtained from the pre-calculated screen enclosure range of the scene objects, the graphics resource dwell state can be obtained from the engine's internal resource table or the driver layer resource receipt, and the task layer recording area can be a memory table, a local recording file, or a cloud-shared recording area. As long as the current cycle scheduling reference frame is still used to form the main view area immediate task, the edge area degradation task, the occlusion area delayed task, the resource preparation task, and the previous cycle compensation task, it belongs to the same implementation method.
[0103] S4. Based on the task layering results, graphics resource resident status, and scheduling feedback records from the previous rendering cycle, generate a layered scheduling strategy that includes full execution, degraded execution, delayed execution, result reuse, resource pre-resident, and prohibition of duplicate delivery. The specific implementation is as follows:
[0104] After obtaining a complete task layering record with a complete registration status, the rendering control process reads the task layering results under the same current rendering cycle number, scene version number, rendering device identifier, and base frame version number from the task layering record area. It also reads the resource residency status and the scheduling feedback record of the previous rendering cycle from the current cycle scheduling base frame with the same version caliber. Subsequently, it generates layered scheduling policies one by one according to the task identifier. This action occurs during the policy generation period from the submission of the task layering record to the execution of the rendering task. The executing entity is the rendering control process in the local rendering workstation, cloud rendering node, or browser rendering container. The task layering results retain the main view area immediate tasks, edge area degradation tasks, occlusion area delayed tasks, resource preparation tasks, and previous cycle compensation tasks formed in the previous step. This step does not re-determine the task category, does not regenerate the rendering task, and does not read scattered fields from the acquisition record area.
[0105] The resource residency status in this step is the same as the graphics resource residency status in the current periodic scheduling baseline frame used in the strategy generation stage. Its fields include resource identifier, resource type, scene object identifier, video memory residency status, system memory residency status, resource loading request issuance status, resource loading request completion status, and resource version number. Before generating the strategy, the scene object identifier is obtained by the task identifier, and then the corresponding resource residency status is associated with the resource identifier and resource version number. If any of the resource identifier, resource version number, video memory residency status, or resource loading request issuance status is missing, a complete strategy item is not generated, and the corresponding task is written to the pending verification record area.
[0106] The scheduling feedback record of the previous rendering cycle uses the task identifier, scene object identifier, task level, resource identifier, resource version number, distribution status, completion status, resource dwell changes, reason for non-execution, degradation method, actual time consumption, number of consecutive delays, and prohibition of repeated distribution flag already bound in the current cycle's scheduling baseline frame. Before generating the strategy, the task identifier is matched first. If the task identifier cannot be matched directly, the scene object identifier, resource identifier, and resource version number are matched together. If they still cannot be matched, a new task record is created for the current cycle, and the status of the previous cycle is not recreated. The resource version number corresponding to the scheduling feedback record of the previous rendering cycle is obtained from the resource version number field in the record. If the resource version number is missing, it cannot be used as the basis for result reuse.
[0107] Complete execution is determined based on task layering results and resource residency status. If the task category is a main viewport real-time task, the geometry cache status is ready to submit drawing commands, the basic texture residency status is uploaded, and the previous rendering cycle scheduling feedback record does not show a valid "prohibit repeated issuance" flag, then the task is registered as a complete execution. If the task category is a previous cycle compensation task, and the resource loading request completion status is completed and the video memory residency status is resided, then it is also registered as a complete execution, and the original task identifier is retained during registration.
[0108] Degraded execution is determined based on task layering results and resource residency status. If a task is classified as an edge area degraded task, and its high-precision texture, detail mesh, reflection cache, and particle detail resources are not in a fully usable state, and the same scene object has one of the following usable resources: low-precision texture, basic mesh, previous cycle reflection cache, or simplified particle resources, then the task is registered for degraded execution. If no usable resources exist, the task cannot be registered for degraded execution and will continue to enter the delayed execution judgment stage.
[0109] Delayed execution is determined based on task layering results, resource residency status, and scheduling feedback records from the previous rendering cycle. Tasks categorized as occlusion area delayed tasks are registered as delayed execution. Tasks categorized as resource preparation tasks, with resource loading request status as issued and resource loading request completion status as incomplete, are also registered as delayed execution. Tasks whose consecutive delay counts, as shown in the scheduling feedback records from the previous rendering cycle, have reached the boundary set by the current scene configuration version are no longer registered as delayed execution; instead, strategy items are generated according to the corresponding conditions of the compensation tasks from the previous cycle.
[0110] Result reuse is formed based on task layering results, resource residency status, and scheduling feedback records from the previous rendering cycle. The result cache from the previous cycle is determined by the cache record corresponding to the task with a completion status in the scheduling feedback record of the previous rendering cycle. The cache record includes at least the task identifier, scene object identifier, resource identifier, resource version number, display window version, and cache record summary. Result reuse is not allowed if the cache record summary cannot be obtained, or if the resource version number or display window version in the cache record is inconsistent with the current cycle. If the task category is an edge area degradation task or an occlusion area postponement task, and the completion status of the same task identifier in the scheduling feedback record of the previous rendering cycle is completed, the reason for non-execution is empty, the current resource version number is consistent with the resource version number in the scheduling feedback record of the previous rendering cycle, and the current display window version is consistent with the corresponding display window version of the previous cycle, the task is registered as a result reuse. If either the resource version number or the display window version is inconsistent, it cannot be registered as a result reuse.
[0111] Resource pre-retention is formed based on task layering results and resource retention status. If the task category is resource preparation task, and the resource identifier, resource version number, and the identifier of the scene object to which it belongs are complete, and the video memory retention status is not retained or the resource loading request distribution status is not distributed, the task is registered as resource pre-retention. If the resource loading request distribution status is distributed and the resource loading request completion status is not completed, resource pre-retention cannot be registered again, and the process continues to enter the judgment of prohibiting duplicate distribution.
[0112] The "prohibit duplicate assignment" rule is formed based on the scheduling feedback record and resource residency status of the previous rendering cycle. If the scheduling feedback record of the previous rendering cycle shows that the assignment status of the same task identifier is "assigned" and the current resource residency status shows that the resource loading request completion status is "incomplete", then the task is registered as "prohibit duplicate assignment". If the "prohibit duplicate assignment" flag in the scheduling feedback record of the previous rendering cycle is valid, it is also registered as "prohibit duplicate assignment". When the "prohibit duplicate assignment" flag is in the "pending verification" state, a complete policy item is not generated, but written to the "pending verification" record area, and it should not be automatically regarded as "no prohibition".
[0113] When the above strategy items are finally registered, only one strategy item is allowed to be retained for the same task identifier. The exclusive order is fixed as: prohibit duplicate issuance, complete execution, result reuse, resource pre-retention, degraded execution, and delayed execution. The first strategy item to be hit is used as the hierarchical scheduling strategy for the task in the current cycle, and subsequent strategy items will not be registered. This exclusive order only limits the generation of strategies and does not change the task category formed in the previous stage.
[0114] The hierarchical scheduling strategy is written to the hierarchical scheduling strategy record area, which records the current rendering cycle number, scene version number, rendering device identifier, base frame version number, task identifier, scene object identifier, resource identifier, resource version number, task category, strategy item name, strategy formation basis record summary, strategy generation timestamp, and complete strategy status. Old records are not overwritten. The current rendering cycle number, rendering device identifier, base frame version number, and task identifier constitute a unique deduplication key. When generating duplicates, the first complete strategy item is retained, and subsequent duplicate items are entered into the duplicate strategy trace area. Records with a pending verification status cannot enter the next stage. Hierarchical scheduling strategies with complete strategy status are read by the next stage according to the base frame version number.
[0115] This step only uses the task layering results, resource residency status, and scheduling feedback records from the previous rendering cycle; it does not read user identity information or business privacy information.
[0116] Preferably, in the virtual exhibition hall roaming scene, the strategy generation delay can be controlled within 3 milliseconds, 50,000 hierarchical scheduling strategies can be generated in a single current cycle, the consecutive delay number boundary can be set to 3 times, the continuous retention check boundary of the prohibition of repeated issuance can be set to 2 rendering cycles, and 30 cycles are extracted from the hierarchical scheduling strategies formed in 300 consecutive current cycles to check the task identifier, task category, resource version number, strategy item name and strategy formation basis record summary, and the strategy consistency rate is not less than 99%; for example, when the basic texture of the main display case has been resident and the task category is the main view area real-time task, a complete execution is formed; when the high-precision reflection cache of the decorative lights in the edge area has not been resident but the reflection cache of the previous cycle is available and the resource version number is consistent, result reuse is formed; when the reflection cache of the previous cycle is unavailable but a low-precision reflection cache exists, degraded execution is formed; when the exhibit texture loading task of the previous cycle has been issued but not completed, the prohibition of repeated issuance is formed.
[0117] Alternatively, the hierarchical scheduling strategy record area can be a memory table, a local record file, or a cloud-shared record area. The resource residency status can come from the engine's internal resource table or the driver layer resource receipt. As long as the hierarchical scheduling strategy, which includes full execution, degraded execution, delayed execution, result reuse, resource pre-residency, and prohibition of repeated delivery, is still generated based on the task hierarchical results, resource residency status, and scheduling feedback records of the previous rendering cycle, it belongs to the same implementation method.
[0118] S5. Execute the hierarchical scheduling strategy, collect task completion status, actual time consumption, resource residency changes, degradation methods, and reasons for non-execution, and form the current cycle execution feedback record. The specific implementation is as follows:
[0119] After the rendering control process reads the hierarchical scheduling policy with complete policy status from the hierarchical scheduling policy record area, it executes the corresponding tasks according to the policy item names between the start and end of the current rendering task execution cycle. It also collects the task completion status, actual time consumption, resource residency changes, degradation methods, and reasons for non-execution, forming the current cycle execution feedback record. The start of the current rendering task execution cycle is the timestamp at which the rendering control process begins reading the hierarchical scheduling policy. The end of the current rendering task execution cycle is the last timestamp at which the current rendering cycle is allowed to receive graphics command receipts, resource loading receipts, and cache read receipts. Receipts arriving after the end of the current rendering task execution cycle do not rewrite the current cycle execution feedback record. Graphics command receipts, resource loading receipts, and cache read receipts arriving after the end of the current rendering task execution cycle do not rewrite the current cycle execution feedback record; they can only serve as on-site evidence for collecting graphics resource residency status or forming resource loading request completion status in subsequent rendering cycles.
[0120] When executing a hierarchical scheduling strategy, tasks with the strategy name "Complete Execution" are entered into the drawing command submission queue or resource usage queue. Basic geometry drawing tasks are submitted when the geometry cache status is ready to submit drawing commands, and basic texture usage tasks are submitted when the basic texture resident status is already uploaded. Tasks with the strategy name "Degraded Execution" only call the low-precision textures, basic meshes, previous cycle reflection caches, and simplified particle resources already registered in the hierarchical scheduling strategy; no new alternative resources are selected temporarily in this step. Tasks with the strategy name "Delayed Execution" are not entered into the drawing command submission queue, but their task identifier and delay reason are retained. Tasks with the strategy name "Result Reuse" read resources that were completed in the previous cycle and whose resources are available. The results of this task are cached consistently and the corresponding drawing task is not resubmitted. Tasks with the strategy name "Resource Pre-retention" enter the resource loading request queue and only issue retention requests for resource identifiers and resource version numbers registered in the hierarchical scheduling strategy. Tasks with the strategy name "Prohibit Duplicate Issuance" will no longer issue new resource loading requests and will continue to follow the status of existing resource loading requests corresponding to the task identifier of the previous cycle. If the existing resource loading request is completed before the deadline of the current cycle's rendering task execution, the task completion status is registered as completed. If the existing resource loading request is not completed before the deadline of the current cycle's rendering task execution, the task completion status is registered as not executed, and the reason for not executing is registered as prohibiting duplicate issuance.
[0121] The task completion status is recorded as only one of completed, incomplete, or not executed; these three statuses cannot be recorded simultaneously. A task that has submitted a drawing command, resource loading request, or cache read action but has not received a corresponding receipt before the deadline for the current rendering task cycle is recorded as incomplete. A task that has not submitted a new drawing command, issued a new resource loading request, or read the result cache according to the policy item name is recorded as not executed. A task that has received a corresponding receipt before the deadline for the current rendering task cycle, and whose task identifier, resource identifier, and resource version number in the receipt are consistent with the hierarchical scheduling policy, is recorded as completed.
[0122] The actual time consumed is recorded in milliseconds. The starting point is the timestamp of the task entering the drawing command submission queue, resource loading request queue, cache reading action, delayed registration action, or prohibited duplicate issuance registration action. The ending point is the timestamp of the task obtaining the completion receipt, incomplete confirmation, or unexecuted confirmation. When there are multiple sub-actions for the same task identifier, the earliest starting point and the latest ending point are used to form the actual time consumed by the task. The time consumed by sub-actions that have not occurred should not be added.
[0123] Resource residency changes are obtained by comparing the resource residency status before and after execution. The resource residency status before execution is taken from the current cycle scheduling baseline frame associated with the hierarchical scheduling strategy. The resource residency status after execution is taken from the last resource management record before the end of the current cycle rendering task execution, recording the resource identifier, resource version number, changes in video memory residency status, changes in system memory residency status, changes in resource loading request issuance status, and changes in resource loading request completion status. If the resource version number is inconsistent, it shall not be merged into the same resource residency change. If the resource identifier is missing, the current cycle execution feedback record is entered into the pending verification record area.
[0124] The degradation method is only recorded when the strategy item name is "Degradation Execution" and the alternative resource is actually called. The actual called items in low-precision texture, basic mesh, previous cycle reflection cache, and simplified particle resources are recorded. If the strategy item name is not "Degradation Execution", the degradation method record is empty. If the strategy item name is "Degradation Execution" but the alternative resource is not called, the degradation method is not filled in, the task completion status is registered as "Incomplete" or "Not Executed", and the corresponding reason for not executing is recorded.
[0125] The reason for non-execution is registered when the task completion status is "not executed" or "not completed". The value is limited to one of the following: policy delay, prohibition of duplicate issuance, incomplete resource loading, inconsistent resource version, unavailable alternative resource, drawing command not submitted, cache read failure, and pending verification status. When a complete execution task is not completed because the drawing command submission queue has not been received, it is registered as "drawing command not submitted". When a resource pre-resident task is not completed because the resource loading request has been issued but not completed, it is registered as "resource loading not completed". When a result reuse task is not completed because the cache read fails, it is registered as "cache read failure". When a result reuse task is not completed because the resource version number is inconsistent, it is registered as "inconsistent resource version".
[0126] The current cycle execution feedback record is written to the current cycle execution feedback record area with the current rendering cycle number, scene version number, rendering device identifier, base frame version number, task identifier, scene object identifier, resource identifier, resource version number, strategy item name, task completion status, actual time consumption, resource residency changes, degradation method, reason for non-execution, and feedback formation timestamp. Old records are not overwritten. The current rendering cycle number, rendering device identifier, base frame version number, and task identifier constitute a unique deduplication key. When writing repeatedly, the first complete feedback record is retained, and subsequent duplicate items are entered into the duplicate feedback trace area.
[0127] If, during execution, it is found that the hierarchical scheduling strategy is missing a task identifier, resource identifier, resource version number, or strategy item name, the strategy item will not be temporarily created, the execution action will not be submitted, and the task will be written to the pending verification record area. The current cycle execution feedback record with the pending verification status shall not be used as a complete feedback record to enter the next stage.
[0128] This step only uses the hierarchical scheduling strategy and the graphical command receipts, resource loading receipts, and cache read receipts generated on-site. It does not collect user identity information or business privacy information.
[0129] Preferably, in the virtual exhibition hall roaming scene, the execution deadline of the current rendering task can be set to 1 millisecond before the end of the current rendering cycle. A single current rendering cycle can execute 50,000 hierarchical scheduling strategies. The delay in forming the current cycle execution feedback record can be controlled within 3 milliseconds. The actual time consumption record precision can be set to 0.1 milliseconds. 30 cycles are selected from 300 consecutive current rendering cycles to check the task identifier, strategy item name, task completion status, resource version number, and reason for non-execution. The consistency rate of the feedback fields is not less than 99%. For example, when the basic texture task of the main display case is submitted for complete execution and a resource usage confirmation receipt is obtained, it is registered as completed. When the decorative light reflection cache is successfully read from the cache of the previous cycle according to the result reuse, it is registered as completed. If the high-precision texture loading task of the exhibit has been issued in the previous cycle and has not been issued again in this cycle, and the old loading request is still not completed before the execution deadline, it is registered as not executed. The reason for non-execution is recorded as prohibiting repeated issuance.
[0130] Alternatively, the drawing command submission queue can be replaced by the command list inside the rendering engine, the resource loading request queue can be replaced by the driver layer resource request table, and the current cycle execution feedback record area can be a memory table, a local record file, or a cloud shared record area. As long as the hierarchical scheduling strategy is still implemented, the task completion status, actual time consumption, resource residency changes, degradation method, and reasons for non-execution are collected, and the current cycle execution feedback record is formed, it belongs to the same implementation method.
[0131] S6. Write the current cycle execution feedback record into the scheduling feedback record to generate the next rendering cycle scheduling boundary version for the next rendering cycle scheduling reference frame to read. The specific implementation is as follows:
[0132] After the current cycle execution feedback record is formed, the rendering control process reads the current cycle execution feedback record with complete feedback status under the same current rendering cycle number, scene version number, rendering device identifier, and base frame version number from the current cycle execution feedback record area, and writes the current cycle execution feedback record into the scheduling feedback record. Then, it generates the next rendering cycle scheduling boundary version for the next rendering cycle scheduling base frame to read. This action occurs after the execution of the current cycle rendering task ends and before the formation of the next rendering cycle scheduling base frame. The executing entity is the rendering control process in the local rendering workstation, cloud rendering node, or browser rendering container. The written object only comes from the current cycle execution feedback record area. It does not re-execute the hierarchical scheduling strategy, does not re-collect resource resident status, and does not rewrite the current cycle execution feedback record.
[0133] Before writing the current cycle execution feedback record, the following fields are maintained: current rendering cycle number, scene version number, rendering device identifier, base frame version number, task identifier, scene object identifier, resource identifier, resource version number, strategy item name, task completion status, actual time consumption, resource dwelling changes, degradation method, reason for non-execution, and feedback generation timestamp. The task completion status is only one of completed, incomplete, or not executed. The actual time consumption is in milliseconds. The resource dwelling changes are maintained by comparing the resource dwelling status before and after execution. If any of the task identifier, scene object identifier, strategy item name, or task completion status is missing, the current cycle execution feedback record will be placed in the pending verification record area and will not be written to the complete scheduling feedback record.
[0134] The scheduling feedback record is written in batches based on the current rendering cycle number, scene version number, rendering device identifier, and base frame version number. After the batch is completed, a scheduling feedback record version number is generated. The scheduling feedback record version number is determined by the current rendering cycle number, scene version number, rendering device identifier, base frame version number, and the writing batch timestamp. Only one scheduling feedback record version number is generated for the same writing batch. During writing, the current cycle execution feedback records are first merged according to the task identifier, then the resource association is confirmed according to the resource identifier and resource version number, and finally the valid records for the same task identifier are determined according to the feedback formation timestamp. When multiple complete feedback records appear for the same task identifier, the one with the feedback formation timestamp closest to the end of the current cycle's rendering task execution is retained, and other records are written to the duplicate feedback trace area. Old scheduling feedback records must not be overwritten.
[0135] Records with a completed task status include the completion status, actual time taken, resource residency changes, and degradation method. Records with an incomplete task status include the incomplete status, actual time taken, resource residency changes, and reason for non-execution. Records with an incomplete task status include the incomplete status, actual time taken, and reason for non-execution. If the resource residency change is empty, the change result should not be added. Records with the reason for non-execution being "prohibition of duplicate issuance" retain the original task identifier. Records with the reason for non-execution being "incomplete resource loading" retain the resource identifier and resource version number. Records with the reason for non-execution being "inconsistent resource version" should not be merged with records that have the same resource version number.
[0136] After the scheduling feedback record is formed, the rendering control process generates the scheduling boundary version for the next rendering cycle and simultaneously generates the scheduling boundary version number for the next rendering cycle. The next rendering cycle is determined according to the cycle immediately following the current rendering cycle in the rendering cycle sequence. The scheduling boundary version number for the next rendering cycle is jointly determined by the current rendering cycle number, the next rendering cycle number, the scene version number, the rendering device identifier, the scheduling feedback record version number, and the boundary generation timestamp. The same scheduling feedback record version number corresponds to only one complete boundary version number. The scheduling boundary version for the next rendering cycle includes the scheduling boundary version number for the next rendering cycle, the scene version number that can be read in the next rendering cycle, the rendering device identifier, the previous rendering cycle number, the previous base frame version number, the scheduling feedback record version number, the task identifier, the scene object identifier, the resource identifier, the resource version number, the task completion status, resource residency changes, the degradation method, the reason for not executing, the number of consecutive delays, the prohibition of repeated issuance of the flag, and the complete boundary status.
[0137] The number of consecutive delays is determined jointly by the current record of the same task identifier in the scheduling feedback record and the record of the same task identifier in the scheduling boundary version of the previous rendering cycle. If the policy item name corresponding to the current record is "delay execution" or "prohibit duplicate issuance", or if the reason for non-execution is that resource loading is not completed, the number of consecutive delays recorded in the scheduling boundary version of the previous rendering cycle is increased by 1. If the task completion status of the current record is "complete", the number of consecutive delays is written as 0. If the same task identifier does not exist in the scheduling boundary version of the previous rendering cycle, the number of consecutive delays starts from 0. If the scheduling boundary version of the previous rendering cycle is missing or there are inconsistent versions of the same task identifier, the task enters the boundary version to be verified and is not written to the complete boundary status.
[0138] The "Do Not Repeatedly Issue" flag is determined based on the policy item name, task completion status, reason for non-execution, resource residency changes, and continuous retention check boundary of the same task identifier in the scheduling feedback record. If the task completion status is "Completed," or the resource residency changes show that the resource loading request completion status has changed to "Completed," then the "Do Not Repeatedly Issue" flag is invalidated. If the policy item name is "Do Not Repeatedly Issue," or the task completion status is "Not Executed" and the reason for non-execution is "Do Not Repeatedly Issue," and the "Do Not Repeatedly Issue" flag has not yet reached the continuous retention check boundary, and the resource residency changes do not show that the resource loading request completion status has changed to "Completed," then the "Do Not Repeatedly Issue" flag is valid. If the "Do Not Repeatedly Issue" flag reaches the continuous retention check boundary but does not meet the invalidation condition, then the task enters the check boundary version and is not automatically written as valid or invalid. If the "Do Not Repeatedly Issue" flag cannot be determined by the above fields, the task enters the check boundary version and is not automatically written as valid or invalid.
[0139] The next rendering cycle's scheduling boundary version is stored in the scheduling boundary version record area using an append-only method. Old versions must not be overwritten. The same current rendering cycle number, scene version number, rendering device identifier, and scheduling feedback record version number constitute a unique deduplication key. When generating repeatedly, the first complete boundary version is retained, and subsequent repeated versions enter the repeated boundary trace area. If any of the scheduling feedback record version number, task identifier, scene version number, or rendering device identifier is missing during the generation process, a complete boundary state is not generated. Instead, a boundary version to be verified is generated, and the names of the missing fields are specified. The boundary version to be verified must not be read by the next rendering cycle's scheduling base frame.
[0140] When reading the baseline frame for the next rendering cycle, only the record with complete boundary state is read according to the version number of the next rendering cycle scheduling boundary. The execution feedback record and scheduling feedback record of the current cycle are not read separately. The confirmation criteria for reading are that the version number of the next rendering cycle scheduling boundary, the scene version number, and the rendering device identifier are consistent. If any of the three are inconsistent, they must not be read together.
[0141] This step only records the execution facts of the virtual scene rendering task, changes in resource residency, and scheduling status; it does not record user identity information or business privacy information.
[0142] Preferably, in the virtual exhibition hall roaming scene, the scheduling feedback record writing latency can be set to within 2 milliseconds, the next rendering cycle scheduling boundary version generation latency can be set to within 2 milliseconds, a single current rendering cycle can write 50,000 current cycle execution feedback records, the continuous delay number boundary can be consistent with the task layering parameter record in the current scene configuration version, the continuous retention check boundary for prohibiting repeated issuance of markers can be set to 2 rendering cycles, and 30 cycles are extracted from 300 consecutive rendering cycles to check the current rendering cycle number, base frame version number, scheduling feedback record version number, and next... The consistency rate of fields such as rendering cycle scheduling boundary version number, task identifier, consecutive delay count, and prohibition of duplicate issuance is not less than 99%. For example, if a high-precision texture task for an exhibit is registered as not executed in the current cycle according to the prohibition of duplicate issuance and the resource loading request is still not completed, the scheduling feedback record retains the task identifier, resource identifier, resource version number, and the reason for prohibition of duplicate issuance. The prohibition of duplicate issuance flag for the task is written into the next rendering cycle scheduling boundary version and the consecutive delay count of the task in the previous rendering cycle scheduling boundary version is increased by 1 for the next rendering cycle scheduling reference frame to read.
[0143] Alternatively, the scheduling feedback record and scheduling boundary version record area can be a local record file, a memory table, or a cloud-shared record area. As long as the current cycle execution feedback record is still written into the scheduling feedback record to generate the scheduling boundary version for the next rendering cycle and is read by the scheduling reference frame for the next rendering cycle, it belongs to the same implementation method.
[0144] In the operating scenario shown in this embodiment: the virtual exhibition hall roaming system runs on a cloud rendering node, with scene version number A2026-01, rendering device identifier XR-Node-03, current rendering cycle number F12058, and current rendering cycle set to 16.7 milliseconds. After the rendering control process issues a collection command at the start of this cycle, it obtains the viewpoint input uploaded by the posture collector of the head-mounted display device. The viewpoint input records the camera position as the unified coordinate point of the virtual scene corresponding to the entrance area of the exhibition hall, with the camera pointing towards the main display case, the observation center falling in the middle of the main display case, the field of view angle being 90 degrees, the near clipping plane being 0.1 meters, and the far clipping plane being 500 meters. Based on this, the rendering control process forms the viewing cone range for this cycle and projects the viewing cone range onto the screen display area, obtaining screen partitions of the central area, transition area, and edge area. The main display case is located in the central area, the decorative lights are located in the edge area, and the rear exhibition wall is completely covered by the projection range of the main display case screen.
[0145] Subsequently, the rendering control process reads the scene hierarchy nodes from the currently active scene resource management records, confirms that the main display case, decorative lights, and rear display wall each have independent scene object identifiers, and obtains the graphics resource resident status from the rendering resource manager, texture cache table, shadow map cache table, and post-processing cache table; among them, the main display case's basic texture resource version number is T-01 and its video memory resident status is resident, the decorative lights' high-precision reflection cache resource version number is R-07 and its video memory resident status is not resident, and the rear display wall's non-basic texture resource version number is W-03 and it is still in the system memory resident state.
[0146] The rendering control process simultaneously reads the previous rendering cycle scheduling feedback records corresponding to the previous rendering cycle number F12057, the previous scheduling boundary version number B-F12057, and the scene version number A2026-01 from the scheduling record area. It confirms that the high-precision texture task of the exhibit has been issued in the previous cycle, but the resource residency change has not been displayed. The resource loading request completion status has changed to complete and is marked with a prohibition on repeated issuance.
[0147] After the aforementioned perspective input, view frustum range, screen partition, scene level nodes, graphics resource dwell status, and scheduling feedback record of the previous rendering cycle are written into the acquisition record area, an acquisition record version number C-F12058-03 is formed. Before the task layering begins, the rendering control process reads each record according to this acquisition record version number, binds it as the current cycle scheduling reference frame, generates the reference frame version number K-F12058-03, and writes a complete readable mark.
[0148] Subsequently, the rendering control process forms rendering tasks according to the current cycle's scheduling reference frame: the main display case's basic texture resources have been resident and the projection center point falls into the central area, so the main display case's basic texture usage task is registered as the main view area's immediate task; the decorative lights are located in the edge area and the high-precision reflection cache is not in a fully usable state, so the decorative lights' reflection cache usage task is registered as an edge area degraded task; the rear display wall and the view frustum have a visible intersection, but its image projection range is completely covered by the main display case, which is closer to the camera position, so the rear display wall's non-basic texture usage task is registered as an occlusion area delayed task; the exhibit's high-precision texture tasks that were issued but not completed in the previous cycle are registered as the previous cycle's compensation tasks according to the previous rendering cycle's scheduling feedback record.
[0149] After the task layering record is formed, the rendering control process generates a layered scheduling strategy based on the task layering results, resource residency status, and scheduling feedback record of the previous rendering cycle: the task using the basic texture of the main display case is registered as fully executed; the task using the reflection cache of the decorative lights is registered as result reuse because there is a low-precision reflection cache with the same resource version number in the previous cycle; the task using the non-basic texture of the rear display wall is registered as delayed execution; and the task using the high-precision texture of the exhibits is registered as prohibited from being issued repeatedly because it has already been issued in the previous cycle and the current resource residency status shows that the resource loading request completion status is still incomplete.
[0150] When executing the hierarchical scheduling strategy, the task using the basic texture of the main display case enters the resource usage queue and obtains a resource usage confirmation receipt before the end of the current cycle, and the task completion status is registered as completed; the task using the decorative light reflection cache successfully reads the result cache of the previous cycle, and the task completion status is registered as completed; the task using the non-basic texture of the rear display wall does not enter the drawing command submission queue, and the task completion status is registered as not executed, with the reason for not executing registered as strategy postponement; the task using the high-precision texture of the exhibits does not issue a resource loading request again, and continues to follow the status of the existing resource loading request from the previous cycle. Since the existing resource loading request has not been completed before the end of the current cycle, the task completion status is registered as not executed, with the reason for not executing registered as prohibition of duplicate issuance.
[0151] After the current cycle execution feedback record is formed, the rendering control process writes the above feedback into the scheduling feedback record, generates the scheduling feedback record version number D-F12058-03, and generates the scheduling boundary version number B-F12059-03 for the next rendering cycle. Among them, the consecutive delay count of the basic texture task of the main display case is written to 0, the consecutive delay count of the non-basic texture use task of the rear display wall is increased by 1 based on the scheduling boundary version of the previous rendering cycle, and the prohibition of repeated issuance flag of the high-precision texture task of the exhibit continues to be written to be valid, and is increased by 1 based on the consecutive delay count.
[0152] When the next rendering cycle F12059 forms the scheduling baseline frame, it only reads the next rendering cycle scheduling boundary version B-F12059-03 with complete boundary states, and no longer reads the current cycle execution feedback record and scheduling feedback record separately. This ensures that the task status, resource dwell changes, prohibition of repeated issuance of flags and continuous delay counts between adjacent rendering cycles can be continuously inherited according to the same scene version number and the same rendering device identifier.
[0153] All calculations involved in the embodiments are dimensionless numerical calculations, and the preset parameters and thresholds in the calculations are set by those skilled in the art according to the actual situation.
[0154] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.
[0155] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or 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 website, computer, server, or data center via wireless or wired transmission; wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission includes infrared, microwave, etc. 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 containing one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.
[0156] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0157] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.
[0158] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.
[0159] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.
[0160] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0161] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
[0162] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A hierarchical scheduling method for virtual scene rendering tasks, characterized in that, include: S1. Collect the view input, view frustum, screen partition, scene level nodes, and graphics resource dwell status of the current rendering cycle, and read the scheduling feedback record of the previous rendering cycle. S2. Bind the view input, view frustum range, screen partition, scene level node, graphics resource dwell status, and scheduling feedback record of the previous rendering cycle to the current cycle scheduling base frame. S3. Based on the current cycle scheduling reference frame, the rendering tasks are layered into tasks such as the main view area immediate task, the edge area degraded task, the occluded area delayed task, the resource preparation task, and the previous cycle compensation task. S4. Based on the task layering results, graphics resource resident status, and scheduling feedback records from the previous rendering cycle, generate a layered scheduling strategy that includes full execution, degraded execution, delayed execution, result reuse, resource pre-resident, and prohibition of repeated delivery. S5. Execute the hierarchical scheduling strategy, collect task completion status, actual time consumption, resource residency changes, degradation method, and reasons for non-execution, and form the current cycle execution feedback record; S6. Write the current cycle execution feedback record into the scheduling feedback record, generate the next rendering cycle scheduling boundary version, and provide it for the next rendering cycle scheduling reference frame to read.
2. The hierarchical scheduling method for virtual scene rendering tasks according to claim 1, characterized in that, S1 includes: Between the start point of data acquisition and the point where the screen task is submitted, the rendering control process acquires the viewpoint input, view frustum, screen partition, scene level nodes, and graphics resource dwell status in a fixed order, and reads the scheduling feedback record of the previous rendering cycle. Records that arrive after the task submission point are not included in the current collection set. The previous rendering cycle scheduling feedback record uses the previous rendering cycle number, the previous scheduling boundary version number, and the scene version number as the reading index; The collected and read records are written to the collection record area, and a unique deduplication key is formed using the current rendering cycle number, scene version number, rendering device identifier, and collection start point. After writing, the collection record version number and record summary are generated.
3. The hierarchical scheduling method for virtual scene rendering tasks according to claim 1, characterized in that, S2 include: After the current rendering cycle acquisition record is written and before the task layering begins, the rendering control process reads the view input, view frustum, screen partition, scene level nodes, graphics resource resident status and previous rendering cycle scheduling feedback record from the acquisition record area according to the current rendering cycle number, scene version number, rendering device identifier and acquisition record version number. Bind the read content to the current period scheduling baseline frame and generate the baseline frame version number; when the read content does not have a pending verification status, a pending supplement status, or a version inconsistency status, write a complete readable tag.
4. The hierarchical scheduling method for virtual scene rendering tasks according to claim 1, characterized in that, S3 includes: The rendering control process reads the current cycle scheduling base frame with a fully readable tag; Rendering tasks are formed based on scene hierarchy nodes, object resource reference relationships, and graphics resource resident status; the image projection range is formed based on the spatial enclosure range of scene hierarchy nodes; Based on screen partitions, view frustum range, image projection range, and graphics resource dwell status, rendering tasks are registered as main view area immediate tasks, edge area degraded tasks, occluded area delayed tasks, and resource preparation tasks. Write the task identifier, task category, and summary of the record based on the task hierarchical record area to form a task hierarchical record with complete registration status.
5. The hierarchical scheduling method for virtual scene rendering tasks according to claim 4, characterized in that, S3 also includes: When the scene object identifier in the scheduling feedback record of the previous rendering cycle is consistent with the scene object identifier of the current rendering task, and the task identifier corresponds to the task identifier of the current rendering task, the compensation task of the previous cycle is formed based on the completion status, distribution status, resource residency changes, degradation method, number of consecutive delays and the prohibition of repeated distribution flag. The same task identifier determines the task category in the following order: previous cycle compensation task, main view area immediate task, resource preparation task, edge area downgrade task, and occlusion area delayed task.
6. The hierarchical scheduling method for virtual scene rendering tasks according to claim 1, characterized in that, S4 include: The rendering control process reads the task layer record with complete registration status; Read the resource dwell status and the scheduling feedback record of the previous rendering cycle from the current cycle scheduling baseline frame. The resource dwell status is the same as the standard used in the strategy generation stage for graphics resource dwell status. Based on the task category, resource residency status, and scheduling feedback records from the previous rendering cycle, generate complete execution, degraded execution, delayed execution, result reuse, and resource pre-residency policy items according to the task identifier, and write the policy items into the hierarchical scheduling policy record area to form a hierarchical scheduling policy with complete policy status.
7. The hierarchical scheduling method for virtual scene rendering tasks according to claim 6, characterized in that, S4 also includes: If the previous rendering cycle scheduling feedback record shows that the same task identifier has been issued and the resource residency status shows that the resource loading request completion status is not completed, then register the policy item to prohibit duplicate issuance. The same task identifier determines the strategy items in the following order: prohibiting duplicate issuance, complete execution, result reuse, resource pre-retention, degraded execution, and delayed execution.
8. The hierarchical scheduling method for virtual scene rendering tasks according to claim 1, characterized in that, S5 include: The rendering control process reads the hierarchical scheduling policy with complete policy state from the hierarchical scheduling policy record area; Between the start and end of the current rendering cycle, the corresponding task is executed according to the strategy item name. Collect task completion status, actual time consumed, resource retention changes, degradation method and reason for non-execution, form current cycle execution feedback record and write it into the current cycle execution feedback record area to form current cycle execution feedback record with complete feedback status; Graphics command receipts, resource loading receipts, and cache read receipts that arrive after the execution deadline of the current cycle's rendering task will not rewrite the current cycle's execution feedback record.
9. The hierarchical scheduling method for virtual scene rendering tasks according to claim 1, characterized in that, S6 include: The rendering control process reads the current cycle execution feedback record with complete feedback status according to the current rendering cycle number, scene version number, rendering device identifier and base frame version number; Write the task completion status, resource residency changes, degradation method, and reason for non-execution from the current period execution feedback record into the scheduling feedback record; Based on the scheduling feedback records and the scheduling boundary version of the previous rendering cycle, determine the number of consecutive delays and the prohibition of repeated issuance flag according to the task identifier, and generate the scheduling boundary version of the next rendering cycle with complete boundary state.