You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To make a lib a better Threejs player we should allow Threejs primitives to be customized via the public api.
Care need to be taken not to be merely passing many options.
This includes:
Scene
Renderer
Camera
Controls
Lighting settings
Fog
We can either
expose these objects as props
allow a primitive to be injected via the constructor
allow them to be customized via new constructor arguments (ex 'sceneOpts')
We can define an approach per case.
Some examples:
1 exposing as prop
If we expose the scene, it can be customized
const preview = new GCodePreview({ ... });
preview.scene.fog = new THREE.Fog( 0xcccccc, 10, 15 );
2 inject
For something like fog it makes sense to allow it to be injectable by itself
const preview = new GCodePreview({
fog: new THREE.Fog( 0xcccccc, 10, 15 )
});
3
const preview = new GCodePreview({
sceneOpts: {
fog: new THREE.Fog( 0xcccccc, 10, 15 )
}
});
The text was updated successfully, but these errors were encountered:
I tend to like the simplicity of exposing the scene.
We don't want to add an abstraction layer on top of Three for almost everything, and support upgrade breaking changes.
The problem with that option is that we don't have control over cleanly disposing of things that would be added to the scene in external context of the renderer class. We also remove all children at each call of render(), which would be incredibly annoying. It's a false promise of flexibility.
I have partial ideas that complete each other out.
Of course, we'd have to override anything on the scene we must set. I'm not sure how risky that approach is. sceneAppend could accept an array of anything that is addable to the scene. We can manage the lifecyle.
To make a lib a better Threejs player we should allow Threejs primitives to be customized via the public api.
Care need to be taken not to be merely passing many options.
This includes:
We can either
We can define an approach per case.
Some examples:
1 exposing as prop
If we expose the scene, it can be customized
2 inject
For something like fog it makes sense to allow it to be injectable by itself
3
The text was updated successfully, but these errors were encountered: