You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(6) |
Feb
(5) |
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Ata O. <a.o...@qm...> - 2021-03-31 15:39:35
|
Dear All, We are looking for participants for a brief (5-10 minutes) online survey on locomotion in virtual reality (VR). The survey comprises two sections. The first section asks for your preferences on some of the available locomotion interfaces and methods. In the second part, we introduce our solution design and we would love to see your opinions on it. Below you can find the link to our questionnaire. Link: https://forms.gle/kHGMdDM9ub7PWY726<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforms.gle%2FgoJLAvG4mrri4sRL8&data=04%7C01%7C%7Cb5c45b311084447d6f7708d8f049c629%7C569df091b01340e386eebd9cb9e25814%7C0%7C0%7C637523547014664146%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Tlc7pdBlGwCmJe8yz0tz8BJCH44aPJqkFNGFvkbD0R0%3D&reserved=0> Thank you in advance for your help. Best wishes, Ata Otaran PhD Student in Robotics Group EECS Department Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 |
From: Fongang D. J. <djf...@gm...> - 2015-09-11 10:34:43
|
I attempted to write a single function to convert a point cloud to a surface using vcglib, by imitating the steps followed in meshlab for that. looked at the meshlab code and attempted to reproduce the steps in the same way as in meshlab's code. However, the function hangs forever in SurfaceSampling< MyMesh, BaseSampler >::ComputePoissonDiskRadius and execution never goes pass that even after 20 minutes on a quadcore intel i7 with 16GB RAM Note: if I comment out the ::ComputePoissonDiskRadius line and call tri::SurfaceSampling<MyMesh, BaseSampler>::VertexUniform( m, mps, DISK_SAMPLING_NUM ) instead, it completes and produces a point cloud reduced to exactly 16000 points, which is suspicious because using disk prunning in meshlab produces a non exact number of vertices in the reduced point cloud, so I am not sure that the output is correct with VertexUniform. Also, when the function completes with VertexUniform, although normals are produced, the BallPivoting algorithm does not add any triangle to the mesh. Please help. the calls made in this function use the exact same parameters as used in meshlab to successfully produce a surface from the same original point cloud with no normals and 986k vertices(from a 3D reconstruction algorithm). I could use meshlabserver and call shell scripts to wrap it..., but not only is that ugly, but this program could do with less dependencies. /**************************bellow the function:*****************************/ static void surface_from_point_cloud( const std::vector<double> &pointcloud, zmqbridge::Surface &zmqsurf ) { //Define the meshes MyMesh m, reduced_m; std::cout << " reducing point cloud and generating surface for " << pointcloud.size() / 3 << " points ..." << std::endl; //Load the points into the mesh assert( pointcloud.size() % 3 == 0 ); for( size_t id = 0; id < pointcloud.size(); id +=3 ) { MyMesh::VertexPointer ivp[4]; ivp[3]= &*vcg::tri::Allocator<MyMesh>::AddVertex( m, MyMesh::CoordType ( pointcloud[ id ], pointcloud[ id + 1 ], pointcloud[ id + 2 ] ) ); } std::cout << "loaded mesh points ..." << std::endl; //resample to 16k vertices max using namespace vcg; std::vector<Point3f> poissonsamples; typedef tri::TrivialSampler<MyMesh> BaseSampler; int sampleNum = DISK_SAMPLING_NUM; int radius = tri::SurfaceSampling< MyMesh, BaseSampler >::ComputePoissonDiskRadius( m, sampleNum ); // //MyMesh *presampledMesh= &( m ); BaseSampler mps( poissonsamples ); tri::SurfaceSampling< MyMesh, BaseSampler >::PoissonDiskParam pp; tri::SurfaceSampling< MyMesh, BaseSampler >::PoissonDiskParam::Stat pds; pp.pds = pds; //pp.adaptiveRadiusFlag=false; pp.preGenFlag = false; pp.preGenMesh = NULL; pp.geodesicDistanceFlag = false; pp.bestSampleChoiceFlag = true; pp.bestSamplePoolSize = 10; tri::SurfaceSampling<MyMesh,BaseSampler>::PoissonDiskPruning( mps, m, radius, pp ); //tri::SurfaceSampling<MyMesh, BaseSampler>::VertexUniform( m, mps, DISK_SAMPLING_NUM );//here I was supposed to do disk prunning instead, but it hangs... vcg::tri::UpdateBounding<MyMesh>::Box( m ); //================== std::cout << "resampled mesh..." << std::endl; size_t outsize = poissonsamples.size(); for( size_t id = 0; id < outsize; ++id ) { MyMesh::VertexPointer ivp[4]; ivp[3]= &*vcg::tri::Allocator<MyMesh>::AddVertex( reduced_m, MyMesh::CoordType ( poissonsamples.at( id )[ 0 ], poissonsamples.at( id )[ 1 ], poissonsamples.at( id )[ 2 ] ) ); } //================== std::cout << "copied resampled mesh..." << std::endl; tri::PointCloudNormal< MyMesh >::Param p; p.fittingAdjNum = 16; p.smoothingIterNum = 0; p.viewPoint = Point3f( 0, 0, 10 ); p.useViewPoint = true; tri::PointCloudNormal< MyMesh >::Compute( reduced_m, p ); vcg::tri::UpdateBounding< MyMesh >::Box( m ); std::cout << "generated point cloud normals..." << std::endl; //generate faces ( auto settings ) vcg::tri::BallPivoting< MyMesh > bpm( reduced_m, 0.0f, 20.0f, 90.0f ); bpm.BuildMesh(); std::cout << "built surface for mesh with " << reduced_m.VN() << " vertices and " << reduced_m.face.size() << " faces !" << std::endl; //fill and return surface MyMesh::VertexIterator vi; MyMesh::VertexPointer vp; SimpleTempData<typename MyMesh::VertContainer,int> indices(reduced_m.vert); std::cout << " constructed vertice indice array " << std::endl; size_t j; for( j = 0, vi = reduced_m.vert.begin(); vi != reduced_m.vert.end(); ++vi ) { vp = &( *vi ); indices[vi] = j; //std::cout << " allocated " << j << " to indices [vi] " << std::endl; if( ! vi->IsD( ) ) // <---- Check added { zmqsurf.add_newpoints( float( vp->P()[ 0 ] ) ); zmqsurf.add_newpoints( float( vp->P()[ 1 ] ) ); zmqsurf.add_newpoints( float( vp->P()[ 2 ] ) ); if ( vp->N()[0] || vp->N()[1] || vp->N()[2] ) { zmqsurf.add_normals( float( vp->N()[ 0 ] ) ); zmqsurf.add_normals( float( vp->N()[ 1 ] ) ); zmqsurf.add_normals( float( vp->N()[ 2 ] ) ); } else { std::cout << "Warning! Missing normal for current vertex!" << std::endl; } j++; } } std::cout << "stored vertices in zmqbridge::Surface..." << std::endl; MyMesh::FaceIterator fi; MyMesh::FacePointer fp; for( fi = reduced_m.face.begin(); fi != reduced_m.face.end(); ++fi ) { if( ! fi->IsD( ) ) // <---- Check added { fp = &( *fi ); zmqsurf.add_addedfaces( indices[ fp->cV( 0 ) ] ); zmqsurf.add_addedfaces( indices[ fp->cV( 1 ) ] ); zmqsurf.add_addedfaces( indices[ fp->cV( 2 ) ] ); } } std::cout << "stored faces in zmqbridge::Surface..." << std::endl; } /************************************************************************************/ |
From: Sylvain P. <syl...@gm...> - 2015-02-12 21:31:24
|
Dear developers, I would like to create a small command line tool to simplify a model. I am using a mac os x yosemite and xcode 6.1.1 Maybe I do something wrong but I cannot compile a single example of a sample program. for instance: cd vcglib/apps/trimeshinfo clang++ -I ../.. -I . trimeshinfo.cpp In file included from trimeshinfo.cpp:185: *../../vcg/simplex/vertex/base.h:24:2: **error: **"This file should not be included alone. It is automatically included by complex.h"* #error "This file should not be included alone. It is automatically included by complex.h" * ^* *../../vcg/simplex/vertex/base.h:61:30: **error: **unknown template name 'Arity12'* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:38: **error: **use of undeclared identifier 'vertex'* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:56: **error: **'UserTypes' does not refer to a value* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:54:17: note: *declared here template <class UserTypes, * ^* *../../vcg/simplex/vertex/base.h:61:68: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:71: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:74: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:77: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:80: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:83: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:86: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:89: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:92: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:95: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:98: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:101: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:134:4: **error: **use of undeclared identifier 'assert'* assert(0); * ^* *../../vcg/simplex/vertex/base.h:184:55: **error: **default template argument for a template template parameter must be a class template* template <typename> class A = DefaultDeriver, template <typename> class B = DefaultDeriver, * ^* *../../vcg/simplex/vertex/base.h:184:101: **error: **default template argument for a template template parameter must be a class template* template <typename> class A = DefaultDeriver, template <typename> class B = DefaultDeriver, * ^* *fatal error: **too many errors emitted, stopping now [-ferror-limit=]* 20 errors generated. Sylvains-MacBook-Pro-2:trimeshinfo sylvain$ clang++ -I ../.. -I . trimeshinfo.cpp In file included from trimeshinfo.cpp:185: *../../vcg/simplex/vertex/base.h:24:2: **error: **"This file should not be included alone. It is automatically included by complex.h"* #error "This file should not be included alone. It is automatically included by complex.h" * ^* *../../vcg/simplex/vertex/base.h:61:30: **error: **unknown template name 'Arity12'* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:38: **error: **use of undeclared identifier 'vertex'* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:56: **error: **'UserTypes' does not refer to a value* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:54:17: note: *declared here template <class UserTypes, * ^* *../../vcg/simplex/vertex/base.h:61:68: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:71: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:74: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:77: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:80: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:83: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:86: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:89: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:92: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:95: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:98: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:61:101: **error: **expected class name* class VertexArityMax: public Arity12<vertex::EmptyCore<UserTypes>, A, B, C, D, E, F, G, H, I, J, K, L> { * ^* *../../vcg/simplex/vertex/base.h:134:4: **error: **use of undeclared identifier 'assert'* assert(0); * ^* *../../vcg/simplex/vertex/base.h:184:55: **error: **default template argument for a template template parameter must be a class template* template <typename> class A = DefaultDeriver, template <typename> class B = DefaultDeriver, * ^* *../../vcg/simplex/vertex/base.h:184:101: **error: **default template argument for a template template parameter must be a class template* template <typename> class A = DefaultDeriver, template <typename> class B = DefaultDeriver, * ^* *fatal error: **too many errors emitted, stopping now [-ferror-limit=]* 20 errors generated. Does it work on mac and clang? Best regards, Sylvain |
From: massimiliano c. <mas...@is...> - 2011-05-19 16:39:17
|
Dear VCG developers, due to last non-properly-coherent changes made to the VCG::Shot class I have changed many comments of the code. Now, all the comments about the computations and assumptions made in this class are correct (I hope). I have also added a test applications of the Vcg::Camera-Vcg::Shot classes under apps\test\camerashot and two new Shot methods to deal with roto-translation of the local reference frame and to adjust both the intrinsics and the extrinsics camera parameters in case you change the scale of your 3D world coordinates system (sometimes it could be useful handling data coming from structure-from-motion reconstruction tools). The new methods are: vcg::Shot::RescalingWorld(ScalarType scalefactor) vcg::Shot::ApplyRigidTransformation(Matrix44<S> M) Finally, the method ::MultMatrix, that it is probably used by PhotoCloud developers, needs to be renamed to match better what it does with its name. Please, give me feedback about this point in order to finish this ''clean'' of the Vcg::Shot class. The official documentation should be updated accordingly. I hope to do it in the next days. Best, Massimiliano Corsini |
From: fabio g. <fab...@gm...> - 2011-04-15 14:06:13
|
Hello Lino, it's solved. The file was not updated to the current version of the lib. lease update and try again, Fabio On 04/15/2011 02:29 PM, lin...@gm... wrote: > Hello, > > thanks for the good work. I am starting now to use your > library and my main task is to compile the trimeshinfo application > sample. > > I have seen that recently there have been some template changes. > > I get these errors compiling it > > > ~/no_backup/tmp/cnr/soft/vcg/vcglib/apps/trimeshinfo $ g++ -I ../.. -I . trimeshinfo.cpp > > In file included from /usr/include/c++/4.3/ext/hash_map:64, > from ../../vcg/space/index/spatial_hashing.h:45, > from ../../vcg/complex/algorithms/clean.h:38, > from trimeshinfo.cpp:196: > /usr/include/c++/4.3/backward/backward_warning.h:33:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. > In file included from XMLTree.h:10, > from trimeshinfo.cpp:206: > InstancesNode.h: In constructor ?InstanceNode::InstanceNode()?: > InstancesNode.h:11: warning: deprecated conversion from string constant to ?char*? > InstancesNode.h:11: warning: deprecated conversion from string constant to ?char*? > In file included from trimeshinfo.cpp:206: > XMLTree.h: At global scope: > XMLTree.h:17: warning: deprecated conversion from string constant to ?char*? > XMLTree.h: In member function ?void XMLTree::initializeMain()?: > XMLTree.h:121: warning: deprecated conversion from string constant to ?char*? > XMLTree.h:126: warning: deprecated conversion from string constant to ?char*? > trimeshinfo.cpp: At global scope: > trimeshinfo.cpp:216: error: expected template-name before ?<? token > trimeshinfo.cpp:216: error: expected `{' before ?<? token > trimeshinfo.cpp:216: error: expected unqualified-id before ?<? token > trimeshinfo.cpp:218: error: expected template-name before ?<? token > trimeshinfo.cpp:218: error: expected `{' before ?<? token > trimeshinfo.cpp:218: error: expected unqualified-id before ?<? token > > ... > > and LOT others... but I cut here. > > The line 216 of trimeshinfo is this (un-wrapped): > > class CVertex : public VertexSimp2< CVertex, CEdge, CFace, > vert::VFAdj, vert::Coord3f, vert::BitFlags, vert::Normal3f> {}; > > > I see that CVertex has not been forward declared. Is this the problem? > > > > Thanks, > Lino > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Vcg-devel mailing list > Vcg...@li... > https://lists.sourceforge.net/lists/listinfo/vcg-devel > > |
From: <lin...@gm...> - 2011-04-15 12:29:13
|
Hello, thanks for the good work. I am starting now to use your library and my main task is to compile the trimeshinfo application sample. I have seen that recently there have been some template changes. I get these errors compiling it ~/no_backup/tmp/cnr/soft/vcg/vcglib/apps/trimeshinfo $ g++ -I ../.. -I . trimeshinfo.cpp In file included from /usr/include/c++/4.3/ext/hash_map:64, from ../../vcg/space/index/spatial_hashing.h:45, from ../../vcg/complex/algorithms/clean.h:38, from trimeshinfo.cpp:196: /usr/include/c++/4.3/backward/backward_warning.h:33:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. In file included from XMLTree.h:10, from trimeshinfo.cpp:206: InstancesNode.h: In constructor ?InstanceNode::InstanceNode()?: InstancesNode.h:11: warning: deprecated conversion from string constant to ?char*? InstancesNode.h:11: warning: deprecated conversion from string constant to ?char*? In file included from trimeshinfo.cpp:206: XMLTree.h: At global scope: XMLTree.h:17: warning: deprecated conversion from string constant to ?char*? XMLTree.h: In member function ?void XMLTree::initializeMain()?: XMLTree.h:121: warning: deprecated conversion from string constant to ?char*? XMLTree.h:126: warning: deprecated conversion from string constant to ?char*? trimeshinfo.cpp: At global scope: trimeshinfo.cpp:216: error: expected template-name before ?<? token trimeshinfo.cpp:216: error: expected `{' before ?<? token trimeshinfo.cpp:216: error: expected unqualified-id before ?<? token trimeshinfo.cpp:218: error: expected template-name before ?<? token trimeshinfo.cpp:218: error: expected `{' before ?<? token trimeshinfo.cpp:218: error: expected unqualified-id before ?<? token ... and LOT others... but I cut here. The line 216 of trimeshinfo is this (un-wrapped): class CVertex : public VertexSimp2< CVertex, CEdge, CFace, vert::VFAdj, vert::Coord3f, vert::BitFlags, vert::Normal3f > {}; I see that CVertex has not been forward declared. Is this the problem? Thanks, Lino |
From: Fabio G. <fab...@gm...> - 2011-04-01 17:37:49
|
The changes concern the folder tree and some name. To update your code for this modification just make the following global search replace in your code tree and everything should be fine. /complex/trimesh/base.h --> /complex/complex.h /complex/trimesh/allocate.h --> /complex/allocate.h /complex/trimesh/append.h --> /complex/append.h /complex/trimesh/ --> /complex/algorithms/ /complex/local_optimization/ ---> /complex/algorithms/local_optimization/ /complex/local_optimization.h ---> /complex/algorithms/local_optimization.h /complex/intersection.h ---> /complex/algorithms/intersection.h /complex/boundary.h ---> /complex/algorithms/boundary.h Make sure the following search/replace is case dependent and entire word TriMesh ---> Complex End of short story. For those interested the long story follows: Why did you do this? The folders vertexmesh,edgemesh,trimesh and tetramesh were created when it was not possible/convenient to have a single definition for a complex. With the recent modifications to the definition of mesh, the TriMesh became de facto a general cell complex so we "promoted" the definition of TriMesh to Complex and raise its level in the tree. We also change the filename from base.h (another old story) to complex.h The folder "trimesh" was changed into "algorithms" to reflect the fact that it contains algorithms working on complexes (for example on quad or polygonal meshes) and not just in triangle meshes (again, as it was before). Is it over? No. The folders vertexmesh,edgemesh and tetramesh are going to disappear. They are almost empty anyway, the few algorithms will be moved inside "algorithms" shortly. cheers, Fabio&Paolo |
From: fabio g. <fab...@gm...> - 2011-04-01 14:36:19
|
Dear all, there will be a few changes to the library. It is minor stuff but, since that it involves some changes on the file paths, if you have modifications to commit please do it as soon as you can. cheers, fabio |
From: fabio g. <fab...@is...> - 2010-03-15 15:09:57
|
Dear all, there has been a small change to the way the mesh is defined. The details are in the commit log (and below ), this email is especially for those who usually do not read the commit log and could panic when their project fails to compile and the compiler returns obscure error messages. The samples projects in vcglib/apps/sample have been updated and the Meshlab filters are on their way. Should you have any trouble with this update, do not hesitate to post on the lists (meshlab-devel or vcg-devel) cheers, f. [ Changes in definition of TriMesh: PART I ] Note for the developers: the change to make to existing projects is very little but strictly necessary to compile. This change IS NOT backward compliant. ==== OLD ==== way to define a TriMesh: // forward declarations class MyVertex; class MyEdge; class MyFace; class MyVertex: public VertexSimp2 < MyVertex, MyEdge, MyFace, vertex::Coord3f,...other components>{}; class MyFace: public FaceSimp2 < MyVertex, MyEdge, MyFace, face::VertexRef,...other components>{}; class MyMesh: public TriMesh<vector<MyVertex>,vector<MyFace> >{}; ==== NEW ==== way to define a TriMesh: // forward declarations class MyVertex; class MyEdge; class MyFace; // declaration of which types is used as VertexType, which type is used as FaceType and so on... class MyUsedTypes: public vcg::UsedType < vcg::Use<MyVertex>::AsVertexType, vcg::Use<MyFace>::AsFaceType>{}; class MyVertex: public Vertex < MyUsedTypes, vertex::Coord3f,...other components>{}; class MyFace: public Face < MyUsedTypes, face::VertexRef,...other components>{}; class MyMesh: public TriMesh<vector<MyVertex>,vector<MyFace> >{}; ===== classes introduced [vcg::UsedType] : it is a class containing all the types that must be passed to the definition of Vertex, Face, Edge... This class replaces the list of classes to pass as first templates and the need to specify the maximal simplicial. So < MyVertex, MyEdge, MyFace, beocmes MyUsedTypes, and VertexSimp2 becomes Vertex [vcg::Use] : an auxiliary class to give a simple way to specify the role of a type Note 2: the order of templates parameters to vcg::UsedTypes is unimportant, e.g: class MyUsedTypes: public vcg::UsedType <vcg::Use<MyVertex>::AsVertexType, vcg::Use<MyEdge>::AsEdgeType, vcg::Use<MyFace>::AsFaceType>{}; is the same as: class MyUsedTypes: public vcg::UsedType <vcg::Use<MyFace>::AsFaceType, vcg::Use<MyEdge>::AsEdgeType, vcg::Use<MyVertex>::AsVertexType>{}; ==== the Part II will be a tiny change to the class TriMesh it self. |
From: Marco Di B. <mar...@is...> - 2010-03-15 15:09:51
|
Dear all, the GLEW library under code/lib/glew has been updated to the latest official version (1.5.3). The new version *should be* backward compatible. Cheers, Marco. ---------------------------------- Marco Di Benedetto Researcher Visual Computing Lab - ISTI - CNR http://vcg.isti.cnr.it ---------------------------------- |
From: fabio g. <fab...@is...> - 2010-03-15 14:50:16
|
"vcg::UsedType" is actually "vcg::UsedTypes" (plural) cheers, f. |
From: Gael G. <gae...@gm...> - 2008-10-30 01:11:34
|
UPDATE: eventually I managed to workaround the second incompatibility I listed about Transpose (but that does not means you should not care about updating them ;), see my remarks ) So, it remains only the dot product as the unique incompatibility. gael. On Wed, Oct 29, 2008 at 5:36 PM, Gael Guennebaud <gae...@gm...> wrote: > Dear all, > > for your information all the changes I made in vcg related to matrices > and points are enabled only if you define VCG_USE_EIGEN. > > Since 2 minutes or so, meshlab compiled with that token on the > following three platforms: > - linux, gcc 4.3 > - linux gcc 4.0.1 (= mac's version + epsilon) > - msvc 9.0 > > This token is now defined by default in meshlab. If you really have > big troubles, then edit the files shared.pri and meshlab/meshlab.pro > to remove it and, please, send me you compiler errors. > > In order to allow for a smooth transition, the goal was to try to keep > a source compatibility with previous matrix/point classes once > VCG_USE_EIGEN defined. In practice this was not entirely possible, and > here is the list of the major issues you might have while enabling > VCG_USE_EIGEN: > > - first of all make sure your code compile without it. In particular > we had to change Point*::Zero() to the more explicit SetZero(). Remind > that p.Zero(); set p to zero. Once VCG_USE_EIGEN is defined, p.Zero() > will still compile but it will do nothing ! Indeed in Eigen, Zero is a > static member function which returns the expression of a zero matrix > or vector. For consistency I've also changed the few other Zero() > functions which actually performed a "set *this to zero", a big regexp > replacement should do the job in most cases. > > - the second major difference is that the dot product is no longer > defined via the operator*. Instead use p1.dot(p2). Perhaps we can also > add a global function vcg::dot(p1,p2) if some of you would prefer such > a syntax. Fortunately those errors are caught at compile time: you > should first get some weird messages stating that it cannot convert a > Eigen::Product<...> to a scalar followed by the very explicit: > invalid_vector_vector_product__if_you_wanted_a_dot_or_coeff_wise_product_you_must_use_the_explicit_functions > > - the third and last incompatibility is with respect to m.Transpose() > and vcg::Transpose(m). I cannot provide such functions because > Transpose is the name of a class in Eigen. The quick fix is to replace > them by either: > * m.transposeInPlace() if you really want to transpose the matrix > you have in hand (it returns nothing). > * m.transpose() if you only want to use the transpose of m (it does > not change m, and returns a transposed expression) > If you want to be a bit smarter, you should also check for code like that: > Matrix33 mt = m; > mt.Transpose(); > m * mt; > which should be replaced by the more efficient and intuitive: m * > m.transpose(); > Note that those 2 functions also work if VCG_USE_EIGEN is not defined. > > - finally I removed a couple of things which seemed to be used only > internally by vcg math classes like MatrixDiag*, and LinearSolver. > Again fell free to contact me if that's a major problem for you or if > you are unsure about how to work around. > > These 3 modifications are the only ones I had to do to make meshlab > compatible. So you have some troubles please report them to me. > > Once you've done that you can start using Eigen's API which is > available trough all Matrix and Point types. > > Of course, this is only the first step towards this major change, more > to come later... > > > cheers, > gael. > > > > > On Tue, Oct 28, 2008 at 9:44 AM, Paolo Cignoni > <pao...@is...> wrote: >> Dear Developers, >> >> as you could have noted, some major changes happened to our VCG library: >> the currently very chaotic, buggy, and incomplete math folder is going >> to be replaced by >> a clean, documented and efficient template library for linear algebra >> (vectors, matrices, >> and related algorithms): Eigen ( http://eigen.tuxfamily.org ) >> >> You should have seen a new folder in the vcglib repository, eigen, this >> folder >> is a SVN direct link to the repository of eigen, so you have no write >> permission >> on that folder (you have to be a eigen developer to commit stuff there). >> More details on these changes later. >> >> In the meantime, if something stop compiling, dont panic :) >> >> I wish to thank warmly Gael Guennebaud, a core developer of eigen, for >> suggesting and implementing this change >> (and obviously for all his point related contribs inside meshlab :) ) >> >> Cheers >> >> Paolo >> >> -- >> Paolo Cignoni -- Senior Researcher >> Visual Computing Laboratory - ISTI - CNR >> http://vcg.isti.cnr.it/~cignoni >> >> ISTI - CNR >> Via Moruzzi 1, >> 56124 Pisa >> ITALY >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Vcg-devel mailing list >> Vcg...@li... >> https://lists.sourceforge.net/lists/listinfo/vcg-devel >> > |
From: Gael G. <gae...@gm...> - 2008-10-29 16:36:52
|
Dear all, for your information all the changes I made in vcg related to matrices and points are enabled only if you define VCG_USE_EIGEN. Since 2 minutes or so, meshlab compiled with that token on the following three platforms: - linux, gcc 4.3 - linux gcc 4.0.1 (= mac's version + epsilon) - msvc 9.0 This token is now defined by default in meshlab. If you really have big troubles, then edit the files shared.pri and meshlab/meshlab.pro to remove it and, please, send me you compiler errors. In order to allow for a smooth transition, the goal was to try to keep a source compatibility with previous matrix/point classes once VCG_USE_EIGEN defined. In practice this was not entirely possible, and here is the list of the major issues you might have while enabling VCG_USE_EIGEN: - first of all make sure your code compile without it. In particular we had to change Point*::Zero() to the more explicit SetZero(). Remind that p.Zero(); set p to zero. Once VCG_USE_EIGEN is defined, p.Zero() will still compile but it will do nothing ! Indeed in Eigen, Zero is a static member function which returns the expression of a zero matrix or vector. For consistency I've also changed the few other Zero() functions which actually performed a "set *this to zero", a big regexp replacement should do the job in most cases. - the second major difference is that the dot product is no longer defined via the operator*. Instead use p1.dot(p2). Perhaps we can also add a global function vcg::dot(p1,p2) if some of you would prefer such a syntax. Fortunately those errors are caught at compile time: you should first get some weird messages stating that it cannot convert a Eigen::Product<...> to a scalar followed by the very explicit: invalid_vector_vector_product__if_you_wanted_a_dot_or_coeff_wise_product_you_must_use_the_explicit_functions - the third and last incompatibility is with respect to m.Transpose() and vcg::Transpose(m). I cannot provide such functions because Transpose is the name of a class in Eigen. The quick fix is to replace them by either: * m.transposeInPlace() if you really want to transpose the matrix you have in hand (it returns nothing). * m.transpose() if you only want to use the transpose of m (it does not change m, and returns a transposed expression) If you want to be a bit smarter, you should also check for code like that: Matrix33 mt = m; mt.Transpose(); m * mt; which should be replaced by the more efficient and intuitive: m * m.transpose(); Note that those 2 functions also work if VCG_USE_EIGEN is not defined. - finally I removed a couple of things which seemed to be used only internally by vcg math classes like MatrixDiag*, and LinearSolver. Again fell free to contact me if that's a major problem for you or if you are unsure about how to work around. These 3 modifications are the only ones I had to do to make meshlab compatible. So you have some troubles please report them to me. Once you've done that you can start using Eigen's API which is available trough all Matrix and Point types. Of course, this is only the first step towards this major change, more to come later... cheers, gael. On Tue, Oct 28, 2008 at 9:44 AM, Paolo Cignoni <pao...@is...> wrote: > Dear Developers, > > as you could have noted, some major changes happened to our VCG library: > the currently very chaotic, buggy, and incomplete math folder is going > to be replaced by > a clean, documented and efficient template library for linear algebra > (vectors, matrices, > and related algorithms): Eigen ( http://eigen.tuxfamily.org ) > > You should have seen a new folder in the vcglib repository, eigen, this > folder > is a SVN direct link to the repository of eigen, so you have no write > permission > on that folder (you have to be a eigen developer to commit stuff there). > More details on these changes later. > > In the meantime, if something stop compiling, dont panic :) > > I wish to thank warmly Gael Guennebaud, a core developer of eigen, for > suggesting and implementing this change > (and obviously for all his point related contribs inside meshlab :) ) > > Cheers > > Paolo > > -- > Paolo Cignoni -- Senior Researcher > Visual Computing Laboratory - ISTI - CNR > http://vcg.isti.cnr.it/~cignoni > > ISTI - CNR > Via Moruzzi 1, > 56124 Pisa > ITALY > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Vcg-devel mailing list > Vcg...@li... > https://lists.sourceforge.net/lists/listinfo/vcg-devel > |
From: Paolo C. <pao...@is...> - 2008-10-28 18:00:45
|
Dear Developers, as you could have noted, some major changes happened to our VCG library: the currently very chaotic, buggy, and incomplete math folder is going to be replaced by a clean, documented and efficient template library for linear algebra (vectors, matrices, and related algorithms): Eigen ( http://eigen.tuxfamily.org ) You should have seen a new folder in the vcglib repository, eigen, this folder is a SVN direct link to the repository of eigen, so you have no write permission on that folder (you have to be a eigen developer to commit stuff there). More details on these changes later. In the meantime, if something stop compiling, dont panic :) I wish to thank warmly Gael Guennebaud, a core developer of eigen, for suggesting and implementing this change (and obviously for all his point related contribs inside meshlab :) ) Cheers Paolo -- Paolo Cignoni -- Senior Researcher Visual Computing Laboratory - ISTI - CNR http://vcg.isti.cnr.it/~cignoni ISTI - CNR Via Moruzzi 1, 56124 Pisa ITALY |
From: fabio g. <fab...@gm...> - 2008-07-28 13:43:14
|
Dear developers, what described in the last email by Paolo Cignoni has happened again, in the very same way (by a different account). We deeply appreciate the effort everyone puts in the library, and with "we" I mean you and everybody who use the library and Meshlab, but please pay attention when committing. We all may accidentally create bugs in the code, but to fill the top level of the folder hierarchy with trash is going a little too far. There is a zillion things to do better than to clean up the mess done out of lack of carefulness, which is what Paolo is doing right now. "I you are not perfectly sure of what a svn command do, please DO NOT ATTEMPT anything.(particularly at late night hours) Read the svn manuals again and again before doing anything." all the best, Fabio Ganovelli |
From: Paolo C. <pao...@is...> - 2008-07-27 07:18:11
|
To Marco Tarini, (and, just for remembering, to everyone who has commit authority on vcg and meshlab) referring to the meaningless trash that is appeared in the repository above the trunk level. (like a wonderful file named conf/passwd http://vcg.svn.sourceforge.net/viewvc/vcg/conf/passwd?view=markup&pathrev=2845 ) **** Please, please, please **** **** before doing any commit action **** **** think twice!! ALWAYS!! **** I you are not perfectly sure of what a svn command do, please DO NOT ATTEMPT anything. (particularly at late night hours) Read the svn manuals again and again before doing anything. If you need other good reasons for being careful simply remember that commit logs are copied on various sites and are crawled by google, and the consequences of your actions will be around forever (this is one of the reasons I usually requires a commit login == to you last name...) For example: http://vcg.svn.sourceforge.net/viewvc/vcg?view=rev&revision=2845 and here: http://cia.vc/stats/author/tarini/.message/0 and here: http://www.ohloh.net/projects/5759/commits and probably in some other spots... Cheers Paolo Cignoni PS Sorry for my harshness but, I have better options for summer sunday morning than cleaning up repositories from trash poured in by ignorance. -- Paolo Cignoni -- Senior Researcher Visual Computing Laboratory - ISTI - CNR http://vcg.isti.cnr.it/~cignoni ISTI - CNR Via Moruzzi 1, 56124 Pisa ITALY |
From: Paolo C. <pao...@is...> - 2008-06-29 23:06:27
|
Thanks a lot for your kind bug submission. (and thanks for the mail on the devel list1 :) ) I have committed your requested changes but the ones on the ball pivoting. I want to look better at the code with the original developer before committing your changes Thanks again and i hope that you will continue to provide us hints on how improve the lib cheers p. Alain Boyer wrote: > Hello, > > I have been using the VCG library for some time now and I must say that > it works very well. It is fast, flexible and quite complete. Great work! > > However, I did find a few bugs. I took the time to enter them in the > SourceForge bug tracker, although it doesn't really seem to be used very > much. Since most of them have patches, I figured I would send an email > to the list to make them more visible. > > > [ 1903296 ] Unused method warning in ply code > http://sourceforge.net/tracker/index.php?func=detail&aid=1903296&group_id=98764&atid=621962 > > [ 2002670 ] Silence compiler warnings > http://sourceforge.net/tracker/index.php?func=detail&aid=2002670&group_id=98764&atid=621962 > > [ 2002673 ] Meshlab code in VCG source tree > http://sourceforge.net/tracker/index.php?func=detail&aid=2002673&group_id=98764&atid=621962 > > Committed > [ 2002678 ] Ball pivoting algorithm randomly crashes > http://sourceforge.net/tracker/index.php?func=detail&aid=2002678&group_id=98764&atid=621962 > This one caused me quite a bit of trouble... > > [ 2002684 ] Increase flexibility of ball pivoting algorithm > http://sourceforge.net/tracker/index.php?func=detail&aid=2002684&group_id=98764&atid=621962 > This is more of an enhancement. If I wasn't clear in the report please > let me know and I will attempt to explain further. > > > Thanks again, > > Alain Boyer. > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Vcg-devel mailing list > Vcg...@li... > https://lists.sourceforge.net/lists/listinfo/vcg-devel > > -- Paolo Cignoni -- Senior Researcher Visual Computing Laboratory - ISTI - CNR http://vcg.isti.cnr.it/~cignoni ISTI - CNR Via Moruzzi 1, 56124 Pisa ITALY |
From: Alain B. <abo...@uo...> - 2008-06-25 20:05:04
|
Hello, I have been using the VCG library for some time now and I must say that it works very well. It is fast, flexible and quite complete. Great work! However, I did find a few bugs. I took the time to enter them in the SourceForge bug tracker, although it doesn't really seem to be used very much. Since most of them have patches, I figured I would send an email to the list to make them more visible. [ 1903296 ] Unused method warning in ply code http://sourceforge.net/tracker/index.php?func=detail&aid=1903296&group_id=98764&atid=621962 [ 2002670 ] Silence compiler warnings http://sourceforge.net/tracker/index.php?func=detail&aid=2002670&group_id=98764&atid=621962 [ 2002673 ] Meshlab code in VCG source tree http://sourceforge.net/tracker/index.php?func=detail&aid=2002673&group_id=98764&atid=621962 [ 2002678 ] Ball pivoting algorithm randomly crashes http://sourceforge.net/tracker/index.php?func=detail&aid=2002678&group_id=98764&atid=621962 This one caused me quite a bit of trouble... [ 2002684 ] Increase flexibility of ball pivoting algorithm http://sourceforge.net/tracker/index.php?func=detail&aid=2002684&group_id=98764&atid=621962 This is more of an enhancement. If I wasn't clear in the report please let me know and I will attempt to explain further. Thanks again, Alain Boyer. |
From: Paolo C. <pao...@is...> - 2008-05-19 12:47:58
|
Dear developers, as announced the transition CVS-> SVN of the vcg lib has been completed, the ONLY repository for the vcg library is now the SVN repository. Do not commit any more on the CVS server (it will be closed and discarded in the next days). Please note the NEW directory structure. The base dir of the vcg library is changed from the rather anonymous sf to the more descriptive vcglib. (The pro files of meshlab will be updated to reflect the new structure in the next hours.) So for example ifyou are a meshlab developer you should have at the same level two dirs meshlab and vcglib. Details on how use the new svn server to get the sources are, as usual, on the meshlab compiling page: http://meshlab.sourceforge.net/wiki/index.php/Compiling Cheers Paolo -- Paolo Cignoni -- Senior Researcher Visual Computing Laboratory - ISTI - CNR http://vcg.isti.cnr.it/~cignoni ISTI - CNR Via Moruzzi 1, 56124 Pisa ITALY |
From: Paolo C. <pao...@is...> - 2008-05-14 16:51:27
|
As we have promised many times, we will move the VCG Library repository from CVS to SVN, The planned date for the cvs to svn switch for the VCG library repository is: ****** Monday May 19th 09:00 gmt ***** So be careful and remember to commit all your changes before that date. Be prepared and start to install a svn client. Windows users should not encounter too much difficulties. TortoiseSVN is quite similar to TortoiseCVS (even better I would like to say) After monday the CVS server will no more be usable. and the svn repository will be the only one that should be used. Cheers p. -- Paolo Cignoni -- Senior Researcher Visual Computing Laboratory - ISTI - CNR http://vcg.isti.cnr.it/~cignoni ISTI - CNR Via Moruzzi 1, 56124 Pisa ITALY |
From: Paolo C. <pao...@is...> - 2008-05-05 12:11:43
|
Dear Developers, The meshlab source repository has been successfully moved from cvs to svn. for the devs with a command line attitude the new repository can be checked out with: svn co https://meshlab.svn.sourceforge.net/svnroot/meshlab/trunk/meshlab meshlab Usual info on the wiki http://meshlab.sourceforge.net/wiki/index.php/Compiling Remember thath the meshlab CVS repository is no more used! DO NOT COMMIT ANYTHING ON THE MESHLAB CVS REPOSITORY. Anything committed to meshlab cvs will be lost. If no particular issue will come up the vcg library will follow the same path in the next weeks. Cheers P. -- Paolo Cignoni -- Senior Researcher Visual Computing Laboratory - ISTI - CNR http://vcg.isti.cnr.it/~cignoni ISTI - CNR Via Moruzzi 1, 56124 Pisa ITALY |
From: Paolo C. <pao...@is...> - 2007-12-22 09:06:44
|
Magari evitiamo di fare commit nella libreria senza metterci uno straccio di commento... Buon natale :) p. -- Paolo Cignoni -- Senior Researcher Visual Computing Laboratory - ISTI - CNR http://vcg.isti.cnr.it/~cignoni ISTI - CNR Via Moruzzi 1, 56124 Pisa ITALY |
From: Paolo C. <pao...@is...> - 2007-10-16 17:04:15
|
Dopo due anni (quasi) ho iniziato a fare quella modifica proposta tempo addietro D'ora in poi usare SetD() e modificarsi a manina vn o fn e' diventato deprecato e si deve usare Allocator<Mesh>::DeleteFace(m,*fi); Allocator<Mesh>::DeleteVertex(m,*vi); Sono partito a fare la caccia a tutti i SetD e a tutti gli accessi a vn e fn.... tremate.... p. -- Paolo Cignoni -- Senior Researcher Visual Computing Laboratory - ISTI - CNR http://vcg.isti.cnr.it/~cignoni ISTI - CNR Via Moruzzi 1, 56124 Pisa ITALY |
From: massimiliano c. <mas...@is...> - 2007-05-16 08:36:23
|
Dicevamo ieri che una modifica da sottolineate e' relativa al metodo Apply(). Ossia, con la nuova trackball, se si vuole che questa venga disegnata bisogna scrivere Apply(true) altrimenti tutte le trackball spariranno... Max Paolo Cignoni wrote: > La classe trackball, grazie allo strenuo lavoro del baldo tirocinante > Benedetti, ha subito una serie di grosse modifiche > per permettere la sua estendibilita'. > > La cosa che salta subito all'occhio e' che qualcosa e' cambiato > nell'icona della trackball, che ora cambia a seconda del trackmode. > (quelle che vedete sono particolarmente temporanee e probabilmente > presto miglioreranno da un punto di vista grafico) > > Sono anche apparsi un tot di trackmode nuovi che possono sempre far > comodo (soprattutto manipolatori vincolati) > > Al 99.99% queste modifiche dovrebbero essere tutte compatibili > all'indietro. > Ma al solito se fate un update della lib e ricompilatele vostre > applicazioni e controllate che tutto funga come prima e' sicuramente meglio. > > Buon rebuild > > P. > > |
From: Paolo C. <pao...@is...> - 2007-05-16 08:25:00
|
La classe trackball, grazie allo strenuo lavoro del baldo tirocinante Benedetti, ha subito una serie di grosse modifiche per permettere la sua estendibilita'. La cosa che salta subito all'occhio e' che qualcosa e' cambiato nell'icona della trackball, che ora cambia a seconda del trackmode. (quelle che vedete sono particolarmente temporanee e probabilmente presto miglioreranno da un punto di vista grafico) Sono anche apparsi un tot di trackmode nuovi che possono sempre far comodo (soprattutto manipolatori vincolati) Al 99.99% queste modifiche dovrebbero essere tutte compatibili all'indietro. Ma al solito se fate un update della lib e ricompilatele vostre applicazioni e controllate che tutto funga come prima e' sicuramente meglio. Buon rebuild P. -- Paolo Cignoni http://vcg.isti.cnr.it/~cignoni ISTI - CNR Via Moruzzi 1, 56124 Pisa ITALY |