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
The intent of this issue is to tease out the things that we can do about this. Two things I see right off the bat:
a) the CubicVR "pass in a URL for the simple case" style of resource loading is much nicer (ie simpler & higher-level) than our resource loader. I suspect we want to adopt the CubicVR style, and push most use of the resource loader down into the engine, so that callers never see any of that complexity unless they actually need it for some reason and explicitly decide to use it. Mostly, but not entirely, separately from that, we may want to look at PreloadJS and see if it makes sense to use that instead of continuing to roll our own loading code.
b) for things that are part of the default distribution (eg the cubicvr extension), I think they ought to be there by default, and the user shouldn't have to explicitly declare a dependency on them and register them manually.
There are almost certainly more things we can do, but I wanted to get these written down while they were still in my head and before getting pulled into something else.
The text was updated successfully, but these errors were encountered:
@jlongster pointed out that https://github.com/gladiusjs/gladius/blob/develop/examples/camera-rotate/camera-rotate.js and https://github.com/cjcliffe/CubicVR.js/blob/master/samples/basic/cube_viewcontrol.html are demos of similar complexity, but the Gladius version feels a bunch heavier. It also takes twice as many lines. This seems like it creates non-trivial barrier to entry for using Gladius, and hurts ease-of-use.
The intent of this issue is to tease out the things that we can do about this. Two things I see right off the bat:
a) the CubicVR "pass in a URL for the simple case" style of resource loading is much nicer (ie simpler & higher-level) than our resource loader. I suspect we want to adopt the CubicVR style, and push most use of the resource loader down into the engine, so that callers never see any of that complexity unless they actually need it for some reason and explicitly decide to use it. Mostly, but not entirely, separately from that, we may want to look at PreloadJS and see if it makes sense to use that instead of continuing to roll our own loading code.
b) for things that are part of the default distribution (eg the cubicvr extension), I think they ought to be there by default, and the user shouldn't have to explicitly declare a dependency on them and register them manually.
There are almost certainly more things we can do, but I wanted to get these written down while they were still in my head and before getting pulled into something else.
The text was updated successfully, but these errors were encountered: