Constant structures/tables

[ariankordi]

Often it’s useful to have lookup tables with named values, like in these snippets:

• https://github.com/ariankordi/FFL.js/blob/93cad58322fe1ed7a996c5af8e878bd48c2186f5/materials/FFLShaderMaterial.js#L452-L547
• https://github.com/cozmo/jsQR/blob/8e6a036beafa7053dd44b1b76ac578d22b1b3311/src/decoder/version.ts#L14-L1319
• https://github.com/ariankordi/FFL.js/blob/93cad58322fe1ed7a996c5af8e878bd48c2186f5/helpers/ModelScaleDesc.js#L38-L85

As far as I understand, Fusion doesn’t support defining these as constants.

The alternatives I use are either:

• Switch statement for setting values (Translation of FFLShaderMaterial)

            case MaterialType.FacelineForehead:
                MaterialAmbient[0] = 0.85;
                MaterialAmbient[1] = MaterialAmbient[2] = 0.75;
                MaterialDiffuse[0] = MaterialDiffuse[1] = MaterialDiffuse[2] = 0.75;
                // ...
                break;

            case MaterialType.Mask:
            case MaterialType.Noseline:
            case MaterialType.Glass:
                // ...
                SpecularPower = 40;
                SpecularAnisoEnable = true;
                break;

• Method for setting values (Translation of ModelScaleDesc)

    public BodyScaleDesc SetForEditor!()
    {
        const string[] none = {
            "all_root", "body", "skl_root"
        };
        const string[] allX = {
            "wrist_l", "wrist_r", "shoulder_l", "shoulder_r",
            "ankle_l", "ankle_r", "knee_l", "knee_r"
        };
        NameRootBone = "skl_root";
        NameHeadBone = "head";
        ModeDefault = BodyScaleBoneMode.Xyz;
        // ...
...

• Linear tables to extract multiple values out of

    void SetCommonParameters!(MaterialType type)
    {
        const uint paramCount = 7;
        // Scalar material parameters per type.
        const float[MaterialType.Count.ToInt() * paramCount] parameters =
        {
            0.4, 1, 2.6, 0.02, 0.8, 2, 0.3, // FacelineForehead
            0.3, 0, 2.6, 0.02, 0.8, 0.55, 0, // Nose
            0.45, 1, 1, 0.06, 0.8, 1, 0.5, // Hair
            // ...
        };

        uint i = type.ToInt() * paramCount;
        HalfLambertFactor = parameters[i + 0];
        SssSpecularFactor = parameters[i + 1];
        SpecularFactorA = parameters[i + 2];
        SpecularFactorB = parameters[i + 3];
        // ...
    }

On a similar topic, it looks like multidimensional arrays can’t be constant either. Examples of this:

• https://github.com/aboood40091/ffl/blob/73fe9fc70c0f96ebea373122e50f6d3acc443180/src/FFLiDatabaseRandom.cpp#L103
• https://github.com/ariankordi/qr.js/blob/463802f025c7f45059e864cb07a4f2a10f879767/qr.js#L38-L80

The way I work around this is to flatten the arrays to be linear.
For example, if each item is a four-element float, then all of the floats would instead be part of a single array.
Then, calculate the start/end manually when you obtain the values. It's straightforward if you are already familiar with how arrays get laid out in memory, but a bit unintuitive if you don't.

For my port of FFLiDatabaseRandom where the sizes of some arrays vary, I used a second "index" array like this:

    const ushort[] FacelineTypeIndex =
    {
        0, 10, 20, 30, 42, 55, 67, 79, 92, 104, 114, 124, 134, 146, 158, 170,
        182, 194, 206
    };
    const byte[] FacelineTypeData =
    {
        0, 0, 1, 1, 2, 3, 4, 5, 9, 9, 0, 0, 1, 1, 2, 3,
        4, 5, 9, 9, 0, 0, 1, 1, 2, 3, 4, 5, 9, 9, 0, 0,
        1, 2, 2, 3, 4, 5, 6, 7, 10, 11, 0, 1, 2, 2, 3, 4,
        // ...
    };
    
    // ...
    uint index = (gender * 9) + (age * 3) + race;
    ushort offset = idxTable[index]; // Offset to the odds table itself.
    ushort size = idxTable[index + 1] - offset; // Size of the individual odds table.
    uint random = context.Random(size); // Random in-bounds index.
    // Access the random offset in the individual array.
    return data[offset + random];

(Hopefully this makes sense)

There is a case to be made that doing it this way can be more optimal for languages like JS, where each Uint8Array has to be constructed one by one.

The property names may also add up to the total (uncompressed) code size. Look at jsQR.min.js as-is, and notice how much room these take:

Compare that to the same code minified with Google Closure Compiler which mangled all of the property names:

(Closure Compiler is not usable on most codebases, and the rest of the minifiers don't mangle like this.)

But, I guess the choice to do this or not should be up to the individual + this cost certainly doesn't appear in places like C++.

IMO I could go without either constant multi-dimensional arrays or structures, though it gets more annoying to not have the latter.
This is something I just implemented the other day, which you can tell it would've been nice to have structures for.

Let me know your thoughts on the matter, or if anybody else has run into a similar limitation while trying to implement something in Fusion. Thanks.

[pfusik]

Currently const arrays can have number, enum and string elements only. I consider introducing multi-dimensional const arrays, but C and C++ don't support jagged arrays directly, so we need to either reject them or provide a workaround with pointers to separate arrays.

The closest I got to this being a limitation in my projects was in DataMatrix.fu which isn't that bad IMO and in most target languages has a smaller memory footprint than AOS.

I did not originally plan const objects because that would require constructor parameters. However, now that we have object literals, perhaps this should be accepted:

const Foo[] Bar = {
    { Baz = 42, Quux = 1337 },
    { Baz = 67, Quux = 6502 }
};

?
The first problem I see here is constructors in C. How do we invoke them?