00:31.58 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
01:09.05 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
01:59.10 |
CIA-32 |
BRL-CAD: 03indianlarry * r34816
10/brlcad/trunk/ (include/opennurbs_ext.h
src/librt/primitives/brep/brep.cpp): added trim distance return to
isTrimmed() for determining when hit crack |
02:28.28 |
CIA-32 |
BRL-CAD: 03ralith * r34817
10/rt^3/trunk/src/other/ogre/Samples/Media/ (428 files in 21 dirs):
Added Ogre SVN (r8739, latest as of this commit) due to serious
bugs in features needed by g3d in Ogre stable. Partial
commit. |
03:10.49 |
CIA-32 |
BRL-CAD: 03ralith * r34818
10/rt^3/trunk/src/other/ogre/Samples/Lighting/ (21 files in 11
dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
03:11.56 |
CIA-32 |
BRL-CAD: 03ralith * r34819
10/rt^3/trunk/src/other/ogre/Samples/ (77 files in 37 dirs): Added
Ogre SVN (r8739, latest as of this commit) due to serious bugs in
features needed by g3d in Ogre stable. Partial commit. |
03:14.55 |
CIA-32 |
BRL-CAD: 03ralith * r34820
10/rt^3/trunk/src/other/ogre/Samples/ (95 files in 49 dirs): Added
Ogre SVN (r8739, latest as of this commit) due to serious bugs in
features needed by g3d in Ogre stable. Partial commit. |
03:16.12 |
CIA-32 |
BRL-CAD: 03ralith * r34821
10/rt^3/trunk/src/other/ogre/Samples/ (86 files in 41 dirs): Added
Ogre SVN (r8739, latest as of this commit) due to serious bugs in
features needed by g3d in Ogre stable. Partial commit. |
03:16.35 |
CIA-32 |
BRL-CAD: 03ralith * r34822
10/rt^3/trunk/src/other/ogre/Scripts/ (.keepme m4/ m4/cppunit.m4
m4/sdl.m4 null.sh remove_debug.sh): Added Ogre SVN (r8739, latest
as of this commit) due to serious bugs in features needed by g3d in
Ogre stable. Partial commit. |
03:20.45 |
CIA-32 |
BRL-CAD: 03ralith * r34823
10/rt^3/trunk/src/other/ogre/Tests/ (97 files in 29 dirs): Added
Ogre SVN (r8739, latest as of this commit) due to serious bugs in
features needed by g3d in Ogre stable. Partial commit. |
03:58.51 |
Ralith |
wonders just how long a svn
commit can take |
04:12.46 |
Ralith |
okay, it's locked up now. |
04:12.57 |
louipc |
wee! |
04:13.19 |
Ralith |
kill -9s and tries
again |
04:13.34 |
louipc |
I feel your pain man |
04:14.23 |
louipc |
maybe I can help. let me know if there's
anything |
04:14.50 |
Ralith |
thanks, I'll do that |
04:15.00 |
Ralith |
pretty sure it's just a matter of slogging
through the heirarchy though. |
04:15.25 |
Ralith |
(and stomping the occasional bug) |
04:31.47 |
Ralith |
another lockup >:| |
05:15.32 |
*** join/#brlcad madant
(n=cb7baf0f@bz.bzflag.bz) |
06:44.09 |
*** join/#brlcad stevegt_1
(n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) |
06:45.52 |
stevegt_1 |
wonders if there's any clean
way to generate 2-D toolpaths to laser cut panels from a BRL-CAD
model |
06:46.25 |
stevegt_1 |
wonders if anyone else is
awake right now |
06:46.46 |
stevegt_1 |
probably have to poke in here tomorrow and ask
again |
06:47.52 |
Ralith |
I'm here |
06:47.56 |
Ralith |
it's theoretically possible |
06:48.02 |
Ralith |
jonored wrote the code to do most of the
work |
06:48.17 |
Ralith |
but he hasn't been around for a while and
never published it |
06:48.50 |
Ralith |
the raytracer gives you enough info to do
it |
06:49.24 |
stevegt_1 |
I just spend the weekend digging through
g-xxx.c et al -- looks doable, but I'd hate to make a fool of
myself if it's already been done |
06:49.35 |
Ralith |
it hasn't. |
06:49.41 |
Ralith |
it's nontrivial though |
06:50.11 |
Ralith |
let us know if you get it working |
06:50.20 |
Ralith |
it'd be a very useful for lots of
things |
06:50.29 |
stevegt_1 |
maybe i'm thinking of it all wrong -- I'm
seeing it as a 2-D dxf generation problem... you think I need to be
looking at the raytracing code instead? |
06:51.04 |
Ralith |
well if you want to just convert a sketch to a
dxf that's not hard |
06:51.12 |
Ralith |
or at least I imagine it's not, I don't know
the relevant code |
06:51.29 |
Ralith |
but going from a 3D model to 2D toolpaths is
significantly more involved. |
06:53.30 |
stevegt_1 |
well, what i'd want to be able to do is put
together a model, mark the material attributes for the parts that
are going to be laser-cut, then, in something like 'g-epilog',
filter out just those parts, and generate a dxf or epilog (PCL)
file for each one |
06:54.22 |
stevegt_1 |
i'm not sure that would solve the general
g-code generation problem, except for driving CNC routers and
lasers |
06:55.06 |
Ralith |
that's most of it |
06:55.15 |
Ralith |
and once you've solved that, any further uses
could easily build on your work |
06:55.26 |
stevegt_1 |
huh |
06:58.14 |
stevegt_1 |
do you know if there's already a piece of code
buried somewhere in the tree that i could call or copy which would
help me rotate a part so it's normal to a reference plane, then get
the resulting 2-D vertices? I don't know if I'm making any sense
or not... for instance, I started looking at the "flatten" stuff
in the NMG libs, not even sure if that's related |
06:59.06 |
stevegt_1 |
s/rotate a part so it's normal/rotate a part
so the largest face is normal/ |
06:59.09 |
stevegt_1 |
or something like that |
07:01.07 |
stevegt_1 |
i mean, if we first assume that the shape is
cut from a flat panel (extruded from a sketch, probably, but not
always), then that means that there will always be exactly two flat
faces which are identical, and we can just pick one |
07:01.24 |
Ralith |
stevegt_1: ...BRL-CAD isn't
mesh-based. |
07:01.25 |
Ralith |
it's CSG. |
07:01.36 |
Ralith |
there's no such thing as "the corresponding
vertices" |
07:01.47 |
stevegt_1 |
right, which means i'm probably confusing
myself by looking at the g-xxx code |
07:01.53 |
Ralith |
everything is in terms of volumes |
07:02.02 |
Ralith |
extracting 2d toolpaths is
nontrivial. |
07:02.19 |
stevegt_1 |
which is why you're mentioning the
raytracer? |
07:02.48 |
Ralith |
that's how you work with the evaluated form of
a BRL-CAD model. |
07:02.54 |
Ralith |
through raytracing. |
07:06.32 |
stevegt_1 |
looking at how the g-xxx
triangulation code does it's job |
07:06.32 |
Ralith |
you don't want to do tesselation. |
07:06.32 |
Ralith |
that's a waste of information |
07:06.32 |
Ralith |
considering that gcode can do true
arcs |
07:06.55 |
stevegt_1 |
that's what i was afraid you'd say |
07:07.06 |
stevegt_1 |
or glad, actually |
07:07.15 |
stevegt_1 |
'cause i was ignoring it so far ;-) |
07:07.21 |
stevegt_1 |
the tesellation code, i mean |
07:08.02 |
stevegt_1 |
was thinking i didn't need it, but now i'm
wondering how it does its job -- going to look |
07:13.55 |
stevegt_1 |
suddenly recalls that it's
g-xxx_facets which does tesselation, which he doesn't need, while
g-xxx does not do tesselation anyway -- it just iterates through
the results of rt_dirbuild |
07:14.31 |
stevegt_1 |
and printf's what it finds |
07:17.15 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
07:21.59 |
stevegt_1 |
looking at g2asc as well now... i'm confused
-- if I have the record in hand that i got from the db, then i have
its parameters in record.s.s_values -- why do i need to raytrace?
to account for booleans? |
07:22.13 |
stevegt_1 |
must be that |
07:25.04 |
stevegt_1 |
i'm going to take a guess and say that the
reason why 2-D toolpath generation has been considered to be a hard
problem is that it's been generally accepted that we needed to
invoke the raytracer to execute boolean operations first |
07:25.38 |
Ralith |
it's not HARD |
07:25.41 |
Ralith |
just hasn't been done yet |
07:25.58 |
Ralith |
there's lots of other stuff to do. |
07:26.11 |
stevegt_1 |
okay, deferred ;-) |
07:27.24 |
Ralith |
and yeah, the only way to evaluate booleans is
to raytrace |
07:27.41 |
Ralith |
only data you can get without raytracing is
the primitives |
07:31.11 |
stevegt_1 |
i'm thinking of gershenfeld's cad.py -- he
used python's numpy 3-D matrix operations to do the booleans in
very little code; part of my brain must have been assuming i'd do
that instead of calling the brl-cad raytracer |
07:31.20 |
Ralith |
... |
07:31.58 |
Ralith |
the raytracer's ability to evaluate booleans
is one of BRL-CAD's major high points |
07:32.00 |
stevegt_1 |
yeah, whacky -- i should look at the raytracer
first |
07:32.08 |
Ralith |
you'd basically be using BRL-CAD for nothing
but its fileformat |
07:32.19 |
Ralith |
doing booleans well is hard. |
07:32.28 |
Ralith |
the raytracer will give you just about perfect
precision. |
07:32.32 |
Ralith |
and reliably, too. |
07:34.18 |
stevegt_1 |
Any suggestion where I should start to get my
head around it? I've been going back and forth through the PDF
tutorials, including the Application_Develeopment slideshow -- am I
missing some swath of developer docs somewhere else? |
07:35.02 |
Ralith |
what kind of docs do you want |
07:36.13 |
stevegt_1 |
I probably don't know enough yet to ask. ;-)
I'll have to go through that slideshow again. I was ignoring the
raytracing before, was just llooking at the DB access bits.
|
07:44.14 |
stevegt_1 |
hmm. src/rt/viewarea.c looks like a real good
place to start as well |
07:45.43 |
stevegt_1 |
actually all the view*.c stuff |
07:48.50 |
stevegt_1 |
expects to sit down someplace
quiet tomorrow and grok view*.c -- "only" 11,568 lines
;-) |
07:49.16 |
stevegt_1 |
Ralith: thank you, very much -- I think you
got me on the right track |
07:49.20 |
Ralith |
cool |
08:11.54 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
08:11.54 |
*** mode/#brlcad [+o ChanServ]
by irc.freenode.net |
09:09.48 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14C62F.dip.t-dialin.net) |
09:50.56 |
*** join/#brlcad CIA-32
(n=CIA@208.69.182.149) |
10:55.08 |
CIA-32 |
BRL-CAD: 03ralith * r34824
10/rt^3/trunk/src/other/ogre/Tools/3dsmaxExport/ (116 files in 26
dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
10:55.17 |
CIA-32 |
BRL-CAD: 03ralith * r34825
10/rt^3/trunk/src/other/ogre/Tools/BitmapFontBuilderTool/ (.
main.cpp): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
10:56.03 |
CIA-32 |
BRL-CAD: 03ralith * r34826
10/rt^3/trunk/src/other/ogre/Tools/BlenderExport/ (24 files in 4
dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
10:56.07 |
CIA-32 |
BRL-CAD: 03ralith * r34827
10/rt^3/trunk/src/other/ogre/Tools/CMakeLists.txt: Added Ogre SVN
(r8739, latest as of this commit) due to serious bugs in features
needed by g3d in Ogre stable. Partial commit. |
10:56.24 |
CIA-32 |
BRL-CAD: 03ralith * r34828
10/rt^3/trunk/src/other/ogre/Tools/CommandLineTools_Readme.txt:
Added Ogre SVN (r8739, latest as of this commit) due to serious
bugs in features needed by g3d in Ogre stable. Partial
commit. |
10:57.25 |
CIA-32 |
BRL-CAD: 03ralith * r34829
10/rt^3/trunk/src/other/ogre/Tools/Common/ (11 files in 5 dirs):
Added Ogre SVN (r8739, latest as of this commit) due to serious
bugs in features needed by g3d in Ogre stable. Partial
commit. |
10:57.52 |
CIA-32 |
BRL-CAD: 03ralith * r34830
10/rt^3/trunk/src/other/ogre/Tools/LightwaveConverter/ (28 files in
4 dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
11:36.12 |
CIA-32 |
BRL-CAD: 03ralith * r34831
10/rt^3/trunk/src/other/ogre/Tools/MaterialEditor/ (178 files in 18
dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
11:37.32 |
CIA-32 |
BRL-CAD: 03ralith * r34832
10/rt^3/trunk/src/other/ogre/Tools/MayaExport/ (35 files in 6
dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
11:37.41 |
CIA-32 |
BRL-CAD: 03ralith * r34833
10/rt^3/trunk/src/other/ogre/Tools/MeshUpgrader/ (7 files in 3
dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
11:38.08 |
CIA-32 |
BRL-CAD: 03ralith * r34834
10/rt^3/trunk/src/other/ogre/Tools/MilkshapeExport/ (28 files in 9
dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
11:38.32 |
CIA-32 |
BRL-CAD: 03ralith * r34835
10/rt^3/trunk/src/other/ogre/Tools/VRMLConverter/ (26 files in 7
dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
11:38.36 |
*** join/#brlcad louipc
(n=louipc@69-196-134-147.dsl.teksavvy.com) |
11:38.44 |
CIA-32 |
BRL-CAD: 03ralith * r34836
10/rt^3/trunk/src/other/ogre/Tools/Wings3DExporter/ (11 files):
Added Ogre SVN (r8739, latest as of this commit) due to serious
bugs in features needed by g3d in Ogre stable. Partial
commit. |
11:41.03 |
CIA-32 |
BRL-CAD: 03ralith * r34837
10/rt^3/trunk/src/other/ogre/Tools/XMLConverter/ (22 files in 5
dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
11:42.24 |
CIA-32 |
BRL-CAD: 03ralith * r34838
10/rt^3/trunk/src/other/ogre/Tools/XSIExport/ (32 files in 6 dirs):
Added Ogre SVN (r8739, latest as of this commit) due to serious
bugs in features needed by g3d in Ogre stable. Partial
commit. |
11:42.34 |
CIA-32 |
BRL-CAD: 03ralith * r34839
10/rt^3/trunk/src/other/ogre/Tools/dotXSIConverter/ (. include/
include/Exporter.h src/ src/Exporter.cpp): Added Ogre SVN (r8739,
latest as of this commit) due to serious bugs in features needed by
g3d in Ogre stable. Partial commit. |
11:42.44 |
CIA-32 |
BRL-CAD: 03ralith * r34840
10/rt^3/trunk/src/other/ogre/Tools/rcapsdump/ (. scripts/ src/
src/main.cpp): Added Ogre SVN (r8739, latest as of this commit) due
to serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
11:42.57 |
Ralith |
:D |
11:42.58 |
Ralith |
done! |
11:45.12 |
CIA-32 |
BRL-CAD: 03Ralith 07http://brlcad.org * r1501
10/wiki/User:Ralith: Log for 2009-06-21 |
13:07.25 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
13:19.33 |
*** join/#brlcad mafm
(n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) |
13:36.28 |
brlcad |
Ralith: hehe, well congrats on that ..
ouch |
13:36.57 |
brlcad |
next time you have something that big, maybe
could tar it up for one of the other devs to commit :) |
13:37.24 |
brlcad |
couldn't hurt to put in an sf.net ticket if
only to have them check it out too just to make sure it's not
something on their end |
13:38.09 |
brlcad |
stevegt_1: there is an overview on the website
that explains the rt view*.c interface |
13:39.19 |
brlcad |
http://brlcad.org/w/images/3/3d/Application_Development.pdf
(found under http://brlcad.org/wiki/Developing_applications
) |
13:39.48 |
brlcad |
stevegt_1: basically it amounts to about a
half-dozen callbacks that you define and register |
13:40.45 |
brlcad |
ahh, reading more of the backlog, I see you
found that pdf already |
13:42.38 |
brlcad |
so probably just asking questions in here is
your best bet if you don't quickly make sense of the code -- each
of those view*.c files is for a separate application like rt,
rtarea, rtweight, rtcheck, etc .. |
13:43.01 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14C62F.dip.t-dialin.net) |
13:43.55 |
brlcad |
those half-dozen or so callbacks are all that
is needed to define the entire application as the rt user interface
is exactly the same across all of them for the front-end (argument
processing, shooting a grid of primary rays, aggregating results,
running in parallel, etc) |
13:56.28 |
brlcad |
case local folks don't see the e-mail or if
others are close by and want to join up, we're looking to have
dinner at Tidewater tonight in Havre de Grace, Maryland around
6pm |
13:56.48 |
starseeker |
ah, thanks :-) |
13:56.54 |
brlcad |
GMTA |
13:57.18 |
brlcad |
~seen madant |
13:57.21 |
ibot |
madant <n=cb7baf0f@bz.bzflag.bz> was
last seen on IRC in channel #brlcad, 1d 5h 16m 20s ago, saying:
'~sleep'. |
14:30.56 |
CIA-32 |
BRL-CAD: 03Tbrowder 07http://brlcad.org * r1502
10/wiki/BRL-CAD%27s_core_C%2B%2B_interface: /* Application Domain
*/ |
14:31.48 |
CIA-32 |
BRL-CAD: 03Tbrowder 07http://brlcad.org * r1503
10/wiki/BRL-CAD%27s_core_C%2B%2B_interface: /* The interface should
be self-contained */ |
15:34.08 |
CIA-32 |
BRL-CAD: 03bob1961 * r34841
10/brlcad/trunk/src/libged/expand.c: Modify ged_expand to return
only database entries that match the pattern(s). |
15:37.55 |
brlcad |
woot! |
15:38.05 |
brlcad |
go go gadget tom |
15:42.29 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
15:43.36 |
jdoliner |
hey guys can someone give me a hand with
ON_SimpleArrays? |
15:44.00 |
jdoliner |
particularly for somereason when I try to use
them I get compile errors that there's no match found for []
operators |
15:44.49 |
jdoliner |
ON_SimpleArray<ON_Line>
segments; |
15:45.48 |
jdoliner |
and then |
15:45.48 |
jdoliner |
ON_Line segment = segments[j]; |
15:45.52 |
jdoliner |
creates an error |
16:40.50 |
CIA-32 |
BRL-CAD: 03jdoliner * r34842
10/brlcad/trunk/src/proc-db/ (brepintersect.cpp brepintersect.h):
Added function TriangleMeshIntersect which intersects a triangle
with a mesh and returns as a polyline their intersection
curve |
17:01.40 |
brlcad |
jdoliner: it returns a reference |
17:02.01 |
brlcad |
type have a type error |
17:03.35 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
17:03.51 |
jdoliner |
so segments is of type
ON_SimpleArray<ON_Line>&? |
17:04.04 |
jdoliner |
then how to I get at its contents? |
17:04.37 |
brlcad |
no, see the header, it returns a
T& |
17:04.46 |
brlcad |
so needs to be an ON_Line& |
17:05.15 |
brlcad |
assuming the type problem isn't on the
j |
17:05.16 |
jdoliner |
okay that makes sense then |
17:06.46 |
jdoliner |
k cool I get it now |
17:26.32 |
CIA-32 |
BRL-CAD: 03jdoliner * r34843
10/brlcad/trunk/src/proc-db/brepintersect.cpp: Modified
TriangleMeshIntersect to be MeshMeshIntersect, now just directly
intersects two meshes and returns an array of Polylines for their
intersection |
17:49.06 |
CIA-32 |
BRL-CAD: 03bob1961 * r34844
10/brlcad/trunk/src/tclscripts/archer/ (33 files in 4 dirs): Added
the first installment of the undo functionality (i.e. only handling
mods to existing geometry) to Archer. More to follow for create,
destroy and rename. |
17:50.00 |
brlcad |
wonders how much of the hackery that
involved.. |
17:57.35 |
*** join/#brlcad _sushi_
(n=_sushi_@80-219-42-101.dclient.hispeed.ch) |
18:23.30 |
CIA-32 |
BRL-CAD: 03Jdoliner 07http://brlcad.org * r1504
10/wiki/User:Jdoliner: |
18:53.53 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
19:45.15 |
brlcad |
jdoliner: curious what your current
goal/milestone is |
19:46.00 |
jdoliner |
my current goal is to finish mesh on mesh
intersections |
19:46.13 |
brlcad |
ON_Mesh objects are all polygonal,
yes? |
19:46.18 |
jdoliner |
yes |
19:46.52 |
brlcad |
they are all untrimmed? |
19:47.08 |
brlcad |
or do they allow/require trimming
evaluation? |
19:47.16 |
jdoliner |
I believe that they are untrimmed |
19:47.30 |
jdoliner |
at least nowhere in the definition do I say
any mention of trimming |
19:47.38 |
brlcad |
okay cool -- there is a problem with one of
your intersection routines if you allow trims |
19:48.34 |
jdoliner |
I see, actually I guess this is a good time
for me to learn some things about trims |
19:48.50 |
jdoliner |
so meshes don't have trims which works
well |
19:49.18 |
jdoliner |
so the way I see it, is that I do an
intersection |
19:49.20 |
brlcad |
one thing that will be very interesting to
test then once you have mesh on mesh intersections working is
having an nmg->ON_Mesh conversion to perform the booleans using
your routines instead of the (extensively complex) NMG
library |
19:50.07 |
jdoliner |
yeah definitely |
19:50.26 |
jdoliner |
so then after the intersection I get back the
polyline |
19:51.09 |
jdoliner |
and then I basically need to just make a new
mesh where I trim off the parts outside of the polyline |
19:52.41 |
jdoliner |
but when I do stuff with nurbs, which support
trimming curves I can just put them in as trimming curves |
19:52.57 |
brlcad |
right |
19:52.58 |
jdoliner |
and then my intersection algorithms need to
take into account the trimming curves |
19:53.13 |
brlcad |
plus you'll have to deal with more generalized
ON_Brep objects, not just ON_Mesh objects |
19:53.16 |
brlcad |
in order to get nurbs |
19:53.20 |
jdoliner |
yes |
19:53.36 |
jdoliner |
what does ON do with the trimming
curves |
19:53.45 |
jdoliner |
are they just used in rendering |
19:54.06 |
brlcad |
a good test case might be to take the cube
that is produced by breplicator or brep_test in src/proc-db, make a
copy of it, translated slightly so it overlaps corners, then
evaluate a boolean |
19:54.48 |
brlcad |
the trimming curves are part of the
topological structure, they define the actual edge to a given
surface |
19:54.49 |
jdoliner |
or is there some function which actually sort
of freezes the nurbs in their trimmed form |
19:55.04 |
brlcad |
there is not (that I"m aware of) |
19:55.13 |
jdoliner |
k I'll poke around |
19:55.36 |
brlcad |
it would be useful to have a routine that took
a given ON_Brep and evaluated all trims to give a resulting object
that is trim-free |
19:55.44 |
brlcad |
or at least only outer trims |
19:56.24 |
brlcad |
so there is a 1-1 relationship with trims to
edges, each edge corresponding to a curve you can test
against |
19:56.59 |
jdoliner |
okay, that makes sense |
19:58.19 |
brlcad |
jdoliner: also, if you've not read it yet,
this may be of some assistance organizationally |
19:58.23 |
brlcad |
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/doc/TODO.BREP |
19:58.40 |
brlcad |
has all of the various pairwise evaluation
possibilities |
20:01.42 |
jdoliner |
I see, are all those things
unimplemented? |
20:03.36 |
brlcad |
oh no, much is, much isn't .. some IS
implemented (particularly for polygonal types), but for different
(non-opennurbs) data types |
20:04.24 |
brlcad |
some is very robust to numerical issues, some
isn't -- it's a very large body of code that gets involved when you
start talking about existing brep work |
20:08.48 |
brlcad |
code of relevance is src/librt/primitives/nmg
(extensive polygonal mesh CSG library, radial-edge data structure),
src/librt/primitives/bspline (old nurbs implementation, lacking
support for trimmed nurbs surfaces), src/librt/opennurbs_ext.cpp
and src/librt/primitives/brep (active new nurbs
development) |
20:09.37 |
brlcad |
suggest at least taking a look at the nmg
routines as they strongly relate to what you're doing with
ON_Mesh |
20:13.51 |
jdoliner |
yes will do immediately |
20:17.14 |
brlcad |
nmg_evaluate_boolean() is particularly
relevant, starting in src/librt/primitives/nmg/nmg_eval.c |
20:18.38 |
brlcad |
as you are going to end up with some sort of
similar routine hopefully to evaluate two ON_Brep objects |
20:26.22 |
CIA-32 |
BRL-CAD: 03indianlarry * r34845
10/brlcad/trunk/ (include/opennurbs_ext.h
src/librt/primitives/brep/brep.cpp): added NEAR_MISS points to
hitlist, hitlist logic being worked |
21:09.41 |
*** join/#brlcad stevegt_1
(n=stevegt@cislunar.TerraLuna.Org) |
21:22.21 |
CIA-32 |
BRL-CAD: 03starseeker * r34846
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: |
21:22.27 |
CIA-32 |
BRL-CAD: Try to add a printout message that
will detail the type of odd hit count |
21:22.34 |
CIA-32 |
BRL-CAD: behavior being observed - for reasons
not quite clear, the reporting isn't doing |
21:22.38 |
CIA-32 |
BRL-CAD: what I expected it to - it's not
reporting close points at all and only |
21:22.44 |
CIA-32 |
BRL-CAD: occasionally reporting
entering/leaving status. |
21:36.02 |
starseeker |
indianlarry: am I doing something wrong with
printing out the hit info? |
21:39.58 |
CIA-32 |
BRL-CAD: 03irpguardian * r34847
10/brlcad/trunk/TODO: Added human geometry generator item |
21:56.23 |
*** join/#brlcad madant
(n=cb7baf0f@bz.bzflag.bz) |
22:07.25 |
madant |
what is the bn or bu random number generating
function which i could use as an id |
22:23.14 |
Ralith |
brlcad: thanksâhopefully it won't come up
again. |
22:36.28 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14C62F.dip.t-dialin.net) |
22:43.22 |
*** join/#brlcad mafm_
(n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) |
23:05.48 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
23:06.50 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
23:09.38 |
*** join/#brlcad mafm_
(n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) |