THREE.WebGLRenderer 76dev
Everything seems to be ok in r76dev, but that error message is not present in the current r75
Hmmm?
Hmmm?
The error was introduced with that "Added THREE.AudioContext"
THREE.Audio.prototype.load = function ( file ) {
console.warn( 'THREE.Audio: .load has been deprecated. Please use THREE.AudioLoader.' );
var scope = this;
var audioLoader = new THREE.AudioLoader();
audioLoader.load( file, function ( buffer ) {
scope.setBuffer( buffer );
} );
return this;
};
PR #8370 recently changed the Audio API. examples/misc_sound.html
shows how to use the new system.
PR #8370 recently changed the Audio API. examples/misc_sound.html shows how to use the new system
In my opinion that's a bad idea.
audio / video . src and audio / video .load() should remain untouched.
http://www.w3schools.com/tags/av_met_load.asp
One motivation of the PR was to align the loading process of THREE.Audio
entities to the rest of the library. Therefore THREE.AudioLoader
was introduced (in addition to THREE.FontLoader
, THREE.ImageLoader
etc.) and THREE.Audio.load
marked as deprecated.
To be honest, i don't understand your objection. THREE.Audio
is a wrapper for HTML5 Web Audio objects (or more precisely AudioBufferSourceNode
). Your mentioned HTML5 DOM method load
and property src
are something different.
To be honest, i don't understand your objection
In most of the cases for sounds you don't need the onLoad, onProgress, onError callbacks.
So you don't need THREE.AudioLoader ...
On the other hand, messing up the API all day long won't bring anything good.
Instead of one library for 1000 users, we'll end up with 1000 libraries for 1000 users.
I hope you got the main point.
Your mentioned HTML5 DOM method load and property src are something different.
No, it's not.
Keep the syntax for WHATEVER.audio.src and WHATEVER.audio.load() untouched.
It's much better for the future of your project.
@EvilPeanut What's your opinion?
To @EvilPeanut
I totally agree that the onLoad, onProgress and onError callbacks should be available for ANY loaded file (including sounds).
If they cannot be implemented for THREE.Audio.load, I don't have any problem with THREE.AudioLoader
But don't depreciate THREE.Audio.load !
@RemusMar The reason we deprecate things is to focus our energies in fewer code paths. The fewer code paths the less things we have to maintain. The less things we have to maintain the more progress we can do (WebGL2 features, WebVR support, etc).
@Mugen87 @RemusMar I agree with @mrdoob. The THREE.AudioLoader
follows the format of the rest of the loaders in the library and provides the onLoad, onProgress and onError callbacks. The loader should be easier to use than the deprecated methods and provides this additional functionality. I don't see a need to keep and support THREE.Audio.load
. If the THREE.AudioLoader
is missing some functionality that you require then I'm sure we can have a look at adding it.
The reason we deprecate things is to focus our energies in fewer code paths.
The fewer code paths the less things we have to maintain.
If so, why don't you create a single loader for any kind of file (3D model, texture, sound)?
Why do you need TextureLoader, AudioLoader, etc ?
Examples:
THREE.Loader( "whatever.obj", "mesh") {...
THREE.Loader( "whatever.dae", "mesh") {...
THREE.Loader( "whatever.jpg", "texture") {...
THREE.Loader( "whatever.wav", "sound") {...
Because I feel like explicit code is less prone to user errors.
Because I feel like explicit code is less prone to user errors.
In most of the cases:
explicit code = more wasted resources
good looking code = bad performances
hardcoded = best performances
Ok.
Sorry, I couldn't resist :')
Sorry, I couldn't resist :')
I'm not sure about your workflow, but be prepared for this change in a future update:
THREE.EvilPeanut = FOUR.mrdoob
cheers
Most helpful comment
Sorry, I couldn't resist :')