| 00:21.08 | *** join/#brlcad krcevnzncbxyguxx (~armin@dslb-088-064-047-237.088.064.pools.vodafone-ip.de) |
| 00:30.04 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 02:50.25 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 03:14.06 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 03:27.21 | *** topic/#brlcad by brlcad -> Welcome to BRL-CAD! || Don't ask if someone is here, ask a better question. || GSoC 2016 is under way, 9 CAx students! || Release 7.26.0 by 27th... || Logs: http://ibot.rikers.org/%23brlcad/ |
| 03:30.13 | *** join/#brlcad tandoorichick (75d837cb@gateway/web/freenode/ip.117.216.55.203) |
| 03:31.56 | brlcad | tandoorichick: how are your setup and preparations coming along? |
| 03:32.43 | brlcad | tandoorichick: please update your dev log with a summary of all the work you've done during the bonding period |
| 03:32.58 | tandoorichick | brlcad: yes they're going good. yet to decide on the method to use for the portable module. |
| 03:33.17 | brlcad | tandoorichick: I didn't fully understand your e-mail |
| 03:33.33 | brlcad | i mean, your first option was pretty clear -- it was the second that was unclear |
| 03:33.41 | tandoorichick | Yes i'm in the middle of that, will be done by today.. had a few problems setting up the blog, now it's done. so i'll be updating the content and adding the link.. |
| 03:34.01 | tandoorichick | the first option being what daniel sugegsted? |
| 03:34.12 | tandoorichick | or the first part of what i suggested? |
| 03:35.21 | tandoorichick | so ok i'll explain it here then |
| 03:35.58 | tandoorichick | so, what that method does it create a structure that contains all the attributes for a mesh that we could possibly need (of course spanning just the needs of BRL- |
| 03:36.06 | tandoorichick | CAd and OpenSCAD) |
| 03:37.07 | tandoorichick | so for OpenSCAD, it is just the PolySet class which just contains information about all the polygons in the mesh. and we're quite familiar with the rt_bot_internal structure |
| 03:39.04 | tandoorichick | essentially because the bot type is a superset of the polyset type (because it includes stuff like mode, thickness, orientation, etc.), what we'll be doing while converting polyset to the intermediate mesh is set those attributes that don't apply to NULL. |
| 03:39.43 | tandoorichick | converting rt_bot_internal to the intermediate type will be trivial because the two structures will essentially contain the same information. |
| 03:40.15 | tandoorichick | this is what i had proposed.. have i made myself clearer? |
| 03:40.17 | brlcad | right, I got that regarding your struct example |
| 03:41.01 | brlcad | it was your next statement: "do you feel it'd be more robust using the generic container and defining the conversion process separately in the utility functions?" |
| 03:41.01 | brlcad | are you suggesting that there'd be two of every utility funciton or something? |
| 03:42.14 | tandoorichick | in the first method (what daniel had suggested), the conversion process essentially lies in the functions - so there'd be two of them right? |
| 03:42.42 | tandoorichick | like get_face or get_num_faces, etc.? |
| 03:43.45 | tandoorichick | these are going to be dependent on the native structures. that's why i suggested the second one, where the conversion process primarily gets over before we even define the functions? |
| 03:43.53 | tandoorichick | .* |
| 03:44.38 | brlcad | I'm still not following -- say I have a "heal_mesh()" top-level function ... it's going to take a data structure of some sort |
| 03:44.50 | brlcad | e.g., struct polygonal_mesh |
| 03:45.25 | tandoorichick | ok? |
| 03:45.28 | brlcad | OR .. there's a heal_brlcad_mesh() and heal_openscad_mesh() |
| 03:45.34 | brlcad | what other alternative is there? |
| 03:45.47 | brlcad | void*? |
| 03:46.42 | brlcad | what I'm not understanding is this second option where the conversion process is defined separately in the utility functions -- what that actually means |
| 03:46.44 | tandoorichick | we're going for the heal_mesh() which takes in the intermediate mesh, that's more efficient right? |
| 03:47.21 | brlcad | I'm asking you what you meant |
| 03:47.38 | brlcad | certainly could be a heal_mesh(struct polygonal_mesh *); |
| 03:48.17 | tandoorichick | ok so we have the struct polygonal_mesh defined. |
| 03:48.55 | brlcad | that struct polygonal_mesh could contain a generic structure or it could contain void*'s or it could contain typed fields for each format (probably a terrible idea) or ... |
| 03:49.51 | brlcad | ok |
| 03:50.16 | tandoorichick | i don't understand your last question.. i'll just try to explain again. |
| 03:50.24 | brlcad | before you do |
| 03:50.25 | tandoorichick | now, for BRL-CAD, we implement it as a rt_bot_internal structure, and for OpenSCAD, as a polyset structure.. |
| 03:50.32 | tandoorichick | yes? |
| 03:50.37 | brlcad | all I'm really trying to understand is what you meant by "defining the conversion process separately in the utility functions" |
| 03:51.05 | brlcad | please continue |
| 03:51.17 | tandoorichick | yeah so for example if we need to get the number of faces of polygonal_mesh, what we'll do is: |
| 03:53.47 | tandoorichick | for BRL-CAD, we'd do it like this: we define the polygonal_mesh as an rt_bot_internal type. that is - struct polygonal_mesh( rt_bot_internal bot; } . now if we need to get the number of faces, we do this: int get_num_faces(struct *polygonal_mesh) { return polygonal_mesh->bot->num_faces; } |
| 03:56.02 | tandoorichick | for OpenSCAD: we define polygonal_mesh as: struct polygonal_mesh{ PolySet polyset_mesh; } . and for getting the number of faces: int get_num_faces(polygonal_mesh *mesh) { return mesh->sizeof(polyset_mesh); } |
| 03:56.30 | tandoorichick | in the get_num_faces for BRL-CAD, i meant int get_num |
| 03:56.45 | tandoorichick | _face (polygonal_mesh *mesh) |
| 03:56.55 | tandoorichick | sorry for all the typos.. |
| 03:57.10 | tandoorichick | is this what you wanted to know? |
| 03:58.53 | brlcad | hmm |
| 03:59.55 | tandoorichick | is it more understandable now? :) |
| 04:00.42 | brlcad | the problem I see is that your utility functions are going to amount to accessors for the generic intermediate container you defined in the first example |
| 04:01.41 | brlcad | to amount to accessors for == be the same as having |
| 04:02.14 | tandoorichick | yeah.. i don't understand the problem though.. |
| 04:02.42 | brlcad | now if you worked in C++, I could totally see having some sort of derived brlcad_bot class and openscad_mesh class that have some common virtual base class |
| 04:02.52 | brlcad | but you were planning on working in C, yes? |
| 04:03.36 | tandoorichick | uhm yes, but since it's going to be a portable module it could be done in C++ right? |
| 04:03.54 | brlcad | I think that's basically the difference between your first and second versions -- the prior is a data-centric model that you'd do in C, the latter is a composition-centric model that you'd do in C++ |
| 04:04.30 | brlcad | so basically, are you more familiar with C or C++? |
| 04:05.10 | tandoorichick | both equally i guess.. i use them alternatively.. |
| 04:05.37 | brlcad | no such thing as equal :) |
| 04:06.09 | tandoorichick | oh well, then C++ it'll be :) |
| 04:06.21 | brlcad | so, then I think that's a decision you need to make with daniel in the loop |
| 04:06.45 | tandoorichick | yeah sure, i'm yet to hear from him on the mailing list.. |
| 04:07.11 | tandoorichick | i'll be updating my dev log/blog entry meanwhile |
| 04:07.44 | brlcad | well your e-mail wasn't clear so he may have had just as much trouble following |
| 04:07.58 | brlcad | but he's a smarter man than I am, so maybe just busy too ;) |
| 04:08.59 | tandoorichick | actually half the stuff i explained here, was what he'd told me on the mailing list.. |
| 04:09.23 | tandoorichick | or do you think i should send another mail stating my strategy more clearly? |
| 04:11.02 | brlcad | no |
| 04:12.19 | brlcad | just a general note -- you should make progress forward just like you've been doing regardless of there being questions |
| 04:12.51 | brlcad | obviously try to get them answered, but some aren't answerable until more progress is made or the problem is more concrete like you spelling out an example here |
| 04:13.22 | tandoorichick | sure, will keep it in mind. :) |
| 04:14.03 | brlcad | fwiw, now that you're further along, I suggest writing an actual header file with comments instead of prose |
| 04:14.48 | brlcad | maybe write a front end driver application for how this would be used before it's implemented (in pseudocode or real code) |
| 04:15.53 | tandoorichick | you mean like putting everything i explained here, as comments? |
| 04:16.09 | tandoorichick | of course for just the method that we decide on right? |
| 04:22.11 | brlcad | right |
| 04:22.46 | brlcad | but not focusing so much on the comments as actually starting towards stubbing in proper class structures, functions, structs, whatever (and yes, putting some comments with them to explain if needed) |
| 04:22.50 | brlcad | simple test program might look something like this: #include "MeshCleanup.h" ; int main() { Mesh *mesh = NULL; if (MeshCleanup::Type(argv[1]) == MeshCleanup::BRLCAD_BOT) mesh = new BrlcadMesh(argv[1]); else if (MeshCleanup::Type(argv[1]) == MeshCleanup::OPENSCAD_MESH) mesh = new OpenscadMesh(argv[1]); mesh->closeGaps(); mesh->write(argv[2]); return 0;} |
| 04:23.50 | brlcad | you could create a "stub" MeshCleanup.h file that would let something like that actually compile .. obviously wouldn't work until you implement the guts, but it will get you thinking about how this will be used before you get lost in the weeds |
| 04:24.45 | tandoorichick | ok got it. :) |
| 04:28.37 | brlcad | concrete examples move the discussion forward ;) |
| 04:52.34 | tandoorichick | brlcad: will keep it in mind from next time onwards! |
| 05:15.33 | *** join/#brlcad kanzure (~kanzure@unaffiliated/kanzure) |
| 06:25.55 | *** join/#brlcad tofu_ (~sean@104.225.5.10) |
| 06:42.01 | *** join/#brlcad merzo (~merzo@32-20-133-95.pool.ukrtel.net) |
| 06:44.34 | *** join/#brlcad merzo (~merzo@32-20-133-95.pool.ukrtel.net) |
| 06:53.37 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 07:13.34 | *** join/#brlcad d_rossberg (~rossberg@104.225.5.10) |
| 07:23.59 | *** join/#brlcad sniok (~sniok@89.252.29.238) |
| 07:39.51 | *** join/#brlcad teepee` (bc5c2134@gateway/web/freenode/ip.188.92.33.52) |
| 11:03.32 | tandoorichick | d_rossberg: i didn't het this question of yours: "If you do the vertex contraction with the triangulated boundary of a plate mode BoT, how will this compare with the contraction of the vertices of the original BoT?" |
| 11:03.39 | tandoorichick | get* |
| 11:07.49 | d_rossberg | a plate mode bot is a solid -> has a boundary -> triangulate the boundary |
| 11:17.14 | tandoorichick | i was talking about vertex contraction while healing gaps in meshes.. how does the relation between the two scenarios you mentioned come in? |
| 11:28.07 | d_rossberg | what would be the difference between haling the plate mode bot and healing its boundary representation bot? |
| 11:46.39 | d_rossberg | i.e. what's the difference of the results (volume object) if you 1) heal the plate mode bot and 2) heal its facetized boundary representation bot |
| 11:48.14 | d_rossberg | ideally it should be the same (i.e equivalent) |
| 14:45.29 | tandoorichick | well it depends: if we're healing a plate mode bot by "gluing" i to something outside of it, it will be the same. if there are defects inside it, then triangulating the brep will be a lot less like the original, i.e. fidelity decreases.. |
| 14:45.56 | tandoorichick | sorry for the late reply, i got in the middle of something.. |
| 14:46.34 | *** join/#brlcad amarjeet (~amarjeet@101.211.162.159) |
| 15:25.07 | d_rossberg | i thought at the vertex contraction feature you wrote about |
| 15:42.28 | *** join/#brlcad merzo (~merzo@32-20-133-95.pool.ukrtel.net) |
| 15:43.07 | Notify | 03BRL-CAD Wiki:Tandoorichick * 9720 /wiki/Google_Summer_of_Code/2016: /* Automatic Polygonal Mesh Healing */ |
| 15:56.42 | *** join/#brlcad djkonro (~konro@41.202.219.77) |
| 16:27.21 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 16:38.49 | *** join/#brlcad ickby (~stefan@p4FD3C9AE.dip0.t-ipconnect.de) |
| 16:55.10 | *** join/#brlcad Mandeep_Singh (~mandeep@117.199.103.101) |
| 16:58.39 | *** join/#brlcad djkonro (~konro@41.202.219.72) |
| 19:45.32 | *** join/#brlcad merzo (~merzo@11-143-53-37.pool.ukrtel.net) |
| 20:16.35 | *** join/#brlcad LordOfBikes (~armin@dslb-088-064-047-237.088.064.pools.vodafone-ip.de) |
| 20:38.38 | *** join/#brlcad djkonro (~djkonro@41.202.219.71) |
| 20:46.52 | *** join/#brlcad LordOfBikes (~armin@dslb-088-064-047-237.088.064.pools.vodafone-ip.de) |
| 21:19.42 | *** join/#brlcad djkonro (~djkonro@41.202.219.72) |
| 21:23.59 | starseeker | Hmm: https://github.com/Kitware/QtTesting |
| 21:38.45 | *** join/#brlcad Guest31597 (~djkonro@41.202.219.76) |
| 21:58.52 | *** join/#brlcad Guest31597 (~djkonro@41.202.219.77) |
| 22:23.12 | *** join/#brlcad Guest31597 (~djkonro@41.202.219.77) |
| 23:01.20 | *** join/#brlcad Guest31597 (~djkonro@41.202.219.73) |