From david.thompson at kitware.com Wed Mar 9 11:46:41 2016 From: david.thompson at kitware.com (David Thompson) Date: Wed, 9 Mar 2016 11:46:41 -0500 Subject: [Smtk-developers] cmb's move to paraview master In-Reply-To: References: <20160308141427.GA31042@megas.kitware.com> Message-ID: Hi all, ... but now when configuring SMTK, I get: CMake Error at /Sekundo/Build/CMB/superbuild/paraview/src/paraview/VTK/CMake/vtkModuleAPI.cmake:121 (message): Requested modules not available: pqApplicationComponents Call Stack (most recent call first): /Sekundo/Build/CMB/superbuild/paraview/src/paraview-build/VTK/VTKConfig.cmake:75 (vtk_module_config) /Sekundo/Build/CMB/superbuild/paraview/src/paraview-build/ParaViewConfig.cmake:50 (include) ThirdParty/SMTK/CMakeLists.txt:209 (find_package) Any ideas of what's happening? ParaView is definitely building pqApplicationComponents and it shows up in the ParaViewTargets.cmake file in the build directory. (Since I'm on Mac OS, the superbuild doesn't install ParaView anywhere -- there is no other ParaViewTargets.cmake.) Thanks, David > On Mar 8, 2016, at 12:33 PM, David Thompson wrote: > >> There is a cmake error currently coming from Paraview/VTK >> CMake Error: INSTALL(EXPORT) given unknown export "targets" >> >> This error comes from VTK/ThirdParty/libproj4, and Dan Lipsa is working on a fix. ... > > Thanks, that helps. > > David From david.thompson at kitware.com Tue Mar 15 13:26:42 2016 From: david.thompson at kitware.com (David Thompson) Date: Tue, 15 Mar 2016 13:26:42 -0400 Subject: [Smtk-developers] Polygon model normals Message-ID: <3393AB12-0BE3-4CF9-BB2E-00D14E164759@kitware.com> Hi all, I've found what's causing the bad shading and small "holidays" when testing Yumin's shapefile importer (but not the other problem yet). The problem is that the shapefile we are using doesn't have lat-long coordinates; instead it uses feet or meters in some datum plane. The values are quite large and the OpenGL library truncates point coordinates from doubles to floats before rendering. I hacked the polygon modeler to move the points near the origin and the dark/light triangles went away. I can't commit the hack (it hardcoded a point coordinate in the polygon code), so how we handle this properly in SMTK and CMB is still an issue. Do you have any preferences? We could 1. Change the "import" operator to accept a "recenter model" item (maybe with an additional double-vector item specifying the new origin so that multiple models could be recentered to the same point?). This could require considerable knowledge on the user/app-developer to set up a processing pipeline. 2. Change the VTK source class to recenter points if the bounds are far from the origin relative to the box size. This would mean that things like the spreadsheet view will appear "off" with no real explanation. But SMTK would provide the correct coordinates. 3. Change VTK's mapper(s) to do recentering as in #2 above. This would be the least leaky abstraction. 4. Make our own CMB mapper. We probably need to do this anyway to handle things like glyphs, instances, and other special model geometry. I like #3 the best, but it's a lot more work than #1 or #2 (and that work would be getting the change tested and approved, not coding the actual fix). David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2016-03-15 at 1.17.09 PM.png Type: image/png Size: 63381 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2016-03-15 at 1.21.08 PM.png Type: image/png Size: 15941 bytes Desc: not available URL: From david.thompson at kitware.com Thu Mar 17 16:10:24 2016 From: david.thompson at kitware.com (David Thompson) Date: Thu, 17 Mar 2016 16:10:24 -0400 Subject: [Smtk-developers] Polygon model normals In-Reply-To: <3393AB12-0BE3-4CF9-BB2E-00D14E164759@kitware.com> References: <3393AB12-0BE3-4CF9-BB2E-00D14E164759@kitware.com> Message-ID: > I've found what's causing the bad shading and small "holidays" when testing Yumin's shapefile importer (but not the other problem yet). ... I've pushed a fix to the polygon-session's "import" operator that gets it loading some shapefiles correctly. It will load files like the "countries.shp" file that ParaView tests but with errors; this is because that particular shapefile stores multiple faces in a single polygon (polygons are allowed to have multiple parts, each of which is an outer loop plus inner loops). However, the problem that led to tessellations with notches in them was that the "import" operator was not populating the "counts" item of the "force create face" operator it calls under the hood. This is required so that the the operator knows which edges are part of the outer loop and which ones form inner loops. Attached is a screenshot created by running the (new) polygonImportPy test in interactive mode: python /path/to/smtk/bridge/polygon/testing/python/polygonImport.py -D /path/to/SMTKTestData -I You can see that some countries have proper tessellations while others do not. David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2016-03-17 at 4.08.03 PM.png Type: image/png Size: 50040 bytes Desc: not available URL: From ben.boeckel at kitware.com Tue Mar 22 17:10:46 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 22 Mar 2016 17:10:46 -0400 Subject: [Smtk-developers] Polygon model normals In-Reply-To: <3393AB12-0BE3-4CF9-BB2E-00D14E164759@kitware.com> References: <3393AB12-0BE3-4CF9-BB2E-00D14E164759@kitware.com> Message-ID: <20160322211046.GB7124@rotor.khq.kitware.com> On Tue, Mar 15, 2016 at 13:26:42 -0400, David Thompson wrote: > The problem is that the shapefile we are using doesn't have lat-long > coordinates; instead it uses feet or meters in some datum plane. The > values are quite large and the OpenGL library truncates point > coordinates from doubles to floats before rendering. I hacked the > polygon modeler to move the points near the origin and the dark/light > triangles went away. Sounds like UTM. Would using proj4 be an option to convert it to latlon? --Ben From bob.obara at kitware.com Tue Mar 22 22:35:11 2016 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Tue, 22 Mar 2016 22:35:11 -0400 Subject: [Smtk-developers] Polygon model normals In-Reply-To: References: <3393AB12-0BE3-4CF9-BB2E-00D14E164759@kitware.com> Message-ID: <520C2E1F-2140-4650-B5CA-D5BE427FAE63@kitware.com> Hey David, Great - in that the current use case is that shape files we will need to process in the short term will be mainly in Lat/long we might be able to hold off further improvements but I will check on this tomorrow. Bob Sent from my iPad On Mar 17, 2016, at 4:10 PM, David Thompson wrote: >> I've found what's causing the bad shading and small "holidays" when testing Yumin's shapefile importer (but not the other problem yet). ... > > I've pushed a fix to the polygon-session's "import" operator that gets it loading some shapefiles correctly. It will load files like the "countries.shp" file that ParaView tests but with errors; this is because that particular shapefile stores multiple faces in a single polygon (polygons are allowed to have multiple parts, each of which is an outer loop plus inner loops). > > However, the problem that led to tessellations with notches in them was that the "import" operator was not populating the "counts" item of the "force create face" operator it calls under the hood. This is required so that the the operator knows which edges are part of the outer loop and which ones form inner loops. > > Attached is a screenshot created by running the (new) polygonImportPy test in interactive mode: > > python /path/to/smtk/bridge/polygon/testing/python/polygonImport.py -D /path/to/SMTKTestData -I > > You can see that some countries have proper tessellations while others do not. > > David > >