Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Close
From: MingChing Chang <mcchang@le...>  20041001 21:02:13
Attachments:
Message as HTML

Dear VXL Developers, This is MingChing Chang from Brown University. I have a question about = vtol library in 3D. If you are an expert in vtol or you are currently = working on it, please let me know your feedback. I appreciate your help. I am working on vtol/vsol libraries on 3D applications. In a series of = meeting with Prof. Joe L. Mundy and other developers in Brown = University, we decide to improve the current vtol library to handle 3D = applications better. However, we found that the current vtol hierarchy = is mainly designed for 2D applications. To extend it to 3D, I need to = make big changes. The first problem I have encountered is that the = vtol_topology_object is currently inherented from = vsol_spatial_object_2d, which is difficult to extend to 3D. // vsol_spatial_object_2d //  // vtol_topology_object //  //  //        // vertex zero_chain edge one_chain face two_chain block //    // vertex_2d edge_2d face_2d I have the dilemma of making multiinheritance of 2d/3d classes or = duplicate the classes like this (i.e. completely separate the 2D and 3D = libraries): vsol_spatial_object_2d  vtol_topology_object_2d  =        =  vertex_2d zero_chain_2d edge_2d one_chain_2d face_2d = two_chain_2d block_2d and vsol_spatial_object_3d  vtol_topology_object_3d  =        =  vertex_3d zero_chain_3d edge_3d one_chain_3d face_3d = two_chain_3d block_3d Our current plan is to complete separate the 2D and 3D classes, so we = can avoid the type casting issue. If I make the vtol_topology_object = inherented from both 2d and 3d spatial_object, I will have compiling = error on the type casting functions.=20 The other issue is, let's say the separation is the solution, how to = minimize the duplication? In other words, many of the vtol functions are = dimensionindependent, we should avoid duplication in a nice way. That's = why in the original design, vtol_vertex class is separated from = vtol_vertex_2d class, I guess. Can I still keep those classes = dimensionindependent as far as I can? If you have any idea of how to solve this problem in a nice way, please = let me know. I appreciate your help very much.=20 If you are a developer of vtol, please tell me your opinion about those = changes. If you an user of vtol and you don't like those changes, please = let me know ASAP. I expect a big change on the code, even with the best = plan. Thank you for your attention. MingChing Chang LEMS, Engineering Brown University mcchang@... 
From: Peter Vanroose <Peter.V<anroose@es...>  20041003 20:27:26

> I have the dilemma of making multiinheritance of 2d/3d classes or duplicate the classes (i.e. completely separate the 2D and 3D libraries) In the ideal world, topology should be embeddingdimensionindependent, i.e., there should be just one vtol_topology_object class and it should not inherit from vsol_spatial_object_2d. It's only at the point where a vtol_vertex points to its geometry, that it becomes clear whether the vertex is embedded in 2D or in 3D (or possibly in 1D!). Maybe the solution is to create a vsol_spatial_object class as a common parent for vsol_spatial_object_[23]d and vtol_topology_object. An other solution could be to make vtol_topology_object not inherit from vsol_spatial_object (but directly from vul_timestamp and vbl_ref_count). Still another solution, which has been discussed before on this list, would be to make vtol_topology_object a templated class, templated on the "spatial object class hierarchy" (being some kind of enum). Allowing for e.g. topology on a projective geometry space. But I'm afraid this solution would make the whole structure more difficult to understand for a firsttime user. I would certainly not make vtol_topology_object multiinherited from 2D and 3D.  Peter. 
From: Amitha Perera <perera@cs...>  20041004 13:30:42

MingChing, I think it would be great to give the current vtol an overhaul and refactor the code. I'm glad you are proposing to do so. From your message, I gather that your work is focused mostly on adding the 3D support. It would be great if you had time to overhaul the current 2D stuff too. For example:  vtol_topology_object should probably not derive from vsol_spatial_object_2d. If necessary, vtol_vertex_2d and relatives could derive from it. Or perhaps simply contain pointers to the spatial objects. Or perhaps the inheritance should be the other way. After all, is a 2D point a vertex, or is a vertex a 2D point?  Are the nchains necessary? Yes, in a theoretical sense. But are they necessary in practice? Already there are functions to bypass the chains and go directly from, say, faces to edges.  Are timestamps used with spatial objects? I agree with you and Peter that inheriting a vtol_topology_object from both a 2d and 3d spatial object is not correct. I hope that when you are done with the changes, you can document the design decisions, and provide examples on how things should be used. Amitha. 