Too long filename prevents load of texture in three.js - three.js

This is totally unbelievable. It is so that a man can go crazy. I was loading textures from a filepath like this:
pic/ekiFear.jpg
pic/ekiAnger.jpg
and so on...
The pathname is not even long but is nested into quite a deep directory if starting from the C:// or something like that. But that should not matter in this case since I am almost in the same directory?
However I had a couple of textures and the way I loaded them was indentical but only the "ekiFear"-texture loaded. The others didn't appear but there was no error message when trying to load them.
Anyway I shortened the filenames but this is madness. What if I had not had one texture with a short name. I would rip my hair before finding the problem. I don't think it should be like this. Should I send the code to MrDoob or is the problem something on my computer?

Related

All my barrels are named index...and its confusing

Im working in VSCode in a large project with lots of barrels. It's bothersome and unnecessarily confusing that all my barrels are called index. The file path helps to differentiate but I would like to be able to more easily differentiate between barrels. Is this possible?
Idk if this is where I would ask this question, but i searched all over the internet and couldn't find anything.

Inserting an inline icon in an .rst file

I am trying to insert an inline image into an .rst file, with no success. I've tried replicating the syntax used by the previous tech writer, as follows:
|icon-copy|
The name of the image file referenced by the above syntax is studio_icon_copy. However, creating an image file called studio_icon_additional, and using the |icon-additional| syntax, doesn't work. I verified that this is the syntax used for all working instances of inline images.
I have also verified that the studio_icon_copy in the folder I'm using is indeed the right image by making a slight change to it and verifying that I see the change on the front end. I've also made sure that the new image I've created is in this same folder.
I've even tried copying and pasting the correct syntax in the desired place and simply replacing copy with additional, which didn't work either.
For what it's worth, I use Notepad++ and work in GitHub. After trying the above I have no clue how to insert it correctly, although I'm pretty sure I'm missing something.
Thank you.

Actual quote from https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#substitution-definitions says:
The |biohazard| symbol must be used on containers used to
dispose of medical waste.
.. |biohazard| image:: biohazard.png
This should be actually this way:
.. |biohazard| image:: biohazard.png
The |biohazard| symbol must be used on containers used to
dispose of medical waste.
Always declare |pic| before referencing to it. I think there were some changes to that and documentation wasn't actually updated. You can always add option to make it really small, then you've got certainty that it will look good next to text:
.. |biohazard| image:: biohazard.png
:height: 25px

Globbing a bunch of .pkl files into one, then converting to .fbx (on Windows)

I'm experimenting with the beautiful frankmocap, feeding a video and getting a quite accurate hands and body tracking. This tool also outputs a .pkl file (which I'm not familiar with) for each frame.
I'd like to convert these files into a usable 3D file but 1. I've discovered I can't use glob.h with ffmpeg on Windows and 2. I cant' get them converted in .fbx.
Along with frankmocap, I've tried VIBE but I still end up with the same problem.
Using miniconda3.
I hope someone can help me! Thank you for your time.

Someone has taken a useful script made for VIBE and adapted it to work with FrankMocap keypoints.
The script takes a folder of PKL frames generated by FrankMocap and then uses Blender to animate them into an FBX rig. It doesn't currently include the hands though, which is something I'm currently trying to solve in it myself (and how I found your question).
Link to the script: https://github.com/facebookresearch/frankmocap/files/5750266/fbx_output_FRANKMOCAP.zip

When cola.js fails, what's a fast way to find out what went wrong?

