search

mrdoob / three.js

JavaScript 3D Library.
https://threejs.org/
MIT License
102.65k stars 35.37k forks source link

OES_texture_float is missing on Android. #18819

Closed imokya closed 4 years ago

imokya commented 4 years ago

OES_texture_float is missing on Android. The default android browser doesn't support float or half floatI type. Is it possilbe to make GPUComputation android compatible?

Mugen87 commented 4 years ago

OES_texture_float is missing on Android.

I'm afraid this statement is not true. It might not be available on your device, but many others support the extension.

Is it possilbe to make GPUComputation android compatible?

Are you referring to GPUComputationRenderer? Well, it's not possible to use the renderer if OES_texture_float is missing. And the concept of GPU computing without floating point textures is very limited and thus not practical.

Can you try to use WebGL 2 on your device?

yomboprime commented 4 years ago

GPUComputationRenderer uses HalfFloat type on some devices to allow more compatibility. The line deciding to use HalfFloat is: type: ( /(iPad|iPhone|iPod)/g.test( navigator.userAgent ) ) ? HalfFloatType : FloatType,

Could we make other Android devices also use HalfFloat where OES_texture_float is not supported?

mrdoob commented 4 years ago

Yeah, seems like we can improve the robustness by checking the available extensions instead.

yomboprime commented 4 years ago

Yeah, seems like we can improve the robustness by checking the available extensions instead.

Yes, a direct check seems the way to go.

yomboprime commented 4 years ago

The default android browser doesn't support float or half floatI type.

Oh, now I've read this. HalfFloat is not supported.

Still, adding the direct extension check is appropiate.

yomboprime commented 4 years ago

I wonder if using a normalized unsigned integer texture would be feasible.

Mugen87 commented 4 years ago

I'm not sure this is worth the effort. If devices do not support floating point textures, I doubt they have sufficient performance for a meaningful usage of GPGPU.

Mugen87 commented 4 years ago

To explain my argumentation a bit more: I've made the experience over the last years that certain techniques don't reliably work with WebGL 1. In the sense of there many devices which do not support required extensions. You can then decide to exclude these devices or provide fallbacks often with worse performance and quality. In any event, users might be disappointed that certain library features don't "just work". And that means higher support effort.

I think stuff like GPGPU, deferred rendering, DoF, SSAO any surely some other techniques can be implemented and used much easier if you just target WebGL 2.