| 00:33.54 | Maloeran | Erik or brlcad, I have a strange design question as this code will end up in BRL-CAD and it should be consistent with the practices there. For network distributed processing, is it be acceptable for slave nodes to "blindly" trust all communication from their master node? |
| 00:34.44 | Maloeran | Or should it be robust, checking and validating all messages for coherency to maintain an usable, normal state? |
| 00:35.39 | Maloeran | I don't expect it would normally matter, unless you distribute processing between trusted and non-trusted boxes, or non-trusted entities forwarding packets |
| 00:36.35 | ``Erik | off the cuff, I would imagine that trusting netowrk traffic would be sufficient... I can doublecheck on monday or tuesday... send me an email <erikg@arl.army.mil> to remind me :) |
| 00:37.47 | Maloeran | Okay, some stuff would just be a bit complex or costly to "validate" for correctness... |
| 00:38.39 | Maloeran | I'm not saying faulty input would cause buffer overruns allowing to run any code on slave nodes, but at the moment, it could get them to segfault or be stuck in infinite loops |
| 01:26.39 | brlcad | Maloeran: in general, I believe there can be an assertion of trust for network-distributed processing is fine (otherwise someone would have already mentioned something) |
| 01:27.39 | brlcad | it should, however, probably still be reliable and robust -- some reasonable due-diligence to make sure things don't fall apart if someone just wiggles a network cable, for example |
| 01:29.08 | brlcad | i.e. you probably don't have to worry about *malicious* code and attacks, but you should be robust under normal operation that things work smoothly and fail in a non-catastrophic manner if they have to fail |
| 01:41.23 | Maloeran | Right, understandably so. As an example, if a master node supplies broken graphs to slave nodes, it wouldn't be easy for them to detect that their rays are going to get stuck in infinite loops |
| 01:43.59 | Maloeran | Thanks, it should be stable under cable wiggling and so on |
| 01:45.10 | brlcad | although getting stuck in an infinite loop would be a catastophic failure, about as useful as crashing |
| 01:45.37 | Maloeran | That's difficult to prevent if the slave nodes do receive faulty, tempered data |
| 01:45.53 | Maloeran | ( i.e. not in any normal circumstances ) |
| 01:45.58 | brlcad | how would they potentially receive faulty data? |
| 01:46.08 | brlcad | other than abuse |
| 01:46.33 | Maloeran | It shouldn't normally happen, hence why I was asking if I can trust the network |
| 01:47.38 | brlcad | which depends on several things.. I trust that when I send a tcp packet that it will eventually arrive, I don't have even that same trust on udp of course |
| 01:48.39 | brlcad | you can trust that you don't have to worry about malicious abuse, packets getting modified on the way, interceptions |
| 01:49.33 | Maloeran | All right, thanks |
| 01:51.05 | brlcad | but not that connectivity will be sustained, that you can loose a connection at *any* point (and how reliably you deal with the fault is a question, but generally some sort of handling even if to just abort()) |
| 01:51.31 | brlcad | whether or not you have to protect against yourself, i.e. bugs in your client code, is a question for yourself :) |
| 01:52.02 | Maloeran | I know that :). Clients can at any time connect and disconnect from their master, smoothly or brutally |
| 01:52.20 | Maloeran | Clients can join up while work is being done, have their state synchronized and start shooting rays |
| 01:53.00 | brlcad | you rolled your own networking? |
| 01:53.45 | brlcad | er, sry jargon -- s/rolled/wrote/ |
| 01:54.08 | Maloeran | It's a low-level interface made of in/out buffers supplied by the user, it can be using tcp, mpi, infiniband, etc. |
| 01:55.04 | brlcad | i mean you wrote your own listen(), select(), read(), etc code or is it all over MPI or a mix or some other interface? |
| 01:55.07 | Maloeran | And the user inserts its own messages within the stream for distribution of raytracing work, so that high-level results can be transfered between nodes instead of large low-level ray intersection results |
| 01:55.44 | brlcad | you're already higher level than I'm asking |
| 01:56.22 | Maloeran | It's meant to work with any communication protocol really, it doesn't fundamentally care about that. There's only an user-supplied networking interface for tcp at the moment |
| 01:56.46 | brlcad | uhm "user-supplied"? |
| 01:56.53 | brlcad | i have to write socket code to use it? :) |
| 01:57.10 | Maloeran | Yes, I mean it's not part of the raytracing library itself :) |
| 01:57.32 | Maloeran | I'll write other interfaces later on |
| 01:57.38 | brlcad | that's actually probably a good thing |
| 01:57.41 | brlcad | a very good thing |
| 01:58.19 | brlcad | brl-cad already has a sufficiently robust network library that is preferred for most client/server applications |
| 01:58.27 | brlcad | (libpkg) |
| 01:58.57 | Maloeran | Great then |
| 02:00.24 | brlcad | i was wondering just because if you had only rolled your own.. i've *yet* to see someone write their own socket code that was truely fault tolerant even under "normal use" (without just aborting on every little abnormality) |
| 02:00.34 | brlcad | at least with respect to writing basic tcp/ip networking code |
| 02:01.05 | Maloeran | I think I have done that long ago, I once wrote some client-based and browser-based game that was in itself a http server written from scrach |
| 02:01.44 | Maloeran | *Perhaps* less portable than your libpkg though :) |
| 02:03.07 | brlcad | just about everyone's written client server apps and most work reasonably well all the time -- but not necessarily truely fault tolerant; i'd say it's even harder than writing portable code that works with any compiler |
| 02:03.24 | brlcad | libpkg is pretty robust, but it's not even 100% |
| 02:04.11 | Maloeran | I don't entirely see what you mean by "fault tolerant", but the code didn't encounter any "fault" it wasn't handling running for two years |
| 02:04.18 | brlcad | portability is usually where things fall apart.. some assumption that worked on linux, that doesn't do a darn thing when running under hpux or bsd or solaris, etc |
| 02:04.44 | brlcad | the code in a specific environment didn't have a fault -- put it in a different environment.. let the fun begin :) |
| 02:04.44 | Maloeran | Networking fault tolerance seems rather simple to me, though I may be mistaken |
| 02:05.01 | Maloeran | Oh, well that :). Okay, that code of mine is strictly Linux >= 2.4 |
| 02:05.11 | brlcad | if you assume standards compliance and a standard networking api it is easier |
| 02:05.36 | brlcad | rather trivial actually |
| 02:06.01 | Maloeran | I'm guessing libpkg supports mpi and infiniband? |
| 02:08.03 | Maloeran | It doesn't appear to, actually |
| 02:08.07 | brlcad | it's focus is very specific to client/server applications as a direct package transport layer -- basically at the same level of mpi, not higher |
| 02:08.46 | Maloeran | I see TCP stuff, do you have support for infiniband? |
| 02:10.29 | brlcad | not specifically, it's not been used over infiniband afaik -- though i'm not sure there's anything that would preclude it from working |
| 02:11.13 | Maloeran | There doesn't seem to be support for fbsd's kqueue() or Linux's epoll() either... |
| 02:11.47 | Maloeran | I guess it's very robust at what it does, perhaps not geared towards peak performance |
| 02:12.02 | brlcad | yep, and nope |
| 02:12.23 | brlcad | predates most of those anyways |
| 02:13.56 | Maloeran | Thanks for the pointer, I'll look into it more in details once I'm ready to move on from tcp |
| 02:14.57 | brlcad | np |
| 02:15.49 | brlcad | it's not meant to be fancy or the fastest, but it is extensively portable and the behavior is pretty robust for what it was designed to do |
| 02:16.30 | brlcad | there's src/libpkg/tpkg.c that basically implements ttcp client and server all in one |
| 02:16.37 | brlcad | as an example |
| 02:18.58 | Maloeran | *nods* I'll have to dig a bit more to find non-blocking I/O |
| 02:28.35 | Maloeran | There sure is much copying and internal dynamic allocation in there |
| 02:32.37 | brlcad | we did already clarify that it's purpose is a robust simple api, not performance already, didn't we? that said the performance is almost always dwarfed by the network transport or application code itself |
| 02:32.59 | brlcad | that is, i've yet to see it actually be a bottleneck concern worth optimizing |
| 02:37.24 | brlcad | buffer allocation could certainly be improved, but it's still not something I'd even consider thinking about until the bottleneck or some profile showed it to be an issue |
| 02:42.12 | ``Erik | hrmph |
| 02:42.21 | ``Erik | it may be starting the obvious.. |
| 02:43.05 | ``Erik | but tcp guarantees packets get to the target.. whole... |
| 02:43.13 | ``Erik | udp makes no such assumptions |
| 02:43.35 | ``Erik | so if you want udp transmitted data to be verifiable, you must do it yourself... |
| 02:45.50 | ``Erik | mal: I've started wiring up a program to do brlcad vs adrt vs rayforce cmparisons... correctness and performance... I'm hoping that sometime next week, I'll have softare working with adrt and librt... and hopefull very soon after, permission to give you a copy |
| 02:46.10 | ``Erik | excuse my kbd mistakes... whiskey has been involved. O.o |
| 02:46.44 | ``Erik | (well more than that night in salt lake city. *cough*) |
| 03:06.53 | brlcad | ``Erik: that was part of the point (regarding assumptions) |
| 03:07.25 | brlcad | and yeah, was quite stating the obvious :) |
| 03:49.50 | *** join/#brlcad IriX64 (n=IriX64@bas3-sudbury98-1168050744.dsl.bell.ca) |
| 05:09.00 | Twingy | brlcad, yes |
| 05:20.33 | Maloeran | Great Erik, let me know how it goes, if you need some specific demo coded for benchmarking |
| 05:22.51 | Maloeran | brlcad, that's surely right. I'm well aware that I over-optimize and see inefficiencies everywhere |
| 05:46.41 | Maloeran | Erik, if correctness is "low", we can turn off automatic vector generation and a couple other things to improve that point ; just tell me so if it appears to be an issue |
| 06:56.53 | *** join/#brlcad clock_ (i=clock@84-72-62-129.dclient.hispeed.ch) |
| 13:36.12 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/misc/ (.cvsignore Makefile.am): clean up after py-compile |
| 13:36.26 | *** join/#brlcad KeenEars (n=opera@eat.ssau.ru) |
| 13:40.17 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/adrt/scripts/adrt.py: trailing newline |
| 13:41.16 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/regress/main.sh: trailing newline |
| 13:42.23 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/facetall.sh: trailing newline |
| 13:43.56 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/gtools/g_qa.1: trailing newline |
| 13:44.34 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/liborle/.cvsignore: trailing newline |
| 13:48.07 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/rtwizard/examples/ (6 files in 6 dirs): trailing newline cleanup |
| 13:51.53 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/util/rtwizard: standard header and footer |
| 13:53.32 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/ (src/vas4/.cvsignore src/vdeck/.cvsignore TODO): trailing newline |
| 13:57.57 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/ (26 files): update copyright to 2007 |
| 14:07.47 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/header.sh: |
| 14:07.47 | CIA-5 | BRL-CAD: Remove the carte blanche statement that allowed selection of the license at |
| 14:07.47 | CIA-5 | BRL-CAD: user's discretion and GNU's provision. If there's motivation to change the |
| 14:07.47 | CIA-5 | BRL-CAD: license, even to a new version, it will need to be a conscious effort and |
| 14:07.47 | CIA-5 | BRL-CAD: decision. |
| 14:08.07 | *** join/#brlcad clock_ (i=clock@84-72-93-149.dclient.hispeed.ch) |
| 14:11.11 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/ (Makefile.am COPYING autogen.sh configure.ac): update copyright to 2007 |
| 14:11.59 | ``Erik | O.o |
| 14:12.58 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/COPYING: copyright statement only relevant to current year in the example |
| 14:13.13 | brlcad | no, i'm not doing them one at a time |
| 14:13.23 | ``Erik | find . -type f | xargs sed -E -i.bak 's/[ \t]+$//' |
| 14:13.26 | ``Erik | o.O |
| 14:13.39 | ``Erik | (if you're on a decent os... I don't think linux can do that) |
| 14:14.16 | brlcad | yeah, there was a script that did that sort of cleanup too |
| 14:14.29 | brlcad | a whole category of things like that |
| 14:14.47 | ``Erik | <-- would've expected to see something like "brlcad/ (897 files in 47 dirs): trailing newline" out of cia |
| 14:15.00 | brlcad | nah, there was only the handful |
| 14:15.11 | ``Erik | hehehe |
| 14:15.23 | brlcad | the copyright script reports them, so I was cleaning up while it churned |
| 14:15.30 | ``Erik | it made a LOT of cvs report noise when I did that to openal a few years back |
| 14:15.43 | ``Erik | too many vc++ coders touching the repo, I guess |
| 14:16.05 | brlcad | did most of that cleanup before we went open source |
| 14:16.08 | ``Erik | or, 'ide' coders, rather... the disease has spread |
| 14:16.17 | brlcad | (since that's when the copyright script was written) |
| 14:16.44 | brlcad | those are basically the ones that were crept in since last year |
| 14:16.59 | brlcad | lee and bob mostly |
| 14:17.09 | ``Erik | bobs in windows land |
| 14:17.18 | brlcad | yeah, I don't know what lee's excuse is :) |
| 14:17.19 | ``Erik | want I should break lees pinky next I see him? ;) |
| 14:21.11 | ``Erik | and you'd be surprised how many "software developers" don't grok the assertations made by tcp and udp and the fundamental differences o.O it's sad... (but they're the same coders who don't even put udp, much less rdp on the table when making design decisions) |
| 14:22.43 | ``Erik | Maloeran: I'm going to get librt and adrt/libtie working in this framework, and it has stubs for rayforce... once it works and goes through the formal release process, you'll have 4 or 5 functions to fill out to get rayforce linked and operating. I'm doing the heavy lifting, you just have to wire your engine into it :D |
| 14:24.31 | brlcad | yeah, I usually have to explain to some dev on bz a couple times a year about how there assumption that packet X arriving before Y (or at all) is a bad assertion to make |
| 14:24.58 | brlcad | surprisingly even happens with some of the more experienced coders, and they'll make the assumption repeatedly |
| 14:27.46 | brlcad | problem more stems from the fact that they do happen to see the behavior of ordering and delivery 99% of the time, if not better, so they often try to blame routers and other crap when it doesn't get there in some order or at all -- and the problems usually only rear their head when it's pushed out to users (where that 1% or 0.1% ends up being dozens/hundreds of bug reports) |
| 14:28.03 | ``Erik | bz is a udp protocol? |
| 14:28.09 | ``Erik | (I doubt rdp) |
| 14:28.41 | ``Erik | in a perfect world, udp is reliable and delivers packets in order... the real world isn't perfect *shrug* |
| 14:28.50 | brlcad | it uses a mix of udp and tcp, depending on whather the packet requires a delivery guarantee |
| 14:29.07 | ``Erik | reponsiveness is probably also a major que |
| 14:29.33 | ``Erik | if you lose a tcp packet, it has to stop the stream and re-request the lost packet... then rebuild it in stream order before you can read() it |
| 14:29.36 | brlcad | yeah, tcp is a pig, rather unplayable if that's all you used |
| 14:30.14 | brlcad | there's an option to make all packets tcp only, and you basically have to be on the local net |
| 14:30.25 | brlcad | otherwise lag is too unbearable with just a couple players |
| 14:30.31 | ``Erik | which results in hitching... sorta similar to shoddy gc (naive stop©, mark&sweep)... infrequent halts |
| 14:31.36 | brlcad | so it's a mix, things like posiition updates (which can be a couple dozen per second per player) are sent udp while things like player spawns and shot starts are tcp |
| 14:32.15 | brlcad | doesn't really matter if you miss an update to some tanks' position, there are going to be many more following -- but i fyou missed notification that they fired a shot.. that could be bad |
| 14:32.47 | ``Erik | oh, btw... the python crap I did yesterday... works dandy on linux and fbsd... not so much using the preinstalled python on a mac (they dont' have the .a file, rhel ONLY has the .a, ...) I think I'm at the point of not caring... I'm only doing it to support this rayforce vs adrt (in an s2 like environment) app, and osX isn't high on the list of concerns :/ |
| 14:33.24 | ``Erik | so if you get really bored and want python linked in on osX, ... I'll let ya take care of that... otherwise, adrt is still "not officially supported" I guess |
| 14:33.49 | ``Erik | does bz do the quack style "delta delta delta key" type thing? |
| 14:33.51 | brlcad | hey, the checks are in there.. if it can autodetect, so be it .. if it still can't so be it :) |
| 14:34.08 | ``Erik | it had detects for the python interpreter executable |
| 14:34.19 | brlcad | right, still does |
| 14:34.25 | brlcad | they're just inside the macro |
| 14:34.55 | ``Erik | finding the libraries and headers was not searched, justin hardwired it for python 2.4 installed normally to /usr/local (fbsd style), so that's what I was working around yesterday... it can now cope with python 2.5, python 2.2 on linux (/usr), ... |
| 14:35.10 | brlcad | yep |
| 14:35.19 | brlcad | i've had that mess he left in the back of my mind all year |
| 14:35.37 | ``Erik | wow, my english is worse than a java devers code |
| 14:36.09 | ``Erik | aaanyhow, I have a mission to complete, I'm just fixing enough to complete it. |
| 14:36.22 | brlcad | shame really, most folks would really really like to use isst if it just worked out of the box and you could, oh say, pass it a.g file and have it display |
| 14:36.43 | ``Erik | heh, yeah |
| 14:37.23 | brlcad | as it is, you have to fuss with the compile, fuss with a conversion, fuss with a config, fuss with running it (probably the easiest aspect) |
| 14:37.26 | ``Erik | if we had reliable tesselation, burning some space to have .g files with both csg and triangles would be awful attractive |
| 14:38.00 | ``Erik | or fast tesselation *shrug* |
| 14:38.01 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/ (1675 files in 81 dirs): update copyright to 2007 |
| 14:38.20 | brlcad | openNURBS might actually help there |
| 14:38.44 | brlcad | it seems to include most of the functionality to handle NMG processing |
| 14:38.47 | ``Erik | hrmmmm, |
| 14:39.06 | brlcad | whether it works or not, or how well or how fast is another question altogether of course |
| 14:39.17 | ``Erik | so having primitive/csg geometry and tnurbs in the file? then tesselate the tnurbs? |
| 14:39.18 | brlcad | because on paper, librt's nmg stuff does everything too |
| 14:39.34 | brlcad | just not robust |
| 14:39.42 | brlcad | yeah, something like that |
| 14:39.48 | ``Erik | hehehe, yeah, curley brackets and dropped regions out the wazoo, yes |
| 14:39.58 | brlcad | more of a dual representation where the primitives/csg would be stored on disk |
| 14:40.23 | brlcad | trimmed nurbs or some more generic brep form would just be another primitive as usual |
| 14:40.26 | ``Erik | my uneducated gut feeling is that csg->tnurb might be necessarily expensive |
| 14:40.46 | brlcad | but each primitive would have the (dual-rep) capability of describing itself as a brep spline surface |
| 14:41.08 | brlcad | then we just need a means to evaluate arbitrary csg on brep spline to spline surfaces |
| 14:41.10 | ``Erik | and when ya measure time vs space, disk space is pretty damn cheap |
| 14:42.10 | brlcad | csg->csg tnurb would be practically immediate, eval'd tnurb->facets is also nearly immediate |
| 14:42.19 | brlcad | evaluating the csg is what takes time |
| 14:42.51 | ``Erik | ok, I'm assuming that the represented tnurb geometry is post csg... no overlaps |
| 14:42.53 | brlcad | i.e. going from csg tnurb->eval'd tnurb (or what we presently do with csg->facets) |
| 14:43.09 | brlcad | you can have before or after, without overlaps |
| 14:43.41 | brlcad | just a matter of how do you carve up those spline surfaces, make new surfaces, so you can get rid of the booleans |
| 14:44.11 | ``Erik | yeah, my mind was already on the assumption that if you want to deal with tnurbs, you want to deal with the post-csg tnurbs, so you'd want to cache those to disk |
| 14:44.12 | brlcad | that'll be the hardest part, but it's not intractable .. you're only dealing with one surface/object type |
| 14:44.39 | brlcad | if they can't be evaluated on the fly, you would want to cache them to disk regardless |
| 14:44.52 | brlcad | along with the facets even potentially |
| 14:45.12 | brlcad | depends just how fast those two steps take |
| 14:45.43 | brlcad | other cad systems seem to be able to do both on the fly |
| 14:45.57 | brlcad | i.e. within a second or two with moderately complex parts |
| 14:46.14 | brlcad | that's more than reasonable if we can get that far |
| 14:48.57 | ``Erik | I'm under the impression that we like to load entire complex systems up when other cad systems are severely limited in how much they can have in memory at any given time |
| 14:50.43 | ``Erik | are files being explicitely skipped in your copyright update script? |
| 14:51.21 | brlcad | yes |
| 14:53.42 | brlcad | there are a lot of files we don't have the copyright on to be changing |
| 14:54.11 | brlcad | you have an example of something not updated that should have? |
| 14:54.13 | ``Erik | ah, I found several that have "United States Government" as the copyright holder |
| 14:55.20 | ``Erik | lemme clean things up a little and commit these... |
| 14:55.27 | ``Erik | then you'll see which ones in the email or whatever |
| 14:56.09 | brlcad | yeah, on a quick glance, I see it missed at least 90 for some reason |
| 14:57.11 | brlcad | and the list i'm looking at, there's a reason on most of them .. like missing headers |
| 14:57.43 | CIA-5 | BRL-CAD: 03erikgreenwald * 10brlcad/sh/header.sh: use dates formatting to extract the year instead of awk... |
| 14:58.40 | brlcad | sh/copyright.sh is what updates |
| 14:59.45 | CIA-5 | BRL-CAD: 03erikgreenwald * 10brlcad/ (6 files in 5 dirs): update copyright to 2007 |
| 14:59.50 | ``Erik | misc/macosx/Resources/License.rtf misc/win32-msvc/vers.vbs misc/win32-msvc/Dll/TclDummies.c misc/win32-msvc/Dll/brlcad.rc src/gtools/g_qa.1 |
| 15:00.35 | brlcad | ahh yeah, it specifically ignores misc |
| 15:00.59 | *** part/#brlcad KeenEars (n=opera@eat.ssau.ru) |
| 15:01.43 | brlcad | should probably add misc though and just exclude the known 3rd party |
| 15:06.14 | ``Erik | interesting that it missed g_qa.1 |
| 15:06.26 | brlcad | yeah, implies something is wrong in the file |
| 15:09.59 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/misc/win32-msvc/Dll/brlcad.rc: copyright on the whole starts back in 1984 |
| 15:11.03 | brlcad | vers.vbs is that vb script I was talking about |
| 15:11.25 | brlcad | just need similar ones for the other scripting activities the build process assumes |
| 15:16.37 | ``Erik | *nod* |
| 15:23.25 | ``Erik | should do just fine, provided the semantics of the file aren't corrupted... |
| 15:24.09 | ``Erik | file that says "this data is at offset X" and change the character count.. |
| 15:24.36 | brlcad | hmm, extended regex foo too, something like \(([cC])|?\) |
| 15:25.45 | ``Erik | that depends on the breed of sed |
| 15:25.50 | ``Erik | the sed in fbsd supports it |
| 15:26.03 | ``Erik | I'd be surprised if the one in irix does... not sure on leenewx |
| 15:26.08 | ``Erik | sed -E |
| 15:26.39 | brlcad | don't really care about portability, this is once a year :) |
| 15:26.52 | brlcad | i think i can find a bsd or linux box at least once a year |
| 15:27.01 | ``Erik | aight *shrug* |
| 15:27.13 | ``Erik | gnu sed does NOT do extended (or 'modern' regex) |
| 15:27.55 | ``Erik | might do a test to verify that sed -E behaves like you expect it to behave and exit with an error if it doesn't, just in case someone else tries it or ya forget :D |
| 15:29.28 | brlcad | trying to see if the match works at all for starters |
| 15:29.40 | brlcad | or I can just fix the one use of that blasted character |
| 15:32.28 | ``Erik | heh, © |
| 15:32.39 | ``Erik | option+g, amusing |
| 15:37.19 | brlcad | ah, even better, just allow for an optional character |
| 15:43.55 | brlcad | woot, that'll do |
| 15:48.09 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/copyright.sh: |
| 15:48.09 | CIA-5 | BRL-CAD: add support to detect/convert \a9 copyright symbols, convert them to (c) for |
| 15:48.09 | CIA-5 | BRL-CAD: consistency just like everything else. also, more importantly, add the ability |
| 15:48.09 | CIA-5 | BRL-CAD: to use this script to process individual files (e.g. in conjunction with find). |
| 15:48.09 | CIA-5 | BRL-CAD: if there's an argument list, that is what will be processed. otherwise, it will |
| 15:48.11 | CIA-5 | BRL-CAD: do the usual task of processing everything under the src root that it recognizes |
| 15:48.13 | CIA-5 | BRL-CAD: (and that isn't exempted). |
| 16:01.33 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/doc/html/manuals/mged/ (cup.sh Makefile.am mged.html mged1.html cup): it's a shell script, so call it cup.sh instead for consistency |
| 16:02.27 | ``Erik | what about the generated scripts? like, uhhh, brlman/awf |
| 16:03.24 | brlcad | those are installed commands where the fact that they're shell scripts is just an implementation detail |
| 16:03.43 | brlcad | plus that was just a doc script |
| 16:04.58 | brlcad | most of the installed user-scripts are unsuffixed, brlman/awf/benchmark/archer/rtwizard |
| 16:09.32 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/copyright.sh: oop, the dotfiles thing caused automatic to go all empty list crazy. remove that contraint, but add a slew of other exemptions of stuff it should be able to safely ignore |
| 17:51.55 | Maloeran | ``Erik, about these 4-5 functions to fill up for a rayforce interface, I hope I can expect these to be friendly with processing of rays in batches and the concept of ray sources? |
| 17:57.17 | ``Erik | um |
| 17:57.21 | ``Erik | unfortunately, not very |
| 17:58.19 | Maloeran | Look, the rayforce interface is somewhat peculiar and it has to be used intelligently to provide good performance |
| 17:58.31 | ``Erik | extern RtTrace* rt_shoot (RtGeometry *geom, RtHandle hp); |
| 17:58.31 | ``Erik | extern double rt_getsize (RtGeometry *g); |
| 17:58.31 | ``Erik | extern bool rt_getbox (RtGeometry *g, VmVect *min, VmVect *max); |
| 17:58.31 | ``Erik | extern RtGeometry* rt_constructor (RtGeomInfo *info, int info_needed, NmPool *comp_names); |
| 17:58.38 | Maloeran | It's quite flexible, but one has to understand and consider how it works |
| 17:59.12 | ``Erik | RtHandle holds exactly 1 ray |
| 17:59.23 | Maloeran | That is very, very bad. |
| 17:59.28 | ``Erik | obviously |
| 17:59.39 | ``Erik | I'll talk to lee about adjusting the interface |
| 18:00.06 | ``Erik | this is the interface ripped almost directly from the "target app" |
| 18:00.19 | Maloeran | Please consider the concept of shooting many rays from a single point. Failing that, consider "displacements" from a fixed origin for the bundle of rays |
| 18:00.23 | ``Erik | if we can unstupid THEIR code, life is grand... but it's not mine to fix... |
| 18:00.26 | Maloeran | The smallest the displacements, the better |
| 18:00.37 | ``Erik | the normal vehicle of behavior is orthographic |
| 18:00.53 | ``Erik | with randomly scattered secondaries |
| 18:01.45 | Maloeran | All right, are the secondary rays traced from the intersection points of previous rays? |
| 18:02.07 | ``Erik | but it's all good, adrt assumes perspective projection and bundles for performance, and you are competing on level ground |
| 18:02.25 | ``Erik | ummmm |
| 18:02.28 | ``Erik | I'm not sure |
| 18:02.45 | ``Erik | I *THINK* they assume either the 'entry' or 'exit' point of a "solid" part |
| 18:03.05 | Maloeran | Typical example : ray sources, from which to shoot secondary rays, can be updated to match the intersection points of primary rays |
| 18:03.07 | ``Erik | and in behavior, it's very similar to shooting, y'know, a few hundred scattered refraction rays |
| 18:03.38 | ``Erik | the secondaries are emitted from an origin on the primary ray. the direction is generally in a similar direction. |
| 18:03.40 | Maloeran | Updating ray sources at intersection points would be a lot faster than resolving origins for secondary rays constantly |
| 18:03.46 | ``Erik | I d'no if it's safe to say any more |
| 18:04.18 | ``Erik | and I'm under the impression that the 'target' app will be incredibly naïve |
| 18:04.44 | ``Erik | but it's ok, this program I'm writing will be the thing used to prove the letter of the contract |
| 18:05.03 | ``Erik | if THEY choose to use your software stupidly |
| 18:05.05 | ``Erik | that's all ok |
| 18:05.25 | ``Erik | allz ya gotta do is the 5x adrt bit, and we have a little wiggle room to prove or disprove that |
| 18:05.26 | ``Erik | :) |
| 18:05.29 | Maloeran | I don't know if it's going to be 5 times faster if it's constrained within such a poor interface |
| 18:05.58 | ``Erik | if we can make the argument that the interface makes it impossible, but an alternate interface fixes it, we can go that route, I guess *shrug* I d'no |
| 18:08.20 | Maloeran | No ray bundling, no intelligent management of ray sources and displacements, no SSE ; it's going to crawl :) |
| 18:08.45 | Maloeran | Anyhow, we can try. |
| 18:11.29 | Maloeran | If you are going to shoot one ray at a time, at least make it rely on a callback so I can buffer up and process in batches |
| 18:11.57 | Maloeran | And the library manages threading internally, all calls should come from the same thread |
| 18:12.43 | Maloeran | ( Unless we quickly make a fix for a public blocking non-threading one-ray-at-a-time function, most inefficient ) |
| 18:14.21 | ``Erik | hopefully I'll have it functioning in a form next week |
| 18:14.39 | ``Erik | which will take maybe another week to push through the dreaded "form 1" process |
| 18:14.41 | ``Erik | to get you the code |
| 18:14.50 | ``Erik | just givin' ya a heads up :) |
| 18:15.36 | Maloeran | Or I could still write the interface without access to your code |
| 18:16.07 | ``Erik | you need teh structs |
| 18:16.19 | ``Erik | and those have to be cleared, since they're from a non-distributable source |
| 18:16.53 | Maloeran | Highly sensitive structs, eh? :) All right |
| 18:17.51 | ``Erik | I think I've appropriately cleaned them up |
| 18:18.07 | ``Erik | and it's not so much the structs as it is the comments |
| 18:18.12 | ``Erik | and variable names |
| 18:21.13 | Maloeran | Am I allowed to ask what the the getsize() and getbox() functions are for? |
| 18:21.41 | ``Erik | getsize() is the diameter (I think, maybe radius) of the bounding sphere |
| 18:21.50 | ``Erik | getbox is the bounding axis aligned cube, I think |
| 18:22.14 | ``Erik | when you get the code, it'll have the appriopriate shtuff filled in for adrt and BRL-CAD librt |
| 18:22.14 | Maloeran | I'm not quite following, what sphere and cube, what's the purpose? |
| 18:22.28 | ``Erik | not entirely sure why both are needed, actually... *shrug* |
| 18:22.35 | ``Erik | but if you have one, an estimate of the other is trivial |
| 18:23.02 | Maloeran | Fine, though I don't see the function of either at the moment :) |
| 18:23.04 | ``Erik | I know my metaball thingy primarily uses the sphere for computation, but the box for the kd-tree |
| 18:23.11 | ``Erik | well |
| 18:23.16 | ``Erik | suppose I have geometry of an unknown size |
| 18:23.21 | ``Erik | and I want to make a picture |
| 18:23.28 | ``Erik | automatically placing the camera |
| 18:23.32 | Maloeran | Oh, bounding box and sphere for the whole scene? |
| 18:23.39 | ``Erik | I have to know how big it is so I know how far away |
| 18:23.40 | Maloeran | Okay, very simple stuff |
| 18:23.46 | ``Erik | bounding for the specified geometry... |
| 18:23.55 | ``Erik | might be the whole 'scene', might be a subset... |
| 18:24.28 | ``Erik | I think the killer part you'll have to deal with, the real rough bit, is when you shoot a ray, you have to return the list of brlcad regions/components in order with in/out points |
| 18:24.59 | ``Erik | (and things like in and out normals, thickness, curvature, possibly GIFT material... ) |
| 18:25.48 | Maloeran | Rayforce will return the ordered hits, it shouldn't be too much trouble from there |
| 18:26.35 | ``Erik | getting you this code is my #1 priority at work... once you have it, you'll know how to craft rayforce to satisfy this benchmark... |
| 18:27.23 | Maloeran | I can already say that this interface will cut performance by a factor of 3-6 |
| 18:27.28 | ``Erik | heh, when trying to figure out who's gonna do some drudgework, I escaped it cuz of this... so jlo is doing the drudge instead of the tnurbs (which are considered "highly important" by money throwing fucktards) |
| 18:27.33 | ``Erik | yes |
| 18:27.34 | ``Erik | I know |
| 18:27.37 | ``Erik | and it's horrible |
| 18:28.10 | ``Erik | but adrt is under the same artificial stupid |
| 18:28.11 | Maloeran | Eheh, I'm glad to hear that :) |
| 18:28.17 | Maloeran | Right. |
| 18:28.22 | ``Erik | and if we rework the comparison, to be fair, we have to rework it for adrt, too |
| 18:28.33 | ``Erik | so, y'know, I wouldn't sweat it at this time |
| 18:28.57 | ``Erik | 5x is an arbitrary number, and we can be reasonably arbitrary in comparison |
| 18:28.58 | ``Erik | :/ |
| 18:29.45 | Maloeran | It's not like adding coherency management, SSE processing and ray bundling to adrt would be that simple |
| 18:30.14 | ``Erik | <- anal and pedantic, would have specified an interface and platform and set of specific cases and said 'total compute time' |
| 18:30.17 | Maloeran | Anyhow, I get the picture. Let's just hope it's naturally 15-30 times faster to reach that 5x thing :) |
| 18:30.22 | ``Erik | adrt has ray coherency and bundling |
| 18:30.31 | ``Erik | it's being skipped in s2 |
| 18:30.52 | ``Erik | it's stupid and wrong, ti's the equivelant of using read() and write() sending one byte at a time |
| 18:31.09 | Maloeran | Specific cases that can be solved in the native way for all raytracers would have been far preferable |
| 18:31.14 | ``Erik | any nonretard would use sendfile(), but *shrug* |
| 18:31.14 | Maloeran | Exactly! |
| 18:32.01 | ``Erik | s2 is a project I have no control over, but we go thte funding saying rayforce would make it faster |
| 18:32.39 | ``Erik | trust me, if I had permission to unfuck s2, it'd be several orders of magnitude faster and smaller right now. |
| 18:32.39 | Maloeran | So it must be faster using their akward interface we can not change, I got it |
| 18:32.44 | ``Erik | well, technically, we didn't say anything about their interface |
| 18:32.56 | ``Erik | but given the purpose, it seems like a rational starting point for comparing |
| 18:33.13 | Maloeran | Right, we can compare accuracy at least |
| 18:33.24 | ``Erik | the big reason I chose it was because libtie itself does no segment list building. you are required to build segment lists. the only adrt code that does that is in s2 |
| 18:33.31 | ``Erik | I'm lazy *shrug* |
| 18:33.42 | ``Erik | accuracy is why I'm also wiring librt into it |
| 18:34.35 | ``Erik | also; my api expects the geometry conversion to be handled by the specific rt engine... in librt, it's trivial, it's the native format. in adrt, there's an explicit tesselation pass to get triangle soup |
| 18:34.37 | Maloeran | I'm still a bit concerned about the numerical precision of my weird ray-triangle intersection tests, I look forward to having this point clarified |
| 18:34.54 | Maloeran | I'll use that same triangle soup |
| 18:34.57 | ``Erik | you might need to crib some crap from the adrt/adrt.c file |
| 18:35.44 | ``Erik | hmmm, I'm under the impression that if you're accurate within 5 digits, we're all good... but they also try to argue 64 bit ieee754/854 data being absolutely identical... |
| 18:35.56 | Maloeran | That's absurd! |
| 18:36.08 | ``Erik | so, y'know, don't sweat it, it's a political battle, and it'll be handled by lee and poor old bman |
| 18:36.21 | Maloeran | Identical results on 64 bits will never occur from different techniques |
| 18:36.38 | *** join/#brlcad cad07 (n=c90e90b1@bz.bzflag.bz) |
| 18:36.45 | ``Erik | nope |
| 18:37.13 | ``Erik | I'm under the impression that they're trying to cover their incompetence by clinging to shit like that, but quoting 5 digits for their own folley |
| 18:37.25 | cad07 | hi |
| 18:37.28 | Maloeran | 5 digits accuracy with float is reasonable |
| 18:37.31 | ``Erik | but that's a political battle. we'll take care of it. go do good things instead |
| 18:37.35 | Maloeran | Good afternoon Lee |
| 18:38.18 | lalola | Good morning |
| 18:38.25 | Maloeran | Oh, so that's where the bzflag.bz come from |
| 18:38.40 | ``Erik | bzflag.bz is the same machine as brlcad.org |
| 18:39.24 | ``Erik | http://irc.brlcad.org/ <-- will have people joining as cad[0-9]*@bz.bzflag.bz |
| 18:40.19 | Maloeran | *nods* By the way, if the segment list building code is the algorithm I have seen on a piece of paper at SURVICE, there's room for improvement |
| 18:40.58 | ``Erik | it might be |
| 18:41.05 | ``Erik | I think twingy wrote a whitepaper on it |
| 18:41.22 | lalola | why I cant join in other channel? |
| 18:41.29 | lalola | with this cgi script |
| 18:41.43 | ``Erik | you're using the incredibly simplified java program, if you want real irc ability, use a real irc program |
| 18:42.06 | lalola | Im in a closed network |
| 18:42.07 | ``Erik | which, naturally, will depend on what OS you're using... |
| 18:42.13 | ``Erik | hrm, sucks to be you? :D |
| 18:42.17 | lalola | I already Am using proxy to access http |
| 18:42.53 | lalola | I dont work with iptables now :/ |
| 18:44.01 | ``Erik | ew, linux |
| 18:44.37 | lalola | GNU/Linux |
| 18:44.56 | lalola | I was wanting join in #debian-br ... |
| 18:46.13 | ``Erik | most java applets that emulate protocol programs (irc, ssh, etc) restrict where you can go |
| 18:46.38 | lalola | well |
| 18:49.23 | lalola | but thanks bye |
| 19:08.24 | *** join/#brlcad digitalfredy_ (n=digitalf@200.71.62.161) |
| 19:48.57 | brlcad | bzflag.bz isn't the same as "brlcad.org" -- that's an sf.net server, but irc.brlcad.org and ftp.brlcad.org are both bzflag.bz |
| 19:55.20 | brlcad | heh, complaining that our cgi:irc isn't open to any channel on the network, sounds like an asshat plea to abuse |
| 19:57.52 | brlcad | there are bounding boxes/spheres around portions of a given model -- in a given solid model, it's comprised of various distinct parts aka regions |
| 19:58.18 | brlcad | segments returned on a shotline aren't just in/out points, but id'd to identifiers for each region |
| 19:59.16 | brlcad | for each given region, the user code can put either the bounding sphere or bounding box to use for some purpose (that you generally don't care about, but have to provide those bounds regardless as part of the interface) |
| 20:01.01 | brlcad | just as an example, they might want use the bounding spheres on a set of regions to get a real fast rough volume estimate, or determine if two regions/parts even have the capacity to potentially overlap each other |
| 20:27.20 | *** join/#brlcad digitalfredy_ (n=digitalf@200.71.62.161) |
| 20:27.35 | *** join/#brlcad digitalfredy_ (n=digitalf@200.71.62.161) |
| 20:43.02 | *** join/#brlcad digitalfredy_ (n=digitalf@200.71.62.161) |
| 21:05.30 | ``Erik | Kelsey Grammer and Cary Elwes, it's gotta be god |
| 21:05.45 | ``Erik | and I'm told it's more or less right, just not as horrible as the truth o.O |
| 21:06.57 | ``Erik | holy mcfuckingshit, john mcginley, too (dr cox from scrubs) |
| 21:26.34 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/copyright.sh: clean up the progress printing a little bit, remove the sed duplication and false modification report on current-year copyrighted files. ws too. |
| 21:27.04 | brlcad | ``Erik: it's pretty good, I imagine it was only worse but a good story regardless |
| 21:29.53 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/bench/viewdiff.sh: header should say viewdiff.sh since it was renamed, not recheck.sh |
| 21:35.55 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/misc/win32-msvc/Dll/TclDummies.c: header cleanup |
| 21:44.39 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/cakeinclude.sh: obsolete script from prior build system |
| 21:45.50 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/Makefile.am: obsolete script from prior build system |
| 21:47.23 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/misc/ (3 files in 3 dirs): consistency on the (c), keep it simple |
| 21:51.03 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/facetall.sh: header and footer |
| 21:52.25 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/gforge.sh: header and footer |
| 21:55.31 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/ (Makefile.am ldAix.sh): remove obsolete ldAix.sh build helper script. it's libtool's job now. |
| 22:08.00 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/copyright.sh: init var safety |
| 22:27.23 | *** join/#brlcad louipc (n=louipc@bas8-toronto63-1088753792.dsl.bell.ca) |
| 22:38.41 | Maloeran | Grah... It is amazingly hard to debate reality and cognitive perceptions with an islamist fundamentalist, it's terrible |
| 22:39.23 | Maloeran | I got to stop jumping in these debates whenever a believer joins programming channels, which strangely happens very often |
| 22:40.23 | dtidrow | heh |
| 22:40.48 | dtidrow | how do you feel about vi vs. emacs? ;-) |
| 22:41.18 | louipc | emacs makes more sense kind of |
| 22:42.09 | louipc | well, I guess I haven't gotten the feel of vi yet. emacs is more natural |
| 22:42.37 | dtidrow | I was being rhetorical |
| 22:42.42 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/copyright.sh: rm -f |
| 22:43.14 | louipc | uh oh! |
| 22:44.18 | Maloeran | vim!... and nedit :) |
| 22:45.11 | Maloeran | I'm just astonished at how religious brainwashing can completely cripple reasonning capabilities, the rational mind is... completely broken |
| 22:50.58 | ``Erik | emacs is only more natural if you have cognative ability and attention spen of a mildly retarded squirrel. |
| 22:51.23 | ``Erik | pentagon wars was a decent 'nuff movie, I may send a bulk email on monday... I'm glad leebert loaned it to me |
| 22:53.28 | ``Erik | on religious brainwashing in regards to emacs vs vim... both editors are phenomenal in capability, but it's our duty to pursue extending our ability as much as we can. Yes, there is a learning curve, but the increased productivity is not dismissable. Anyone who does NOT try to learn at least one of the two seriously has the kind of shortsightedness that leads to stagnation of real ability. |
| 22:53.31 | ``Erik | IMHO. |
| 23:04.44 | *** join/#brlcad cad55 (n=4316dc41@bz.bzflag.bz) |
| 23:05.15 | cad55 | hi |
| 23:05.30 | Maloeran | Greetings |
| 23:05.56 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/indent.sh: add support similar to that added to copyright.sh that allows the script to also work on individual files or with find. the script now also processes a backup just in case there are no changes made. |
| 23:07.15 | cad55 | I was wondering on google and saw that brlcad might feed my curiosity into the cad stuff on linux |
| 23:07.33 | cad55 | I am using a gentoo derivative, sabayonlinux, and was wondering what should i do to compile brl-cad |
| 23:08.01 | dtidrow | what exactly do you want to do with a CAD package? |
| 23:08.05 | Maloeran | If it's similar enough to Gentoo, downloading the source and compiling would do |
| 23:08.42 | Maloeran | ( You probably already have the other packages required ) |
| 23:09.16 | cad55 | ok,,I want just want to play with it and see what stuff it can do...I am fed up with windowze and tired of downloading pirated software |
| 23:09.46 | cad55 | I heard a lot about blender but it seems that it does not have cad features |
| 23:10.05 | cad55 | for example, I would like to try to model my house here in the us :) |
| 23:11.08 | cad55 | brl-cad architecture supports plugins or modules? |
| 23:11.25 | Maloeran | The user interface might be a bit lighter than what you are used to, it should be fine if you like command lines |
| 23:11.39 | Maloeran | Yet, depending on the purpose of the houes model, Blender might be more appropriate |
| 23:12.07 | Maloeran | house* model, even |
| 23:13.38 | cad55 | I see..well I kind of start to like the command line and like I said I am bored with windowze so after feedling with linux for about three years it's time for a change |
| 23:13.56 | cad55 | what would you say about q-cad and the features in brl-cad (never mind the UI) |
| 23:14.28 | louipc | cad55: I think the commands are little programs in themselves, so are all the file import functions |
| 23:15.47 | Maloeran | brlcad or Erik could probably tell you much more about CAD design and software, I'm just the guy working on the next raytracing engine |
| 23:15.49 | louipc | cad55 completely different programs, brl-cad doesn't think in terms of lines, faces, edges. |
| 23:16.26 | louipc | only solid 3d geometry |
| 23:17.50 | cad55 | can you give me just a simple example of a command to do 2d square with 20x20 -10 ofset from Z? |
| 23:17.51 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/Makefile.am: prior.sh missing from dist |
| 23:17.59 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/prior.sh: add header and footer; embed the psql sql statement directly |
| 23:18.37 | cad55 | ok, make it 3d then if possible |
| 23:19.15 | louipc | It's been awhile since I've actually used it but I'm pretty sure you can do that in one line |
| 23:19.26 | cad55 | I mean I compiled some programs before, blacklisted drivers, troubleshooted my grubs and lilos but i woudl like to have an idea of the sintax |
| 23:20.13 | cad55 | ok, then I will give it a go and then will post the results |
| 23:20.15 | cad55 | thanks all |
| 23:20.48 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/prior.psql: remove the unnecessary script -- directly embedded into prior.sh now |
| 23:21.09 | louipc | did you get the MGED tutorial pdf? |
| 23:22.30 | brlcad | cad55: brl-cad's main modeler is called "mged" - there's a fairly comprehensive introductory pdf on the website (that louipc is referring to) |
| 23:23.07 | brlcad | if you're interested in a 2D modeling, there are other tools more suited (like qcad, which has features more in line with other drafting tools like autocad) |
| 23:23.46 | louipc | qcad is about the only one I know |
| 23:23.51 | brlcad | brl-cad's design is more 3D-centric similar under the hood to packages like solidworks, pro/e, and unigraphics (though with a consirably less polished user interface) |
| 23:24.21 | louipc | hehe I would love to get something other than qcad |
| 23:24.27 | louipc | maybe... |
| 23:24.34 | brlcad | the interface is quite extentible and supports plugins, as is the entire brl-cad package (contains more than 400 tools related to modeling, rendering, signal processing, etc) |
| 23:25.17 | brlcad | we have way more of the foundation needed for a drafting program than even qcad, but pretty much no GUI support for creating/editing from that approach |
| 23:25.29 | brlcad | would make a great project for someone with initiative |
| 23:25.42 | louipc | really!? that's great |
| 23:26.34 | brlcad | most of brl-cad's main deficiencies are in the GUI -- the geometry and rendering engine underneath is quite robust/stable/extensive |
| 23:27.28 | louipc | so brlcad can look at things both as pure solids as well as line, face etc..? |
| 23:28.50 | brlcad | louipc: there's support in brl-cad for creating/representing those 2D entities, though again -- very minimal gui support for doing anything with them |
| 23:28.57 | louipc | hmm I think I'll start by making a package for my distro hah |
| 23:29.16 | cad55 | I see..you have a good foundation and walls but somebody needs to still do the windows and doors :) |
| 23:29.40 | louipc | brlcad that's good I thought that the internals were only pure solids. but there is the bag of triangles... I thought there might be something behind that |
| 23:29.47 | brlcad | the support was mainly added so that for converted solid models that were modeled with sketches and extrusions, they could be converted to a suitable preserving format in brl-cad land |
| 23:30.23 | brlcad | cad55: not a bad analogy :) |
| 23:31.09 | louipc | do you think it's possible to analyse those formats to be converted into pure solid instead of bag of triangles? |
| 23:31.51 | brlcad | maybe also like, the land was purchased, foundation layed, structure in place, all materials on hand with diagrams on what needs to be done -- but only a couple builders so progress chugs along at its own pace |
| 23:32.08 | brlcad | louipc: that depends entirely on the converter being used |
| 23:32.25 | louipc | well I mean to write a converter to do that |
| 23:32.43 | dtidrow | and none of the builders are very good at finish work ;-) |
| 23:32.57 | brlcad | the dxf-g converter, for example, will bring in 2D entites as brl-cad 2D entities (not triangles) |
| 23:33.08 | brlcad | though that's a relatively recent feature addition |
| 23:33.11 | louipc | I notice solidworks can import an IGES file and it asks if you want 'feature recognition' |
| 23:33.31 | brlcad | alas, IGES is dying |
| 23:33.36 | louipc | then it seems to do some real nice work |
| 23:33.52 | louipc | oh? what's the next big thing? |
| 23:34.27 | brlcad | STEP |
| 23:35.20 | brlcad | that's our next major converter task .. monumental task to say the least, one of the most complex formats to ever be created -- but it's an ISO standard and pretty much fully replaces IGES |
| 23:35.30 | louipc | ah yeah that's the ISO one |
| 23:36.00 | louipc | customers will send my company either IGES or Parasolid models though |
| 23:36.08 | brlcad | that's a task that's going to take several man-years to implement fully |
| 23:36.31 | louipc | I looked at STEP ages ago but I don't see anyone using it, I like the idea though |
| 23:36.36 | brlcad | nothing preventing anyone from taking the existing iges importer and improving it though |
| 23:37.04 | louipc | yea, except being too busy ;) |
| 23:37.21 | brlcad | step has been under development for a few years, but only starting to take off within the past couple -- slow adoption, but IGES is dead so it is pretty much guaranteed to eventually occur |
| 23:37.54 | louipc | yeah |
| 23:51.16 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/ (header.sh footer.sh): add recognition of python |
| 23:52.49 | louipc | CIA-5 is showing us the TODO list? |
| 23:54.36 | brlcad | CIA shows actual commits to the source code as they happen |