Beta Release 39


HOTFIX update for T-Pose Avatars
HOTFIX 2: Fix to bad Audio for people on wifi
HOTFIX 3: Fix for the fix for T-Pose Avatars - includes protocol change, sorry!

Beta Release 39 includes up to Developer Release 6457 and includes a protocol change; you will need to update High Fidelity in order to visit domains running this new version.


You can now send out alerts about events happening in your domain! Go to Snapshots and choose “Blast to my Connections” to give it a try.

And also:

  • PAL WebView is now a TabletWebView
  • Lots of Snapshot app improvements
  • “Set Availability” UI changes
  • Fix deadlock from accessing an initializing tablet
  • Fix reliability of keyboard enabling in tablet Web pages
  • Grab is driven by timer rather than update, load tablet model with high priority
  • Fix tablet webview showing incorrect url.
  • Fix for resource downloads getting capped
  • Fix deadlock from minimizing
  • Prevent possible crash in texture buffering thread
  • Fixing the the mip gpu copy for compressed format texture in GL41Backend
  • Fix event enum
  • expose more bullet constraints to javascript: slider, ball-socket, cone-twist
  • spring action can now be rotational, translational, or both
  • spring action can now have targets relative to another entity
  • Fix numeric keys not displaying in social media sharing dialogs
  • Guard against bad hinge-constraint settings
  • Don’t warn that recording didn’t start playing if you stop it
  • Migrate Avatar rendering code to library
  • Fix OBJ material loading not working over ATP
  • Fixing the by region update transfer of the compressed texture
  • Store irradiance in cached KTX files
  • Fix progressive loading of KTX skybox textures
  • Fix potential crashes when loading invalid KTX cached textures
  • Removing logspam on toggling scripts window
  • Feat/normal map compression
  • Expire announcement when announcer leaves.
  • Announcement Card visual tweaks.
  • Fix – dont send non-entity edits to entity-server


High Fidelity is impossible platform to work with.
Just updated to beta 39, and my materials and look on objects are complete screwed again.
Just the same did happen as with the previous beta 38. it’s changing material settings. It did look good. Until you update to a new version. and POOF. things are extreme reflective. Or normal map seems to be stronger this round. the object with the changed normal alos lost the deep color it did had before.

Pfff. :angry:

And i still need to kill maual after every use of interface.exe the VR compositor and VR Dashboard VR server get killed automatic after killing the other two. And i told STeamVR to not run STeamVR. Still hifi starts it ! :rage::angry:


Hi @Richardus.Raymaker can you send me your models with the issue with some picture?


Well, it’s a bit difficult to send the example. i tried and just tesed a basic one. but blender seems todo very weird things with 2.78 (i have Version C) It’s adding extra copy of the roughness texture to the FBX when i export it.

So i end with 2 roughnes maps. One have no assignment to anything. The other is assigned to hardness. This could be the problem. I first need to do some checks to see if a texture is not in the same directory by accident as everything else.

The one with normal map i have not checked. FBX is just a painfull format, because it’s not open format.

ADD: In this case it’s exporting 3 texture maps if i do it with copy. so that seems correct.
If high fidelity would handle not embedded textures correct it would save lot’s of troubles. But not embedded textures i have tried it are really a neightmare.


With external textures (i think it did use that now) it looks the same metallic. So something is possible screwed again in this new build. need to fiddle with sliders in blender again to get it right i think. There’s no logic workflow in PBR with blender and high fidelity.


Don’t use embedded textures.

FBX files with FST files that reference an external texture directory work fine and consistently. Zero issues for me that way.

It’s not ideal or efficient to be packing textures anyway, because if you later want to change only 1 of the textures in a model that has dozens of them, you would have to reupload the entire FBX with all textures for any tiny change. Whereas with external textures, you can just reupload only that 1 texture you want to modify. It’s much more efficient that way.


I agree external textures would be better. But nobody ever made a tutorial how todo it with high fidelity. Never heared about a QST file. And because embed gave less problems you use that. And i still keep using it because external fails to load.

Possible because i not use any QST file or what it will be.

ADD: Did a quick google. No (usefull) info that is making QST usefull to understand with high fidelity.


You do mean fst files. CC @Richardus.Raymaker.


Yes, typo. I meant FST. :slight_smile:

There are posts by Menithal here on the forums about how to use the FST file, you can find them by search.

By the way the texture directory can also be a directory on your ATP server. It doesn’t have to be a remote web host. You can also upload the FBX + FST to your ATP, while the textures are on a remote web host instead (Just change the texture dir in the FST file to reference the web location). Since FBX files are generally not that big in file size, while textures ARE, this is a great way to remove the bandwidth burden from your local host.


Your funny :smile:
Finding something on this forum ? It’s disaster to search on this forum. also because the use CTRL-F that my browser use for find for search on this forum itself. Search on this forum is really a disaster. I avoid searching on this forum.

I just tried it btw, not much result. You just need the rigth words.
But i can guess it works a bit the same as the Fuse avatar FST… but just copy the Texture data into from the object.

It can work without FST mabye. i just found this.

I need to see if that trick is fixing the porblem, always expected the textures need to be in the same level as the FBX. Only thing i found so quick.

ADD: Tried above trick, tried out of my mind a guess with the FST file. both failed. I need to find more info first.


The fst trick is mostly for textures not embedded to the fbx. just as a side note. it is also 2years old.

You actually by default generate it when you package the fbx in high fidelity, but it wouldnt do anything to embedded textures which you are having issues with (not sure with what exactly, again if just resolution it is the build version, use debugDefferedlighting to debug issue)


Well, the problem is when i do not embed textures but just use copy.
The object in high fidelity keeps complete blank. Blender makes a directory fbxfilename.fbm and put the textures in there. it did fail. i moved it out of that diri think it still did fail. only when things where on the top level on my hdd it did seems to do something. If you could tell in high fidelity in the object what directory to look for the textures. It would mabye more easy.


If it is interpreting it as fbm texture, then that means that is considering it is looking for embedded textures.

You can point to specific directories as well

But here is a few things to note:

If not using fst overidde, the textures will be relative to the model. So forexample if I have model that uses textures within child directories, they must also be within the child directories.

if you have textures in the following configuration work fine

  • modelA
  • textureA

but note that The following will not work atm after some experimentation (this may need looksie)

  • modelA
  • dir/textureA
  • …/dir /textureB

If you create a packaged fst file of modelA, then you must have

  • modelA
  • modelA.fst

But in that case, the textures also must be uploaded..

there are modelA.fst points via texdir to the directory where all the textures are, but they must be within the root of that directory and cannot be in child directories Note that for some strange reason (@sam) the fst always seems to add /textures at the end of the path. even if relative or non relative

You can also use the texture field to replace any textures within High Fidelity. by pointing an absolute url to the file using edit.js. You can do this by copying originalTextures to textures, and simply changing the url of the texture.

Note however that when you do this for roughness it will be roughness, regardless if the model was made in blender.


Oww, Complex high fidelity logic am still forget that.

You need to pack the model with seperate textures first.
Then you can import the model, and easy replace the textures after that.
It looks now at least not shiny anymore. well the shine is complete lost right now.
If hifi support Reflection map and i know the setting in blender it possible can work.

Btw: how it looks now also got that result with embedded textures. Mabye i have now problems with some bug you talk about.