You could export your model by using all available options and then, size / quality wise, compare their outputs to see if any of them might work for your purposes.
Any other options that you might require would involve using the command line in terminal, as you might find as a suggestion in some other topics.
This viewer can be used as a standalone so modify and improve whatever you can.
Viewing the exported models in any GLTF Viewer would require that it has DRACO and / or MESHOPT decoders already included plus any texture extension that might be required.
That’s awesome!! Might I request drag and drop? And also maybe a link to the boilerplate for setting up the loaders with meshopt+ktx2 etc? Then I can direct people to one stop for optimizing and how to load the optimized meshes.
Cool stuff!
Good stuff. I’ll be sticking with gltf.report for now though, as it’s more mature.
Kudos on having the WebP option, I think gltf.report might be able to do it but I’d have to check the gltf transform docs for that.
What I’d really love is for options to convert textures to KTX2 formats, so that 3D modellers can send me a fully optimised model when working on a project.
KTX compression appears to only be available in command line interface, so there is no way for me to include it as a web option.
I have not included either drag-and-drop or ZIP support in any of my viewers and not really looking to do so.
This is not to stop anyone from trying to improve it on their own since this viewer’s HTML file can be used as a standalone. If somebody does come up with a code that can be weaved into the existing code then I could include it as well.
There is now KTX2 support included with a choice of either ETC1S or UASTC. Even though it appears to work properly it should be considered as experimental.
A recently posted ktx2-encoder on NPM is providing this KTX2 support and appears to be doing it properly. Do note that this process can be a little bit slow so just be patient.
My GM Viewer’s menu controls were adjusted and my initial post was updated to reflect this new change.
This is just a little bit late of a reply to the question by @manthrax about boilerplate for setting up the loaders with meshopt+ktx2 etc.
Try to take your time and just inspect the code of my GLTF Viewer where you might observe that:
most of the stuff is setup within the importmaps and module scripts on the top of the document:
this is applicable to both loading and exporting
all the imports that start with ../static/jsm are actually calling modified version of the components and can be replaced with three/addons to call the official components instead
creation of the gltf_loader is done in the init function after the renderer is created:
this is where KTX2 and DRACO and MESHOPT are attached to the gltf_loader
You will not get overwhelmed with the code if you can focus only on the parts that might be applicable to your setup.
Everything can be simplified and rearranged, maybe look at the official three.js examples where they usually contain the code within the module script.
If you might be interested in exporting only, then observe the export_gltf function:
this is where the draco_compress and meshopt_compress functions are called so check those functions as well
some of my other viewers also have the same setup which allows for other formats, like OBJ and DAE and 3DM etc, be exported as GLB with compression applied.
I wasn’t suggesting making the boilerplate available for my benefit. I have all that in my workflow just fine. I was suggesting you make it available on your site as a popup or something, so that users don’t use your site to compress a model, and then end up here asking how to set up the loaders, aka one stop shopping!
Additionally If I could drag a .glb file onto your website and get meshopt+ktx2 compressed output, I would definitely use that, and direct users there for ease of implementation!
I’m not sure why there is so much inertia to supporting drag and drop of files?
Locating files with the file picker is a horrible user experience. That alone is enough to keep me using the commandline tools.
However imo meshopt without ktx2 is of limited use. Glb file size is often dominated by texture size for the majority of models, so ktx2 is a huge win there.
Additionally, vertex dense geometries tend to be much larger files, (point clouds, giant environments) so if that is a limitation for doing compression on the web, then again, I would probably default to the commandline. The commandline tool is multithreaded, and can handle files on the order of gigabytes.
I like what you’re building… it looks like a very capable tool, but some basic quality of life features are going to prevent it being widely adopted.
You have a gigantic spinning 2d logo that serves Zero purpose, with a TON of UI scrunched up into the header bar of the page. There are 2 buttons for choosing files, with no indication of what they are/what they mean.
As a user this would be fine if I could drag a .glb file onto your spinning logo, and it would load my model and display it. As it stands that is not the case.
I’m not clear on the reasoning behind this design? Is there something I’m missing that prevents it from being as seamless/usable/uncluttered as something like:
@manthrax there is only one thing users should realize, which is that all they need to do is pay a single visit to my repository, download GM Viewer.html file to their device and run it from their device every time they need some GLB file compressed. This way they would not need to visit my webpage ever again.
Since this file is standalone, all they would need to remove from it is a single line on top that actually looks for favicon.ico in my repository. Once this line is removed then the file will be like their own and they can modify it if they wish.
By the way, the picture of the GLTF Viewer that you posted doesn’t really do it any justice since it doesn’t show as maximized on the screen. I never really suggested to users to actually use this GLTF Viewer for compression but to only look at its code and try to use whatever parts of it they can in their own projects. And KTX2 support is included.
This is a notice for all who might have downloaded the GM Viewer.html file previously.
It appears that revisions of the ktx2-encoder beyond 0.0.0-experimental.5 are not importable by the esm.sh network so this has been corrected on my end with hardcoding of the experimental version. Maybe update this import on your end as well.
Also, for those who might be interested in trying a slightly stripped down mobile version of the GM Viewer then check this link. Maybe try it and see if it works for you.
As it was suggested before, KTX2 exports do take some time to process even on a desktop and not to mention mobile hardware requirements that might be needed for certain models. My testing of standard damaged helmet model did complete the export in Chrome browser on Huawei P10 mobile phone.