00:00.15 |
andrecastelo |
thanks, brlcad, i'll do some research, take a
look at the code, write the application and see how it turns out
;) |
00:00.24 |
brlcad |
sounds good |
00:15.14 |
mafm |
so brlcad, are you available now to talk about
that? |
00:15.27 |
brlcad |
probably |
00:16.22 |
mafm |
good |
00:16.53 |
mafm |
so what about the distributed approach, can
you please elaborate or link to some document? |
00:17.16 |
brlcad |
well we have a raytracer in brl-cad |
00:17.19 |
brlcad |
lots of them, actually |
00:17.34 |
brlcad |
all based around our librt ray-trace
library |
00:18.49 |
brlcad |
we support parallel ray-tracing pretty
pervasively |
00:19.14 |
brlcad |
'rt' is the main ray-tracer |
00:19.42 |
brlcad |
we also have distributed ray-tracing via
'remrt' (remote rt) and 'rtsrv' (remote compute daemons) |
00:20.30 |
brlcad |
remrt and rtsrv basically set up manual
communication pipes and negotiate packets as needed, and you have
to specify all machines you want to work on |
00:21.25 |
brlcad |
what we don't do easily though is 'automatic
distributed' using something like mpi, pvm, or grid
interfaces |
00:21.44 |
brlcad |
it would be nice if rt inherintly had
distributed capacities |
00:22.45 |
mafm |
are the computations heavy enough that it
compensates to distribute them via network? |
00:22.50 |
brlcad |
so that's the basic idea, either adding the
functionality to rt or giving remrt/rtsrv major updates to improve
them |
00:23.18 |
brlcad |
that depends entirely on the model being
rendered |
00:23.41 |
brlcad |
some are blazingly fast, others swimmingly
slow |
00:23.58 |
mafm |
slow as in minutes? |
00:24.19 |
brlcad |
anywhere from subsecond to hours |
00:24.51 |
brlcad |
so it really needs to auto-detect and
load-balance accordingly, know when to farm out the job and when
not to |
00:25.17 |
brlcad |
the models might be just a few k or might be
several GB in size too |
00:26.17 |
mafm |
typical grid jobs, for scientific grids that
I'm used to, usually take hours/days |
00:26.31 |
brlcad |
the two extremes where we usually want
distributed are when someone's making a movie and rendering
thousands of frames or someone rendering a really high-quality
detailed complex model rendering |
00:26.44 |
mafm |
and in most them the turnaround time for
"hello world" is like 3-5 minutes :D |
00:27.14 |
mafm |
so the idea would be to run them withing
clusters I guess, with LAN setups? |
00:27.28 |
brlcad |
pretty much |
00:28.25 |
mafm |
I have programmed in PVM a bit, only at univ
for test programs |
00:28.29 |
brlcad |
as well as loosely connected LAN-based setups
over slow connections (a typical office with maybe 10-100 high-end
workstations available to run compute nodes with an mpi config for
example) |
00:28.45 |
mafm |
and in MPI at work but only for testing, no
real applications |
00:29.16 |
mafm |
anyway the theory I think that I'm OK with
it |
00:29.25 |
brlcad |
MPI or a solid grid framework would probably
be ideal |
00:30.06 |
mafm |
but I guess that for doing that from a ray
tracer, I would have to have solid knowledge of the techniques of
raytracing too? |
00:30.52 |
brlcad |
not necessarily |
00:30.59 |
brlcad |
at least not beyond understanding the data
model |
00:31.17 |
brlcad |
ray-tracing generally requires the entire
model for example since rays can diverge in any direction |
00:32.00 |
brlcad |
so you either have some sort of master
dispatch and distribute portions of data or distribute all the data
to all nodes and dispatch rays/scanlines or some hybrid |
00:33.31 |
mafm |
say that you want to render a
village |
00:33.47 |
mafm |
the input are the solids represenging houses
and so on |
00:33.59 |
mafm |
the output would be what, just the 2D
image? |
00:34.20 |
brlcad |
yep |
00:34.27 |
brlcad |
or a series of 2D images in the case of an
animation |
00:35.19 |
mafm |
say that you want an animation |
00:35.28 |
andrecastelo |
hey brlcad, the download page is a little
off |
00:35.55 |
andrecastelo |
it points to the 7.10.2 release (at least the
source) |
00:35.56 |
mafm |
the output or intermediate calculations of one
frame could be used for the second? (similar to what MPEG
do) |
00:36.32 |
brlcad |
andrecastelo: thanks |
00:36.40 |
brlcad |
it needs to be wikified |
00:36.50 |
brlcad |
or made a module that auto-points to the
latest |
00:37.05 |
brlcad |
mafm: yes |
00:37.18 |
brlcad |
rt already has inherint support for multiframe
rendering |
00:37.33 |
andrecastelo |
(also, if i want to check the code, i get the
7.12.0 source, right?? how hard is it to compile in windows??
) |
00:37.40 |
brlcad |
you feed it transactioned command lists and it
deals with what needs to be reprepped accordingly |
00:38.00 |
brlcad |
andrecastelo: there's an msvc studio project
in misc -- should be click and run |
00:38.25 |
andrecastelo |
great, thanks |
00:39.29 |
mafm |
if frames are interdependent, that turns it a
bit difficult it seems |
00:39.42 |
brlcad |
they're independent |
00:40.09 |
brlcad |
it's just you can speed things up if you don't
need to reprep, so rt does so accordingly |
00:40.52 |
mafm |
well yes, but if rendering them sequentially
is much less effort than the sum() of separate efforts, the speedup
of distributing it is not very big |
00:41.05 |
mafm |
with aqsis there was a similar
problem |
00:41.19 |
mafm |
buckets (portions of the image) were in
principle independent |
00:41.35 |
mafm |
but constructing the octree was very
expensive |
00:42.23 |
mafm |
so if you didn't take advantage of that, and
construct the octree from scratch each time, the result was that it
was more expensive when using several threads |
00:42.56 |
mafm |
I think that there could be similar problems
in brlcad, or you already have that part sorted out? |
00:43.09 |
brlcad |
you're thinking thread-level, we have
that |
00:43.26 |
brlcad |
parallel is a done deal |
00:43.36 |
brlcad |
distributed even works, it can just be heavily
improved |
00:44.15 |
mafm |
I know the difference between theads and
distributed, it was an example, to be extrapolated :) |
00:44.26 |
brlcad |
so yeah, buckets of an impage are independent
-- but the model itself isn't |
00:44.30 |
hippieindamakin8 |
andrecastelo and mafm u guys might be
interested in this
http://www.siggraph.org/education/materials/HyperGraph/raytrace/rtrace0.htm |
00:44.45 |
andrecastelo |
hippieindamakin8: thanks! |
00:44.50 |
brlcad |
mafm: sure, but the latency concerns between
parallel and distributed are huge |
00:45.03 |
hippieindamakin8 |
u wanted to know the raytracing fundamentals
rt :) np |
00:45.22 |
brlcad |
that's why the real driver is big render jobs
where we know implicitly that it's going to be a benefit (huge
render or tons of frames) |
00:45.31 |
andrecastelo |
also - is a kd tree implemented?? |
00:45.56 |
brlcad |
effectively, we have a hybrid |
00:46.04 |
mafm |
I see |
00:47.16 |
brlcad |
brl-cad's rt is actually the first parallel
distributed ray-tracer (per all published references), an early
second-generation ray-tracer |
00:48.02 |
mafm |
that's remrt+rtsrv? |
00:48.10 |
brlcad |
the distributed portion, yes |
00:48.11 |
mafm |
or the librt? |
00:48.30 |
mafm |
I mean, which parts would I have to
modify? |
00:48.59 |
brlcad |
depends entirely on whether the idea is to
improve remrt usability or add inherint distributed support to rt
:) |
00:49.04 |
brlcad |
there are merits to both |
00:51.11 |
brlcad |
could read some of the published papers, this
relates specifically to brl-cad: http://ftp.arl.army.mil/~mike/papers/95cadsymp/realtime.html |
00:51.14 |
mafm |
both them are in C it seems (browsing the
repositories) |
00:52.35 |
brlcad |
more references in http://graphics.cs.uni-sb.de/Publications/2001/star.pdf |
00:52.43 |
brlcad |
yes, 90% of the sources are in C |
00:53.09 |
brlcad |
only the new BREP code is in C++ plus a few
modules, along with the tcl/tk modeler sources |
00:53.31 |
brlcad |
rt stays C, remrt could be
redesigned |
00:53.31 |
mafm |
is there a "central" source file in librt
where the high level stuff is implemented? |
00:53.51 |
brlcad |
what high-level stuff? |
00:54.17 |
brlcad |
high-level ray dispatching is in the binary
front-end, src/rt src/remrt |
00:55.09 |
mafm |
I mean an important file in librt |
00:55.21 |
mafm |
to see how scary is the code :D |
00:56.29 |
mafm |
int is_hackers_night( struct timeval *tv
); |
00:56.33 |
mafm |
:D |
00:56.48 |
brlcad |
you wouldn't really be modifying anything in
librt, at least I'd be surprised if you need to |
00:57.50 |
brlcad |
otherwise, some of the core is in shoot.c,
bool.c |
00:58.18 |
brlcad |
you really should start from srt/rt though --
librt is the library itself, even parallelism happens higher
up |
00:59.16 |
brlcad |
src/rt/view.c do.c and most importantly
worker.c |
01:00.06 |
hippieindamakin8 |
librt is all about the geometry representation
and manipulations/transformations mostly |
01:01.55 |
mafm |
ok, looking at those :) |
01:01.58 |
hippieindamakin8 |
brlcad .. btw wat is the function of this
server ? rtserver |
01:04.24 |
Daytona |
librtserver is a C library that is loaded by a
Java class to provide raytracing services for a Java App |
01:07.28 |
hippieindamakin8 |
ohh |
01:07.42 |
hippieindamakin8 |
tx :) |
01:08.32 |
mafm |
hmm, don't know brlcad |
01:08.59 |
mafm |
does this have more priority than the other
idea? |
01:09.09 |
Daytona |
hippieindamakin8: If you have some ideas on
how to improve that code, that would be great!!! |
01:09.11 |
mafm |
I haven't even seen it in the Project Ideas
page |
01:09.13 |
hippieindamakin8 |
daytona can u suggest me an
appilcation |
01:10.36 |
hippieindamakin8 |
:) i just opened it daytona :P i wanted to
apply for this OO API project so was going through the places where
there is a possibility of rendering some geometry :) |
01:10.57 |
hippieindamakin8 |
as i get more familiar with brlcad i sure will
:) |
01:10.59 |
brlcad |
mafm: like I said -- a really solid
application for any of the ideas trumps the priority
aspect |
01:12.09 |
Daytona |
hippieindamakin8: The librtserver is just used
in a JNI wrapper |
01:13.17 |
hippieindamakin8 |
ohh there is this jade.jar in the src :) now i
am connecting pieces |
01:13.35 |
hippieindamakin8 |
in case it is connected to this |
01:14.08 |
Daytona |
the librtserver and the jbrlcad are not
connected |
01:14.57 |
hippieindamakin8 |
nono.. in the src there is this folder called
java |
01:15.05 |
hippieindamakin8 |
i aint talking about jbrlcad |
01:15.11 |
Daytona |
jade.jar is a units and measurments jar (now
replaced by jscience) |
01:15.50 |
hippieindamakin8 |
sorry.. :P i am mistaken.. i wanted to talk
about brlcad server.java |
01:16.11 |
hippieindamakin8 |
sorry.. it was a long time :P |
01:16.32 |
mafm |
brlcad: hmm, honestly, I'm not talking into
getting into GSoC with BRL-CAD for being a higher priority
project |
01:17.01 |
brlcad |
no comprendo |
01:17.02 |
mafm |
hmm, let me think about how to explain it...
(I'm a bit tired at the moment :) ) |
01:17.11 |
hippieindamakin8 |
~/brlcad7-10-2/src/java/mil/army/arl/brlcad |
01:18.43 |
Daytona |
looks like there is almost nothing in that
class |
01:19.10 |
hippieindamakin8 |
ya i shalll go through that :) |
01:20.50 |
Daytona |
the jbrlcad has a bit more functionality
:-) |
01:21.27 |
mafm |
<brlcad> mafm: like I said -- a really
solid application for any of the ideas trumps the priority
aspect |
01:21.46 |
mafm |
when I'm asking about the priority, I don't
mean to take it as an advantage |
01:22.10 |
mafm |
I mean if you suggest that because of my
relation with distributed computing at work or what |
01:22.28 |
mafm |
or if you came up with that for other
reasons |
01:22.48 |
brlcad |
yes, I only suggested it as a consideration
because of your background |
01:23.05 |
brlcad |
otherwise, no different than then other listed
ideas |
01:23.12 |
mafm |
yesterday we were talking about other
proposals, it's you who started to talk about this one (IIRC, I was
a bit sleepy) |
01:23.59 |
brlcad |
there was someone (a student) that worked on
an mpi layer for rt a couple years ago too, for several months, but
they were learning everything from scratch and never finished
anything more than job propagation |
01:24.36 |
mafm |
aha |
01:24.58 |
mafm |
so one of the reasons is that maybe I see it
as a more doable proposal than the other one? |
01:25.18 |
brlcad |
right, and I firmly believe that you need to
be excited about the work --figured with your background that
distributed might be of interest, if not then screw it |
01:26.20 |
mafm |
well, certainly distributed computing it is
interesting, but I enjoy many areas |
01:27.18 |
mafm |
working with a 3D engine to communicate with
commands with a remote server is also another, making a multiplayer
game it's similar in concept, I think |
01:27.51 |
mafm |
so probably this project would have more
chances to succeed |
01:27.54 |
brlcad |
some loose similarities, yes |
01:29.38 |
mafm |
but I also understand that maybe it would be
more valuable for you to make my application for other project,
because is less common |
01:30.02 |
mafm |
so if I was accepted and finish the program,
there would be more chances for other people to do that OpenGL
GU |
01:30.03 |
mafm |
GUI |
01:30.04 |
brlcad |
what's less common? |
01:30.23 |
brlcad |
ah, yes -- it certainly has higher impact
potential |
01:30.30 |
mafm |
the knowledge of MPI/distributed
stuff |
01:30.36 |
brlcad |
it's also one that will be more critiqued
design-wise :) |
01:30.57 |
mafm |
so in the case that I would go ahead, I would
be beaten? :) |
01:32.15 |
brlcad |
nope |
01:33.45 |
mafm |
good to know :) |
01:33.47 |
mafm |
well, I see two problems then: |
01:34.03 |
mafm |
1) it's more difficult for me to come up with
a plan, |
01:34.21 |
mafm |
2) it's a more risky project I think, there
are more chances of failure |
01:34.43 |
brlcad |
whether you're not accepted is dependent on
the quality of your application (compared to quality of others),
number of slots we accept (just 2-4), the topic being proposed, as
well as any details about yourself and your abilities |
01:34.49 |
mafm |
oh, and 3) I don't have the infrastructure to
test the distributed rendering |
01:35.01 |
brlcad |
okay, so forget it :) |
01:35.07 |
brlcad |
not pressing the idea on you :) |
01:35.14 |
brlcad |
pick whatever suits you |
01:37.48 |
mafm |
I don't feel pressed really, I just want to
make explicit that it's more risky, in the case that I would be
accepted and go ahead, I think that it could fail more
easily |
01:38.06 |
mafm |
and I don't know if you could provide the
infrastruture or what? |
01:38.40 |
mafm |
we have clusters (not very big) at my job, but
they're in production and we cannot install new things |
01:38.45 |
brlcad |
heh, you're just saying all of the reasons for
why you shouldn't submit it |
01:38.51 |
brlcad |
forget about it! :) |
01:42.29 |
mafm |
sighs |
01:42.40 |
mafm |
btw, I could submit more than one proposal,
you now :D |
01:42.46 |
brlcad |
that you could |
01:43.01 |
brlcad |
but better to focus on getting at least one
really solid |
01:43.19 |
andrecastelo |
have you guys received lots of
applications?? |
01:43.21 |
brlcad |
i'd recommend doing one proposal and putting
the extra effort on a better patch .. |
01:43.34 |
brlcad |
andrecastelo: not really |
01:43.56 |
andrecastelo |
and also - i see that you are part of the
bzflags community as well, will you be a mentor both ?? |
01:44.04 |
andrecastelo |
be a mentor in* both.. |
01:45.08 |
brlcad |
i'm admin for both, I hope to actually *not*
mentor for either (officially) if I can get away with it ... but
then still mentoring as usual group-mentorshipwise |
01:45.52 |
brlcad |
if I do mentor, it's probably be for
brl-cad |
01:46.17 |
andrecastelo |
i see |
01:48.07 |
mafm |
there are no assigned/expected mentors yet, I
guess? |
01:48.21 |
mafm |
btw I hope that we have some extended period
to submit the patch :) |
01:48.49 |
brlcad |
there's about another week to submit a
patch |
01:52.44 |
mafm |
ah, good |
01:53.52 |
brlcad |
it will be required of any serious
candidates |
01:54.03 |
brlcad |
i.e. any finalists for certain |
01:54.33 |
brlcad |
if someone can't make a basic patch out of a
million line codebase, that bodes very poorly :) |
01:58.40 |
mafm |
sed -i 's/BRL-CAD/mafm-CAD/g' :) |
01:58.56 |
brlcad |
heh |
01:59.14 |
mafm |
that'd be at least 1000 lines
changed |
02:00.09 |
brlcad |
that'd hit every file |
02:00.16 |
brlcad |
BRL-CAD is in the file header |
02:00.18 |
mafm |
btw, now I should still submit the proposal to
the mailing list, or in parallel, or what? |
02:00.24 |
brlcad |
"yes" |
02:00.41 |
brlcad |
could give a summary to the mailing
list |
02:00.55 |
brlcad |
then extra detail to the wiki or as a
submission |
02:01.30 |
mafm |
what if I paste the complete
submission? |
02:01.41 |
mafm |
in the wiki or so |
02:02.44 |
brlcad |
you can put whatever you like into the
wiki |
02:03.03 |
brlcad |
good place for full/more detail |
02:04.07 |
mafm |
going to sell his wikispace
for Google ads :P |
02:05.36 |
andrecastelo |
hey brlcad, i was looking at the TODO list and
found this in the lower priority part: |
02:05.37 |
andrecastelo |
* center of presented area |
02:05.49 |
brlcad |
yes? |
02:06.07 |
andrecastelo |
what is it exactly ?? |
02:06.13 |
andrecastelo |
(
http://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/TODO
) |
02:06.32 |
brlcad |
in a given 2D projection, where is the center
of presented area |
02:07.42 |
andrecastelo |
is it simple enough to implement as the
required patch ?? |
02:07.43 |
brlcad |
that task really souldn't take more than a
couple days at best |
02:07.59 |
brlcad |
it's possible .. a bit heavy for a patch,
might take a day |
02:08.17 |
brlcad |
(i.e. a few hours) |
02:08.45 |
andrecastelo |
hm i see.. |
02:10.28 |
brlcad |
but certainly would be impressive for a
patch |
02:10.52 |
brlcad |
folks for bz have already submitted patches
that are actually harder |
02:11.07 |
mafm |
I think that my router will reconnect, be
right back :D |
02:11.14 |
andrecastelo |
really?? hmm.. |
02:11.19 |
andrecastelo |
we have one week to deliver, right ? |
02:11.26 |
brlcad |
yep |
02:11.38 |
brlcad |
seriously though -- make the application
itself good first :) |
02:11.57 |
brlcad |
then work on the patch |
02:12.02 |
andrecastelo |
hm ok.. will do |
02:12.13 |
andrecastelo |
another thing |
02:13.56 |
andrecastelo |
i'm having a problem running the program..
tried compiling from source and at first i've got "Build: 133
succeeded, 1 failed.." |
02:14.10 |
andrecastelo |
then tried again and got " Build: 0 succeeded,
0 failed, 134 up-to-date, 0 skipped" |
02:14.21 |
andrecastelo |
tried running and got some problem with
libbu.dll |
02:14.36 |
brlcad |
maybe that could be your patch ;) |
02:14.47 |
brlcad |
a build system patch, figure out what went
wrong |
02:15.20 |
*** join/#brlcad mafm_
(n=mafm@89-180-59-113.net.novis.pt) |
02:16.41 |
andrecastelo |
hmm |
02:16.41 |
brlcad |
otherwise, that's not enough info to say
anything useful, would have to know what failed, what the error
was, maybe other factors |
02:17.00 |
andrecastelo |
yes, i was pasting it- http://rafb.net/p/61FfDf17.html |
02:17.56 |
brlcad |
it's trying to run asc2g to build our models
and failing to find some library |
02:18.13 |
brlcad |
was that the original 1 failed? |
02:18.34 |
andrecastelo |
it fails to find libbu.dll.. but it compiled
this library fine |
02:19.13 |
brlcad |
so needs a path added to the library search
paths |
02:20.33 |
andrecastelo |
ok, let me give it a try |
02:23.42 |
andrecastelo |
the library compiled fine, i guess it's just a
path problem |
02:26.30 |
mafm_ |
mafm: go away! |
02:27.21 |
Daytona |
hmm, two mafm's |
02:27.37 |
andrecastelo |
brlcad: http://rafb.net/p/jcpiTJ88.html |
02:27.43 |
mafm_ |
Daytona: as if one was not enough! |
02:27.49 |
Daytona |
LOL |
02:29.00 |
mafm |
that'll show him :) |
02:29.15 |
andrecastelo |
brlcad: found the problem - http://rafb.net/p/5XE59Z48.html |
02:29.43 |
andrecastelo |
i guess brlcad is not portuguese-friendly
? |
02:30.31 |
brlcad |
how so? |
02:30.57 |
brlcad |
it's failing because you don't have nsis
installed -- that's used to build the installer |
02:32.04 |
andrecastelo |
brlcad: true, but technically it would go to
another directory |
02:32.42 |
brlcad |
que? |
02:33.47 |
brlcad |
it'll go wherever it's configured to
go |
02:34.13 |
andrecastelo |
hm ok, i'll get nsis |
02:36.14 |
mafm |
"and that full nonexclusive copyright will be
assigned." -- what does that mean, that we have to assign copyright
as FSF requires for their projects? |
02:39.18 |
brlcad |
mafm: yeah, we use single-copyright |
02:41.33 |
andrecastelo |
brlcad: it's a minor bug perhaps concerning
non-english windows |
02:42.12 |
andrecastelo |
brlcad: because english windows defaults
installations to C:\Program files, and every other language version
has its own "Program Files" |
02:43.17 |
brlcad |
andrecastelo: perhaps |
02:43.21 |
andrecastelo |
brlcad: i installed nsis to the default
directory and the same problem occurred.. therefore we need to edit
the correct file to use a "program files" system var |
02:43.35 |
brlcad |
yeah |
02:44.06 |
andrecastelo |
but what is the correct file ? :b |
02:45.41 |
andrecastelo |
i don't think there's a way to do that
though |
02:55.25 |
mafm |
the 3D engine to use is strongly preferred to
be OGRE, anything, or not important to specify in the
proposal? |
02:56.08 |
hippieindamakin8 |
wat is it rt now ? |
02:56.53 |
mafm |
hippieindamakin8: that's a question for
me? |
02:57.12 |
hippieindamakin8 |
in general :) |
02:57.49 |
mafm |
that's from the project ideas, to make an
OpenGL-based GUI instead of MGED |
02:58.01 |
mafm |
and OGRE listed as possible one |
02:58.56 |
hippieindamakin8 |
ohh .. |
02:59.10 |
hippieindamakin8 |
yaya rt now everything is based on
MGED |
03:03.04 |
brlcad |
mafm: for the submitter to decide really, from
my own experience, testing, and connections, ogre really seems to
be one of the best fits |
03:04.43 |
mafm |
well, for me it's about the same if it's with
CrystalSpace, OpenSceneGraph or OGRE |
03:04.48 |
brlcad |
but it could just as easily be a java3d
interface with the right submittions |
03:05.01 |
mafm |
I see OGRE or OSG more suited for BRL-CAD as
we've talked yesterday |
03:05.53 |
mafm |
but since for me it's about the same, it's
better to let core developers decide I guess |
03:07.57 |
mafm |
so maybe I leave it open in the proposal and
to be decided later? |
03:08.26 |
mafm |
btw andrecastelo, I think that you maybe this
proposal is also well suited for you |
03:09.52 |
andrecastelo |
hmm |
03:10.16 |
andrecastelo |
i'm already studying the photonmap.c to see
what has been done and what hasn't |
03:12.05 |
brlcad |
mafm: it could be decided later |
03:13.12 |
mafm |
another thing is, what's the functionality to
replicate? e.g. 20% of MGED? |
03:13.16 |
brlcad |
more detail is generally better, but
particularly if you don't have a strong justification then ogre
would still be my preference as the one to start with (a LOT of
time has already been spent evaluating the various options
available) |
03:13.50 |
mafm |
or it's only the framework and the
functionality to be filled later? |
03:13.54 |
brlcad |
yeah |
03:14.22 |
brlcad |
having a debug command console would be useful
to have, logging services |
03:14.35 |
brlcad |
but mostly the console |
03:15.04 |
brlcad |
ability to get lists of geometry available,
loading them, displaying various representations (wireframe,
polygonal, etc) |
03:18.10 |
mafm |
loading them as in drawing a cube inside
OGRE? |
03:18.47 |
mafm |
with the vertex data coming from the server
backend? |
03:19.06 |
brlcad |
display lists, yes |
03:19.45 |
brlcad |
there is a client/server protocol being
developed (concurrently) that will manage the geometry
itself |
03:20.07 |
brlcad |
the client is a *thin* client, it just passes
commands/events to the backend and gets stuff back |
03:20.49 |
mafm |
yep, but the client would have to convert the
marshalled data to the 3d engine representation at list,
right? |
03:21.21 |
mafm |
and the same to position the camera and things
like that |
03:26.26 |
brlcad |
yep |
03:26.48 |
brlcad |
and/or make the protocol support reporting the
data in the format that the engine requires |
03:27.40 |
brlcad |
camera state management is predominantly a
client issue |
03:28.43 |
mafm |
brlcad: the protocol doing the translation you
mean? that would be part of my project anyway, I guess |
03:35.22 |
andrecastelo |
hey brlcad.. how functional is photonmap.c
? |
03:35.50 |
brlcad |
andrecastelo: if you pray to the gods and
sacrifice the right sized chicken heads, it works great |
03:36.11 |
hippieindamakin8 |
:)) paganism :P |
03:36.19 |
andrecastelo |
lol.. but do you know what exactly works and
what doesn't? |
03:36.27 |
brlcad |
example photonmap rendering http://brlcad.org/tmp/moss_pm.png |
03:37.32 |
andrecastelo |
hm, that cube shadow is a little off isn't it
? |
03:38.18 |
brlcad |
andrecastelo: usability is pretty poor (it's
complicated to use), effects through thin-walled objects is flawed
(the photons bleed), performance sucks unless you put the objects
in a box (all the photons go off into space) |
03:38.42 |
brlcad |
positionwise, no the shadows are
right |
03:39.38 |
brlcad |
there's a question as to whether it should be
light due to reflections, but otherwise right |
03:39.58 |
brlcad |
http://brlcad.org/tmp/moss_pm_2.png |
03:44.55 |
hippieindamakin8 |
cya ppl |
03:45.00 |
andrecastelo |
cya hippieindamakin8 |
03:45.00 |
hippieindamakin8 |
later |
03:45.40 |
mafm |
laterz :) |
03:48.03 |
andrecastelo |
brlcad: so, i'd have to rewrite part of
it |
03:48.15 |
brlcad |
andrecastelo: possibly |
03:48.59 |
brlcad |
implementing a bidirectional path-tracer would
pretty much trump photonmapping though |
03:49.05 |
mafm |
OK, I have everything but the plan
:PPP |
03:49.22 |
brlcad |
or a path tracer with photomapping
aspects |
03:49.33 |
brlcad |
or a path trace option to rt
directly |
03:49.37 |
andrecastelo |
at least the kd-tree functions are already
implemented.. those are usable, right ? |
03:49.49 |
brlcad |
yeah, you really don't worry about any of
that |
03:50.17 |
brlcad |
even for implementing some other global
illumination interface, you wouldn't worry about that |
03:50.29 |
mafm |
is there some talk in the mailing list, wiki
or whatever of the main features needed by the GUI? |
03:50.54 |
andrecastelo |
i see.. well, i thought photon mapping was the
most realistic method to implement GI |
03:51.07 |
brlcad |
andrecastelo: read up on http://brlcad.org/wiki/Developing_applications
.. talks about some of the basics of the shotline
interface |
03:51.21 |
brlcad |
no, photon-mapping isn't the most
realistic |
03:51.26 |
brlcad |
it's the fastest |
03:51.47 |
brlcad |
at least it can be fast |
03:52.26 |
brlcad |
bidirectional path-tracing is a brute-force
solution to the rendering equation, and converges generally to a
great answer |
03:52.46 |
brlcad |
that's what most people see when they look at
ultra-realistic images |
03:53.20 |
brlcad |
usually MLT |
03:54.24 |
mafm |
brlcad: is there some talk in the mailing
list, wiki or whatever of the main features needed by the
GUI? |
03:54.31 |
brlcad |
the brazil rendering system is probably one of
the best MLT implementations (http://www.splutterfish.com/sf/WebContent/Index) |
03:54.43 |
brlcad |
mafm: not really, at least not yet |
03:55.13 |
mafm |
:S |
03:55.15 |
brlcad |
for now, just think of it as a thin graphical
network client |
03:55.34 |
mafm |
yep, but I was trying to think about the
milestones |
03:55.44 |
brlcad |
that needs to display stuff obviously, look up
geometry, display it, spin it around, etc |
03:55.48 |
andrecastelo |
brlcad: those are amazing! |
03:56.11 |
mafm |
<slashdot> |
03:56.20 |
mafm |
1) Create hello world |
03:56.22 |
mafm |
2) ??? |
03:56.30 |
mafm |
3) GSoC completed!! |
03:56.34 |
mafm |
</slashdot> |
03:56.35 |
andrecastelo |
4) Profit!!! |
03:56.38 |
andrecastelo |
hehe |
03:57.02 |
brlcad |
andrecastelo: they were one of the first to
make detailed pictures that seriously looked real |
03:57.27 |
andrecastelo |
i was trying to write milestones too, that's
why i was asking about photonmap.c functionality |
03:57.59 |
mafm |
holy cow! those images are truly
amazing |
03:58.10 |
brlcad |
the milestones aren't necessarily set in
stone, it's mostly important to see that you've actually thought
through a timeline and design process that we can then talk
about |
03:59.17 |
andrecastelo |
what are the most important things in an app
? |
03:59.49 |
andrecastelo |
(for you guys) |
04:00.34 |
mafm |
why is the logging thing an important one?
it's logging what commands go back and forth for debugging, or
what? |
04:01.02 |
brlcad |
especially images like:
http://www.splutterfish.com/sf/WebContent/Gallery/Image/283?category=2&perpage=24&page=7
and
http://www.splutterfish.com/sf/WebContent/Gallery/Image/436?category=2&perpage=24&page=2 |
04:01.50 |
brlcad |
mafm: logging is one of those fundamental
things nice to have sorted out early on, for testing, development,
debugging, etc |
04:02.17 |
brlcad |
not critical for the app, I was just thinking
of basic infrastructure items |
04:02.23 |
andrecastelo |
brlcad: omg, those are beautiful |
04:03.35 |
brlcad |
you can do some cool stuff with metropolis
light transport, global illumination ;) |
04:03.55 |
mafm |
so milestones could be: logging, console,
being able to communicate with the back-end, displaying geometries,
rotating & positioning |
04:04.48 |
mafm |
displaying various representations (wireframe,
polygonal, etc) |
04:07.03 |
brlcad |
plus maybe clean cross-platform build system
integration, and input support (trackball, shift-grips) |
04:07.23 |
andrecastelo |
brlcad: so, what would be better, photon
mapping or bidirectional path tracing ?? |
04:07.52 |
brlcad |
andrecastelo: if you have experience with
neither, path tracing |
04:08.24 |
andrecastelo |
ok, i'll have to do some research to write the
application though |
04:08.26 |
brlcad |
the algorithm for forward path-tracing is like
100-200 lines of code |
04:08.49 |
brlcad |
maybe 10x for full bidirectional, and then
some for usability and render options |
04:10.03 |
mafm |
be right back |
04:12.44 |
andrecastelo |
brlcad: what's your timezone ? |
04:12.51 |
brlcad |
EDT |
04:13.05 |
andrecastelo |
how many hours from UTC ? |
04:13.11 |
brlcad |
-4 |
04:13.26 |
andrecastelo |
great |
04:13.50 |
andrecastelo |
i'll be back tomorrow in the morning to finish
discussing the application ;) |
04:14.25 |
andrecastelo |
good night |
04:14.32 |
andrecastelo |
mafm: good night man, cya |
04:17.23 |
brlcad |
waves |
04:34.32 |
mafm |
sighs |
04:34.43 |
mafm |
maybe I'm lucky and get 3h of sleep today
:) |
04:41.13 |
mafm |
brlcad: there it is |
04:41.28 |
brlcad |
there what is? |
04:42.43 |
brlcad |
ah, to the mailing list |
04:42.45 |
brlcad |
got it |
04:43.24 |
mafm |
and to the Google's webapp too |
04:43.54 |
brlcad |
looks good, gracias |
04:44.01 |
mafm |
yw :) |
04:48.34 |
mafm |
it's about time to sleep, night :) |
05:00.27 |
*** join/#brlcad spik1
(n=spike@eridani.acm.jhu.edu) |
05:56.31 |
*** join/#brlcad clock_
(n=clock@217-162-111-241.dclient.hispeed.ch) |
07:16.13 |
*** join/#brlcad clock_
(n=clock@zux221-122-143.adsl.green.ch) |
07:23.18 |
*** join/#brlcad homovulgaris
(n=ca3fe93d@bz.bzflag.bz) |
08:09.20 |
*** join/#brlcad yukonbob_
(i=1000@s142-179-54-198.bc.hsia.telus.net) |
08:09.20 |
*** join/#brlcad homovulgaris
(n=ca3fe93d@bz.bzflag.bz) [NETSPLIT VICTIM] |
08:09.20 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
08:09.20 |
*** join/#brlcad ``Erik
(i=erik@c-68-54-174-162.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
08:11.50 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
08:19.14 |
*** join/#brlcad yukonbob_
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
08:19.14 |
*** join/#brlcad homovulgaris
(n=ca3fe93d@bz.bzflag.bz) [NETSPLIT VICTIM] |
08:19.14 |
*** join/#brlcad ``Erik
(i=erik@c-68-54-174-162.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
10:01.05 |
*** join/#brlcad Maloeran
(n=maloeran@glvortex.net) |
10:51.11 |
*** join/#brlcad
MinuteElectron
(n=MinuteEl@silentflame/member/pdpc.base.minuteelectron) |
10:56.42 |
*** join/#brlcad andrecastelo
(n=pulse@189.71.62.248) |
10:56.53 |
andrecastelo |
good morning everyone |
11:27.18 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
11:58.11 |
*** join/#brlcad clock_
(n=clock@zux221-122-143.adsl.green.ch) |
12:37.52 |
andrecastelo |
hey brlcad :) |
12:37.54 |
andrecastelo |
you there? |
12:47.03 |
*** join/#brlcad mafm
(n=mafm@elnet-111.lip.pt) |
12:48.45 |
mafm |
hallo |
13:00.13 |
*** join/#brlcad CIA-34
(n=CIA@208.69.182.149) |
13:22.20 |
brlcad |
hallo |
13:34.54 |
d_rossberg |
brlcad: the tags/7.12.0 won't compile on
windows (cpp issue) |
13:35.09 |
d_rossberg |
it looks like bob solved it for the
trunk |
13:35.26 |
brlcad |
cpp issue? |
13:38.00 |
d_rossberg |
math.h is included in a cpp file but in an
extern "C" section |
13:38.30 |
d_rossberg |
the problem is: math.h defines templates if it
is included in a cpp file |
13:38.53 |
d_rossberg |
however, this won't work with extern
"C" |
13:39.13 |
brlcad |
ah, yeah I think I actually may have fixed
that one |
13:39.41 |
d_rossberg |
yes, it looks like it's fixed on the
trunk |
13:40.37 |
brlcad |
the bigger question is why the .exe isn't
working, haven't had a chance to poke at that yet |
13:41.54 |
d_rossberg |
which exe? the install.exe and mged.exe work
on my computer (MS Windows XP) |
13:42.13 |
brlcad |
the 7.12.0 test binary |
13:42.37 |
brlcad |
ftp://ftp.brlcad.org/incoming/brlcad-7.12.0.exe |
13:42.40 |
d_rossberg |
the is what i was talking about |
13:42.50 |
brlcad |
wim couldn't get it to work |
13:43.20 |
d_rossberg |
what os does he use: xp or vista? |
13:43.35 |
brlcad |
course his e-mail apparently just died too --
him and another just got delisted from the mailing list due to
bounced e-mails :) |
13:45.11 |
d_rossberg |
BUT: rt does not work (at least from mged),
even a ray-trace to a file fails |
13:45.40 |
brlcad |
i believe wim was on xp |
13:45.56 |
brlcad |
what's rt fail with? runtime linker
error? |
13:47.19 |
d_rossberg |
nor error, it says "Raytrace
complete" |
13:49.22 |
brlcad |
then it's probably crashing |
13:49.34 |
brlcad |
does it produce any output? like the prep
output? |
13:50.11 |
d_rossberg |
no, at least not on the mged window |
13:51.39 |
brlcad |
bob's finally back this week, I'll mention it
to him |
13:55.11 |
d_rossberg |
maybe i could be more useful if i get my new
VS running |
13:55.47 |
d_rossberg |
i got it today and at the moment i try to get
my old projects running with it |
13:55.57 |
d_rossberg |
this could take some time ... |
14:00.59 |
brlcad |
nods |
14:02.20 |
brlcad |
feel free to comment on any of the submissions
.. |
14:29.51 |
*** join/#brlcad andrecastelo
(n=pulse@189.71.62.248) |
14:29.59 |
brlcad |
hello andrecastelo |
14:30.01 |
andrecastelo |
hi everyone |
14:30.03 |
andrecastelo |
hey brlcad |
14:30.10 |
brlcad |
responded to your submission |
14:30.14 |
andrecastelo |
just read the comment on the app |
14:30.21 |
andrecastelo |
yeah, just saw it ;) |
14:30.50 |
andrecastelo |
you want more detail about how MTL would
interact with BRL-CAD's existing libraries, right ? |
14:31.08 |
brlcad |
yeah, just a little more detail about how it
ties to us |
14:31.36 |
andrecastelo |
hm, ok |
14:31.38 |
brlcad |
you've shown reasonable competency in the task
itself, but there's not much in the way of how it integrates with
our code |
14:32.04 |
andrecastelo |
hm, ok, i'll try to detail further and it'll
be ready in a minute |
14:32.20 |
brlcad |
what library/routines would you possibly be
using for example -- does it leverage existing functionality (or
not) |
14:33.43 |
brlcad |
emphasis on most tools are tools that
*integrate* with brl-cad cleanly, that aren't just stand-alone apps
being added to an otherwise already massive codebase, replicating
existing functionality for example |
14:34.12 |
brlcad |
also just to show me that you have at least
done your homework on what we actually already provide |
14:35.08 |
brlcad |
you also never explicitly mention what
language you'd be working in or forsee implementing this
in |
14:35.14 |
brlcad |
i.e. more implementation detail ;) |
14:35.22 |
brlcad |
otherwise a good submission |
14:35.33 |
andrecastelo |
hm ok, i thought C was implicit :b |
14:35.53 |
andrecastelo |
i'll include these details, though |
14:36.08 |
brlcad |
C or C++ is preferred, but not exactly
required -- that's a design decision |
14:36.27 |
brlcad |
I'd be perfectly willing to consider another
language if someone makes a strong valid case (good luck with that
:) |
14:37.00 |
andrecastelo |
brlcad: is it possible to implement that in
C++ ? |
14:37.14 |
brlcad |
yes |
14:37.20 |
andrecastelo |
i mean, wouldn't it kind of conflict with
existing code.. ? |
14:37.38 |
brlcad |
it would have to live in a directory of its
own, but no |
14:37.45 |
andrecastelo |
ok, i'll add some justification why C++ would
be better then |
14:37.45 |
brlcad |
we already have some C++ interfaces |
14:38.11 |
brlcad |
you should know where we use C++ already
:) |
14:39.42 |
brlcad |
if you do propose C++, I'd also expect you to
speak of basic performance profiling as well |
14:40.43 |
andrecastelo |
performance profiling ? |
14:41.31 |
brlcad |
sanity checks to make sure it's not spinning
its wheels in abstractions |
14:43.16 |
andrecastelo |
hm ok ok.. |
14:44.29 |
brlcad |
path tracers are very expensive, the same
really holds true for a C implementation too -- but even more so
for C++ |
15:01.28 |
andrecastelo |
hey brlcad - would it be better for me to
reuse some of the ray tracer code for the path tracer or just write
one from scratch ? |
15:01.37 |
brlcad |
heh |
15:01.41 |
brlcad |
which do you think |
15:02.28 |
andrecastelo |
reuse the code for a prototype
version |
15:02.31 |
brlcad |
"10:33 <@brlcad> emphasis on most tools
are tools that *integrate* with brl-cad cleanly, that aren't just
stand-alone apps being added to an otherwise already massive
codebase replicating existing functionality for example" |
15:02.33 |
andrecastelo |
then extend it to become fully
functional |
15:02.43 |
brlcad |
we already shoot rays |
15:02.57 |
brlcad |
one of the specific intents is to use librt
for ray shooting |
15:03.50 |
brlcad |
see the links I posted yesterday about
developing brl-cad applications |
15:03.58 |
andrecastelo |
alright |
15:14.15 |
*** topic/#brlcad by brlcad
-> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad
|| Channel logs at http://ibot.rikers.org/%23brlcad/
|| BRL-CAD is participating in the 2008 Google Summer of Code, see
http://brlcad.org/wiki/Google_Summer_of_Code
and join the developer mailing list || GSoC application submissions
are (STILL) open with a one-week extension, submission deadline is
now April 7th |
15:14.52 |
brlcad |
kudos to those of you that got your
submissions in on time :) |
15:16.50 |
andrecastelo |
brlcad: this week will be really useful for me
to get familiar with the code and detail it even further
;) |
15:17.52 |
brlcad |
andrecastelo: glad to hear it :) |
15:27.04 |
andrecastelo |
brlcad: hm, so, i updated the application with
the details you wanted ;) |
15:27.22 |
andrecastelo |
i'm open to critics and suggestions
now |
15:32.50 |
*** join/#brlcad Jai
(n=Jai@202.3.77.38) |
15:37.40 |
mafm |
1 week extensions??? |
15:39.27 |
andrecastelo |
mafm: yup :) |
15:39.49 |
mafm |
pff |
15:39.56 |
andrecastelo |
why pff ? |
15:39.59 |
mafm |
and I only slept 3h tonight because of that
:P |
15:49.59 |
brlcad |
mafm: hehe, well it does speak well for those
that got their applications in on time |
15:50.08 |
brlcad |
it's an edge |
15:52.54 |
mafm |
no need to send a box of Oporto wine to the
mentors then? |
15:53.02 |
brlcad |
hehe |
15:53.35 |
brlcad |
never said he could or could
not be bribed with women and alcohol |
15:56.06 |
mafm |
let's just keep the alcohol thing, you
wouldn't want to meet most portuguese women :P |
15:56.28 |
andrecastelo |
mafm: great, i'll supply the women |
15:56.32 |
brlcad |
:) |
15:56.37 |
andrecastelo |
:P |
15:57.56 |
*** join/#brlcad Daytona
(n=jra@c-68-55-36-65.hsd1.md.comcast.net) |
15:58.22 |
Daytona |
brlcad: I just saw that the application
extension is official |
16:00.57 |
mafm |
that's a real news flash :) |
16:01.27 |
brlcad |
heh |
16:01.46 |
brlcad |
drive by daytona! |
16:12.55 |
mafm |
<lh> brlcad: you are cruel and
vicious |
16:12.56 |
mafm |
lol |
16:13.11 |
mafm |
I think that brlcad is served in the women
dept. |
16:13.21 |
brlcad |
lubs the
leslie |
16:13.46 |
mafm |
no luck for you andrecastelo, I think that you
might better try with brazilian coffee or something :) |
16:14.52 |
brlcad |
mafm: the comments also take on quite a
different tone when you've met many of them :) |
16:15.10 |
*** join/#brlcad vedge
(i=vedge@vedge.org) |
16:15.36 |
mafm |
did you go to the mentor summit last
year? |
16:15.44 |
brlcad |
yeah |
16:15.51 |
brlcad |
fun stuff |
16:15.54 |
mafm |
btw, how many applications are there? ~20 for
CrystalSpace |
16:16.42 |
brlcad |
fewer, but close hold until the deadline
:) |
16:17.42 |
mafm |
probably they'll get more too, it was less
than 20 yesterday, but probably there will be 5 or 10 today before
the former deadline |
16:17.51 |
brlcad |
the interesting thing is that right now there
are probably 4 really strong applicants and we were only going to
accept at most 4 ... :) |
16:18.35 |
mafm |
how so? don't you want to accept more, if they
give you the chance? |
16:18.36 |
brlcad |
hopefully the apps keep improving, it'll be a
tight competition |
16:18.50 |
brlcad |
no no |
16:19.28 |
brlcad |
i just saying that 4 are *really* strong, so
if there wasn't an extension -- the list of who gets selected is
pretty straightforward |
16:20.02 |
brlcad |
now with an extension, it just becomes more
competitive .. if more really strong apps come in |
16:20.26 |
hippieindamakin8 |
good morning fellows :) |
16:21.12 |
mafm |
I see :) |
16:21.48 |
andrecastelo |
brlcad: how many mentors does brlcad have
? |
16:21.59 |
andrecastelo |
that seems to be the student cap, right
? |
16:22.19 |
brlcad |
we have 6 mentors at present |
16:22.46 |
brlcad |
with two potential backups |
16:22.57 |
brlcad |
but no, that's not the cap |
16:23.16 |
brlcad |
they can't all be managed effectively with
that many -- that's why we're looking at just 2-4 |
16:23.42 |
andrecastelo |
but the organizations do define a max number
of students, right ? |
16:23.42 |
brlcad |
takes time to integrate, review code, plan,
etc |
16:23.46 |
brlcad |
right |
16:23.48 |
andrecastelo |
i see |
16:23.49 |
brlcad |
our max is 4 |
16:24.01 |
brlcad |
i don't want more than 4 for brl-cad this
year |
16:24.12 |
andrecastelo |
i hope i can make my application compete with
those 4 strong ones you talked about :) |
16:24.45 |
brlcad |
that's also why having students speak to what
interests them in the long run becomes useful, we'd like new
long-term developers not just projects worked on |
16:25.47 |
brlcad |
here's an example of a really strong
application received for bzflag, http://my.bzflag.org/w/User:Jude- |
16:26.33 |
brlcad |
detailed, careful thoughts on implementation,
ties to our code, timelines, etc |
16:31.29 |
hippieindamakin8 |
mafm are u dawn thomas ? |
16:32.25 |
hippieindamakin8 |
ohh its somebody else from india |
16:39.01 |
mafm |
nope, I'm Manuel A. Fernandez Montecelo (hence
the acronym of my nick, not the most creative thing
really) |
16:41.45 |
hippieindamakin8 |
:) |
16:43.49 |
yukonbob_ |
waves in |
16:44.00 |
yukonbob_ |
ohh --- I'm a ghosty |
16:52.23 |
brlcad |
howdy yukonbob_ |
16:52.28 |
yukonbob_ |
:) |
16:52.44 |
yukonbob_ |
doesn't have his
tail-removing instructions with him atm :P |
16:53.07 |
yukonbob_ |
it's a msg to nicserv, but I don't remember
what... |
16:56.42 |
yukonbob |
what's the status of the GSoC -- on schedule,
or extended? |
16:59.38 |
brlcad |
points at topic
;) |
17:20.11 |
*** join/#brlcad dtidrow
(n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
17:23.03 |
``Erik |
erm |
17:23.06 |
``Erik |
why? |
17:23.18 |
``Erik |
lack of solid submissions? :( |
17:24.45 |
``Erik |
<-- thought the expectation was ~50 "good"
submissions |
17:25.13 |
``Erik |
no, I have not been reading my
email. |
17:25.14 |
``Erik |
:D |
17:47.18 |
mafm |
50 good submissions?? |
17:48.06 |
mafm |
that's a lot |
17:51.51 |
*** join/#brlcad Elperion
(n=Bary@p54874DCE.dip.t-dialin.net) |
17:54.58 |
``Erik |
mebbe I had pie in the sky
aspirations |
18:21.11 |
hippieindamakin8 |
i am done making a proposal |
18:21.48 |
mafm |
about what? |
18:36.27 |
mafm |
hippieindamakin8: ? |
18:48.35 |
hippieindamakin8 |
OOP geometry |
18:49.23 |
hippieindamakin8 |
its about OOP geometry engine mafm |
18:57.09 |
*** join/#brlcad clock_
(n=clock@77-56-79-63.dclient.hispeed.ch) |
19:01.05 |
mafm |
ah ok |
19:01.21 |
mafm |
I had thought about that project too |
19:04.01 |
yukonbob |
re: topic, me nods, points out that the irrsi
topic-line across top doesn't show novels ;) |
19:07.46 |
hippieindamakin8 |
i might put in a proposal for the web
repository as well |
19:17.48 |
yukonbob |
wonders, is there an official
msg from Google re: this extension -- on the gsoc
(code.google.com/...) the timelines still show the deadline as
31Mar |
19:18.09 |
brlcad |
``Erik: given how similar i'm seeing our rate
is to bz's, that would have resulted in about 25 "good"
ones |
19:18.44 |
brlcad |
thinks ``Erik should comment
on the submissions more |
19:19.38 |
mafm |
yukonbob: do you mean if the extension is for
real? |
19:20.31 |
yukonbob |
mafm: see brlcad's note to me re:
topic |
19:20.33 |
brlcad |
yukonbob: depends how big your window is too
:) |
19:20.52 |
brlcad |
sees it all |
19:21.08 |
yukonbob |
brlcad: heh -- not all of us are developing on
16-way multi-gpu chromium-equipped workstations ;) |
19:21.22 |
brlcad |
mmm.. 16-way |
19:21.34 |
yukonbob |
laughs |
19:21.39 |
yukonbob |
what a bunch of nerds we are. |
19:26.41 |
yukonbob |
looks for discussion brlcad
and self had re: other projects... |
19:27.47 |
brlcad |
thinks yukonbob should
mentor |
19:28.38 |
mafm |
why do you keep saying "re: something"? I
don't understand at least half of your phrases |
19:28.53 |
brlcad |
re: == regarding |
19:29.45 |
yukonbob |
brlcad: my heart has always been 100%
agreeable to that, but I've held off just for logistic
reasons... |
19:29.52 |
yukonbob |
bets he _will_
mentor |
19:29.59 |
yukonbob |
do I need to register or anything? |
19:30.08 |
brlcad |
you would need to, yes |
19:30.08 |
yukonbob |
(by some deadline?) |
19:30.12 |
mafm |
ah ok |
19:30.24 |
brlcad |
by then end of the week |
19:30.36 |
yukonbob |
fine, fine ;) |
19:30.39 |
brlcad |
er, by the time we start ranking
actually |
19:30.47 |
brlcad |
which is probably the day apps close |
19:30.58 |
brlcad |
I can't add you though, you have to do
it |
19:31.23 |
yukonbob |
ok -- I'll do that now... |
19:31.33 |
mafm |
I guess that they'll extend it for another two
weeks or something :P |
19:32.11 |
yukonbob |
mafm: 1 week |
19:33.02 |
brlcad |
yeah, just one week, mentors then still have
their 12+ days to deliberate, rank, and ask for more
detail |
19:33.25 |
brlcad |
then there's a community bonding time frame
for about 5 weeks |
19:34.11 |
mafm |
just kidding, I was saying that by the time
that the new deadline is reached, maybe they extend it for another
2 weeks :) |
19:34.16 |
brlcad |
where students get familiarized, hopefully
start committing, learn what they need to |
19:34.24 |
brlcad |
ahh, heh, not likely |
19:35.04 |
brlcad |
4300 or so applicants was probably enough to
stay on schedule -- adding another week it just going to make it a
heck of a lot more competitive |
19:35.22 |
brlcad |
as there will likely be 6000-8000 applicants I
bet |
19:36.04 |
brlcad |
which means for a group like ours, we're going
to have anywhere from 8-16 people competiting for 2-4
slots |
19:37.03 |
yukonbob |
finishes mentor
application |
19:39.07 |
brlcad |
wonders wtf Avinash Dubey
is |
19:39.18 |
brlcad |
rejects |
19:44.32 |
mafm |
I go now, night |
19:45.21 |
*** join/#brlcad spike_
(i=[U2FsdGV@centaur.acm.jhu.edu) |
19:56.22 |
yukonbob |
has to log-off temporarily
(battery) -- chat later, folks |
20:51.05 |
*** join/#brlcad Elperion
(n=Bary@p54874DCE.dip.t-dialin.net) |
21:33.20 |
yukonbob |
returns, like he never even
left (thx, screen(1)) |
21:50.16 |
yukonbob |
wonders (speaking of
meta-projects like GSoC and BRL-CAD) -- is there any progress on
Coverity and BRL-CAD? |
21:53.25 |
brlcad |
i emailed dave yet again, no
response |
21:57.08 |
hippieindamakin8 |
hey brlcad are u there |
21:57.09 |
hippieindamakin8 |
? |
21:57.30 |
brlcad |
nope |
21:57.38 |
brlcad |
~ask |
21:57.39 |
ibot |
Questions in the channel should be specific,
informative, complete, concise, and on-topic. Don't ask if you can
ask a question first. Don't ask if a person is there, just ask
what you intended to ask them. Better questions more frequently
yield better answers. We are all here voluntarily or against our
will. |
21:58.58 |
yukonbob |
likes the "against our will"
description |
21:59.51 |
hippieindamakin8 |
ya wanted to submit my proposal :) |
21:59.54 |
yukonbob |
receives cattle prod, and is
instructed to refrain from meta-comments |
22:00.25 |
yukonbob |
hippieindamakin8: submit it, and it will be
commented on |
22:00.47 |
hippieindamakin8 |
:) ya |
22:01.29 |
hippieindamakin8 |
brlcad can the user define his primitives
? |
22:01.54 |
brlcad |
huh? |
22:02.06 |
yukonbob |
hippieindamakin8: in what sense? Primitives
are "primitive" -- they're the core bits that "stuff" is made
from... |
22:02.32 |
hippieindamakin8 |
like in AUTOCAD inventor 3d modelling and
solidworks .. i add 2 already existing primitives and they can
define it as another primitive |
22:02.36 |
hippieindamakin8 |
for his later worl |
22:02.46 |
hippieindamakin8 |
*work |
22:03.00 |
yukonbob |
read vol II, iirc about regions,
etc. |
22:03.17 |
hippieindamakin8 |
smthing like.. a template |
22:06.46 |
brlcad |
yes, you can do that -- they're not called
primitives, though -- they are combinations |
22:07.01 |
brlcad |
primitives are the most fundamental object
type |
22:10.57 |
hippieindamakin8 |
ohk.. like when i used AUTOCAD, it calls it
user defined primitive |
22:13.22 |
hippieindamakin8 |
just sent the proposal |
22:14.13 |
yukonbob |
s/vol II/ Vol III/; s/regions/combinations and
regions/ -- (http://brlcad.org/wiki/Documentation) |
22:15.37 |
hippieindamakin8 |
thanks yukonbob |
22:15.39 |
yukonbob |
np |
22:15.49 |
yukonbob |
~doc |
22:15.49 |
ibot |
Documentation can be found at http://digium.com/index.php?menu=documentation
or http://www.digium.com/handbook-draft.pdf
or http://www.voip-info.org/wiki-Asterisk
or http://www.asteriskdocs.org or
http://www.oreilly.com/catalog/asterisk |
22:16.00 |
yukonbob |
hrm... |
22:16.12 |
yukonbob |
^-- not for you, hippieindamakin8 |
22:16.14 |
yukonbob |
: |
22:16.17 |
yukonbob |
: |
22:16.21 |
hippieindamakin8 |
ya got it :) |
22:16.25 |
yukonbob |
:), rather |
22:16.44 |
hippieindamakin8 |
hates lab reports and open
office the most |
22:16.57 |
yukonbob |
hates bad
coffee |
22:20.21 |
hippieindamakin8 |
is waiting for comments from
brlcad and yukonbob |
22:20.38 |
brlcad |
hippieindamakin8: be patient |
22:20.47 |
hippieindamakin8 |
ohk :) i am |
22:20.49 |
brlcad |
it might take hours or even days |
22:21.08 |
hippieindamakin8 |
that was just a message .. i shall get back to
my lab reports |
22:21.11 |
brlcad |
work on a patch in the meantime :) |
22:21.27 |
hippieindamakin8 |
yaya.. hey is the nsis installer working
properly? |
22:21.47 |
brlcad |
the patches will probably be a huge deciding
factor given the extension |
22:21.53 |
hippieindamakin8 |
i wanted to do that though :P |
22:21.53 |
brlcad |
works for me |
22:22.05 |
hippieindamakin8 |
ya i understand :| |
22:22.15 |
brlcad |
could do the localization fix that was
mentioned yesterday |
22:22.22 |
brlcad |
so it doesn't just assume "Program
Files" |
22:22.30 |
hippieindamakin8 |
ohk... |
22:22.34 |
hippieindamakin8 |
i ll have to chk.. |
22:22.56 |
hippieindamakin8 |
i have no windows rt now.. i shall get to it
in a day or 2 |
22:23.22 |
hippieindamakin8 |
wats the new deadline for the submission of
patches ? |
22:24.59 |
yukonbob |
hippieindamakin8: you mean for GSoC proposals?
7 Apr. |
22:25.09 |
hippieindamakin8 |
no the patches |
22:25.59 |
brlcad |
technically they're optional, but you'll not
likely get selected if you don't provide a patch given how
competitive it's going to be |
22:26.35 |
brlcad |
given we start ranking on the 7th, it's in
your best interest to have something done by then or very shortly
thereafter |
22:31.48 |
hippieindamakin8 |
ya i sure want to submit a patch |
22:32.27 |
yukonbob |
go for it!! |
22:32.28 |
brlcad |
you sure do |
22:32.43 |
yukonbob |
cheers "submit a patch!
submit a patch!" |
22:34.14 |
yukonbob |
also gets a glass of
water... |
23:10.09 |
poolio |
hippieindamakin8: Submit a documentation patch
:) |
23:10.18 |
poolio |
brlcad: how's the gsoc going? |
23:11.27 |
hippieindamakin8 |
cool :) |
23:12.09 |
hippieindamakin8 |
ya seen them in the list of TODOs |
23:12.17 |
brlcad |
code patch would probably be preferred since
one of the points is to see how you code, but yeah, even a
documentation patch would work :) |
23:12.25 |
brlcad |
poolio: fun fun |
23:12.33 |
brlcad |
some good proposals to evaluate |
23:12.36 |
hippieindamakin8 |
i shall try for a technical patch first and
then i shall come up with docs when i am unable to do
that |
23:14.01 |
hippieindamakin8 |
i shall be submitting it by 9th .. will it do
?? too many academic committments rt now with the end semester
examinations approaching |
23:14.01 |
brlcad |
looking at the bug and feature requests on
sf.net is also recommended |
23:14.06 |
hippieindamakin8 |
i am trying to keep a track of them |
23:43.44 |
hippieindamakin8 |
brlcad: Sean w.r.t ur slashdot post |
23:44.04 |
brlcad |
que? |
23:44.05 |
hippieindamakin8 |
<PROTECTED> |
23:44.19 |
hippieindamakin8 |
:) |
23:44.20 |
brlcad |
doesn't mean computer science degree
students |
23:44.34 |
hippieindamakin8 |
i aint :) and it is open to all |
23:45.07 |
brlcad |
the fact that they are working on code as
stucents makes them "computer science students" over the course of
the summer |
23:46.00 |
hippieindamakin8 |
:) thats true |
23:46.08 |
poolio |
brlcad: at some schools that's an
insult |
23:46.42 |
brlcad |
the wording is actually based off of google's
own original announcements from chris |
23:46.56 |
hippieindamakin8 |
ya my school considers my contribution to the
firefox and imageprocessing community a big waste of time
:P |
23:47.18 |
brlcad |
more power to them if they're insulted, less
rediculous people to have to deal with during the review
process |
23:47.29 |
hippieindamakin8 |
its ohk.. :) wat Sean wrote is actually rt but
literally not :) |
23:47.40 |
brlcad |
you're missing the point |
23:47.47 |
brlcad |
literally it is the case, it doesn't say
degree |
23:47.59 |
hippieindamakin8 |
aah yeah |
23:48.12 |
hippieindamakin8 |
ya that is ppl interested in CS |
23:49.33 |
hippieindamakin8 |
my school is completely ridiculous in the
point that when enrolled in mechanical engg u are just supposed to
take mechanical engg courses when given an option for an
elective |
23:50.49 |
yukonbob |
isn't that point neither here not there,
though -- the only way the school (maybe) needs to be involved is
to verify you're enrolled in school... you could get a job selling
ice-cream for the summer if you like, too... |
23:51.19 |
yukonbob |
...whether it's related to your studies or
not, or whether the school likes it or not... |
23:51.23 |
hippieindamakin8 |
hehe |
23:51.33 |
brlcad |
yep, in fact that's exactly what one of the
bzflag gsoc students did last year |
23:52.17 |
brlcad |
(and he was ultimately failed due to lack of
progress and inadequate time put forth) |
23:52.45 |
yukonbob |
heh |
23:53.25 |
yukonbob |
off-topic: how suitable would the bzflag
framework be to building a virtual world, a la second life...
perhaps one could have a project setting up a virtual ice-cream
shop? |
23:53.39 |
brlcad |
heh, doable |
23:53.50 |
yukonbob |
makes note |
23:53.50 |
poolio |
yukonbob: Just out of curiousity, for what
purpose would this virtual world exist? |
23:54.01 |
brlcad |
there's no dynamic geometry right now, that'd
require modifications |
23:54.04 |
yukonbob |
feh -- same reason second life exists, I
guess... |
23:54.13 |
poolio |
Although there are probably a ton of better
frameworks out there. |
23:54.19 |
yukonbob |
sure |
23:54.27 |
poolio |
yukonbob: entertainment? There are some AGI
people trying to hook up to virtual worlds for the purpose of
learning |
23:54.31 |
brlcad |
blasphemy! |
23:54.41 |
poolio |
... |
23:54.42 |
brlcad |
nothing is better than bzflag |
23:54.45 |
brlcad |
except brl-cad |
23:54.46 |
yukonbob |
laughs -- brlcad is
agitated!!! |
23:54.51 |
hippieindamakin8 |
:)) |
23:54.52 |
poolio |
brlcad: Can I quote you on this? |
23:55.01 |
brlcad |
hehe, sure |
23:55.34 |
brlcad |
gets craving for chinese
food |
23:56.26 |
yukonbob |
is interested in machinema
(sp?) -- perhaps brl-cad and bzflag could provide the bulk of the
framework to make a video... |
23:56.37 |
yukonbob |
meow |
23:57.30 |
yukonbob |
does bzflag support any easy-to-do
articulation? (/me thinks "no") |
23:57.48 |
brlcad |
bzflag doesn't support any
articulation |
23:57.58 |
brlcad |
"no dynamic geometry" |
23:58.04 |
yukonbob |
GSoC ;) |
23:58.19 |
brlcad |
not something I'd rank high on our priority
list :) |
23:58.56 |
yukonbob |
can hardly wait to get a
'puter w/ hardware acceleration to get bzflag installed
again... |