ReadonlybufferBytes held by those geometries — §84's bufferMemory.
ReadonlygeometriesLive, undisposed geometries.
Optional ReadonlymaterialsLive, undisposed materials. Optional: @fourjs/materials is outside this
package's dependency set, so the caller passes the count it already has.
ReadonlyrenderLive, undisposed render targets.
Optional ReadonlysolverLive solver body handles. Optional; kept beside LiveResourceCounts.solverHandles so existing call-sites that already filled this field keep working.
Optional ReadonlysolverLive solver collider handles. Optional: @fourjs/physics is outside this
package's dependency set.
Optional ReadonlysolverLive solver handles (bodies + colliders + joints, or whatever the caller
accounts as one population). Optional: @fourjs/physics is outside this
package's dependency set (A-5 follow-up: materials + solver handles).
Optional ReadonlysolverLive solver joint handles. Optional: @fourjs/physics is outside this
package's dependency set.
ReadonlytextureBytes described by textures and targets — §84's textureMemory.
ReadonlytexturesLive, undisposed textures.
A reading of §83's live-resource accounting, as the caller's packages report it.
The first five fields are exactly the five zero-argument readers
@fourjs/geometryand@fourjs/renderexport, in that order:liveGeometryCount(),geometryMemoryBytes(),liveTextureCount(),liveRenderTargetCount(),textureMemoryBytes(). The optional material and solver-handle fields are filled the same way from@fourjs/materialsand@fourjs/physicswhen the caller can see those packages.bufferBytesandtextureBytesare byte totals, not per-population splits:textureBytescovers textures and render targets together, because that is howtextureMemoryBytes()is defined (§84 names two memory counters, and a target's attachments are textures). The instance counts stay separate, so a report can still say which population grew.