02:29.20 |
*** join/#brlcad mahesh
(n=mahesh@12-217-228-235.client.mchsi.com) |
06:20.27 |
*** join/#brlcad clock_
(n=clock@84-72-90-11.dclient.hispeed.ch) |
07:33.14 |
*** join/#brlcad clock_
(n=clock@84-72-90-11.dclient.hispeed.ch) |
09:30.08 |
*** join/#brlcad clock_
(n=clock@zux221-122-143.adsl.green.ch) |
13:17.05 |
*** join/#brlcad archivist
(n=archivis@host217-35-76-52.in-addr.btopenworld.com) |
13:42.05 |
*** join/#brlcad
joevalleyfield (n=joevalle@bz.bzflag.bz) |
19:34.44 |
*** join/#brlcad clock_
(n=clock@zux221-122-143.adsl.green.ch) |
19:36.45 |
*** join/#brlcad pier
(n=pier@151.56.220.10) |
19:56.56 |
*** join/#brlcad clock_
(n=clock@zux221-122-143.adsl.green.ch) |
21:06.35 |
pier |
Hi brlcad |
21:30.57 |
brlcad |
howdy |
21:47.42 |
pier |
hi.. |
21:48.01 |
pier |
I am having a look at the g-dxf.c
code |
21:48.34 |
pier |
and wondering where to look for the
db_walk_tree function source |
21:49.38 |
brlcad |
eep, you hopefully don't need to follow
db_walk_tree beyone understanding that it walks the database
geometry tree |
21:49.49 |
brlcad |
regardless, it's in
src/librt/db_tree.c |
21:50.33 |
brlcad |
parallel tree walker |
21:51.16 |
pier |
looks like this function does a lot of very
important things |
21:52.14 |
pier |
Does it brows the input file pointed by
dbip? |
21:53.13 |
brlcad |
it does |
21:54.11 |
brlcad |
it walks through all the geometry in a
directory |
21:54.32 |
brlcad |
by itself, that is all that it does |
21:54.55 |
brlcad |
what makes it useful, though, is that you
provide it function pointers |
21:55.43 |
pier |
nmg_booltree etc? |
21:55.44 |
brlcad |
those callback functions are called when
various geometry are encountered |
21:58.03 |
pier |
so these functions get out triangles from the
shapes in the db tree? |
21:58.46 |
brlcad |
what are you looking at
specifically? |
21:59.15 |
brlcad |
more than likely if db_walk_tree is being used
with nmg evaluation, then yes.. the geometry is being extracted as
triangles |
21:59.50 |
pier |
I was just trying to work out the way the code
works but the deeper I go the harder it gets |
22:01.36 |
pier |
in order to learn something more about the
way you get the shell surface from a boolean combination of solid
shapes |
22:01.42 |
brlcad |
you're starting with a pretty complicated
converter to begin with |
22:02.22 |
brlcad |
all the nmg_* routines basically do the "get
the shell surface from a boolean combination of solid
shapes" |
22:02.25 |
pier |
... positive.. |
22:03.36 |
brlcad |
so you presumably were looking at: |
22:03.40 |
brlcad |
<PROTECTED> |
22:03.40 |
brlcad |
<PROTECTED> |
22:03.40 |
brlcad |
<PROTECTED> |
22:03.40 |
brlcad |
<PROTECTED> |
22:03.40 |
brlcad |
<PROTECTED> |
22:03.42 |
brlcad |
<PROTECTED> |
22:03.44 |
brlcad |
<PROTECTED> |
22:03.49 |
pier |
yes |
22:04.25 |
brlcad |
when you open a geometry database, you're
create a directory of the contents |
22:04.37 |
brlcad |
that eventually gets you the dbip |
22:04.56 |
pier |
ok |
22:05.09 |
pier |
I get it |
22:05.16 |
brlcad |
the db_walk_tree function there has two
callbacks |
22:05.39 |
brlcad |
whild it's walking the directory, it
encounters combinations/regions and primitives |
22:05.48 |
brlcad |
the primitives are "leaf nodes" |
22:06.09 |
pier |
go on please |
22:06.11 |
brlcad |
when it finds a combination/region,
db_walk_tree() calls do_region_end() |
22:06.25 |
brlcad |
when it finds a primitive, it calls
nmg_booltree_leaf_tess() |
22:07.41 |
brlcad |
nmg_booltree_leaf_tess() is provided by a
library and basically tesselates the object into
triangles |
22:07.54 |
pier |
ok |
22:08.05 |
brlcad |
do_region_end() is presumably a function in
the dxf converter that puts it all together |
22:11.21 |
pier |
I pondered your idea about getting plan views
from a raycastin algorithm and I was trying to understand |
22:12.36 |
pier |
the dxf outputting code to see if that aim
could have been achieved by modifying the g-dxf code |
22:14.25 |
brlcad |
i thought about that a little bit more as
well, the route I'd think about to get a non-discretized answer
would require adding a routine to all the primitives |
22:15.39 |
brlcad |
e.g. for the sphere primitive, there already
exists a routine to evaluate/get the implicit for (the _shot()
routine) and a polygonal explicit form (the _tess()
routine) |
22:15.45 |
pier |
that somewhere finds the coordinates of all
the objects in the db whose manipoulation I wouldn't like to get
involved with |
22:16.33 |
pier |
ok but I got stuck when it comes to the hidden
line removal |
22:16.53 |
brlcad |
if one added a _brep() routine or somesuch
that returned the brep form, you could then rather easily directly
extract exact spline projections |
22:19.17 |
pier |
say I got a pipe |
22:20.11 |
brlcad |
you mean a cylinder? |
22:20.25 |
pier |
which can be thought of as a union rcc1 (with
R) - rcc2 (r<R) |
22:20.58 |
pier |
in a g file I ould retrieve the geometrical
data of both |
22:20.59 |
brlcad |
ah, so an actual hollow pipe, got it |
22:21.04 |
pier |
yes |
22:21.44 |
pier |
rcc1 (lenght L) rcc2 (l>L) |
22:22.33 |
pier |
I could work out the maximum dimensions of the
object |
22:22.56 |
pier |
Xmax Ymax Xmin Ymin to get a view
port |
22:23.41 |
pier |
from whose points shoot perpendicoular
rays |
22:24.15 |
pier |
am I on the right way? |
22:25.34 |
brlcad |
for a discretized method, sure |
22:25.55 |
pier |
mmm |
22:26.05 |
pier |
otherwise |
22:27.36 |
pier |
for a shape one should consider the edges and
project them on a plane |
22:28.02 |
brlcad |
right |
22:28.35 |
brlcad |
that's the method i'm referring to, it's just
a matter of how to "get the edge" |
22:28.39 |
pier |
in the case of a cylinder two ellipses joined
by two lines tangent to botw of them |
22:29.18 |
brlcad |
you can get a discretized edge from ratracing
(a pretty good one at that, but discretized nonetheless) and
respline |
22:30.24 |
brlcad |
for non-discretized splines, you can get the
edges/outlines etc .. but that's where I said that it'll require
modifying the primitives themselves since there currently aren't
routines to do this |
22:31.01 |
brlcad |
the first is more simple (and could even be
tacked into g-dxf or wherever, but the latter is a "better"
solution from a numerical standpoint |
22:32.11 |
pier |
for the sigle shapes (primitives) the
projection shouldn't be hard as long as they are not
concave |
22:33.43 |
brlcad |
some primitives will be very hard |
22:33.46 |
brlcad |
some not so hard |
22:33.49 |
brlcad |
at all |
22:34.06 |
pier |
yes the ellipsoid for instance |
22:34.49 |
brlcad |
the only hard part will be implementing the
boolean evaluation |
22:35.33 |
brlcad |
we have booleans on implicits and triangles,
but not brep splines |
22:35.48 |
brlcad |
even for generalized polygons |
22:35.48 |
pier |
yes |
22:36.17 |
brlcad |
it's more the amount of time/effort
involved |
22:37.05 |
brlcad |
i'd gather it'd be a generous month or so to
get splines in an rtedge fashion inside g-dxf |
22:37.37 |
brlcad |
6+ months to get full brep support, maybe 2 or
3 for minimal |
22:37.48 |
``Erik |
MEER ME |
22:37.50 |
brlcad |
and that's a lot of math |
22:37.50 |
``Erik |
BEER |
22:37.58 |
brlcad |
~beer ``Erik |
22:37.59 |
ibot |
ACTION deftly decants a fine Jever for
``Erik |
22:38.06 |
``Erik |
heh, yelling typo's kinda spoiles the
effect |
22:38.15 |
pier |
maybe for one who knows exactly what to do and
where put hands |
22:38.24 |
brlcad |
yet conveniently still works when it's related
to alcohol |
22:38.37 |
``Erik |
wish I had me some of that |
22:38.43 |
``Erik |
but, alas, I'm not allowed yet |
22:38.54 |
brlcad |
pier: that was factored in somewhat
:) |
22:39.04 |
pier |
:) |
22:39.40 |
pier |
was thinking about matrix rotation to get
ellipsoid projection on a plane but not sure |
22:41.52 |
pier |
ok I'll think it over... going to bed now.
Have a nice day |
22:42.04 |
brlcad |
not so hard if you have brep |
22:42.24 |
brlcad |
it all ends up being transformations on the
splines like how triangles get transformed |
22:47.06 |
pier |
put enough meat on the fire for me... risk
going to get clogged up :) bye |
22:48.15 |
brlcad |
heh, cya |
22:48.56 |
*** part/#brlcad pier
(n=pier@151.56.220.10) |
23:48.31 |
``Erik |
so how's the new gui going? |
23:51.44 |
brlcad |
no decent progress in dec |