ATP FBX bake DESTROYS Avatar FBX files


I’m going to try my very best to maintain a positive attitude on this…

I really appreciate the upgrades to the loading speeds baking offers. Especially that it is on the atp. However, nothing has changed in my avatar creation pipeline yet now new uploads are unusable. This is bug; I’m certain of it… I’ve tried using the non-baked version checkbox also. Here is an avatar made with the exact same creation pipeline that is not on atp that does function. I promise this is not a question of competency; I’ve been building avatars successfully for months and I can upload the asset in question to a webserver and it works just fine. This is a bug in the baking.
the above .fst is not file referenced or used to generate the bug


cc: @jess, @ozan


Actually, I was curious if the baking process even supported avatar files. I wasn’t so sure, so I never did test it.

Granted, I’m also not sure if the ATP even lets you call avatars properly, but then again, I’d love to be proven wrong as well.


My best-guess is the baker doesn’t care about the dough. In other words, an .fbx is an .fbx is an .fbx regardless of it’s intended purpose.

ATP loading of .fst for .fbx reference has been working just fine until the baker was included.


I can say avatars were not specifically tested for ATP+Bake operations per its testing plan as, to the best of my knowledge, it’s assumed avatars + ATP isn’t a thing since that locks them to a single domain… of course, I have used that to advantage to keep my in testing AVs “private”. @b or @huffman would be the likely “at” targets on this. I do know that you can bake an avatar for HTTP serving via the oven tool (not distributed but can be built from source). I suspect mesh compression would give troubles with rigged meshes and how ATP remaps references to textures, whether baked or not, seems troublesome with the slightly different way avatars are handled traditionally. As a matter of principle… I believe avatars should be fully supported for ATP serving as there is merit to not having them out there on a HTTP server.


Hi, Indeed it looks like baking does not work with Avatar. To get around the issue you could un-check “use baked” for the FBX. It sounds like you can also try to embed the texture.

Here’s a doc page that describes the workaround:

Hope this helps.


Thank you for confirming. I only tried this with embedded textured avatar; so unfortunately, the work-around didn’t solve the problem for me. I do thank you for the quick investigation and confirmation of the bug. I look forward to a fix.


Just to ensure I’m ‘shooting straight dice’ I can report this internally to my team as a bug; might I get a simple,

‘yes - we are fixing this’
’no- we are not fixing this’

I was and am under NDA for specific ‘situations’ and do need very clear statements about the future of this Avatar baker failure on ATP. Please, and thank you. :smiley:

cc: @Caitlyn


@AlphaVersionD - What are you doing with Avatars on your Asset Server? If you set your avatar URL to an ATP based URL it would only work on your domain… and the second you go to some other domain, you’d end up as an invalid/invisible avatar…

Can you help us understand what you’re doing with FST files on your asset server?


Hey @AlphaVersionD! Just to clarify, did you try unchecking the “Use baked” option for your avatar .fbx (not the .fst)?


Worth noting: even though this is an edge case (putting an avatar on ATP)… I just tested this with my own avatar, and even the baked version seems to be working fine. So this is probably avatar specific.Can you also clarify, what is the failure you’re seeing?


Yes. I tried that thank you.


Result is skeleton missing pop-up, followed by default avatar assignment.

Try using a .fbx with embedded assets, and an.fst on the same directory level.


This error was noted prior to beta 57.

I will confirm or deny bug validity with new release as soon as practical (typically 12 hours)


While certainly an edge case in a more global view of how HF works with moving about domains… an avatar served via ATP is certainly useful and something I used many times in days past.

  1. It’s quick/easy to test new avatars - especially when doing devel on a LAN setup.
  2. It allows an avatar to be “domain specific” (Other than pull with atp-get or cache scrape).

Personally, I think there are several compelling reasons why avatars via ATP should be considered a useful feature for a user understanding they can’t travel with you.


Agreed – I wasn’t saying this wasn’t supported per se… I was just confirming that the limitations were understood.

And note: I just tested this with my local domain, and my avatar… and it is working fine in the latest “master” build… using the baked FBX… it’s animating, etc…


I will confirm the same just as soon as possible. I have not had an opportunity to bake using latest.


I have to ponder what Draco compression does to a rigged mesh… KTX texture compression seems good and right. But, I’m dubious about the mesh compression for rigged meshes as it does change geometry and might lead to loss of fidelity where one has spent a lot of time optimizing mesh weights to achieve a better than “auto-rigged” result. Just keep that in mind for AV over ATP as when you use baked – far as I know – you get KTX texture conversion and draco mesh compression.


The goal of the baking process is to make imperceptible changes to the content while maximizing savings on processing and loading time. This applies also to the rig of a mesh.

We know there may be cases where changes are perceptible. There may also be cases like this one where we appear to have a bug and it outright fails. Please leverage the checkbox to disable baking on a per asset basis if the baked version of the asset isn’t what you expect. When you run into those cases, we’d be happy to internally test with your asset and see if we can repair or improve the baking process for that asset. I’ve reached out to @AlphaVersionD to see if I can get the FBX of the Avatar that produces no skeleton when baked.


I was going to make a " thats a half baked response" joke here but im 2 grown up for that
instead heres some muzac


As long as draco compression is always an option vs enforced (regardless of how a model is served – i.e. I would not want to see a mandate that avatars be draco compressed in order to display via Interface) … it’s all good. Weight painting a real model and its attachments is a tedious thing – far more art than science if you want really superior visuals under movement - and, with all due respect to our default woody, far more important to complex avatars/attachments where decimating vertices or any re-arrangement of their geometry could have little effect visually, but, huge effects to how said objects deforms under movement.