| 01:31.51 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) |
| 04:11.16 | *** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 04:40.55 | *** join/#brlcad abhi2011 (~chatzilla@117.200.89.98) |
| 05:31.21 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 06:43.57 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.54) |
| 06:44.01 | CIA-109 | BRL-CAD: 0323.19.56.171 07http://brlcad.org * r3191 10/wiki/Talk:Main_Page: |
| 06:50.53 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 07:10.23 | *** join/#brlcad abhi2011 (~chatzilla@117.200.89.69) |
| 08:15.19 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.86.172) |
| 08:31.34 | *** join/#brlcad merzo (~merzo@109-45-133-95.pool.ukrtel.net) |
| 11:07.28 | *** join/#brlcad abhi2011 (~chatzilla@117.200.89.50) |
| 11:41.38 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 12:22.00 | *** join/#brlcad abhi2011 (~chatzilla@117.200.85.236) |
| 12:40.08 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 12:46.32 | *** join/#brlcad merzo (~merzo@72-3-133-95.pool.ukrtel.net) |
| 13:31.16 | *** join/#brlcad abhi2011 (~chatzilla@117.200.84.105) |
| 13:54.23 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3192 10/wiki/Talk:Main_Page: Reverted edits by [[Special:Contributions/23.19.56.171|23.19.56.171]] ([[User talk:23.19.56.171|Talk]]); changed back to last version by [[User:X Tin Basher|X Tin Basher]] |
| 13:54.36 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:23.19.56.171]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 14:15.35 | brlcad | abhi2011: funny coincidence, someone on the bullet channel was bitching just yesterday about bullet's internal ray tracing sucking |
| 14:16.00 | brlcad | told them about your efforts to integrate with librt, excitedness ;) |
| 14:27.27 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 14:29.58 | *** join/#brlcad abhi2011 (~chatzilla@117.200.91.35) |
| 14:30.07 | abhi2011 | brlcad: cool :) |
| 14:30.19 | abhi2011 | so there is someone replying in that channel :P |
| 14:31.00 | abhi2011 | I have been trying to figure out a algorithm that uses all the normal and curvature info to generate the points |
| 14:31.22 | abhi2011 | guess I ll first go with the box-box case |
| 14:31.50 | abhi2011 | a important thing to figure out is the direction in which an object is penetrating another object |
| 14:32.08 | abhi2011 | as the normal has to point along that direction |
| 14:33.36 | abhi2011 | currently I ll just check to see which ever dimension is the least in the overlapping volume , i.e. if the object is penetrating another along the z axis, then the dimension of the overlap region along the z axis will be least |
| 14:35.14 | abhi2011 | of course the best way would be to make the normal point according to the curvature of the 2nd body |
| 14:39.16 | abhi2011 | like so : https://docs.google.com/drawings/d/1Fp44t9AcZZurbNufXti64u-23CRjC49Z3r0WSmim5tU/edit |
| 14:40.23 | abhi2011 | but then rays hitting the curving surface would give many normals, so the proper normal has to be chosen, which can be got by vector summing I guess |
| 14:45.59 | abhi2011 | funny warning about the IGNORE symbol being redefined : http://bin.cakephp.org/view/1298213576 |
| 14:46.24 | brlcad | yeah, that channel is quite most of the time, but every now and then a discussion sparks up |
| 14:47.39 | brlcad | good to know about the IGNORE redefinition |
| 14:52.10 | brlcad | abhi2011: we actually include measures to define our IGNORE macro without conflicting with the windows macro |
| 14:52.23 | brlcad | so somewhere a windows header is getting included without our usual protections |
| 14:53.44 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.84.102) |
| 14:53.45 | brlcad | abhi2011: AHA ... I think I found the problem -- you must include common.h before any/all *system* headers |
| 14:54.01 | abhi2011_ | ok |
| 14:54.25 | brlcad | you saw my other comments? |
| 14:55.52 | brlcad | irc problems? |
| 15:03.30 | abhi2011 | brlcad: yes , yes I saw them till : good to know about the IGNORE redefinition and then AHA |
| 15:03.47 | abhi2011 | yeah, disconnected in between |
| 15:05.44 | abhi2011 | yep I ll move up common.h |
| 15:10.34 | abhi2011 | hmm ,warning is still there though |
| 15:11.54 | abhi2011 | I think the issues is that a similar macro has been defined in both places |
| 15:11.57 | abhi2011 | not the order |
| 15:12.14 | abhi2011 | winbase.h & common.h |
| 15:20.11 | CIA-109 | BRL-CAD: 03abhi2011 * r47378 10/brlcad/trunk/src/libged/simulate/ (9 files): |
| 15:20.33 | abhi2011 | ok hope the commit went through fine, committing from windows with tortoise svn for the 1st time |
| 15:35.38 | abhi2011 | so is there a function already, which lets me check if a solid is present in the tree of a comb |
| 15:36.26 | abhi2011 | I can write one to recursively check the tree of a comb, and if it find the solid, then return true, but perhaps one already exists |
| 15:37.03 | abhi2011 | I need it for checking which comb, a solid belongs to , when rt gives me a solid at the point where a ray exits |
| 15:37.26 | abhi2011 | I then need to sum the normal only for that comb(rigid body) |
| 15:38.46 | abhi2011 | dbfind is there I see |
| 15:46.49 | abhi2011 | yep, ged_find, does exactly that , traversing in LNR order, will modify it a bit(in my own file) :P |
| 16:42.13 | CIA-109 | BRL-CAD: 03abhi2011 * r47379 10/brlcad/trunk/src/libged/simulate/ (simutils.c simutils.h): Added a function to check if a solid is present in a comb, required for checking which rigid body(a comb), a particular solid belongs to , while raytracing. |
| 18:04.29 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 18:52.50 | CIA-109 | BRL-CAD: 03abhi2011 * r47380 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.h): |
| 18:54.23 | CIA-109 | BRL-CAD: 03abhi2011 * r47381 10/brlcad/trunk/src/libged/simulate/simrt.c: Added code for normals |
| 19:10.11 | *** join/#brlcad Forth (~Forth@92.242.118.253) |
| 19:11.55 | *** part/#brlcad Forth (~Forth@92.242.118.253) |
| 19:16.19 | CIA-109 | BRL-CAD: 03abhi2011 * r47382 10/brlcad/trunk/src/libged/simulate/simrt.c: More supporting code to test if the normals are being recorded correctly during the ray trace |
| 19:18.11 | brlcad | abhi2011: of course the macro is defined in both places, but the places we include windows headers takes care of that |
| 19:18.40 | brlcad | so if that conflict is encountered, some assumption is failing or the header inclusion ordering is wrong or the wrong headers are being included |
| 19:19.35 | brlcad | winbase.h shouldn't be directly included anywhere, so you have to look at the header includes to recursively see who includes winbase.h |
| 19:19.36 | abhi2011 | ok |
| 19:20.44 | brlcad | abhi2011: what was r47378? |
| 19:21.14 | brlcad | commit message got left off, not clear what changed since it was a fairly big commit .. wondering what it was |
| 19:21.25 | abhi2011 | it was an update of the source code to use contact pairs again |
| 19:21.33 | brlcad | ah, okay |
| 19:21.39 | abhi2011 | new svn software :P |
| 19:21.44 | abhi2011 | forgot to add message |
| 19:21.46 | brlcad | yep, realized that |
| 19:22.01 | abhi2011 | so I have an awesome idea now about how to generate normals |
| 19:22.22 | abhi2011 | basically summing the normals in the surface inside the overlap region |
| 19:23.03 | brlcad | sounds good :) |
| 19:23.20 | abhi2011 | the vector sum of the normals on the outer surface of the body gives the direction of the force that the body would apply on anything touching it |
| 19:23.28 | abhi2011 | as is the case in the real world |
| 19:23.54 | abhi2011 | once I have the normal, I ll shoot rays in that direction to get the depth of penetration |
| 19:24.27 | abhi2011 | and then the contact points (which should be on the surface of the body always), are the points where these rays leave the object |
| 19:24.33 | brlcad | could you use the velocity vector of the object in motion too? |
| 19:24.49 | abhi2011 | yes I can vectgr sum that to the normal too |
| 19:24.56 | abhi2011 | or just use the velocity vector |
| 19:25.08 | abhi2011 | but the point is no matter what the velocity vectpr |
| 19:25.19 | brlcad | why wouldn't you just use the velocity vector, shoot rays in the direction of the velocity, calculate the depth of penetration? |
| 19:25.20 | abhi2011 | the force will be based on the surface |
| 19:25.41 | abhi2011 | well because it depeds on both |
| 19:26.01 | abhi2011 | the angle of the surface and the velocity direction at which the object strikes |
| 19:26.09 | abhi2011 | that surface |
| 19:26.18 | brlcad | okay |
| 19:26.36 | abhi2011 | like a ray reflecting off a glass at an angle |
| 19:26.43 | brlcad | nods, makes sense |
| 19:26.46 | brlcad | misunderstood |
| 19:26.47 | abhi2011 | so hav to think about how to account for the velocity |
| 19:26.52 | abhi2011 | ah |
| 19:27.00 | abhi2011 | the angle between normal and velocity |
| 19:27.13 | abhi2011 | law of reflection calculation maybe |
| 19:27.45 | abhi2011 | but hmm, I think bullet will take care of that |
| 19:27.56 | abhi2011 | the fnal velocity direction i mean |
| 19:28.04 | abhi2011 | all I need to give it is the normal |
| 19:28.12 | abhi2011 | at the point of contact |
| 19:29.34 | abhi2011 | here are some sample cases : https://docs.google.com/drawings/d/1Fp44t9AcZZurbNufXti64u-23CRjC49Z3r0WSmim5tU/edit |
| 19:30.49 | abhi2011 | so the lower left case, shows that the concave case should also be possible to calculate correctly |
| 19:31.27 | abhi2011 | if this works out then I can check how to insert multiple manifolds, which I have read somewhere , is possible |
| 19:52.51 | brlcad | can't get to gdocs at the moment, will have to take a look later |
| 19:54.54 | CIA-109 | BRL-CAD: 03bob1961 * r47383 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: When opening a database also change the current working directory to the directory where the database lives. |
| 20:02.17 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.81.190) |
| 20:15.49 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.81.155) |
| 20:46.01 | CIA-109 | BRL-CAD: 03starseeker * r47384 10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-xml-catalog.xml.in: I don't think this variable needs to be specific to BRL-CAD in this case... |
| 20:52.33 | CIA-109 | BRL-CAD: 03starseeker * r47385 10/geomcore/trunk/ (12 files in 5 dirs): Turn on docbook documentation for geomcore. Stub in a geometry protocol doc, but nothing much there at the moment. |
| 20:56.01 | CIA-109 | BRL-CAD: 03abhi2011 * r47386 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simutils.c simutils.h): Now the entry and exit solids of a ray passing through an overlap region are checked to see if they belong to the comb of rigid body B |
| 20:59.16 | brlcad | deadline is today -- feel free to fill out quick/easy tasks that could be completed in 1-3 days at http://brlcad.org/wiki/Contributor_Quickies |
| 20:59.40 | brlcad | I'm crafting together our proposal now |
| 20:59.58 | brlcad | ideally we need 10 topics for each of the 8 categories |
| 21:00.49 | ``Erik | 'separate out libnmg' O.o I have vague recollection of libnmg not too long ago :) |
| 21:00.55 | brlcad | well, 5-10 tasks per topic |
| 21:01.37 | ``Erik | think simd/sse vmath might be worth an entry? |
| 21:03.02 | brlcad | iirc, include/vector_*.h was (as anticipated) an attempt at that |
| 21:03.04 | brlcad | and it failed |
| 21:03.53 | brlcad | test harness for vmath.h might be something though |
| 21:04.28 | brlcad | example of gnome tasks https://live.gnome.org/GoogleCodeIn/Tasks |
| 21:04.55 | brlcad | I'm inclined to direct all students to either IRC or the mailing list, thoughts on which? |
| 21:05.12 | brlcad | keeping in mind that it might be a lot of students 24-7 |
| 21:05.13 | ``Erik | in looking at that a while back, the choice to go with typedef point_t fastf_t[3]; instead of typedef point_t struct { fastf_t f[3]; }; or something was ... critical |
| 21:06.16 | brlcad | it wasn't a fail in terms of being a drop-in replacement -- that would have been the technical issue there |
| 21:06.46 | brlcad | it was a fail in that the simd version wasn't actually faster -- needed more data, not just one vector/matrix at a time |
| 21:07.01 | starseeker | fix tkhtml3 on Win64? |
| 21:07.22 | starseeker | for large numbers of students, I'd vote mailing list |
| 21:07.23 | ``Erik | I think irc will be quicker and more accepting of newbs |
| 21:07.31 | starseeker | hard to track conversations though |
| 21:07.34 | brlcad | starseeker: can you explain the problem? |
| 21:07.39 | ``Erik | but irc would lack good record |
| 21:07.45 | starseeker | probably not well enough for a student |
| 21:07.46 | brlcad | remember that these are *high school* students |
| 21:08.08 | brlcad | the questions are going to be very much "hold my hand", what's next? |
| 21:09.23 | brlcad | bhinesley: jordisayol: louipc: kanzure: anyone else: interested in being a GCI mentor? |
| 21:10.20 | starseeker | brlcad: what about bu_getopt_long or some such? |
| 21:10.57 | starseeker | just getting it working + adding it to one command would be a good start |
| 21:11.45 | brlcad | I don't think bu_getopt_long is what we want really (at least there's little-to-no value in having a bu version of getopt_long()) |
| 21:12.09 | starseeker | uh... rt with -- options seems worthwhile... |
| 21:12.10 | brlcad | we need long options, but there's no reason it needs to be compatible with that extension |
| 21:12.42 | starseeker | do they do it the wrong way? |
| 21:12.43 | brlcad | getopt_long() is an overlay with getopt() .. the two work suckily together |
| 21:13.04 | brlcad | pretty much |
| 21:13.28 | starseeker | we need something - what do you suggest? |
| 21:14.09 | brlcad | writing an option interface for bu |
| 21:14.20 | brlcad | already sketched out the basics a month or two ago |
| 21:14.31 | starseeker | erm. link? |
| 21:14.45 | brlcad | no link |
| 21:14.46 | brlcad | code in a checkout |
| 21:14.50 | starseeker | ah |
| 21:15.02 | brlcad | still, too advanced for gci I think |
| 21:15.08 | starseeker | k. pity |
| 21:15.24 | brlcad | if it's not something that'd take you less than a half a day from start to finish, it's probably too complex |
| 21:15.59 | brlcad | 13 year olds ... |
| 21:16.02 | starseeker | well, there's always fixing the bbox function for bots |
| 21:16.29 | brlcad | sure -- could put that one up, but i'd mark it hard :) |
| 21:18.50 | abhi2011 | I think tcl and gui will be easier for high school students :) |
| 21:19.04 | abhi2011 | maybe more of tcl and some libged related code |
| 21:19.10 | brlcad | from other project's reviews from prior years, the kids really do end up being a nearly full-time effort so we need to manage the complexity up front -- things we can explain and point trivially |
| 21:19.19 | starseeker | heh - I can't seem to come up with small projects from the gui side... |
| 21:19.25 | brlcad | abhi2011: you have some project ideas? |
| 21:19.30 | abhi2011 | for example the idea about integrating some of the visualization tools into the gui |
| 21:19.45 | abhi2011 | most of them have a fixed interface I guess |
| 21:19.48 | brlcad | remember that it's basically a contest -- they're looking for tasks that take hours or a day or two at most |
| 21:20.00 | abhi2011 | oh ok |
| 21:20.22 | brlcad | which includes the time to download the software, become familiar with the problem, find their way around, run a tool, etc |
| 21:21.05 | abhi2011 | hmm, then tcl and gui stuff would be tough |
| 21:21.23 | brlcad | came up with what I think is a GREAT idea at the mentor summit... we can create a preconfigured disk image for the students that already has a source checkout and compiled install ready to go |
| 21:22.14 | brlcad | that with a few simple instructions to download qemu, download disk image, create new image, run .. source is here, binaries are there, go! |
| 21:24.46 | abhi2011 | yes, that can really get things going fast, did that for virtual box images once |
| 21:25.21 | abhi2011 | so we are not expecting code from them I guess, they design something using the tools already present in brlcad ? |
| 21:25.59 | brlcad | you seen the http://brlcad.org/wiki/Contributor_Quickies list? |
| 21:26.03 | brlcad | it can be a code project |
| 21:26.12 | brlcad | or docs, or web or ... anything really |
| 21:26.21 | brlcad | something that'd take hours of time |
| 21:28.19 | abhi2011 | ok |
| 21:33.14 | abhi2011 | well I was thinking along the lines of making mged a bit easier to use : like when an object is selected and the primitive editor is opened, then the selected object's name should already be there and it should be displaying the object name |
| 21:33.48 | CIA-109 | BRL-CAD: 03128.63.32.62 07http://brlcad.org * r3193 10/wiki/Contributor_Quickies: /* Code */ add rt_bot_bbox item |
| 21:34.03 | abhi2011 | or even simpler, ensuring that closing the command window closes the application |
| 21:34.47 | abhi2011 | including the gfx window |
| 21:35.04 | starseeker | that... might not be so simple, actually |
| 21:35.13 | abhi2011 | oh :) |
| 21:35.23 | starseeker | seems to recall brlcad working with that once... |
| 21:35.26 | abhi2011 | low level opengl callbacks ? |
| 21:35.35 | starseeker | don't recall now |
| 21:36.25 | starseeker | brlcad: is excising Tcl functions from libraries too hard? (guessing yes...) |
| 21:37.02 | abhi2011 | also is there a script for moving the view along a specified path, it would be awesome to write a script or a simple c function that revolves the camera around the scene as objects are dropping |
| 21:37.08 | abhi2011 | *moving the camera |
| 21:37.18 | cvds_ | abhi2011: please dont, since I use that feature (closing thecommand window but keeping the gfx window) |
| 21:37.29 | abhi2011 | hehe ok :) |
| 21:37.53 | abhi2011 | so you run a script then close the command window I guess |
| 21:38.27 | cvds_ | mged -c to attach a single window and then set mged_default(multi_pane) 1; gui; and close the mged command window ;) |
| 21:38.54 | abhi2011 | ah ok |
| 21:40.13 | cvds_ | and using yakuake as the input. Works like a charm |
| 21:40.32 | starseeker | brlcad: http://directory.fsf.org/wiki/Popt |
| 21:40.40 | starseeker | http://rpm5.org/files/popt/popt-1.16.tar.gz |
| 21:40.46 | starseeker | would that be of interest? |
| 21:41.38 | starseeker | looks like MIT style license |
| 21:48.02 | starseeker | (not for GCI per say, but as an alternative to rolling our own option parsing?) |
| 21:59.21 | brlcad | abhi2011: having the closure of all of mged's windows actually close mged sounds like a great task -- can you add that to the wiki? |
| 22:00.04 | brlcad | starseeker: not sure what you meant with the excising |
| 22:00.34 | starseeker | doing whatever is needed to get the Tcl/Tk C api usage up to libtclcad (or steps in that direction) |
| 22:00.35 | brlcad | abhi2011: camera 360 script sounds like another great one, wiki? |
| 22:01.20 | starseeker | blinks - must have been thinking something else - I thought that "close all windows" issue was tied up with something else more complex |
| 22:01.28 | brlcad | cvds_: interested in being a mentor? :) |
| 22:02.01 | abhi2011 | brlcad: sure and sure :) |
| 22:02.22 | brlcad | starseeker: it's a bug, it used to close mged |
| 22:02.37 | brlcad | now you can close those two windows and mged is still running |
| 22:02.41 | brlcad | abhi2011: awesome :) |
| 22:08.42 | CIA-109 | BRL-CAD: 03starseeker * r47387 10/brlcad/trunk/src/ (3 files in 2 dirs): Shouldn't have moved this, used only internally in libbu and it's one file. |
| 22:11.06 | brlcad | starseeker: Makefile.am |
| 22:11.20 | starseeker | coming now |
| 22:11.39 | CIA-109 | BRL-CAD: 03starseeker * r47388 10/brlcad/trunk/src/ (5 files in 3 dirs): Clean up the rest of the uce stuff |
| 22:11.41 | starseeker | prods CIA |
| 22:21.20 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3194 10/wiki/Contributor_Quickies: /* Code */ |
| 22:54.32 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3195 10/wiki/Contributor_Quickies: /* Code */ |
| 22:55.37 | brlcad | ~abhi2011++ |
| 22:55.41 | brlcad | awesome |
| 22:55.44 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3196 10/wiki/Contributor_Quickies: /* EASY: Camera 360: A Tcl script to capture images while rotating the view around a scene */ |
| 22:56.47 | abhi2011 | will try to come up with some more tomorrow :) |
| 22:56.53 | brlcad | we need at least 3 more outreach and translation tasks, and at least 1 more research and UI task :) |
| 22:57.01 | brlcad | and QA |
| 22:57.09 | brlcad | need at least 5 for each |
| 22:57.58 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 22:59.16 | abhi2011 | how about starting the primitive editor with the currently selected object instead of having the user type it in each time |
| 22:59.53 | brlcad | you mean sed? |
| 22:59.58 | brlcad | sure |
| 23:00.16 | brlcad | oh, in the gui |
| 23:00.20 | abhi2011 | yes |
| 23:00.30 | brlcad | yeah, that'd be possible .. a bit complicated to explain, definitely a hard task |
| 23:00.43 | brlcad | your camera task is probably medium or hard for that matter :) |
| 23:00.47 | abhi2011 | yeah it requires familairity with mged |
| 23:01.01 | abhi2011 | yeah :P |
| 23:01.02 | brlcad | easy if you know mged and know scripting.. but that's a big IF for a 13 year old :) |
| 23:12.14 | ``Erik | iff, even |
| 23:12.38 | ``Erik | *ponder* logo on mged? |
| 23:12.59 | brlcad | perfect, add it |
| 23:13.16 | brlcad | great idea |
| 23:13.37 | ``Erik | iirc, logo was a variant of scheme, soooo... yeah, let's ditch tcl for lisp! |
| 23:14.11 | brlcad | heh |
| 23:14.23 | brlcad | took that to mean .. model the BRL-CAD logo in MGED :P |
| 23:14.52 | ``Erik | if mged ate lisp, it'd be automatable... |
| 23:15.00 | ``Erik | "just a couple lines" |
| 23:17.38 | ``Erik | has an old sorbel filter in C *ponder* |
| 23:20.45 | ``Erik | (whuddya mean, making each pixel a colored arb8 ain't what ya meant?) |
| 23:23.18 | brlcad | mmhmm |
| 23:23.33 | brlcad | pix-g will do it now :) |
| 23:25.33 | ``Erik | pix2g ya mean? |
| 23:25.43 | brlcad | right |
| 23:25.55 | brlcad | didn't want it to look like a proper tool :) |
| 23:26.07 | ``Erik | does not recall that puppy |
| 23:26.30 | brlcad | proc-db |
| 23:26.35 | ``Erik | and I keep typing 'git log', starseeker has poisoned my brain |
| 23:26.57 | ``Erik | it's old, even |
| 23:27.12 | brlcad | yeah, did that a long time ago |
| 23:27.21 | brlcad | fairly useless, but fun hack |
| 23:27.39 | ``Erik | is it actually a planar arb8 set with colors? |
| 23:28.01 | brlcad | I started with arbs, but I think that last rev uses spheres |
| 23:28.15 | brlcad | trivial to put it back |
| 23:28.38 | ``Erik | painter and smoother might replicate something acceptable... push it to nurbs and it's all good |
| 23:29.31 | ``Erik | (curve fit on a nurb is a whole lot easier than attempting to replicate geometry in implicits, right?) |
| 23:29.57 | ``Erik | srry, on a nurbs |
| 23:32.00 | brlcad | you going to add that logo task? that really is a great idea |
| 23:32.55 | ``Erik | I'll let you... I actually meant the language "logo" |
| 23:33.59 | ``Erik | if you want to give me credit for sparking the idea in you, that's cool, but that definitely isn't what I meant :) |
| 23:36.26 | brlcad | even better if you'd write it, cause writing this proposal is going to have me right up against the submission deadline |
| 23:36.54 | ``Erik | which logo? |
| 23:37.18 | brlcad | the new logo |
| 23:37.38 | brlcad | point them to the news page on the main website |
| 23:38.25 | ``Erik | I have a cat on my lap, and I'm not sure if he's actually alive anymore O.O |
| 23:40.29 | ``Erik | abhi has no user page |
| 23:42.32 | ``Erik | I d'no, doco or ux? |
| 23:43.06 | ``Erik | I'll go ahead and call it ux |
| 23:49.38 | ``Erik | ffs, WoW is stomping my machine here O.o 20-30 seconds before a keypress registers in other apps :/ |
| 23:49.39 | brlcad | <PROTECTED> |
| 23:55.08 | CIA-109 | BRL-CAD: 03Erik 07http://brlcad.org * r3197 10/wiki/Contributor_Quickies: /* User Interface */ Add .g of logo task |
| 23:55.53 | ``Erik | wordsmith your heart out, probably needs a time guess |
| 23:56.00 | brlcad | k |
| 23:56.41 | brlcad | ideas on hold.. the deadline apparently isn't .. what I calculated it to be .. (ffs.) |
| 23:56.52 | brlcad | just went to submit (early) and .. it's not |
| 23:59.34 | CIA-109 | BRL-CAD: 03128.63.32.74 07http://brlcad.org * r3198 10/wiki/Contributor_Quickies: move logo to outreach, needs two more |