02:54.30 |
CIA-28 |
BRL-CAD: 03starseeker * r35874
10/brlcad/trunk/ (5 files in 3 dirs): |
02:54.30 |
CIA-28 |
BRL-CAD: Add (but do not enable) code to grab
all regions whose bounding boxes intersect |
02:54.31 |
CIA-28 |
BRL-CAD: a sphere and place them in a group.
This will at some point make a beginning |
02:54.31 |
CIA-28 |
BRL-CAD: for advanced selection options in
editors, but in its current form is too |
02:54.31 |
CIA-28 |
BRL-CAD: limited to enable as a
command. |
03:32.21 |
*** join/#brlcad ibot
(i=ibot@rikers.org) |
03:32.21 |
*** topic/#brlcad is BRL-CAD
Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad
|| Release 7.14.8 posted (20090511) || GSoC2009 Next Step: upload
your code to google, wait for shirt ;) thanks everyone! || log at
http://ibot.rikers.org/#brlcad |
05:37.07 |
*** join/#brlcad KingofCSU
(n=king@222.247.155.229) |
06:04.14 |
*** join/#brlcad puddingpimp
(n=dave@118-93-244-155.dsl.dyn.ihug.co.nz) |
12:00.26 |
*** join/#brlcad surje
(n=surje@202.3.77.11) |
12:54.04 |
CIA-28 |
BRL-CAD: 03brlcad * r35875
10/brlcad/trunk/NEWS: |
12:54.04 |
CIA-28 |
BRL-CAD: reword so proper commit note will be
associated with those lines in the summary |
12:54.04 |
CIA-28 |
BRL-CAD: report. cliff added -r and -v options
to the 3dm-g importer to set random |
12:54.04 |
CIA-28 |
BRL-CAD: colors on objects during import and
to provide better verbose processing |
12:54.04 |
CIA-28 |
BRL-CAD: information during import. |
15:19.03 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14CE79.dip.t-dialin.net) |
16:18.33 |
*** join/#brlcad cpc26
(n=cpc26@72.170.156.242) |
17:30.28 |
*** join/#brlcad samrose
(n=samrose@c-71-238-71-94.hsd1.mi.comcast.net) |
17:51.53 |
*** topic/#brlcad by louipc
-> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad
|| Release 7.14.8 posted (20090511) || GSoC2009 Next Step: upload
your code to google, wait for shirt ;) thanks everyone! || Logs at
http://ibot.rikers.org/%23brlcad/ |
18:29.35 |
*** join/#brlcad samrose
(n=samrose@c-71-238-71-94.hsd1.mi.comcast.net) |
18:36.37 |
CIA-28 |
BRL-CAD: 03erikgreenwald * r35876
10/isst/trunk/src/Makefile.am: cope with growing c++isms in
librt |
18:37.02 |
CIA-28 |
BRL-CAD: 03erikgreenwald * r35877
10/brlcad/trunk/src/adrt/ (4 files in 2 dirs): more interface
unification |
18:37.17 |
CIA-28 |
BRL-CAD: 03erikgreenwald * r35878
10/isst/trunk/src/local_worker.c: use new init interface |
19:06.19 |
brlcad |
V3ARGS() will expand a %f %f %f for
you |
19:06.54 |
brlcad |
assuming [0], [1], [2] indexing |
19:19.37 |
``Erik |
'cept I have to break away from that, v3args
is too "clever" |
19:20.33 |
``Erik |
(notice, blah, blah+1, blah+2, NOT blah[0],
blah[1], blah[2]... references :D ) |
19:21.11 |
``Erik |
if V3ARGS(&blah) did what I wanted, that'd
be nifty, but it doesn't |
20:40.15 |
brlcad |
parens? |
20:40.15 |
brlcad |
((&blah))? |
20:40.19 |
brlcad |
maybe with a cast |
20:40.33 |
brlcad |
(((float*)(&blah))) |
20:46.37 |
``Erik |
def'd as (a)[X], so'z V3ARGS(&a) resolves
to (&a)[X], which blows up... can't do it with the
macro |
20:47.24 |
``Erik |
it's too damn safe :D |
21:03.09 |
brlcad |
~seen Ralith |
21:03.12 |
ibot |
ralith <n=ralith@69.90.48.127> was last
seen on IRC in channel #brlcad, 1d 19h 57m 45s ago, saying:
'Yoshi477: yay!'. |
21:03.53 |
brlcad |
~seen jdoliner |
21:03.54 |
ibot |
jdoliner
<n=jdoliner@c-67-173-0-29.hsd1.il.comcast.net> was last seen
on IRC in channel #brlcad, 10d 7h 29m 53s ago, saying: 'ah but
fortunately, this won't be too hard to fix at all'. |
21:04.16 |
brlcad |
students need to upload their code
still |
21:14.18 |
``Erik |
ponders how evil "#define
V3ARGSP(a) &((a)[X]), &((a)[Y]), &((a)[Z])" would be
:> |
21:51.08 |
brlcad |
pretty evil |
23:00.25 |
``Erik |
indeed, unrestrained thinking down that alley
can turn into truely horrible abuses, that's how c++ crawled its
way from the depths ;> *duck* |
23:30.06 |
brlcad |
heh |
23:30.16 |
brlcad |
c++ isn't *that* bad :) |
23:30.20 |
``Erik |
:D |
23:30.43 |
``Erik |
(it did begin life has a klugefest of macro's,
though) |
23:32.41 |
starseeker |
proposes klugefest as the
code name for the next Windows release |
23:33.10 |
``Erik |
dude, not cool, don't insult the art of the
kluge like that |
23:33.10 |
``Erik |
:D |
23:33.40 |
starseeker |
heh |
23:33.55 |
``Erik |
windows 8 will be codenamed "fuckit, no one's
using this anyways" if vista and 7 are indicators |
23:34.01 |
starseeker |
``Erik: oh, by the by - are you planning to
un-weird-ify the isst user navigation? |
23:34.07 |
``Erik |
yes. |
23:34.11 |
starseeker |
sweet |
23:34.30 |
``Erik |
I'm refactoring things to be clean and generic
to make gui's trivial to write |
23:34.54 |
``Erik |
and then have a few versions to slap on
(cocoa, gtk, sdl, tk, mebbe qt...) |
23:35.12 |
louipc |
is 7 out now? |
23:35.19 |
``Erik |
libdm... |
23:35.42 |
``Erik |
windows 7 has been out for a bit now, I
think |
23:35.44 |
starseeker |
ogre... :-P |
23:36.02 |
starseeker |
tries to ignore Windows
releases... |
23:36.15 |
``Erik |
mebbe it's pre-release versions I've been
hearing about |
23:36.23 |
louipc |
I thought it was just beta |
23:36.30 |
louipc |
or RCs |
23:36.38 |
``Erik |
hum, says oct 22 for release |
23:36.45 |
``Erik |
*shrug* |
23:37.29 |
``Erik |
doesn't quite see how ogre
would be a viable interface for adrt... ogre is the engine below
the interface, just like adrt... O.o |
23:37.49 |
starseeker |
was thinking integrate it
into the ogre+qt g3d stuff |
23:38.04 |
starseeker |
nevermind - just idle humor |
23:38.21 |
``Erik |
ok, so g3d would be the frontend and adrt
would be the optional ogre replacement :D |
23:39.14 |
starseeker |
yeah, in that case you'd just render into ogre
like we render into ogl now for a raytrace I guess (well, except
working properly...) |
23:39.55 |
``Erik |
do we rasterize raytrace results into an ogl
window? I thought just the plot sequences were sent down that
pipeline |
23:39.58 |
``Erik |
*shrug* |
23:40.22 |
starseeker |
Well, if you compile with opengl enabled, the
rt window that pops up says ogl iirc |
23:40.51 |
starseeker |
yeah - /dev/ogl |
23:41.01 |
starseeker |
and at least on my machine it doesn't work so
hot |
23:41.13 |
starseeker |
(I think it's a long known issue) |
23:41.27 |
starseeker |
just waiting on someone to really dig down
deep and figure it out |
23:41.34 |
``Erik |
guh |
23:41.38 |
``Erik |
glDrawPixels() |
23:42.28 |
``Erik |
(historically, noticably slower than an
unaccelerated X window, and stomped by decent XAA...) |
23:42.40 |
starseeker |
even our X raytrace is drawing too slow - Sean
and I noticed it when comparing a sphere raytrace to a nurbs sphere
raytrace |
23:42.53 |
``Erik |
um, in mged, or direct? |
23:43.01 |
starseeker |
direct, iirc |
23:43.09 |
starseeker |
or rather, both |
23:43.10 |
``Erik |
mged uses the network framebuffer which does
some r-tarded lock crap or something |
23:43.26 |
``Erik |
so on a fast multicore machine, it's hard to
get a decent amount of cpu utilization |
23:43.34 |
starseeker |
yeah, IMHO the whole thing needs a
rethink/serious cleanup |
23:43.40 |
``Erik |
but 'rt' talks straight to the fb, so it's
able to cook the cpu's pretty good |
23:44.41 |
``Erik |
thought rt was being called
with like -P0 or something at first, until digging into it and
spotting the ugly |
23:45.31 |
starseeker |
heh |
23:45.51 |
starseeker |
yeah, modern hardware exposes some interesting
issues |
23:47.48 |
starseeker |
it almost feels like some kind of double
buffering is needed - render N lines to a buffer then update that
part of the window |
23:51.48 |
``Erik |
*readreadread* looks like libpkg makes some
assumptions that may no longer be valid? plus a whole lot of logic
for each send (therefore each scanline) |
23:52.35 |
``Erik |
a better IPC approach might be the right thing
for that |
23:52.42 |
``Erik |
if_shm.c ? :) |
23:53.26 |
*** join/#brlcad talcite_
(n=matthew@69-165-139-121.dsl.teksavvy.com) |
23:53.54 |
``Erik |
(or unix sockets, or at least jumbo
frames) |