00:38.35 |
*** join/#brlcad infobot
(~infobot@rikers.org) |
00:38.35 |
*** topic/#brlcad is BRL-CAD
|| http://brlcad.org || logs:
http://ibot.rikers.org/%23brlcad/
|| GCI winners: Jacob Burroughs and Peter Amidon! || GSoC 2014 is
under way, student selections announced soon! |
01:52.05 |
*** join/#brlcad Zhao_Anqing
(~clouddrif@2001:da8:e000:1a08:c563:f00f:d61e:36a) |
01:53.21 |
Zhao_Anqing |
hi, I have some questions about NMG
functions. |
01:53.36 |
Zhao_Anqing |
It seems most of them just deal with the first
region of model |
01:53.46 |
Zhao_Anqing |
and the first shell of region. |
01:56.12 |
Zhao_Anqing |
for example the use of 'nmg_bot' |
01:57.49 |
Zhao_Anqing |
Is it something specical for such usage. I
means, don't act on all region and shell. |
02:18.10 |
*** join/#brlcad teepee
(~teepee@gateway/tor-sasl/teepee) |
03:09.43 |
*** join/#brlcad teepee
(~teepee@gateway/tor-sasl/teepee) |
06:07.32 |
*** join/#brlcad pandrei
(~pandrei@188.25.172.88) |
06:24.48 |
*** join/#brlcad kesha
(~kesha@14.139.122.114) |
06:29.00 |
*** join/#brlcad gaganjyot
(~gagan@27.255.252.57) |
06:30.39 |
pandrei |
if I have a patch that's build of several
patches, is it ok to keep them in the same 'ticket'? |
06:31.09 |
pandrei |
I ll add _#number to list tthe according
order |
06:37.26 |
*** join/#brlcad kesha
(~kesha@14.139.122.114) |
07:25.37 |
*** join/#brlcad hoiji
(671b082c@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.44) |
07:32.55 |
*** join/#brlcad gaganjyot__
(~gagan@27.255.252.57) |
07:53.51 |
*** join/#brlcad hcurtis
(4af13a6e@gateway/web/freenode/ip.74.241.58.110) |
07:58.35 |
*** join/#brlcad richa
(uid11933@gateway/web/irccloud.com/x-uvblqucunyipmpbu) |
08:23.04 |
*** join/#brlcad Anaphaxeton
(~george@unaffiliated/anaphaxeton) |
08:39.00 |
*** join/#brlcad merzo
(~merzo@user-94-45-58-138-1.skif.com.ua) |
08:47.38 |
*** join/#brlcad d_rossberg
(~rossberg@66-118-151-70.static.sagonet.net) |
09:12.54 |
*** join/#brlcad teepee_
(bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
09:42.20 |
*** join/#brlcad gaganjyot__
(~gagan@27.255.252.57) |
09:42.59 |
*** join/#brlcad pandrei
(~IceChat77@188.25.172.88) |
09:43.03 |
pandrei |
Hello |
09:43.21 |
pandrei |
Daniel, I've seen the comments on sourceforge
and I'm a bit confused |
09:44.03 |
pandrei |
you mentioned that I should implement tgc, tgc
is "Cone". I haven't taken a thorough look in it but it seems to be
implemented |
09:44.27 |
pandrei |
What you guys are saying is that I only have
to add the special constructor(rcc) inside tgc(Cone). That's what I
understood from the comments |
09:58.44 |
*** join/#brlcad Zhao_Anqing
(~clouddrif@2001:da8:e000:1a08:c563:f00f:d61e:36a) |
10:50.16 |
*** join/#brlcad kesha
(~kesha@14.139.122.114) |
11:16.26 |
*** join/#brlcad merzo
(~merzo@user-94-45-58-138-1.skif.com.ua) |
11:16.46 |
*** join/#brlcad Anaphaxeton
(~george@unaffiliated/anaphaxeton) |
11:28.12 |
d_rossberg |
pandrei: sorry, i forgot that Cone was in fact
the tgc |
11:28.53 |
d_rossberg |
and if you look at the constructors there (in
Cone.h) what do you see there? |
12:18.27 |
*** join/#brlcad teepee
(~teepee@gateway/tor-sasl/teepee) |
12:27.31 |
*** join/#brlcad ries
(~ries@190.9.171.121) |
12:34.41 |
*** join/#brlcad merzo
(~merzo@user-94-45-58-138-1.skif.com.ua) |
12:37.57 |
*** join/#brlcad gaganjyot__
(~gagan@27.255.252.57) |
12:59.27 |
*** join/#brlcad FreezingCold
(~FreezingC@135.0.41.14) |
13:08.53 |
ries |
teepee: ping |
13:11.48 |
teepee_ |
o/ |
13:14.56 |
teepee_ |
ries: . |
13:15.29 |
ries |
teepee_: if I remember correctly, you have
been discussing DXF import/export, right? |
13:15.58 |
teepee_ |
ries: yup |
13:16.16 |
ries |
teepee_: are there any MIT licensed DXF
libraries? |
13:16.21 |
teepee_ |
the implementation in openscad is not exactly
perfect |
13:17.14 |
teepee_ |
hmm, not really at this time I think. not as
library for simple reuse |
13:19.09 |
ries |
I have no idea how hard/easy it is to write a
DXF parser |
13:20.10 |
teepee_ |
i guess it's an annoyingly amount of work but
likely not the hardest thing as file formats go |
13:23.08 |
ries |
…and the version differences.. |
13:37.36 |
teepee_ |
ries: hmm, right, that might make it a bit
more complex |
13:48.30 |
*** join/#brlcad hcurtis
(4af13a6e@gateway/web/freenode/ip.74.241.58.110) |
13:49.31 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
14:00.06 |
*** join/#brlcad javampire
(~ncsaba@remote-munich.teradata.com) |
14:18.44 |
Notify |
03BRL-CAD:starseeker * 60411
brlcad/branches/openscenegraph/src/libfb/if_osg.cpp: Not working
properly yet, but get raytracing data into texture memory a show in
view. |
14:30.47 |
*** join/#brlcad kesha
(~kesha@14.139.122.114) |
14:44.29 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
14:52.44 |
Notify |
03BRL-CAD:starseeker * 60412
brlcad/branches/openscenegraph/src/libfb/if_osg.cpp: Can see image
now, but no incremental update. |
14:55.37 |
kanzure |
brlcad: i've been ill for the past week, but i
notice you've mentioned a deadline for something in an email to me.
should i be doing something? |
14:56.37 |
kanzure |
oh it looks like we ran out of candidates
anyway |
14:56.39 |
kanzure |
nevermind then |
15:03.17 |
starseeker |
ries, teepee_ : what about https://bitbucket.org/Coin3D/dime
? |
15:04.53 |
teepee_ |
starseeker: hmm, that's not very active
lately, but kintel might know more :) |
15:05.43 |
kintel |
starseeker: It's not maintained, but BSD
licensed |
15:08.53 |
teepee_ |
so there's 2 GPL libs, on non-maintained BSD
and the brl-cad code that might be moved to a library in the
future |
15:10.27 |
*** join/#brlcad kesha
(~kesha@14.139.122.114) |
15:10.28 |
Notify |
03BRL-CAD:starseeker * 60413
brlcad/branches/openscenegraph/src/libfb/if_osg.cpp: Doesn't
update, but there's a performance penalty to pay. Will try
switching back to osg and see if triangle-based solution works with
an osgViewer... |
15:12.16 |
starseeker |
kintel: right - my thinking was since it's set
up as a library already, it might be worth forking as a starting
point on which to improve |
15:12.31 |
starseeker |
also, as BSD licensed code, it's the most
liberal of the options |
15:12.57 |
kintel |
starseeker: It's a bit dated, but should be
solid. I've had production code running on it for years |
15:13.18 |
starseeker |
I'd started working on a CMake build for it as
part of psketcher, so I can finish that up and take it for a
spin |
15:14.19 |
teepee_ |
cool, i guess it would be a good idea to use
the same library if we switch anyway |
15:14.42 |
*** join/#brlcad teepee
(~teepee@gateway/tor-sasl/teepee) |
15:14.58 |
starseeker |
let's put it this way - what would y'all like
to see from dime that would make it the "preferred"
choice? |
15:15.18 |
starseeker |
personally thinks a BSD
licensed lib everyone can use would be the best long term
solution... |
15:15.56 |
teepee_ |
hmm, OpenSCAD would need DXF import /
export |
15:16.09 |
starseeker |
I think dime does both? |
15:16.43 |
teepee_ |
according to the readme it can do
both |
15:17.12 |
teepee_ |
regarding API is not much needed i
think |
15:17.36 |
starseeker |
you mean for I/O? yeah, should be fairly
straightforward |
15:17.37 |
teepee_ |
some basic data model that provides the raw
data is probably best |
15:17.39 |
pandrei |
guys, how can I checkout svn branch rt^3 on
windows |
15:17.50 |
pandrei |
when I'm trying to do that on console it
somehow converts rt^3 to rt3 |
15:18.13 |
teepee_ |
oh ^ is a special character on windows command
line |
15:18.18 |
starseeker |
http://tortoisesvn.net/ might
help |
15:18.20 |
pandrei |
yes |
15:18.33 |
teepee_ |
try ^^ |
15:19.03 |
starseeker |
teepee_: my thought was to dust off dime, see
what it's like, and if it's worth building on set it up as a
stand-alone project |
15:19.19 |
pandrei |
feels so uncomfortable doing anything on
windows |
15:19.38 |
starseeker |
kintel having used it in production is a
definite point in its favor |
15:19.56 |
teepee_ |
starseeker: sounds good, that would match
kintel's plan to maybe move OpenSCAD to some other license. right
now GPL would not be an issue |
15:20.20 |
starseeker |
not for OpenSCAD, but it would preclude
BRL-CAD using it :-/ |
15:20.57 |
starseeker |
which is OK, but misses possibilities for
mutually advantageous development |
15:21.17 |
*** join/#brlcad drv_
(~smuxi@dynamic-78-8-240-121.ssp.dialog.net.pl) |
15:21.27 |
starseeker |
if I can I'll finish up the CMake build for it
tonight and see what's there |
15:22.46 |
drv_ |
hi, is there everything ok with brlcad.org
site? |
15:23.52 |
drv_ |
I can't open it... I've tried also from my
phone, but it also doesn't work. |
15:24.01 |
teepee_ |
starseeker: yeah, I know. we do need some
other code as the current implementation does not support all
primitives |
15:29.53 |
*** join/#brlcad gaganjyot__
(~gagan@27.255.252.57) |
15:34.50 |
pandrei |
d_rossberg: in cone.h the implicit constructor
seems like the one similar to rcc |
15:34.56 |
pandrei |
base, height and radius |
15:35.55 |
pandrei |
but shouldn't the rcc one have some additional
constraints? |
15:36.56 |
pandrei |
from what I see, the set for rcc is
implemented, I'm a bit confused. |
15:55.30 |
d_rossberg |
pandrei: see src/libwdb/wdb.c: mk_rcc simply
calls mk_tgc. rcc isn't a primitive, the primitive constructed by
"in foo rcc ..." is a tgc |
16:12.17 |
*** join/#brlcad hoiji
(671b082c@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.44) |
16:19.09 |
*** join/#brlcad jasleen
(~chatzilla@117.255.247.150) |
16:38.52 |
*** join/#brlcad kesha
(~kesha@14.139.122.114) |
17:39.12 |
*** join/#brlcad richa
(uid11933@gateway/web/irccloud.com/x-eudpradxfcselbbe) |
17:41.13 |
*** join/#brlcad kesha
(~kesha@14.139.122.114) |
18:13.15 |
*** join/#brlcad Denis
(~denisilie@p16.eregie.pub.ro) |
18:32.05 |
*** join/#brlcad ries
(~ries@190.9.171.121) |
18:43.52 |
Notify |
03BRL-CAD:carlmoore * 60414
(brlcad/trunk/doc/docbook/system/mann/en/build_region.xml
brlcad/trunk/doc/tool_categories.txt and 15 others): fix spellings;
2 cases of 'eg' should have been 'e.g.' (I can NOT change 'eg' if
it is part of a program-used name) |
19:03.28 |
*** join/#brlcad LordOfBikes
(~armin@dslb-094-216-166-051.pools.arcor-ip.net) |
20:47.53 |
brlcad |
teepee: and brl-cad code that IS being moved
to a library (unless we find something better, something we could
collaborate on like stepcode .. but that's looking slim
pickings) |
20:49.03 |
teepee |
brlcad: starseeker wanted to have a look ad
Coin3D |
20:52.56 |
brlcad |
heh sure |
20:53.42 |
brlcad |
though pulling in something that aims to be
openinventor just for format conversion is literally akin to buying
a house to get the sink |
20:54.00 |
brlcad |
might be extractable, though I'm not seeing it
yet in their tree |
20:54.15 |
brlcad |
dxf isn't that complex a format .. most of the
work is the wiring |
20:54.25 |
teepee |
https://bitbucket.org/Coin3D/dime |
20:54.30 |
teepee |
sounds like it's in a library |
20:54.44 |
teepee |
but i haven't looked at the code yet |
20:55.25 |
brlcad |
ah cool, that would be why I couldn't find it
in the coin3d tree |
20:56.00 |
brlcad |
was going to say, unless someone created a
general library, there's not much difference with our parser at
that point (given the work is the wiring) |
20:57.30 |
brlcad |
which they did, so quite possible |
20:58.03 |
brlcad |
maybe that'll be our first plugin test
case |
20:58.05 |
teepee |
it probably has not proven yet that it has a
general useful api |
20:58.32 |
teepee |
but at least the license is generally
agreeable :) |
20:58.50 |
teepee |
and if it's not working out there's still the
brl-cad code |
20:58.57 |
brlcad |
nods |
21:02.17 |
teepee |
I'm not yet convinced it's a good idea to mix
2d and 3d for an import/export library |
21:03.44 |
brlcad |
dxf describes both |
21:03.53 |
*** join/#brlcad FreezingCold
(~FreezingC@135.0.41.14) |
21:04.40 |
brlcad |
that's actually one of the cool features of
ours, that it'll bring in dxf 2D sketch entities as our sketch and
extrusion entities as well, so you import the 3D
definition |
21:05.14 |
brlcad |
looks like their parser is set up to handle
pretty most/all of the entities |
21:05.16 |
teepee |
so dxf can describe extrusion? |
21:05.19 |
brlcad |
yeah |
21:05.34 |
brlcad |
"can" |
21:05.42 |
teepee |
hmm, ok. i only used 2d dxf so far |
21:05.44 |
brlcad |
in my experience, they usually do, but don't
need to |
21:06.20 |
*** join/#brlcad drv_
(~smuxi@dynamic-78-9-147-183.ssp.dialog.net.pl) |
21:06.27 |
brlcad |
they have full 3D polyface support too, so
it's also got most of the concepts of formats like obj and
stl |
21:07.25 |
teepee |
looks like that's again something used for
specific workflows |
21:07.30 |
brlcad |
it's actually not a "bad" format .. just a lot
of codes everywhere that they use to describe things which can seem
wonky |
21:07.32 |
teepee |
like 3d printing invented the AMF
format |
21:08.01 |
brlcad |
nice, looks like dime can read AND write
dxf |
21:08.04 |
brlcad |
as well as dxb |
21:08.40 |
brlcad |
for all entities |
21:08.53 |
brlcad |
at least all the ones I'm point
sampling |
21:10.05 |
brlcad |
yeah, I could definitely see giving this a try
as our first plugin to GCV ... |
21:10.22 |
teepee |
talking of file formats, do you have SVG
import? |
21:10.33 |
brlcad |
looks similar to what we have in terms of
read/write support, but better organized |
21:10.44 |
brlcad |
Nooo.. that's not a 3d format :P |
21:10.59 |
teepee |
right, it's quite 2d :) |
21:11.34 |
brlcad |
we call those image formats ;) |
21:12.03 |
brlcad |
or "images" for short |
21:12.37 |
brlcad |
mm, just reading up on AMF .. DXF is actually
a lot more complicated in comparison, many more features |
21:13.09 |
teepee |
hmm, we do use SVG pretty much at the same
level as DXF |
21:13.41 |
teepee |
(or better plan to use...) |
21:13.52 |
brlcad |
http://usa.autodesk.com/adsk/servlet/item?siteID=123112&id=12272454&linkID=10809853 |
21:14.56 |
teepee |
oh, it even has sweep and loft |
21:15.19 |
brlcad |
it's basically anything you can do in
autocad |
21:16.05 |
brlcad |
though some things get dumb'd down if written
to dxf compared to getting written out as dwg |
21:16.08 |
teepee |
ahh, that's the user interface stuff. I first
thought it's the file format |
21:17.06 |
brlcad |
ah, that link didn't go through
right |
21:17.22 |
teepee |
there's a big discussion about this going on
right now as it would be nice to have support for this
features |
21:18.03 |
brlcad |
http://images.autodesk.com/adsk/files/acad_dxf0.pdf |
21:18.05 |
brlcad |
that's better |
21:18.41 |
teepee |
yeah, i downloaded that some weeks ago when
the first proposal about dxf import came in |
21:19.23 |
teepee |
the number of pages already tells it's not the
easiest format |
21:19.59 |
brlcad |
heh |
21:20.21 |
teepee |
the AMF spec is 15 pages |
21:20.26 |
brlcad |
it's actually rather simple format, the whole
thing decomposes into blocks with entities in a block .. each
defined by a code |
21:20.52 |
brlcad |
there are just hundreds of possible
codes |
21:21.07 |
brlcad |
to write a parser, you have to deal with maybe
10-20 codes |
21:21.31 |
hcurtis |
brlcad: Hi, Sean. I just wanted to make sure I
understood correctly--when you said "I could definitely see giving
this a try as our first plugin to GCV," you were referring to dxf,
right? |
21:21.40 |
brlcad |
unless you want all the details like line
stipple type and arrow types and font styles and vertex colors and
... |
21:21.52 |
brlcad |
hcurtis: yes, I was |
21:22.15 |
teepee |
hmm, yeah, I guess we will not support that
for quite some time |
21:22.21 |
hcurtis |
brlcad: Cool |
21:22.35 |
brlcad |
GCV is intended to a an excessively modular
plugin-style library so we/others can plug in formats |
21:22.58 |
hcurtis |
Yes |
21:23.43 |
teepee |
compile-time or run-time plugins? |
21:25.18 |
brlcad |
I envision there being a set of core formats
bundled in compile-time for basic functionality, but at least
having the ability to load plugins at run-time is
desirable |
21:25.21 |
brlcad |
whether it ships with them configured that way
or not |
21:25.46 |
teepee |
cool |
21:28.01 |
brlcad |
I could see someone wiring up some commercial
plugin for thier needs, they'd need to be able to just compile
against the lib and have it work |
21:28.01 |
brlcad |
or another project that has their own format
needs that might not be integratable for whatever reason (e.g.,
license) ... dwg is a great example |
21:29.50 |
teepee |
sounds very promising |
21:30.29 |
teepee |
it's a bit strange that nothing really usable
exists in that area yet |
21:30.47 |
brlcad |
and one of the best ways to share our treasure
trove of file formats that we've implemented over the
years |
21:30.49 |
teepee |
looks like every project did roll their own
solutions |
21:31.19 |
brlcad |
each format is hard and it's easty to put
blinders on to just import that small bit of data you care
about |
21:31.49 |
teepee |
indeed, and the additional effort to create a
nice API is quite big |
21:31.58 |
brlcad |
we have 2 or 3 formats that literally took
years of full-time effort to implement |
21:32.19 |
brlcad |
and they're still just "a good start" in our
view |
21:33.06 |
Notify |
03BRL-CAD:carlmoore * 60415
(brlcad/trunk/src/conv/step/g-ap242/AP242_managed_model_based_3d_engineering_20131030.exp
brlcad/trunk/src/libpc/pcMathGrammar.h): fix spellings (it's been
called to my attention that the fix to the *242* file will have to
propagate upstream) |
21:34.40 |
brlcad |
at quick glance, it looks like we have support
for 33 different file formats, either import, export, or
both |
21:35.19 |
brlcad |
granted about half are the stupid easy
polygonal formats, but the other half ... not so much |
21:35.37 |
hcurtis |
brlcad: Wow, this pdf on dxf that you provided
the link to is beautiful. Thanks for sharing it. You might not know
this, but dxf is of special interest to me because it was one of my
first BRL-CAD-related research topics. I originally was going to
write my proposal on dxf import. |
21:36.04 |
brlcad |
hcurtis: we have a dxf importer
already |
21:36.40 |
brlcad |
could be beefed up (or replaced by dime), but
it's actually pretty robust and featured for 3D data |
21:36.46 |
teepee |
quite a lot, we pretty much had STL/OBJ only
up to some weeks ago :) |
21:37.23 |
hcurtis |
brlcad: Don't I know it. :) Teepee and others
told me, and I went in another direction with my
proposal. |
21:37.47 |
teepee |
well, that dxf import proposal was actually
OpenSCAD |
21:38.27 |
hcurtis |
teepee: That is correct. |
21:38.29 |
teepee |
as the current import is limited so much it
really causes trouble with any normally exported file (e.g. from
inkscape |
21:38.29 |
teepee |
) |
21:39.25 |
*** join/#brlcad zxq9
(~ceverett@FL9-125-199-207-150.okn.mesh.ad.jp) |
22:21.09 |
Notify |
03BRL-CAD:brlcad * 60416
brlcad/trunk/CMakeLists.txt: group the test logic together for the
ones that require additional testing |
22:25.45 |
``Erik |
brlcad: crit was not affected by heartbleed,
but I went ahead and updated world (thus openssl) and restarted
apache anyway... php had split out the apache module so there was
some issue getting the php pages working again, so service
disruption :/ should all be sorted now |
22:51.15 |
Notify |
03BRL-CAD:brlcad * 60417
(brlcad/trunk/src/libged/vutil.c brlcad/trunk/src/mged/mged.c):
make sure gvp is not null before we dig the view matrices out of it
for bn_mat_mul(). carl isolated a crash in the mirror command
caused by this very issue (presumably in console mode). the
ged_view_update() call was specifically to blame. |
22:53.56 |
Notify |
03BRL-CAD:brlcad * 60418 (brlcad/trunk/BUGS
brlcad/trunk/NEWS): reported by carl moore, fixed a bug in mged
where it'd crash if there was no view after running the mirror
command. looking at the cause, it was really any command that
attempted to update the view that could provoke this
issue. |
22:55.38 |
brlcad |
``Erik: awesome! I was just wondering that
yesterday |
22:56.04 |
brlcad |
way to go on updates to miss that one! .. so
many affected |
23:00.56 |
brlcad |
starseeker: note carls' r60415 commit fixed
errors in the 242 schema .. something else to share on stepcode
list to hopefully get that propagated up |
23:07.12 |
*** join/#brlcad cstirk
(~charlie@c-71-56-216-45.hsd1.co.comcast.net) |
23:26.22 |
*** join/#brlcad drv_
(~smuxi@dynamic-78-9-147-183.ssp.dialog.net.pl) |
23:50.40 |
*** join/#brlcad Anaphaxeton
(~george@unaffiliated/anaphaxeton) |