Closed
Conversation
0.16.0.0 Update
DRVeyl
force-pushed
the
OcclusionHandler
branch
2 times, most recently
from
942bc91 to
8eb36f6
Compare
Make the overall mesh axis-aligned bounding box accessible from VehicleVoxel Collect in VehicleAerodynamics and expose as VoxelCenter and VoxelMeshExtents
Uses Unity Jobs to perform raycasts against the overall vessel and cache visible areas for all parts for a configurable set of orientations. Replace stock drag-cube-based convection occlusion and sun occlusion calculations. Runs two passes: FixedUpdate for required calculations, and Update for building up the cache
Apply VehicleOcclusion mechanics to FlightIntegrator calculations Take more direct control for convection heating calculations. Sift through the mess of stock skin exposed/unexposed temperature difference handling.
Parallelize convection precalc filtering Jobify ProcessRaycasts. Main thread code only needs to access 1 value per collider.
Use nameof pattern Remove fieldsVisible setting in SetProjectedArea, it is properly covered in UpdateAeroDisplay
Convert from chain of IJobParallelFor to a single IJob that creates the resulting sorted lists. Trade HashMaps for Lists: the cost of allocating/clearing the hashmap ended up more than computing IndexOf() on Lists, for small lists. The complexity of making a hashmap to convert to a list because NativeQueue has a leak and we don't have IParallelFilterJob from ECS is basically not worth it. Fully utilizing the multiple cores for burst jobs this small/short was also very spotty.
Declare a reset interval and coroutines to invoke it after completing a run Refactor job creation into a few methods Refactor job allocation and creation order again; focus on optimizing runtime when no raycasts are required Run on any unpacked vessel, not just the active one; always add TimingMananger methods in Start Add Vessel reference in debug lines Handle occlusion by parts on a different vessel than the one being measured Track Vessel directly instead of through farVesselAero Pull NativeMultiHashMap indexedPriorityMap up to class member, save on cost to clear in a job vs allocate
Use OcclusionHandler calculations for sun and body directions [used for radiation heating] Fallbacks from OcclusionHandler to FARAeroModule to stock. No longer necessary to invoke stock UpdateOcclusion() methods. Bugfix: skinExposedArea ported from stock SetSkinProperties was incorrect.
More job re-ordering Bugfix: Add processed quaternion even if it hit absolutely nothing. Can happen on selected angles with projected vessel extents < ray interval. Add third priority list to BucketSortByPriority. (This seems very awkard to handle and does not extend well. May be better to split into a job that combines lists, and then implement a single HashMap here). Extending the sorting lists like this suggests a different approach may be cleaner if more angles need to be pre-computed.
Fix incorrect porting of stock code Initialize skinUnexposedTemperature properly Set min areaFraction [1%] to mitigate errors in raycast averaging Change body flux direction to point towards mainBody center instead of vessel transform's "down" (stock behaviour)
Multiple NativeLists was an awkward approach. Build a new job that merges a List into a HashMap.
Avoid race condition with resetting memory allocations while jobs may be using them. Request a reset and handle only at the end of a frame. Fix convectionArea handling when part.ShieldedFromAirstream
Avoid coming back to main thread to conduct a single math operation to forward to new set of jobs.
Allocate array containers once on creation instead of during reset Make ResetCalcuations() private since it does memory allocation/deallocation, avoid race-condition with running jobs. Request a reset that will be handled at end-of-frame instead. Carry occlusion directions-of-interest in a list instead of hard-coding the directions to calculate Parameterize many lists/arrays in jobs processing methods instead of referring to globals. WIP: On-demand occlusion calculator for external use
This value is used elsewhere in determining, among other things, the background temperature for the exposed vice unexposed portions of skin. It can be used similarly to ptd.exposed or skinExposedAreaFrac. Since VehicleOcclusion returns the skin exposed area taking occlusion into account, this value should be 1: the temperature of the air at the exposed area shouldn't be scaled. However, it needs to be 0 if the entire part is occluded, because of the design choice that skinExposedAreaFrac=1 (instead of 0) in that situation, and so the background temperature of the air at the part needs to interpolate to the atmosphere temperature, not some convection shock temperature.
More appropriate use of ref, in, out parameters, especially with native containers Using keyword to ensure native containers are disposed. (Automatic try/finally)
Carry all thermal debug fields in a List<BaseField>, and separate out methods to initialize, change visibility, and update the fields. Add/Remove a new field by declaring it, adding it to the list in AddThermalDebugFields, and updating it in UpdateThermalDebugFields Extract thermal debug field display/update handling to OnUpdate Add PAW groups to aero debug fields Todo: Refine fields included in debug display
Tag pass started in UpdateEarly/FixedUpdateEarly, un-tag when processing jobs Maintain global count of jobs created across all instances of VehicleOcclusion. Each instance may request as many jobs as are critical to answer this physics tick during the FixedUpdate cycle. During the Update cycle, first come first serve the remaining slots, up to MAX_JOBS. Thread starvation during Update cycle is possible, but the fallback of unrestricted job count during FixedUpdate may be sufficient
Move the exposed area into a Sqrt.
Replace compile-time constants with configurable settings: enabling, performance values
Default to stock drag cube handling until either of these systems is ready, ie voxelization has completed.
Manually merge Voxelization and Occlusion edits
DRVeyl
force-pushed
the
OcclusionHandler
branch
from
73fb05b to
8cbc24d
Compare
Author
|
Closing in favor of a PR to master (#109) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Unity Jobs+Burst-based Occlusion Handling for FlightIntegrator
Precompute occlusion from configurable number of directions on a sphere (currently 2000), sample by raycasting over the entire vessel and record per-part dictionary of <direction, area of total raycasts hitting collider>. Limit calculations during FixedUpdate cycle to only those that will be required for physics on that pass. Consume configured number of additional directions during Update() cycle, prioritized by near-ness to current vessel orientation. (That is, attempt to predict which orientations not yet calculated are most likely to be requested next.)
Since it is a physics raycaster, it can only hit colliders. Badly-configured part colliders, or missing colliders, will have an impact. (No collider ala ProcFairings [pre-1.8.3] means no detected surface area/occlusion for thermal processing.)
Creating this PR and leaving in DRAFT status for tracking / discussion. Will likely edit this section with any issues/status.
For testing / to exercise more fully, re-calculates over entire vessel [configurable interval, default 180 seconds] after completion, or whenever voxelization completes. Ideally the precomputation is a one-time cost each time the vessel changes. Part animations, if they move colliders, maybe should trigger a recompute. Things in the environment can also occlude, so decoupling two vessels may lead to one occluding the other, and this state should get re-computed ... some time later.
Known issue: Update-cycle jobs cap is per-vessel instead of global. If multiple vessels are in physics range (such as after decoupling a lot of fairingsides) then they will all consume their allotment of raycast jobs. Need to track how many total jobs have been created across all active vessels, not per-instance. Probably should prioritize access by the ActiveVessel in this instance? Does it matter if we starve some vessels of their pre-compute jobs, or should all vessels get a minimum?
Implementation note: Current raycaster is limited to 10,000 rays over entire vessel. Min interval between rays is 0.1m in each dimension. Vessel dimension <10m will cast fewer rays. Vessel dimension > 10m will stretch the interval in that dimension to cast 100 rays along that slice. Not sure if I should keep it this way with the fixed min interval, or configure the raycaster to always shoot 10,000 rays and not have a minimum interval (so a small part/vessel will get a more precise area measurement). Forcing all casts to the fixed size would cost some performance in exchange for some accuracy, not sure if that is needed.
Fixes #107