So I’ve been trying to optimize my glb model, but it seems like my textures always disappears? Is there something I’m doing wrong here or is this just not possible to keep?
If I put the optimized glb model into https://sandbox.babylonjs.com/ the textures are missing.
If I put the optimized glb model into https://gltf-viewer.donmccurdy.com/ - I can see the textures.
On the optimization viewer the textures are also missing, guess since its a babylon? - However when I import it into my threejs project the textures are also missing.
Example is below
How it looks after optimization:
I have tried all of these options - I’m optimizint it on 1K with 100% target mesh resolution
Would you be able to provide the e-mail connected to your RapidCompact account and the raw or rapid IDs? With that info we can check what went wrong.
On first glance, we can not reproduce the issue.
We would only recommend the atlas baking method in case you have a single asset and not a whole scene (all scene maps baked on one atlas loose alot of quality even with 4 or 8k resolution).
Therefore, for this type of asset we recommend using the “Preserve UVs” method, 1k texture resolution and draco compression. Attached a screenshot of the file reduced to ~30mb without too much quality loss:
We also tested a 250k mesh resolution, which actually looks fine as well with the same settings and gets the filesize down even further to about 15mb.
From the error logs we can see that the baking process reports some errors in terms of meshes without UVs but with Textures assigned. Howeve in our tests that made no difference.
Hope that already helps!
The black sidearms of the chair are actually coming from the occlusion. If you dissable occlusion baking the original grey texture/color will be visible.
This seems to be an issue due to the set-up of the model and the baking warnings I mentioned above (we can not correctly bake onto wrong or missing UVs, thus the parts with these issues will be covered black from the occlusion map). I will check with our engineers if this is something on our side, but so far it looks like this is just a limitation of UV preservation and ao baking (which requires propper UVs for all meshes, or ao baking into a newly generated 2nd UV set). The latter is possible with the “preserve tiling” option, I will investigate if we can add this to the preserve UV function as well.
It also seems that currently ao baking is active if the “Preserve UVs” workflow is chosen. I opened a cloud developer ticket for this, so you will be able to turn the ao generation off for this workflow.
In addition our core developers will look into the origin of the black sidearms due to the ao baking (the ao should be baked onto the 2nd UV channel, which is created by RapidCompact). Is this asset by any chance using multiple UV channels in the first place? That could indeed be the problem here.
In reply to the above, I don’t really know - Im mostly a newby when it comes to blender and some of the models are imported, if licensing approved of it. So maybe that could be an issue aswell? - So wouldnt really be able to tell you in all honesty.
Where would I be able to find Occulusion baking to turn that off?
For now we would recommend the “Preserve Tiling” workflow for this asset. There you can dissable the ao baking under “Materials&Baking” section inside the Preset Creator → Asset Simplification.
The “Preserve UVs” workflow unfortunately does not expose these settings yet, we will fix that within the next update!
Alos it seems like the ao error (black parts) is coming from inverted normals in your input model (sidearms of the chair, mouse and keyboard, legs of the table):
Cheers a ton for the feedback, I’ve managed to try different settings as you proposed and aswell fixed the normals! Super helpful, however I do have one question. For whatever I try and do, it seems that I cant reduce the file size that much, roughly close to the 100mb?
I haven’t tried to export it from Blender as a DRACO model but I tried from Rapidcompact itself?
Yeah the reason is that RapidCompact has an automated breaking detection which usually kicks in earlier if you have complex constraints such as preserving the UVs. Meaning if RC realizes that while preserving your UVs and trying to reduce to e.g. 50k faces, the UVs or mesh topology would “break” it reverts to the point where it breaks and adds ~10% faces on top to be on the save side.
This mostly guarantees non-broken meshes while still applying the constrains (other optimization software usually just return broken results which are technically “correct”)
You are able to apply draco compression in the export settings under mesh compression in the glTF/glb file format tab!
Hope that helps!
@juliandgg3d Hi Julian, is it possible you still have that 15mb file size available to you? for what its worth im not able to downsize the file that much, would love to see how that performs
I stored the 15MB file, accessible with the e-mail you registered on the RC platform. You should have gotten a OneDrive notification and link to your e-mail.
Also we could see that with the Web UI this results seems to be indeed not possible (lowest we could get is 50mb), we will investigate the reason behind that.
We found out that the mesh crompression method “dracoLossy” (see screenshot below) is not applied correctly in the UI. To get the file below 50mb we recommend to use the setting “draco” instead for now, until we fix the “dracoLossy” setting.
@AFluffyFloof Quick Update: The dracoLossy issue was fixed