Wow, great work! That can’t have been easy to track down…
This sounds similar to this issue that @bjeurissen encountered a while back. The added problem there was that this was internal to Qt, which meant we couldn’t modify the code – there was nothing we could do other than modify the locale, in pretty much the same way as you suggest.
However, in this instance, we do have control of the relevant code. @rsmith, I suggest we change the problematic line from what it is now:
Not really, but it will affect the exact procedure and the specific flags that might need to be set in the configure call. So it helps to know if we’re trying to help you to compile a debug build. You should be able to use the exact same steps as you must have used to compile your original installation, but with -assert -debug at the end of the ./configure line – everything else should be the same…
I think we’ll need to take a look at the data to get to the bottom of this. But before we do, it might be worth looking into whether you might not have the reverse issue: maybe the numbers are written in the file using the comma as the decimal separator, and your locale is set to use a dot? Can you look at the file in a text editor and see how the numbers are stored? It should be just text…
OK, so here are the first few lines of my .obj file:
# mrtrix_version: 3.0_RC2-37-gb4bca32f
o none
o 1
v -31.120390560477745 -56.278932370245329 -16.580981446196731 1.0
v -31.620390579104196 -55.778932373970619 -16.580981401260416 1.0
v -31.120390597730648 -55.778932400047651 -17.080981490667384 1.0
OK, that doesn’t seem to be the issue. Feel free to send me the problematic file, by email or any other means: jdtournier@gmail.com, I’ll take a look when I have a minute.
For me, when i do label2mesh and mesh filter. None of the files produces any node.
I have tried to build mrtrix with various versions of Qt, including two qt4 and two qt5 versions with no difference.
I even did start debugging with Qt Creator GUI, but nothing.
Here is my openGL information and picture that i get.
@martahedl: Could you try locally modifying the code according to @jdtournier’s suggestion? If this is a more general issue around text-string conversions in different locales, it might require a decent block of changes to MRtrix3, which will take a bit of work, so I’d like to know beforehand whether or not such a modification actually fixes the issue. @david142: You could try the same modification if you’d like.
Also, if anyone encountering the issue could provide the output of the locale command, that might help to determine whether or not we’re going down the right rabbit-hole.
That’s strange. LC_NUMERIC for de_DE uses “,” as decimal separator (I’m not sure in the case of hr_HR).
In case it helps, the steps I made for solving the issue in three different Ubuntu/Debian machines were the following:
First, change the code in MeshMulti::load (src/surface/mesh_multi.cpp) replacing the line sscanf (data.c_str(), “%f %f %f %f”, &values[0], &values[1], &values[2], &values[3]);
with @jdtournier’s sugggestion:
auto list = split (data);
for (int n = 0; n < 4; ++n)
values[n] = to(list[n]);
Finally, recompile mrview with ./build bin/mrview
Also maybe you can try to change LC_NUMERIC to en_US.utf8 in your system. I tried that and also does the trick for me.
@albertofpena, any chance you could confirm whether the locale handling changes discussed here (and now implemented in the latest 3.0_RC3 release) also fix the streamtubes rendering issue you initially reported? We have reports from other macOS users that this isn’t working, and we’re trying to figure out whether this might be related to the use of an ATI graphics card. If you also still have the issue, we’ll know it’s not that simple (assuming you’re using a Nvidia system, which your previous screenshot suggests).
Streamtubes are working properly now in my Linux machine. I’ve tried in a macOS machine and I can view meshes but I can’t see streamtubes (streamlines work fine.) The installation on the macOS machine was done via Homebrew, so I’m afraid it’s not running the last version with the fix. Here I’m attaching a screenshot of the OpenGL info window:
As that one is not my computer I’m not sure I’ll be able to tinker and install last MRtrix version there, but if I see anything else I’ll let you know.
Darn, that’s not what I wanted to hear… It looks like the issue might not be specific to ATI after all, then. Although it could be a result of the uninitialised variable issue I pointed out in this post. Is there any chance you could modify the code as suggested in that post, see if that deals with that particular issue? If so, that’s an unrelated issue with an easy fix. Otherwise, it’ll take a lot of effort to debug that one…
Hi,
I’ve been following this post for a while because I have the exact same problem: Streamline visualization works, streamtube visualization does not (no edges show up). Since it’s been a while since the last update, I was wondering whether you could solve the problem by now?
@jdtournier, I’m sorry I didn’t reply sooner, we’ve been very busy in the Lab and I didn’t have access to the macOS until today.
I’ve done a checkout of the last version available in the GitHub repository (as far as I’ve seen, that version includes the patch in the post you pointed out). I’ve tried the visualization again with this new version and the problem is still there. Streamlines work fine but streamtubes are missing.
Also, the visualization with cylinders works fine, so if the OpenGL primitive used for cylinders is the same as for the streamtubes, could it might be a problem in the generation of the streamtubes instead of OpenGL?
That’s a useful little piece of information; I’m not sure if it will get me anywhere, since the cylinder and streamtube renderings follow significantly different code paths, but it at least gives me something to go on.
Ultimately reproducing any error is the first step in diagnosing it, which is why I’m so powerless here… Maybe if someone encountering the issue could provide me with ssh access to their machine and activate a video call with screen sharing so I can perform debugging on their system remotely?
Same here, cylinders, streamlines and the parcellated meshes work, just the streamtubes don’t –as mentioned here: Visualising edges as streamlines / streamtubes .
Rob, if you want, you can access my laptop, no problem at all. Our timezones might be conflicting a bit though (Berlin / Europe)…
