[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Adding internalformat param to all texImage2d variants
Am Fr, 14.05.2010, 17:08, schrieb Chris Marrin:
> On May 14, 2010, at 6:19 AM, Johannes Behr wrote:
>> Hi Crhis,
>> thank you and everyone involved in this effort!
>> As far as the X3D/X3DOM relevance goes:
>> This proposal would certainly help to control the final format but
>> we still would need more information about the original format.
>> How should we know if there where RGB-channels in the original format or
>> Remember: We do not have a controlled data-preparation step or process
>> with X3DOM based application. All we get inside of the X3D-stream is
>> a reference to the external image-data. No additional information on the
>> format is provided inside of the XML-stream.
>> But, according to the X3D-spec, we must shade the geometry differently
>> depending on the channel-setup of the image (wise or not):
>> One example:
>> If we have an A, L or LA image we use the diffuseColor from the
>> If we have a RGB or RGBA the diffuseColor is not modulated.
>> 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. 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. 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.
Indeed, many people think that X3D lacks this functionality. That's why most
X3D players implemented an additional "internalFormat" texture node field...
> There might be some incompatibilities in a small amount of X3D content, but I
> think you'd have a better ImageTexture spec.
I absolutely agree, this is missing. Anyway, the internalFormat in most cases
is used to convert a given texture into a floating point precision format etc.
Hence, IMHO both concepts are orthogonal to each other, since converting a
texture is different from just wanting to know (for whatever reason) what the
original image format was.
> 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
Yes, this would be really great!
> 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
Good question, never found such a method...
Fraunhofer-IGD | Tel.: ++49-6151-155-290
Fraunhoferstr. 5 | Fax.: ++49-6151-155-196
64283 Darmstadt | email: email@example.com
Germany | http://www.igd.fhg.de/igd-a4
You are currently subscribe to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: