realthunder / FreeCAD_assembly3

Experimental attempt for the next generation assembly workbench for FreeCAD
GNU General Public License v3.0
879 stars 76 forks source link

difficulty identifying elements in UI #167

Closed J-Dunn closed 5 years ago

J-Dunn commented 5 years ago

In manipulating non trivial objects it is necessary to identify which elements are being selected or to be able to select a specific element from the treeview.

eg. Referring to the assembly uploaded in #166:

There are two holes into which the two bearing-axis assemblies need to be inserted and aligned. Due to symmetry, it is difficult to know which one is being selected: hole01 or hole02.

Since most of they parts are greyed out in the treeview, nothing is indicated in the 3D view when a specific item is clicked in the treeview. Inversely , if a surface is selected in the 3D view, only the last element in the treeview which is not greyed out in the gets selected. This does not indicate the actual item selected. This is not helpful to identifying what has been selected.

Secondly, having applied a constraint, the default ( typically two ) elements get given default names. Coming back to an existing assy it is typically not clear visually what these banal names refer to, for example when coplanar. In order to give meaningful names to these elements one needs to know exactly what has been selected. Again this not at all evident in the UI.

Also, I am seeing names revert to meaningless defaults, which is not at all helpful. In the 3washer stack in bearing-spacer.fcstd, I had carefully given all elements clear, explicit names. Now after naming a couple of elements in the top level assy, I find most of the washer surfaces have lost the user defined names and returned to meaningless defaults.

Fortunately it crashed again and I was able to restart and delete transient objects so I did not need to re-edit all my element names ;)

realthunder commented 5 years ago

asm3 only uses the slvs python binding. No openGL is used. To build only the python binding, run make _slvs.

realthunder commented 5 years ago

I have fixed assembly freezing feature. Please sync both LinkStage3 (need rebuild) and asm3 (no need rebuild).

asm-freeze

J-Dunn commented 5 years ago

This mess is getting more unstable at every iteration, I'm going to do a full rebuild of both occt and stage3 and have pulled new asm3.

running cmake on linkstage3 I see it is using qt4 ( I have qt5 ) and "can not fiind" Coin. I have installed coin from source and have libCoin.so.4.0.0 and friends in /usr/local/lib64

Since cmake seems to often say it can't find something then does, I don't know if this is really a problem. Would it fail during make if it finally had not found it?

-- Found Qt4: /bin/qmake-qt4 (found suitable version "4.8.7", minimum required is "4.5.0") 
-- Found Freetype: /usr/lib64/libfreetype.so (found version "2.9.1") 
-- Found OpenGL: /usr/lib64/libOpenGL.so   
-- Found OpenGLU: /usr/lib64/libGLU.so
-- Checking for module 'Coin'
--   Package 'Coin', required by 'virtual:world', not found
-- Found Spnav: /usr/lib64/libspnav.so  
-- Using default python: -python2.7
-- libshiboken built for Release
-- Found PySide Tools: /bin/pyside-uic, /bin/pyside-rcc
-- -- matplotlib-2.2.3 has been found.
-- Platform is 64-bit, set -D_OCC64

I have python 2.7 3.4 3.5 3.7 !! I tried this but still reports can't find Coin4 export CMAKE_PREFIX_PATH=/usr/local/lib64/cmake/Coin-4.0.0


-- /svn/FreeCAD/src/Mod/Path/App/FeatureAreaPy.cpp
-- setting gcc options: -Wall -Werror -Wno-deprecated -pedantic-errors
-- Could NOT find Boost
-- Could NOT find Boost
-- Boost version: 1.66.0
-- Found the following Boost libraries:
--   python
-- found Boost: 1_66
-- boost-incude dirs are: /usr/include
-- boost-python lib is: /usr/lib64/libboost_python.so
-- boost_LIBRARY_DIRS is: /usr/lib64
-- Boost_LIBRARIES is: /usr/lib64/libboost_python.so
-- area module (for Path Workbench) will be installed to: /usr/local/lib
-- /svn/FreeCAD/src/Mod/Path/PathSimulator/App/PathSimPy.cpp

So did it find boost or not ?

Do I need ot rebuild Coin and Pivy, maybe a system update has pulled the rug on those two also, as happened with eigen3 . This is the problem with having a bunch of uncoordiinated non-distro stuff lying around.

realthunder commented 5 years ago

Some of the CMake message is indeed confusing. If CMake succeed I am pretty sure it found Coin in the end, and so does boost, as these two are mandatory.

Have you enabled automatic system update? Because the previous egien3 problem is resulted by a very recent Fedora update. Maybe that's what causing all the problems. Maybe you can turn down the 'autoness' a bit, and only auto update with those critical security patches.

J-Dunn commented 5 years ago

Thanks, no I only trigger updates manually every couple of weeks and scan what it is installing. Since I had no reason to be wary of eigen3, I would not have noticed but I did an update last week. IIRC the buggy update was dated Dec 10th. So I don't think this would be affecting my initial builds done end of Nov.

I've got as far as installing a fresh occt 7.3.0 , and now running cmake on stage3 finds the VTK stuff.


-- -- Found OCE/OpenCASCADE version: 7.3.0
-- -- OCE/OpenCASCADE include directory: /usr/local/include/opencascade
-- -- OCE/OpenCASCADE shared libraries directory: /usr/local/lib
-- VTK components: vtkCommonCore;vtkCommonDataModel;vtkFiltersVerdict;vtkIOXML;vtkFiltersCore;vtkFiltersGeneral;vtkIOLegacy;vtkFiltersExtraction;vtkFiltersSources;v$
-- Checking for one of the modules 'hdf5-serial'
-- HDF5: Using hdf5 compiler wrapper to determine C configuration
-- Checking for one of the modules 'ompi-cxx'
CMake Warning at CMakeLists.txt:735 (message):
  mpi.h was not found.  Check for error above.

Not sure about this mpi.h, I think I had this fixed before but can't find it in my installation notes.

cmake confusing ?


-- boost_LIBRARY_DIRS is: /usr/lib64
-- Boost_LIBRARIES is: /usr/lib64/libboost_python.so
-- area module (for Path Workbench) will be installed to: /usr/local/lib
-- Coin3D doc is not installed
=======================================
Now run 'make' to build FreeCAD
=======================================

except that current directory linkstage3_build is totally empty and make has nothing to do.

Obviously it did not finish and and telling me to "now run make" is pretty dumb.

J-Dunn commented 5 years ago

[snip]

EDIT, minor distraction, I was missing openmpi-devel ;)

still nothing in my build dir.

Hang on, here's what I did ..

cd linkstage3_build
cmake  -DFREECAD_USE_OCC_VARIANT="Official Version" ../FreeCAD

It says it has written the "build files" to my FreeCAD directory ? This isn't the way its worked for the last month. What is going on? I have out-of-tree builds for all of this now and I'm copy-pasting what I did last time. :?

Doing the same command on ../FreeCAD-master produces the Makefiles and cmake stuff in the build directory.

Looks like they're rearranging the Matrix again.

J-Dunn commented 5 years ago

I have tested the AppImage on another Fedora 28 system and it crashes just the same. Seems to be a generalised Fedora issue, not specific hardware or a buggy system.

That system is not affected by the buggy eigen3 release.

I would still like to finish the out-of-tree rebuild of latest stage3 if you can put me straight. I can't see that I'm doing anything different but maybe I'm just having a senior moment ;)

J-Dunn commented 5 years ago

Hi realthunder. Do you have an up to date AppImage to download? I imagine a few things have improved since the last one you linked here.

thanks.

realthunder commented 5 years ago

The latest released image is dated Feb. 2nd. You can try that first. I am going to release new version soon (maybe next week).

J-Dunn commented 5 years ago

Many thanks, that is working a lot better than the last version I tested. Minimal testing so far on my assembly files has not produce the spewing of errors and crashing I was getting before. No idea whether that is due to change in Asm3 or improvements in updates to the 'nouveau' video driver. I'll do more testing later.