| 00:34.10 | CIA-109 | BRL-CAD: 03starseeker * r47407 10/brlcad/trunk/src/libged/simulate/simrt.c: Need unused on these parameters for now to allow strict build to succeed |
| 01:05.58 | *** join/#brlcad DarkCalf (DC@173.231.40.98) |
| 01:14.52 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 01:50.39 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3214 10/wiki/Early_Raytracing_History: Flesh out intro, add list of MAGIC documents (most of the links not live yet) |
| 02:01.27 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) |
| 02:02.26 | Technicus | ello . . . I have about no extensive practical CAD or significant knowledge and I am attempting to design a cabin for a motorhome. I am undertaking the opportunity to learn what I can with this project. Currently I would like to start desiging the framework, would BRL-CAD be an adaquat application for this task? |
| 02:39.25 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) |
| 03:05.08 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3215 10/wiki/Early_Raytracing_History: Stub in some more categories and tables, smattering of links - GIFT and BRL-CAD will have much longer lists than MAGIC! |
| 03:23.00 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3216 10/wiki/Early_Raytracing_History: Another comgeom model report |
| 03:31.10 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3217 10/wiki/Early_Raytracing_History: com-geom debugger |
| 03:32.20 | *** join/#brlcad abhi2011 (~chatzilla@117.200.81.173) |
| 03:37.45 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3218 10/wiki/Early_Raytracing_History: /* GIFT */ add another GIFT/COMGEOM application report |
| 05:27.39 | *** join/#brlcad abhi2011 (~chatzilla@117.200.81.254) |
| 05:27.54 | CIA-109 | BRL-CAD: 03abhi2011 * r47408 10/brlcad/trunk/src/libged/simulate/ (simrt.c simutils.c simutils.h): |
| 05:27.54 | CIA-109 | BRL-CAD: Normals already encountered, were not being added to the list of normals, fixed |
| 05:27.54 | CIA-109 | BRL-CAD: that. There are situations where summing the normals in the overlapping surface |
| 05:27.54 | CIA-109 | BRL-CAD: alone will not give the exact direction from which a body is hitting another |
| 05:27.54 | CIA-109 | BRL-CAD: body. But simply using the velocity also does not work for all cases to find |
| 05:27.54 | CIA-109 | BRL-CAD: this direction. Somewhere these 2 ways need to be merged or chosen from , based |
| 05:27.55 | CIA-109 | BRL-CAD: upon criteria. |
| 05:34.38 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3219 10/wiki/Early_Raytracing_History: tweaks |
| 05:36.59 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3220 10/wiki/Early_Raytracing_History: /* MAGIC */ tweak |
| 08:22.08 | *** join/#brlcad b0ef (~b0ef@78.58.34.95.customer.cdi.no) |
| 09:39.04 | *** join/#brlcad abhi2011 (~chatzilla@117.200.89.195) |
| 11:50.56 | brlcad | Technicus: it depends on your goals, but for the basic modeling for layout and visualization, sure |
| 11:51.26 | brlcad | if you're hoping for it to spit out blueprints or construction parts lists, then not so adaquate |
| 11:58.31 | cvds_ | is it possible to get the actual dimensions of a primitive from within a combination ? |
| 11:58.40 | cvds_ | (with all matrices in the tree applied) |
| 12:05.14 | CIA-109 | BRL-CAD: 03Caddui 07http://brlcad.org * r3221 10/wiki/NURBS_TODO: |
| 12:25.04 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3222 10/wiki/NURBS_TODO: Reverted edits by [[Special:Contributions/Caddui|Caddui]] ([[User talk:Caddui|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 12:25.58 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Caddui]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 12:34.07 | cvds_ | aha, using l with the full path seems to provide just that |
| 12:45.15 | Technicus | brlcad: Thanks . . . that might possibly be about enough to get me started. |
| 13:12.27 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 13:27.28 | brlcad | cvds_: yep, exactly that way ;) |
| 13:27.54 | brlcad | you could also clone the object, xpush, then l the primtive |
| 13:28.34 | brlcad | you can get dimensions on other non-primitive objects on a line-of-sight basis using the ruler tool, the ADC angle-distance-cursor, and/or nirt |
| 13:31.30 | cvds_ | brlcad: I can not push, same sub-combination used in other bigger combinations but rotated and translated |
| 13:32.17 | cvds_ | i will check those other tools later /me makes mental notes. |
| 13:32.32 | cvds_ | Now to fix a clean way for these not critical overlaps ... |
| 13:34.17 | cvds_ | I guess I just have to clip the corners of these parts |
| 13:36.39 | brlcad | cvds_: xpush is not the same as push :) |
| 13:36.51 | brlcad | xpush will split multiply referenced objects |
| 13:37.51 | brlcad | I'd recommend avoiding xpush/push regardless just because you lose a localized coordinate space on the primitives, but it can be useful if you repeatedly need their values in global position |
| 13:38.52 | brlcad | that's also why I suggested clone first, since that will perform a deep copy that you can "destroy" with xpush, just to peek at the values in global position |
| 13:40.23 | cvds_ | brlcad: ah with clone, that makes sense :) |
| 13:40.45 | cvds_ | hrmz... this design tidbit is becoming a nightmare |
| 13:50.41 | *** join/#brlcad abhi2011 (~chatzilla@117.200.87.121) |
| 14:03.05 | cvds_ | phew made it fit |
| 14:15.28 | *** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz) |
| 14:15.40 | pawleeq | Hello |
| 14:16.52 | pawleeq | I have written a short article introducing BRL-CAD to wider czech public: http://www.abclinuxu.cz/clanky/brl-cad-strucne-predstaveni |
| 14:33.33 | cvds_ | hmm copymat on the quickref says that I can copy a matrix from one path to another path... but when I try this its complaining about arcs ? |
| 14:35.46 | cvds_ | (I want to use it to move an object to the exact space of another object so that I can subtract it) |
| 14:46.40 | cvds_ | and googling this only finds c files |
| 14:48.22 | cvds_ | hmm Ensure that each argument contains exactly one slash <-- hint located |
| 15:06.30 | cvds_ | yup that worked |
| 16:11.14 | ``Erik | nice http://article.gmane.org/gmane.comp.version-control.git/57918 |
| 16:14.53 | abhi2011 | I am trying to use rt_gen_circular_grid() to generate a circular grid of rays (its defined in mkbundle.c) |
| 16:15.08 | abhi2011 | int rt_gen_circular_grid(struct xrays *rays, const struct xray *center_ray, fastf_t radius, const fastf_t *up_vector, fastf_t gridsize) |
| 16:15.50 | abhi2011 | so here gridsize is the size of the edge of the square, which bounds the circle of radius = radius |
| 16:16.48 | abhi2011 | I think thats the case, but I would like to be certain of that |
| 17:02.41 | ``Erik | iirc, that func does a funky polar fill, 'gridsize' comes out to some combination of layers and radians |
| 17:02.51 | ``Erik | so the outer rings are less dense than the inner ones |
| 17:03.31 | ``Erik | there was a similar one that indianlarry bolted in a few months back due to different ray density requirements, I think |
| 17:15.53 | CIA-109 | BRL-CAD: 03abhi2011 * r47409 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simrt.c simrt.h): Started shooting for getting the depth and points on surface of object B |
| 17:27.45 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 17:36.05 | abhi2011 | Erik: ok I thought that rays would be generated in a square grid, with those rays that lie within the circle getting accepted in the structure returned to the caller |
| 17:37.04 | brlcad | pawleeq: ah, that was you! .. saw that a couple days ago |
| 17:37.12 | brlcad | awesome |
| 17:37.30 | brlcad | my czech-to-english translator totally failed on it, though :) |
| 17:38.00 | brlcad | looks like ia nice detailed discussion got started |
| 18:08.08 | pawleeq | brlcad: czech is quite hard to learn and even impossible for automated translators |
| 18:12.09 | pawleeq | the discussion is full of trolls flaming about CATIA and how BRL-CAS is unusable for construction design |
| 18:13.10 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3223 10/wiki/Early_Raytracing_History: /* MAGIC */ Add links to MAGIC docs |
| 18:17.43 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3224 10/wiki/Early_Raytracing_History: /* MAGIC */ tweaks |
| 19:21.30 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.114) |
| 19:33.50 | CIA-109 | BRL-CAD: 03starseeker * r47410 10/brlcad/trunk/doc/docbook/system/man1/en/coil.xml: fix coil man page |
| 19:35.24 | CIA-109 | BRL-CAD: 03starseeker * r47411 10/geomcore/trunk/doc/docbook/CMakeLists.txt: remove debug blather |
| 20:10.10 | CIA-109 | BRL-CAD: 03abhi2011 * r47412 10/brlcad/trunk/src/libged/simulate/simrt.c: Trying to fix a bug related to generating a circular grid of rays along a specific direction. |
| 20:18.17 | CIA-109 | BRL-CAD: 03brlcad * r47413 10/brlcad/trunk/include/magic.h: match BU_CKMAG() |
| 20:20.34 | CIA-109 | BRL-CAD: 03brlcad * r47414 10/brlcad/trunk/include/fb.h: |
| 20:20.34 | CIA-109 | BRL-CAD: fix abort on 64-bit power7 (big endian) due to bad magic number checking. the |
| 20:20.34 | CIA-109 | BRL-CAD: cast through intptr_t was causing a zero-value to result, failing the magic |
| 20:20.34 | CIA-109 | BRL-CAD: number test. change the macro to just treat the ifp pointer as a pointer to a |
| 20:20.34 | CIA-109 | BRL-CAD: uint32_t and we should get the number we were looking for. |
| 20:23.35 | CIA-109 | BRL-CAD: 03brlcad * r47415 10/brlcad/trunk/include/fb.h: dumbass. else if. |
| 21:21.22 | CIA-109 | BRL-CAD: 03brlcad * r47416 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: don't fake the alloc. sizes might be null and we'll just bomb. |
| 21:27.56 | CIA-109 | BRL-CAD: 03brlcad * r47417 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: do what was done for v4, validate the dsp dimensinos are non-zero |
| 21:41.53 | CIA-109 | BRL-CAD: 03brlcad * r47418 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: vls might be null, so don't try to get the address. allow 1x1 dsp without warning. fix y-axis warning. |
| 21:47.35 | CIA-109 | BRL-CAD: 03brlcad * r47419 10/brlcad/trunk/include/rtgeom.h: add a TODO. dsp_name should probably be a pointer so we know when it's been initialized and so the dsp struct itself will consume less memory. |
| 21:48.09 | CIA-109 | BRL-CAD: 03brlcad * r47420 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: still have to init the vls, otherwise we can't print it even if it's empty. |
| 21:51.14 | *** part/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz) |
| 22:12.38 | CIA-109 | BRL-CAD: 03starseeker * r47421 10/brlcad/trunk/src/other/ (7 files in 2 dirs): Add a vanilla check-in of clipper 4.6 - Bob needs to track some tweaks he is making to it. Extra dist it until it goes live. |
| 22:28.12 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) |
| 22:48.20 | brlcad | starseeker: er, you changed it from -l to -L but then documented extra detail on -l ... ;) |
| 22:49.37 | CIA-109 | BRL-CAD: 03brlcad * r47422 10/brlcad/trunk/NEWS: cliff expanded the manpage on how the -l/-L parameter works |
| 22:51.00 | brlcad | ah, nevermind.. misread the patch .. cool |