| 00:08.14 | ``Erik | mmm, lasagna code *drool* </homer> |
| 00:29.09 | *** join/#brlcad backom (75c76a87@gateway/web/freenode/ip.117.199.106.135) | |
| 00:30.19 | backom | hello, i am tring to convert .g into vrml. File is converted incompletely into vrml format. |
| 00:31.36 | backom | syntax used is as : g-vrml -o mybox.wrl mybox.g sphere1.s box1.s cyl1.s cyl2.s cyl3.s |
| 00:40.09 | backom | hello brlcad |
| 00:41.01 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 01:00.22 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 01:02.34 | *** join/#brlcad backom (75c76a87@gateway/web/freenode/ip.117.199.106.135) | |
| 01:52.10 | ``Erik | http://www.youtube.com/watch?v=TRPKOrTRE0w&list=PLzxw__7_u01DHnu7ZSbkRQski0Emu-NNX&feature=share&index=2 |
| 02:32.50 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 03:15.53 | brlcad | hcurtis: your declaration still creates a static array (of size "numberOfRegions") instead of a dynamic array (using a pointer and bu_malloc or bu_calloc |
| 03:17.53 | brlcad | your "different approach" is closer to being right, but still is missing the initial allocation and an initial size |
| 03:18.42 | brlcad | also can't base it on numberOfRegions (we don't know that), it just needs to grow as needed. |
| 04:03.56 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 04:53.34 | hcurtis | brlcad: Thank you for the feedback. |
| 05:36.02 | *** join/#brlcad ishwerdas (~ishwerdas@59.91.112.18) | |
| 05:38.05 | *** join/#brlcad piyushparkash (~piyushpar@117.205.77.209) | |
| 05:52.37 | Notify | 03BRL-CAD Wiki:Hcurtis0010 * 7303 /wiki/User:Hcurtis0010/GSoC2014/logs: |
| 06:24.27 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 06:24.27 | *** join/#brlcad albertcoder (~albertcod@101.215.8.157) | |
| 06:24.27 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) | |
| 06:24.27 | *** join/#brlcad hcurtis (b82d2cf1@gateway/web/freenode/ip.184.45.44.241) | |
| 06:24.27 | *** join/#brlcad ejno (~ejno@unaffiliated/kazaik) | |
| 06:24.27 | *** join/#brlcad Guest4446 (~Ch3ck@66-118-151-70.static.sagonet.net) | |
| 06:24.27 | *** join/#brlcad cwstirk (~charlie@c-24-9-78-79.hsd1.co.comcast.net) | |
| 06:24.27 | *** join/#brlcad oana_ (~oana@188.209.97.130) | |
| 06:24.27 | *** join/#brlcad caen23_ (~caen23@92.83.166.162) | |
| 06:24.27 | *** join/#brlcad raj12lnm (uid35020@gateway/web/irccloud.com/x-gtyofukgykgusznl) | |
| 06:24.27 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 06:24.27 | *** join/#brlcad mpictor (~mark@c-68-58-38-45.hsd1.in.comcast.net) | |
| 06:24.27 | *** join/#brlcad starseeker (~starseeke@66-118-151-70.static.sagonet.net) | |
| 06:24.27 | *** join/#brlcad KimK (~Kim__@ip68-102-30-143.ks.ok.cox.net) | |
| 06:24.27 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 06:24.27 | *** join/#brlcad zxq9 (~ceverett@FL9-125-199-207-150.okn.mesh.ad.jp) | |
| 06:24.27 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 06:24.27 | *** join/#brlcad brlcad (~sean@66-118-151-70.static.sagonet.net) | |
| 06:24.27 | *** join/#brlcad ankesh11 (uid8015@gateway/web/irccloud.com/x-npcokdntikhhjpbb) | |
| 06:24.27 | *** join/#brlcad n_reed (~molto_cre@66-118-151-70.static.sagonet.net) | |
| 06:24.27 | *** join/#brlcad Guest3313 (~Ch3ck@66-118-151-70.static.sagonet.net) | |
| 06:24.27 | *** join/#brlcad fenn (~fenn@131.252.130.248) | |
| 06:24.27 | *** join/#brlcad ``Erik (~erik@pool-74-103-94-19.bltmmd.fios.verizon.net) | |
| 06:24.28 | *** join/#brlcad maths22 (~maths22@66-118-151-70.static.sagonet.net) | |
| 06:24.28 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 06:24.28 | *** mode/#brlcad [+o ChanServ] by holmes.freenode.net | |
| 12:56.53 | *** join/#brlcad infobot (~infobot@rikers.org) | |
| 12:56.53 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || GCI winners: Jacob Burroughs and Peter Amidon! || GSoC 2014 selections are announced! Thank you to all we got to work with. Remember that SOCIS is coming up right around the corner and you don't need a summer of code to get involved with open source. | |
| 12:58.06 | d_rossberg | what's m_lineSegment? |
| 12:58.28 | d_rossberg | ok, i see |
| 12:59.07 | d_rossberg | you need a handle to rt_sketch_internal too |
| 12:59.40 | andrei_ | I have that in the Sketch class/object |
| 12:59.48 | d_rossberg | maybe as a protected variable in Segment |
| 13:00.02 | d_rossberg | (you need it in Line) |
| 13:00.14 | andrei_ | I figured, but I was trying to see why |
| 13:01.36 | andrei_ | I looked this up ELEMENTS_PER_VECT2D, this is a simple two value, the only possbile reason I see we could need an sketch internal pointer |
| 13:01.38 | andrei_ | is vertex count |
| 13:01.44 | d_rossberg | and then the start point is verts[m_lineSegment->start] and the end point is verts[m_lineSegment->end] |
| 13:02.59 | d_rossberg | verts is a member of rt_sketch_internal |
| 13:03.37 | andrei_ | ah, so we store the vertex array inside Sketch |
| 13:03.55 | andrei_ | I'll modify it now |
| 13:04.43 | *** join/#brlcad chick_ (~chick_@41.205.22.41) | |
| 13:04.44 | andrei_ | aaaaaaaaaah, now I see why you said this. We couldn't "tie" the segments together without using this, each segment would've started from origin |
| 13:11.09 | andrei_ | I added this on Line( will add on others as well) : protected: |
| 13:11.09 | andrei_ | <PROTECTED> |
| 13:11.12 | andrei_ | meh; |
| 13:11.12 | andrei_ | <PROTECTED> |
| 13:11.13 | andrei_ | <PROTECTED> |
| 13:11.38 | andrei_ | but don't we need a method to set this pointer to the sketch? or am I wrong? |
| 13:13.44 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) | |
| 13:13.58 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) | |
| 13:21.32 | *** join/#brlcad piyushparkash (~piyushpar@117.205.77.209) | |
| 13:30.53 | *** join/#brlcad chick_ (~chick_@41.205.22.41) | |
| 13:37.34 | d_rossberg | yes, with the constructor which now gets the line_seg only (now it needs at least the verts too) |
| 13:38.21 | d_rossberg | so, you'll add the rt_sketch_internal which has the verts as a member variable |
| 13:41.47 | andrei_ | so this : Line(void) throw() : Segment(), m_lineSegment(0) {} |
| 13:41.51 | andrei_ | becomes |
| 13:42.02 | andrei_ | <PROTECTED> |
| 13:42.04 | andrei_ | and so on |
| 13:42.15 | andrei_ | m_sketch is how I named the internal pointer |
| 13:44.09 | *** join/#brlcad albertcoder (~albertcod@101.216.93.183) | |
| 13:47.49 | Zhao_Anqing | d_rossberg: I tested hollowed model, cut off a small sphere from a bigger sphere. |
| 13:47.54 | d_rossberg | i would make the m_sketch a member of Segment |
| 13:48.18 | Zhao_Anqing | the result of facetize still is one model, nmgregion, and shell. |
| 13:48.44 | andrei_ | ah, you have a point. Thanks! This solves up most of my questions, thanks a lot ! |
| 13:49.00 | d_rossberg | Zhao_Anqing: hollows shouldn't be a problem, but two spheres in some distance? |
| 13:49.48 | Zhao_Anqing | actually, the result of facetize seems just a set of triangles in one shell. |
| 13:49.55 | Zhao_Anqing | Let me try it now. |
| 13:51.36 | Zhao_Anqing | I use nmg_pr_m_struct_counts to print counts of structure on the console. is there any commands to do such thing better? |
| 13:53.19 | d_rossberg | ufortunately i don't know any better method |
| 13:54.18 | d_rossberg | i tried g2asc, with no success (the implementation is buggy) |
| 13:55.25 | Zhao_Anqing | I add a function call when use facetize, then I can see the number of every level of nmg structure. |
| 13:55.46 | Zhao_Anqing | now, I get the result of two seperated sphere. |
| 13:55.57 | Zhao_Anqing | still one model, one region , and one shell |
| 13:57.26 | Zhao_Anqing | It looks interesting, so can I make sure the result of facetize is always *ONE* shell? |
| 13:58.12 | Zhao_Anqing | If so, things will be simpler. |
| 13:59.33 | d_rossberg | at least after the reorganisation of the nmg primitive you can be sure, there won't be any model or nmgregion any more |
| 14:01.03 | d_rossberg | but, all signs are of the single shell hypothesis |
| 14:02.40 | d_rossberg | so, it should really be simple |
| 14:04.26 | Zhao_Anqing | OK. I will try to deal with import/export again. |
| 14:04.34 | Zhao_Anqing | Thanks a lot. :) |
| 14:05.39 | *** join/#brlcad albertcoder (~albertcod@117.238.196.28) | |
| 14:12.59 | *** part/#brlcad ishwerdas (~ishwerdas@117.214.202.189) | |
| 14:13.15 | brlcad | Zhao_Anqing: hollowing out a sphere results in one shell? is that shell properly using that reverse feature you meantioned earlier? |
| 14:13.47 | brlcad | andrei_: I saw your e-mail -- all your questions are answered now? |
| 14:13.58 | andrei_ | yes! |
| 14:14.05 | andrei_ | finally no more confusion |
| 14:14.39 | andrei_ | thanks a lot :D |
| 14:16.15 | brlcad | I have some other comments, do you have a couple minutes for a pm talk? |
| 14:16.22 | andrei_ | yes |
| 14:20.16 | Zhao_Anqing | brlcad: yes, the cutted part displays in dotted line. |
| 14:20.39 | Zhao_Anqing | I use r comb.r u sph1.s - sph2.s |
| 14:20.51 | Zhao_Anqing | then facetize -n comb.r |
| 14:23.01 | Zhao_Anqing | I use nmg_pr_m_struct_counts to print the count, it shows there is only one shell, always. |
| 14:32.52 | brlcad | Zhao_Anqing: ouch, that sounds like it'll really complicate things? |
| 14:33.26 | brlcad | I mean, it's right ... but I'm not sure I realized nmg also had that ability to keep track of interior/exterior faces |
| 14:35.17 | d_rossberg | that's right, but they are all members of the same shell |
| 14:43.36 | brlcad | was that already being tracked by the shell or in the model? |
| 14:44.10 | *** join/#brlcad alisha (~alisha@115.245.164.76) | |
| 14:45.55 | brlcad | if they can be the same shell, it's not clear to me then what it really means to be a shell, why you couldn't have multiple surfaces stored in one "shell" structure (we'd just rename shell to mesh or poly or polymesh or whatever) |
| 14:46.13 | brlcad | kind of like how bots store multiple surfaces in one structure, doesn't know or care |
| 14:46.27 | brlcad | just needs some acceleration structures in the shot routine |
| 14:47.35 | brlcad | if we allowed that, you wouldn't need to do any comb trickery (which I have questions about too) |
| 14:48.04 | d_rossberg | it looks like it's possible to have multiple surfaces (or volumes) in one shell, this was my question to zhao |
| 14:48.47 | d_rossberg | and indeed, it looks like we don't need any combination tricks |
| 14:50.34 | d_rossberg | e.g. the facetize command: it'll run into trouble if there is more than one shell, in this case only the first shell can be converted into a bot |
| 14:52.57 | d_rossberg | nmgs with more than one shell will cause problems at multiple places => allow only one shell, if a group is neede use a combination (but i havn't found such a place yet) |
| 14:56.18 | brlcad | confusing terminology |
| 14:59.34 | brlcad | are you saying "if there are nmgs with more than one surface (spanning multiple shells) causing problems in more than one place, we should limit nmgs to only one surface (one shell) and employ comb tricks" or are you saying "if there are nmgs with more than one surface (spanning multiple shells) causing problems, limit them to one shell (with multiple surfaces) until we find a case where that doesn't work" ? :) |
| 15:00.40 | brlcad | if a shell can indeed have multiple surfaces, I think we should just make that work (if it doesn't) and call it done |
| 15:01.38 | *** join/#brlcad chick_ (~chick_@41.205.22.41) | |
| 15:01.59 | brlcad | attempts a facetize of sph - torus |
| 15:04.52 | brlcad | andrei_: this may be of remote utility when thinking about class design: http://doc.spatial.com/qref/ACIS/html/group__ACISGEOMETRICENTITIES.html (and the parent http://doc.spatial.com/qref/ACIS/html/group__ACISGEOMETRY.html which has more component types) ... just keep in mind that you're working with a MUCH more simplified API so yours is more about constructors, inheritance, and how the data is getting stored in private structures |
| 15:06.42 | d_rossberg | i'm saying: nmgs with more than one shell (this is a structure inside the nmg, what it is good for doesn't matter here) are causing problems in more than one place, that's a fact |
| 15:07.41 | d_rossberg | the structures above the shell in the nmg are for grouping purpose only |
| 15:07.52 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 15:09.03 | d_rossberg | so, let's reduce the nmg to one shell and do the grouping with the usual BRL-CAD comb if needed |
| 15:10.39 | brlcad | okay, but I guess my confusion is that he's already started doing that, quite in the middle of that even |
| 15:10.43 | d_rossberg | the usual routines (import, export, ray-trace, boolean ops, etc.) are able to handle the comb and the nmg-shell |
| 15:10.52 | brlcad | thought elimination of nmgregion and model were a given :) |
| 15:11.55 | brlcad | do we know if ray tracing already handles a shell with |
| 15:12.00 | brlcad | multiple surfaces? |
| 15:12.14 | d_rossberg | there was a confusion on how the "combination when needed" should be handled |
| 15:12.15 | brlcad | (besides an interior surface) |
| 15:12.50 | d_rossberg | the ray-trace should be able to handle these shells because this is what we have now |
| 15:13.08 | brlcad | I'm not sure it'd ever be needed except for backwards-compatibility if the code can't currently handle multiple-surface shells and that gets fixed |
| 15:13.31 | d_rossberg | the fact is that we are only using single shell nmgs |
| 15:13.40 | brlcad | sure |
| 15:13.49 | brlcad | at least exposed in userland |
| 15:15.00 | d_rossberg | model and nmgregion are good for confusion only |
| 15:15.00 | brlcad | would be quick to check E, ev, and all the polygonal exporters where multi-shell nmgs might have existed, but it still doesn't matter if a single shell can basically hold data for N shells |
| 15:15.14 | brlcad | well, can't forget API complexity |
| 15:15.23 | brlcad | the API clearly wasn't complex enough as it was |
| 15:16.36 | brlcad | I see no problems ditching nmgregion and model entirely even if we do have code that relys on or supports multishell within model |
| 15:16.45 | brlcad | like I said, I thought that was a given! :) |
| 15:18.17 | brlcad | and I'd even go further -- that we should make mutli-surface shells work if they do not and rename that shell struct to somthing better |
| 15:18.50 | brlcad | even if those "new" nmg objects cannot be read by old versions of BRL-CAD |
| 15:19.12 | brlcad | we need to move forward with what makes sense to the API |
| 15:21.16 | d_rossberg | it will probably renamed to rt_nmg_internal |
| 15:21.44 | brlcad | :) |
| 15:22.50 | d_rossberg | at the moment it looks like we don't need to change the disk format, multiple shells can be joined with nmg_js() (an "old" function) |
| 15:24.39 | d_rossberg | just looked at bigE.c: there are many r = BU_LIST_FIRST(nmgregion, &eptr->l.m->r_hd) without a NEXT (same for shell) |
| 15:26.09 | brlcad | wow, facetize -n of a sph - torus worked perfectly |
| 15:26.34 | brlcad | do you know how to discern whether this made multiple shells from within mged/archer? |
| 15:28.21 | brlcad | Zhao_Anqing: sorry, I keep referring to you with the wrong pronoun! my apologies |
| 15:29.02 | d_rossberg | this can only be done by changing the code: zhao put an nmg_pr_m_struct_counts() in the facetize code |
| 15:29.03 | brlcad | here we go, looks like the get command will dump an nmg |
| 15:31.46 | brlcad | huh, of course rt_nmg_get() has the R{} and S{} commented out, heh .. so it combines them all into one shell during g2asc too |
| 15:32.06 | brlcad | hm, so that should be a good way to test multiple-surface shells.. |
| 15:33.25 | d_rossberg | yes, rt_nmg_get() is one of the routines which can't handle multiple nmgregions and shells correctly |
| 15:34.08 | d_rossberg | but with only a few changes it works perfectly for the single shell nmg |
| 15:57.22 | brlcad | looks like it's working perfectly here with multiple surfaces inside a single shell |
| 15:57.45 | brlcad | (without any changes) |
| 15:58.12 | brlcad | Zhao_Anqing: so perhaps no comb trickery is needed after all... |
| 15:58.25 | *** join/#brlcad piyushparkash (~piyushpar@117.205.77.209) | |
| 16:12.03 | Zhao_Anqing | brlcad: yes, if all facetize result is just single shell. the task to deal with this part becomes simpler. I will not change the file format to storage new nmg structure. |
| 16:13.04 | Zhao_Anqing | some combination-like structure is also needless. |
| 16:13.12 | brlcad | Zhao_Anqing: so it looks like facetize and the bigE command and ascii export only deal with one shell -- have you looked at any of the others? |
| 16:13.13 | *** join/#brlcad Ch3ck (~Ch3ck@66-118-151-70.static.sagonet.net) | |
| 16:13.18 | brlcad | the converters |
| 16:13.28 | brlcad | yeah, a comb structure sounds unnecessary |
| 16:14.39 | brlcad | i.e., what code will actually even create a multiple-shell nmgregion? |
| 16:18.43 | Zhao_Anqing | for example, the facetize.c |
| 16:20.02 | Zhao_Anqing | db_walk_tree traversal target primitive/comb, then put the result of facetize in the variable 'facetize_tree' |
| 16:25.46 | brlcad | Zhao_Anqing: so it'll put a hierarchy into multiple regions ... but where do multiple shells come from |
| 16:26.27 | brlcad | I'd expect a comb with multiple regions turn into a model with multiple nmgregion with one shell each |
| 16:26.51 | brlcad | which I guess is the same problem .... |
| 16:26.55 | brlcad | tests that theory |
| 16:33.31 | Zhao_Anqing | the facetize result is just a set of triangle. These face/edge information can be put in one or more shells, but the meaning is the same. |
| 16:34.04 | Zhao_Anqing | the db_walk_tree transform all primitives into nmg structure/the triangles. |
| 16:34.22 | brlcad | so, "facetize -n" is what I was referring to |
| 16:35.07 | brlcad | result should be polygons, not necessarily triangles |
| 16:37.12 | brlcad | it's wasn't clear before today (at least to me) that ray tracing supported the interpretation of a shell containing more than one surface |
| 16:38.33 | brlcad | particularly with subtracted interiors (with potentially even other interior surfaces) can be interepreted in a variety of ways, so it's not a given that the meaning is the same |
| 16:40.19 | brlcad | testing, though, I was able to subtract a torus and get a valid result (with is incredibly surprising to me) as that's an exterior surface, and interior one at the surface boundary of the torus, and ... oh hum, I guess I didn't really test an interior interior surface |
| 16:45.09 | Zhao_Anqing | eh, I know the common situation of nmg is: when I get a hollowed model, it should be two shell, one inner shell and one outter shell. But current nmg in BRL-CAD is, just put all polygons in one shell to represent such structure. |
| 16:45.46 | Zhao_Anqing | when you use command 'facetize -n', it will call ged_facetize in facetize.c |
| 16:46.43 | Zhao_Anqing | at first, it use db_walk_tree to get facetize result of all primitives. |
| 16:47.43 | Zhao_Anqing | at this step, it will get a tree with multiple models. each represent a facetize result of a primitive. |
| 16:48.10 | Zhao_Anqing | then nmg_boolean is called to merge them into one shell. |
| 16:48.31 | Zhao_Anqing | I mean put all faces/edges into one shell. |
| 16:48.39 | brlcad | calls nmg_boolean per region right? |
| 16:49.09 | brlcad | note that region != nmgregion |
| 16:49.27 | brlcad | region is a geometric construct that affects db_walk_tree() callbacks |
| 16:50.20 | ankesh11 | The current benchmark script doesn't seem to platform independent, as in there isn't a benchmark executable in the installation. There is a .sh script, which is not cross-platform. How do users from platforms other than Linux submit their logs? |
| 16:50.26 | Zhao_Anqing | eh..region...give me some time to check the codes. |
| 16:50.30 | brlcad | regions are basically combinations with a flag set, impling they now occupy space (they have mass/volume) |
| 16:51.06 | brlcad | ankesh11: same way as users on Linux |
| 16:51.23 | brlcad | they e-mail them |
| 16:51.59 | ankesh11 | Yes, but the lack of an executable means they have to run the script via something like Cygwin. |
| 16:52.55 | ankesh11 | in Windows that is |
| 16:53.18 | brlcad | Zhao_Anqing: I'm familiar with the nmg facetization processing pipeline, but there are just some details that need to be looked up like whether ANYTHING actually does create 1) an nmg 'model' with multiple nmgregion with one or more shells per nmgregion and 2) an nmg model with a single nmgregion with more than one shell |
| 16:53.38 | brlcad | if both 1 and 2 are NO ... that really simplifies things |
| 16:54.02 | brlcad | ankesh11: yep |
| 16:54.24 | brlcad | (and there's efforts to fix that deficiency, obviously non-optimal) |
| 16:54.39 | brlcad | but they still submit the same, the log is e-mailed |
| 16:55.25 | brlcad | automatic submission would be good, but we're not doing that yet |
| 16:55.54 | brlcad | (because it's a bit of work to do portably) |
| 16:56.11 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 16:58.12 | ankesh11 | Yes, which brings me to the question of supporting FTP uploads. One possible would be to integrate it within the current script via another command line argument, another would be to have a new Python script which would be straight-forward to implement. |
| 16:58.32 | Zhao_Anqing | brlcad: OK. I understand what you mean, I almost make make sure so, but I know 'almost' is not enough. I need check them carefully again. It seems nmg_booltree_evaluate deal with all tree node including the region. |
| 17:00.01 | Zhao_Anqing | and to make sure, I will check the facetize routines for all primitive, see whether they just create single shell or not. |
| 17:00.33 | brlcad | Zhao_Anqing: the only places that come to mind are facetize -n (which looks to be NO for both), g2asc (also NO), E and ev commands, and the converters |
| 17:00.33 | ankesh11 | Should supporting FTP uploads be a focus now? I feel the Web Interface and Emails are two good methods to upload log files. FTP would be good, but not a necessary feature. |
| 17:01.06 | brlcad | Zhao_Anqing: good idea ... whether a particular primitive might create multiple regions or shells |
| 17:01.38 | brlcad | ankesh11: what's your web interface look like? |
| 17:02.27 | Zhao_Anqing | OK. give me some time, and I will check them. |
| 17:03.42 | ankesh11 | brlcad: http://imgur.com/a/RhPLe |
| 17:05.40 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) | |
| 17:07.03 | brlcad | ankesh11: so a manual user upload interface |
| 17:08.20 | brlcad | ankesh11: I think the most useful next step is a web API upload, maybe something REST / ajax / jsonified |
| 17:08.38 | brlcad | then we can work on getting the benchmark suite automatically submitting to that API |
| 17:09.58 | brlcad | you'll need/want some way to queue any uploads so benchmarks numbers can be sanity-checked |
| 17:10.02 | ankesh11 | Right, what I can do is have a python script that uploads to the server via a POST API. This can be then coupled to the benchmark script file. |
| 17:10.23 | brlcad | can't couple python, that's a major dependency |
| 17:10.44 | brlcad | as much as I like python :) |
| 17:11.13 | brlcad | that's all infrastructure that the benchmark suite will need to have implemented |
| 17:11.56 | brlcad | you could implement the python script to show how it'll communicate, then we'll turn that into C API internal to the suite |
| 17:12.33 | ankesh11 | Okay, will look into it. |
| 17:14.06 | brlcad | Zhao_Anqing: so my test of facetize -n with a *proper* layering of interior surfaces was a success .. i'm really a bit surprised that works :) |
| 17:14.30 | brlcad | that it's actually keeping faceuse->orientation set correctly all the way down |
| 17:14.39 | ankesh11 | I had a couple of other questions as well which I drafted in an e-mail to the list. |
| 17:18.49 | *** join/#brlcad piyushparkash (~piyushpar@117.205.77.209) | |
| 17:21.02 | brlcad | ankesh11: I'm aware of the two issues you identified and will get you set up as soon as I'm able, you'll just have to make due in the meantime |
| 17:23.06 | ankesh11 | brlcad: Thanks. :) |
| 17:23.09 | brlcad | there are certainly aspects of openbenchmarking.org that would be good to have, but we need to be far more easier to use and the interface should be more modern/beautiful/responsive |
| 17:23.09 | *** join/#brlcad albertcoder (~albertcod@117.224.171.194) | |
| 17:24.59 | brlcad | ankesh11: another example is http://www.speedtest.net/ |
| 17:25.49 | brlcad | obviously they focus on networking performance and the 3d glitz is superfluous, but the simplicity of the results and comparisons are easy to navigate and interpret |
| 17:26.19 | brlcad | especially http://www.speedtest.net/results.php |
| 17:26.24 | brlcad | (after you run the test) |
| 17:26.53 | ankesh11 | Yes, that is one of the primary principles I have in mind. The question was to access in what way should I serve the data to the developers. |
| 17:27.35 | brlcad | I'm not understanding |
| 17:27.43 | brlcad | those two sites give some examples on how to serve the data |
| 17:27.59 | brlcad | there's nothing specifici to developers... |
| 17:28.08 | brlcad | or are you asking about a developer API to the database information? |
| 17:28.47 | ankesh11 | Yes, but wouldn't the core developers want access to the bulk information, rather than just results after uploading a file. |
| 17:29.14 | ankesh11 | We have visualizations for that, I was trying to understand if we need smething like performance indexes etc. |
| 17:29.17 | brlcad | this is intended to be a public resource, just like those two sites |
| 17:29.50 | brlcad | the devs will be able to log into the server and look at the actual log files |
| 17:29.59 | ankesh11 | Fine. |
| 17:30.02 | brlcad | (which should be stored in a folder with some indexing mechanism) |
| 17:30.40 | brlcad | we will want a variety of views on the data through the web site ... |
| 17:31.23 | ankesh11 | Okay, to be clear, the views I have worked on are of the aggregate data. Not individual results. |
| 17:31.59 | brlcad | the screenshot you just showed displays an individual result or is that across all logs? |
| 17:32.08 | ankesh11 | Across all logs |
| 17:32.25 | brlcad | okay, that's interesting in itself |
| 17:32.37 | brlcad | so let's break this down |
| 17:33.04 | brlcad | you want to have at least one view that just displays all of the available information for a given result |
| 17:33.23 | brlcad | basically, everything the back-end is able to extract from a log |
| 17:33.36 | brlcad | that's #1 |
| 17:35.09 | ankesh11 | Okay, it can be done definitely for the logs uploaded manually via the web interface. |
| 17:35.18 | brlcad | you'll want to compare a given result with the database, thats #2, and that view is a bit more complicated because they may wish to only compare some subset of the database results |
| 17:35.55 | brlcad | it should be doable for all logs, no? |
| 17:36.23 | brlcad | we want to keep track of the log originals so we can rebuild the database or do additional processing later that we didn't think about |
| 17:38.11 | brlcad | for #2, that subset might be based on results for similar/different CPUs, architectures, memory levels, clock cycles, results submitted "near my location", results submitted in a given timeframe, ... |
| 17:38.36 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 17:38.47 | brlcad | then there's #3, show me the data in the database in aggregate form, very similar to #2 but without the comparison aspect |
| 17:39.18 | ankesh11 | All the uploaded logs will be stored in a separate folder, yes. |
| 17:39.29 | ankesh11 | How do we do it for logs sent via an e-mail? |
| 17:39.43 | ankesh11 | The immediate results view that is. |
| 17:40.58 | ankesh11 | Okay, I get it I think. We can reply with the address to a unique URL that shows and compares the submitted results. |
| 17:41.04 | brlcad | put all incoming logs into a queue directory, then they can be processed at a throttleable rate |
| 17:41.14 | brlcad | right! |
| 17:41.57 | brlcad | that unique URL could be e-mailed to them on submission (optionally) so they have it, or with account profiles, they could get added to their account profile so they can look at their submitted results later |
| 17:42.19 | brlcad | you'll want some unique key, maybe and md5 hash |
| 17:42.39 | brlcad | that'd make it easy to locate using command-line tools too |
| 17:44.40 | ankesh11 | These are great inputs. I will get started with them. |
| 17:47.11 | brlcad | excellent progress, keep it up! |
| 17:47.18 | brlcad | oh, something else to work on |
| 17:47.32 | brlcad | it'd be nice if your style matches the GCI style guide that I mentioned a while back |
| 17:49.15 | brlcad | http://www.google-melange.com/gci/task/view/google/gci2013/5844328496758784 |
| 17:49.31 | brlcad | alas, nobody made the css file for it, so you'll have to do that yourself |
| 17:56.48 | brlcad | responded to e-mail with a summary of what we talked about here, for others |
| 17:56.56 | starseeker | makes a note to try tinypy sometime... |
| 18:00.18 | ankesh11 | <PROTECTED> |
| 18:01.24 | brlcad | ankesh11: screenshot? demo? |
| 18:01.36 | brlcad | it's a very flexible color scheme... |
| 18:01.55 | Notify | 03BRL-CAD Wiki:Valneastarcevic * 0 /wiki/User:Valneastarcevic: |
| 18:02.03 | ankesh11 | I don't have a saved copy. |
| 18:03.05 | ankesh11 | Probably I don't put much effort to make everything look well too. I will try that, and show you the results. |
| 18:03.25 | brlcad | okay, thanks ... it should be possible to make it look snappy |
| 18:03.39 | brlcad | the style is just a guide, some elements are left to interpretation |
| 18:04.20 | brlcad | like you could still have a white background with colorful banner and menu options, or the gray background with colorful elements |
| 18:04.35 | ankesh11 | Yes, is it okay if I stick to the style and use a framework like Bootstrap to build. That saves a lot of pain, I don't have to worry about responsiveness and such things too. |
| 18:04.49 | brlcad | it's more about using colors within the theme |
| 18:05.25 | ankesh11 | Okay. |
| 18:05.41 | brlcad | what are you using now? |
| 18:06.58 | ankesh11 | This is bootstrap too, just customized a few elements. |
| 18:07.20 | brlcad | then what are you really asking? :) |
| 18:07.31 | brlcad | is your question "is it okay to keep using bootstrap?" |
| 18:08.20 | ankesh11 | Yes, essentially. |
| 18:08.35 | brlcad | heh |
| 18:09.01 | brlcad | well that's an interesting discussion in itself |
| 18:09.25 | brlcad | I know there was talk from dr. rai about using existing infrastructure |
| 18:09.38 | brlcad | making this work within a mediawiki context, iirc |
| 18:10.12 | ankesh11 | Ah, it's just adding a CSS file to the project. |
| 18:10.14 | ``Erik | ankesh11: by 'customized', do you mean that you changed parts of the less code and recompiled it, or did you override stuff with a second css file? |
| 18:10.21 | brlcad | I do see this benchmark suite site as it's own entity so that's not entirely necessary in my perspective but it does beg some questions about how things like user accounts will be managed |
| 18:13.02 | ankesh11 | ``Erik: The latter, except that I didn't use another file to overwrite stuff, everything's in place. |
| 18:14.55 | ``Erik | ah, I'm using a free cdn for the core bootstrap, then I have a small css file for my modifications :) |
| 18:15.56 | ``Erik | brlcad: is the jun6 server maintenance reschedule, or were they able to replace the pmm without having to shut down? |
| 18:16.02 | ``Erik | rescheduled, even |
| 18:16.45 | kanzure | brlcad, what's the simplest way to render a scene to png? i'd like to add a png output helper function to the python bindings. |
| 18:17.38 | kanzure | by scene i think i mean wdb db_i or something |
| 18:17.49 | ``Erik | kanzure: "rt -o file.png file.g top" should work |
| 18:18.16 | ``Erik | libicv does 'smart'ish output formatting :) |
| 18:18.23 | kanzure | i am not using files |
| 18:18.27 | kanzure | so i don't have a file.g |
| 18:18.54 | kanzure | can i just call an entry function somewher? |
| 18:18.56 | kanzure | *somewhere |
| 18:19.52 | ``Erik | um, there's no library to generate an image, the rt executable does the prep stuff and calls rt_shootray a bunch of times, filling in the buffer |
| 18:20.26 | kanzure | does the rt executable just call a function in librt somewhere? |
| 18:21.11 | brlcad | ``Erik: I received no word, so I presume it was probably a temporary network outage only or hasn't happened yet |
| 18:21.59 | ``Erik | rt kinda works liked rt_prep(); for(j=0;j<height;j++) for(i=0;i<width;i++) { /* build vector for buffer[i][j] */ rt_shootray(); } save_to_file(); |
| 18:22.28 | brlcad | plus view_pixel() for every fixel to color it correctly |
| 18:23.21 | kanzure | how does mged's mouse-rotatable viewer work? raytrace every time there's a mouse movement? |
| 18:23.22 | brlcad | it could very easily be turned into LIBRT API, but right now it's part of the ray trace user interface framework (RTUIF) |
| 18:23.27 | brlcad | which is front-end code |
| 18:24.12 | brlcad | the rtgl and adrt viewers work like that, but mged draws a wireframe by default (or polygons) |
| 18:24.53 | brlcad | mged has a proper 3d view, so it's basically an opengl context |
| 18:25.15 | brlcad | and you manually tell it when to raytrace |
| 18:25.29 | brlcad | (unless you're using rtgl, which nobody is) |
| 18:25.54 | kanzure | maybe i'll just embed the opengl context into a qt/gtk event loop to sit next to the python interpreter |
| 18:26.16 | brlcad | n_reed should get that working again/better now that he's all so much more familiar with the code now |
| 18:26.22 | brlcad | and with all his copious spare time :) |
| 18:27.19 | kanzure | i should have been more stern about which commits i merged into python-brlcad :( |
| 18:27.29 | brlcad | kanzure: you could certainly do that .. our display manager is pretty easily embedded (that's what holds the opengl context) |
| 18:27.50 | brlcad | how so? |
| 18:28.23 | kanzure | pm ok? |
| 18:28.33 | brlcad | sure |
| 18:43.33 | *** join/#brlcad mihaineacsu (~mihaineac@92.85.193.175) | |
| 18:49.03 | kanzure | how about this, instead of the solution i have implemented there, it should be the opposite: a blacklist of function names that should not be included (ged_open, because that's a custom function in that file), and everything else gets used automatically by introspection |
| 18:56.15 | Notify | 03BRL-CAD:bob1961 * 61347 (brlcad/trunk/src/tclscripts/archer/Archer.tcl brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl): Added code to get around Tcl's "file writable somefile" failure (i.e., command always returns 0 when on windows and the file in question is on a remote drive. |
| 18:56.43 | kanzure | brlcad: https://github.com/kanzure/python-brlcad/commit/1c25ce30ad1ed6f695a0bb504187f79cacb81bc0 |
| 19:12.16 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) | |
| 19:16.04 | brlcad | kanzure: that could work too, but to me it's the same interface fail -- it's almost the same amount of work to put in a proper registration API (espeically if you count that this would now be the third work-around) |
| 19:16.19 | kanzure | what does this have to do with registration in particular? |
| 19:17.12 | brlcad | what do you mean? |
| 19:17.36 | brlcad | by the way, your exclusion list is awefully short .. print out all the ged_ functions it found and compare to your prior list ;) |
| 19:19.47 | kanzure | my exclusion list is based on the functions already defined in that file |
| 19:19.50 | kanzure | which was only two |
| 19:19.58 | kanzure | so the exclusion list should be of length two |
| 19:20.09 | kanzure | e.g. open and close have custom definitions in that file |
| 19:23.57 | brlcad | not sure that's relevant to my point or I'm misunderstanding something |
| 19:24.12 | brlcad | it looks like it's taking the command string and looking it up in the dictionary of library symbols |
| 19:24.32 | brlcad | if it tries to invoke ged_view_update, for example, it's probably going to "do bad things" |
| 19:25.15 | brlcad | before, it wasn't possible to invoke ged_view_update, so no potential crash case |
| 19:25.36 | kanzure | this is only exporting/exposing symbols, not invoking the functions |
| 19:26.07 | kanzure | actually now that i think about it i'm not sure why this is here if you can just call brlcad._bindins.libged.ged_view_update directly |
| 19:27.27 | brlcad | but the function is (potentially) invoked later based on that export/binding being made available to the user, no? |
| 19:28.25 | *** join/#brlcad vladbogo (~vlad@79.115.184.216) | |
| 19:31.43 | kanzure | yes. but also, the user can supply the arguments when invoking at that time. |
| 19:33.06 | brlcad | I guess that's my point; there's a handful of private functions named "ged_" that cannot be invoked (at least not without wrapping more data types and structs) ... pass them an arg and they'll just crash |
| 19:33.47 | kanzure | iirc all structs are being wrapped at the moment, although not always in nice accessible thoughtful ways |
| 19:34.21 | brlcad | there are private structs |
| 19:34.44 | brlcad | like I said, these are naming violations |
| 19:34.52 | brlcad | they shouldn't have the ged_ prefix |
| 19:40.09 | kanzure | alright |
| 19:40.45 | kanzure | In [12]: libwdb.mk_metaball.argtypes[-1] |
| 19:40.46 | kanzure | Out[12]: brlcad._bindings.libwdb.LP_c_double_Array_5 |
| 19:40.57 | kanzure | In [13]: type(brlcad._bindings.libwdb.LP_c_double_Array_5) |
| 19:41.01 | kanzure | AttributeError: 'module' object has no attribute 'LP_c_double_Array_5' |
| 19:41.20 | kanzure | ~magic~ |
| 19:41.58 | kanzure | it's _ctypes.PyCArrayType apparently |
| 19:42.11 | brlcad | that recently changed iirc or was proposed to be changed (I think by raj) and I haven't thought through all the implications |
| 19:42.35 | brlcad | he wanted a double[5] to get turned into a double * .. probably due to this very issue |
| 19:45.00 | kanzure | python/ctypes sometimes gets confused when certain ctypes primitives are imported from different libraries |
| 19:45.14 | kanzure | often this is a dependency issue, like the same struct getting two different definitions |
| 19:45.44 | kanzure | this often appears as "ArgumentError: ... expected Sphere instead of Sphere" |
| 19:58.18 | Notify | 03BRL-CAD:starseeker * 61348 (brlcad/trunk/include/rt/arb_edit.h brlcad/trunk/src/libged/edarb.c and 2 others): Refactor permute into librt. |
| 20:20.28 | Notify | 03BRL-CAD Wiki:Vladbogolin * 7306 /wiki/User:Vladbogolin/GSoC2014/Logs: /* Week 5 */ |
| 20:58.04 | Notify | 03BRL-CAD:starseeker * 61349 (brlcad/trunk/include/rt/arb_edit.h brlcad/trunk/src/libged/edarb.c and 2 others): refactor editarb into librt. Probably want to consider a mechanism for passing more informative strings back up the call stack in these cases... |
| 20:59.36 | Notify | 03BRL-CAD:starseeker * 61350 brlcad/trunk/include/rt/arb_edit.h: ws |
| 21:02.46 | andrei_ | does anyone know how fastf_t differs from double, I'm using grep but it's producing an awful lot of output |
| 21:03.46 | andrei_ | uh, apparently it s .. double, cool |
| 21:07.57 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 21:11.49 | kanzure | brlcad, what is the correct format of const fastf_t *verts[5] for mk_metaball? i tried passing a ctypes.c_double * 5 of (((1, 1, 1), 1, 0), ((0, 0, 1), 2, 0)) but i get a segmentation fault |
| 21:36.00 | Notify | 03BRL-CAD Wiki:Albertcoder * 7307 /wiki/User:Albertcoder/GSoC2014/logs: /* Week 5 */ |
| 21:36.17 | andrei_ | nevermind, fixed it, was a typo |
| 21:39.48 | Notify | 03BRL-CAD Wiki:Albertcoder * 7308 /wiki/User:Albertcoder/GSoC2014/logs: /* Week 5 */ |
| 22:02.54 | brlcad | andrei_: it's usually double -- that can be set to float or even some complex type though |
| 22:03.32 | andrei_ | ah, thanks, my error was just a typo, then. |
| 22:04.10 | andrei_ | that makes no sense, I meant that I understood what you said, but my error was just a typo, so it works |
| 22:06.59 | brlcad | kanzure: I'm not sure what (((1, 1, 1), 1, 0) translates to with ctypes, but I'd think ((1,1,1,1,0), (0,0,1,2,0), ... nctlpts-1) would be the format to match the arg no? |
| 22:07.32 | brlcad | I'd expect (((1, 1, 1), 1, 0) to turn into (pointer, int, int) |
| 22:08.18 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 22:08.39 | brlcad | it's expecting an array with #nctlpts entries, five values each |
| 22:29.30 | andrei_ | brlcad: you still around? |
| 22:30.22 | andrei_ | there's an array of control points in Nurb class, and I need to have a method to add control points to that array |
| 22:31.21 | andrei_ | The array is dynamically allocated, and I need to find an efficient way to reallocate it(As we can't know beforehand how many ctl points we have) |
| 22:31.52 | andrei_ | as far as I know reallocating it to double is the best solution , as it s O(n) |
| 22:49.35 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 7309 /wiki/User:Popescu.andrei1991/devlogs2014: /* Week 5 */ |
| 22:50.02 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 23:05.37 | brlcad | ankesh11: what's your question :) |
| 23:05.55 | brlcad | ankesh11: oops, sorry, meant for andrei but he apparently left |
| 23:10.45 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |