A strange thing about asset requests

#1

Ok - this is hard to explain, but, easy to document.

When Interface makes a request for a physics shape as a .obj file it’s also making a strange set of additional requests. Here’s what you see in http server log;

x.x.x.x - - [13/Jan/2016:20:30:40 +0000] "GET /asset/506c13cb798df8967bdb02a0d654983fc14688d4ccfa08a8c0378a4fb3dab36b.obj HTTP/1.1" 304 0 "-" "Mozilla/5.0 (HighFidelityInterface)"

Ok - that’s Interface asking for a compound physics shape with HTTP server returning 304 for not modified as is proper. All good. Then it immediately sends requests for;

x.x.x.x - - [13/Jan/2016:20:30:40 +0000] "HEAD /asset/506c13cb798df8967bdb02a0d654983fc14688d4ccfa08a8c0378a4fb3dab36b.jpg HTTP/1.1" 404 0 "-" "Mozilla/5.0"
x.x.x.x - - [13/Jan/2016:20:30:40 +0000] "HEAD /asset/506c13cb798df8967bdb02a0d654983fc14688d4ccfa08a8c0378a4fb3dab36b.jpeg HTTP/1.1" 404 0 "-" "Mozilla/5.0"
x.x.x.x - - [13/Jan/2016:20:30:40 +0000] "HEAD /asset/506c13cb798df8967bdb02a0d654983fc14688d4ccfa08a8c0378a4fb3dab36b.png HTTP/1.1" 404 0 "-" "Mozilla/5.0"
x.x.x.x - - [13/Jan/2016:20:30:40 +0000] "HEAD /asset/506c13cb798df8967bdb02a0d654983fc14688d4ccfa08a8c0378a4fb3dab36b.tga HTTP/1.1" 404 0 "-" "Mozilla/5.0"

HTTP server responds with 404 - Not found as is proper since there are no such files.

Now - why is Interface doing this? It’s no wonder I notice a much much slower scene populate cycle when I have hundreds of models present with compound shapes. But, even if the overhead would be considered negligible for those superfluous requests - they’re still superfluous. It’s also odd that user agent string changes from .“Mozilla/5.0 (HighFidelityInterface)” to “Mozilla/5.0” and method changes from GET to HEAD.

@chris

#2

Interface has been doing that for a very long time. I get that sequence when I load an fbx model that includes references to textures. Then interface does that xxx.jpg/.jpeg/.png… for every texture in the mdf. And too it gets it wrong because it does not understand relative folder paths.

This is a huge performance and asset loading bug but it is treated as very low priority by HF staff. We’ll have to wait until their big HMD/controller push ends to hope for a fix, and that is not until the next few months.

#3

Well, while in discuss asset mode - I’m also seeing totally random fails in processing embedded FBX textures - I’ve noticed some models load without textures about 1 out of 10 times. I initially blamed it on ATP so I moved back to HTTP. Now I see if loading an FBX with embedded textures - model loads, textures don’t and I see in HTTP server log - 404 for textureX.jpg – which is correct as it’s embedded in the FBX not sitting around to be fetched on its own. So what’s up with that? Tracing that down is how I came to find the weird requests for original post.

It’s a shame if they’re ignoring this - it probably is also connected to a lot of other weirdness and seemingly random fails.

#4

Also - with compound physics shapes a central point is they have no material thus no texture - that’s how vhacd-util generates its .obj files and what physics processor seems to want. It looks like .obj reader is trying to fix a problem for a .obj that’s an actual model vs a physics shape (since both forms of .obj is Wavefront OBJ spec). This adds an additional time penalty to processing physics shapes as object reader is not only making futile requests for material data it’s also spending CPU time evaluating things that aren’t even (as far as I can tell) applicable to task at hand.

All this stuff adds up rapidly and is not something that should be seen in code aiming to be massively scaled and high performing.