irclog2html for #brlcad on 20061130

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)

Generated by irclog2html.pl by Jeff Waugh - find it at freshmeat.net! Modified by Tim Riker to work with blootbot logs, split per channel, etc.