3D API Overview - 1.3.2 Beta

General
101

I’ve been hesitant to start a thread on it because it uses features (not being discussed here) that are only currently in the 1.4 beta (http.get).

But yeah - if nothing else, I’ve made a “Procedural Planets” thread, where we can discuss graphics; I’ll make one for the game proper when I can actually share (ie. when everyone can participate).

102

Hello @Andrew_Stacey. I am working through the code of the Roller Coaster example project, and I have a question about the Vec3.SO(u, v) function:


function Vec3.SO(u, v)
    if u:is_zero() and v:is_zero() then    -- Are both u and v zero vectors?
        return {Vec3.e1, Vec3.e2, Vec3.e3} -- Then return the standard basis
    end

    if u:is_zero() then                    -- Is u a zero vector?
        u, v = v, u                        -- Then swap u and v, so v is the zero vector
    end

    if u:cross(v):is_zero() then           -- Is v a zero vector, or u and v co-linear?
        if u.x == 0 and u.y == 0 then      -- Is u along the z-axis?
            v = Vec3.e3                    -- Set v along the z-axis too (In error?)
        else
            v = Vec3(u.y, -u.x, 0)         -- Reset v to the x, y components of u,
                                           -- but rotated 90 degrees clockwise
        end
    end

    local t = GramSchmidt({u, v})

    t[3] = t[1]:cross(t[2])

    return t
end

It seems to me that if u is in the direction of the z-axis, then v needs to be set to something other than Vec3.e3 (also along the z-axis), otherwise the inputs into the Gram-Schmidt process will not be linearly independent.

103

Sounds right. Make it Vec3.e1 instead.

It could probably be made a little more efficient by just testing if u.x == 0 and if so setting v = Vec3.e1, otherwise putting v = Vec3(u.y, -u.x,0) with no further test.

104

I have a slightly reworked version of that code which uses the native vec3 instead of defining a new class.

Edit Looking back, I see I already mentioned it.