00:36.33 |
*** join/#brlcad nmz787_i
(~nmccorkx@134.134.137.71) |
00:48.34 |
*** join/#brlcad FreezingAlt
(~FreezingC@135.0.41.14) |
01:34.02 |
*** join/#brlcad ries
(~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl) |
04:01.32 |
*** join/#brlcad Notify
(~notify@66-118-151-70.static.sagonet.net) |
04:37.38 |
*** join/#brlcad YashM
(~YashM@117.198.13.37) |
05:02.47 |
*** join/#brlcad Stragus
(~alexis@modemcable090.29-19-135.mc.videotron.ca) |
05:23.15 |
*** join/#brlcad YashM_
(~YashM@117.222.65.0) |
05:49.16 |
*** join/#brlcad YashM__
(~YashM@117.222.65.0) |
06:59.58 |
*** join/#brlcad YashM
(~YashM@117.215.32.202) |
07:43.53 |
*** join/#brlcad mpictor
(~mark@c-69-136-183-213.hsd1.in.comcast.net) |
07:48.22 |
*** join/#brlcad Izakey
(~Izak@41.205.22.13) |
08:15.50 |
*** join/#brlcad sprakash
(~sidd_prak@14.139.82.6) |
08:33.55 |
*** join/#brlcad merzo
(~merzo@user-94-45-58-141.skif.com.ua) |
08:50.15 |
*** join/#brlcad mpictor_
(~mark@c-68-39-98-222.hsd1.nj.comcast.net) |
08:57.04 |
*** join/#brlcad Sricharanized
(~raincrash@116.202.9.124) |
09:17.35 |
*** join/#brlcad merzo
(~merzo@92.60.189.225) |
09:46.41 |
*** join/#brlcad mihaineacsu
(~mihaineac@92.81.153.81) |
09:53.17 |
*** join/#brlcad
Sricharanized1 (~raincrash@116.202.9.124) |
10:22.08 |
*** join/#brlcad teepee-
(bc5c2134@gateway/web/freenode/ip.188.92.33.52) |
10:31.06 |
*** join/#brlcad YashM
(~YashM@117.222.18.72) |
10:51.21 |
*** join/#brlcad sprakash
(~sidd_prak@14.139.82.6) |
11:16.55 |
*** join/#brlcad YashM
(~YashM@117.198.11.51) |
11:29.03 |
*** join/#brlcad mihaineacsu
(~mihaineac@92.81.153.81) |
11:53.31 |
*** join/#brlcad Sricharanized
(~raincrash@116.202.168.73) |
13:08.30 |
*** join/#brlcad YashM
(~YashM@59.88.31.246) |
13:16.27 |
*** join/#brlcad sprakash
(~sidd_prak@14.139.82.6) |
14:24.01 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
14:58.31 |
kintel |
brlcad: Any news on GSoC this year? |
15:01.36 |
teepee- |
hehe, maybe the question is too early. still
totally exhausted by GCI :) |
15:01.46 |
teepee- |
that was quite some action |
15:09.53 |
*** join/#brlcad sofat
(~sofat@202.164.45.198) |
15:59.20 |
*** join/#brlcad sofat
(~sofat@202.164.45.198) |
16:33.50 |
Notify |
03BRL-CAD:starseeker * 64108
brlcad/trunk/src/libbrep/shape_recognition_cylinder.cpp: More
thinking about how to process cylinder shapes. |
16:39.08 |
*** join/#brlcad FreezingCold
(~FreezingC@135.0.41.14) |
16:58.37 |
*** join/#brlcad nmz787_i
(nmccorkx@nat/intel/x-cextyeigvmmjpmud) |
17:01.45 |
*** join/#brlcad nmz787_i1
(~nmccorkx@192.55.55.37) |
17:08.09 |
*** join/#brlcad mmu_man
(~revol@vaf26-2-82-244-111-82.fbx.proxad.net) |
17:33.35 |
*** join/#brlcad sprakash
(~sidd_prak@14.139.82.6) |
17:33.45 |
*** join/#brlcad gaganjyot
(~gaganjyot@27.255.242.59) |
17:33.49 |
gaganjyot |
#librecad |
18:20.34 |
*** join/#brlcad yiyus
(1242712427@je.je.je) |
18:36.11 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
18:39.09 |
*** join/#brlcad shaina
(~shaina@202.164.53.117) |
18:50.58 |
brlcad |
kintel: not yet |
18:55.51 |
nmz787_i1 |
so is it bad to union two primitives into a
region, then union that region into another region or
primitive? |
18:56.05 |
nmz787_i1 |
it seems to work, but mged prints warnings
constantly |
18:56.12 |
brlcad |
nmz787_i1: did you delete your cmake cache
before that cmake run? |
18:56.55 |
brlcad |
nmz787_i1: and yes, unioning two *overlapping*
regions is considered a modeling error |
18:57.34 |
brlcad |
making something a region is when you go from
it being a description of a volume to being actual physical
material occupying a volume |
18:57.37 |
nmz787_i1 |
hmm, I can't remember, I think so, but I may
have just done rm -r ./build* from the svn-repo dir |
18:57.53 |
brlcad |
so you can combine shapes into a new shape no
problem |
18:58.38 |
brlcad |
but to combine two physical object is like in
star trek where you beam one object into another .. can't have two
objects occupying the same space |
18:58.46 |
nmz787_i1 |
I think this or the next line is what mged was
warning about
https://github.com/nmz787/python-brlcad-tcl/blob/master/28BYJ_48__motor_example.tcl#L12 |
19:00.02 |
nmz787_i1 |
wasn't sure how to do subsequent unions, or if
I could do intersect and subtractions in the same line, or if I
could use parentheses to separate the + and - operations |
19:00.32 |
nmz787_i1 |
but indeed using that tcl script then using
g-stl produces what I expect as output |
19:00.45 |
brlcad |
yeah, line 11 (along with a few others) should
be combs first |
19:00.46 |
nmz787_i1 |
https://github.com/nmz787/python-brlcad-tcl/blob/master/28BYJ_48__motor_example.stl |
19:00.58 |
brlcad |
you can just replace "r ..." with "comb
..." |
19:01.19 |
nmz787_i1 |
ah |
19:01.20 |
nmz787_i1 |
ok |
19:01.33 |
brlcad |
"comb whatever.c u a.s u b.s" and then make an
"r whatver.r u whatever.c" |
19:01.43 |
brlcad |
you make the .r when you want it to
exist |
19:01.53 |
brlcad |
e.g., as an instantiated part |
19:01.53 |
nmz787_i1 |
ah |
19:01.57 |
nmz787_i1 |
hm |
19:02.09 |
nmz787_i1 |
I was reading a oed PDF a few nights
ago |
19:02.16 |
brlcad |
so like if I had a bolt, i'd make a bolt.c
shape, then have a bolt1.r a bolt2.r etc for all my actual
bolts |
19:02.21 |
nmz787_i1 |
was trying to figure out how to rotate a
region/instance |
19:02.34 |
nmz787_i1 |
ah |
19:02.36 |
nmz787_i1 |
ok |
19:03.24 |
brlcad |
the quick reference card mentions this very
briefly/concisely about
regions/parts/solids/groups/assemblies |
19:03.57 |
nmz787_i1 |
the CAD demo in there? |
19:04.06 |
brlcad |
if you're familiar with other CAD systems, our
notion of a region is basically that of a part, a group is that of
an assembly, and sub-region combinations are just hierarchical
feature edits |
19:04.06 |
nmz787_i1 |
C A D |
19:04.12 |
brlcad |
yeah |
19:04.47 |
nmz787_i1 |
hmm, no not too jargon-knowledgeable |
19:05.00 |
brlcad |
then nothing to worry about getting confused
about ;) |
19:05.35 |
brlcad |
from a CS perspective, a region is literally a
simple bit flag ... but it's an important bit that means "this
thing occupies actual space" |
19:05.42 |
brlcad |
otherwise, everything is just collections and
shapes |
19:06.02 |
nmz787_i1 |
I don't have the script now, but in my
multi-part example, I try to instantiate that motor, then rotate
it, then add a cup around it (two rcc, one smaller and
subtracted) |
19:06.16 |
nmz787_i1 |
I remember trying to use Z to hide
everything |
19:06.20 |
nmz787_i1 |
then e something.c |
19:06.26 |
nmz787_i1 |
then orot 90 90 90 |
19:06.27 |
nmz787_i1 |
I think |
19:06.28 |
brlcad |
nods |
19:06.38 |
brlcad |
ah, yeah missed a step |
19:06.55 |
nmz787_i1 |
but it didn't work, again, can't remember
exactly what I was doing, and it's at home now |
19:06.57 |
brlcad |
"e" just means "draw this" |
19:07.21 |
brlcad |
with mged, you need to tell mged what and how
you intend to rotate with more specificity |
19:07.35 |
brlcad |
the oed manual is the place for that but it's
admittedly complicated |
19:07.54 |
brlcad |
rotations are actually why it's complicated
too .. they need a defined keypoint, so you specify that |
19:08.07 |
brlcad |
B something.g |
19:08.20 |
brlcad |
oed / something.c/path/to/primitive |
19:08.23 |
brlcad |
orot 90 90 90 |
19:08.34 |
brlcad |
accept |
19:08.41 |
brlcad |
(or reject or keep orot'ing) |
19:08.52 |
brlcad |
B == Z + e something.c |
19:09.03 |
nmz787_i1 |
ah, yeah, the oed command was
confusing |
19:09.13 |
nmz787_i1 |
i couldn't tell why i couldn't rotate the
whole .c |
19:09.31 |
brlcad |
yeah it is ... we're going to make that step
go away eventually with implicit keypoints, but right now it's
explicit |
19:09.47 |
nmz787_i1 |
keypoints are fine I think |
19:09.51 |
brlcad |
which means it needs to know what point to
rotate about and that's where the whatever/path/to/something comes
in |
19:10.02 |
nmz787_i1 |
since so far I'm just using 0 0 0 for the
centers or bottoms of things |
19:10.36 |
brlcad |
right, but orot doesn't know what you
want |
19:10.39 |
nmz787_i1 |
and I'm creating these tcl scripts with
object-oriented Python, so keeping track of the center/key is
easy... just give my object that attribute |
19:10.40 |
brlcad |
oed tells it |
19:11.20 |
nmz787_i1 |
also, I couldn't tell what lpath and rpath
meant... left and right? |
19:11.27 |
brlcad |
yes |
19:11.45 |
brlcad |
left-hand path and right-hand path
.. |
19:12.07 |
brlcad |
which is basically a complicated way of
answering "where do you want the matrix edit performed" |
19:12.21 |
brlcad |
(note rotating/translating primitives is much
different) |
19:12.27 |
nmz787_i1 |
so can I say oed mygroup.c
mygroup.c? |
19:12.46 |
brlcad |
no, it still needs a full right-hand
side |
19:12.49 |
nmz787_i1 |
or do I have to make a helper function to
rotate each primitive the group contains? |
19:13.24 |
brlcad |
if you want to rotate mygroup and it's at the
origin such that you don't care, then the right-hand side can be
basically any object |
19:13.34 |
brlcad |
oed / mygroup.c/path/to/anything |
19:13.39 |
nmz787_i1 |
oh, the right side sets the origin? |
19:13.44 |
brlcad |
yes |
19:13.44 |
nmz787_i1 |
rpath |
19:13.49 |
nmz787_i1 |
hrmm |
19:13.55 |
nmz787_i1 |
that wasn't obvious at all |
19:14.07 |
nmz787_i1 |
I assumed it was like directory and file
paths |
19:14.13 |
brlcad |
it is that too |
19:16.08 |
*** join/#brlcad sofat
(~sofat@202.164.45.208) |
19:16.39 |
brlcad |
e.g., say I have a filesytem instead of object
paths |
19:16.50 |
brlcad |
<PROTECTED> |
19:16.56 |
brlcad |
the oed command would be: oed /
usr/local/bin/reboot |
19:17.19 |
brlcad |
it basically needs a file (really any file) in
order to modify any directory |
19:18.46 |
brlcad |
reboot in this example is not the thing being
modified, it's between the "/" and "usr", i.e., we're modifying usr
in the top-level dir |
19:19.36 |
brlcad |
we only had to specify a file (reboot),
because this is a crazy-ass filesystem that doesn't know how to
change directories without a file handle |
19:19.46 |
brlcad |
that's 3d geometry for you ;) |
19:21.01 |
starseeker |
notes appleseed has posted a
summery of their GSoC 2014 efforts:
http://google-opensource.blogspot.com/2015/01/google-summer-of-code-wrap-up-appleseed.html |
19:21.43 |
starseeker |
is amused by the box
rendering |
19:23.55 |
starseeker |
nice - uses bezier curves |
19:24.17 |
brlcad |
sweet |
19:25.24 |
starseeker |
brlcad: was there ever any follow up with them
on the idea of them providing an API to let us shoot rays and feed
them into their system? |
20:12.16 |
ries |
it's amazing what guy's can do :s |
20:18.15 |
starseeker |
growls - sf is acting up
again |
20:25.35 |
starseeker |
pokes
Notify |
20:28.40 |
``Erik |
last BRL-CAD commit email I got was 11:30,
r64108 O.o is sf not sending them in a timeline manner? |
20:28.59 |
``Erik |
checked his procmail log to
verify... |
20:48.24 |
*** join/#brlcad teepee_
(~teepee@gateway/tor-sasl/teepee) |
20:53.06 |
*** join/#brlcad nmz787_i
(~nmccorkx@192.55.55.37) |
21:10.40 |
Notify |
03BRL-CAD:starseeker * 64110
(brlcad/trunk/src/libbrep/shape_recognition_cone.cpp
brlcad/trunk/src/librt/test_shape_recognition.cpp): Create cones -
both this and the cyl routine are missing some shapes - need to
figure out why. |
22:13.41 |
Notify |
03BRL-CAD:starseeker * 64111
brlcad/trunk/src/libbrep/shape_recognition_cone.cpp: Forgot the
tolerance in tests. |
22:23.20 |
Notify |
03BRL-CAD:starseeker * 64112
(brlcad/trunk/src/libbrep/shape_recognition.cpp
brlcad/trunk/src/libbrep/shape_recognition_cylinder.cpp): Wrong
place for the loop test. |
23:00.52 |
*** join/#brlcad merzo
(~merzo@99-15-133-95.pool.ukrtel.net) |
23:20.36 |
*** join/#brlcad teepee_
(~teepee@gateway/tor-sasl/teepee) |
23:26.30 |
ignacio |
brlcad, ping |