01:31.51 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
04:11.16 |
*** join/#brlcad dtidrow_desk
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
04:40.55 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.89.98) |
05:31.21 |
*** join/#brlcad hackrat
(~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
06:43.57 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.80.54) |
06:44.01 |
CIA-109 |
BRL-CAD: 0323.19.56.171 07http://brlcad.org * r3191
10/wiki/Talk:Main_Page: |
06:50.53 |
*** join/#brlcad archivist
(~archivist@host81-149-189-98.in-addr.btopenworld.com) |
07:10.23 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.89.69) |
08:15.19 |
*** join/#brlcad abhi2011_
(~chatzilla@117.200.86.172) |
08:31.34 |
*** join/#brlcad merzo
(~merzo@109-45-133-95.pool.ukrtel.net) |
11:07.28 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.89.50) |
11:41.38 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
12:22.00 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.85.236) |
12:40.08 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
12:46.32 |
*** join/#brlcad merzo
(~merzo@72-3-133-95.pool.ukrtel.net) |
13:31.16 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.84.105) |
13:54.23 |
CIA-109 |
BRL-CAD: 03Sean 07http://brlcad.org * r3192
10/wiki/Talk:Main_Page: Reverted edits by
[[Special:Contributions/23.19.56.171|23.19.56.171]] ([[User
talk:23.19.56.171|Talk]]); changed back to last version by [[User:X
Tin Basher|X Tin Basher]] |
13:54.36 |
CIA-109 |
BRL-CAD: 03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:23.19.56.171]] with an
expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
14:15.35 |
brlcad |
abhi2011: funny coincidence, someone on the
bullet channel was bitching just yesterday about bullet's internal
ray tracing sucking |
14:16.00 |
brlcad |
told them about your efforts to integrate with
librt, excitedness ;) |
14:27.27 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
14:29.58 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.91.35) |
14:30.07 |
abhi2011 |
brlcad: cool :) |
14:30.19 |
abhi2011 |
so there is someone replying in that channel
:P |
14:31.00 |
abhi2011 |
I have been trying to figure out a algorithm
that uses all the normal and curvature info to generate the
points |
14:31.22 |
abhi2011 |
guess I ll first go with the box-box
case |
14:31.50 |
abhi2011 |
a important thing to figure out is the
direction in which an object is penetrating another
object |
14:32.08 |
abhi2011 |
as the normal has to point along that
direction |
14:33.36 |
abhi2011 |
currently I ll just check to see which ever
dimension is the least in the overlapping volume , i.e. if the
object is penetrating another along the z axis, then the dimension
of the overlap region along the z axis will be least |
14:35.14 |
abhi2011 |
of course the best way would be to make the
normal point according to the curvature of the 2nd body |
14:39.16 |
abhi2011 |
like so :
https://docs.google.com/drawings/d/1Fp44t9AcZZurbNufXti64u-23CRjC49Z3r0WSmim5tU/edit |
14:40.23 |
abhi2011 |
but then rays hitting the curving surface
would give many normals, so the proper normal has to be chosen,
which can be got by vector summing I guess |
14:45.59 |
abhi2011 |
funny warning about the IGNORE symbol being
redefined : http://bin.cakephp.org/view/1298213576 |
14:46.24 |
brlcad |
yeah, that channel is quite most of the time,
but every now and then a discussion sparks up |
14:47.39 |
brlcad |
good to know about the IGNORE
redefinition |
14:52.10 |
brlcad |
abhi2011: we actually include measures to
define our IGNORE macro without conflicting with the windows
macro |
14:52.23 |
brlcad |
so somewhere a windows header is getting
included without our usual protections |
14:53.44 |
*** join/#brlcad abhi2011_
(~chatzilla@117.200.84.102) |
14:53.45 |
brlcad |
abhi2011: AHA ... I think I found the problem
-- you must include common.h before any/all *system*
headers |
14:54.01 |
abhi2011_ |
ok |
14:54.25 |
brlcad |
you saw my other comments? |
14:55.52 |
brlcad |
irc problems? |
15:03.30 |
abhi2011 |
brlcad: yes , yes I saw them till : good to
know about the IGNORE redefinition and then AHA |
15:03.47 |
abhi2011 |
yeah, disconnected in between |
15:05.44 |
abhi2011 |
yep I ll move up common.h |
15:10.34 |
abhi2011 |
hmm ,warning is still there though |
15:11.54 |
abhi2011 |
I think the issues is that a similar macro has
been defined in both places |
15:11.57 |
abhi2011 |
not the order |
15:12.14 |
abhi2011 |
winbase.h & common.h |
15:20.11 |
CIA-109 |
BRL-CAD: 03abhi2011 * r47378
10/brlcad/trunk/src/libged/simulate/ (9 files): |
15:20.33 |
abhi2011 |
ok hope the commit went through fine,
committing from windows with tortoise svn for the 1st
time |
15:35.38 |
abhi2011 |
so is there a function already, which lets me
check if a solid is present in the tree of a comb |
15:36.26 |
abhi2011 |
I can write one to recursively check the tree
of a comb, and if it find the solid, then return true, but perhaps
one already exists |
15:37.03 |
abhi2011 |
I need it for checking which comb, a solid
belongs to , when rt gives me a solid at the point where a ray
exits |
15:37.26 |
abhi2011 |
I then need to sum the normal only for that
comb(rigid body) |
15:38.46 |
abhi2011 |
dbfind is there I see |
15:46.49 |
abhi2011 |
yep, ged_find, does exactly that , traversing
in LNR order, will modify it a bit(in my own file) :P |
16:42.13 |
CIA-109 |
BRL-CAD: 03abhi2011 * r47379
10/brlcad/trunk/src/libged/simulate/ (simutils.c simutils.h): Added
a function to check if a solid is present in a comb, required for
checking which rigid body(a comb), a particular solid belongs to ,
while raytracing. |
18:04.29 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
18:52.50 |
CIA-109 |
BRL-CAD: 03abhi2011 * r47380
10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h
simulate.h): |
18:54.23 |
CIA-109 |
BRL-CAD: 03abhi2011 * r47381
10/brlcad/trunk/src/libged/simulate/simrt.c: Added code for
normals |
19:10.11 |
*** join/#brlcad Forth
(~Forth@92.242.118.253) |
19:11.55 |
*** part/#brlcad Forth
(~Forth@92.242.118.253) |
19:16.19 |
CIA-109 |
BRL-CAD: 03abhi2011 * r47382
10/brlcad/trunk/src/libged/simulate/simrt.c: More supporting code
to test if the normals are being recorded correctly during the ray
trace |
19:18.11 |
brlcad |
abhi2011: of course the macro is defined in
both places, but the places we include windows headers takes care
of that |
19:18.40 |
brlcad |
so if that conflict is encountered, some
assumption is failing or the header inclusion ordering is wrong or
the wrong headers are being included |
19:19.35 |
brlcad |
winbase.h shouldn't be directly included
anywhere, so you have to look at the header includes to recursively
see who includes winbase.h |
19:19.36 |
abhi2011 |
ok |
19:20.44 |
brlcad |
abhi2011: what was r47378? |
19:21.14 |
brlcad |
commit message got left off, not clear what
changed since it was a fairly big commit .. wondering what it
was |
19:21.25 |
abhi2011 |
it was an update of the source code to use
contact pairs again |
19:21.33 |
brlcad |
ah, okay |
19:21.39 |
abhi2011 |
new svn software :P |
19:21.44 |
abhi2011 |
forgot to add message |
19:21.46 |
brlcad |
yep, realized that |
19:22.01 |
abhi2011 |
so I have an awesome idea now about how to
generate normals |
19:22.22 |
abhi2011 |
basically summing the normals in the surface
inside the overlap region |
19:23.03 |
brlcad |
sounds good :) |
19:23.20 |
abhi2011 |
the vector sum of the normals on the outer
surface of the body gives the direction of the force that the body
would apply on anything touching it |
19:23.28 |
abhi2011 |
as is the case in the real world |
19:23.54 |
abhi2011 |
once I have the normal, I ll shoot rays in
that direction to get the depth of penetration |
19:24.27 |
abhi2011 |
and then the contact points (which should be
on the surface of the body always), are the points where these rays
leave the object |
19:24.33 |
brlcad |
could you use the velocity vector of the
object in motion too? |
19:24.49 |
abhi2011 |
yes I can vectgr sum that to the normal
too |
19:24.56 |
abhi2011 |
or just use the velocity vector |
19:25.08 |
abhi2011 |
but the point is no matter what the velocity
vectpr |
19:25.19 |
brlcad |
why wouldn't you just use the velocity vector,
shoot rays in the direction of the velocity, calculate the depth of
penetration? |
19:25.20 |
abhi2011 |
the force will be based on the
surface |
19:25.41 |
abhi2011 |
well because it depeds on both |
19:26.01 |
abhi2011 |
the angle of the surface and the velocity
direction at which the object strikes |
19:26.09 |
abhi2011 |
that surface |
19:26.18 |
brlcad |
okay |
19:26.36 |
abhi2011 |
like a ray reflecting off a glass at an
angle |
19:26.43 |
brlcad |
nods, makes
sense |
19:26.46 |
brlcad |
misunderstood |
19:26.47 |
abhi2011 |
so hav to think about how to account for the
velocity |
19:26.52 |
abhi2011 |
ah |
19:27.00 |
abhi2011 |
the angle between normal and
velocity |
19:27.13 |
abhi2011 |
law of reflection calculation maybe |
19:27.45 |
abhi2011 |
but hmm, I think bullet will take care of
that |
19:27.56 |
abhi2011 |
the fnal velocity direction i mean |
19:28.04 |
abhi2011 |
all I need to give it is the normal |
19:28.12 |
abhi2011 |
at the point of contact |
19:29.34 |
abhi2011 |
here are some sample cases :
https://docs.google.com/drawings/d/1Fp44t9AcZZurbNufXti64u-23CRjC49Z3r0WSmim5tU/edit |
19:30.49 |
abhi2011 |
so the lower left case, shows that the concave
case should also be possible to calculate correctly |
19:31.27 |
abhi2011 |
if this works out then I can check how to
insert multiple manifolds, which I have read somewhere , is
possible |
19:52.51 |
brlcad |
can't get to gdocs at the moment, will have to
take a look later |
19:54.54 |
CIA-109 |
BRL-CAD: 03bob1961 * r47383
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: When opening
a database also change the current working directory to the
directory where the database lives. |
20:02.17 |
*** join/#brlcad abhi2011_
(~chatzilla@117.200.81.190) |
20:15.49 |
*** join/#brlcad abhi2011_
(~chatzilla@117.200.81.155) |
20:46.01 |
CIA-109 |
BRL-CAD: 03starseeker * r47384
10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-xml-catalog.xml.in:
I don't think this variable needs to be specific to BRL-CAD in this
case... |
20:52.33 |
CIA-109 |
BRL-CAD: 03starseeker * r47385
10/geomcore/trunk/ (12 files in 5 dirs): Turn on docbook
documentation for geomcore. Stub in a geometry protocol doc, but
nothing much there at the moment. |
20:56.01 |
CIA-109 |
BRL-CAD: 03abhi2011 * r47386
10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simutils.c
simutils.h): Now the entry and exit solids of a ray passing through
an overlap region are checked to see if they belong to the comb of
rigid body B |
20:59.16 |
brlcad |
deadline is today -- feel free to fill out
quick/easy tasks that could be completed in 1-3 days at http://brlcad.org/wiki/Contributor_Quickies |
20:59.40 |
brlcad |
I'm crafting together our proposal
now |
20:59.58 |
brlcad |
ideally we need 10 topics for each of the 8
categories |
21:00.49 |
``Erik |
'separate out libnmg' O.o I have vague
recollection of libnmg not too long ago :) |
21:00.55 |
brlcad |
well, 5-10 tasks per topic |
21:01.37 |
``Erik |
think simd/sse vmath might be worth an
entry? |
21:03.02 |
brlcad |
iirc, include/vector_*.h was (as anticipated)
an attempt at that |
21:03.04 |
brlcad |
and it failed |
21:03.53 |
brlcad |
test harness for vmath.h might be something
though |
21:04.28 |
brlcad |
example of gnome tasks https://live.gnome.org/GoogleCodeIn/Tasks |
21:04.55 |
brlcad |
I'm inclined to direct all students to either
IRC or the mailing list, thoughts on which? |
21:05.12 |
brlcad |
keeping in mind that it might be a lot of
students 24-7 |
21:05.13 |
``Erik |
in looking at that a while back, the choice to
go with typedef point_t fastf_t[3]; instead of typedef point_t
struct { fastf_t f[3]; }; or something was ... critical |
21:06.16 |
brlcad |
it wasn't a fail in terms of being a drop-in
replacement -- that would have been the technical issue
there |
21:06.46 |
brlcad |
it was a fail in that the simd version wasn't
actually faster -- needed more data, not just one vector/matrix at
a time |
21:07.01 |
starseeker |
fix tkhtml3 on Win64? |
21:07.22 |
starseeker |
for large numbers of students, I'd vote
mailing list |
21:07.23 |
``Erik |
I think irc will be quicker and more accepting
of newbs |
21:07.31 |
starseeker |
hard to track conversations though |
21:07.34 |
brlcad |
starseeker: can you explain the
problem? |
21:07.39 |
``Erik |
but irc would lack good record |
21:07.45 |
starseeker |
probably not well enough for a
student |
21:07.46 |
brlcad |
remember that these are *high school*
students |
21:08.08 |
brlcad |
the questions are going to be very much "hold
my hand", what's next? |
21:09.23 |
brlcad |
bhinesley: jordisayol: louipc: kanzure: anyone
else: interested in being a GCI mentor? |
21:10.20 |
starseeker |
brlcad: what about bu_getopt_long or some
such? |
21:10.57 |
starseeker |
just getting it working + adding it to one
command would be a good start |
21:11.45 |
brlcad |
I don't think bu_getopt_long is what we want
really (at least there's little-to-no value in having a bu version
of getopt_long()) |
21:12.09 |
starseeker |
uh... rt with -- options seems
worthwhile... |
21:12.10 |
brlcad |
we need long options, but there's no reason it
needs to be compatible with that extension |
21:12.42 |
starseeker |
do they do it the wrong way? |
21:12.43 |
brlcad |
getopt_long() is an overlay with getopt() ..
the two work suckily together |
21:13.04 |
brlcad |
pretty much |
21:13.28 |
starseeker |
we need something - what do you
suggest? |
21:14.09 |
brlcad |
writing an option interface for bu |
21:14.20 |
brlcad |
already sketched out the basics a month or two
ago |
21:14.31 |
starseeker |
erm. link? |
21:14.45 |
brlcad |
no link |
21:14.46 |
brlcad |
code in a checkout |
21:14.50 |
starseeker |
ah |
21:15.02 |
brlcad |
still, too advanced for gci I think |
21:15.08 |
starseeker |
k. pity |
21:15.24 |
brlcad |
if it's not something that'd take you less
than a half a day from start to finish, it's probably too
complex |
21:15.59 |
brlcad |
13 year olds ... |
21:16.02 |
starseeker |
well, there's always fixing the bbox function
for bots |
21:16.29 |
brlcad |
sure -- could put that one up, but i'd mark it
hard :) |
21:18.50 |
abhi2011 |
I think tcl and gui will be easier for high
school students :) |
21:19.04 |
abhi2011 |
maybe more of tcl and some libged related
code |
21:19.10 |
brlcad |
from other project's reviews from prior years,
the kids really do end up being a nearly full-time effort so we
need to manage the complexity up front -- things we can explain and
point trivially |
21:19.19 |
starseeker |
heh - I can't seem to come up with small
projects from the gui side... |
21:19.25 |
brlcad |
abhi2011: you have some project
ideas? |
21:19.30 |
abhi2011 |
for example the idea about integrating some of
the visualization tools into the gui |
21:19.45 |
abhi2011 |
most of them have a fixed interface I
guess |
21:19.48 |
brlcad |
remember that it's basically a contest --
they're looking for tasks that take hours or a day or two at
most |
21:20.00 |
abhi2011 |
oh ok |
21:20.22 |
brlcad |
which includes the time to download the
software, become familiar with the problem, find their way around,
run a tool, etc |
21:21.05 |
abhi2011 |
hmm, then tcl and gui stuff would be
tough |
21:21.23 |
brlcad |
came up with what I think is a GREAT idea at
the mentor summit... we can create a preconfigured disk image for
the students that already has a source checkout and compiled
install ready to go |
21:22.14 |
brlcad |
that with a few simple instructions to
download qemu, download disk image, create new image, run .. source
is here, binaries are there, go! |
21:24.46 |
abhi2011 |
yes, that can really get things going fast,
did that for virtual box images once |
21:25.21 |
abhi2011 |
so we are not expecting code from them I
guess, they design something using the tools already present in
brlcad ? |
21:25.59 |
brlcad |
you seen the http://brlcad.org/wiki/Contributor_Quickies
list? |
21:26.03 |
brlcad |
it can be a code project |
21:26.12 |
brlcad |
or docs, or web or ... anything
really |
21:26.21 |
brlcad |
something that'd take hours of time |
21:28.19 |
abhi2011 |
ok |
21:33.14 |
abhi2011 |
well I was thinking along the lines of making
mged a bit easier to use : like when an object is selected and the
primitive editor is opened, then the selected object's name should
already be there and it should be displaying the object
name |
21:33.48 |
CIA-109 |
BRL-CAD: 03128.63.32.62 07http://brlcad.org * r3193
10/wiki/Contributor_Quickies: /* Code */ add rt_bot_bbox
item |
21:34.03 |
abhi2011 |
or even simpler, ensuring that closing the
command window closes the application |
21:34.47 |
abhi2011 |
including the gfx window |
21:35.04 |
starseeker |
that... might not be so simple,
actually |
21:35.13 |
abhi2011 |
oh :) |
21:35.23 |
starseeker |
seems to recall brlcad
working with that once... |
21:35.26 |
abhi2011 |
low level opengl callbacks ? |
21:35.35 |
starseeker |
don't recall now |
21:36.25 |
starseeker |
brlcad: is excising Tcl functions from
libraries too hard? (guessing yes...) |
21:37.02 |
abhi2011 |
also is there a script for moving the view
along a specified path, it would be awesome to write a script or a
simple c function that revolves the camera around the scene as
objects are dropping |
21:37.08 |
abhi2011 |
*moving the camera |
21:37.18 |
cvds_ |
abhi2011: please dont, since I use that
feature (closing thecommand window but keeping the gfx
window) |
21:37.29 |
abhi2011 |
hehe ok :) |
21:37.53 |
abhi2011 |
so you run a script then close the command
window I guess |
21:38.27 |
cvds_ |
mged -c to attach a single window and then set
mged_default(multi_pane) 1; gui; and close the mged command window
;) |
21:38.54 |
abhi2011 |
ah ok |
21:40.13 |
cvds_ |
and using yakuake as the input. Works like a
charm |
21:40.32 |
starseeker |
brlcad: http://directory.fsf.org/wiki/Popt |
21:40.40 |
starseeker |
http://rpm5.org/files/popt/popt-1.16.tar.gz |
21:40.46 |
starseeker |
would that be of interest? |
21:41.38 |
starseeker |
looks like MIT style license |
21:48.02 |
starseeker |
(not for GCI per say, but as an alternative to
rolling our own option parsing?) |
21:59.21 |
brlcad |
abhi2011: having the closure of all of mged's
windows actually close mged sounds like a great task -- can you add
that to the wiki? |
22:00.04 |
brlcad |
starseeker: not sure what you meant with the
excising |
22:00.34 |
starseeker |
doing whatever is needed to get the Tcl/Tk C
api usage up to libtclcad (or steps in that direction) |
22:00.35 |
brlcad |
abhi2011: camera 360 script sounds like
another great one, wiki? |
22:01.20 |
starseeker |
blinks - must have been
thinking something else - I thought that "close all windows" issue
was tied up with something else more complex |
22:01.28 |
brlcad |
cvds_: interested in being a mentor?
:) |
22:02.01 |
abhi2011 |
brlcad: sure and sure :) |
22:02.22 |
brlcad |
starseeker: it's a bug, it used to close
mged |
22:02.37 |
brlcad |
now you can close those two windows and mged
is still running |
22:02.41 |
brlcad |
abhi2011: awesome :) |
22:08.42 |
CIA-109 |
BRL-CAD: 03starseeker * r47387
10/brlcad/trunk/src/ (3 files in 2 dirs): Shouldn't have moved
this, used only internally in libbu and it's one file. |
22:11.06 |
brlcad |
starseeker: Makefile.am |
22:11.20 |
starseeker |
coming now |
22:11.39 |
CIA-109 |
BRL-CAD: 03starseeker * r47388
10/brlcad/trunk/src/ (5 files in 3 dirs): Clean up the rest of the
uce stuff |
22:11.41 |
starseeker |
prods CIA |
22:21.20 |
CIA-109 |
BRL-CAD: 03Abhi2011 07http://brlcad.org * r3194
10/wiki/Contributor_Quickies: /* Code */ |
22:54.32 |
CIA-109 |
BRL-CAD: 03Abhi2011 07http://brlcad.org * r3195
10/wiki/Contributor_Quickies: /* Code */ |
22:55.37 |
brlcad |
~abhi2011++ |
22:55.41 |
brlcad |
awesome |
22:55.44 |
CIA-109 |
BRL-CAD: 03Abhi2011 07http://brlcad.org * r3196
10/wiki/Contributor_Quickies: /* EASY: Camera 360: A Tcl script to
capture images while rotating the view around a scene */ |
22:56.47 |
abhi2011 |
will try to come up with some more tomorrow
:) |
22:56.53 |
brlcad |
we need at least 3 more outreach and
translation tasks, and at least 1 more research and UI task
:) |
22:57.01 |
brlcad |
and QA |
22:57.09 |
brlcad |
need at least 5 for each |
22:57.58 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
22:59.16 |
abhi2011 |
how about starting the primitive editor with
the currently selected object instead of having the user type it in
each time |
22:59.53 |
brlcad |
you mean sed? |
22:59.58 |
brlcad |
sure |
23:00.16 |
brlcad |
oh, in the gui |
23:00.20 |
abhi2011 |
yes |
23:00.30 |
brlcad |
yeah, that'd be possible .. a bit complicated
to explain, definitely a hard task |
23:00.43 |
brlcad |
your camera task is probably medium or hard
for that matter :) |
23:00.47 |
abhi2011 |
yeah it requires familairity with
mged |
23:01.01 |
abhi2011 |
yeah :P |
23:01.02 |
brlcad |
easy if you know mged and know scripting.. but
that's a big IF for a 13 year old :) |
23:12.14 |
``Erik |
iff, even |
23:12.38 |
``Erik |
*ponder* logo on mged? |
23:12.59 |
brlcad |
perfect, add it |
23:13.16 |
brlcad |
great idea |
23:13.37 |
``Erik |
iirc, logo was a variant of scheme, soooo...
yeah, let's ditch tcl for lisp! |
23:14.11 |
brlcad |
heh |
23:14.23 |
brlcad |
took that to mean .. model
the BRL-CAD logo in MGED :P |
23:14.52 |
``Erik |
if mged ate lisp, it'd be
automatable... |
23:15.00 |
``Erik |
"just a couple lines" |
23:17.38 |
``Erik |
has an old sorbel filter in C
*ponder* |
23:20.45 |
``Erik |
(whuddya mean, making each pixel a colored
arb8 ain't what ya meant?) |
23:23.18 |
brlcad |
mmhmm |
23:23.33 |
brlcad |
pix-g will do it now :) |
23:25.33 |
``Erik |
pix2g ya mean? |
23:25.43 |
brlcad |
right |
23:25.55 |
brlcad |
didn't want it to look like a proper tool
:) |
23:26.07 |
``Erik |
does not recall that
puppy |
23:26.30 |
brlcad |
proc-db |
23:26.35 |
``Erik |
and I keep typing 'git log', starseeker has
poisoned my brain |
23:26.57 |
``Erik |
it's old, even |
23:27.12 |
brlcad |
yeah, did that a long time ago |
23:27.21 |
brlcad |
fairly useless, but fun hack |
23:27.39 |
``Erik |
is it actually a planar arb8 set with
colors? |
23:28.01 |
brlcad |
I started with arbs, but I think that last rev
uses spheres |
23:28.15 |
brlcad |
trivial to put it back |
23:28.38 |
``Erik |
painter and smoother might replicate something
acceptable... push it to nurbs and it's all good |
23:29.31 |
``Erik |
(curve fit on a nurb is a whole lot easier
than attempting to replicate geometry in implicits,
right?) |
23:29.57 |
``Erik |
srry, on a nurbs |
23:32.00 |
brlcad |
you going to add that logo task? that really
is a great idea |
23:32.55 |
``Erik |
I'll let you... I actually meant the language
"logo" |
23:33.59 |
``Erik |
if you want to give me credit for sparking the
idea in you, that's cool, but that definitely isn't what I meant
:) |
23:36.26 |
brlcad |
even better if you'd write it, cause writing
this proposal is going to have me right up against the submission
deadline |
23:36.54 |
``Erik |
which logo? |
23:37.18 |
brlcad |
the new logo |
23:37.38 |
brlcad |
point them to the news page on the main
website |
23:38.25 |
``Erik |
I have a cat on my lap, and I'm not sure if
he's actually alive anymore O.O |
23:40.29 |
``Erik |
abhi has no user page |
23:42.32 |
``Erik |
I d'no, doco or ux? |
23:43.06 |
``Erik |
I'll go ahead and call it ux |
23:49.38 |
``Erik |
ffs, WoW is stomping my machine here O.o 20-30
seconds before a keypress registers in other apps :/ |
23:49.39 |
brlcad |
<PROTECTED> |
23:55.08 |
CIA-109 |
BRL-CAD: 03Erik 07http://brlcad.org * r3197
10/wiki/Contributor_Quickies: /* User Interface */ Add .g of logo
task |
23:55.53 |
``Erik |
wordsmith your heart out, probably needs a
time guess |
23:56.00 |
brlcad |
k |
23:56.41 |
brlcad |
ideas on hold.. the deadline apparently isn't
.. what I calculated it to be .. (ffs.) |
23:56.52 |
brlcad |
just went to submit (early) and .. it's
not |
23:59.34 |
CIA-109 |
BRL-CAD: 03128.63.32.74 07http://brlcad.org * r3198
10/wiki/Contributor_Quickies: move logo to outreach, needs two
more |