tomaspietravallo / sparkar-volts Goto Github PK

Switch away from the current Time.ms.monitor to a recursive setTimeoutWithSnapshot. The benefit would be being able to add/remove signals from the snapshot, instead of having it fixed from beginning to end.

Will need to evaluate the precision and tradeoffs of using setTimeoutWithSnapshot instead of monitor. I only previously tested this with the MultipeerAPI & 200ms+ delays, so I don't know how suitable this might be when it needs to run on every frame

Is your feature request related to a problem? Please describe.:
An easier way to swizzle vector components

Describe the solution you'd like:

const v = new Vector(1,2,3);
// returns a new Vector with components [3.0, 2.0, 1.0]
const swizzled = v.swizzle('zyx');

Describe alternatives you've considered:

const v = new Vector(1,2,3);
const bad = new Vector(v.z, v.y, v.x);

// in place, looks even uglier
v.values = [v.values[2], v.values[1], v.values[0]];

Additional context:
Handy when axis are swapped in 3D models

Create a system/unit with which world objects can be placed on the scene while maintaining a fixed position on screen.

Eg.: Placing objects at 0.1%x || 0.9%x, instead of having to rely on the ScreenSize and having to do a lot of conversions (since those measurements are in pixels/uv space, and we'd need world space coordinates to place 3D objects)

Provide a way to easily convert coordinate spaces for given Points & TransformSignals

This might come in really handy when trying to tie world space objects to face coordinate values

As of now, the idea is to have a separate function that can do the conversions, and later a user can use the VOLTS.World.snapshot to get vanilla js values if they so desire

Specs for this might change/are open to changes

Add an interface to save/fetch Persistent data.

As of now, the idea is to use the setDebounce function + some wrapper to make the process of saving/loading data easier, while preventing any bad code from overloading the API.

Note: Potential bug:

Previously, the Persistence module had a bug which caused a promise to never(/30s+) resolve, depending on the implementation, this would slow down or completely prevent an experience from running.

This was patched by using Promise.race, and was later addressed by the Spark/IG dev team, but it would be nice to be prepared for any similar bugs.

My guess is that the PersistenceModule is more reliant on the device + isn't used as much by creators, so the issue might have passed internal tests without anyone noticing. (This is pure speculation and I have no basis).

In any case, making use of Promise.race seems like the better option

Update:

The current plan is to add a high performance physics engine within Volts itself. Complete with gravity, collisions, and more.

Object3D.usePhysics()

usePhysics should take care of collision detection and response all on it's own. While being moderately fast.

The objective:

• Add accurate real-world physics. Linear, accelerated, and parabolic trajectories
• 100+ objects on scene at any given time

Tasks:

• Matrix class
• OBB Collision detection
• #18
• Optimization of OBB collisions

This is somewhat related to #6 , but probably deserves a separate issue

Once a nice interface for scene objects/bones is created, implementing a simple algorithm for this should be easy.

Will probably stay on-hold until the TransformSignal bug is fixed, but will be explored in the meantime.

This could be part of VOLTS, or a separate project/plug-in for physics/simulations

A really cool feature of the Spark AR Reactive API is that different signals have different types -- which is specially handy when working with Vectors/VecSignals

A very simple example of how to implement this currently might be:

function createVector<T>(...args: VectorArgRest): Vector & (T extends 1 ? {x: number} : {[key:string]: any}) {
  return new Vector(...tmp);
};

// note that {x: number} is part of the Vector type already, so this wouldn't be useful
const vec = createVector<1>(); // vec1 -> has {x: number}

A slightly more complex one:

In this case, NDVector could be extended/union'ed together with other Vector1/2/3/4 interfaces, which would also be great for hiding methods custom to each type (like cross3D). These functions will likely be defined on the NDVector class, and later hidden away from the type def for non-3d vectors. Completely removing the function definitions into separate classes feels unnecessary, and would likely require complex code or a confusing dev-experience.

interface NDVector {
  values: number[];
}

const NDVector = function(): NDVector {
  this.values = [1,2,3];
  return this;
} as unknown as { new (...args: VectorArgRest): NDVector; };

Unfortunately, using both rest parameters and allowing an array to be passed as an argument, might cause some confusion when types are automatically inferred. Arrays might have to default to the number type no matter their length. A user of the lib could still explicitly declare the Vector type if they so wished by calling Vector<type>

Vector<number> (fallback) will likely reassemble the current type def, which merges all possible types into one

Open to changes/comments. Likely to be included as part of [email protected]

Integrating test-driven development to ensure operations (mostly the math ones) work as intended.

Coverage would ideally include:

• Vector
• Quaternion (yet to be added)

Developing additional tests that can integrate with Spark AR Studio would be nice, but since most of the operations that interface with Spark/its APIs are simple assignments (eg. mesh.transform.position = position), there isn't as much room for error -- the only exception to this might be the Snapshot(-ing) process

Find MTV from axis overlap. Can be found within the againstOBB method, so that the axis do not need to be all tested again

This is are major changes for Object3D in the plans, going to break lots of things, especially Oimo compatibility. But the changes are worth it.

Ideas include:

1. Built in Solver (#6)
2. Decoupling rendering
3. Better performance
4. More flexibility

2.: Not as big of a deal now that premature async event support is in the works

Beta changes may break existing projects using Object3D, will be pushed on the next major release as well

Build out mock modules to use in test cases. Modules that currently need to be built

1. Scene module
2. Reactive
3. Time
4. Diagnostics

Empty mocks will be used to get initial tests of the Vector class to run

Add a compatibility layer that hooks up Volts to signal sources, to implement a seamless integration.

Opening this issue to keep track of changes related to this integration. Most changes already pushed to @beta on df00732