| 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) |