| 00:31.09 | starseeker | http://sourceforge.net/blog/subversion-repository-gap-notifications-by-email/ |
| 00:31.13 | starseeker | confound it |
| 00:31.29 | starseeker | they shouldn't have enabled committing without doing that |
| 00:34.27 | starseeker | ``Erik, brlcad: should we put out an email not to commit until we get this fixed? |
| 00:37.23 | starseeker | I've got patches for most of the missing commits to master thanks to the brlcad.org git repo, but that doesn't cover branches and it's missing a couple at the end |
| 00:38.19 | starseeker | those will probably have to be reconstructed from the brlcad-commits emails |
| 00:39.17 | starseeker | not sure what will happen to local checkouts that already have these commits when they svn up after we rebuild them - may have to tell people to do new checkouts |
| 01:38.25 | *** join/#brlcad infobot (ibot@69-58-76-73.ut.vivintwireless.net) |
| 01:38.25 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || Congrats to all GCI 2014 winners Peter & Marc! || Congratulations to our 12 GSoC students! || Don't ask if someone is here, just ask your questions and wait for a response. ;-) |
| 02:00.40 | *** join/#brlcad gurwinder (~chatzilla@117.220.148.234) |
| 02:20.49 | Notify | 03BRL-CAD Wiki:Gurwinder Singh * 9109 /wiki/Povray: |
| 02:22.49 | Notify | 03BRL-CAD Wiki:Gurwinder Singh * 9110 /wiki/Povray: |
| 02:40.08 | Notify | 03BRL-CAD Wiki:Gurwinder Singh * 9111 /wiki/Povray: |
| 02:41.43 | Notify | 03BRL-CAD Wiki:Gurwinder Singh * 9112 /wiki/Povray: |
| 02:42.49 | gurwinder | brlcad: Hi, please check the page http://brlcad.org/wiki/Povray |
| 02:43.45 | gurwinder | brlcad: I have written it according to your given instructions. |
| 03:37.47 | *** join/#brlcad gurwinder (~chatzilla@117.220.148.234) |
| 04:50.50 | *** part/#brlcad dracarys983 (dracarys98@nat/iiit/x-mxvjyvetkymbrxiv) |
| 05:32.52 | brlcad | starseeker: I have a more detailed e-mail from sourceforge on exactly which commits are missing and am passing it along to everyone |
| 05:35.41 | brlcad | as this is essentially a revert with a day and a half of commits dropped, individual authors will just have to replay their commits (one at a time or they can diff to a new checkout and collapse to fewer commits) |
| 05:37.11 | brlcad | what will likely happen to existing checkouts that were up-to-date is that they'll first report no such revision .. then when that revision exists, it'll likely report a checksum mismatch and have to get checked out again |
| 05:40.04 | gurwinder | brlcad: please check http://brlcad.org/wiki/Povray |
| 05:40.18 | brlcad | gurwinder: yes, I saw your link, patience please :) |
| 05:40.24 | brlcad | kind of have a major issue going on right now |
| 05:40.35 | gurwinder | brlcad: ok :) |
| 05:57.20 | brlcad | gurwinder: okay, took a quick look and that looks great -- of those that are incomplete, here are a few in a rough priority order: ellg/ell1 (these are simply ell), tec/trc (these are simply tgc), half, pipe, arbn, ehy, epa, rhc, rpc, bot, and then probably extrude and revolve (which requires sketch) |
| 05:58.01 | brlcad | you don't have to do anything special for the ell/tgc specializations, just write them out as ell/tgc |
| 05:58.27 | brlcad | the same shape should result -- how you get there is somewhat unimportant for povray export |
| 05:59.35 | gurwinder | brlcad: Ok, I will do these two first |
| 06:00.28 | gurwinder | and want to know about my patch submittion |
| 06:01.01 | brlcad | gurwinder: all patches are on hold for a couple days until we get the repository back online and up-to-date |
| 06:01.11 | gurwinder | brlcad: How to submit my work? One by one or by submitting it as a single file |
| 06:01.22 | brlcad | sourceforge restored our repository, but we lost 4 days of commits that we have to re-do |
| 06:01.37 | gurwinder | brlcad: Ok, I undertand :) |
| 06:02.29 | brlcad | gurwinder: ah, whether to combine or keep separate -- it depends |
| 06:03.02 | brlcad | you have a couple pending already that need to be reviewed |
| 06:04.08 | brlcad | as you complete additional work, it'll probably be easier for you and your reviewer if all your work is in one patch file |
| 06:04.22 | brlcad | BUT that means you will have to work even harder to make sure there aren't any problems in your patches |
| 06:05.15 | gurwinder | Ok, I will submit it with my additional work. And the patch that I have submitted is working well on my system. |
| 06:05.28 | brlcad | if you see anything that can be improved in the code you wrote, you should make sure your patch has the improvement |
| 06:05.37 | brlcad | if you see something that can be improved, I will almost certainly see it too |
| 06:06.33 | brlcad | for that, I mean coding style, indentation, proper names, proper comments, etc ... the issues listed in HACKING and more |
| 06:06.59 | brlcad | basically be CONSISTENT ;) |
| 06:09.43 | gurwinder | ok, If anything left I think re-viewer's comment is good way to get it :) |
| 06:10.41 | brlcad | it's not .. anything left that the reviewer finds disqualifies that patch as demonstrating commit competency |
| 06:12.12 | gurwinder | oh, Ok then :) |
| 06:12.22 | brlcad | the reviewer IS a good source for feedback on the design, intent, scope, etc .. |
| 06:13.54 | brlcad | but your job is to make sure your work is "complete" (remember the acceptance requirements you agreed to) such that nothing you submit will have to get "cleaned up" by someone else or (worse) undone |
| 06:14.53 | brlcad | gurwinder: in addition to the coding style issues in HACKING, you can see a specific review checklist in doc/code_review.txt ... ask yourself each question |
| 06:16.18 | brlcad | if you don't understand any of them, just ask |
| 06:17.50 | gurwinder | brlcad: thank I will check my patch by going through all those questions. I will ask If I have any problem :) |
| 06:27.22 | brlcad | thx |
| 06:28.43 | brlcad | starseeker: can you snarf the individual patches from the git mirror into a web folder (from r65597 forward) to individuals can replay their commits? |
| 06:35.02 | brlcad | starseeker: never mind, already did it |
| 06:35.28 | *** join/#brlcad shaina (~shaina@59.89.44.182) |
| 07:42.48 | Notify | 03BRL-CAD:brlcad * 65646 brlcad/trunk/TODO: test commit after sourceforge backup recovery (4 days lost + down 8), mention ovoid shape a new primitive as our existing solvers should easily handle it |
| 07:57.36 | Notify | 03BRL-CAD:brlcad * 65647 brlcad/trunk/TODO: correction, only 1.5 days lost (13 commits, 4 devs impacted). this is a replay commit of what was r65658 - some more thoughts on extending libbu's parallelism functionality. |
| 08:02.33 | Notify | 03BRL-CAD:brlcad * 65648 brlcad/trunk/src/librt/primitives/datum/datum.c: replay of r65649 following major Sourceforge service outage (hard file store failure, filesystem corruption, full backup restoration): update copyright to inception, even though it was derived from the template. |
| 08:06.36 | Notify | 03BRL-CAD:brlcad * 65649 brlcad/trunk/src/librt/primitives/datum/datum.c: replay of r65650.document what's going on here better with the buffer size padding, so simple changes to datum data don't end up leaving pockets of dead objects throughout the .g file. also fix a bug in the size where we weren't allocating space for the decode size bytes. |
| 08:07.13 | *** join/#brlcad dracarys983 (dracarys98@nat/iiit/x-vqlyjnllsckpdlvi) |
| 08:41.58 | *** join/#brlcad ries (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl) |
| 08:55.27 | *** join/#brlcad merzo (~merzo@92.60.189.225) |
| 09:50.10 | *** join/#brlcad andrei_il (~andrei@109.100.128.78) |
| 10:32.57 | *** join/#brlcad sofat (~sofat@202.164.45.204) |
| 10:39.17 | *** join/#brlcad teepee-- (bc5c2134@gateway/web/freenode/ip.188.92.33.52) |
| 11:42.00 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 12:12.50 | *** join/#brlcad luca79 (~luca@host4-221-dynamic.5-87-r.retail.telecomitalia.it) |
| 12:13.24 | *** join/#brlcad sofat (~sofat@202.164.45.204) |
| 12:30.13 | *** join/#brlcad ries (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl) |
| 12:30.25 | *** join/#brlcad sofat (~sofat@202.164.45.204) |
| 12:34.42 | *** join/#brlcad ih8sum3r (~deepak@122.173.5.55) |
| 12:36.43 | *** join/#brlcad shaina (~shaina@59.91.92.89) |
| 12:42.22 | *** join/#brlcad sofat_ (~sofat@101.208.64.209) |
| 12:59.04 | *** join/#brlcad teepee-- (bc5c2134@gateway/web/freenode/ip.188.92.33.52) |
| 13:11.57 | Notify | 03BRL-CAD:starseeker * 65650 brlcad/trunk/src/libbrep/shape_recognition.cpp: Replay of commit r65653 - This test was known to be insufficient/incorrect from the outset - it's going to take a raytracing based approach to resolve this question generally. Will have to punt and return the to-be-evaluated cases in a struct, so bu_ptbl won't cut it as a return type either. |
| 13:12.48 | Notify | 03BRL-CAD:starseeker * 65651 brlcad/trunk/src/libbrep/shape_recognition.cpp: Replay of commit r65654 - This'll be a job - has to be done in libged land (or possibly libanalyze/librt) but make some notes for now on how we'll have to go at it. |
| 13:13.40 | *** join/#brlcad andrei_il (~andrei@109.100.128.78) |
| 13:13.47 | Notify | 03BRL-CAD:starseeker * 65652 brlcad/trunk/src/libged/nmg_cmface.c: Replay of commit r65655 - Apply patch #390 from Brad Hollister, removing unused tmp variable. |
| 13:14.26 | Notify | 03BRL-CAD:starseeker * 65653 brlcad/trunk/src/libged/nmg_cmface.c: Replay of commit r65656 - Apply patch #390 version 2 from Brad Hollister |
| 13:25.35 | *** join/#brlcad sofat_ (~sofat@101.208.64.209) |
| 13:26.46 | *** join/#brlcad ries (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl) |
| 13:36.55 | *** join/#brlcad Shubham (6719e766@gateway/web/freenode/ip.103.25.231.102) |
| 13:39.15 | starseeker | brlcad: that should be all of mine |
| 13:46.13 | *** join/#brlcad sofat_ (~sofat@101.208.64.209) |
| 13:57.11 | Notify | 03BRL-CAD:ejno * 65654 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: recommit r65646 after sourceforge outage: 'write CCONE1 records' |
| 13:58.39 | Notify | 03BRL-CAD:ejno * 65655 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: recommit r65647 after sourceforge outage: 'write a CCONE2 if the CCONE1 internal radii are zero' |
| 14:01.23 | Notify | 03BRL-CAD:ejno * 65656 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: recommit r65657 after sourceforge outage: 'remove unnecessary try block' |
| 14:13.03 | *** join/#brlcad sofat_ (~sofat@202.164.45.212) |
| 14:19.45 | Notify | 03BRL-CAD:ejno * 65657 brlcad/trunk/src/conv/3dm/3dm-g.cpp: check argc to ensure that there are no excess arguments; free brep on exception; remove unused options |
| 14:21.11 | Notify | 03BRL-CAD:ejno * 65658 brlcad/trunk/src/conv/gcv/gcv.cpp: fix typo in comment |
| 14:23.55 | Notify | 03BRL-CAD:ejno * 65659 (brlcad/trunk/src/libgcv/gcv_test.c brlcad/trunk/src/libgcv/plugin.c): check for excess arguments; simplify loop |
| 14:26.26 | Notify | 03BRL-CAD:ejno * 65660 brlcad/trunk/src/libgcv/facetize.c: move BU_UNSETJUMP to correct location |
| 14:30.16 | Notify | 03BRL-CAD:ejno * 65661 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_read.c: return error rather than exiting on unexpected EOF; free all memory before returning |
| 14:33.05 | Notify | 03BRL-CAD:ejno * 65662 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: fix truncate_float(); refactoring |
| 14:36.54 | *** join/#brlcad shaina (~shaina@61.0.202.88) |
| 14:39.35 | Notify | 03BRL-CAD:ejno * 65663 (brlcad/trunk/src/librt/primitives/bot/gct_decimation/auxiliary/cc.h brlcad/trunk/src/librt/primitives/bot/gct_decimation/auxiliary/cpuconfig.h and 11 others): formatting; replace math3d.h macros with those from vmath.h; fix so that if tri_count/1024 == 0, use one thread |
| 14:44.52 | Notify | 03BRL-CAD:ejno * 65664 brlcad/trunk/src/librt/reduce.c: use direct comparisons when checking 0.0 <= reduction_level <= 1.0 |
| 14:47.06 | Notify | 03BRL-CAD:brlcad * 65665 brlcad/trunk/doc/docbook/presentations/en/brlcad-app-devel.xml: sub-bullet presentation cleanup made obvious by sofat's automatic rendering |
| 14:47.55 | *** join/#brlcad sofat_ (~sofat@101.208.64.209) |
| 15:00.27 | Notify | 03BRL-CAD:ejno * 65666 brlcad/trunk/src/librt/primitives/bot/decimate.c: use direct comparison for feature_size |
| 15:06.17 | *** join/#brlcad arno (~luca@host17-111-dynamic.4-87-r.retail.telecomitalia.it) |
| 15:21.27 | *** join/#brlcad libero (~luca@host129-20-dynamic.4-87-r.retail.telecomitalia.it) |
| 15:23.02 | Notify | 03BRL-CAD:ejno * 65667 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_read.c: close fpin on failure to open the plot file |
| 15:48.13 | Notify | 03BRL-CAD:starseeker * 65668 brlcad/trunk/TODO: Need to fix MGED clear command - giving Error: can't read "PRIV\(console\)": no such element in array |
| 15:55.40 | Notify | 03BRL-CAD:starseeker * 65669 (brlcad/trunk/src/libanalyze/CMakeLists.txt brlcad/trunk/src/libanalyze/raydiff.c): Begin refactoring of libanalyze raydiff pieces - these will be useful for other logic as well. |
| 16:07.18 | Notify | 03BRL-CAD:starseeker * 65670 (brlcad/trunk/src/other/openscenegraph/CMakeLists.txt brlcad/trunk/src/other/openscenegraph/src/CMakeLists.txt): Enable the building of osgQt - not quite sure this version of Qt/OSG integration will work with the latest Qt5, but enable what is available as a starting point. |
| 16:19.56 | Notify | 03BRL-CAD:starseeker * 65671 (brlcad/trunk/db/nist/CMakeLists.txt brlcad/trunk/db/nist/README): NIST has released a number of additional public domain NURBS CAD files - incorporate into build. The 7-10 assembly files are currenly too slow as STEP files, so they've been added as a single 3dm file which attemps to place them in assembly positions. |
| 16:27.48 | Notify | 03BRL-CAD:carlmoore * 65672 brlcad/trunk/TODO: fix a spelling in TODO |
| 16:40.42 | Notify | 03BRL-CAD:starseeker * 65673 brlcad/trunk/TODO: Start mapping local git commits back into trunk. Make a note to investigate CmakePushCheckState macros |
| 16:45.13 | Notify | 03BRL-CAD:starseeker * 65674 (brlcad/trunk/src/other/stepcode/CMakeLists.txt brlcad/trunk/src/other/stepcode/src/exp2cxx/CMakeLists.txt brlcad/trunk/src/other/stepcode/src/express/CMakeLists.txt): Don't do the fancy version trick when SCL is a subbuild - it causes problems with continual rebuilding with newer GCC compilers. |
| 16:48.07 | Notify | 03BRL-CAD:starseeker * 65675 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/raydiff.c brlcad/trunk/src/libanalyze/util.c): Move grazing elimination into util. |
| 16:48.51 | *** join/#brlcad bhollister2 (~brad@2601:647:cb02:7a00:f04d:35ac:f0ba:5880) |
| 16:52.53 | Notify | 03BRL-CAD:starseeker * 65676 (brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp =================================================================== and 479 others): Forgot to add this one |
| 16:53.31 | Notify | 03BRL-CAD Wiki:Shaina7837 * 9113 /wiki/User:Shainasabarwal/GSoC15/logs: /* 25 July */ |
| 16:54.15 | Notify | 03BRL-CAD:starseeker * 65677 (brlcad/trunk/src/libanalyze/CMakeLists.txt brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp): Convert util to C++ |
| 16:55.21 | Notify | 03BRL-CAD:starseeker * 65678 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/raydiff.c brlcad/trunk/src/libanalyze/util.cpp): Try to make the solid ray filter a bit more generic from a data type standpoint. |
| 16:56.29 | Notify | 03BRL-CAD:starseeker * 65679 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/raydiff.c brlcad/trunk/src/libanalyze/util.cpp): Inching slowly towards a generic analyze_gen_worker function |
| 16:57.37 | Notify | 03BRL-CAD:starseeker * 65680 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/raydiff.c): Another step towards a generic gen_worker |
| 16:59.26 | Notify | 03BRL-CAD:starseeker * 65681 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/raydiff.c brlcad/trunk/src/libanalyze/util.cpp): Make a universal libanalyze worker generator, with better CPU utilization characteristics. |
| 17:00.04 | Notify | 03BRL-CAD:starseeker * 65682 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/util.cpp): Start rework of get solid partitions function |
| 17:01.09 | Notify | 03BRL-CAD:starseeker * 65683 brlcad/trunk/src/libanalyze/util.cpp: more updating of the solid partitions func to the new approach |
| 17:01.59 | Notify | 03BRL-CAD:starseeker * 65684 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/tests/CMakeLists.txt brlcad/trunk/src/libanalyze/util.cpp): Get the solid partitions function printing out some info. |
| 17:02.42 | Notify | 03BRL-CAD:carlmoore * 65685 brlcad/trunk/HACKING: fix a spelling |
| 17:02.44 | Notify | 03BRL-CAD:starseeker * 65686 brlcad/trunk/src/libanalyze/util.cpp: Infinite loops are a bad thing... make sure they can't happen here. |
| 17:03.11 | *** join/#brlcad sofat_ (~sofat@202.164.45.204) |
| 17:03.46 | Notify | 03BRL-CAD:starseeker * 65687 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/raydiff.c): Fiddle with libanalyze rt prep - something funny going on here. |
| 17:04.45 | Notify | 03BRL-CAD:starseeker * 65688 brlcad/trunk/src/libanalyze/raydiff.c: Put some timers in for debugging gdiff performance |
| 17:05.28 | Notify | 03BRL-CAD:starseeker * 65689 brlcad/trunk/src/libanalyze/util.cpp: Start working on bookkeeping of hits and overlaps. |
| 17:06.23 | Notify | 03BRL-CAD:starseeker * 65690 brlcad/trunk/src/libged/shape_recognition.cpp: Start thinking about how we're going to handle managing using the raytracer to augment the comb definition from the libged side of things. |
| 17:07.25 | Notify | 03BRL-CAD:starseeker * 65691 (brlcad/trunk/include/brep.h brlcad/trunk/src/libanalyze/analyze_private.h and 4 others): Checkpoint work towards using raytracing to do subtraction evaluations. |
| 17:08.04 | Notify | 03BRL-CAD:starseeker * 65692 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/util.cpp): More work on solid partition collecting |
| 17:09.09 | Notify | 03BRL-CAD:starseeker * 65693 brlcad/trunk/src/libanalyze/util.cpp: Get the filtered results into the results bu_ptbl. |
| 17:10.01 | Notify | 03BRL-CAD:starseeker * 65694 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp brlcad/trunk/src/libanalyze/util.cpp): Start thinking about how the raytracing and the partition checking will interact |
| 17:10.40 | Notify | 03BRL-CAD:starseeker * 65695 (brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp brlcad/trunk/src/libged/shape_recognition.cpp): checkpoint |
| 17:11.34 | Notify | 03BRL-CAD:starseeker * 65696 (brlcad/trunk/include/analyze.h brlcad/trunk/src/libanalyze/CMakeLists.txt and 3 others): Stub in actual functions to do subtraction evalutions. Quite a bit of logic needed here. |
| 17:12.26 | Notify | 03BRL-CAD:starseeker * 65697 (brlcad/trunk/include/brep.h brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp brlcad/trunk/src/libbrep/shape_recognition.h): More work on preparing for ray subtraction analysis. Realized the subbrep_bbox function actually already does what we need for this... |
| 17:15.42 | Notify | 03BRL-CAD:starseeker * 65698 brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp: Checkpoint of most recent git changes. |
| 17:16.33 | starseeker | phew |
| 17:20.20 | *** join/#brlcad shaina (~shaina@117.214.243.253) |
| 17:25.03 | *** join/#brlcad Gurwinder (75dc94ea@gateway/web/freenode/ip.117.220.148.234) |
| 17:25.47 | *** join/#brlcad sofat (~sofat@202.164.45.204) |
| 17:28.24 | *** join/#brlcad gurwinder_ (~chatzilla@117.220.148.234) |
| 17:28.53 | brlcad | starseeker: thanks -- looks like we're good to go |
| 17:29.35 | brlcad | lee has three on the ert branch, but otherwise back on track |
| 17:29.53 | sofat | brlcad, hello |
| 17:30.13 | brlcad | sofat: all done with everything? |
| 17:30.28 | brlcad | or almost |
| 17:31.00 | ih8sum3r | brlcad: I have dropped an email to you. Please check once. |
| 17:31.25 | gurwinder_ | brlcad: I'm working on ell1 ellg, I think they comes under ell. And tec under tgc. Right? |
| 17:31.30 | sofat | I need some help regarding google custom search. |
| 17:33.45 | brlcad | gurwinder_: that sounds correct, yes -- though I'm not sure those are actually distinguishly different types |
| 17:35.27 | gurwinder_ | brlcad: Thanks :). I just want to confirm as I also check them using mged. Thanks :) |
| 17:35.34 | brlcad | i.e., if you open a .g file ...there is no such thing as a tec/ell1/ellg |
| 17:36.08 | brlcad | they only are an option on creation via the in/make commands as they take different parameters |
| 17:36.29 | brlcad | basically can think of them like alternative constructors, like C++ classes |
| 17:37.14 | gurwinder_ | yes |
| 17:37.23 | brlcad | so ... you may be done already |
| 17:37.48 | gurwinder_ | brlcad: yes I have done with them. |
| 17:39.10 | gurwinder_ | brlcad: As by your priority order next is half? Right? |
| 17:39.33 | brlcad | I gave you the list, your responsibility to track it ;) |
| 17:40.07 | brlcad | if you don't have the list, you should pull the IRC log |
| 17:40.24 | gurwinder_ | Yes, I have that list in my system. |
| 17:40.43 | *** join/#brlcad sofat (~sofat@202.164.45.204) |
| 17:40.45 | gurwinder_ | So I'm going to work on that list |
| 17:40.49 | gurwinder_ | :) |
| 17:41.15 | brlcad | ih8sum3r: I'd like to see your work set up running somewhere before proceeding differently |
| 17:43.08 | *** join/#brlcad konrado (~konro@41.205.22.7) |
| 17:43.20 | ih8sum3r | You mean production ready thing or front-end and back-end merged branches? Or Both. |
| 17:43.31 | *** join/#brlcad sofat_ (~sofat@202.164.45.204) |
| 17:43.32 | brlcad | ih8sum3r: so if you have the VM working, either make the web server available somewhere or make the disk image available |
| 17:44.03 | brlcad | i mean your work |
| 17:44.31 | sofat_ | I also update the language work, presentation work, and working on google custom search. |
| 17:44.34 | brlcad | the merged mess would be useful to see in comparison, but need to see either a before or after for that to matter much |
| 17:44.49 | brlcad | sofat_: url? the ones I'm testing no longer seem to be there |
| 17:45.50 | sofat_ | <PROTECTED> |
| 17:45.56 | brlcad | sofat_: to be clear, you should be working on google custom search specific to the documentation only, not the entire website |
| 17:46.23 | sofat_ | <PROTECTED> |
| 17:47.08 | sofat_ | this is presentations links :- http://202.164.53.122/wordpress/presentations/en/brlcad-app-devel_2.html#/ |
| 17:47.28 | sofat_ | http://202.164.53.122/wordpress/presentations/en/intro-to-tcltk_2.html#/ |
| 17:47.31 | brlcad | sofat_: what did you change?! ... google translate is working now :) |
| 17:47.48 | ih8sum3r | brlcad: I'll try to make it available somewhere, the size of image is to large (around 3-4GB) so it will take bit time. Report you asap. |
| 17:48.19 | brlcad | ih8sum3r: why is it that big? |
| 17:48.21 | sofat_ | I am made some changes in google translator plugin code. |
| 17:48.44 | brlcad | sofat_: and those changes were? ... can you explain the fix? |
| 17:48.57 | sofat_ | yes i explain. |
| 17:50.11 | sofat_ | you send some links. regarding this work . in these links have some code. so then use this code. |
| 17:51.08 | sofat_ | but this code not work on your side , and gave the error . so I now what i do. |
| 17:51.32 | ih8sum3r | brlcad: This is the size of .vdi file let me check after converting it into .vmdk. Above I wrote .vdi file size. |
| 17:52.48 | brlcad | sofat_: when I provide links to code, that is not ever direction to simply use that code -- it's to understand possible solutions to a given problem, related information |
| 17:53.11 | brlcad | ih8sum3r: I know it's the size of the vdi file -- my question is why is it that big :) |
| 17:53.16 | sofat_ | i Have google translator plugin which i am used before this work , because last time you said " when you convert the style of languages then it stop the working before this its working on my side " so that's means I goging to update the code of plugin instead using other code now I online update the layout os plugin and it working . |
| 17:53.45 | sofat_ | s/goging/going |
| 17:54.05 | sofat_ | s/online/only |
| 17:54.12 | sofat_ | s/os/of |
| 17:54.16 | brlcad | back up ... |
| 17:54.21 | ih8sum3r | brlcad: I installed the required packages side by side and also did the updates after that it shows me this much size. |
| 17:54.34 | brlcad | "but this code not work on your side , and gave the error . so I now what i do." ... what did you do? what was the error? |
| 17:54.42 | brlcad | what was the fix? |
| 17:55.24 | sofat_ | error is library which i used its old version . |
| 17:55.24 | brlcad | ih8sum3r: if you do a df -k inside the vm, what does it report being in use? |
| 17:55.37 | brlcad | sofat_: which library? |
| 17:57.08 | sofat_ | which is using for google translator. |
| 17:57.28 | brlcad | you're not being specific |
| 17:57.35 | brlcad | give me a name or a url or something |
| 17:57.52 | brlcad | is it code you wrote? |
| 17:57.59 | brlcad | *completely* |
| 17:58.17 | brlcad | or code that calls a library someone else wrote? |
| 18:00.50 | ih8sum3r | brlcad: Here is the output : http://pasteboard.co/2hccOlfF.png |
| 18:02.07 | sofat_ | there is plugin code |
| 18:02.08 | sofat_ | http://202.164.53.122/wordpress/wp-content/plugins/google-language-translator/ |
| 18:02.37 | sofat_ | I only made the changes in layout because this plugin already works |
| 18:03.26 | sofat_ | I only update this file google-language-translator.php |
| 18:08.35 | sofat_ | brlcad, please check presentation work and tell changes. |
| 18:13.28 | brlcad | ih8sum3r: what is that df telling you? |
| 18:15.29 | *** join/#brlcad konrado (~konro@41.205.22.53) |
| 18:16.33 | sofat_ | brlcad, I facing problem with google custom search it is not working with my docs means its not search these docs. |
| 18:16.48 | sofat_ | I also upload the sitemap on webmaster tools |
| 18:16.54 | brlcad | sofat_: okay, so you changed it from the code copy-pasted from StackOverflow with the official wordpress google-language-translator plugin |
| 18:17.02 | sofat_ | yes |
| 18:17.21 | brlcad | you should have started by saying that :) |
| 18:17.46 | sofat_ | so this is not working properly |
| 18:17.48 | ih8sum3r | 34% used for home and 19 |
| 18:17.51 | ih8sum3r | % for boot |
| 18:18.00 | brlcad | so effectively, we don't know why it was broken and didn't directly fix the error, but you switched it to a plugin where it is working |
| 18:18.06 | ih8sum3r | I am right. This is what I can see. |
| 18:18.50 | brlcad | ih8sum3r: percentage doesn't matter .. the question is surrounding how much disk space is in use and why that much :) |
| 18:18.54 | sofat_ | problem is that which error you show me I solve this error (javascript ) |
| 18:19.09 | brlcad | ih8sum3r: so how much is in use within the disk image? |
| 18:19.19 | sofat_ | after that its not working |
| 18:19.53 | brlcad | sofat_: I don't understand -- are you saying it no longer works for you? |
| 18:19.55 | sofat_ | so then you told me your old part is working fine then i switch to old and made some changes in this only layout changes |
| 18:19.59 | sofat_ | yes |
| 18:21.10 | brlcad | the current version does not work for you? |
| 18:21.11 | sofat_ | I am saying which error you send me in image on mail. I solve this error but after that its not work on your side. |
| 18:22.19 | brlcad | problems are only solved when it is working correctly for everyone |
| 18:22.27 | brlcad | "solved" is not the right word |
| 18:22.29 | sofat_ | I think you not understand |
| 18:22.44 | ih8sum3r | 6.6G is in use + 42MB. I think I have done something wrong while assigning memeory space. Total size is of 21G. |
| 18:22.55 | sofat_ | ok i explain again . |
| 18:23.05 | ih8sum3r | On which 6.6G is in use. |
| 18:23.54 | brlcad | ih8sum3r: right, about 6.6 GB in use ... and that's obviously being compressed if the vdi/vmdk is 3-4 GB |
| 18:24.19 | brlcad | sofat_: what is the purpose of the explanation? |
| 18:24.50 | sofat_ | how i solve this problem |
| 18:25.26 | brlcad | ih8sum3r: so the question of why is the vdi 3-4 GB is because the disk data is 6.5 GB of data ... so then the NEW question is why is there 6.5 GB being used in the image -- where is most of that space going? |
| 18:25.57 | brlcad | sofat_: before you explain again, then ... is it working for you now? |
| 18:26.05 | brlcad | because if it's not, then it's not solved |
| 18:26.10 | sofat_ | yes |
| 18:26.15 | sofat_ | its working now |
| 18:26.21 | brlcad | okay .. you just told me that it was not working for you :) |
| 18:26.28 | ih8sum3r | brlcad: Questions seems intresting let me find answer for this. |
| 18:26.53 | sofat_ | so now on google custom search so i need some help |
| 18:27.22 | sofat_ | I upload my sitemap on webmaster tool but after that it could not search my docs |
| 18:27.41 | brlcad | ih8sum3r: if you're willing to wait a long while (hours), something like this will tell you the biggest folders: find / -type d -exec du -ks {} \; | sort -n | tee dir_sizes.txt |
| 18:27.48 | sofat_ | i set this url for search 202.164.53.122/wordpress |
| 18:30.25 | sofat_ | and also check my presentation work and tell me about changes |
| 18:31.15 | brlcad | sofat_: before changing subject, I want to be clear about something -- namely that you did not learn why it google translate wasn't working |
| 18:31.35 | brlcad | with the prior solution |
| 18:33.11 | brlcad | you got it working again by reverting to the WP plugin, which is fine -- but in responding to my question of "what was wrong?", the answer should have been "I don't know. I worked around the problem by using the plugin, which worked." |
| 18:33.31 | brlcad | I say that only because it took almost an hour to get that understanding |
| 18:34.19 | sofat_ | <PROTECTED> |
| 18:34.42 | sofat_ | because after removing all error its not working |
| 18:34.54 | brlcad | that's fine |
| 18:35.01 | sofat_ | so then I again switch to plugin and customize it |
| 18:35.15 | brlcad | but that's the answer, not that it's solved ;) |
| 18:35.21 | brlcad | solved means something else |
| 18:35.29 | sofat_ | hmm |
| 18:35.31 | sofat_ | :-( |
| 18:35.52 | brlcad | this is just a language issue, not a quality of work question |
| 18:35.58 | brlcad | you got it working, which is great |
| 18:36.45 | sofat_ | okay |
| 18:37.07 | brlcad | there are still some changes I'd like to see to translation but they are minor |
| 18:37.24 | sofat_ | ok tell me |
| 18:37.58 | brlcad | later, lets move on to the presentations |
| 18:38.21 | sofat_ | ok |
| 18:38.50 | brlcad | they look much better now |
| 18:38.56 | sofat_ | okay |
| 18:39.01 | brlcad | you did not need to match the style and blue color, but that's a stylesheet issue we can fix |
| 18:39.15 | brlcad | the issues I mentioned by e-mail were structural xml transformation problems |
| 18:39.28 | brlcad | there is still at least one issue I see, images are duplicated |
| 18:39.30 | sofat_ | what please explain |
| 18:40.30 | brlcad | ah, you fixed it! never mind |
| 18:40.44 | brlcad | I was looking at intro-to-tcltk.html, not intro-to-tcltk_2.html |
| 18:40.53 | sofat_ | hahah |
| 18:41.12 | brlcad | er, hrm |
| 18:41.27 | brlcad | no, the images are still duplicated :) |
| 18:41.46 | brlcad | neat that you have the navigation going down on them though |
| 18:41.48 | sofat_ | this is in xml document also |
| 18:41.54 | brlcad | yes it is |
| 18:42.05 | brlcad | but they are just one image |
| 18:42.09 | brlcad | one mediaobject |
| 18:42.19 | sofat_ | ok no problem its not big problem |
| 18:42.29 | sofat_ | ok |
| 18:42.30 | brlcad | different images for different output formats (fo vs html) |
| 18:42.52 | sofat_ | ok |
| 18:43.35 | brlcad | when you're dealing with images, you want to have web resolution (e.g., 1024x768) and print resolution (e.g., 8192x6144) |
| 18:44.08 | brlcad | they happen to be the same for that presentation, but they should be different size images |
| 18:44.15 | sofat_ | hmm |
| 18:44.23 | brlcad | and only one should get used |
| 18:45.14 | brlcad | since it's web, you want the role=html mediaobject imageojects only |
| 18:45.32 | sofat_ | ok |
| 18:45.33 | brlcad | if it were for pdf, you'd want the role=fo version |
| 18:46.27 | sofat_ | ok |
| 18:47.19 | brlcad | the color theme should match the main site |
| 18:48.05 | sofat_ | ok |
| 18:48.10 | sofat_ | no problem |
| 18:48.14 | sofat_ | next |
| 18:48.17 | brlcad | the rest of the problems I see are problems in the original xml |
| 18:48.32 | brlcad | yes, so that's good |
| 18:48.51 | brlcad | is it possible to make the link be more interesting? |
| 18:49.03 | brlcad | the link to the presentation from the presentation overview page |
| 18:49.38 | sofat_ | hmm yes i try to do some interesting |
| 18:49.52 | brlcad | i'm talking about the "Read More" |
| 18:50.05 | sofat_ | so now next changes for language translator . |
| 18:50.18 | brlcad | wait, must make sure we understand each other :) |
| 18:50.21 | sofat_ | yes i will change change this |
| 18:50.27 | brlcad | I'm talking about this page: http://202.164.53.122/wordpress/presentations/en/intro_intro-to-tcltk.php |
| 18:50.34 | sofat_ | I know that |
| 18:51.00 | brlcad | I think the fix requires a change in the repo |
| 18:51.09 | sofat_ | if explain some thing interesting ? |
| 18:51.24 | sofat_ | which type you want for this |
| 18:51.25 | brlcad | that there needs to be an overview xml file for each presentation separate from the presentation itself |
| 18:51.34 | sofat_ | yes |
| 18:51.48 | brlcad | probably an article |
| 18:52.08 | sofat_ | yes |
| 18:52.23 | brlcad | and that overview page would maybe have a small image preview of the presentation title page |
| 18:52.43 | brlcad | the preview image and "Read More" would both link to the presentation |
| 18:52.54 | brlcad | not sure how to embed that into the article |
| 18:53.30 | sofat_ | ok |
| 18:53.39 | brlcad | let me add a simple overview page for one of those presentations and you can try to figure out how to link them? |
| 18:53.57 | ih8sum3r | brlcad: I used the command you gave me it gives to long output. I used another command and it shows me the following output: http://pasteboard.co/2hfzibef.png. Still there is a mystery that where rest of the space is being used. |
| 18:54.36 | brlcad | sofat_: oh, I take that back -- we are working in docbook land, so maybe the overview and the presentation can be combined sort of like how it's working now |
| 18:55.04 | brlcad | sofat_: we just need to separate out some section in the xml file to be the overview |
| 18:55.12 | brlcad | not the first page |
| 18:55.25 | brlcad | and not include that overview in the presentation itself |
| 18:55.39 | sofat_ | means i can't understand now please explain in simple english |
| 18:56.35 | brlcad | ih8sum3r: that implies you used a 5 GB linux image? |
| 18:56.52 | brlcad | sofat_: okay |
| 18:57.11 | brlcad | sofat_: specific example, consider doc/docbook/presentations/en/intro-to-tcltk.xml |
| 18:57.28 | sofat_ | <PROTECTED> |
| 18:57.36 | brlcad | right now, you use that to make http://202.164.53.122/wordpress/presentations/en/intro_intro-to-tcltk.php |
| 18:57.51 | sofat_ | yes |
| 18:57.54 | brlcad | and http://202.164.53.122/wordpress/presentations/en/intro_intro-to-tcltk_2.html |
| 18:58.12 | sofat_ | yes |
| 18:59.04 | ih8sum3r | brlcad: I used iso file (approx. size 625MB) and maybe after installing it expands to this much size. |
| 18:59.25 | brlcad | that's good, that works -- the only problem is that the overview page (intro_intro-to-tcltk.php) needs an introduction and preview of the presentation BUT we do not want that intro in the presentation itself (intro_intro-to-tcltk_2.html) |
| 18:59.51 | brlcad | ih8sum3r: that's where knowing what that 5GB is would be helpful |
| 18:59.56 | brlcad | did the command I gave you complete? |
| 19:00.09 | ih8sum3r | Yes completed. |
| 19:00.17 | brlcad | okay, so just run less on the file |
| 19:00.25 | brlcad | less dir_sizes.txt |
| 19:00.43 | brlcad | (and "man tee" since you apparently don't know what that did) ;) |
| 19:01.26 | brlcad | copy-paste the top 100 or so dirs into a text pastebin |
| 19:01.27 | sofat_ | for that i need to update your xml docs separate the intro part from presentation i am right ? |
| 19:01.38 | brlcad | sofat_: right! |
| 19:01.54 | sofat_ | okay now for language translator ? |
| 19:02.07 | brlcad | sofat_: I'm not sure exactly how to do that, but hopefully you can figure it out ;) |
| 19:02.26 | sofat_ | ok |
| 19:02.38 | brlcad | okay, last issue -- I assume you mean google search not translation? |
| 19:02.47 | sofat_ | ok |
| 19:03.15 | sofat_ | both |
| 19:03.27 | brlcad | okay, so translation first -- what? |
| 19:04.02 | brlcad | my earlier comment about a couple more changes? |
| 19:04.04 | sofat_ | you also told me you need some changes in translation so which changes you want? |
| 19:04.08 | brlcad | okay, yes |
| 19:04.19 | brlcad | couple minor issues |
| 19:04.24 | sofat_ | tell me |
| 19:04.31 | brlcad | getting there :) |
| 19:05.02 | sofat_ | hmm ? |
| 19:05.16 | brlcad | it means be patient, I'm trying to type :) |
| 19:05.23 | brlcad | the language list is all in english |
| 19:05.32 | brlcad | that's not very helpful if you don't speak english... |
| 19:06.10 | sofat_ | okay |
| 19:06.56 | Notify | 03BRL-CAD Wiki:Bhollister * 9114 /wiki/User:Bhollister/DevLogJuly2015: |
| 19:07.20 | brlcad | the languages should all be with native character set and spelling |
| 19:07.53 | brlcad | e.g., ?????? instead of hindi |
| 19:07.54 | sofat_ | means ? |
| 19:08.37 | brlcad | e.g., http://piwigo.org/screenshots/piwigo-2.2-language_switch.png |
| 19:09.27 | brlcad | I also think the flag on the left of the name will work better for layout, just like in that image |
| 19:09.44 | sofat_ | ok |
| 19:10.00 | brlcad | which icon set are you using? |
| 19:10.45 | sofat_ | this plugin fetch the icons automatically . |
| 19:10.55 | brlcad | from where? |
| 19:11.23 | sofat_ | form server |
| 19:11.31 | brlcad | of course |
| 19:11.40 | sofat_ | i don't know which server |
| 19:11.40 | brlcad | you're not being specific |
| 19:12.16 | brlcad | we need to know which server, what license of use they are under |
| 19:12.24 | sofat_ | ok |
| 19:13.56 | sofat_ | okay you want the language not in english they must ve in original name like hindi is written in hindi language not english i am right ? |
| 19:14.07 | sofat_ | s/ve/be |
| 19:14.50 | brlcad | the other issue is minor, but surprising ... when the page is loaded, it first displays all the flags while they are loaded and THEN it hides them ... can you make them hidden first? |
| 19:15.07 | brlcad | right, each language written in that language |
| 19:15.14 | brlcad | and flag on left |
| 19:15.17 | sofat_ | ok |
| 19:15.34 | sofat_ | yes i use hidden first |
| 19:16.21 | brlcad | also, when the language list is expanded, the "Move to Top" disappears |
| 19:17.26 | *** join/#brlcad vasc (~vasc@bl12-167-71.dsl.telepac.pt) |
| 19:17.53 | sofat_ | hmm |
| 19:18.07 | vasc | kewl. the svn is up again. |
| 19:18.34 | sofat_ | ok i will do this |
| 19:19.10 | sofat_ | now last one is google custom search this is not working |
| 19:19.11 | brlcad | sofat_: the list of languages displays before it's hidden for me, both with chrome and safari |
| 19:19.17 | brlcad | see http://snag.gy/Or9Jt.jpg |
| 19:19.38 | brlcad | it only displays for about 0.5 seconds |
| 19:19.40 | vasc | hm cmake isn't working |
| 19:20.15 | sofat_ | you need to scroll down |
| 19:20.33 | brlcad | sofat_: what do you mean? |
| 19:21.02 | sofat_ | means scroll down the page and then you get other language which not show you |
| 19:21.18 | vasc | CMake Error at CMakeLists.txt:154 (_message): |
| 19:21.19 | vasc | <PROTECTED> |
| 19:21.19 | vasc | <PROTECTED> |
| 19:21.21 | brlcad | no, you misunderstand |
| 19:21.51 | sofat_ | hmm |
| 19:21.52 | brlcad | vasc: hm, that's easy to fix (just remove that file from CMakeLists.txt) -- almost certainly related to recent changes by starseeker |
| 19:22.02 | brlcad | sofat_: that image is showing you the page loading |
| 19:22.11 | sofat_ | hmm |
| 19:22.13 | sofat_ | i see |
| 19:22.18 | brlcad | the list of languages should NOT be displayed at all |
| 19:22.24 | brlcad | it shows the list, and then it hides |
| 19:22.33 | brlcad | for about 0.2-0.5 seconds |
| 19:23.12 | sofat_ | yes then click on additional language |
| 19:23.24 | sofat_ | link and then its show you |
| 19:23.27 | brlcad | right |
| 19:23.31 | brlcad | that part is fine |
| 19:23.37 | sofat_ | hmm |
| 19:24.04 | brlcad | the problem is that is first draws the whole list and THEN hides |
| 19:24.11 | brlcad | instead of drawing the list hidden |
| 19:24.18 | sofat_ | ok so what you want there ? |
| 19:24.46 | brlcad | to not show the list of languages until the additional languages or arrow are selected |
| 19:25.24 | sofat_ | ok |
| 19:25.33 | sofat_ | i will check this issue |
| 19:25.39 | brlcad | please don't say ok if you don't understand :) |
| 19:25.51 | brlcad | do you understand the issue? |
| 19:27.21 | sofat_ | yes you said on loading time this part not show(meas not work like show/hide). when user click on additional language the n it wi ll sho w to user |
| 19:27.41 | sofat_ | <PROTECTED> |
| 19:28.15 | brlcad | that doesn't sound right... |
| 19:28.55 | sofat_ | hmm ? |
| 19:28.56 | brlcad | the page once loaded is working okay NOW ... |
| 19:29.11 | brlcad | clicking additional languages works |
| 19:29.21 | brlcad | hiding additional languages works |
| 19:29.38 | brlcad | the problem (and it's minor) is ONLY during page loading |
| 19:30.38 | sofat_ | hmm |
| 19:30.38 | brlcad | while it's loading the page, it displays the EXPANDED list and THEN it hides the list (during loading) |
| 19:30.38 | sofat_ | means when page loading you don't want language shoe to 0.5 second and then gone |
| 19:30.38 | brlcad | and it only does it the first time the page is loaded |
| 19:30.38 | sofat_ | s/shoe/show |
| 19:30.41 | brlcad | the second time it doesn't show |
| 19:30.47 | sofat_ | ok |
| 19:31.08 | brlcad | right, it shouldn't show the list during loading (if it can be easily fixed) |
| 19:31.22 | sofat_ | means i need some state store work like menu |
| 19:31.34 | brlcad | if it cannot be easily fixed, don't worry about it -- but try, maybe 1-3 hours at most |
| 19:31.42 | sofat_ | <PROTECTED> |
| 19:31.48 | sofat_ | <PROTECTED> |
| 19:31.57 | sofat_ | <PROTECTED> |
| 19:32.50 | brlcad | eh, it should not require a cookie! |
| 19:32.50 | brlcad | this is a resource loading issue |
| 19:32.50 | sofat_ | ok |
| 19:32.50 | brlcad | probably jquery-related |
| 19:32.54 | sofat_ | I will check this issue |
| 19:33.16 | ih8sum3r | brlcad: This is what I get top 100 : https://gist.github.com/anonymous/c0b7a6a5dfd117b3794b |
| 19:33.31 | sofat_ | so now move further next problem with google search |
| 19:33.50 | brlcad | sofat: sounds like this issue: http://stackoverflow.com/questions/2801032/jquery-hide-elements-before-they-rendered-best-practice |
| 19:34.08 | vasc | hm |
| 19:34.31 | brlcad | setting initial css to display:none and then display may work |
| 19:34.52 | brlcad | ih8sum3r: heh, that's the bottom 100 :) |
| 19:34.54 | sofat_ | ok |
| 19:36.00 | brlcad | ih8sum3r: or rather, you're looking at the top of the file and you need to reverse sort the list or look at the bottom |
| 19:36.00 | brlcad | sort -r file | less |
| 19:36.00 | bhollister | is there a way to get at 'view_state' from within libged? |
| 19:36.52 | vasc | did you guys change the compiler flags or something? the compiler is being more anal than usual. |
| 19:36.52 | sofat_ | so need some help in google search I am using this link to search my document content 202.164.53.122/wordpress/ and i also upload the sitemap in google webmaster tools but its not working . you have any solution ? |
| 19:36.52 | brlcad | bhollister: no, that's an mged construct |
| 19:36.52 | brlcad | bhollister: what do you need? |
| 19:37.26 | brlcad | vasc: not that I'm aware of, but it's supposed to be VERY anal to be compliant with our code standard |
| 19:38.53 | brlcad | vasc: depending on what state your checkout was in, you may want to obtain a fresh checkout and reapply your changes |
| 19:39.05 | vasc | i didn't get any 'M' or 'G' file hits so it should be ok in that regard |
| 19:39.06 | brlcad | need to get you working on a branch now that svn is back up... remind me later this week if I don't get to your patches beforehand |
| 19:39.12 | vasc | i mean G |
| 19:39.19 | brlcad | no, that's the point |
| 19:39.28 | vasc | ok |
| 19:39.41 | brlcad | you're not going to because the repo was ripped out from under that checkout and restored in a different state |
| 19:41.38 | brlcad | so locally you are consistent but not with the server (in theory, it'll eventually give you a checksum error if/when you ever tried to commit) |
| 19:42.18 | vasc | so i should download everything again? |
| 19:42.27 | brlcad | but it essentially means the checkout cannot be fully trusted if you ran svn update after the Wed when the filesystem corrupted |
| 19:42.40 | brlcad | for your work, I would recommend it yet |
| 19:42.45 | brlcad | s/yet/yes/ |
| 19:42.56 | vasc | when we do the branch i'll just do it from a clean slate then |
| 19:43.01 | vasc | and apply patches on it |
| 19:43.23 | brlcad | might not make a difference, but can't say for certain that there's not a stateful build issue lurking |
| 19:44.22 | vasc | i'm just removing some consts here and there. if its important to keep the consts i'll rewrite this differently later. |
| 19:44.46 | vasc | 3 lines |
| 19:45.19 | sofat_ | brlcad, need some in google search please help me in that . |
| 19:46.17 | sofat_ | need some help |
| 19:47.07 | vasc | the most important patch to apply is the sph patch. it fixes a compilation error in current svn. |
| 19:47.24 | vasc | you can also apply the arb8, ehy patch fine |
| 19:47.56 | vasc | don't apply the grid patches because they change the way the rendering is done so the output ain't the same |
| 19:48.10 | vasc | it uses a simplified rendering engine |
| 19:48.36 | vasc | which is WIP |
| 19:49.17 | vasc | brlcad |
| 19:50.40 | vasc | well the svn compiled with the changes to the CMakeLists.txt |
| 19:51.16 | vasc | Index: src/libanalyze/tests/CMakeLists.txt |
| 19:51.16 | vasc | =================================================================== |
| 19:51.16 | vasc | --- src/libanalyze/tests/CMakeLists.txt(revision 65698) |
| 19:51.16 | vasc | +++ src/libanalyze/tests/CMakeLists.txt(working copy) |
| 19:51.16 | vasc | @@ -1,6 +1,6 @@ |
| 19:51.17 | vasc | <PROTECTED> |
| 19:51.19 | vasc | <PROTECTED> |
| 19:51.21 | vasc | -BRLCAD_ADDEXEC(tester_sp solid_partitions.c "libanalyze;libbu" NO_INSTALL) |
| 19:51.25 | vasc | +#BRLCAD_ADDEXEC(tester_sp solid_partitions.c "libanalyze;libbu" NO_INSTALL) |
| 19:59.32 | ih8sum3r | brlcad: Here it is : https://gist.github.com/anonymous/a182acb4b8e0438e89bf |
| 20:01.43 | brlcad | ih8sum3r: good lordy... what's in that db? |
| 20:03.03 | ih8sum3r | I think these are collections, OGV. |
| 20:03.07 | brlcad | vasc: best practice is obviously to propagate const, not remove them, but it obviously depends what you're doing |
| 20:03.50 | brlcad | if someone went through the effort to mark something const, it is 'usually' intentional |
| 20:04.10 | brlcad | which 3 lines? |
| 20:05.01 | brlcad | sofat_: for search, we need a different URL base so you can limit it to just documentation |
| 20:05.13 | sofat_ | means |
| 20:05.14 | brlcad | when it comes time to publish, we will not be exposing "wordpress" |
| 20:06.03 | brlcad | sofat_: means right now you're limiting it to 202.164.53.122/wordpress/ and this is NOT limiting the search to just documentation |
| 20:06.20 | brlcad | it's desirable to have a search box that is limited to documentation |
| 20:06.44 | brlcad | there will be a different main site search that will search everything |
| 20:06.45 | ih8sum3r | What I can see in that db folder there are binary files like prealloc.0, meteor.0, meteor.ns etc. which most probably are the collections. |
| 20:07.12 | brlcad | ih8sum3r: I don't know what collections means in this context |
| 20:07.27 | sofat_ | ok now means i need full domain for this like ww.abcd.com |
| 20:07.29 | brlcad | 3.2 GB of data is a lot of data |
| 20:07.41 | sofat_ | www.abcd.com |
| 20:07.44 | brlcad | sofat_: it'll be on brlcad.org |
| 20:07.51 | sofat_ | ok |
| 20:07.57 | brlcad | you just have to make sure the logic translates when it's moved |
| 20:08.15 | brlcad | that the logic still works |
| 20:08.21 | sofat_ | ok |
| 20:08.48 | ih8sum3r | What say should I try installing one more time from scratch just to cross-check whether output again will be of 3.5G or less. |
| 20:08.55 | sofat_ | ok |
| 20:09.42 | brlcad | so our two prime candidates will be to use something like docs.brlcad.org or brlcad.org/docs/ |
| 20:10.07 | brlcad | ih8sum3r: sure, or use mongodb tools to inspect what is in the database |
| 20:10.20 | brlcad | that's a lot of data to be unaccounted for |
| 20:10.30 | vasc | i can keep the const but now i just wanna get something working. it won't be in the final version. |
| 20:11.05 | vasc | the weird thing is it compiled before |
| 20:11.09 | vasc | so i guess it wasn't const |
| 20:11.27 | ih8sum3r | brlcad: Okay, on it. Will report you asap. |
| 20:11.51 | brlcad | "i just wanna get something working" <-- do you know just how many times I've heard that over the past two years only to find that was effectively the final state? :) |
| 20:12.11 | brlcad | almost every time ;) |
| 20:12.14 | vasc | i never submit the initial version of anything to anyone |
| 20:12.25 | vasc | the patches are always 3rd gen code |
| 20:12.28 | brlcad | well you have a hard submission deadline coming up really fast :) |
| 20:12.39 | brlcad | 3 weeks remaining? |
| 20:12.52 | vasc | i thought it was more than that |
| 20:12.56 | vasc | ah |
| 20:13.22 | brlcad | don't remember the exact date but it is soon |
| 20:13.27 | vasc | 24 aug |
| 20:13.50 | brlcad | okay, and that's after the suggested pencil's down date which is the week prior |
| 20:14.00 | vasc | oh oh crap |
| 20:14.13 | brlcad | you can keep coding all the way up to the deadline |
| 20:14.15 | vasc | yeah i didn't see that one |
| 20:14.25 | brlcad | it's just a suggestion to motivate procrastinators |
| 20:14.40 | Notify | 03BRL-CAD:carlmoore * 65699 brlcad/trunk/src/util/bwcrop.c: fix subscript to eliminate some memory-fault errors |
| 20:14.59 | brlcad | heck you can keep coding after the deadline, but the evaluation is only on code up to the deadline date |
| 20:15.13 | vasc | well this is like 1-2 weeks behind schedule |
| 20:15.23 | vasc | so i think in the worst case i might like drop the bot code |
| 20:15.33 | brlcad | drop it now |
| 20:15.54 | vasc | but i want to do the full rendering pipeline. even if i only get it working 100% in opencl after the deadline |
| 20:16.09 | brlcad | really, it's probably going to be more valuable to start wrapping up in about 1-1.5 weeks time |
| 20:16.33 | vasc | right now we got a bunch of primitives implemented and a simplified rendering pipeline with grids |
| 20:16.50 | brlcad | getting what you have in some useful state either as a clear path forward or as a working demo or bits of functions hooked back into the production code |
| 20:16.50 | vasc | but it still does those expensive calls to the gpu all the time |
| 20:17.04 | brlcad | and docs... writing up where you got to and what's next |
| 20:17.04 | vasc | it already is a working demo |
| 20:17.08 | vasc | but its slow |
| 20:17.33 | vasc | i want the whole pipeline in opencl so don't have all this call overhead |
| 20:17.48 | Notify | 03BRL-CAD:starseeker * 65700 (brlcad/trunk/src/libanalyze/tests/solid_partitions.c =================================================================== and 95 others): Forgot to svn add this file |
| 20:18.01 | brlcad | nods |
| 20:18.01 | vasc | there it is |
| 20:18.52 | brlcad | it's not necessarily your case as you have a different class of open source experience, but historically.. |
| 20:19.30 | brlcad | gsoc research projects tend to die shortly after gsoc ends despite authors best intentions |
| 20:19.53 | vasc | well |
| 20:20.09 | brlcad | hence the focus and desire to scavenge whatever small or big piece of the effort into progress |
| 20:20.21 | vasc | its possible to retrofit the grid accel to work with the current way the code is structured. but its gonna be a step backwards from what i have now. |
| 20:20.41 | vasc | i think in that case its better to put that in the branch |
| 20:20.47 | brlcad | basically coding deep on some pinpoint feature/capability, not wide where it's useless until the whole trench is dug |
| 20:21.52 | brlcad | step backwards from what you have doesn't matter -- would it be a step forward for the current code |
| 20:21.52 | *** join/#brlcad sofat_ (~sofat@202.164.45.204) |
| 20:22.28 | brlcad | e.g., implementing just the opencl shot for ell was a step forward, even though practically useless for production |
| 20:22.48 | vasc | its actually worse than useless for production because it makes the rendering slower |
| 20:22.58 | brlcad | it validated behavior, demonstrated how to transcode a real example, etc |
| 20:23.13 | vasc | i can get why it was done that way |
| 20:23.38 | vasc | well think about this again in 2 weeks then |
| 20:23.39 | brlcad | it did exactly what it was scoped to do and very little has to be "undone" to do a next step |
| 20:23.53 | brlcad | that's huge |
| 20:24.15 | brlcad | not a dead effort that required the original author to keep at it for another N weeks/months/whatever |
| 20:24.20 | vasc | i did a bunch of coding to make a simplified pipeline and that should be stored somewhere too |
| 20:24.35 | vasc | as it is the code can render stuff |
| 20:24.49 | vasc | it has some warts and duplicates things and its slow but it renders stuff |
| 20:25.20 | brlcad | can anything you have be merged into rt or librt (in the opencl branch) without eliminating functionality? |
| 20:25.30 | vasc | like i said |
| 20:25.37 | vasc | merge the sph and arb8, and ehy patches |
| 20:25.52 | vasc | the grid patch reimplements its own rendering pipeline |
| 20:25.58 | vasc | so don't put that in yet |
| 20:26.04 | brlcad | yeah, the prims are easily keepers |
| 20:26.32 | brlcad | could the grid pipeline be reworked to sit beside the old one? |
| 20:26.36 | brlcad | (even slow) |
| 20:26.51 | vasc | it could but like i said it would only mean the next guy will have to redo what i did again |
| 20:27.26 | vasc | basically i did a completely new mostly self-contained rendering pipeline in ansi c |
| 20:27.30 | brlcad | it's not an unfair assumption that they will likely have to do that anyways |
| 20:27.31 | vasc | simplified |
| 20:27.45 | Notify | 03BRL-CAD:carlmoore * 65701 (brlcad/trunk/src/util/bw-ps.c brlcad/trunk/src/util/pix-ps.c): make cosmetic changes to bw-ps.c and pix-ps.c so that they look more alike |
| 20:28.03 | brlcad | because at the end of the day, this all has to get hooked back into rt/librt |
| 20:28.05 | vasc | the alternative is someone just writing it and putting it in without looking at how the code works |
| 20:28.15 | vasc | the present code |
| 20:28.40 | vasc | what i did was i tried to simplify the current rendering pipeline in a way that it can be digested and simplified for later opencl or whatever porting |
| 20:29.11 | vasc | you can call it the 'simple' rendering pipeline.... |
| 20:30.13 | vasc | it is still WIP |
| 20:30.48 | vasc | like the boolean eval isn't simplified yet |
| 20:30.59 | vasc | and that's critical |
| 20:31.17 | brlcad | I entirely get what you did, why you did it, etc ... it's what to do with it before it's done |
| 20:31.25 | vasc | well |
| 20:31.50 | vasc | i think one way is to have optional compilation for different rendering pipelines in librt |
| 20:32.01 | brlcad | such that it isn't wasted effort in the long run because, oh, say your simplification goes too far and completely fails validation |
| 20:32.25 | brlcad | or just sits in a branch and is never merged because it was hooked into a skeleton rt2 instead of rt |
| 20:32.31 | vasc | i actually have two versions of the grid construction code you know |
| 20:32.36 | vasc | one is ANSI C the other is OpenCL |
| 20:33.03 | vasc | so we can compile the ANSI C one by default if someone selects the simplified pipeline and doesn't have OpenCL |
| 20:33.11 | brlcad | boolean eval is critical for performance, it's not critical for leveraging/integrating other code in this pipeline |
| 20:33.18 | vasc | right |
| 20:33.47 | vasc | we had a similar issue in freeciv at one point |
| 20:33.59 | vasc | our only graphics client was written for the X Athena Widgets |
| 20:34.13 | vasc | i did the first port to a 'modern' graphics toolkit i.e. Gtk+ |
| 20:34.25 | brlcad | we're still at the point that I frankly DO NOT CARE about performance, I care about the survivability of code that will eventually result in performance gains :) |
| 20:34.38 | vasc | eventually someone else realized we should also have a bare non-toolkit client so the next time someone did a port they could refer to that |
| 20:34.42 | brlcad | the point is performance, but it's not the goal, if that makes sense |
| 20:35.05 | vasc | yeah i know |
| 20:35.17 | Notify | 03BRL-CAD:carlmoore * 65702 brlcad/trunk/doc/docbook/system/man1/en/bwcrop.xml: add 'clockwise-from-upper-left' remark, to provide a summary |
| 20:35.29 | vasc | man when i did the gtk+ client in Freeciv it took me a year to get SOMETHING in CVS |
| 20:35.41 | vasc | it worked but it had all the memory leaks in it |
| 20:35.44 | vasc | these |
| 20:35.56 | Stragus | Ouch, never do that :) |
| 20:36.00 | brlcad | nods |
| 20:36.02 | Stragus | Don't write code with memory leaks "to fix later" |
| 20:36.16 | vasc | well some of them i didn't realize they were memory leaks |
| 20:36.27 | vasc | because they were deep inside the gtk+ library code itself |
| 20:37.04 | vasc | anyway nothing a few rounds of valgrind didn't work |
| 20:37.14 | vasc | i ended up reimplementing a couple of gtk+ widgets because of that |
| 20:37.39 | vasc | s/didn't/did/ |
| 20:37.42 | vasc | the |
| 20:37.56 | vasc | i caught them all with valgrind and i forget the other tool |
| 20:38.22 | vasc | right memprof |
| 20:39.27 | vasc | so we had noticeable memory leaks in 15minutes, then it was 30 minutes, then it was 3 hours of gameplay, and then no leaks |
| 20:40.34 | brlcad | we'd all be lucky if memory leaks were the entent of the problem here ;) |
| 20:40.43 | Notify | 03BRL-CAD:starseeker * 65703 brlcad/trunk/TODO: Note that this is to replace existing manual code |
| 20:41.03 | vasc | well i had to do a lot of things still that was actually a pretty barebones client |
| 20:41.16 | brlcad | starseeker: give poor carl a break, typo ;) |
| 20:41.19 | vasc | i think the whole port took close to 2 years |
| 20:41.33 | starseeker | brlcad: heh, sorry |
| 20:41.40 | vasc | but yeah i was an undergrad so i guess i had more patience back then |
| 20:41.47 | brlcad | and time |
| 20:41.58 | brlcad | and motivation, all new interesting different |
| 20:42.06 | vasc | time too yes |
| 20:42.16 | Notify | 03BRL-CAD:starseeker * 65704 brlcad/trunk/TODO: typo |
| 20:43.02 | vasc | but now i have something i didn't have back then. masters students to coherce in working for me. |
| 20:43.04 | vasc | muhahahaha |
| 20:43.10 | vasc | into |
| 20:43.21 | brlcad | at a minimum, we'll end up with an "rt2" or "rtcl" or whatever you're calling your harness, but the more that can be integrated, the better |
| 20:43.29 | brlcad | that is all |
| 20:43.37 | vasc | yeah that's the idea |
| 20:44.38 | vasc | i'm presently supervising like 2 masters students, and two more in like 3 months. and maybe another one in 6 months or 8 |
| 20:44.46 | vasc | co-supervising anyway |
| 20:45.14 | vasc | they are all doing GPU ray tracing. |
| 20:45.26 | brlcad | if all we end up with, though, is rt2 ... then we'll be in a world of hurt once your faculty impose different priorities on your time |
| 20:45.40 | vasc | that's the problem i have |
| 20:45.55 | vasc | in the end of this year or start of next year i'm going to work on something else |
| 20:46.06 | vasc | i could try convincing a masters student to work on this but i dunno |
| 20:46.31 | brlcad | boolean eval on gpu is easily paper-worthy imo |
| 20:47.05 | vasc | half my students aren't doing their thesis now because they started working part-time |
| 20:47.16 | vasc | i had one dropout a couple months back because of that |
| 20:47.36 | vasc | the economic situation is bad here |
| 20:47.37 | brlcad | can do nothing with that information :) |
| 20:48.05 | vasc | yeah me neither :-) |
| 20:48.20 | vasc | i can just wish them good luck |
| 20:48.40 | brlcad | so do you think end-to-end opencl pipeline is achievable in two weeks? |
| 20:48.47 | vasc | no way |
| 20:48.49 | brlcad | (NOT opimized) |
| 20:49.15 | vasc | there's a really big issue here. which is the dynamic memory allocation the current code keeps insisting on doing |
| 20:49.25 | vasc | a big no no in opencl or cuda or whatever |
| 20:49.39 | Stragus | nods to that |
| 20:49.41 | brlcad | which code |
| 20:49.53 | vasc | you can call malloc inside the gpu. unless you implement your own malloc... and you don't wanna do that anway |
| 20:50.07 | vasc | you can't call malloc inside the gpu |
| 20:50.11 | brlcad | that big no-no is not at all unique to cuda/opencl/gpu |
| 20:50.36 | brlcad | you're not answering my question.. I know malloc is nfg |
| 20:50.49 | vasc | yes which is why i want to do a simplified ANSI C pipeline without the mallocs first |
| 20:51.12 | vasc | well |
| 20:51.22 | brlcad | what piece of the pipeline is problematic in the current code such that it's a problem? |
| 20:51.27 | vasc | in the multi-hit traversal code the hits are stored in this doubly linked list |
| 20:51.42 | vasc | dynamic doubly linked list |
| 20:51.51 | brlcad | so the hit record-keeping portion |
| 20:51.55 | vasc | which is then processed by the boolean evals |
| 20:52.28 | vasc | the boolean eval processing is seemingly split in two portions. one works every time you advance the traversal, and then there's an rtfinal call once the traversal ends |
| 20:52.35 | vasc | which traverses the whole hit list i think |
| 20:53.03 | brlcad | sounds about right, yes |
| 20:53.30 | vasc | well the best option would be if somehow you could incrementally compute the rtfinal thing and not need dynamic memory allocation |
| 20:53.43 | vasc | or at least that's what my gut tells me |
| 20:54.28 | brlcad | it would not be hard to eliminate the dynamic memory allocation there |
| 20:54.43 | Stragus | Static per-ray buffer? |
| 20:54.51 | brlcad | hits could easily be stored in an array/buffer, yes |
| 20:55.16 | vasc | but we would like not to use a lot of memory if we could too |
| 20:55.22 | Stragus | You would need some kind of dynamic allocation of bundles of 4/8 hits, from some big static buffer, managed by atomics |
| 20:55.23 | vasc | gpus have tiny caches |
| 20:55.26 | brlcad | pages of them to avoid some arbitrary #-of-objects-along-ray limit |
| 20:55.32 | Stragus | Stop shooting rays when the buffer is too full, process results, resume |
| 20:55.47 | vasc | right |
| 20:56.04 | vasc | i thought of doing it that way |
| 20:56.12 | vasc | and for that actually we should be using a bvh instead of a grid |
| 20:56.41 | brlcad | vasc: by the time this is all done being implemented, we'll probably have a TB on the video card ;) |
| 20:56.41 | vasc | coz in a bvh you can guarantee the max amount of object in a cell. |
| 20:56.53 | starseeker | I think the assertion is that this approach is so foreign to the assumptions and design of our existing code that fitting it in involves a virtual rewrite? |
| 20:56.57 | Stragus | The idea would be to stop raytracing before the big static buffer runs out |
| 20:57.12 | Stragus | If you run out, drop the rays, process buffered rays, then restart |
| 20:57.17 | starseeker | vasc: with csg though you can't make any assumptions about the maximum number of hits in a cell |
| 20:57.42 | brlcad | starseeker: it is a rewrite, but we want to gut the cathedral from the inside out, not build a new one ;) |
| 20:57.55 | starseeker | even an individual csg primitive may produce unpredicitable numbers of hit points |
| 20:58.00 | vasc | all the primitives i've seen so far are manifolds so at most you have two intersections per object |
| 20:58.12 | starseeker | vasc: take a look at nurbs ;-) |
| 20:58.23 | starseeker | even a torus can have 4 intersections |
| 20:58.34 | brlcad | so can a tgc |
| 20:58.34 | vasc | yeah coz it has a hole |
| 20:58.49 | vasc | so much for that idea |
| 20:59.02 | starseeker | bots are another one that's not predictable |
| 20:59.17 | starseeker | dsp, ebm... |
| 20:59.21 | brlcad | same idea as the hit tables though -- you just keep track of pages of results |
| 20:59.30 | vasc | hmpf |
| 20:59.54 | vasc | i didn't want to keep the dynamic memory allocation but i guess i'll have to stomach it |
| 21:00.05 | starseeker | vasc: what about a memory pool? |
| 21:00.05 | vasc | it seems kind of like a low tech solution to the problem |
| 21:00.17 | vasc | yeah we would have to do it like that yes |
| 21:00.18 | Stragus | Properly managed dynamic memory allocation with atomics is all right |
| 21:00.22 | starseeker | minimze the dynamic part, even if we can't totally eliminate it? |
| 21:00.54 | brlcad | it can be "practically" eliminated for most models |
| 21:00.58 | Stragus | has had to use dynamic memory on CUDA with atomics |
| 21:01.09 | brlcad | then there will be atypical models that break the mold |
| 21:01.11 | vasc | like i said i have a gut feeling we don't need dynamic memory to solve the problem at all |
| 21:01.31 | Stragus | You don't need dynamic memory if you can process the hits right away as they come |
| 21:01.50 | starseeker | vasc: we can probably avoid it for many cases, but it's trivial to construct a model that will break any static assumptions we care to make |
| 21:01.54 | Stragus | Which is also a lot faster... but all code calling the raytracer isn't designed for that |
| 21:02.33 | starseeker | Stragus: as I understand boolweave that's not actually possible (processing hits right away) |
| 21:02.39 | starseeker | Stragus: at least, not for solid raytracing |
| 21:03.14 | Stragus | You could end up buffering just few hints to process "segments", which would a lot lighter on memory requirements |
| 21:03.27 | Stragus | You could store the hits in shared memory, no global memory stores involved |
| 21:03.34 | vasc | i could just use the memory pool and if it gets exausted i abort the processing, realloc more chunks and try again |
| 21:03.38 | brlcad | so vasc, we're again back to gsoc scoping ... goal towards the finish line, what useful things will result |
| 21:03.44 | starseeker | vasc: doesn't mean it's not worth optimizing for the "common" situations which will be most models, but it's important that there be a working fallback (even if it is slow) for the harder cases |
| 21:04.02 | brlcad | this discussion would have been great had the gsoc goal been "implement coherent boolean weaving" ;) |
| 21:04.28 | brlcad | it was a given that this would not be achieved in the timeframe given the other aspects |
| 21:04.48 | vasc | yeah it would take the entire timeframe just to get a good solution to this specific problem |
| 21:05.16 | brlcad | certainly not enough time in 2 weeks -- my earlier question about full pipeline was whether something really trivial could be done |
| 21:05.39 | brlcad | like "don't weave, sort, take the first hit" |
| 21:06.30 | vasc | well |
| 21:06.38 | brlcad | having a testing pipeline that went end-to-end would be a useful end state as that could be used down the road for the next step(s) |
| 21:07.13 | bhollister | brlcad: regarding 'view_state'... trying to turn on vertex labeling when subcommand "kill V" is invoked on the CLI. this appears to be done in f_labelvert (overlay.c) after entering solid edit mode. |
| 21:07.15 | vasc | wouldn't that bork the csg? |
| 21:07.32 | brlcad | sure, we're talking about opencl pipeline though, not correctnesss |
| 21:07.49 | vasc | well a single-hit ray tracing pipeline is rather simpler yes |
| 21:07.50 | brlcad | doing both is impossible in the timeframe |
| 21:08.05 | vasc | yeah i should be able to do that in the timeframe |
| 21:08.06 | brlcad | assuming doing both will happen later is super high risk |
| 21:09.07 | brlcad | quasi single-hit |
| 21:09.17 | brlcad | it could still do all hits and simply throw them away |
| 21:09.27 | vasc | yeah that |
| 21:09.38 | vasc | the hit intersection routines would still compute all the intersections |
| 21:09.44 | vasc | but we only store one |
| 21:09.47 | vasc | hm |
| 21:09.48 | brlcad | that's arguably the correct thing to do that wouldn't have to be changed/undone when coherent booleans materialize |
| 21:10.31 | brlcad | currently, there's a flag in the application structure that says whether we care only about the first hit or all hits |
| 21:11.15 | brlcad | it currently evaluates all of them (for most primitives) and decides at the end whether to return all segments or just the first |
| 21:11.17 | vasc | wouldnt that also require dynamic memory? |
| 21:11.30 | vasc | its like you said the torus can have 4 hits and so on |
| 21:11.54 | brlcad | back to what the goal/point is |
| 21:12.03 | *** join/#brlcad merzo (~merzo@170-0-133-95.pool.ukrtel.net) |
| 21:12.17 | vasc | i think we should just do an ANSI C pipeline |
| 21:12.20 | brlcad | if it's to get a pipeline, then the record keeping strategy doesn't matter as it's not the goal |
| 21:12.26 | vasc | which we'll get to simplify more later |
| 21:12.38 | brlcad | so use a fixed array or try to do efficient dynamic pages, etc |
| 21:13.19 | brlcad | why C pipeline? |
| 21:13.50 | vasc | in my experience trying to code a complex algorithm in CUDA or OpenCL direct usually leads to wasted time |
| 21:14.02 | vasc | you should have a C implementation first |
| 21:14.20 | vasc | it also helps because then you have something you can compare against on debugging |
| 21:14.21 | brlcad | which ... we do :) |
| 21:14.51 | vasc | yeah but its not something you should implement on CUDA or OpenCL. |
| 21:15.16 | brlcad | not transcoded directly, sure |
| 21:15.43 | vasc | its also kind of opaque |
| 21:16.10 | vasc | i kind of get it but the design but its a bit overengineered. |
| 21:16.18 | brlcad | that's more familiarity, I think ... if anything the datastructures and layerings are quite exposed |
| 21:16.41 | vasc | its lasagnified |
| 21:16.54 | brlcad | you're referring to the spatial partioning if I'm not mistaken? |
| 21:17.01 | vasc | the traversal |
| 21:17.17 | brlcad | traversal of the spatial partitioning, yes |
| 21:17.28 | vasc | its almost like i'm programming Java EE. |
| 21:17.51 | vasc | almost as lasagnified. |
| 21:17.59 | brlcad | now that's an exaggeration :P |
| 21:18.07 | brlcad | and a mean one |
| 21:18.39 | brlcad | if the code had feelings, you would have hurt them |
| 21:18.41 | vasc | it all makes sense because of all the options |
| 21:18.59 | vasc | conditional this and conditional that |
| 21:19.31 | vasc | so having seen this gordian knot i felt like cutting it. my 2nd name is alexander after all. |
| 21:19.45 | vasc | :-P |
| 21:19.53 | brlcad | that's how production codes evolve, espeically when they are highly actively developed and expanded |
| 21:20.04 | vasc | yeah |
| 21:20.09 | vasc | it always like that |
| 21:20.12 | brlcad | then the next guy comes along and just see's dozens of options on the periphery of what they care about |
| 21:20.26 | brlcad | but pull together 20 other users, and suddenly all options are in use |
| 21:20.33 | vasc | or not |
| 21:20.37 | brlcad | that said, rt does have too many options (exposed) |
| 21:20.56 | brlcad | most actually do get used (at least the ones that are not compile-time) |
| 21:21.15 | vasc | i mean it should be used someplace but sometimes man |
| 21:21.21 | brlcad | so cutting a feature means having to negotiate and consider the impact with/on users |
| 21:21.41 | vasc | which is why i propose a simplified pipeline which can be select someplace |
| 21:21.49 | vasc | instead of trashing what is there |
| 21:21.59 | vasc | what is there is there for a reason |
| 21:22.13 | vasc | and any replacement, if there is one, should cover all the necessary use cases |
| 21:22.31 | vasc | what i have is too simplified to do that |
| 21:22.44 | brlcad | I would assert that until demonstrated otherwise, the production code defines the necessary use cases :) |
| 21:22.49 | vasc | but too complicated and it all becomes unmanageable to port. at least at this point. |
| 21:23.29 | brlcad | otherwise "starting fresh" is hardly defensible from a pragmatic standpoint |
| 21:23.44 | brlcad | the value is in the complexity and depth of features |
| 21:23.45 | vasc | good luck trying to port the current setup to CUDA |
| 21:23.48 | vasc | or OpenCL |
| 21:24.03 | vasc | and getting good performance out of it to boot |
| 21:24.45 | vasc | it uses dynamic memory and it has way too many function calls, and uses way too much memory |
| 21:24.48 | brlcad | if I only got performance because I ripped out all functionality or correctness, that's not at all interesting or valuable |
| 21:25.19 | vasc | ah but the thing is i don't think you need to write the algorithms like that to produce the required functionality |
| 21:25.32 | vasc | its just noone bothered doing it before |
| 21:25.53 | vasc | because at the time the code was written the hardware performance optimization parameters were different |
| 21:25.56 | brlcad | sure |
| 21:26.02 | vasc | memory was fast and computations were slow |
| 21:26.06 | vasc | now its the other way around |
| 21:26.15 | brlcad | old news |
| 21:26.31 | vasc | so an extra malloc do prevent doing a dot product is no longer a good optimization |
| 21:26.35 | brlcad | now == a decade ago |
| 21:27.27 | vasc | yeah but you can still sense that in the code |
| 21:28.04 | vasc | it looks a lot like the raytracer i wrote in 2001 |
| 21:28.11 | vasc | 2000 actually |
| 21:28.15 | brlcad | I don't quite understand the logic you're using -- nothing ever stated implied that "port the current setup to CUDA" meant keep malloc |
| 21:29.19 | brlcad | this is all a question of how to go about instituting an upgrade on very old infrastructure |
| 21:29.20 | vasc | let's examine one case |
| 21:29.25 | vasc | the current code has mailboxing in it |
| 21:29.43 | vasc | so do you do the mailboxing or do you just recompute the intersections? |
| 21:30.13 | Stragus | Some primitive intersections are very expensive to compute, like NURBS |
| 21:30.20 | brlcad | there's plenty of research papers demonstrating both quite fast, so fast that I frankly wouldn't care |
| 21:30.51 | vasc | see there's all this context i don't have because i didn't reimplement all the primitives yet |
| 21:31.00 | brlcad | is it the absolute fastest for a given test case, dunno and *really* don't care |
| 21:31.34 | brlcad | and you wouldn't have time to anytime soon, and that's part of the point of doing things incremental like this |
| 21:31.44 | vasc | exactly |
| 21:31.54 | brlcad | NURBS is a good example because that's not going to be rewritten in less than a year |
| 21:32.18 | vasc | i should have a student working on that next year |
| 21:32.27 | brlcad | and it's kind of useless to a user if I had one renderer that was blazing fast for all primitives but I had to use a different tool if there were nurbs |
| 21:32.42 | vasc | not necessarily |
| 21:32.48 | brlcad | it's got to be the same tracer, just some models result in slow performance |
| 21:32.50 | vasc | take the wireframe mode for an example |
| 21:33.14 | brlcad | and slow is relative |
| 21:33.17 | vasc | if i can get a more accurate preview that can have some value in itself |
| 21:33.43 | Stragus | I would have considered writing a raytracer that just returns "hits" to some callback |
| 21:33.55 | Stragus | Then, in a second phase, someone can plug something that buffer the hits into that callback |
| 21:34.01 | brlcad | if we're taling about accuracy, I don't trust the results one bit without incredibly expensive verification and validation |
| 21:34.44 | brlcad | analogy time |
| 21:34.47 | vasc | that's why i don't work in the medical sector |
| 21:34.49 | Notify | 03BRL-CAD:starseeker * 65705 (brlcad/trunk/include/analyze.h brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp and 2 others): Put the control comb prep in the subtraction search function. Need to think about where/how/if to store preps for later validation diffing... |
| 21:35.03 | brlcad | much of what is in BRL-CAD is like the Louvre |
| 21:35.09 | vasc | i had enough of that when i worked in telecoms |
| 21:35.15 | brlcad | it's a big old building filled with old artwork |
| 21:35.53 | Stragus | Then you want to transform the Louvres into a modern space station? |
| 21:35.53 | brlcad | but shitty dangerous wiring, bathrooms with holes in the ground, and solid marble walls |
| 21:35.59 | Stragus | :) |
| 21:36.35 | brlcad | not at all, just into a modern museum, up to code |
| 21:36.49 | vasc | http://cdn4.sol.pt/fotos/2014/11/21/393092.jpg |
| 21:36.53 | brlcad | Stragus: your approach would certainly be: I'll build my own damn museum |
| 21:36.58 | Stragus | Damn right! |
| 21:37.21 | Stragus | Just kidding, I appreciate the monstrous amount of work into BRL-CAD |
| 21:37.22 | brlcad | and I'd say, that's great -- anyone can and will and have done that |
| 21:37.38 | brlcad | but then it's not the Louvre |
| 21:37.39 | bhollister | brlcad: okay, i suppose that that 'labelvert' can be used before calling 'kill V'. i'm getting coords as labels (not billboarded). but i believe i've seen this as vertex numbering before in some other context. |
| 21:37.44 | brlcad | it's a modern art building |
| 21:38.13 | brlcad | a lot of the modern tracers are exactly like that -- very sleek polished, very little art but what is there is impressive |
| 21:38.28 | brlcad | the bathrooms and wiring are AMAZING *cough* |
| 21:38.45 | vasc | until they aren't. see you in 300 years. |
| 21:38.53 | brlcad | in the end for BRL-CAD, we have a big old building that needs the wiring upgraded |
| 21:40.09 | vasc | that building in the picture i posted, they just nuked the interior. they built a glass building and kept the facade. |
| 21:40.21 | Stragus | And we can't sanely renovate the bathroom without upgrading the hallways falling apart into modern moving walkways |
| 21:40.46 | brlcad | vasc: that is certainly another approach |
| 21:41.24 | brlcad | one that has some appeal, but one that we can't afford to stop to build so it's up to some contractor/builder to remain motivated and do a good job for that to happen |
| 21:41.39 | bhollister | starseeker: besides http://brlcad.org/wiki/MGED_CMD_labelvert, is there a way to label vertex number on an object instead of coords. |
| 21:42.21 | brlcad | Stragus: I certainly can -- and figuring out how to do that without disrupting the day-to-date operations of the museum is exactly the sort of engineering concerns I think about all the time :) |
| 21:42.32 | Stragus | I would be interested in working on a GPU CSG raytracing, but the interfaces currently leading to the rt code are... problematic |
| 21:42.40 | Stragus | Indeed brlcad :) |
| 21:42.41 | brlcad | it presents it's own set of challenges |
| 21:42.51 | brlcad | and takes time |
| 21:43.05 | Stragus | GPU CSG raytracer* |
| 21:43.07 | brlcad | but I find it both more rewarding and ultimately more impacting / important to users |
| 21:43.19 | Notify | 03BRL-CAD Wiki:Bhollister * 9115 /wiki/MGED_CMD_permute: /* Argument(s) */ |
| 21:44.01 | vasc | well i simplified those interfaces quite a lot |
| 21:44.34 | vasc | that was my problem too |
| 21:44.52 | brlcad | that's why my comments were centered around what can we salvage because there's never going to be enough time to entirely gut the building (even though I live in a magical world where I can clone the Louvre and work on it) |
| 21:45.12 | vasc | quite |
| 21:45.20 | vasc | which is why i think the should have rt and rt-simple |
| 21:45.25 | vasc | we |
| 21:45.32 | Stragus | rt-archaic and rt-modern |
| 21:45.56 | brlcad | Stragus: and the tool keeps an internal timer and renames itself down the road? |
| 21:46.09 | Stragus | That works. :) |
| 21:46.09 | brlcad | "modern" is so overused |
| 21:46.26 | vasc | something is only "modern" until it isn't. |
| 21:46.27 | Stragus | Obviously, there was a hint of sarcasm in that suggestion |
| 21:46.34 | brlcad | I know |
| 21:47.10 | brlcad | but it's a good point -- what we consider modern today was really an architecture shift that happened about 20 years ago, popularlized about 10 years ago |
| 21:47.22 | Stragus | Agreed |
| 21:47.37 | vasc | https://en.wikipedia.org/wiki/Modern_art |
| 21:47.41 | brlcad | and will likely be obsolete 10 years from now for one reason or another |
| 21:48.01 | vasc | so you have modern and postmodern and postpostmodern |
| 21:48.51 | Stragus | ultranewpostmodern or nothing |
| 21:49.22 | vasc | neomodern |
| 21:49.32 | brlcad | vasc: it's too late now to do much else about things, but in terms of your gsoc project -- what do you see the end state being? |
| 21:49.58 | vasc | every primitive we talked about except the bot, gpu side database storage |
| 21:50.03 | vasc | the grid construction |
| 21:50.35 | vasc | the traversal and rendering is something else which i think should be kept in a separate pipeline that the user selects if he wants to use it i.e. rt-simple |
| 21:50.51 | vasc | i'm still interested in doing a paper out of this |
| 21:51.03 | vasc | and for that the rendering pipeline needs to be made properly efficient |
| 21:51.10 | vasc | but i don't know how my time will be |
| 21:52.04 | brlcad | well we're talking gsoc timeframe |
| 21:52.19 | brlcad | that'd easily be after (gladly support you in any way needed) |
| 21:52.22 | vasc | so the primitives are : ell, ehy, arb8 (done) |
| 21:52.25 | starseeker | bhollister: I don't know of one offhand |
| 21:52.53 | brlcad | as I see it, the only decision is whether to a) spend the next 2 weeks working on completing a pipeline transform demo (with whatever limitations), or b) spend 2 weeks merging the traversal features of your demo with the rt/librt code as a runtime option (as the intention is migration as more pieces fall into place) |
| 21:53.02 | vasc | tor, tgc i'll do it in the timeframe too |
| 21:53.17 | brlcad | o.O |
| 21:53.21 | vasc | what i'm working on now is gpu side database storage |
| 21:53.24 | brlcad | how are you going to do tor? :) |
| 21:53.42 | vasc | and then i'll do opencl shot code for the tor and tgc |
| 21:54.05 | brlcad | I doubt you'd get tor done before the deadline if you started now... |
| 21:54.19 | brlcad | tgc is even highly debatable |
| 21:54.21 | vasc | its just a cone with a couple of planes right? |
| 21:54.42 | brlcad | just a cone, a fully generalized mathematical model of one, yes |
| 21:54.57 | brlcad | s/fully/mostly/ |
| 21:55.03 | vasc | i did a ray cone intersector in 2000. so i kinda know the problem. |
| 21:55.12 | vasc | its not gonna be that much more complicated than ehy was |
| 21:55.13 | brlcad | heh |
| 21:55.25 | brlcad | well then it should have been obvious to you how 4 hits are possible |
| 21:55.36 | vasc | no just two |
| 21:55.45 | brlcad | if it's not, then you almost certainly didn't work with something this generalized |
| 21:55.46 | vasc | 4 in the torus |
| 21:55.52 | brlcad | tgc is also 4 |
| 21:55.52 | vasc | but the tgc only 2 |
| 21:56.00 | brlcad | 2 or 4 |
| 21:56.03 | vasc | i don't see how. it has no holes |
| 21:56.05 | vasc | does it? |
| 21:56.08 | brlcad | nope |
| 21:56.24 | vasc | you either hit the caps or the walls |
| 21:56.39 | vasc | man |
| 21:56.56 | vasc | i don't see how you get more than 2 valid hits |
| 21:57.15 | vasc | you are going to have 4 results |
| 21:57.19 | vasc | but some won't be valid |
| 21:57.24 | brlcad | you can hit a cap, come out a wall, go through another wall, come out another cap |
| 21:57.38 | brlcad | or in a wall, out a wall, in a wall, out a wall |
| 21:58.05 | brlcad | what's that whiteboard site? |
| 21:58.14 | bhollister | starseeker: how does 'permute' determine which vertex has a particular vertex index then? 'sed' doesn't appear to turn on the billboarded overlay of vertex-list indices. |
| 21:59.01 | vasc | so the problem is because you need to return the ins and outs |
| 21:59.12 | vasc | no but that doesn't make a lot of sense |
| 21:59.22 | vasc | in that case you needed 4 for the sphere too |
| 21:59.24 | vasc | and you don't |
| 21:59.46 | Stragus | Four hits on a cone? I'm not following that either |
| 21:59.47 | brlcad | vasc: you're not visualizing the right shape -- like I said, this is a cone generalization |
| 22:00.06 | vasc | its just a truncated cone |
| 22:00.07 | brlcad | the code is defined as a ruled surface with two elliptical ends |
| 22:00.12 | vasc | its like a frustum except its round |
| 22:00.14 | Stragus | Any convex shape is two hits, the end |
| 22:00.19 | vasc | right |
| 22:00.21 | vasc | it has no holes in it |
| 22:00.22 | Stragus | Ah, so two cones on top of each other |
| 22:00.22 | vasc | genus 0 |
| 22:00.32 | vasc | oh that? |
| 22:00.32 | brlcad | no, one cone -- one single equation |
| 22:00.38 | vasc | see genus 0 |
| 22:01.15 | brlcad | pinch the top ellipse so it's wide |
| 22:01.28 | brlcad | pinch the bottom ellipse so it's narrow |
| 22:01.47 | brlcad | the resulting conic is higher order and requires a solve |
| 22:01.57 | ih8sum3r | brlcad: I just installed ubuntu server 14.04 and run update command, nothing else. I check .vdi file size it's about 1.8G. Huge! |
| 22:04.54 | brlcad | I forget the ratio required, but just construct a cone with ends orthogonally stretched 10x and you easily can go in and out twice as you clip the top and bottom |
| 22:05.35 | vasc | the code does use a quartic equation in some cases |
| 22:05.47 | vasc | but i never heard of someone doing the ray-cone intersection like that... |
| 22:05.50 | brlcad | that's the case |
| 22:06.05 | brlcad | it figures out when that happens |
| 22:06.31 | brlcad | obviously specializes the faster simpler cases |
| 22:07.42 | brlcad | vasc: that's why I say tor is also unlikely -- notice the call to rt_poly_roots() in both tor and tgc |
| 22:07.50 | vasc | now i get it |
| 22:07.54 | vasc | no i still don't |
| 22:08.03 | brlcad | you need a polynomial root solver to handle the quartic equations |
| 22:08.15 | brlcad | doing that via opencl is going to be fun |
| 22:08.20 | vasc | are the split planes enforced to be parallel or not? |
| 22:08.31 | vasc | the top and bottom split planes |
| 22:08.34 | brlcad | I think they are, but doesn't matter |
| 22:08.38 | vasc | it does |
| 22:08.53 | vasc | when |
| 22:08.54 | vasc | well |
| 22:08.56 | brlcad | that's one more generalization that was discussed, but little value |
| 22:09.10 | brlcad | and really would complicate things |
| 22:09.41 | vasc | www.geometrictools.com/Documentation/IntersectionLineCone.pdf |
| 22:10.25 | vasc | they don't use the quartic either |
| 22:10.40 | brlcad | that's our "REC" case, right elliptical cone |
| 22:11.58 | vasc | well in the torus its evident that you can get 4 hits because of the hole |
| 22:12.06 | vasc | in the truncated cone i just can't visualize it |
| 22:13.45 | brlcad | if you have brl-cad compiled, just run mged test.g and make tgc tgc |
| 22:13.56 | brlcad | I believe the default can have 4 hits |
| 22:14.16 | brlcad | or edit the ends to stretch them out so it's more obvious |
| 22:14.28 | brlcad | the difference from what you're used to is having elliptical ends |
| 22:14.49 | brlcad | not circles, and the ellipses don't have to align |
| 22:15.48 | Stragus | doesn't get it either |
| 22:16.05 | Stragus | Unless it's two cones on top of each other, defined by the same equation |
| 22:16.53 | vasc | http://news.povray.org/povray.advanced-users/thread/%3C379F3F96.48A201E8@isd.net%3E/?ttop=340620&toff=1500 |
| 22:18.03 | vasc | the surface of revolution isn't axis symmetrical with the vertical axis |
| 22:18.10 | vasc | but it will sounds strange that you need 4 hits |
| 22:18.35 | vasc | still |
| 22:18.51 | vasc | does it somehow get in an hourglass shape? |
| 22:22.07 | brlcad | here we go, check out this ancient rendering: http://brlcad.org/gallery/var/albums/historic/primitives_old.jpg |
| 22:22.20 | brlcad | next to the terrain-looking object is a TGC |
| 22:22.41 | starseeker | bhollister: I believe the vertex indicies are implicit in the data structures, but that may be only for arbs... |
| 22:22.41 | brlcad | notice how on both sides, you can barely slice through both the top and the bottom |
| 22:23.21 | vasc | the top most red one? |
| 22:23.22 | brlcad | that generalization dates back to at least the 70's |
| 22:23.25 | brlcad | yes |
| 22:23.50 | vasc | well it looks interesting |
| 22:24.11 | brlcad | Tron used that same notion of a cone (which was based on Comgeom, which BRL-CAD was also based on) |
| 22:25.02 | vasc | its because it's concave |
| 22:25.23 | vasc | calling that a cone is a bit of a stretch though :-) |
| 22:25.49 | *** part/#brlcad ih8sum3r (~deepak@122.173.5.55) |
| 22:26.15 | brlcad | the conical surface is the same equation as seen in the other three forms |
| 22:26.27 | brlcad | their equations just simplify to quadratic because of alignments |
| 22:26.42 | vasc | that doesn't have rotational symmetry |
| 22:26.51 | brlcad | i'm not sure it's technically concave |
| 22:27.08 | vasc | if it wasn't you wouldn't get more than 2 hits |
| 22:27.17 | vasc | its bent and concave |
| 22:27.18 | brlcad | yes |
| 22:27.49 | starseeker | maybe a good way to say it is the shape does not define its own convex hull? |
| 22:28.06 | brlcad | I had a discussion with one of our mathematicians years ago and vaguely recall arguing the same point and him going into detail how it was not mathematically |
| 22:28.26 | brlcad | at least not the mathematical definition of concavity |
| 22:28.27 | Notify | 03BRL-CAD:ejno * 65706 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: verify section volume/plate modes |
| 22:28.39 | brlcad | there was some other way to characterize it |
| 22:29.11 | starseeker | it *is* a ruled surface, IIRC |
| 22:29.30 | brlcad | but that's also goggles from about 10 years ago, I could be mistaken |
| 22:30.29 | brlcad | yeah, and there was some aspect of how this particular surface is constructed iirc |
| 22:30.49 | brlcad | that each "outline of the surface" is actually a straight line |
| 22:31.07 | starseeker | maybe some form of generalized cone? http://mathworld.wolfram.com/GeneralizedCone.html |
| 22:31.40 | brlcad | maybe, but I think that might be different meaning to the word generalized |
| 22:31.52 | brlcad | fully generalized to nonelliptical ends is pretty nuts |
| 22:32.02 | starseeker | vasc: well, the upshot is it's going to be a challenge ;-) |
| 22:37.32 | vasc | well it can't have more than four |
| 22:38.17 | vasc | so i guess it is more complicated than i thought |
| 22:38.24 | vasc | damn |
| 22:38.44 | vasc | still it was interesting |
| 22:40.09 | vasc | you say this is a commonly used primitive? |
| 22:40.53 | vasc | are there some physical processes which can generate this easily? |
| 22:43.16 | Notify | 03BRL-CAD:starseeker * 65707 (brlcad/trunk/include/brep.h brlcad/trunk/src/libbrep/shape_recognition_util.cpp brlcad/trunk/src/libged/shape_recognition.cpp): Not working yet, but try to delay comb finalization so we can be sure all necessary objects are in place. |
| 22:44.15 | starseeker | vasc: you mean machining or some such? |
| 22:44.45 | vasc | it seems kind of like something you could do with bending |
| 22:44.52 | vasc | ah well |
| 22:45.06 | vasc | i'll just finish this database thing it's been taking too long |
| 22:51.42 | vasc | i'll redo my schedule though |
| 22:52.09 | vasc | its probably not a good idea to do the opencl rendering pipeline until we know how we can process the multiple hits without the mallocs |
| 22:55.44 | Notify | 03BRL-CAD:starseeker * 65708 brlcad/trunk/src/libged/shape_recognition.cpp: Helps to pass the right pointer... |
| 23:03.40 | Notify | 03BRL-CAD Wiki:Konrado DJ * 9116 /wiki/User:Konrado_DJ/GSoc2015/logs: /* 27 JULY 2015 */ |
| 23:12.38 | vasc | this is using obscene amounts of memory. need to pack the data more. |
| 23:19.02 | vasc | its amazing how bad the standard packing is |
| 23:21.20 | vasc | 384 bytes if i use the standard types and 160 bytes if i pack things myself |
| 23:31.26 | *** join/#brlcad konrado (~konro@41.205.22.56) |
| 23:46.29 | bhollister | starseeker: is there a preferred way to visit all the vertices in an nmg model? is there a use case somewhere showing nmg_visit_* to search for a vertex with a given coord? |
| 23:56.31 | Notify | 03BRL-CAD Wiki:Bhollister * 9117 /wiki/MGED_CMD_nmg: /* Proposed subcommands */ |
