|
MayaFlux 0.5.0
Digital-First Multimedia Processing Framework
|
Declarative configuration for the GPU-side spatial-relational work a GpuFieldOperator can drive beyond plain field bindings: uniform-grid spatial hashing, neighbour-density colouring, the deterministic claim/absorption protocol, and opt-in population dynamics. More...
#include <GpuFieldOperator.hpp>
Collaboration diagram for MayaFlux::Nodes::Network::SpatialFieldConfig:Public Attributes | |
| std::optional< float > | absorb_radius |
| Enables the deterministic claim/absorption pipeline at this distance. | |
| float | capture_growth { 0.0F } |
| Scales a claimant's effective capture radius by the cube root of its own currently accreted mass (mutation_accreted_mass, uploaded fresh each cycle from PhysicsOperator::get_accreted_mass_span when a PhysicsOperator drives the network): max(absorb_radius,
cbrt(accreted_mass) * capture_growth). | |
| std::optional< float > | cell_size |
| Spatial hash cell size. | |
| bool | cosmetic_swallow { true } |
| Whether ClaimSwallowProcessor's cosmetic pass (position snap onto root, size/colour from this cycle's swallow_count) is added to the chain. | |
| bool | cross_cluster { false } |
| Whether ClaimProcessor and HashDensityColorProcessor may see across cluster boundaries. | |
| bool | density_color { false } |
| Enables neighbour-density colouring (ember-to-white-hot ramp). | |
| float | density_saturation_count { 24.0F } |
| HashDensityColorProcessor: neighbour count at which the density ramp saturates to fully warm. | |
| float | reserve_fraction { 0.0F } |
| Fraction of extra reserve capacity the geometry buffer allocates beyond the live point count, for PopulationSpawnProcessor to claim: reserve_count = ceil(live_count * reserve_fraction), and the vertex buffer plus every hash/claim/mutation state field is sized to live_count + reserve_count from the moment this operator is wired, never resized again afterward. | |
| float | spawn_density_threshold { 30.0F } |
| PopulationSpawnProcessor: real neighbour count (same 27-cell query HashDensityColorProcessor performs) a live point must clear before it spawns a copy of itself into a fresh reserve slot. | |
| float | swallow_base_size { 10.0F } |
| ClaimSwallowProcessor: a survivor's point size the cycle it has swallowed nothing. | |
| float | swallow_dim_factor { 0.08F } |
| ClaimSwallowProcessor: brightness multiplier applied to an absorbed particle's cluster colour (0 invisible, 1 as bright as the survivor). | |
| float | swallow_growth_rate { 0.6F } |
| ClaimSwallowProcessor: point-size increase per particle a survivor swallowed this cycle. | |
| float | swallow_max_size { 70.0F } |
| ClaimSwallowProcessor: point-size ceiling regardless of swallow count, so one runaway cluster can't dominate the screen. | |
| bool | transfer_on_claim { false } |
| Whether a claim that crosses a cluster boundary moves the absorbed vertex into the claimant's cluster (a "hop"/transfer) instead of destroying it (population dynamics) or cosmetically swallowing it. | |
Declarative configuration for the GPU-side spatial-relational work a GpuFieldOperator can drive beyond plain field bindings: uniform-grid spatial hashing, neighbour-density colouring, the deterministic claim/absorption protocol, and opt-in population dynamics.
Domain-neutral. Every stage this selects operates on the vertex records a GraphicsOperator produces, addressed through that operator's VertexLayout, with no dependency on what kind of network or primary operator sits behind them: a PhysicsOperator on a ParticleNetwork is one source, a TopologyOperator or PathOperator on a PointCloudNetwork is another. A handful of fields draw on concepts only a PhysicsOperator supplies (accreted mass, collection boundaries) and degrade to a documented no-op when none is present; each such field says so in its own entry.
Filled once, at construction, with designated initializers: the same shape as VolumeGridBuffer::FlowConfig, a plain value handed over once rather than a sequence of enable_x() calls.
Two kinds of field here, deliberately not distinguished by type but documented per-field: cell_size/absorb_radius/cosmetic_swallow/density_color are structural, as they decide which processors the geometry buffer constructs in the first place, so changing them after wiring would mean tearing down and rebuilding part of the chain, and there is no live path for that yet. Every other field is a tuning value read by a processor that exists regardless of its value; those do have a live path, through GpuFieldOperator's own setters (see each field's own doc for which one).
Definition at line 43 of file GpuFieldOperator.hpp.