Addendum 01 (3D Modeling): A Cross-Platform “Hello 3D World”

Supplementary Use Case to the Main BRCC Paper

1. Introduction

This addendum illustrates how Business Rule Completeness Conjecture (BRCC) principles apply to 3D modeling—an unexpected yet highly relevant domain. While the main paper focuses on eliminating the ripple effect in business logic, the same five declarative primitives (Schema, Data, Lookups, Aggregations, Calculated Fields) can unify 3D shapes across different environments (OpenSCAD, Blender, AutoCAD, etc.).

Key Insight

• A single “rulebook” (stored declaratively in an ACID-compliant datastore) captures the “what” of a 3D model.

• Each environment’s “how” (specific syntax, scripts, or code) is automatically generated from the rulebook.

• By separating semantic intent from syntactic implementation, updates (e.g., changing a sphere radius) propagate without manual rewriting.

2. A Simple Demonstration: Cube + Sphere Hole

Consider a “hello world” geometry: a cube with a spherical hole. Normally, you would maintain different code snippets for OpenSCAD, Blender, AutoCAD, etc. Under BRCC, we store parameters once, then generate scripts for each tool.

2.1 Declarative Definition (JSON)

Below is a minimal JSON “rulebook” describing the shapes. We do not embed any environment-specific syntax here.

json


Copy

{

  "name": "drawHolySquare",

  "parameters": {

    "cubeSize": 10,

    "sphereRadius": 5,

    "smoothness": 100

  },

  "operation": "subtract",

  "shapes": [

    {

      "type": "cube",

      "center": true,

      "size": "{{cubeSize}}"

    },

    {

      "type": "sphere",

      "radius": "{{sphereRadius}}",

      "smoothness": "{{smoothness}}"

    }

  ]

}

• Schema (S): The structure defining a cube and a sphere.

• Data (D): Parameter values (e.g., cubeSize, sphereRadius).

• Lookups (L): Could be references among shapes or external libraries (not used here).

• Aggregations (A): In more complex models, e.g., combining multiple surfaces, computing volumes.

• Calculated Fields (F): Derived attributes (e.g., shape thickness).

2.2 Example Generated Scripts

A templating engine (like Handlebars) reads the JSON and produces environment-specific code.

OpenSCAD

handlebars


Copy

module {{name}}(

  cubeSize={{parameters.cubeSize}}, 

  sphereRadius={{parameters.sphereRadius}}, 

  smoothness={{parameters.smoothness}}

) {

    difference() {

        cube(cubeSize, center=true);

        sphere(sphereRadius, $fn=smoothness);

    }

}

Blender (Python)

handlebars


Copy

def {{name}}(

  cube_size={{parameters.cubeSize}}, 

  sphere_radius={{parameters.sphereRadius}}, 

  smoothness={{parameters.smoothness}}

):

    import bpy


    # Create a cube

    bpy.ops.mesh.primitive_cube_add(size=cube_size, location=(0, 0, 0))

    cube = bpy.context.object


    # Create a sphere

    bpy.ops.mesh.primitive_uv_sphere_add(

        radius=sphere_radius, location=(0, 0, 0),

        segments=smoothness, ring_count=smoothness

    )

    sphere = bpy.context.object


    # Boolean difference

    bool_mod = cube.modifiers.new(type="BOOLEAN", name="difference_mod")

    bool_mod.object = sphere

    bool_mod.operation = 'DIFFERENCE'

    bpy.context.view_layer.objects.active = cube

    bpy.ops.object.modifier_apply(modifier="difference_mod")


    bpy.data.objects.remove(sphere, do_unlink=True)

    return cube

AutoCAD (AutoLISP)

handlebars


Copy

(defun c:{{name}} (/ cubeSize sphereRadius)

    (setq cubeSize {{parameters.cubeSize}})

    (setq sphereRadius {{parameters.sphereRadius}})


    (command "_box" '(0 0 0) (list cubeSize cubeSize cubeSize))

    (command "_sphere" (list (/ cubeSize 2) (/ cubeSize 2) (/ cubeSize 2)) sphereRadius)


    (setq lastbox (entlast))

    (setq lastsphere (entnext lastbox))

    (command "_subtract" lastbox " lastsphere ")

)

3. Potential Challenges & Observations

1. Different Capabilities and Paradigms

• Tools vary in how they handle advanced geometry, materials, or animations.

• Under BRCC, these differences become questions of runtime implementation rather than changes to the core definition. If a tool supports the feature, it can implement it from the same declarative source.

2. Complex Geometries

• One might suspect certain shapes (e.g., parametric surfaces or intricate blends) cannot be captured declaratively.

• In practice, these can be encoded as parametric expressions, references, or new “shape” primitives. If the Conjecture holds, no finite geometry is unrepresentable by (S, D, L, A, F).

3. Performance Considerations

• Large or high-polygon models require efficient runtimes, but BRCC addresses design-time semantics, not how the engine optimizes those operations.

• By making intent explicit, advanced compilers/runtimes might optimize more effectively than if the logic were hidden in line-by-line code.

4. Templating and Edge Cases

• Tools have unique coordinate systems or file formats. In the BRCC model, these details become part of the transform layer.

• Additional fields in the JSON (e.g., metadata.coordinateSystem) can handle environment-specific nuances while keeping the overall definition consistent.

Overall, attempts to produce “unrepresentable” geometry consistently reveal that the five declarative primitives can handle these scenarios when carefully modeled.

4. Conclusion

This 3D printing (and broader 3D modeling) “hello world” example showcases the heart of BRCC:

• Design-Time Rulebook: A single, ACID-stored JSON capturing the essential shape.

• Syntax-Free Updates: Changing any parameter (cube size, sphere radius) instantly regenerates environment-specific code, eliminating manual rewrites.

• Universal Applicability: Despite initial skepticism, most “complex” geometry or environment-specific edge cases can still be tackled in a purely declarative format if the Conjecture holds.

By treating geometry the same way we treat other business rules—abstracting away syntax and maintaining an authoritative semantic model—teams can collaborate efficiently across multiple CAD/CAM tools without the usual “ripple effect.” While not a proof of BRCC’s full universality, this example strongly demonstrates its potential value in domains well beyond conventional business logic.

Citation

Addendum 01 (3D Modeling): A Cross-Platform “Hello 3D World.” In Business Rule Completeness Conjecture: Foundations & Falsifiability, 2025.