Closed EnochYing closed 2 years ago
Do you mean the XML files of the scene or the binary kdtree files? The binary kdtree files that you built with 1.0.9 are not compatible due to major changes and improvements in the kdtree of HELIOS++ 1.1.0 (https://github.com/3dgeo-heidelberg/helios/releases/tag/v1.1.0). In this case the straightforward solution is to build the binary scene files once and then can reuse it for later simulations.
Also few parameters in the XML definitions have changed. So far we have no systematic documentation of those parameter changes. Easiest is to check the examples scenes (and their history), e.g. https://github.com/3dgeo-heidelberg/helios/commits/dev/data/scenes/demo.
Alternatively, please provide the error messages and - if possible - also (parts) of the XML files. This helps us to identify the problem.
For the v1.1.0, I failed at the exact step of locading xml files of a building floor scene, i.e. cannot creating a .scene file, which should be before creating kdtree?
the error message, the xml files of survey and scene are attached.
It is weird that helios files of other floors can be successfully processed by v1.1.0. These files are prepared by the same software. They should not have difference in syntactic.
Dear Enoch,
we tried to reproduce the error using your scene and survey XMLs. The XMLs seem to be correct. The warning regarding the missing upwards axis (Failed to read 'up'-axis from scene XML file, assuming 'z' is 'up'. C++ Exception: boost::bad_get: failed value get using boost::get
) is not the cause of abort. As you said it is running with other obj files.
Thus we think that this one obj file might be corrupt or contain non-conformal elements. If you provide us this obj, we could try to test it. Furthermore, the scanner XML would also helpful to reproduce your problem. You can also provide a link and send it to me personally via email (helios[at]uni-heidelberg.de) if you do not want to share your data.
BTW: The use of an extra param-tag to specify the up direction axis in the obj is supported with the latest version and described here: https://github.com/3dgeo-heidelberg/helios/wiki/Scene#wavefront-object-mesh-loader
The orientation of the mesh can be specified with the up parameter within a separate param-tag. Often, the default value="z" will be suitable. However, some software (e.g., Blender) exports meshes with the y-axis pointing upwards per default, so here we would specify value="y". For a demonstration of this parameter, see data/scenes/arbaro_demo.xml.
Thanks so much for the prompt reply!
I located and checked the obj file where the program stops. I did not find any issues. I attached the full set of data here. Hopefully you can help find the problems.
I actually scanned several buildings. And often there are several storeys of each building that cannot be processed by v1.1.0 but can by v1.0.9. So I am wondering there my exist bugs in v1.1.0.
but v1.0.9 is too slow for big building scenes.
A really great dataset for challenging HELIOS++ with such a large scene (wrt input files).
By loading the almost 5000 obj files into a 3D software (I used CloudCompare), we found out that two of the obj-files are corrupt and cannot be loaded. We assume this causes the program abort. In the earlier version, this problem might have been circumvented by skipping such files. We will improve error messages regarding damaged input files and will avoid stopping the program for the next release.
The screenshots of the problematic files are enclosed. Either fix them or remove them from or comment in the scene XML (see scene.xml attached to this post). We could run the simulation when removing the who corrupt files from the scene. Don't forget to --rebuildScene
if you already have a .scene file with the same name.
We would be happy to get feedback if this solved your problem. Then can close this issue.
Thanks for the debugging. This does solve my problem. And I find the problem that cause the malformed obj files.
Yes, it would be great for Helios++ to output more meaningful error messages.
I will close this issue. Thanks again.
Hi,
As the title said, what is the reason and how can I bypass the problem when using v1.1.0. I am using v1.1.0 rather than v1.0.9 because the former one is much faster than the latter.
Many thanks, Enoch