[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Adding internalformat param to all texImage2d variants



HI,

>> 
>> This can be easily done during runtime as part of your standard-shader
>> but we just have to know it upfront.
> 
> Yes, this is the original discussion. But you only need to know the original format because that's how X3D defines it today.

Right. We only need to know. Can be RGB or RGBA or anything we understand at the end. 

> In fact X3D is deficient in that, if you have an RGB image and want to use it as an alpha channel you can't.

Correct for the standard lighting model. But you can use the shader component and your are free to do whatever you want. 

> X3D has no property to indicate that the image should be stored in texture memory in the requested format. 
> 
> My proposal would change the rules of the X3D ImageTexture. You'd have to add a format property, where you specify what format you want the texture to be. There might be some incompatibilities in a small amount of X3D content, but I think you'd have a better ImageTexture spec.

I don't agree. Putting a extra "format" parameter to the ImageTexture spec would not lead to a better ImageTexture interface:

- What should this format be if you use the ImageTexture e.g. as shader property ?
- Source of confusion if the image and format do not match. What should happen if somebody changes the url during runtime ?
- You can not reuse the ImageTexture with a different format.

We could add something like an diffuseSrc to Material. This could be "material", "texture", and "auto". 
"auto" would be the default value but not work on WebGL.

But this would just be a different interface on the X3D(OM) layer. 

> 
> The browser vendors (including me) should look at their implementations to understand if it's even practical to get and maintain the original source image format.
> If it is, we can certainly allow a "SOURCE_FORMAT" internal format value which would keep the format intact (although this would likely require conversion in some cases since most browsers keep images around as RGB(A)). In that case we could also add a get() method which would give you back the current format of a given texture object (maybe that method already exists?).

We really don't need the original Image or pixel. Everything can be RGB(A). We just need to know the original channel configuration. So if the browser vendors would provide a function in the image object to retrieve the original format description (not the pixel) would really help in our use-case.

best regards
johannes

> 
> 
> 
> 

--------
Dr.-Ing. Johannes Behr	tel: +49-6151-155-510
Fraunhoferstr. 5			fax: +49-6151-155-196
D-64283 Darmstadt		skype: johannesbehr
Germany				web: www.igd.fhg.de/www/igd-a4/


-----------------------------------------------------------
You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: