Activity for Fabian Brinkmann
-
Fabian Brinkmann modified ticket #78
Scaling of the 3d_Model_uniform.blend file
-
Closed due to inactivity
-
Documentation
-
Most common errors
-
NumCalc
-
mesh2hrtf not showing up in file/export menu
-
It's stable - we are working on one final feature before 1.0 will be released :)
-
Hi Mattias, the master contains Mesh2HRTF 0.4.0 which requires Blender < 2.79. I would recommend to use the files from the develop branch, that soon will be released to the master as Mesh2HRTF 1.0 Best, Fabian ps. Please post future issues please post at https://github.com/Any2HRTF/Mesh2HRTF/issues
-
Preparing the mesh
-
Preparing the mesh
-
Mesh2HRTF 1.0 and above
-
Home
-
Home
-
Home
-
Evaluation grids
-
Mesh2HRTF 1.0 and above
-
Evaluation grids
-
Mesh2HRTF 1.0 and above
-
Mesh2HRTF 1.0 and above
-
Output File Structure
-
NumCalc
-
Mesh grading
-
Evaluation grids
-
Mesh2HRTF 1.0 and above
-
Mesh2HRTF 1.0 and above
-
Mesh2HRTF Source Code
-
Mesh2HRTF Source Code
-
Mesh2HRTF Source Code
-
Mesh2HRTF Source Code
-
Mesh2HRTF Project Folder
-
Unix Tutorials
-
Installation
-
Mesh2HRTF Export Parameters
-
Unix Tutorials
-
Tutorials
-
Tutorials
-
Tutorials
-
Installation
-
Installation
-
Mesh2HRTF 1.0 and above
-
Home
-
Hi and thanks for looking into this. I assume checking for duplicate faces and vertices would be quite easy to do upon export in blender. If anyone of you has the interest and time to do this let me know and we can look for the best way to implement this. It would also be possible to select the problematic faces or vertices to give the user a good starting point for fixing the problem. ps. since we moved the code to GitHub, lets open new issues here in the future https://github.com/Any2HRTF/Mesh...
-
New example scripts
-
Convergence of NumCalc simulation
-
Issue is now documented on GitHub
-
Testing
-
Your evaluation grid and mesh seem to have a node in common, which is what throws the error. Mesh2HRTF numbers the nodes and each node must have a unique number. You can find the numbers in (I think) the first column of the nodes.txt files inside the project folder. Best, Fabian
-
Hi Mokh, large meshes with > 100 000 elemements can take a couple of hours to compute a single high frequency. Reducing the mesh size can be done by mesh grading (attached :) Best, Fabian
-
Hi Mokh, I wonder why your error message shows a copyright sign. Can you verify the following The line in exportMesh2HRTF.py should be: open(os.path.join(programPath, "..", "VERSION")) If programPath/../VERSION does not exist, you might have set a wrong value for programPath. The value is set during the export. Best, Fabian
-
Hi Sergejs, great to see contributions from you. They are going in the right direction and add things that are needed. Here are a couple of general comments that I'd like to discuss It would be best to make it separate merge request. This makes the git history cleaner and the code review simpler My idea for python code inside Mesh2HRTF is that we use functions instead of scripts. This has the advantage that they can be reused more easily as you can pass the parameters directly to the functions and...
-
Does that only happen with the new version, or also with the old versions? If it happens with both, the complete error and project would be good to take a look...
-
Hi Sergejs, I'm not sure if I will be able to check this week. In case nobody else can jump in you could try to test it in a Docker container. I've attached a Dockerfile that I quickly adapted from the hrtf-mesh-grading package - I did not test it, though. If it works, you could compile and run NumCulc inside the container Best, Fabian
-
Hi Filip, did you freshly build NumCalc before testing? If yes, I'll pass the issue on to Wolfgang... Best, Fabian
-
Wolfgang pushed a new version to the develop branch. It has 250 as the new default value, which can be changed via the command line using NumCalc -nitermax 1500, where 1500 could be any positive integer. Can you also test it? If it works I will merge it into the other branches...
-
Hi Sergejs, thanks for the merge request. Let's make this happen for mesh2HRTF 1.0. I will update you when I had the time to test this on a unix based system.
-
Hi Filip, NC.out does not warn about these things as they are (at least in part) hard to detect automatically. That is something that you will have to do in Blender or similar software. I think @sdx-lv once manually changed the number of iterations but there is no documentation for this. Best, Fabian
-
The Matlab version is kept up to date by someone in Vienna. I would only fully remove it , in case it won't be ready for the 1.0 release and live with it for now...
-
Hi Filip, havent't tried changing that myself. However, if you are experiencing high iteration counts, it might be related to your mesh: https://sourceforge.net/p/mesh2hrtf/wiki/Most%20common%20errors/ Best, Fabian
-
Hi Sergejs, thanks for the Feedback! 1: fixed but used frequencies[0] < 0.1 instead of frequencies[0] < 0.9 -was there a specific reason for the 0.9? 2: The limit is a rough estimation based on the triangles' edge lengths. As a rule of thumb there should be at least 6 edges per wave length. The estimation might be wrong for graded meshes with large elements away from the ear of interest. I think it was intended as a first place to look, if the results are weird. 3: Did you have to uncomment the lines...
-
Let's say ready to test. All API changes that are planned vor Mesh2HRTF 1. 0 are there, but not everything is tested yet. We are usually working on it one to two days a week. I would say it's an early beta version. And the Matlab part in that branch is currently not working. There is a different person working on that.
-
Let's say ready to test. All API changes that are planned vor Mesh2HRTF 1. 0 are there, but not everything is tested yet. We are usually working on it one to two days a week. I would say it's an early beta version.
-
Ok, we checked the problem. A first test suggests that it is now fixed. Note that the latest work is on simplify_export.. branch and that this is work in progress. This branch creates data directiores source# instead of CPU#_Core', which makes the code simpler
-
I think line 257 should be tmpPressure = [] not del tmpPressure. The way of indexing works with numpy arrays...
-
We are currently implementing testing for the code. It worked with a few minimal examples that we tested so far but there might be undiscovered bugs. Can you upload you project or is it too large?
-
Most common errors
-
Most common errors
-
Structure of NC.inp
-
Hi Sergejs, Its not ok, and it should appear in the HRIRs computed by Mesh2HRTF. How did you do the plot? My guess is, that this is a problem of the Matlab/Octave SOFA API, not Mesh2HRTF. Best, Fabian
-
Various minor fixes
-
Hi Nikhil, that looks like the data was not computed or the simulation did not finish. The line that throws the error tries to read information from NumCalc/CPU*/NC.out. Can you check that these files exist and maybe post one of them here? Best, Fabian
-
yes - exactly! You can check output2HRTF_main.m to see how it is done in Code :)
-
Yes, and no. The HRTF can be calculated at any frequency or frequencies. So it can be a single sided spectrum but does not necessarily have to be. To calculate to HRIR you need to have a full spectrum, which is obtained from mirroring the HRTF. This can only be done if it is a single sided spectrum. This is the case if it was simulated for evenly spaced frequencies and the first frequency equals the spacing of the bins. Best, Fabian
-
Hi Filip, I think I understand the question now. The single sided spectra is mirrored before the IFFT to account for all the energy. As far as I understand, you usually don't apply normalization for energy signals, i.e., finite signals such as impulse responses. So I usually don't generate the yellow spectrum. Best, Fabian
-
Hi Filip, I'm not sure if I understand how the data was generated. Which line shows the pressure as simulated with Mesh2HRTF, what is the difference between the two HRTF lines, how was the HRIR obtained? I usually check the boxes Reference and Compute HRIRs during export which takes care of that. The HRIRs are computed in output2HRTF_main. Best, Fabian
-
crash in SOFAupdateDimensions(Obj) when processing both ears
-
Convergence of NumCalc simulation
-
Upgrade to 2.8x required
-
Hi Sergejs, the issue with Data.Delay was a bug. I committed a fix to develop - can you check if that works for you? The Issue with the plot looks unrelated to me. The delay is a meta data entry that is not used in that case. Best, Fabian
-
Hi Sergejs, can you post a link to the entire Project folder, please? Best, Fabian
-
Hi Johan, thanks for the effort. I manually diffed an accepted most of your suggestions and included you as a contributor in history.txt (assuming you are the Johan Pauwels from Imperial College London). I will try to find some time to move the code to github to make future merge requests easier. It would be great if you keep your fork and we will try to take care of the remaining changes once testing is in a more mature state. Best, Fabian
-
Regarding the question of changing the input parameters for CPUfirst/last: I like the idea of simplifying this to a single numCPUs parameter, however, we are currently working on implementing testing and porting the Matlab files to python. I would suggest to wait until the python port is done. From that moment on, I would prioratize the python version, since it can be automatically tested. We should still try to keep the Matlab version up to date, nevertheless. This means double the work for changes...
-
Hi Johan, thanks for the work it looks good to me. Just two quick questions: - Can you merge the latest develop branch into your fork first. I spotted a few outdated spots here and there, and want to make sure that they are not merged. (Sourceforge is giving me a hard time - I am used to GitHub pull requests and diffs...) - Can you revert the default of unit in exportMesh2HRTF.py to 'mm'? Changing the default to 'm' might cause errors for long term users. Best, Fabian
-
Regarding element form warning
-
Hi Ganesh, I'm not an expert in mesh editing and remeshing - so I'm afraid I can't help here. This is what I would try: - run NumCalc regardless of the warning (if it's only a single or few elements, it might still work fine) - find the distorted elements in the mesh and try to manually fix the problem. Since this is not a Bug in the Code, please use the mailing list for such requests in the future. Best, Fabian
-
Potential pitfall
-
thanks - This is now part of the develop branch :)
-
Frequency Scale
-
Hi Ganesh, yes it is - you can specify linearly distributed frequencies using the parameters Min. Frequency, Max. Frequency, and Frequencies in the Blender export: https://sourceforge.net/p/mesh2hrtf/wiki/Mesh2HRTF%20export%20parameters/ If you prefer to directly edit the inp-files you can have a look here: https://sourceforge.net/p/mesh2hrtf/wiki/Structure%20of%20NC.inp_0.4.0/ Best, Fabian
-
A small bug in the exportMesh2HRTF.py
-
Great - I changed the default as you suggested and merged into develop :)
-
Hi Filip, can you upload your entire export_Mesh2HRTF.py? This would make it easier for me to spot and update your changes :) Best, Fabian
-
Hi Sergejs, thanks for the work - I've created the branch 'enhancement/export' with a slightly changed suggestion. Can you check it out and let me know if it is good to be merged into develop from your point of view? The only larger thing that I changed is that I wanted to keep the First/Last_CPU logic. Some people might use that to distribute jobs by mapping from numbers to computers. Best, Fabian
-
Thanks - that looks good! I think I would only change the error message to "Error! Not all faces in the Reference mesh are triangular!" Can you give it a try and include it in exportMesh2HRTF.py in the develop branch? That would be great. It might be the most modular solution to make it a function that is called after line 344 Best, Fabian
-
Hi Filip, sorry for my slow responses lately - I had quite a work stack followed by a vacation. A check for triangular faces would be good, indeed. It might be easier though to directly check it in Blender upon project export. Here's an example for checking if all faces are quads, but it would be easy to change: https://blender.stackexchange.com/questions/146051/how-to-check-if-all-my-faces-on-mesh-are-all-quads-using-a-script Would you have time to try to incorporate this in the Python export script?...
-
Hi Sergejs, thanks for reporting, this could indeed be improved. At the moment the export assumes, that the field "FileName" in the export window is empty and that the project is saved in an already existing folder. If you find time, it would be great if you could provide an improved export script here or using a merge request. It would have to work for these cases "FileName" is empty (as before) "FileName" is not empty, folder already exists "FileName" is not empty, folder does not exist Regarding...
-
Hi Lorenz, the develop branch already supports Blender 2.8 - it will be released in a while... Best, Fabian
-
Can you upload the working and not working versions somewhere and post the link? I would ask Wolfgang if he has time to take a look.
-
you can find the list here: https://sourceforge.net/p/mesh2hrtf/mailman/
1 >