Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Added support for S3TC textures in ImageTextureAtlas. #538
ImageTextureAtlas node has been extended to handle compressed (S3TC) textures by simply setting the "compressed" boolean field to true.
In case the necessary extension (WEBGL_compressed_texture_s3tc) is not supported by the browser, the "fallbackUrl" field can be set to the URL of an equivalent uncompressed image (See src/Texture.js, line 267 and following).
The actual logic for reading an s3tc fileis contained in src/util/Utils.js (x3dom.Utils.createCompressedTexture2D).
Thanks for the contribution!
A question about the "fallbackUrl" (-> "fallbackURL" ?) field:
Actually, we should already have fallback URLs, that's why url should be a multi-field (MFString). At least that's the intention in the X3D standard. The idea is that the X3D browser can try the first texture URL, and then proceed with following ones if that didn't work.
I think we can have the same here if we suppose for a moment that compressed textures could be identified by their URL. That's another question, of course. In case we are not able to identify them via their URL in general, the "compressed" field could be an array of boolean values, where each field corresponds to an entry in the "URL" field.
To sum up, I think an explicit fallbackURL field does not make sense, since the existing url field should already be used to provide fallback urls - because of that, it would be confusing to have another "fallbackURL" field that is only used for the case of compressed textures.
Yes, the url field is supposed to provide alterntive urls if one is not interpretable by the browser:
Would it be possible to automatically recognize S3TC as a supported image format, such as .jpg, in order to avoid having to introduce the "compressed" field ? The logic already checks for the DDS_MAGIC number, right ?
Then ImageTexture would be able to benefit from this great contribution without change as well.
However, I am not sure if x3dom currently actually supports using alternative URLs from the url field for any node (other than ExternalGeometry) in case of failure with one URL. It looks like it may not for ImageTexture. See issue #435. I believe this would need to be fixed first.
So at this point it may be necessary to work around with a fallbackurl field.
I agree that it would be nice if #435 could be resolved first, but I would vote against working around using a "temporary" field. The reason is simply that I'm not aware of any case where a temporary field really got removed later on (if it's in the dev version, people will directly use it and complain later on if something changes).
Maybe this pull request could provide a workaround that only implements a fallback solution (using the regular URL field) for the case of compressed textures, and the more general implementation of #435 could build on this initial solution.
I completely agree, and this is also why it would be best not to introduce a 'compressed' field. The logic flow could be:
issue #435 can be divided into a general part and a node specific part. The general part would address the situation where an url is not reachable, or returns no content. The node specific part needs to address if the content is not "interpretable", eg. is not a valid x3d file (for inline) or valid image (for imagetexture) but something else (html).
Okay, sounds great, so let's figure out a proposal what @girier-tsha could do right now. I would propose this:
It is probably not easy to find a good solution for the second point, but what @andreasplesch proposed seems like a good starting point.
Thanks again for providing this contribution, this will be very useful for a lot of applications!
Thanks for your comments and suggestions.
I was very reluctant to add the
I considered using the URL list as is specified in the X3D specification instead of
As for the
I also considered checking the URL extension to decide if the image is a JPEG or a X3TC file, but it seems far too unreliable to me.
Finally, I think the two issues can be solved separately.
As for #435, wouldn't a simple for loop at the end of the
As for the removal of the
Does this approach seems practical to you ?
Thank you much for taking the time to go beyond what your needs for the node are.
Presumably, the browser will cache the image after downloading it the first time ? So hopefully the second attempt would not involve actual remote access and therefore still have satisfactory performance for your purposes. (Due to CORS remote access may be rare anyways).
A method may be to convert to dataurl after the
Not sure where the best place is to iterate through the urls of the MFString url field. @mlimper may have more insight.
Perhaps a general function can be made which returns a reordered MFString which has the first accessible URL in the first (index ) position, and all inaccessible URLs at the end ? Could src/util/DownloadManager.js be used in some way to find the first accessible url ? Such a function could then be reused for other nodes.
I followed the suggestion from @andreasplesch and made it so that, if loading a texture as a jpeg/gif/png fails, X3DOM tries to load it as a compressed texture if the corresponding WebGL extension exists on the client platform.
As an automagical side effect, compressed textures are now available for
I did not address #435, as it is another issue of its own and requires more change to the X3DOM source code than I am confident in doing without breaking anything else. In particular, some kind of feedback would be necessary so that the
Presumably, if someone was to fix #435, the functionality of
Very nice :-D
Before we merge this one, I have only one / two more things: