| 00:05.21 | *** join/#brlcad mpictor (~mark@c-69-136-183-213.hsd1.in.comcast.net) |
| 00:22.17 | clock | brlcad, how can I separate the BRL-CAD C source from the 3rd party libraries as I said for purpose of stat analysis? |
| 00:22.40 | clock | brlcad, rm -rf src/other is the right way? |
| 00:30.34 | Notify | 03BRL-CAD:n_reed * 63353 brlcad/branches/brep-debug/src/libbrep/intersect.cpp: replace hard-coded values with tol arguments |
| 01:58.32 | *** join/#brlcad KimK (~Kim__@ip68-102-30-143.ks.ok.cox.net) |
| 05:00.58 | *** join/#brlcad witness___ (uid10044@gateway/web/irccloud.com/x-ggfywybfntjqwgec) |
| 06:19.27 | *** join/#brlcad ``Erik_ (~erik@pool-74-103-94-19.bltmmd.fios.verizon.net) |
| 08:28.23 | *** join/#brlcad ries (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) |
| 09:18.31 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) |
| 09:48.26 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 10:37.57 | *** join/#brlcad ries (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) |
| 12:10.04 | ries | ping starseeker |
| 12:49.50 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 12:54.25 | *** join/#brlcad ries_nicked (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) |
| 13:21.05 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 14:02.18 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 14:14.50 | starseeker | ries: ~ask |
| 14:14.53 | starseeker | ~ask |
| 14:14.53 | infobot | Questions in the channel should be specific, informative, complete, concise, and on-topic. Don't ask if you can ask a question first. Don't ask if a person is there; just ask what you intended to ask them. Better questions more frequently yield better answers. We are all here voluntarily or against our will. |
| 14:15.33 | ries | starseeker: Remember the disussion we had around dime? |
| 14:15.52 | ries | I was wondering if any work was done on it⦠|
| 14:17.37 | *** join/#brlcad clock (~clock@212.203.58.127) |
| 14:29.06 | *** join/#brlcad gaganjyot (~gaganjyot@124.253.225.90) |
| 14:29.28 | gaganjyot | starseeker, can you please tell me which version of DXF DIME Supports ? |
| 14:32.38 | Notify | 03BRL-CAD:starseeker * 63354 brlcad/branches/qtged/src/qbrlcad/cadtreeview.cxx: Be aware of whether or not the state is selected, and use the highlight color if it is. Not sure if this color should come from the palette or the stylesheet, but go with the palette per Qt's examples for now. |
| 14:32.43 | starseeker | ries: I haven't worked with dime much lately |
| 14:32.49 | starseeker | too busy on other things :-( |
| 14:32.54 | starseeker | gaganjyot: um. One second |
| 14:33.12 | ries | starseeker: I was scanning the code, properly r14 ? |
| 14:34.36 | starseeker | ries: is that the commit number in the coin3d bit bucket repo? |
| 14:35.25 | ries | starseeker: Nope, just found it here : https://github.com/starseeker/psketcher/blob/master/src/DIME/src/Input.cpp#L623 |
| 14:36.01 | starseeker | gaganjyot: ah, ries found it |
| 14:36.16 | gaganjyot | hmm :) |
| 14:36.16 | starseeker | scowls at DIME's (lack of) docs on the issue |
| 14:36.49 | starseeker | ries: thanks for reminding me - I need to split DIME out into it's own github repo and finish up the build |
| 14:37.05 | starseeker | ries: are we agreed that there should be one libdime and not a lot of sub-libraries? |
| 14:38.10 | starseeker | I may actually have a little time this weekend for a change, so I'll try to get it split out and building |
| 14:38.10 | ries | starseeker: Agreed, gaganjyot and I where just looking at what versionâs it can load, and r14 fileâs are rather old already ⦠thus wondering about the code, if itâs worth to maintain etc... |
| 14:38.26 | starseeker | does anything else support anything newer? |
| 14:38.34 | gaganjyot | starseeker, yes |
| 14:38.55 | gaganjyot | libdxfrw supports upto 2007 I guess |
| 14:39.26 | gaganjyot | just a sec, I am confirming |
| 14:39.29 | starseeker | gaganjyot: unfortunately, that's GPL - for BRL-CAD it doesn't work :-( |
| 14:40.23 | starseeker | second question - how much difference is there between older and newer versions of DXF? I.e., given a working r14, how much work is it to add in newer bits? |
| 14:41.01 | gaganjyot | starseeker, quite large work I think |
| 14:41.25 | gaganjyot | I mean not that large but its large work |
| 14:42.36 | starseeker | it would be helpful if we could come up with a way to determine what's lacking in DIME in some sort of systematic way |
| 14:42.38 | gaganjyot | starseeker, I am reviewing the difference |
| 14:43.21 | starseeker | gaganjyot: in principle, a re-vitalized DIME might garner interest from a wide variety of players, if it solves the problem well - BSD license is quite flexible |
| 14:43.43 | gaganjyot | starseeker, :) Agreed :) |
| 14:44.34 | gaganjyot | starseeker, I don't think DIME has |
| 14:44.48 | gaganjyot | vports, UCS |
| 14:45.13 | gaganjyot | http://images.autodesk.com/adsk/files/autocad_2014_pdf_dxf_reference_enu.pdf |
| 14:45.42 | starseeker | vports, if I'm interpreting this correctly, are information about views? |
| 14:45.47 | gaganjyot | yes |
| 14:46.05 | gaganjyot | UCS is I think Universal Coordinate sysem |
| 14:46.57 | gaganjyot | DIME needs Hatch |
| 14:47.25 | gaganjyot | Dimension support |
| 14:47.57 | gaganjyot | Thats not large :D but still DIME needs work :) |
| 14:48.09 | starseeker | certainly :-) |
| 14:48.42 | gaganjyot | starseeker, if you could please check the page no 5 of the document link I send you above :) |
| 14:48.49 | gaganjyot | It shows the list of entities |
| 14:50.01 | gaganjyot | need improvement in entites section mainly |
| 14:50.13 | starseeker | so the thing to do then is to find or construct a series of small dxf files that exercise each element of interest in the spec |
| 14:50.38 | gaganjyot | BRL-CAD might be needing support for tables |
| 14:50.40 | starseeker | would give us inputs both for coverage testing and unit/regression tests |
| 14:51.07 | gaganjyot | yes |
| 14:52.12 | gaganjyot | starseeker, I was going through your github profile, what is QtCAD ? |
| 14:52.49 | starseeker | some experiments I was doing with the Qt toolkit to see how it might work for a BRL-CAD GUI |
| 14:53.02 | gaganjyot | I see |
| 14:53.21 | gaganjyot | and starseeker does it opens BRL-CAD db ? |
| 14:54.17 | starseeker | our most sophisticated interface currently is Archer, which is written in Tcl/Tk (actually, Itcl/Itk): http://brlcad.org/~starseeker/archer_diylilcnc_NURBS_shaded.png |
| 14:58.08 | gaganjyot | I see |
| 15:10.58 | starseeker | qtcad doesn't do much with .g files |
| 15:11.03 | starseeker | oh, nevermind - he left |
| 15:12.59 | starseeker | ries: I'll see if I can get a DIME repo up on github and get the whole build going - that'll make testing easier |
| 15:13.10 | starseeker | tonight or tomorrow probably |
| 15:38.16 | ries | starseeker: thanks, no rush though! |
| 16:36.14 | *** join/#brlcad gaganjyot (~gaganjyot@124.253.225.90) |
| 18:10.57 | brlcad | starseeker: fyi, openscad says they're also interested in a dxf lib, so potential triple whammy |
| 18:12.45 | kintel | Weâve got the DXF project outlined here: https://github.com/openscad/openscad/wiki/Project:-Improve-DXF-import-and-export |
| 18:13.00 | kintel | Not too much info yet though - looking for dev resources : / |
| 18:17.34 | Notify | 03BRL-CAD:starseeker * 63355 (brlcad/branches/qtged/src/qbrlcad/cadapp.cxx brlcad/branches/qtged/src/qbrlcad/cadapp.h and 6 others): Get a basic related-object highlighting working. Need to think about ways to tune this further, since on really large databases it noticably slows the tree interactivity... |
| 18:19.24 | starseeker | gaganjyot: to answer your previous question - technically qtcad can open .g files, but it can't do much of anything with them |
| 18:19.45 | gaganjyot | I see |
| 18:25.06 | brlcad | kintel: yeah, I looked more into our dxf implementation and it's quite intertwined with our needs, primarily just pulling out the entities related to 2d sketches and 3d solids ... not a great basis for a general-usage library |
| 18:25.28 | brlcad | the parsing is fine as it's just a simple state machine, but an object system would probably be better |
| 18:26.02 | brlcad | that'll be a fun format to wire into our new conversion lib |
| 18:26.30 | brlcad | starseeker: you get a change to fix those null dereferences? |
| 18:26.36 | brlcad | s/change/chance/? |
| 18:26.58 | teepee | yes, I guess something that returns a list or tree of entity objects and provide a visitor to convert to the native entites |
| 18:27.16 | teepee | that's where I want to go with the svg reader :) |
| 18:29.52 | Notify | 03BRL-CAD:bob1961 * 63356 brlcad/trunk/src/libtclcad/tclcad_obj.c: Modify to_rt_gettrees_application() to use to_resourcep that is global to tclcad_obj.c instead of resp that was on the stack and subject to being overwritten. |
| 18:32.14 | brlcad | teepee: yeah, that's my thinking as well |
| 18:32.34 | brlcad | the problem is different formats have COMPLETELY different notions of what constitutes an object |
| 18:32.50 | brlcad | and categories of objects are completely disjoint |
| 18:33.37 | teepee | true, and with things like IGES that supports CSG it gets even more complicated as it's not just entities but also logic |
| 18:34.25 | brlcad | so you'll have something like step where literally everything is an object (every coordinate, for example, its own object), then something like dxf that's a random hybrid |
| 18:34.53 | teepee | and SVG which can even have javascript code :) |
| 18:35.04 | brlcad | a concept of a "view" is a good one, very very different in most systems |
| 18:35.35 | teepee | or the new glTF which has animation |
| 18:36.10 | brlcad | heh, yeah .. that might be a second-year activity to think about :) |
| 18:36.25 | brlcad | let some poor gsoc think about that |
| 18:39.21 | brlcad | we're on the hook this year to refactor our stl, obj, and vrml support into a library iirc, which shouldn't be too complex as they're relatively simple polygonal formats with limited entity types |
| 18:39.48 | brlcad | even for those, though, we'll have to sort out how to do object mappings that are disjoint |
| 18:40.11 | brlcad | obj has a good number of entities... |
| 18:40.51 | teepee | I wonder what happened to our obj reader, I think that's dormant in some branch... |
| 18:42.20 | teepee | ahh, it reads only a known collection of entites and ignores the rest |
| 18:52.17 | gaganjyot | brlcad, I am trying to understand the sketch working of brlcad |
| 18:52.30 | gaganjyot | and I am a bit confused |
| 18:52.57 | gaganjyot | with respect to representation of sketches in brlcad |
| 18:53.22 | gaganjyot | how is sketch represented in a brlcad db ? |
| 18:53.25 | brlcad | teepee: ah, for obj, we do already have a stand-alone lib (and then our own converter that extracts the entities we care about) |
| 18:53.37 | Notify | 03BRL-CAD:carlmoore * 63357 brlcad/trunk/doc/docbook/system/man1/en/patch-g.xml: note the need for quotation marks for -c option |
| 18:53.58 | brlcad | gaganjyot: not sure I understand the question ... |
| 18:54.06 | brlcad | it's stored as an object in our database |
| 18:54.20 | gaganjyot | A complete object ? |
| 18:54.27 | brlcad | yes |
| 18:54.31 | gaganjyot | I see |
| 18:54.39 | gaganjyot | and that object points to entites ? |
| 18:54.40 | brlcad | each sketch object is basically an unbound container of 2D entities |
| 18:55.23 | brlcad | think of each sketch object as a sheet of paper |
| 18:55.27 | gaganjyot | I am confused if replacing with the kernel is a big change to sketch internals of brlcad |
| 18:55.30 | brlcad | you can draw whatever you want onto that paper |
| 18:55.44 | gaganjyot | yes |
| 18:56.15 | gaganjyot | Like I mean if I have to make changes how the sketch is exported or not |
| 18:56.16 | gaganjyot | :S |
| 18:56.20 | brlcad | that's why I suggested src/proc-db/sketch.c |
| 18:56.41 | brlcad | don't worry about changing the internals .. try to create that same sketch, those same entities, with the kernel |
| 18:56.58 | brlcad | if you can, then we can probably convert everything now |
| 18:57.02 | gaganjyot | the point is how will that stuff be stored in |
| 18:57.04 | gaganjyot | the G file |
| 18:57.13 | gaganjyot | I am confused with that portion |
| 18:57.37 | gaganjyot | I can create the same in kernel but all will be stored in memory |
| 18:57.44 | brlcad | that's just serialization, we can decide later what makes the most sense |
| 18:57.46 | gaganjyot | How to move that data to brlcad db is confusing |
| 18:57.55 | brlcad | we have import/export functions |
| 18:58.00 | brlcad | so they'd do whatever translation needed |
| 18:58.05 | gaganjyot | I was reading the same functions |
| 18:58.18 | gaganjyot | mk_sketch calls |
| 18:58.20 | gaganjyot | wdb_export |
| 18:58.51 | brlcad | which ultimately will end up calling the rt_sketch_export5() function in src/librt/primitives/sketch/sketch.c |
| 18:59.08 | gaganjyot | Ah I see |
| 18:59.22 | brlcad | a sketch knows how to read and write itself to disk |
| 18:59.31 | gaganjyot | ;_; |
| 18:59.47 | gaganjyot | I was finding this function ;_; |
| 18:59.51 | brlcad | so those two functions would get rewritten to read from the kernel data structure and write out the right bytes during export |
| 18:59.54 | brlcad | and reverse on import |
| 19:00.09 | gaganjyot | Yes :) |
| 19:00.31 | brlcad | yeah, following the functions can be tricky because they're encapsulated behind an object function table mechanism |
| 19:00.31 | gaganjyot | that was what I was worried becasue I was not able to find these :S |
| 19:00.40 | brlcad | object-oriented C ;) |
| 19:00.45 | gaganjyot | :D yes |
| 19:01.05 | gaganjyot | thanks for help :) |
| 19:01.20 | brlcad | basically calls a function registered by that class of object, but yeah .. you can find all the guts in src/librt/primitives/sketch |
| 19:01.41 | brlcad | and the two main users of sketch in src/librt/primitives/extrude and src/librt/primitives/revolve |
| 19:02.04 | brlcad | for linear extruded 3D entities and 3D surfaces of revolution |
| 19:02.34 | brlcad | (we still need sweeps) |
| 19:04.31 | gaganjyot | hmm |
| 19:05.29 | brlcad | example: http://brlcad.org/wiki/Extrude |
| 19:08.17 | gaganjyot | yes I have used extrude |
| 19:08.18 | gaganjyot | for my gear |
| 19:08.30 | gaganjyot | mechanical gear :) |
| 19:30.40 | gaganjyot | brlcad, one thing that I doubt is that we don't have attributes such as position of sketch |
| 19:30.45 | gaganjyot | and the parameter space |
| 19:31.41 | gaganjyot | but since you will encapsulate the LC document in side a rt_sketch kind struct |
| 19:31.47 | gaganjyot | you can have those attributes there |
| 19:31.52 | brlcad | right |
| 19:59.33 | gaganjyot | brlcad |
| 19:59.37 | gaganjyot | arc radius is -1 in example |
| 20:01.44 | brlcad | yes, the radius is inferrable because it's a full circle and you already have to provide the center and a point on the circle |
| 20:03.37 | gaganjyot | pardon brlcad I did not understood |
| 20:04.09 | gaganjyot | <PROTECTED> |
| 20:04.10 | gaganjyot | <PROTECTED> |
| 20:04.10 | gaganjyot | <PROTECTED> |
| 20:04.10 | gaganjyot | <PROTECTED> |
| 20:04.10 | gaganjyot | <PROTECTED> |
| 20:05.49 | brlcad | -1 radius means it's a circle |
| 20:05.52 | brlcad | the fields are overloaded |
| 20:06.03 | brlcad | instead of having to define an entirely different structure |
| 20:06.24 | gaganjyot | I see :) |
| 20:06.30 | brlcad | I think csg.start is the center and csg.end is a point on the circle when radius is -1 |
| 20:06.59 | brlcad | have to create it and inspect the output in mged (run "l objectname") |
| 20:07.08 | gaganjyot | I see |
| 20:07.15 | brlcad | or read the code ;) |
| 20:07.24 | gaganjyot | :D yes :) |
| 20:08.06 | brlcad | ah, had it reversed |
| 20:08.29 | brlcad | (looking at rt_sketch_describe in librt/primitives/sketch.c) |
| 20:09.00 | brlcad | center is csg->end and point on circle is csg->start |
| 20:10.54 | gaganjyot | one more question, |
| 20:11.06 | gaganjyot | circle has same radius through out |
| 20:11.26 | gaganjyot | ahh |
| 20:11.30 | gaganjyot | just a sec ~_~ |
| 20:11.34 | gaganjyot | sorry |
| 20:11.59 | gaganjyot | Cleared doubts thankyou :) |
| 20:19.00 | *** join/#brlcad LordOfBikes (~armin@dslb-088-065-191-230.088.065.pools.vodafone-ip.de) |
| 20:20.38 | gaganjyot | brlcad, I have built the example |
| 20:20.44 | gaganjyot | using the kernel |
| 20:20.56 | gaganjyot | Just need to compile and execute |
| 20:22.51 | gaganjyot | How should I share the code ? |
| 20:22.52 | gaganjyot | gist ? |
| 20:23.57 | brlcad | sure that works |
| 20:28.38 | Notify | 03BRL-CAD:carlmoore * 63358 brlcad/trunk/doc/docbook/system/man1/en/patch-g.xml: revise description of -t and -o defaults |
| 21:42.23 | Notify | 03BRL-CAD Wiki:ShayincbifiazxDiallo * 0 /wiki/User:ShayincbifiazxDiallo: |
| 21:43.27 | clock | brlcad, is the right way to separate the BRL-CAD C source rm src/others? |
| 22:21.35 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 23:00.48 | Notify | 03BRL-CAD:starseeker * 63359 brlcad/branches/qtged/src/qbrlcad/cadtreemodel.cxx: Since the assembly and selection-related searches are not dynamic, boil them down into what is hopefully the fastest possible tests. These are performance critical on large databases and must be as fast as possible. Still need to optimize the expand case, where it is only necessary to update the new children. |
| 23:03.42 | starseeker | brlcad: no chance to fix yet (presumably I have to check for nulls in the code to clear the warnings?) |
| 23:31.54 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 23:35.38 | *** join/#brlcad ries (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) |
| 23:51.49 | Notify | 03BRL-CAD:starseeker * 63360 (brlcad/branches/qtged/src/qbrlcad/cadapp.cxx brlcad/branches/qtged/src/qbrlcad/cadapp.h and 3 others): Rework the signal/slot setup for updating a bit. |
