00:00.12 |
Notify |
03BRL-CAD:starseeker * 61561
(brlcad/branches/openscenegraph/BUGS
brlcad/branches/openscenegraph/CMakeLists.txt and 30 others): Sync
through trunk r61560 |
00:00.32 |
Notify |
03BRL-CAD:starseeker * 61562
(brlcad/branches/gecode/BUGS brlcad/branches/gecode/CMakeLists.txt
and 29 others): Sync through trunk r61560 |
00:00.51 |
Notify |
03BRL-CAD:starseeker * 61563
(brlcad/branches/bullet/BUGS brlcad/branches/bullet/CMakeLists.txt
and 29 others): Sync through trunk r61560 |
00:29.56 |
Notify |
03BRL-CAD:starseeker * 61564
brlcad/branches/openscenegraph/include/ged.h: Start thinking about
what a new display list structure is going to look like. |
00:31.32 |
starseeker |
brlcad: with autoview, should it actually
calculate view bounds or just add an event for the displays to size
themselves to show all objects? |
00:32.22 |
starseeker |
it appears to be using solid wireframes to
calculate the view size currently... if it stays in libged I'd
prefer to have it actually ask for bounding boxes, if that's not
prohibitively slow |
00:36.19 |
starseeker |
brlcad: can we add a deprectation notice for
all code that interacts with v4 databases that is not involved with
dbupgrading them to v5? |
00:38.17 |
starseeker |
concedes that it may be
necessary for unpacking the data to retain a fair bit of that code,
but I'd much rather it live in dbupgrade and maybe
src/librt/db_v4_read.c than places like
src/libged/color.c... |
00:42.28 |
starseeker |
makes a note to add an audit
of the state of librt's bounding box routines to some student task
list... |
00:43.47 |
starseeker |
if any primitives still require the "plot it
and bound the plot" fudgery, it should be in their bbox callback
and not the responsibility of libged's draw.c... |
00:50.24 |
starseeker |
hmm... do we want libged's commands to be able
to specify the mode of viewing? (wireframe vs shaded vs
hidden_line vs...?) |
00:50.57 |
starseeker |
might be worth an enum, if we could be
reasonably comprehensive... |
01:08.36 |
Notify |
03BRL-CAD:starseeker * 61565
brlcad/branches/openscenegraph/include/ged.h: More thinking on
'what information do we need for display list entries to have all
the information a display will need?' |
02:01.27 |
*** join/#brlcad infobot
(~infobot@rikers.org) |
02:01.27 |
*** topic/#brlcad is BRL-CAD
|| http://brlcad.org || logs:
http://ibot.rikers.org/%23brlcad/
|| GCI winners: Jacob Burroughs and Peter Amidon! || GSoC 2014
selections are announced! Thank you to all we got to work with.
Remember that SOCIS is coming up right around the corner and you
don't need a summer of code to get involved with open
source. |
02:05.46 |
*** join/#brlcad infobot
(~infobot@rikers.org) |
02:05.46 |
*** topic/#brlcad is BRL-CAD
|| http://brlcad.org || logs:
http://ibot.rikers.org/%23brlcad/
|| GCI winners: Jacob Burroughs and Peter Amidon! || GSoC 2014
selections are announced! Thank you to all we got to work with.
Remember that SOCIS is coming up right around the corner and you
don't need a summer of code to get involved with open
source. |
03:38.00 |
brlcad |
starseeker: excellent questions...
oof! |
03:42.43 |
brlcad |
for autoview, there's actually substantial
logic -- a method -- to setting up a particular view, so it's guts
can/should be in libged |
03:43.12 |
brlcad |
note though that it should also generate a
"view changed" event if/when it changes the view |
03:43.44 |
brlcad |
the app gets to decide what to do with that
event and the view specified |
04:10.36 |
brlcad |
no opinion on bbox vs wireframe ... aabb's and
even obb's are going to create views more padded than they are now
-- the wireframe points are basically a poorman convex hull. oob
would probably be okay; a real convex hull would probably be best
(perhaps off the brep edges). I agree that using plot data
(especially if LoD is in play) isn't desirable going
forward. |
04:13.00 |
brlcad |
yes to the deprecation notice, but I think we
should do the actual incremental removal on the rel8
branch |
04:18.50 |
brlcad |
the last one is tricky but my initial
inclination is "no" in part to keep it simple, but also because
that really gets into how data is presented, which is the apps (and
libdm's) job |
04:29.35 |
brlcad |
from libged's perspective, I'm not even sure
it needs to know what representation data to provide other than
commands that specialize in returning a particular type of data
(e.g., 'ls' returns objects in text form, 'get' in tcl text form,
maybe 'facetize' in mesh form and 'brep' in nurbs form) |
04:30.50 |
brlcad |
and for that, the first two generalize to a
text blob result, and the latter two can be viewed as creating an
object and generating OBJECT_ADDED events |
04:31.43 |
brlcad |
keepin it simple is good |
05:39.15 |
*** join/#brlcad albertcoder
(~albertcod@202.164.53.117) |
06:46.03 |
*** join/#brlcad teepee
(~teepee@gateway/tor-sasl/teepee) |
07:14.41 |
*** join/#brlcad Zhao_Anqing
(~clouddrif@183.157.160.13) |
07:34.11 |
*** join/#brlcad albertcoder
(~albertcod@101.215.119.112) |
07:36.56 |
*** join/#brlcad d_rossberg
(~rossberg@66-118-151-70.static.sagonet.net) |
08:19.26 |
*** join/#brlcad oana_
(~elf11@p5.eregie.pub.ro) |
08:20.35 |
*** join/#brlcad pandrei
(~pandrei@188.25.173.120) |
08:39.09 |
pandrei |
Daniel: I've been looking at mode
method |
08:39.13 |
pandrei |
you ve told me to investigate |
08:39.39 |
pandrei |
and the mode unsigned char struct
field |
08:40.26 |
pandrei |
and it's pretty obvious that it sets the bot's
type, like RT_BOT_SURFACE, RT_BOT_SOLID, RT_BOT_PLATE and
RT_BOT_PLATE_NOCOS |
08:45.40 |
d_rossberg |
fine, then the interface should have a
self-explaining/self-consistent method for setting this
mode |
08:45.46 |
d_rossberg |
maybe with an enum? |
08:47.00 |
pandrei |
hmm |
08:47.49 |
pandrei |
I'm not sure if I get your point, enum like
{surface, solid, plate, nocos} ? |
08:48.38 |
*** join/#brlcad teepee-
(bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
08:52.32 |
d_rossberg |
yes, or do you have another idea? |
08:59.13 |
pandrei |
hm, not really, but I'm a bit confused of an
aspect |
08:59.19 |
pandrei |
enum values are actually integer |
09:00.13 |
pandrei |
ah, no, no, it makes sense now |
09:00.16 |
pandrei |
apparently RT_BOT_SURFACE is 1 |
09:03.26 |
d_rossberg |
the values are still saved as chars in the
_internal structure |
09:04.12 |
d_rossberg |
and you should explicitely cast them, e.g.
"case surface: value = RT_BOT_SURFACE" |
09:05.06 |
d_rossberg |
don't trust in the actual order as somebody
could change it |
09:06.34 |
pandrei |
ah, that's good to know |
09:08.15 |
pandrei |
but the cast should be done in the
implementation, right? |
09:08.41 |
d_rossberg |
right :) |
09:10.34 |
pandrei |
since you're already here, aside of mode, was
there any issue I should address before resubmitting the
interface? |
09:10.51 |
pandrei |
I've removed Face class and moved Thickness
and Normal methods into Triangle |
09:38.22 |
*** join/#brlcad teepee
(~teepee@gateway/tor-sasl/teepee) |
09:49.58 |
Notify |
03BRL-CAD Wiki:130.216.215.253 * 7452
/wiki/Talk:Google_Summer_of_Code: AP242 P21 file |
09:52.05 |
*** join/#brlcad Zhao_Anqing
(~clouddrif@183.157.160.7) |
10:04.28 |
*** join/#brlcad teepee-
(bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
10:20.45 |
d_rossberg |
pandrei: orientation and flags? |
10:26.01 |
Notify |
03BRL-CAD Wiki:Ankeshanand * 7453
/wiki/User:Ankeshanand/GSoC14/logs: /* Week 7 */ |
10:48.51 |
*** join/#brlcad FreezingCold
(~FreezingC@135.0.41.14) |
11:27.16 |
starseeker |
brlcad: the trick with returning "text blobs"
though is the dm needs some context to know how to interpret the
result - vlists could be a wireframe or they could be instructions
for polygons, and unless that gets encoded directly into the vlist
serialization (which I guess might be the right way) we'll need
some sort of notion of data type |
11:29.12 |
starseeker |
braces himself for a rel8
branch sync... that's been a while... |
11:29.38 |
starseeker |
how do we word the deprecation notice for that
one? |
11:31.50 |
starseeker |
hmm... unless we carry the plot around in the
display list object, we'll need to have autoview calculate all the
plots from the display list on the fly - that'll probably slow
autoview down a lot |
11:32.47 |
*** join/#brlcad teepee-
(bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
11:35.03 |
starseeker |
grumble... I guess we might have to carry
around that info, since a lot of the commands seem to directly use
it in their operations... |
11:35.31 |
starseeker |
can't do a proper brep edge approach until the
booleans are in shape |
11:36.21 |
starseeker |
and even then it might not be fast
enough |
11:39.34 |
pandrei |
daniel: what do you mean with orientation and
flags? Should orientation be bool ? |
11:40.46 |
d_rossberg |
what are the possible values for the
orientation? |
11:41.47 |
pandrei |
well if I look in rtgeom.h |
11:42.04 |
pandrei |
@brief 0 -> ccw, !0 -> cw |
11:42.10 |
pandrei |
so I figured bool will do |
11:43.24 |
pandrei |
as for flags, I don't fully understand why
it's & between the flags var |
11:43.46 |
d_rossberg |
??? are we looking at the same file? see lines
679 to 681 in rtgeom.h |
11:44.22 |
pandrei |
ah |
11:44.29 |
pandrei |
now I figured the confusion |
11:44.40 |
pandrei |
I was looking in
/usr/brlcad/dev/include/rtgeom.h |
11:44.42 |
pandrei |
which is the old one |
11:44.52 |
pandrei |
not in brlcad updated sources |
11:44.55 |
pandrei |
yeah, it makes sense |
11:45.06 |
pandrei |
ignore my last patch on sourceforge until I
edit it |
11:45.55 |
d_rossberg |
for the flags: i see 3 possible flags, each
one is a bool |
11:46.13 |
pandrei |
ok, so the flags are "split" like
that |
11:46.29 |
pandrei |
I would make the orientation in two
bools |
11:46.49 |
pandrei |
one for cw and one for unoriented, or should
I make an enum as well? |
11:49.11 |
d_rossberg |
i'm in favor for an additional enum |
11:49.53 |
d_rossberg |
btw, if you look at the flags you'll see tha
each one sets/unsets a bit |
12:25.48 |
pandrei |
I've noticed that |
12:26.26 |
pandrei |
but I was wondering why that method was
chosen, instead of some values(i.e 1, 2, 3) |
12:39.09 |
d_rossberg |
these bits are boolean flags, you can
set/reset/test for this flags with masks and bitwise boolean
operations (|, &, ...) |
12:39.41 |
d_rossberg |
|| =! | |
12:40.42 |
d_rossberg |
äh || != | |
12:42.01 |
pandrei |
yeah |
12:42.14 |
pandrei |
I've edited the interface submitted on
sourceforge |
13:23.20 |
starseeker |
winces - last rel8 sync was
Dec. 31st, 2010 |
13:23.23 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
13:23.46 |
starseeker |
almost 20000 commits ago |
13:24.04 |
starseeker |
sets up the merge command and
grabs popcorn |
13:28.46 |
*** join/#brlcad FreezingCold
(~FreezingC@135.0.41.14) |
14:08.38 |
*** join/#brlcad piyushparkash
(~piyushpar@59.91.255.141) |
15:08.47 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
15:11.39 |
brlcad |
starseeker: you should tell it to merge
everything so it has the proper mergeinfo set |
15:11.56 |
brlcad |
I think that branch was started when svn
wasn't doing so hot with merge tracking |
15:13.49 |
brlcad |
d_rossberg: did you have an algorithm in mind
for turning mesh/point data into pipe lines? |
15:16.38 |
brlcad |
starseeker: seems wrong to me on the surface
for libged to return vlists data as that is arguably presentation
of data (and as I mentioned, we don't have commands that I can
think of that directly needs to know about that data) |
15:17.48 |
brlcad |
so like the draw command, it wouldn't ask
librt for plot vlist data and return it -- it would simply return
the list of objects/paths to be drawn and create "draw me"
events |
15:18.19 |
brlcad |
the app would figure out that it's in
wireframe mode or whatever mode and ask libdm or librt to do some
work |
15:19.14 |
brlcad |
starseeker: as for deprecation notice, I think
that every place there's support that is user-exposed, it should
probably be itemized in CHANGES .. |
15:19.47 |
brlcad |
otherwise it's going to be a very broad
statement... which would also be fine, but less trackable
:) |
15:20.09 |
d_rossberg |
brlcad: i think no, but i'm not sure what you
mean |
15:21.13 |
brlcad |
d_rossberg: I think it was you? maybe it was
Tom? .. there's a gsoc project idea to convert mesh wires (e.g.,
imported from Pro/E or other systems) into pipe solids |
15:22.15 |
brlcad |
http://brlcad.org/wiki/Convert_BoT_to_Pipe |
15:23.03 |
brlcad |
never mind, that IP address looks like it was
probably Tom :) |
15:25.06 |
d_rossberg |
ok, found it:
https://google-melange.appspot.com/gsoc/proposal/review/org/google/gsoc2014/foposseleger/5629499534213120 |
15:25.25 |
d_rossberg |
and it wasn't me ;) |
15:28.23 |
brlcad |
okay thanks .. let me know if you think of a
great algorithm for it ;) |
15:30.59 |
Notify |
03BRL-CAD:carlmoore * 61566
brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: remove
trailing blanks/tabs; misc/tools stuff is now automatically removed
from such listing |
15:44.32 |
*** join/#brlcad clock
(~clock@77-58-143-135.dclient.hispeed.ch) |
15:45.06 |
*** join/#brlcad teepee
(~teepee@gateway/tor-sasl/teepee) |
15:46.19 |
n_reed |
starseeker, brlcad: wrt to autoview, halfspace
comes to mind as the thing whose bbox (if you say it has one)
doesn't tell you how to size the view for its plot |
15:48.24 |
n_reed |
I've also noticed autoview doesn't work well
in a perspective projection (at least in Archer) |
15:58.01 |
*** join/#brlcad albertcoder
(~albertcod@202.164.53.117) |
16:37.21 |
*** join/#brlcad albertcoder
(~albertcod@202.164.53.117) |
16:43.29 |
Notify |
03BRL-CAD:n_reed * 61567
brlcad/branches/brep-debug/src/libbrep/boolean.cpp: move duplicate
code to function, renaming vars and adding comments |
16:53.23 |
Notify |
03BRL-CAD:starseeker * 61568
(brlcad/branches/rel8/include/analyze.h
brlcad/branches/rel8/include/anim.h and 55 others): Sync rel8 with
trunk through r61565 - part 1 |
17:01.32 |
Notify |
03BRL-CAD:starseeker * 61569
(brlcad/branches/rel8/misc/win32-msvc/CMakeLists.txt
brlcad/branches/rel8/misc/win32-msvc/Dll/BrlcadCore.def and 5
others): Sync rel8 with trunk through r61565 - part 2 |
17:12.15 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
17:45.32 |
Notify |
03BRL-CAD:indianlarry * 61572
brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: Fix the
brlcad_config.h.in logic |
17:47.00 |
*** join/#brlcad albertcoder
(~albertcod@101.208.22.91) |
17:56.08 |
Notify |
03BRL-CAD:carlmoore * 61573
brlcad/trunk/doc/docbook/system/man1/en/pix-ps.xml: add -l info,
remove -h info, and add commas |
18:04.34 |
Notify |
03BRL-CAD:n_reed * 61574
brlcad/trunk/src/conv/3dm/conv3dm-g.cpp: need limits for
std::numeric_limits |
18:10.15 |
Notify |
03BRL-CAD:ejno * 61575
brlcad/trunk/src/conv/3dm/conv3dm-g.cpp: cleanups; use int for
loops |
18:11.24 |
*** join/#brlcad clock
(~clock@77-58-143-135.dclient.hispeed.ch) |
18:12.07 |
Notify |
03BRL-CAD:n_reed * 61576
(brlcad/branches/brep-debug/BUGS
brlcad/branches/brep-debug/CMakeLists.txt and 24 others): sync from
trunk through r61575 |
18:19.05 |
Notify |
03BRL-CAD:ejno * 61577
brlcad/trunk/src/conv/3dm/conv3dm-g.cpp: add comments |
18:31.52 |
Notify |
03BRL-CAD:ejno * 61578
brlcad/trunk/src/conv/3dm/conv3dm-g.cpp: cleanups |
18:46.50 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
18:52.23 |
*** join/#brlcad piyushparkash
(~piyushpar@59.91.255.141) |
19:02.01 |
*** join/#brlcad clock
(~clock@77-58-143-135.dclient.hispeed.ch) |
19:09.57 |
*** join/#brlcad albertcoder
(~albertcod@101.215.123.48) |
19:12.28 |
Notify |
03BRL-CAD:starseeker * 61580
brlcad/branches/openscenegraph/include/ged.h: Rather than get into
libged at all, is there enough information in the various GED
structures to map information to a new libdm structure? Test that
first, because libged refactoring needs a lot of design
thought. |
19:12.35 |
Notify |
03BRL-CAD:starseeker * 61579
(brlcad/branches/rel8/misc/NIST_DENSITIES
brlcad/branches/rel8/misc/archlinux/PKGBUILD and 16 others): Sync
rel8 with trunk through r61565 - part 4 |
19:14.30 |
starseeker |
brlcad: so (for example) with rtcheck's
overlap visualization, how do you envision returning that from
libged to libdm? |
19:18.51 |
*** join/#brlcad Izakee
(~Isaac@195.24.220.134) |
19:19.06 |
starseeker |
votes that g5-g4 and g4-g5 go
away - any functionality they offer can be functions/options in
dbupgrade |
19:20.11 |
Notify |
03BRL-CAD:starseeker * 61581
(brlcad/branches/rel8/doc/BRL-CAD.bib
brlcad/branches/rel8/doc/PROJECTS and 392 others): Sync rel8 with
trunk through r61565 - part 5 |
19:33.24 |
Notify |
03BRL-CAD:ejno * 61582
brlcad/trunk/src/conv/3dm/conv3dm-g.cpp: check for and ignore
meshes with zero vertices or faces |
19:55.20 |
*** join/#brlcad jasleen
(~jasleen@117.255.245.124) |
20:10.44 |
Notify |
03BRL-CAD:starseeker * 61583
(brlcad/branches/rel8/src/other/boost/LICENSE_1_0.txt
===================================================================
and 26 others): Sync rel8 with trunk through r61565 - part
6 |
20:15.29 |
Notify |
03BRL-CAD:brlcad * 61584
brlcad/trunk/src/rt/viewweight.c: Account for the hypersample rays
in the volume calculation so that the volume and mass calculations
are correct |
20:16.32 |
*** join/#brlcad albertcoder
(~albertcod@202.164.53.117) |
20:18.23 |
Notify |
03BRL-CAD:brlcad * 61585 brlcad/trunk/BUGS:
rtweight is fixed |
20:19.46 |
Notify |
03BRL-CAD:brlcad * 61586 brlcad/trunk/AUTHORS:
rishub helped fix the aforementioned commit that fixed rtweight
hypersampling |
20:37.09 |
*** join/#brlcad albertcoder
(~albertcod@202.164.53.117) |
20:44.49 |
*** join/#brlcad javampire
(~ncsaba@p4FF714BF.dip0.t-ipconnect.de) |
20:45.53 |
javampire |
brlcad: I just read your discussion with
starseeker about libged/libdm entanglements related to the view
concept which both need |
20:46.44 |
javampire |
starseeker: did you consider to extract the
part which both of those need in a extra library which is used by
both libdm and libged ? |
20:48.14 |
javampire |
just write something like a "libview" and make
them both use it |
20:48.39 |
javampire |
not sure if that makes sense, just my
2c |
20:49.43 |
Notify |
03BRL-CAD Wiki:Albertcoder * 7454
/wiki/User:Albertcoder/GSoC2014/logs: /* Week 7 */ |
20:49.47 |
javampire |
(I will leave now IRC, but will read up on the
logs later) |
21:06.20 |
ankesh11 |
Screenshot of the results view I have been
working on: http://i.imgur.com/HN3fc97.png |
21:06.46 |
ankesh11 |
brlcad: hsrai: Feedback? |
21:32.53 |
starseeker |
yeah, bot raytracing is totally broken - even
a sphere facetization fails |
21:40.54 |
Notify |
03BRL-CAD:starseeker * 61587
(brlcad/branches/rel8/src/other/URToolkit/Makefile.am
brlcad/branches/rel8/src/other/URToolkit/cnv/Makefile.am and 677
others): Sync rel8 with trunk through r61565 - part 7 |
21:47.03 |
Notify |
03BRL-CAD:starseeker * 61588
(brlcad/branches/openscenegraph/AUTHORS
brlcad/branches/openscenegraph/BUGS and 9 others): Sync through
trunk r61587 |
21:47.17 |
Notify |
03BRL-CAD:starseeker * 61589
(brlcad/branches/gecode/AUTHORS brlcad/branches/gecode/BUGS and 9
others): Sync through trunk r61587 |
21:47.28 |
Notify |
03BRL-CAD:starseeker * 61590
(brlcad/branches/bullet/AUTHORS brlcad/branches/bullet/BUGS and 9
others): Sync through trunk r61587 |
21:53.46 |
starseeker |
ponders the advisability of a
script to run that syncs trunk to all the branches (or at least,
the subset of them for which that makes sense...) |
21:54.58 |
*** join/#brlcad ``Erik_
(~erik@pool-74-103-94-19.bltmmd.fios.verizon.net) |
22:12.23 |
starseeker |
61337 is where the problem appeared |
22:12.30 |
starseeker |
(bot raytracing) |
22:17.05 |
*** join/#brlcad clock
(~clock@77-58-143-135.dclient.hispeed.ch) |
22:17.31 |
Notify |
03BRL-CAD Wiki:Ankeshanand * 0
/wiki/File:ResultsInterface.png: |
22:18.24 |
Notify |
03BRL-CAD Wiki:Ankeshanand * 7456
/wiki/User:Ankeshanand/GSoC14/logs: /* Week 7 */ |
22:38.47 |
Notify |
03BRL-CAD:starseeker * 61591
(brlcad/branches/rel8/AUTHORS brlcad/branches/rel8/BUGS and 1791
others): Sync rel8 with trunk through r61565 - part 8 |
22:44.34 |
starseeker |
the problem (locally, at least, is line 73 of
g_bot_include.c - m4 >= tol->para is failing for all
points. |
22:46.38 |
starseeker |
arrgh - the failur in trunk is different from
the failure at 61337 |
22:47.34 |
starseeker |
n_reed: well, I guess that explains why you
weren't seeing the failure - it's not the 61337 problem, that must
have been fixed |
22:48.16 |
Notify |
03BRL-CAD:starseeker * 61592
(brlcad/branches/rel8/AUTHORS brlcad/branches/rel8/BUGS and 9
others): Sync rel8 with trunk through r61591 |
22:50.02 |
starseeker |
weird |
22:50.08 |
starseeker |
alright, later for this |
23:15.23 |
*** join/#brlcad archivist
(~archivist@host81-149-189-98.in-addr.btopenworld.com) |
23:15.40 |
*** join/#brlcad teepee
(~teepee@gateway/tor-sasl/teepee) |