When cola.js fails, how do you find out what went wrong?
I don't have a minimal reproducible example, because that will likely take hours of debugging to make, and if I had it, then it wouldn't be an example of what I'm asking about. I'm hoping to hear of a way to quickly find out what's gone wrong. Presumably it's some bad data in my graph. But how can I tell what the bad data is?
The screenshot below illustrates a typical situation where something has gone wrong. Various NaNs are reported, there are a bunch of Uncaught TypeErrors, and an Assertion fails. There are a whole lot of local variables, all named with a single letter. Clicking and looking at them shows that a NaN got into a coordinate somewhere, as suggested by the previous error messages. It looks like sometime earlier, something got a null when it needed some sort of list-like data structure. How can I quickly find out what was the bad data that got into the graph?
I'm using cola.v3.min.js.
Details
I'm looking for a general approach to finding this kind of error, but here's the specific data that produced the errors in this example. Each line is the argument passed to cy.add() (as suggested by Stepan T.—and printing out everything passed to cy.add() might turn out to be the first step of the answer!).
{"group":"nodes","data":{"id":1,"label":"Workspace","parent":[]},"position":{"x":45,"y":0}}
{"group":"nodes","data":{"id":2,"label":"Target(121)","parent":[1]},"position":{"x":5,"y":0}}
{"group":"nodes","data":{"id":3,"label":"WantFullySourced","parent":[]},"position":{"x":50,"y":0}}
{"group":"nodes","data":{"id":4,"label":"Brick(120)","parent":[1]},"position":{"x":10,"y":0}}
{"group":"nodes","data":{"id":5,"label":"Avail","parent":[]},"position":{"x":55,"y":0}}
{"group":"nodes","data":{"id":6,"label":"Brick(1)","parent":[1]},"position":{"x":15,"y":0}}
{"group":"nodes","data":{"id":7,"label":"Avail","parent":[]},"position":{"x":60,"y":0}}
{"group":"nodes","data":{"id":8,"label":"Brick(2)","parent":[1]},"position":{"x":20,"y":0}}
{"group":"nodes","data":{"id":9,"label":"Avail","parent":[]},"position":{"x":65,"y":0}}
{"group":"nodes","data":{"id":10,"label":"Brick(3)","parent":[1]},"position":{"x":25,"y":0}}
{"group":"nodes","data":{"id":11,"label":"Avail","parent":[]},"position":{"x":70,"y":0}}
{"group":"nodes","data":{"id":12,"label":"Brick(4)","parent":[1]},"position":{"x":30,"y":0}}
{"group":"nodes","data":{"id":13,"label":"Avail","parent":[]},"position":{"x":75,"y":0}}
{"group":"nodes","data":{"id":14,"label":"Brick(5)","parent":[1]},"position":{"x":35,"y":0}}
{"group":"nodes","data":{"id":15,"label":"Avail","parent":[]},"position":{"x":80,"y":0}}
{"group":"nodes","data":{"id":16,"label":"NumericalRelationScout","parent":[1]},"position":{"x":40,"y":0}}
{"group":"nodes","data":{"id":17,"label":"OperandView","parent":[1]},"position":{"x":0,"y":0}}
{"group":"edges","data":{"id":"2.member_of.1.members","source":2,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"4.member_of.1.members","source":4,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"6.member_of.1.members","source":6,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"8.member_of.1.members","source":8,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"10.member_of.1.members","source":10,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"12.member_of.1.members","source":12,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"14.member_of.1.members","source":14,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"16.member_of.1.members","source":16,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"17.member_of.1.members","source":17,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"3.taggees.2.tags","source":3,"source_port_label":"taggees","target":2,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"2.support_from.3.support_to","source":2,"source_port_label":"support_from","target":3,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"3.support_from.2.support_to","source":3,"source_port_label":"support_from","target":2,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"5.taggees.4.tags","source":5,"source_port_label":"taggees","target":4,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"4.support_from.5.support_to","source":4,"source_port_label":"support_from","target":5,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"7.taggees.6.tags","source":7,"source_port_label":"taggees","target":6,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"6.support_from.7.support_to","source":6,"source_port_label":"support_from","target":7,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"9.taggees.8.tags","source":9,"source_port_label":"taggees","target":8,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"8.support_from.9.support_to","source":8,"source_port_label":"support_from","target":9,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"11.taggees.10.tags","source":11,"source_port_label":"taggees","target":10,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"10.support_from.11.support_to","source":10,"source_port_label":"support_from","target":11,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"13.taggees.12.tags","source":13,"source_port_label":"taggees","target":12,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"12.support_from.13.support_to","source":12,"source_port_label":"support_from","target":13,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"15.taggees.14.tags","source":15,"source_port_label":"taggees","target":14,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"14.support_from.15.support_to","source":14,"source_port_label":"support_from","target":15,"target_port_label":"support_to","weight":2}}
The object passed to cy.layout() had a circular structure, so JSON.stringify() wouldn't print it. Adding the getCircularReplacer() function recommended here seemed to crash the browser. But manually removing elements from the layout object exposed the error: in a relative alignment constraint (documented under API here), I had an offset of '0' where I needed a 0, i.e. a string where a number was needed.
OK, happily that problem is now fixed. That still leaves the original question: is there a faster way to find errors like that? (The static-typing advocates are surely cackling by now.)

Images with certain path types will not display in my webgl app

I have a webgl application and quite a bunch of images. It has, however, come to my attention that images with given paths do not get recognized and hence are not used as textures in this application while others work just fine.
for example images with paths like:
assets/my_app/images/products/775/882/gHI1%201%200%20007%205NR%20H00968%2001b.jpg
are not recognized, but whats worse is that I get no error whatsoever, except the fact that where a texture is supposed to be, I get none.
however paths like this works fine:
assets/my_app/images/products/1/1/10_58_1458220717_exnurfqolcmsbpgajizdhkywt.jpg
I really need the first kind of path to work as well because most of the images I am using are saved this way.
How best can I solve this issue. I have got quite a number of images. Any suggestions are highly appreciated. Thanks.

If there are actually % symbols in the filenames then you need to escape them by replacing % with %25 in the url otherwise the server will read %20 as a space so for a url of KI1%20I the server will look for KI1 I not KI1%20I

Resources