| 00:00.11 | mdavis | no no! Displacement maps |
| 00:00.17 | mdavis | (although digital signal processors are very interesting too) |
| 00:00.47 | ``Erik | I'm sure there's some knowedge in the channel |
| 00:01.43 | mdavis | well...I am using 7.14.8...whenever I try to evaluate a DSP, it says invalid NMG |
| 00:02.05 | mdavis | or something of that sort about NMGs..earlier, I even got a NULL pointer something or another |
| 00:03.43 | Ralith | that sounds serious :/ |
| 00:03.45 | Ralith | doing anything weird? |
| 00:10.54 | brlcad | ah, mdavis -- you're trying to export to some polygonal format? |
| 00:10.56 | mdavis | well |
| 00:11.02 | mdavis | yes...i want to export g-stl |
| 00:11.14 | mdavis | and I would also like to do an ev -w |
| 00:11.15 | mdavis | or even just an ev |
| 00:11.43 | mdavis | I spent 36 hours trying to generate an STL of a DSP just for it to go kaput |
| 00:11.54 | brlcad | they all end up calling the same nmg routines |
| 00:12.09 | brlcad | can you provide the .g file with the dsp somewhere? |
| 00:12.17 | mdavis | certainly..give me a second |
| 00:12.24 | brlcad | sounds like a bug of course |
| 00:12.52 | brlcad | anything unusual about the dsp? |
| 00:13.28 | mdavis | well...the one I was really working on was just a plump parabola...this test file just has 6 points or so in it for testing |
| 00:13.29 | *** join/#brlcad stevegt_1 (n=stevegt@cislunar.TerraLuna.Org) | |
| 00:13.47 | brlcad | and presumably it raytraces okay? |
| 00:13.55 | mdavis | Haven't tried that..let me see.. |
| 00:14.27 | brlcad | either way, can post up details and the .g here: https://sourceforge.net/tracker/?func=add&group_id=105292&atid=640802 |
| 00:14.49 | brlcad | I can take a look at it for a little bit tonight, but there others can also take a peek at it |
| 00:15.33 | mdavis | Raytraces fine |
| 00:15.42 | mdavis | visit autolich.com/test.dsp and autolich.com/test.g |
| 00:15.43 | brlcad | good |
| 00:16.54 | brlcad | 404 on both |
| 00:16.58 | mdavis | This file just has the values 12,15,17,14,11,25 |
| 00:17.01 | mdavis | please retry |
| 00:18.33 | ``Erik | facetize works fine on it |
| 00:18.34 | brlcad | I can reproduce the bug here, great! |
| 00:18.49 | mdavis | by the way..although it goes without saying...despite the bug, BRL-CAD is truly awesome and I am VERY appreciative |
| 00:18.57 | stevegt_1 | Hey all -- anyone know the total size of the svn repository (all changesets, not just current)? I'm wondering how practical it is to replicate it to a local hg repository for faster history searches etc. Based on progress so far I'm guessing it's about a half gig... |
| 00:19.02 | brlcad | ah, nice catch ``Erik |
| 00:19.10 | brlcad | that's probably a workable workaround |
| 00:19.32 | brlcad | mdavis: run "facetize test.bot test.s", then g-stl test.bot instead of the .s |
| 00:19.36 | mdavis | I'm afraid I don't know facetize |
| 00:19.51 | ``Erik | well, it means the nmg routines are ok with it, g-stl must be retarded. mebbe i doesn't load the .dsp file correctly |
| 00:19.52 | mdavis | ok..let's se |
| 00:19.52 | mdavis | see |
| 00:20.12 | ``Erik | mdavis: it's a command in mged, creates a 'bot' object, a bunch of triangles |
| 00:20.47 | ``Erik | (Bag O' Triangles, your usual triangle soup) |
| 00:21.38 | ``Erik | yeah, facetize and g-stl works fine, g-stl on the dsp fails |
| 00:22.10 | ``Erik | mged -c test.g facetize test.f test.s && g-stl -o test.stl test.g test.f |
| 00:22.12 | brlcad | ev also fails like he mentioned, so there is some mutual stupidity going on |
| 00:24.12 | mdavis | my processor is blazing up.... |
| 00:24.38 | mdavis | shoot..ran it on the wrong file (the one with the big shape) and the computer freaked out |
| 00:24.42 | mdavis | trying again |
| 00:25.57 | mdavis | OK..I did it and it likes it |
| 00:26.02 | mdavis | have a nice test.bot |
| 00:26.19 | stevegt_1 | ...speaking of history, does anyone know what the a_rbeam member of the rt application structure is all about? It's supposed to be ray beam width, but it looks like it may have never been completely implemented. I was hoping to use it to simulate a laser cut, but rt_shootray returns the same results no matter what I set it to. |
| 00:27.46 | ``Erik | implementation of a non-zero diameter ray has been discussed for many many years, you may've hit the nail on the head, stevegt_1 :/ |
| 00:28.41 | *** join/#brlcad docelic (n=docelic@78.134.202.119) | |
| 00:29.11 | mdavis | This thing is working great now |
| 00:29.17 | mdavis | Thanks a lot!! |
| 00:29.43 | brlcad | thanks for reporting the problem |
| 00:30.05 | brlcad | feel free to use that tracker if you've found other problems, possibly ones you've since worked around even, or if something new comes up |
| 00:30.10 | ``Erik | yeah, I imagine g-stl on a dsp is going to be working ok in the next few days O.o |
| 00:30.51 | stevegt_1 | Erik: thanks -- thought so. This line of code in prep.c is sooo tantalyzing: rtip->rti_max_beam_radius = 175.0/2; /* Largest Army bullet */ |
| 00:30.56 | stevegt_1 | ;-) |
| 00:31.19 | brlcad | heh |
| 00:31.28 | ``Erik | interest comment |
| 00:31.41 | ``Erik | s/ c/ing&/ |
| 00:34.28 | *** join/#brlcad stevegt`` (n=stevegt@cislunar.TerraLuna.Org) | |
| 00:35.14 | stevegt_1 | gotta unplug -- back in a couple hours, i think |
| 00:38.40 | brlcad | cya stevegt_1 |
| 01:46.54 | brlcad | ``Erik: you have 10.5 on your lappy? |
| 01:47.44 | brlcad | if you do, you see a crash if you configure --with-ogl and "attach ogl" in mged? |
| 02:06.13 | *** join/#brlcad stevegt_ (n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) | |
| 03:16.04 | ``Erik | compiling |
| 03:19.27 | yukonbob | hello, cadheads |
| 04:20.58 | ``Erik | it eated my X |
| 04:24.53 | ``Erik | http://brlcad.org/~erik/Xcrash.txt |
| 04:27.24 | Ralith | nom |
| 06:27.21 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 06:29.46 | CIA-32 | BRL-CAD: 0395.133.217.16 07http://brlcad.org * r1543 10/wiki/Main_Page: |
| 07:25.41 | *** join/#brlcad _clock_ (n=_sushi_@77-58-151-159.dclient.hispeed.ch) | |
| 08:10.13 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 08:11.28 | CIA-32 | BRL-CAD: 03d_rossberg * r34993 10/brlcad/trunk/src/libged/make_pnts.c: |
| 08:11.28 | CIA-32 | BRL-CAD: replaced c99 idioms with c89 compatible ones |
| 08:11.30 | CIA-32 | BRL-CAD: a const specifier in ged_make_pnts still need some consideration |
| 08:17.38 | *** join/#brlcad Don_ (n=Don@c-71-238-51-148.hsd1.mi.comcast.net) | |
| 09:24.01 | CIA-32 | BRL-CAD: 03Ralith 07http://brlcad.org * r1544 10/wiki/User:Ralith: Log for 2009-07-06 |
| 09:31.45 | CIA-32 | BRL-CAD: 03jdoliner * r34994 10/brlcad/trunk/src/proc-db/brepintersect.cpp: Added functions SegmentPolylineIntersect which is hopefully self explanatory in nature and Triangulate which takes an array of Polylines and renders the polygon as triangles, the later is presently a work in progress |
| 09:53.59 | *** join/#brlcad Don__ (n=Don@c-71-238-51-148.hsd1.mi.comcast.net) | |
| 09:54.44 | *** join/#brlcad starseeker (n=starseek@bz.bzflag.bz) | |
| 09:56.11 | *** join/#brlcad pacman872 (n=pacman87@pool-173-74-57-16.dllstx.fios.verizon.net) | |
| 10:07.11 | *** join/#brlcad mafm (n=mafm@83.42.152.74) | |
| 10:26.39 | d-lo | Merinin all |
| 10:27.17 | d-lo | Ralith: Hows it goin? I see the log entries, but its not telling me much :/ |
| 10:28.36 | d-lo | Since g3d isn't directly in the build structure of rt^3 (and rt^3 isnt a production module) is there any way I can get you to start checking in your attempts? (Regardless of whether they work or not) |
| 10:28.55 | d-lo | No one can provide help/guidance if we can't see the code :/ |
| 11:07.30 | CIA-32 | BRL-CAD: 03brlcad * r34995 10/brlcad/trunk/src/librt/primitives/nmg/nmg_ck.c: |
| 11:07.32 | CIA-32 | BRL-CAD: revert a change introduced in revision 8121, Mon Dec 27 22:46:05 1993, where the |
| 11:07.34 | CIA-32 | BRL-CAD: min_pt/max_pt comparison was (inadvertently?) changed from > to >= which is |
| 11:07.36 | CIA-32 | BRL-CAD: causing facetization problems when the structure is empty. this in turn causes |
| 11:07.38 | CIA-32 | BRL-CAD: tools that use nmg_triangulate_model() to incorrectly fail (e.g., g-stl). |
| 11:08.50 | d-lo | Wow... 1993 |
| 11:09.09 | d-lo | i was... a sophmore in HS.... wow. |
| 11:20.24 | CIA-32 | BRL-CAD: 03brlcad * r34996 10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: fix geomtry typo |
| 11:55.56 | CIA-32 | BRL-CAD: 03brlcad * r34997 10/brlcad/trunk/NEWS: |
| 11:55.58 | CIA-32 | BRL-CAD: fixed Invalid NMG empty output bug in g-stl that was reported by mdavis (irc) |
| 11:56.00 | CIA-32 | BRL-CAD: that was causing the tool to exit early. the problem seems to be two-fold, that |
| 11:56.02 | CIA-32 | BRL-CAD: the nmg_vface() routine had a minor logic error thinking it needs to abort and |
| 11:56.04 | CIA-32 | BRL-CAD: the nmg coming out of the dsp's tess routine is possibly an incomplete |
| 11:56.06 | CIA-32 | BRL-CAD: structure. |
| 12:30.38 | brlcad | is still hunting for the dsp bug, but is losing steam |
| 12:31.09 | ``Erik | the commits weren't for that? O.o |
| 12:32.13 | brlcad | it fixed half the problem |
| 12:32.42 | brlcad | dsp's tess() is doing something wrong in the construction of the nmg, that's what triggered the validity failure |
| 12:33.08 | ``Erik | shouldn't that trigger on the facetize cmd? |
| 12:33.14 | brlcad | the validity failure was weak, but arguably correct -- facetize happens to work simply because it doesn't validate |
| 12:33.25 | ``Erik | ahhh |
| 12:33.49 | ``Erik | HrrrmmMMmmMMmmm |
| 12:34.44 | ``Erik | non-validated facetization would be far faster and throw less away if the converter doesn't especially require a topologically closed surface, yes? |
| 12:34.54 | ``Erik | is thinking g-adrt shtuff |
| 12:35.09 | *** join/#brlcad docelic_ (n=docelic@78.134.197.78) | |
| 12:54.46 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) | |
| 13:02.00 | CIA-32 | BRL-CAD: 03brlcad * r34998 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: mass consistency/ws/style/comment cleanup while browsing |
| 13:02.03 | brlcad | this isn't "non-solid" validation |
| 13:02.20 | brlcad | this is "is the data structure being used and filled in the way it's supposed to" |
| 13:02.51 | brlcad | validating that there is geometry associated with an edge for every face, for example |
| 13:07.07 | CIA-32 | BRL-CAD: 03brlcad * r34999 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: couple more stragglers missed |
| 13:58.45 | CIA-32 | BRL-CAD: 03erikgreenwald * r35000 10/brlcad/trunk/src/adrt/ (Makefile.am slave/load_g.c): begin the ability to load a .g database into adrt |
| 13:58.56 | brlcad | woot |
| 14:04.18 | ``Erik | :r ../../conv/g-egg.c and some cleanup heh, nothing to w00t about :D |
| 14:04.38 | ``Erik | (neat rev #, tho) |
| 14:04.45 | brlcad | that was the woot :) |
| 14:04.56 | ``Erik | ah |
| 14:11.29 | d-lo | brlcad: You in today? |
| 14:11.43 | d-lo | also, might wanna get a hotel... they are going faaaaast. |
| 14:11.47 | d-lo | ;) |
| 14:11.55 | *** join/#brlcad BigAToo (n=BigAToo@64.74.225.82) | |
| 14:22.34 | brlcad | d-lo: soon as I find this bug or give up, but I've got too much invested to go just yet |
| 14:24.47 | d-lo | okay. Just giving you a heads up. 2 hotels dropped off the available list since I started this morning :/ |
| 14:53.36 | brlcad | woo hoo, think I got it |
| 14:54.14 | brlcad | they come on and go off repeatedly as rooms are released and rescheduled, you can sometimes watch and get lucky even |
| 14:55.10 | *** join/#brlcad alex_joni (n=juve@emc/board-of-directors/alexjoni) | |
| 15:02.49 | CIA-32 | BRL-CAD: 03brlcad * r35001 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: |
| 15:02.51 | CIA-32 | BRL-CAD: found the remaining bug that was provoking the dsp to not validate (nmg_vface() |
| 15:02.56 | CIA-32 | BRL-CAD: failure and 'nmg_unbreak_handler: no geometry for edge' failures). the problem |
| 15:03.00 | CIA-32 | BRL-CAD: was some final dsp region cleanup to mark the edges as real and compute the |
| 15:03.02 | CIA-32 | BRL-CAD: region/shell/edge-level geometry. |
| 15:03.06 | CIA-32 | BRL-CAD: 03erikgreenwald * r35002 10/isst/trunk/src/ (gui.c isst.h sql.c): use bu_vls for database and host names. Trim whitespace around names. |
| 15:06.35 | *** join/#brlcad elena (n=elena@89.136.118.141) | |
| 15:07.50 | brlcad | might want to s/strncpy/bu_strlcpy/ on those buffers |
| 15:08.57 | ``Erik | iirc, strlcpy isn't everywhere (and I thought I did s/strncpy/bu_vls/strcpy/ ) |
| 15:09.15 | brlcad | bu_strlcpy |
| 15:09.20 | brlcad | we have a wrapper |
| 15:09.52 | brlcad | implements it if strlcpy isn't available, otherwise identical signature |
| 15:10.19 | brlcad | bu_strlcat too, but didn't see those in use |
| 15:12.23 | elena | interesting. i never meet strlcpy before. |
| 15:12.31 | elena | learns new thing |
| 15:17.33 | ``Erik | after lunch :D |
| 15:27.06 | *** join/#brlcad mafm (n=mafm@83.42.152.74) | |
| 15:29.14 | *** join/#brlcad alex_joni (n=alex_jon@emc/board-of-directors/alexjoni) | |
| 17:14.13 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 17:33.02 | jdoliner | indianlarry? |
| 17:33.10 | jdoliner | are you around/ did you get my email? |
| 17:37.40 | indianlarry | hey joe |
| 17:37.55 | indianlarry | yes i got your email and will try and look into this evening |
| 17:39.20 | jdoliner | cool |
| 17:41.29 | ``Erik | mmm, green turtle |
| 17:45.59 | ``Erik | fails to see what bu_strlcpy will buy over bu_strcpy in this situation |
| 17:47.11 | ``Erik | can't buffer overflow and the gtk side guarantees the null terminator O.o |
| 18:05.58 | brlcad | probably nothing, I just noticed one unadorned strncpy from the original code |
| 18:06.54 | CIA-32 | BRL-CAD: 03erikgreenwald * r35003 10/brlcad/trunk/src/adrt/slave/load.c: get load working again. meh. |
| 18:10.48 | ``Erik | original code used char hostname[64]; and strncpy to avoid running past |
| 18:11.37 | CIA-32 | BRL-CAD: 03erikgreenwald * r35004 10/isst/trunk/src/gui.c: attempt to fill database and master hostnames using envirnment variables |
| 18:11.37 | ``Erik | there're still a couple static string buffers left |
| 18:13.07 | brlcad | ``Erik: what's the diff between field strength and threshold |
| 18:13.32 | ``Erik | field strength is per point, threshold is throughout the entire primitive |
| 18:14.10 | brlcad | how do they play together? |
| 18:14.12 | ``Erik | intends to make a wiki page (and eventually form 1 report) |
| 18:14.22 | brlcad | if I set a non-zero field strength on all points, is threhold ignored? |
| 18:14.29 | ``Erik | no |
| 18:14.30 | brlcad | and vice-versa |
| 18:15.24 | ``Erik | they work together, if you take a point of consideration, field strength and distance are used to compute the points contribution, if the sum of all points contribution is above the threshold, you are inside, otherwise you're outside |
| 18:16.34 | ``Erik | with a single control point, strength 1 and threshold one... changing str to 2 and leaving threshold 1 will have the same effect as leaving str 1 and changing threshold to .5 |
| 18:16.46 | brlcad | so random field strengths + zero threshold is a bunch of spheres no matter how close |
| 18:17.07 | ``Erik | 0 threshold means every point in existence is inside of the metaball |
| 18:18.23 | ``Erik | the formulae are tuned so threshold=1 is "natural" |
| 18:18.37 | brlcad | then is threshold distance-based (size/units-dependent?) |
| 18:18.46 | brlcad | what does natural mean? :) |
| 18:19.05 | ``Erik | threshold=1, 1 control point, fldstr=400 means a 400 unit radius sphere |
| 18:19.43 | ``Erik | (there's a reason for that, in s2) |
| 18:20.00 | brlcad | okay, so not distance |
| 18:20.01 | ``Erik | but 99.999% of outside usage will want threshold=1 |
| 18:20.48 | brlcad | what is method? |
| 18:21.00 | ``Erik | different algorithms O.o |
| 18:21.11 | ``Erik | crafting an explanation email? heh |
| 18:21.20 | brlcad | writing code |
| 18:21.25 | ``Erik | ah |
| 18:21.59 | jdoliner | what do our metaballs use as their falloff function? |
| 18:22.13 | ``Erik | jdoliner: that's what method defines... :D |
| 18:22.43 | jdoliner | I see |
| 18:23.03 | ``Erik | src/librt/primitives/metaball/metaball.c starting at line 244 |
| 18:23.07 | jdoliner | so we provide a number of different options |
| 18:23.11 | jdoliner | reading |
| 18:23.25 | brlcad | okay, more to the point of this.. which 'method' should I use? don't see any API defines/enums, so 0, 1, 42? |
| 18:24.05 | ``Erik | 'iso' is the same formula used to compute gravity or point charge strenght, blob is the '82 blinn blobby surface method, the unimplemented one is the tokyo metaball approximation |
| 18:24.45 | ``Erik | defines are in metaball.c:67 (should move those to rtgeom.h or raytrace.h if people want to muck with the programatically) |
| 18:24.50 | ``Erik | here, lemme do that |
| 18:25.07 | brlcad | found em |
| 18:25.25 | jdoliner | so is is inverse square |
| 18:25.38 | brlcad | an enum in wdb.h would work well since it needs it for mk_metaball |
| 18:27.33 | ``Erik | oh, I was putting it in rtgeom heh |
| 18:29.10 | ``Erik | contemplates rtgeomo.h vs wdb.h |
| 18:29.13 | CIA-32 | BRL-CAD: 03irpguardian * r35005 10/brlcad/trunk/src/proc-db/human.c: |
| 18:29.15 | CIA-32 | BRL-CAD: Made all limbs join together smoothly with themselves. Also added a feature to allow the creation |
| 18:29.17 | CIA-32 | BRL-CAD: of many humans at once using the -N command. |
| 18:30.05 | CIA-32 | BRL-CAD: 03erikgreenwald * r35006 10/brlcad/trunk/ (include/rtgeom.h src/librt/primitives/metaball/metaball.c): move metaball method definitions to a public header |
| 18:50.50 | brlcad | heh |
| 18:50.59 | brlcad | ``Erik: have you actually used mk_metaball anywhere yet? :) |
| 18:51.18 | ``Erik | hmmmm, newp? |
| 18:51.33 | brlcad | k, didn't think you had :) |
| 18:51.35 | ``Erik | don't think so |
| 18:52.59 | brlcad | the *verts[5] is a bit of a pita to work with :) |
| 18:53.09 | brlcad | at least if you have dynamic sets, having to allocate your points |
| 18:53.37 | ``Erik | *shrug* so make it a bu list |
| 18:53.59 | ``Erik | I think I was starting to put that together to support the proc-db |
| 18:54.04 | ``Erik | and got distracted |
| 18:54.11 | ``Erik | or, rather, redirected |
| 18:54.49 | CIA-32 | BRL-CAD: 03brlcad * r35007 10/brlcad/trunk/src/libwdb/wdb.c: fix an infinite loop and add the points in the order the user specified (in case it's significant for their usage, e.g. printing) |
| 18:55.19 | ``Erik | last halloween even heh, with the log of "stubbed out..." |
| 19:11.31 | brlcad | gah, rt_metaball_point_value_metaball() No implemented |
| 19:12.29 | brlcad | of course method "0" isn't implemented apparently.. |
| 19:17.07 | CIA-32 | BRL-CAD: 03brlcad * r35008 10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: don't bu_exit() inside the library as it cannot be caught like bu_bomb. clean up indent on STEPBACK too with a semi |
| 19:20.20 | CIA-32 | BRL-CAD: 03brlcad * r35009 10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: ws, comment cleanup |
| 19:25.11 | ``Erik | method 0 is the tokyo metaball, was redirected |
| 19:26.50 | brlcad | http://brlcad.org/tmp/mbug/mbug.png |
| 19:27.18 | brlcad | tis viewing-angle specific |
| 19:27.23 | brlcad | .g is up there |
| 19:27.51 | brlcad | is that right? |
| 19:30.29 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) | |
| 19:42.34 | CIA-32 | BRL-CAD: 03brlcad * r35010 10/brlcad/trunk/src/proc-db/metaball.c: |
| 19:42.36 | CIA-32 | BRL-CAD: hijack the stubbed metaballs example with something entirely different. this |
| 19:42.38 | CIA-32 | BRL-CAD: one creates a couple metaballs using the (now working) mk_metaball() routine as |
| 19:42.40 | CIA-32 | BRL-CAD: a means to show creation, and next manipulation. to be added is how to read |
| 19:42.45 | CIA-32 | BRL-CAD: them back in from the .g and combine them into one megametaball. |
| 19:49.21 | *** join/#brlcad BigAToo1 (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) | |
| 19:51.40 | CIA-32 | BRL-CAD: 03erikgreenwald * r35011 10/brlcad/trunk/src/adrt/slave/load_g.c: eliminate verbose stuff. wire stuff together. |
| 19:53.02 | ``Erik | that don't look right O.O |
| 20:23.30 | brlcad | welp, I just finished debugging a hellish bug early this morning, so that one is up to you! |
| 20:41.47 | Ralith | hehe |
| 20:42.07 | starseeker | Ralith: any more luck with Ogre+Qt? |
| 20:42.59 | Ralith | starseeker: none yet, nope; if I can't find anything useful in the GL intercept results I'll try the ogre centric approach |
| 20:43.28 | Ralith | it's getting pretty frustrating :/ |
| 20:45.22 | CIA-32 | BRL-CAD: 03brlcad * r35012 10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: minor cleanup, implement rt_metaball_free() |
| 20:45.36 | brlcad | Ralith: did you see d-lo's comments earlier today? |
| 20:46.05 | Ralith | brlcad: have now. |
| 20:46.09 | brlcad | you gotta commit something, else nobody can help -- even if it doesn't work |
| 20:47.01 | Ralith | alright, I'll try to. Haven't been doing so because it's been much more casting around across a wide variety of ideas than focusing on a particular approach. |
| 20:47.21 | brlcad | trying ideas is fine, but should still be committing |
| 20:47.34 | Ralith | kk |
| 20:47.35 | brlcad | as often as you save the file is fine -- i.e., if it compiles, commit it |
| 20:47.42 | Ralith | heh, okay, okay |
| 20:47.55 | brlcad | otherwise "it doesn't exist" |
| 20:48.06 | brlcad | and we have no idea what you've tried |
| 20:48.09 | Ralith | I'll tidy things up so that the test can be built cleanly without interfering with old g3d |
| 20:48.21 | brlcad | could be you tried the right idea weeks ago and had a minor bug |
| 20:48.33 | Ralith | good point. |
| 20:48.40 | brlcad | don't worry about the old g3d, we can resurrect that from svn if needed |
| 20:49.07 | Ralith | I'm hesitant to replace it with nothing but a broken testcase :/ |
| 20:49.11 | Ralith | but alright. |
| 20:50.49 | brlcad | if what you have is a testcase, that could just as easily be added alongside as well |
| 20:50.58 | Ralith | that's what I was saying |
| 20:51.24 | brlcad | how's that interfere? |
| 20:51.28 | Ralith | I mean, it's a little more involved than that, but it doesn't *do* anything, and interacts only minimally with the existing g3d codebase. |
| 20:52.10 | Ralith | I'd rewritten main.cxx to use the QT stuff w/ OgreScene as it would be used in the working app |
| 20:52.26 | Ralith | it would not be much work to just make all that ifdef'd |
| 20:52.53 | brlcad | don't ifdef it, either replace it or copy the file and commit the "second binary" |
| 20:52.59 | Ralith | at the time I had expected that I'd have something interesting working with OgreScene quickly, but seeing as that wasn't the case... |
| 20:53.23 | brlcad | all the more reason that you gotta be committing even more frequently from now on, even if busted |
| 20:53.23 | Ralith | I'll split it, then |
| 20:53.33 | Ralith | that should be even easier, actually |
| 20:53.39 | Ralith | just a matter of copy, revert, tweak cmakelists |
| 20:53.46 | brlcad | otherwise, all we have is an ogre commit and irc logs, and I'm sure you've done more than that |
| 20:55.23 | starseeker | Grrr - where is the "distribute" command used in opennurbs_ext.cpp on line 789 defined?? |
| 20:57.45 | brlcad | http://brlcad.org/xref/ident?i=distribute |
| 20:59.05 | brlcad | or were you using emacs, "make tags", then cursor over the word distribute on that line and hit M-. then enter |
| 20:59.37 | CIA-32 | BRL-CAD: 03erikgreenwald * r35013 10/isst/trunk/src/gui.c: stub in .g loading shtuff |
| 20:59.39 | brlcad | http://brlcad.org/xref/source/src/librt/opennurbs_ext.cpp <-- starting poitn |
| 21:00.24 | CIA-32 | BRL-CAD: 03erikgreenwald * r35014 10/brlcad/trunk/src/adrt/slave/load_g.c: parse string into filename/treename |
| 21:01.05 | brlcad | gives ``Erik cheesypoofs |
| 21:01.31 | starseeker | is surprised - i thought opennurbs_ext was compiled before brep |
| 21:02.12 | ``Erik | heh |
| 21:04.44 | brlcad | starseeker: doesn't matter |
| 21:04.49 | CIA-32 | BRL-CAD: 03brlcad * r35015 10/brlcad/trunk/src/libbu/bomb.c: |
| 21:04.51 | CIA-32 | BRL-CAD: annotate that bu_exit() should generally not be called by library code. it's |
| 21:04.53 | CIA-32 | BRL-CAD: intended use is by application codes for graceful exit. there are a few |
| 21:04.55 | CIA-32 | BRL-CAD: exceptions, but since the exit is not catchable, it's not very polite to |
| 21:04.57 | CIA-32 | BRL-CAD: applications and doesn't give them a chance to handle the situation or perform |
| 21:04.59 | CIA-32 | BRL-CAD: their own cleanup. |
| 21:05.05 | ``Erik | gets ready to start screaming "commit" over and over until he sees a msg from a certain user O:-) |
| 21:08.36 | CIA-32 | BRL-CAD: 03brlcad * r35016 10/brlcad/trunk/src/librt/opennurbs_ext.cpp: minor ws/indent consistency cleanup, remove author from headers |
| 21:12.21 | CIA-32 | BRL-CAD: 03r_weiss * r35017 10/brlcad/trunk/src/libged/make_pnts.c: cleanup |
| 21:12.45 | ``Erik | thinks he might have adrt sorta kinda loading .g tomorrow |
| 21:12.58 | starseeker | awesome! |
| 21:12.59 | CIA-32 | BRL-CAD: 03starseeker * r35018 10/brlcad/trunk/ (4 files in 2 dirs): (log message trimmed) |
| 21:13.05 | CIA-32 | BRL-CAD: Start cleaning up the opennurbs tree building routines/logic. Would prefer the |
| 21:13.07 | CIA-32 | BRL-CAD: flatness test to be a per-node affair (like, say, isLeaf) but need to hit my |
| 21:13.12 | CIA-32 | BRL-CAD: head on it a bit more first. For the time being, since there is still active |
| 21:13.16 | CIA-32 | BRL-CAD: debugging going on with indianlarry and this approach is not yet functional, |
| 21:13.20 | CIA-32 | BRL-CAD: sticking it into two temporary files that are EXTRA_DISTed. Once the trees are |
| 21:13.28 | CIA-32 | BRL-CAD: building successfully in testing, see about rewiring brep.cpp to use the |
| 21:14.37 | Ralith | adrt? |
| 21:14.49 | CIA-32 | BRL-CAD: 03erikgreenwald * r35019 10/brlcad/trunk/src/adrt/slave/load_g.c: db_walk_tree wants char**, not char* |
| 21:14.57 | ``Erik | interactive distributed raytracer thingymajigger |
| 21:15.49 | ``Erik | at the moment, it needs specially prepared geometry in a mysql database... .g loading would make it so people outside of my office and play with it... (related to the isst stuff) |
| 21:15.50 | Ralith | the really pretty one? |
| 21:16.09 | ``Erik | yeah, it's the engine that did the stryker in slat armor image for the gallery |
| 21:16.22 | Ralith | cool! |
| 21:16.28 | CIA-32 | BRL-CAD: 03brlcad * r35020 10/brlcad/trunk/src/librt/ (opennurbs_ext.cpp primitives/brep/brep.cpp): move the inline distribute() function over to the only place it's actually used in opennurbs_ext.cpp until it's actually needed elsewhere (in which case it probably belongs in the header if it needs to be inline) |
| 21:17.08 | ``Erik | now I'm going to roll my old bones home O.o |
| 21:17.36 | Ralith | why's adrt take so much power, btw? just 'cuz raytracing CSG is inherently a lot of work? |
| 21:18.10 | brlcad | no, not really |
| 21:18.26 | brlcad | it's because it's performing a different style of rendering, global illumination rendering |
| 21:18.40 | Ralith | oh, right, plain old rt is pretty fast |
| 21:18.43 | brlcad | which requires shooting several orders of magnitude more rays to fully simulate light transport |
| 21:19.00 | Ralith | but I ask because I've played with other (at least alleged) GI renderers before that don't take nearly so long |
| 21:19.09 | Ralith | raytracers, that is |
| 21:19.19 | brlcad | what are you comparing to? |
| 21:19.40 | brlcad | the time the stryker image took? |
| 21:19.45 | Ralith | yeah |
| 21:19.55 | brlcad | most GI renderers couldn't have handled that scene |
| 21:20.12 | Ralith | ahh. why's that? |
| 21:20.37 | brlcad | the level of detail in there is a bit misleading fromt he picture alone |
| 21:21.06 | brlcad | there aren't textures in use, there is actually geometry for every single blade of grass and leaf on tree |
| 21:21.20 | Ralith | pulls it up agin |
| 21:21.48 | brlcad | not to mention incredible detail inside the vehicle, every nut bolt and wire along with all of the internal components, not just a surface model |
| 21:21.55 | Ralith | oh damn. |
| 21:22.08 | Ralith | shame not much of that is visible |
| 21:22.19 | Ralith | had forgotten just how ridiculously detailed that scene was |
| 21:22.20 | brlcad | if it were, you wouldn't have gotten to see the picture :) |
| 21:22.27 | Ralith | hehe |
| 21:22.39 | Ralith | what was that modelled for, anyway? |
| 21:23.37 | brlcad | mostly just a demo |
| 21:23.47 | Ralith | that seems like an incredible amount of modeling work for a demo |
| 21:24.30 | brlcad | also notice the number of rays fired.. 8 *trillion* rays is a lot of rays |
| 21:24.44 | Ralith | enough that it's hard to get a sense of scale. |
| 21:24.57 | Ralith | certainly did't leave any visible artifacts. |
| 21:26.20 | Ralith | what generated the trees? |
| 21:26.54 | brlcad | some plugin, it was imported |
| 22:12.33 | ``Erik | the trees and grass came from blender, iirc |
| 22:13.31 | ``Erik | adrt/tie doesn't do CSG, it's straight triangle rendering, but every pixel is something like 256 primary rays... in a path tracing system O.o |
| 22:13.45 | ``Erik | (antialiasing, depth of field, etc) |
| 22:14.45 | ``Erik | with a simple phong shader, it renders a couple dozen 1024x768 frames a second |
| 22:15.20 | ``Erik | (it doesn't require much power at all, that's why it can go above and beyond like that styker image) |
| 22:35.39 | CIA-32 | BRL-CAD: 03Ebautu 07http://brlcad.org * r1545 10/wiki/More_Changelog: July 8 activity |
