When trying to compile the source I receive the following error:
/nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c: In function ‘isect_2D_loop_ray.clone.2’:
/nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:625:57: error: array subscript is above array bounds
/nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:625:45: error: array subscript is above array bounds
/nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:625:69: error: array subscript is above array bounds
/nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:625:57: error: array subscript is above array bounds
/nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:625:45: error: array subscript is above array bounds
/nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:672:2: error: array subscript is above array bounds
/nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:674:2: error: array subscript is above array bounds
/nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:677:5: error: array subscript is above array bounds
/nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:624:8: error: ‘ra[2]’ may be used uninitialized in this function
/nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:1623:15: note: ‘ra[2]’ was declared here
/nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:624:8: error: ‘rb[2]’ may be used uninitialized in this function
/nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:1624:15: note: ‘rb[2]’ was declared here
/nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:624:8: error: ‘center2d[2]’ may be used uninitialized in this function
/nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:1628:15: note: ‘center2d[2]’ was declared here
make[2]: *** [src/librt/CMakeFiles/librt.dir/primitives/extrude/extrude.c.o] Error 1
make[1]: *** [src/librt/CMakeFiles/librt.dir/all] Error 2
make: *** [all] Error 2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That build issue has been fixed in the latest sources of BRL-CAD (after 7.20.4). To get past that issue now, you can either build from an svn checkout or re-run the cmake build configuration to disable strict mode compilation (cmake -DBRLCAD_ENABLE_STRICT=OFF or select it in ccmake gui).
Cheers!
Sean
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Several ideas, but none terribly enlightening without more investigative searching. My reluctant guess as to what is happening is that you have a libfb library somewhere else on your system that is conflicting with the rpm. So when you run mged/archer, it's finding that other libfb where opengl was disabled and then ends up unable to resolve the opengl-enabled mged/archer that you're trying to run. Money is on an LD_LIBRARY_PATH set, unset it and it just might work.
Cheers!
Sean
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sean - good bet!! I put the BRL-CAD libraries at the beginning of LD_LIBRARY_PATH and now it works. Let's wait and see which other software does not work any more … ;-)
Thanks again!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting, that's a pretty rare library naming conflict then. There's a relatively young framebuffer library with that name, but never encountered them in the wild. If you remove BRL-CAD's path from LD_LIBRARY_PATH and run "ldd /path/to/mged", it'll tell you which libfb it intends to use. Could just as likely be another install of BRL-CAD somewhere on your system.
So when can we expect to see a BRL-CAD <-> enGrid exporter/importer? :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll do the test tomorrow when I am back in the office.
There is a preliminary BRL-CAD import functionality in enGrid's master branch, but it is based on STL files - fairly ugly to be honest. Currently I am waiting for a contract signature and on the back of that project we will try to get a real interface to BRL-CAD - i.e. using BRL-CAD databases as geometry input. Do you know what is the state of the step-g tool? That will be an important utility to have in order to ensure compatibility with other CAD packages.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's fantastic news. Yeah, STL is not just a terrible format but relies on our ability to evaluate boolean mesh intersections robustly which is often not possible due to dirty input geometry or floating point drift or because it's Tuesday and our tessellation library is in a bad mood. Working with the geometry in implicit CSG or BREP form is much more ideal. When/If you work towards integrating more directly, join the dev list and we can walk through the process (pretty simple really).
Currently, our bridge to FEA/CFD codes is via SNL's Cubit package, which isn't open source so it's an unsolved problem from my perspective. I don't really want BRL-CAD to get into the meshing business any more than we need to, too. I'd love to be able to say that if folks want an FEM from BRL-CAD geometry that they can just download and import into enGrid and get whatever mesh they want back.
The step-g importer is coming along great. We've got a few guys working on tasks directly and indirectly related to it from a few different angles. Just today, support was added for importing assemblies. Getting our STEP library cleanly ported to Windows is almost complete as well with a lot of issues worked out along the way. In a month or so, we should have the step-g importer going through regular regression testing where we'll start throwing more complex and varied inputs at it for robustness.
Cheers!
Sean
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I have severe problems installing BRL-CAD-7.20.4 on an openSUSE system. The rpm package gives the following error when starting mged:
When trying to compile the source I receive the following error:
ogloth,
That build issue has been fixed in the latest sources of BRL-CAD (after 7.20.4). To get past that issue now, you can either build from an svn checkout or re-run the cmake build configuration to disable strict mode compilation (cmake -DBRLCAD_ENABLE_STRICT=OFF or select it in ccmake gui).
Cheers!
Sean
Sean,
that was quick - thanks!!
Any idea about the rpm package issue??
Cheers,
Oliver
ogloth, on which opensuse version? 32 or 64-bit?
Oliver,
Several ideas, but none terribly enlightening without more investigative searching. My reluctant guess as to what is happening is that you have a libfb library somewhere else on your system that is conflicting with the rpm. So when you run mged/archer, it's finding that other libfb where opengl was disabled and then ends up unable to resolve the opengl-enabled mged/archer that you're trying to run. Money is on an LD_LIBRARY_PATH set, unset it and it just might work.
Cheers!
Sean
Sean - good bet!! I put the BRL-CAD libraries at the beginning of LD_LIBRARY_PATH and now it works. Let's wait and see which other software does not work any more … ;-)
Thanks again!
Interesting, that's a pretty rare library naming conflict then. There's a relatively young framebuffer library with that name, but never encountered them in the wild. If you remove BRL-CAD's path from LD_LIBRARY_PATH and run "ldd /path/to/mged", it'll tell you which libfb it intends to use. Could just as likely be another install of BRL-CAD somewhere on your system.
So when can we expect to see a BRL-CAD <-> enGrid exporter/importer? :-)
I'll do the test tomorrow when I am back in the office.
There is a preliminary BRL-CAD import functionality in enGrid's master branch, but it is based on STL files - fairly ugly to be honest. Currently I am waiting for a contract signature and on the back of that project we will try to get a real interface to BRL-CAD - i.e. using BRL-CAD databases as geometry input. Do you know what is the state of the step-g tool? That will be an important utility to have in order to ensure compatibility with other CAD packages.
That's fantastic news. Yeah, STL is not just a terrible format but relies on our ability to evaluate boolean mesh intersections robustly which is often not possible due to dirty input geometry or floating point drift or because it's Tuesday and our tessellation library is in a bad mood. Working with the geometry in implicit CSG or BREP form is much more ideal. When/If you work towards integrating more directly, join the dev list and we can walk through the process (pretty simple really).
Currently, our bridge to FEA/CFD codes is via SNL's Cubit package, which isn't open source so it's an unsolved problem from my perspective. I don't really want BRL-CAD to get into the meshing business any more than we need to, too. I'd love to be able to say that if folks want an FEM from BRL-CAD geometry that they can just download and import into enGrid and get whatever mesh they want back.
The step-g importer is coming along great. We've got a few guys working on tasks directly and indirectly related to it from a few different angles. Just today, support was added for importing assemblies. Getting our STEP library cleanly ported to Windows is almost complete as well with a lot of issues worked out along the way. In a month or so, we should have the step-g importer going through regular regression testing where we'll start throwing more complex and varied inputs at it for robustness.
Cheers!
Sean