Stop checking isFramebufferTexture in copyFramebufferToTexture.

[chubei-oppen]

Description

FramebufferTexture was first added in #22916 because copyTexImage2D doesn't work with texStorage2D. However, copyTexImage2D was later replaced by copyTexSubImage2D in #22985, making checking FramebufferTexture unnecessary.

However, FramebufferTexture is still useful in that we don't have to set an image to allocate texture memory.

This contribution is funded by OppenFuture Technologies

[Mugen87]

I wonder if it is a good idea to allow other texture types again. FramebufferTexture was introduced to have a dedicated class for extracting framebuffer data into a texture.

What would be the use case for using other texture types? Just because something is technically possible does not mean it has a value. So why would users require this change?

However, FramebufferTexture is still useful in that we don't have to set an image to allocate texture memory.

Forcing users into FramebufferTexture means they do not need an unnecessary image to allocate texture memory. I don't fell well with enabling workflow which does not have this advantage.

[chubei-oppen]

Serveral versions ago, there was a RoughnessMipmapper used for modifying roughness mipmaps to account for the normal variation when objects are rendered in distance. Before the introduction of FramebufferTexture, it does the modification in place. After that, it has to allocate a new texture for every material.

We're keeping this class in our project and I found that removing the check brings back the old more performant behaviour.

This is the only use case I know, though I can imagine other people wishing to copy framebuffer to exsiting textures which were not framebuffer textures when created (runtime modified environment maps for example) .

[Mugen87]

runtime modified environment maps for example

Sounds reasonable. Okay, let's remove the check. It shouldn't hurt anybody^^.

[mrdoob]

Thanks!