00:41.47 |
Notify |
03BRL-CAD Wiki:Sullivanjd * 0
/wiki/User:Sullivanjd: |
01:50.57 |
*** join/#brlcad kesha
(~kesha@49.249.1.70) |
03:47.04 |
Notify |
03BRL-CAD:brlcad * 55311 brlcad/trunk/BUGS:
richards efforts to test all of our sample geometry conversion to
nurbs uncovered a bug in rendering operators.g:ehy in brep
form. |
04:08.07 |
brlcad |
woot, down to four issues |
04:49.00 |
Notify |
03BRL-CAD:phoenixyjll * 55312
brlcad/trunk/src/libbrep/opennurbs_ext.cpp: Loop detection in 3D
space and 2D space should be done separately. |
04:53.57 |
kanzure |
neat. |
04:58.17 |
*** join/#brlcad kesha
(~kesha@49.249.1.70) |
05:06.53 |
*** join/#brlcad avneet
(caa43575@gateway/web/freenode/ip.202.164.53.117) |
05:29.04 |
*** join/#brlcad kesha_
(~kesha@49.249.1.70) |
05:34.19 |
*** join/#brlcad avneet
(caa43575@gateway/web/freenode/ip.202.164.53.117) |
05:49.24 |
*** join/#brlcad avneet
(caa43575@gateway/web/freenode/ip.202.164.53.117) |
06:52.52 |
*** join/#brlcad kesha_
(~kesha@49.249.1.70) |
07:54.25 |
*** join/#brlcad jasleen
(~chatzilla@202.164.53.118) |
07:54.50 |
*** join/#brlcad avneet
(~avneet@202.164.53.122) |
07:59.24 |
*** join/#brlcad avneet_
(caa43575@gateway/web/freenode/ip.202.164.53.117) |
07:59.46 |
*** part/#brlcad avneet_
(caa43575@gateway/web/freenode/ip.202.164.53.117) |
08:02.06 |
Notify |
03BRL-CAD Wiki:Hhhhsfffoss * 0
/wiki/User:Hhhhsfffoss: |
08:05.13 |
*** join/#brlcad jasleen
(~jasleen@202.164.53.122) |
08:18.53 |
*** join/#brlcad avneet_
(~avneet@202.164.53.122) |
08:25.38 |
*** join/#brlcad jasleen__
(~jasleen@202.164.53.122) |
08:44.34 |
*** join/#brlcad jasleen
(~jasleen@202.164.53.122) |
08:46.56 |
*** join/#brlcad jasleen
(~jasleen@202.164.53.122) |
11:27.03 |
*** join/#brlcad d_rossberg
(~rossberg@66-118-151-70.static.sagonet.net) |
11:34.13 |
*** join/#brlcad caen23_
(~caen23@92.81.171.97) |
13:26.33 |
*** join/#brlcad cstirk
(~quassel@c-71-56-216-45.hsd1.co.comcast.net) |
14:42.13 |
*** join/#brlcad zero_level
(7aa1eb64@gateway/web/freenode/ip.122.161.235.100) |
14:48.17 |
*** join/#brlcad crdueck
(~cdk@24.212.219.10) |
15:08.28 |
*** join/#brlcad kesha_
(~kesha@49.249.18.107) |
15:16.49 |
*** join/#brlcad zero_level
(~androirc@122.161.235.100) |
16:08.54 |
*** join/#brlcad cstirk
(~quassel@c-71-56-216-45.hsd1.co.comcast.net) |
16:18.24 |
Notify |
03BRL-CAD:r_weiss * 55313
brlcad/trunk/sh/cmp.sh: Bug fix to 'cmp.sh' script to fix 'g_qa'
volume testing. |
16:26.56 |
Notify |
03BRL-CAD:carlmoore * 55314
brlcad/trunk/src/sig/smod.c: implement 'progname' in output
statements, and be concerned with cosmetic stuff (looking like
umod.c as much as possible) |
16:33.12 |
Notify |
03BRL-CAD:carlmoore * 55315
brlcad/trunk/src/sig/umod.c: cosmetic changes (look like smod.c as
much as possible); implement progname in outputs (some hardwired
usages had wrong name); implement 'usage' variable; add an
'else' |
16:37.37 |
*** join/#brlcad caen23
(~caen23@92.83.172.247) |
16:44.11 |
Notify |
03BRL-CAD:carlmoore * 55316
brlcad/trunk/src/sig/dmod.c: implement progname in
outputs |
17:10.06 |
kesha_ |
Plz Help me understand this http://pastebin.mozilla.org/2382431
. I changed the reference in src/fedex_plus/CMakeLists.txt from
"non-ors.cc" to "../clstepcore/non-ors.cc" and the same in
fedex_python after removing the file non-ors.cc in
src/fedex_plus/ |
17:18.21 |
Notify |
03BRL-CAD:n_reed * 55317
brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp: need to unitize
direction vector before scaling by absolute distance to
intersection |
18:09.05 |
*** join/#brlcad kesha__
(~kesha@49.249.18.107) |
18:19.45 |
*** join/#brlcad kesha__
(~kesha@49.249.18.107) |
18:37.26 |
brlcad |
kesha__: what does that error say to
you? |
18:43.51 |
*** join/#brlcad kesha__
(~kesha@49.249.18.107) |
18:50.19 |
*** join/#brlcad jasleen
(~jasleen@202.164.53.122) |
18:52.13 |
*** join/#brlcad jasleen_
(~chatzilla@117.253.233.182) |
19:00.49 |
brlcad |
kesha__: basically, you can't just move files
around and expect it to work ;) |
19:01.14 |
brlcad |
non-ors.cc is calling some functions (the ones
listed) .. those functions do not exist in clstepcore |
19:01.28 |
brlcad |
they did exist in fedex_plus (which is
probably why that file was in that directory) |
19:02.34 |
brlcad |
so you'd presumably have to figure out what to
do, whether it's possible to untangle the calls, replace them, move
them, delete them, or otherwise refactor them into
clstepcore |
19:07.00 |
*** join/#brlcad caen23
(~caen23@92.81.182.136) |
19:11.07 |
caen23 |
i have svn 1.7.9 and just tried to run an `svn
up`, but it told me to run `svn upgrade` first. is the svn on the
server older? |
19:18.13 |
Notify |
03BRL-CAD:n_reed * 55318
brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp: oversimplified
a bit in r55303, s near zero should become 2pi |
19:42.47 |
*** join/#brlcad mpictor
(~mark@99-93-104-202.lightspeed.iplsin.sbcglobal.net) |
19:50.19 |
``Erik |
caen23: probably means you've upgraded your
install of svn since the last time you did an update... the server
is running whatever sourceforge decides to run |
20:01.33 |
Notify |
03BRL-CAD:n_reed * 55319
brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp: swapping
parameters changes traversal direction, don't do it |
20:41.15 |
*** join/#brlcad cstirk
(~quassel@c-71-56-216-45.hsd1.co.comcast.net) |
20:58.53 |
*** join/#brlcad caen23_
(~caen23@92.81.223.225) |
21:00.51 |
zero_level |
brlcad: i got pix files in the pix folder..
looking for .bw files can u point me to some src |
21:27.31 |
``Erik |
could always do pix-bw to generate
one |
21:28.19 |
zero_level |
oh yes.. |
21:28.26 |
zero_level |
thanks.. |
21:28.59 |
zero_level |
actually i just figured it out.. |
21:31.14 |
zero_level |
``Erik: in the design of icv at present we use
fd in the image struct |
21:31.23 |
zero_level |
what is the use of thisn? |
21:33.18 |
``Erik |
it's the handle to the file that backs the
image |
21:34.32 |
zero_level |
but do we need this when we have already read
the file ? |
21:35.45 |
``Erik |
a big part of icv was to provide a way for
programs like rt to write to arbitrary file formats, like png or
jpg |
21:38.01 |
zero_level |
ok... and fd backs the primitive format like
bw and pix ? |
21:38.43 |
``Erik |
so when the icv is created, the fd is attached
to the file (to verify it can write before spending cpu raytracing)
, then buffers as much as needed and writes when it can |
21:38.59 |
``Erik |
so with a pix or bw, it's almost immediately
writing, but a png has to buffer up the image to run the
compression algorithms |
21:47.31 |
zero_level |
is jpg also important format because i didnt
find that in icv formats and indeed didnt incluse in my
proposal |
22:05.40 |
``Erik |
no, not yet, just one that would require
collecting all the pixels before generating the image
*shrug* |
22:05.58 |
zero_level |
``Erik: i meant important for brlcad
applications since it is lossy |
22:06.01 |
``Erik |
png is probably the gold standard: pixel
perfect and highly compressed |
22:06.09 |
zero_level |
ok. |
22:06.22 |
``Erik |
there was discussion about integrating the EXR
format using the open source library |
22:06.39 |
``Erik |
http://en.wikipedia.org/wiki/OpenEXR |
22:07.39 |
``Erik |
that'd involve changing the icv internal
representation, but that's a "private" data glob, so it's
ok |
22:23.40 |
zero_level |
k i will find the details of
implmentation. |
22:35.26 |
``Erik |
the proposals have not been reviewed and none
have been accepted yet, so there is no guarantee that you'll be
awarded this task or that it will remain exactly the same... if
you're looking for some related trivial task to submit as a patch,
I'd imagine something very simple like modifying pix-bw to use the
icv read/write functions? |
22:48.48 |
zero_level |
i have already submitted a patch for reading
png pix and bw file... |
22:49.26 |
zero_level |
currently i am trying to remove the bug in
guess_fike_format |
22:49.42 |
zero_level |
and then using this to load. |
22:50.48 |
zero_level |
``Erick did u implement the current form of
icv? |
22:51.33 |
zero_level |
``Erik sry for typo.. |
22:55.24 |
``Erik |
zero_level: mostly, others have provided
changes as well... it began as bu_image |
22:58.45 |
zero_level |
actually i inferred from the chats and the
comments in the code... they were very much in sync |
23:57.49 |
*** join/#brlcad caen23_
(~caen23@92.81.219.150) |