00:07.00 |
*** join/#brlcad Twingy
(n=justin@74.92.144.217) [NETSPLIT VICTIM] |
03:26.44 |
*** join/#brlcad dtidrow
(n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
04:45.28 |
*** join/#brlcad jano
(n=point@216.115.228.148) |
04:45.31 |
*** part/#brlcad jano
(n=point@216.115.228.148) |
06:26.46 |
*** join/#brlcad dtidrow
(n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
06:52.38 |
*** join/#brlcad clock_
(i=clock@84-72-61-117.dclient.hispeed.ch) |
08:07.59 |
*** join/#brlcad clock_
(n=clock@zux221-122-143.adsl.green.ch) |
09:08.57 |
*** join/#brlcad clock_
(n=clock@zux221-122-143.adsl.green.ch) [NETSPLIT
VICTIM] |
09:08.57 |
*** join/#brlcad SWPadnos
(n=Me@emc/developer/SWPadnos) [NETSPLIT VICTIM] |
09:08.57 |
*** join/#brlcad Maloeran
(n=maloeran@195.139.172.210) [NETSPLIT VICTIM] |
12:20.27 |
*** join/#brlcad docelic
(i=docelic@ri01-201.dialin.iskon.hr) |
14:10.23 |
*** join/#brlcad clock_
(n=clock@zux221-122-143.adsl.green.ch) |
17:03.47 |
*** join/#brlcad ibot
(i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
17:17.57 |
*** join/#brlcad clock_
(n=clock@zux221-122-143.adsl.green.ch) [NETSPLIT
VICTIM] |
17:17.57 |
*** join/#brlcad SWPadnos
(n=Me@emc/developer/SWPadnos) [NETSPLIT VICTIM] |
17:17.57 |
*** join/#brlcad Maloeran
(n=maloeran@195.139.172.210) [NETSPLIT VICTIM] |
17:36.49 |
Maloeran |
Hum! If anyone is also a gamer and desires a
PS3 : http://ps3.shimpinomori.net/index_en.html |
19:18.57 |
*** join/#brlcad docelic
(i=docelic@ri01-129.dialin.iskon.hr) |
20:29.20 |
brlcad |
heh |
20:44.16 |
``Erik |
toast burner o.O |
20:45.41 |
brlcad |
and proud of it |
21:07.45 |
*** join/#brlcad lg_
(n=lg_@85.101.21.197) |
21:07.50 |
lg_ |
hi |
21:08.30 |
lg_ |
anyone online? |
21:09.42 |
docelic |
take a guess. |
21:09.59 |
``Erik |
no, we're all off-line, which is why this
channel has no users in it |
21:10.04 |
``Erik |
:) |
21:10.22 |
lg_ |
;-) great, i also have no time and should
sleep now |
21:10.39 |
lg_ |
actually i wanted to ask for a
favour... |
21:13.02 |
lg_ |
i have asked for some info on the new
cpp-interfaces available for brlcad, which should be in rather
active development right now. there is a project forming to create
a kde-based parametric cad app, and as the focus should be on
useability, and the underlying engine could be an external one, the
idea was to build up on brlcad |
21:15.14 |
Maloeran |
If there was anything after "build up on
brlcad", the irc length limit cuts it |
21:15.50 |
lg_ |
no, there should have been a point maybe
;-) |
21:16.58 |
lg_ |
the project name is kreative3d, and there had
been some discussion on the topic among interested people, but i
could not get any insight into how to interface brlcad as an engine
for a cad application written in c++ |
21:18.51 |
Maloeran |
The person holding the 'brlcad' nickname could
guide you on this, any idea what piece of BRL-CAD you are
interested in? It's one huge beast |
21:21.15 |
lg_ |
actually, i thought it should be possible to
write a database layer on top of the geometric objects, making it
extendeable to app-specific objects such as walls, stairs, which
would be generators for brlcad-databases |
21:22.00 |
lg_ |
but there is a point where feedback is
required, i must be able to load a scene, perform csg, view it in a
buffer that must be managed by the cpp-app |
21:23.02 |
lg_ |
if i catch user activity in this frame, e.g.
clicking on a pixel, i have to be able to call brlcad routines to
trace to get the object, e.g. to edit it |
21:23.44 |
Maloeran |
*nods* brlcad is the guy to help there, feel
free to idle around until he wakes up |
21:24.17 |
lg_ |
i see, it is hard with time zones
;-) |
21:24.44 |
lg_ |
(sitting in istanbul, turkey, where it is
23.25 now ;-) |
21:25.02 |
Maloeran |
Metaphorically speaking :), he's in the united
states, 16h25 there |
21:25.49 |
lg_ |
i know ;-) |
21:42.04 |
brlcad |
hello lg_ |
21:42.29 |
lg_ |
hi! |
21:42.43 |
lg_ |
so you woke up, as others predicted
;-) |
21:42.55 |
brlcad |
catching my breath |
21:43.42 |
lg_ |
by the way, my name is lars an i never get
used to these irc-nicks |
21:44.01 |
brlcad |
lg_: so just reading through what you just
wrote, there's a couple considerations |
21:44.07 |
brlcad |
did we talk a couple weeks ago? |
21:44.18 |
brlcad |
or was that someone else? |
21:44.23 |
lg_ |
yes, but that time there was no
kreative3d-group |
21:44.28 |
brlcad |
okay |
21:44.59 |
lg_ |
(which was not invented by me, but i try to
find out if i can suggest them to work on brlcad) |
21:45.37 |
brlcad |
it sounds like a good idea, and will overall
save years of effort really if utilized appropriately |
21:45.53 |
brlcad |
but that isn't to say that it's a trivial
task, and there's work that would need to be done to support
it |
21:46.53 |
lg_ |
yes, i wasn't expecting anything else. but i
guess inventing a new csg would be harder, so IF it is possiblen,
than by adopting to an existing engine |
21:46.59 |
brlcad |
brl-cad is used as a geometry engine, that's
one of it's primary purposes -- creating a robust C++ wrapper over
that engine is a task in itself, nothing too complicated really but
something that's only partiallly completed as is |
21:47.55 |
brlcad |
there is a prototype start of some effort, I
think I mentioned that last time -- and I've actually blocked off
some time tomorrow to work on reviewing what we currently have and
putting it into revision control somewhere so folks can access
it |
21:48.31 |
lg_ |
that would be great, as people could estimate
what it needed to connect to this effort |
21:48.34 |
brlcad |
the bigger issue that I'm sure will impact you
will be .. getting an explicit representation of the geometry, i.e.
getting triangles out so you can stuff it over to opengl |
21:49.24 |
brlcad |
that layer of brl-cad, converting from the
preferred mathematical implicit geometry to an explicit form, needs
work to be more robust frankly at least for "real models" |
21:49.40 |
lg_ |
yes, i wonder if this should be done in a pure
unix-way by using conversion from the .g-database to
meshes |
21:49.57 |
brlcad |
but the other side, e.g. picking and selecting
objects along a ray, is rather trivial stuff -- ray-tracing is
brl-cad's bread and butter |
21:49.59 |
lg_ |
maybe with some caching, it could be possible
to create an atomic cad like this? |
21:50.59 |
lg_ |
yes, i think the point about tracing back and
querying object information is only a question how clean it could
be integrated into cpp, so the wrappers |
21:51.07 |
brlcad |
our existing converters work in a 'unix-way"
g- |
21:51.38 |
brlcad |
but that's not the issue, the issue is an
algorithmic one .. going from implicit to explicit |
21:52.15 |
lg_ |
yes... do you think it is possible to build
graphic output on something like the other mesh converters (g2obj
e.g.)? |
21:52.33 |
brlcad |
there is an interface that exists now for
doing that conversion, wheter it be by a tool-based approach, or
directly calling the same routines that the converters
use |
21:53.00 |
lg_ |
ok, that sounds interesting for the
task |
21:53.02 |
brlcad |
you mean directly connecting the converter as
part of the display process in the app? |
21:53.11 |
lg_ |
yes ;-) |
21:53.14 |
brlcad |
ah |
21:53.17 |
brlcad |
no |
21:53.17 |
brlcad |
:) |
21:53.22 |
brlcad |
that would probably be bad :) |
21:53.42 |
brlcad |
conversions take a long time and are generally
rather error-prone processes |
21:53.56 |
brlcad |
unless you have pristine geometry, which is
rather rare |
21:54.25 |
brlcad |
there are means to fix that.. it "could" be
made more interactive |
21:54.29 |
lg_ |
i know, i actually thought about that by the
means if caching, doing this step only for modified or added
objects |
21:55.02 |
brlcad |
but that would require (re)implementing a mesh
library for brl-cad geometry (which would be a great
task) |
21:55.19 |
brlcad |
ahh, that is possible, and something we've
considered on occassion |
21:55.46 |
lg_ |
i would like to avoid building a fat
app |
21:55.49 |
brlcad |
it would be doable in that situation, though
you're architecting a hack around a suboptimal situation |
21:56.05 |
brlcad |
it's only a little more work to "fix it" so
that it works interactively |
21:56.57 |
brlcad |
apologies on the delay responding.. rather
overloaded with tasks at the moment and support e-mails have been
piling up |
21:57.03 |
lg_ |
what do you mean by mesh library - putting the
conversion code into a lib? |
21:57.11 |
brlcad |
sure |
21:57.16 |
lg_ |
;-) no problem, i am asking for help |
21:58.58 |
brlcad |
all the mesh library would really entail is
taking the in-memory brl-cad form, and generating the polygons from
the data |
21:59.21 |
brlcad |
it's trivial to get polygons for each
primitive, and brl-cad supports that rather easily .. the work is
in performing the CSG boolean evaluations |
21:59.42 |
lg_ |
hm, so the big task would be to divide the
meshing and conversion, and than write an app that loads the mesh -
than we could just call rt to query objects and set up on a cpp
wrapper for modifying the database. |
22:00.22 |
lg_ |
sounds more like a problem with code structure
in brlcad for this use than too much algorithm stuff? |
22:00.24 |
brlcad |
you can either perform that directly on the
implicits (via ray-tracing), on triangles to triangles (which an
implementation of exists in brl-cad), or on splines to triangles
(which doesn't exist functionally yet) |
22:00.42 |
brlcad |
if you can do the meshing, you've got a
conversion |
22:00.47 |
brlcad |
they're the same problem |
22:01.13 |
brlcad |
if you have a mesh or if you don't, brl-cad
can still query the geometry fast enough for picking/info
purposes |
22:02.08 |
lg_ |
yes, but as i understand the meshing code
exists and is functional, e.g. in g2obj, just had to be cleanly
seperated into libs? |
22:03.26 |
brlcad |
lg_: the problem is with the overall design
purpose and approach.. brl-cad's library was written to be
numerically sound and robust to represent/evaluate first (which is
where implicit geometry comes to play), not for pretty opengl
display (which requires explicit geometry) |
22:04.00 |
brlcad |
that said, we have a mutual need -- everyone
wants pretty opengl displays these days ;) |
22:04.33 |
lg_ |
;-) what is about the opengl dm, how much
useable is the code used there? |
22:04.50 |
brlcad |
the meshing code exists in several forms and
is functional .. but could certainly be improved, and in well
defined ways |
22:05.41 |
brlcad |
the opengl dm in brl-cad isn't really
relevant/useful to this purpose |
22:07.05 |
lg_ |
i see. maybe it would be worth to test the
concept by writing a dummy app? |
22:07.30 |
lg_ |
than people could laugh about it or build
something serious on the idea |
22:08.09 |
brlcad |
basically what I'd suggest is to consider what
exactly it is that you're wanting from the engine -- if you're
actually writing a "CAD" system, there are fundamental design
considerations that should be taken into account |
22:08.52 |
brlcad |
in that regard, brl-cad will certainly be a
given to use, solid modeling is not something any new project is
going to be able to jump into without many years of invested
effort |
22:10.10 |
brlcad |
which is basically saying that there is a lot
provided in brl-cad that you'd be getting for free, even though
more work is likely going to be required to get wherre you
want |
22:10.20 |
brlcad |
namely work on the c++ interface and the
meshing interface |
22:11.04 |
brlcad |
collaboration there would certainly be a very
good thing -- it's also something on our task plate (both of them)
over the next upcoming year for the project |
22:11.37 |
lg_ |
yes, that is what i got. i think getting a
view of what exists now will be great, and than people can consider
what they can and want to do. |
22:12.39 |
brlcad |
I just recently put together a presentation
that I can send to you that describes brl-cad in a
nutshell |
22:13.02 |
brlcad |
it's rather high-level, so I' |
22:13.07 |
lg_ |
the point is that the folks behind the project
i mentioned are mainly from gui. and that is a big part of what is
missing to make brlcad useable for some applications. if you send
me the description, it might motivate folks to jump on the
project |
22:13.27 |
brlcad |
so I'm not sure how interesting it'll be to
you, but it might at least give you an idea where things are and
where they may be going |
22:14.01 |
lg_ |
i think especially to see where development
takes place is very valuable now |
22:14.20 |
brlcad |
yeah, I completely agree with respect to
brl-cad's gui.. that's our own #1 issue being worked on actually,
and the reason for the new solid modeler under development (that I
suppose would technically be a competitor to kreative3d)
;) |
22:14.37 |
brlcad |
btw, doesn't creative labs have a tool called
kreative3d?? |
22:15.10 |
lg_ |
i don't hope so, but it is worth to look
for. |
22:15.59 |
brlcad |
i vaguely recall some product .. it was either
the sound card folks or maybe.. maybe bryce or something |
22:16.15 |
lg_ |
but i think that the difference of the
modelers as i think it is that i would like to see it not so much
as a pure geometry modeler, which might be your goal,
right? |
22:16.43 |
lg_ |
(when the project starts to produce things,
the name has to be checked!) |
22:17.00 |
brlcad |
maybe just confusing product names.. rather
generic terms with a K sound :) |
22:17.23 |
lg_ |
yes, it is not that new, that idea |
22:17.41 |
brlcad |
not sure what you mean by a pure geometry
modeler |
22:18.20 |
brlcad |
as for whether our scope is limited to a solid
geometry modeler, then initially yes |
22:18.50 |
brlcad |
though the demand is so large for drafting,
that it's also on the development plan but hopefully from
contributors that get interested |
22:18.51 |
lg_ |
i think you want to create geometry. i am
thinking about a layer, where the user actually creates a wall, and
that wall object is translated into (brlcad) csg
instructions |
22:19.26 |
lg_ |
so maybe not all of brlcads features is
used |
22:19.39 |
brlcad |
undoubtedly |
22:19.46 |
brlcad |
brl-cad does more than csg too ;) |
22:20.16 |
brlcad |
(geometry representation-wise) |
22:20.33 |
lg_ |
i thought about a modeler doing something as
the generator tools brlcad includes |
22:21.02 |
brlcad |
huh? parse error on that sentance :) |
22:21.31 |
brlcad |
"generator tools brlcad includes" |
22:22.21 |
lg_ |
i would actually save the wall objects as a
scripts generating brlcad geometry (there is a wall generator in
brlcad e.g., which simply outputs a .g database) |
22:22.23 |
brlcad |
ooh, maybe s/as the/with/ |
22:22.37 |
brlcad |
gotcha |
22:22.58 |
brlcad |
that's procedural geometry |
22:23.43 |
lg_ |
yes. but the generator would have to be able
to e.g. provide an opening when a window object requests
it |
22:24.55 |
brlcad |
sure, that's just a term for geometry that is
created procedurally and generally automatically according to some
defined interface process |
22:25.13 |
brlcad |
you could have a procedural geometry generator
for just about anything |
22:26.47 |
lg_ |
and i would do it in a way that the wall
object not only creates geometry, but would have a set of
procedures defined to e.g. cut holes. than this object would create
the brlcad calls |
22:29.45 |
brlcad |
so, I'll see if I can get through the c++
interface review tomorrow, and hopefully more progress on it over
the weekend so it can be put into svn |
22:30.03 |
brlcad |
did you want that high-level
overview? |
22:30.44 |
lg_ |
yes, would be great |
22:31.21 |
brlcad |
okay, I should have that out to you tomorrow
at the latest |
22:31.43 |
lg_ |
(i do not want you to hurry that much, if it
is in the next days, it would be great!) |
22:32.12 |
lg_ |
should i give you my mail? |
22:32.21 |
brlcad |
not any trouble, I've been working on it over
the past couple days, just have to take out a few things that
aren't yet releasable |
22:36.54 |
lg_ |
as i already mentioned, i am a victim of time
zones, it is past midnight here. so i would really like to thank
you for tonight and switch to sleep mode ;-) |
22:38.57 |
lg_ |
i will be on the net on week-end |
22:41.11 |
lg_ |
good night (i know most of you have some more
hours of daylight before ;-) |
22:43.35 |
lg_ |
|-) |
22:43.45 |
*** part/#brlcad lg_
(n=lg_@85.101.21.197) |