Skip to content

Type-level bound / field differentiation #12

@ProfLander

Description

@ProfLander

SignedDistanceField is incorrectly-named as-is, since it will accept arbitrary distance functions which may not be valid signed distance fields.

It's desirable to be able to use non-field functions, but they come with various caveats (increased raymarching cost, being unsuitable for collision detection) that justify encoding a distiction.

Currently, the difference is encoded via cargo tests; each test asserts that a shape is a field via BoundChecker, with bounds being marked as should_panic so tests will pass with a note and panic message. This is sufficient for informational purposes (even with BoundChecker's current non-comprehensive implementation), but is too expensive for runtime checks, and provides nothing in terms of type-level machinery.

Thus, SignedDistanceField should be renamed to DistanceFunction or DistanceFn, and extension traits for inner / outer field validity should be implemented. This will demonstrate boundedness more explicitly in code, and allow type-level checking for cases like passing a non-field-interior SDF into a collision support function.

Need to research the semantics around unsafe traits - these would be simple marker traits (or blanket impls with a const bool, need to weigh the pros and cons) and thus not perform any actual unsafe rust, but would result in logical unsoundness if implemented on a non-field type. Simply being markers may be sufficient.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions