@RemusMar SEA3D.js is an SDK. It should have no dependence.

What dependence?
in r89 they moved "decodeText" and "extractUrlBase" from Loader to LoaderUtils.
That's all.

In this case, we should extractUrlBase in SEA3D.js

See this:
https://github.com/mrdoob/three.js/blob/dev/src/loaders/LoaderUtils.js

extractUrlBase: function ( url ) {
		var parts = url.split( '/' );
		if ( parts.length === 1 ) return './';
		parts.pop();
		return parts.join( '/' ) + '/';
}

SEA3D.js is an SDK. It should have no dependence.

Not true.
In the previous version it was:

this.config.path = THREE.Loader.prototype.extractUrlBase( url );

So we should keep them both.
Besides, SEA3D.js without THREE.js does not make much sense.

Not true.
In the previous version it was:

it is a bug.

Besides, SEA3D.js without THREE.js does not make much sense.

So one can use sea3d in another library for example... but the purpose is not this.
Today sea3d is only used for graphics, I am releasing an updates that have extended its functionality using SEA3D.js, SEA3DLZMA.js and others codes to load an entire project including a threejs(lzma-compressed and possible others algorithms) inside .sea file.

I think in sea3d.js should be like this:

if (!this.config.path) {

	this.config.path = this.extractUrlBase( url );

}

"extractUrlBase" does not exist in the SEA3D files.

If you want to make SEA3D independent of THREE, you need to include both functions from LoaderUtils to SEA3D.
In my opinion, not a good idea because It's wasted resources (memory) for nothing.

In my opinion: for r89 we should keep them how they are now.
They identified stack overflows for large strings in old browsers, they will come with more fixes,
so It's better to rely on the THREE functions for now.

"extractUrlBase" does not exist in the SEA3D files.

Yes, my suggests we should add extractUrlBase function inside sea3d.js.

In my opinion, not a good idea because It's wasted resources (memory) for nothing.

I do not think that some lines of code will overload something. My concern would be just with maintaining of code but for this case is necessary that sea3d.js has no dependency.

Yes, my suggests we should add extractUrlBase function inside sea3d.js.

Again, In my opinion: for r89 we should keep them how they are now.
We can reopen this subject after r90 release.

In my opinion: for r89 we should keep them how they are now.
They identified stack overflows for large strings in old browsers, they will come with more fixes,
so It's better to rely on the THREE functions for now.

https://github.com/mrdoob/three.js/blob/8701e404874bc603b814b7ea50aaf5216cd2c9ef/src/loaders/LoaderUtils.js#L23

You're sure this work for oriental characters?

You're sure this work for oriental characters?

No, I'm not.
But let's give them some time to fix all the stack overflows.
We will create

SEA3D.LoaderUtils.prototype = {

starting with r90.
Don't you agree?

No, I'm not.
But let's give them some time to fix all the stack overflows.

Try naming a 3d object in sea3d to 日本国 and test with the current stack overflows approach. It is not work.

Try naming a 3d object in sea3d to 日本国

Can they do that in THREE ?

Can they do that in THREE ?

Not using this approach. Its work done to ASCII but not UTF8 (pure).

We updated SEA3D for THREE.
If they cannot do it in THREE r89, is not our problem.

We updated SEA3D for THREE.
If they cannot do it in THREE r89, is not our problem.

No, no! SEA3D must have support to oriental characters. Three.js can use oriental characters with another approach if wish. It is important that the sea3d.js approach work done.

I tried to keep.

return decodeURIComponent( escape( String.fromCharCode.apply( null, new Uint8Array( buffer ) ) ) ); 

But they didn't like the idea.
Read again these messages:
mrdoob/three.js#12911

Today I can not it because of lack of time, but tomorrow I am going to do a PR in threejs about it.

It's better to make a PR on their LoaderUtils.
Otherwise we'll have the same problem again and again in the THREE future updates.

See the latest SEA3D update.
Now it's Independent of THREE and includes your fix for multibyte characters.
cheers

I see, I see. That is it, I will merger it soon.
Thanks!