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 |