| 00:15.20 | ``Erik | if .igs is IGES, you have to use iges-g to convert the IGES file to a BRL-CAD .g database file |
| 00:16.30 | ``Erik | and if you do iges-g to amke a .g file, then you can do g-dxf to make a .dxf file |
| 02:56.12 | brlcad | SWAT: in addition to what ``Erik said, yes it is possible to have a elements in an IGES file that are either custom extensions by that commercial tool, or perhaps 2D elements that brl-cad wouldn't otherwise care about (since we strongly focus on solid modeling) |
| 02:57.23 | brlcad | once you have a brl-cad .g file, you can open that with mged to view a wireframe and ray-trace images of any viewpoint, saving the images to files and using your favorite image viewer software to them print |
| 09:59.35 | *** join/#brlcad clock_ (i=clock@84-72-63-61.dclient.hispeed.ch) | |
| 10:49.43 | SWAT | hmmm, still something goes wrong. The .dxf files are empty and the .g files probably also contain errors. Could you take a look at it? http://paste.ubuntu-nl.org/5029/ |
| 11:25.28 | SWAT | will brlcad ever get an interface like qcad or autocad? |
| 11:36.23 | clock_ | no |
| 12:16.06 | SWAT | any idea on what goes wrong when I convert the .igs file to .g and .dxf? |
| 13:53.07 | ``Erik | did you read the output of iges-g ? |
| 13:53.45 | ``Erik | it says that there was no solid geometry found, just 2d drawings... and it says that nothing was converted and suggests a way to get your 2d drawings out of the iges file... |
| 13:54.46 | ``Erik | down |
| 13:55.20 | ``Erik | ok, g-dxf can't do globbing, and you didn't escape it, you gave it a list of files in the directory as names |
| 13:55.30 | ``Erik | sorry, all that whitespace confuzzled me :D |
| 13:55.49 | ``Erik | do something like "mged -c testfile.g tops" to get a list of toplevel objects |
| 13:56.06 | ``Erik | then do g-dxf -o testfile.dxf testfile.g <toplevel objects> |
| 14:01.08 | ``Erik | http://techdigest.tv/pcmaclinux.jpg |
| 14:03.26 | brlcad | from the looks of the first output, there are no 3D solids and no 2D drawings in that .iges file -- you might try the other suggested option of -3 for 3D drawings |
| 14:04.15 | brlcad | and specifying * for g-dxf is rather wrong, you have to know/specify the object name(s) |
| 14:05.24 | SWAT | thanks for the info, I'm going to try them. ``Erik, did you get that picture from the planet? :) |
| 14:13.41 | SWAT | I guess it starts out by creating a 'good' .g file (I guess I b0rked this up from the start). The -3 option gives me "No drawing entities and No view entities". If I try the '-t' flag 0 surfaces are converted. |
| 14:14.12 | SWAT | I'm going to try and use another .igs file, if you have any thoughts, just say so, I'm very open to suggestions |
| 14:19.31 | SWAT | "Unrecognized IGES version", could this be the source of the errors? |
| 14:23.25 | brlcad | SWAT: potentially, but the fact that it lists out the entity types found more indicates that there is "stuff" in there that it finds, just nothing useful to a 3D solid modeler |
| 14:23.40 | brlcad | ideally, it wants 3D solids |
| 14:24.06 | brlcad | what is generating the iges file? |
| 14:24.14 | SWAT | on another file (when "-t" is used) I get lots of output, among with are: "WARNING: UV point outside of domain of surface!!!" and "Convtrimsurfs: Cannot find a point in fu" |
| 14:24.54 | brlcad | that's a good sign, sounds like there are trimmed nurbs surfaces |
| 14:24.55 | SWAT | brlcad, I'm going to be honest, I don't really know. I 'guess' it's software like SolidWorks or something |
| 14:26.35 | brlcad | another issue could be version compatibility -- brl-cad's support is pretty comprehensive, but only up to version 4.5 or 5 (forget exactly) |
| 14:27.08 | brlcad | if something is outputting the handful of entity extensions added since, there might be issue, though that generally hasn't been an issue |
| 14:28.18 | SWAT | well, my .g file seems to be 104 bytes big, which means it didn't work ;) |
| 14:28.26 | brlcad | yep |
| 14:29.00 | SWAT | I wish I could e-mail you the files, but I can't. Do you have any advice? (except buying/getting/installing Windows and commercial software XXX) |
| 14:30.02 | brlcad | aside from sharing the iges file (which would be the most expedient) .. hmm |
| 14:30.23 | brlcad | I don't think blender has an iges importer iirc do they |
| 14:30.39 | brlcad | otherwise you could try them as an intermediate too |
| 14:31.17 | brlcad | did iges-g produce a 104 byte file after each of the various options? |
| 14:32.12 | SWAT | yes |
| 14:32.48 | brlcad | i suggest trying all the iges-g conversion option combinations just to see, -n -d -t |
| 14:32.48 | SWAT | I can go ask if they have 'dummy' iges files, but most of it is highly confidential. |
| 14:33.24 | SWAT | I tried all of them, and the only one that gives me any output that shows me that there is progress, is the "-t" flag |
| 14:33.38 | SWAT | I just love the commercial/closed-source world.... :-/ |
| 14:33.42 | brlcad | if this is from a commercial CAD sytem, there's going to be an option on the export to generate an IGES file that we can read almost for sure |
| 14:34.07 | brlcad | iges export panels are usually riddled with checkboxes ;) |
| 14:34.52 | SWAT | and n00bs who ignore them (just like the great AutoCAD formats) |
| 14:35.13 | brlcad | need to check the box(es) that say export solids/brep/bspline surfaces .. if there are only drawings and/or 2D entities, you're not going to get far with brl-cad |
| 14:36.36 | SWAT | brlcad, thanks for the help/advice. What else could I do? (if it contains drawings and/or 2d entities, just for the sake of argument) |
| 14:36.48 | brlcad | another possibility would be to simply export to a different file format, iges is great when it works but a royal pain when it doesn't .. something more simplified like stl or dxf or ply might be easier |
| 14:37.28 | brlcad | if it contains only 2D entities, you're going to need a drafting CAD package .. probably best to export to dxf and import that into qcad or somesuch |
| 14:37.37 | SWAT | iges has become the new standard for some companies and I guess they are unwilling to export also to .dxf or whatever (because it's more work, the bastards) |
| 14:37.49 | brlcad | iges is the "old standard" :) |
| 14:37.53 | brlcad | step is the new standard |
| 14:38.37 | SWAT | ah, OK. I guess it's .stp? And how does brl-cad to with STEP files? (would I get the same issues as I get now with IGES?) |
| 14:38.49 | brlcad | nobody on the open source side does step yet, though we're probably closest to having one implemented later this year |
| 14:39.15 | brlcad | STEP is even more complicated that IGES was, but more comprehensive too and more reliable |
| 14:39.45 | brlcad | either way, though, it's not going to help you today unless you have access to a commercial cad system |
| 14:40.35 | SWAT | hmmm, crap |
| 14:41.08 | SWAT | seeing that you're channel admin etc., I guess you're the lead developer of this project? |
| 14:41.39 | brlcad | yeah |
| 14:42.12 | SWAT | since I have some customers who have this issue, how could we solve it? |
| 14:42.50 | SWAT | I mean, in what direction should we 'stear' the companies? |
| 14:42.55 | SWAT | use .dxf by default? |
| 14:43.06 | brlcad | your best bet is to probably try different iges export options from whomever is providing them to you -- going for 4.5 IGES for example and specifying creation of solids or drawings at least by default |
| 14:43.39 | brlcad | i wouldn't suggest dxf by default |
| 14:44.07 | brlcad | step is really the way to go for full compatibility and reduction of introduction of modeling error or other information loss |
| 14:44.31 | brlcad | it's pretty much a fully-preserving format, whereas all of the others (including iges) aren't necessarily |
| 14:45.15 | SWAT | so STEP *is* already the way to go (it's finished and the format is open?)? |
| 14:45.36 | brlcad | it's finished, it's an ISO standard |
| 14:45.53 | SWAT | :-) |
| 14:46.19 | brlcad | it's also a very complicated and expensive ISO standard and just as unpublishable as most ISO standards |
| 14:46.39 | SWAT | and do you know if any of the commercial packages are 'mean' and have their own STEP implementation? (c.q. their own little format, which quirks) |
| 14:46.52 | brlcad | but mostly irrelevant to "us" as we've already paid for the relevant portions of the STEP standard (few thousand $$) |
| 14:47.11 | brlcad | i've yet to see that |
| 14:48.06 | brlcad | the step specification actually includes validation and correctness rules too, it would be rather "difficult" to say the least |
| 14:49.00 | brlcad | more likely is that it might contain some geometry that a given system doesn't understand/support -- the format itself is sort of the union of all CAD system formats |
| 14:49.25 | SWAT | hmmm, it almost seems to good to be true |
| 14:49.30 | brlcad | so whether your system cares that there are "dashed 2D line curves" or not still depends on the converter |
| 14:50.05 | brlcad | oh, it's not too good to be true -- perhaps I'm not conveying just exactly how "complicated and expensive" it is ;) |
| 14:50.13 | SWAT | so now we have to wait for all the commercial and non-commercial packages to support STEP and then 'force' everyone to use STEP? |
| 14:50.41 | brlcad | iges is probably 10 times to complexity of dxf which is probably 10 times the complexity of a simple polygonal format that opengl might want |
| 14:50.50 | brlcad | step is about 10 times more complex than iges |
| 14:51.24 | brlcad | most of the commercial systems already support step -- adoption started in early 2000's |
| 14:51.49 | SWAT | damn, sounds pretty complex (and complex mostly isn't good). I'm all 'for' open-standards and open-source (OpenDocument Format is a great standard) |
| 14:51.55 | brlcad | open source has had zero penetration simply because of the expense of the standard and nicheness of the market |
| 14:52.36 | SWAT | qcad mostly only supports .dxf (afaik) |
| 14:52.39 | brlcad | that and the fact that there are only a couple open source CAD systems, and we're by far the most developed in most respects |
| 14:53.05 | brlcad | http://ftp.brlcad.org/tmp/converters_page23.jpg mentions step briefly |
| 14:54.27 | SWAT | I'm pretty impressed by brl-cad. At first I found it hard to figure out (the .deb didn't work here), but now I see it has lots of small programs that are pretty strong on their own. Only the GUI is horrible (mged) if you compare it to qcad etc.. But that's my vision |
| 14:54.57 | brlcad | yep, that is a pretty reasonable summary |
| 14:55.24 | brlcad | mged's failings are well known too -- a new/better interface is one of the top priorities to "fix" |
| 14:55.34 | ``Erik | the pic was from another channel... on another network... :) |
| 14:55.36 | SWAT | ow great :) |
| 14:55.57 | *** join/#brlcad Twingy (n=justin@74.92.144.217) [NETSPLIT VICTIM] | |
| 14:56.01 | SWAT | brlcad, please take a look at autocad/qcad for a gui (and just start with those and make a better one) |
| 14:56.16 | brlcad | most of the underlying features and power of the geometric modeling engine are decades beyond (effort-wise) what can be found anywhere else .. just the modeling interface is currently .. painful. |
| 14:56.30 | SWAT | I mean, Windows had a pretty good gui too, but the menu was horrible (no HCI at all) |
| 14:56.54 | brlcad | autocad/qcad are drafters .. which actually is only partially relevant to solid modeling |
| 14:57.01 | clock_ | qcad interface is sometimes horrible as well. |
| 14:57.15 | clock_ | Especially v.1 was |
| 14:57.25 | clock_ | like changing the zoom was a diploma thesis for half an hour |
| 14:57.43 | SWAT | yet the 'drafters' are often used (very often, as far as I know) |
| 14:57.57 | clock_ | brlcad: don't worry, qcad is crap too :) |
| 14:57.57 | brlcad | autocad, pro-engineer, unigraphics, solidworks.. all being taken into consideration and fairly well known at least by myself and a few others as to their own strengths and weaknesses |
| 14:58.22 | SWAT | brlcad, before I forget it, I mean, I gave some harsh criticism... Great work everyone! It's appreciated :) |
| 14:59.01 | brlcad | SWAT: it's alright -- that's part of what's great about open source, being able to critique, recognize the dificiencies, look at the code, and fix/improve things :) |
| 14:59.09 | clock_ | brlcad: qcad 1.x had some great features like when you save the file, it forgets all line thicknesses in the layers |
| 14:59.20 | clock_ | So if you want to add a contour line, you get a zero thickness |
| 14:59.41 | clock_ | In practice when you opened a file you had to manually reset all the thicknesses you planned to work with - great afterburner for productivity |
| 15:00.31 | ``Erik | yay, power supply surgery was successful |
| 15:01.27 | brlcad | SWAT: the main concern is that autocad provides an interface that is more geared towards concept and design purposes .. which yes, are heavily 2D drafting-centric for some shops |
| 15:01.41 | SWAT | brlcad, yes, that's the great thing about it. I'm probably going to work on a pretty big project soon, but I'll just have to see. My time is very much limited and I just wanted to inquire here and give some feedback (hopefully good and constructive) |
| 15:02.20 | brlcad | the problem is that the domain of "CAD" as a generic industry is utterly massive and one must focus resources else you end up with a variety of useless metiocrity |
| 15:02.39 | SWAT | correct |
| 15:02.41 | brlcad | SWAT: have you seen our industry diagram |
| 15:04.13 | SWAT | brlcad, not yet... I just have very basic cad experience (very very basic, about 120 minutes) |
| 15:05.27 | brlcad | http://ftp.brlcad.org/Industry_Diagram.png |
| 15:06.10 | brlcad | from a system perspective, AutoCAD falls pretty squarely on the CADD domain |
| 15:06.47 | brlcad | something like ArchiCAD is of course CAAD, a CAM system like GibbsCAM is an MCAD system |
| 15:07.26 | clock_ | CAC |
| 15:07.31 | clock_ | Computer Aided Contraptions |
| 15:07.32 | brlcad | Rhino3D is sort of a CAID system |
| 15:07.35 | SWAT | okay, this is too niche-specific for me. But I guess I know what you mean |
| 15:08.16 | brlcad | solidworks is a big system that falls more in line with the centralized "CAD" domain as is unigraphics |
| 15:09.45 | brlcad | the dashed lines indicate the purpose that those systems/markets generally tend to focus on -- e.g. drafting systems are heavily used for concept and design, but rarely for analysis and manufacturing |
| 15:10.06 | SWAT | true |
| 15:10.44 | SWAT | btw, are you funded by the US government (I saw the US eagle on the project website)? |
| 15:11.12 | clock_ | SWAT: they are CAM, Computer Aided Millitary |
| 15:12.44 | ``Erik | ciad... computer illiterates aiding military... |
| 15:13.08 | clock_ | CIA - Computer Illiterate Analysis? |
| 15:13.21 | ``Erik | completely idiotic asshoel? |
| 15:13.23 | ``Erik | *cough* |
| 15:13.32 | ``Erik | sorry, I'll go bac to my cage now O:-) |
| 15:13.34 | ``Erik | back |
| 15:13.44 | clock_ | ``Erik: Remember OpenBSD lost funding because criticizing the Iraq qar |
| 15:13.46 | clock_ | war |
| 15:14.02 | clock_ | how long do you think BRL-CAD will have funding when you called CIA Completely Idiotic Assholes? |
| 15:14.20 | ``Erik | probably about as long as it'd have without me shooting my mouth off... |
| 15:14.51 | SWAT | clock_, harhar, very funny |
| 15:14.54 | clock_ | ``Erik: now repeat: "I love Uncle Sam and his American Dream" |
| 15:15.22 | clock_ | ``Erik: give me 20 and clean all toilets with your toothbrush :) |
| 15:16.08 | brlcad | SWAT: yes, BRL-CAD comes from the U.S. Army Research Laboratory, developed there for 20+ years before being turned into open source |
| 15:16.28 | clock_ | ``Erik: long hair is hippie and hippies are enemy of the US National Interests |
| 15:16.51 | brlcad | it continues to be funded and developed to this day, though the open source side of things has breathed some new life into developments that ARL wouldn't have supported |
| 15:17.35 | clock_ | SWAT: they planted some backdoors and trojans into the code and opened it so hippies now start using it as it's free, design some weapons, and the trojans copy themselves into the weapons and then DoD will be able to log in remotely and turn the weapons into cute tamagotchis |
| 15:20.22 | clock_ | brlcad: well BRL-CAD it's a bit insignificant step in light of the fact that Russians open sourced their atomic weapons and are now giving them out to any bypasser :) |
| 15:22.31 | brlcad | always going for the political angle, I see |
| 15:25.17 | clock_ | brlcad: is it possible that BRL-CAD generates data for CNC tooling? |
| 15:26.04 | clock_ | brlcad: for me BRL-CAD is not interesting as a millitary tool, but a tool to bypass the go-to-work-make-money-go-to-shop-buy-a-consumer-product loop |
| 15:28.27 | ``Erik | clock: provided you write the code to output the appropriate format, sure... :) |
| 15:28.39 | ``Erik | like a g-gcode converter, hhe |
| 15:28.59 | clock_ | Hmm write code, funny |
| 15:29.10 | ``Erik | (ahhh, shower fresh, w00t) |
| 15:29.13 | brlcad | there is no g-gcode |
| 15:29.27 | ``Erik | yet |
| 15:29.40 | ``Erik | clock is gonna write us a g-gcode.c :D |
| 15:29.44 | SWAT | clock_, keyword: MS Windows XP and Vista. Go! |
| 15:33.32 | brlcad | heh |
| 15:35.06 | SWAT | the NSA helped with the development of XP/Vista. I expected a reply with 'backdoors', 'trojans' etc. etc. etc. |
| 15:35.38 | brlcad | he's usually like a wind-up toy once someone gets him started |
| 15:35.41 | brlcad | must be busy ;) |
| 15:37.46 | brlcad | for what it's worth, "BRL-CAD is not interesting as a military tool" for me either, or most of the people that have ever worked on the project for that matter .. it's used for many many purposes and is just a graphics CAD system when it comes down to it |
| 15:38.28 | brlcad | ``Erik: weren't those mostly all wigs? :) |
| 15:38.44 | ``Erik | heh, for the bald people, sure :D |
| 15:39.15 | brlcad | mm. no more "big wigs" party, that'd be pretty funny today |
| 15:40.11 | brlcad | 80 |
| 15:40.19 | brlcad | 80's mohawk |
| 15:41.02 | ``Erik | it's hav eto be a fauxhawk, I'm not shaving the sides of my head... I'm not that lame :D |
| 15:41.03 | brlcad | a bet particular image-conscious bosses would love seeing you with a two foot blue spike |
| 15:41.07 | ``Erik | heh |
| 15:41.30 | ``Erik | with enough jelly, I could make my real hair a hella crazy fauxhawk |
| 15:41.46 | ``Erik | been a while since I've dyed my hair blue... *scratches chin* |
| 15:42.16 | ``Erik | we should send her to defcon some year... heheehehhe |
| 15:42.34 | brlcad | hmm.. i haven't colored mine approaching two years *gasp* |
| 15:43.21 | ``Erik | heh, yeah, uh, I don't think she'd consider that anywhere close to the same scale as, say, blue or green or purple... :D |
| 15:44.02 | brlcad | i think you should spike it blue, send pjt a picture and ask if you can be a pointy-haired boss |
| 15:44.09 | brlcad | (too) |
| 15:44.14 | ``Erik | heh |
| 15:44.20 | ``Erik | two big honkin' spikes, one on each side of the head |
| 15:44.27 | ``Erik | optimus prime style, yo |
| 15:44.40 | clock_ | brlcad: if you print out some long listing in mged, then press page up, page down and then type a command, it types the command in front of the prompt instead of after the prompt. And then it ignores the command. Isn't this a bug? |
| 15:58.02 | brlcad | a long-standing one, minor annoyance that nobody has bothered trying to track down |
| 16:00.08 | ``Erik | is it in the tracker? |
| 16:01.06 | brlcad | maybe, don't remember |
| 16:04.00 | brlcad | either way, now it's in BUGS |
| 16:04.16 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/BUGS: mged command prompt will have the cursor reset to before the 'mged>' prompt after performing certain actions (e.g. page up/down) |
| 16:05.45 | brlcad | something to do with the text-area tk widget as mged doesn't specifically have a page up/down binding |
| 16:06.01 | brlcad | at least I just went looking for it and don't see it |
| 16:10.25 | ``Erik | still fighting tcl, I take it? |
| 16:11.53 | brlcad | chugging along |
| 16:12.06 | brlcad | it's all compiling now, but some portability annoyances with pic crap again now |
| 17:45.48 | *** join/#brlcad PrezKennedy (n=Matthew@c-69-138-68-160.hsd1.md.comcast.net) | |
| 18:19.53 | *** join/#brlcad debarshi (n=rishi@202.141.130.198) | |
| 18:20.54 | debarshi | What is the license of BRL-CAD? |
| 18:29.25 | clock_ | GPL |
| 18:30.03 | debarshi | clock_: Thanks. |
| 19:00.04 | SWAT | right... |
| 19:00.31 | SWAT | that information can't be found on the project page or on sourceforge or something ;) |
| 19:10.53 | IriX64 | pkg_suckin read error? |
| 19:49.35 | *** join/#brlcad cad65 (n=c88b730b@bz.bzflag.bz) | |
| 20:37.11 | ``Erik | lgpl with bsd chucnks (and a couple others iirc0, actually |
| 21:41.46 | brlcad | clock_: it's predominantly LGPL now |
| 21:42.21 | brlcad | BSD for the build system, benchmark suite, testing scripts, a few other utility scripts, and the documentation |
| 21:44.31 | brlcad | which according to ohloh is about an 80/20 split percentage-wise |
| 21:51.59 | ``Erik | huh, neat, a cvs analyzer |
| 21:54.31 | ``Erik | pretty easy to spot 'major events' on that timeline... |
| 21:54.51 | ``Erik | jra goes to 0 at the start of hell project.. and the move to sf... |
| 21:56.57 | ``Erik | kinda unfortunate cvs isn't aware of moving files or silly things like scripts... someone is overrepresented :D |
| 22:01.41 | clock_ | ``Erik: svn is |
| 22:01.54 | clock_ | ``Erik: I used first CVS, then Arch, and now SVN on Ronja |
| 22:02.13 | clock_ | CVS sucks by design |
| 22:02.24 | clock_ | Arch sucked at the moment when it was unable to read it's own archive |
| 22:02.39 | clock_ | got trashed at that moment and replaced by Subversion. |
| 22:02.43 | ``Erik | svn captures file moves because it's change set based instead of file history... |
| 22:02.53 | ``Erik | but it doesn't do, say, scriptware monitoring |
| 22:03.44 | ``Erik | so "find . -type f | xargs sed -E -i.bak 's/[ \t]+$//'" ends up looking like a lot of diligent work... |
| 22:05.34 | ``Erik | I'm also fairly against restructering organization... generally means it wasn't thought out in the first place... BRL-CAD warranted one as it's an ancient project and conventions had changed radically... :) |
| 22:30.46 | ``Erik | O.o |
| 22:30.55 | Maloeran | It's only when writing the networking demos that I realized it was a pain for the user to manage the clients, synchronize its own data ( textures, whatever ) |
| 22:31.13 | Maloeran | So I shifted design for the library to take care of everything ; including user-land data |
| 22:31.21 | ``Erik | ayup, gotta make sure the right bits are at the right place at the right time |
| 22:31.39 | Maloeran | Now, it doesn't even have to care what, how and when clients connect ; work is just silently distributed |
| 22:31.41 | ``Erik | if the planets of your created universe don't align just right, it don't go |
| 22:32.42 | Maloeran | 50 days, mmhm :) |
| 22:33.11 | ``Erik | 50 days is terminal... the goal should be a fair bit inside of that :) |
| 22:33.41 | Maloeran | Right, I'm returning to the work output of the first couple months, AI experiments ( working quite well by the way ) will wait |
| 22:35.02 | Maloeran | How's the wrapper thing coming along? |
| 22:35.15 | ``Erik | slowly |
| 22:35.17 | ``Erik | I'm lazy |
| 22:35.22 | ``Erik | and distracted |
| 22:35.31 | Maloeran | Ah, so I'm not the only one :) |
| 22:36.07 | ``Erik | oh |
| 22:36.12 | ``Erik | and I got to write two project plans this week |
| 22:36.26 | Maloeran | Sounds great! Aren't you overflowing with motivation? |
| 22:36.30 | ``Erik | heh |
| 22:36.46 | ``Erik | I've already put forward the idea of putting a jar on my desk and if anyone asks me a question, they have to put a buck in it |
| 22:37.51 | ``Erik | librt is wired into the framework and working ok, adrt is 'mostly' wired in, extracting triangle info from the csg's is the part I'm working on now... and the ray fire SHOULD be a trivial thing after that |
| 22:38.30 | ``Erik | but once I have adrt wired in, I'll have to fix the control function to provide the proper 'golden' shots and a grid |
| 22:38.40 | Maloeran | Your single-ray function is called from multiple threads, right? |
| 22:38.45 | ``Erik | no |
| 22:38.49 | Maloeran | Oh. |
| 22:38.55 | ``Erik | right now, it's all single threaded |
| 22:39.10 | ``Erik | but I could easily thread it out somewhere... it's a single shot function, though |
| 22:39.34 | Maloeran | Is it meant to be threaded? Because I would need to keep track of data specific to each thread, just some pointer... If it's single threaded, I can just put that stuff as globals |
| 22:39.53 | ``Erik | no, at the moment, I'm thinking straight up single threaded |
| 22:40.19 | ``Erik | and mebbe, if it's appropriate, we could do a quick 'by thumb' scalability exercise... which'd probably be the distributed aspect more than the threaded aspect |
| 22:42.06 | Maloeran | Eh, scalability and threading for shooting one ray at a time, what a mess :) |
| 22:42.56 | ``Erik | well, this framework is for three reasons |
| 22:43.06 | ``Erik | to make sure rayforce produces reasonably correct results |
| 22:43.15 | ``Erik | and demo how it can be wired into the 'goal' application... |
| 22:43.24 | ``Erik | and to prove at least 5x over adrt |
| 22:43.45 | Maloeran | At least 5x could be tight if you don't give me SSE-packed ray batches |
| 22:43.52 | Maloeran | But you know that already |
| 22:44.08 | ``Erik | if it fails the 5x, we'll start looking why and if adrt was unfairly advantaged... and go from there *shrug* |
| 22:44.41 | ``Erik | and 'reasonably' correct is something that'll be a discussion (based on perliminary results) with leebert and possibly mark |
| 22:45.19 | ``Erik | if you're thinking 'function call overhead', I've already put forth the idea of having a dumby function (just returns) to measure that and subtract it from both engines times |
| 22:45.26 | ``Erik | dummy |
| 22:46.01 | Maloeran | It's not really the calling overhead... It's the fact that a one-ray-at-a-time function discards all optimisation based on the coherency and locality of rays |
| 22:46.21 | Maloeran | Plus of course the SSE packing |
| 22:46.24 | ``Erik | if the 5x mark is made in the na�ve comparison, then you're all ok, and we don't have to exert effort... |
| 22:46.44 | Maloeran | Do you have any raw numbers on adrt? |
| 22:46.52 | ``Erik | hm, *shrug* from eyeball comparisons, you have ntohing to worry about.. |
| 22:46.54 | ``Erik | not really :/ |
| 22:47.14 | ``Erik | I think I remember something about 1.2m r/s on a dual 2.4ghz xeon? |
| 22:47.40 | Maloeran | Seriously, don't under-estimate the huge blow one-ray-a-at-time tracing will deal... |
| 22:47.56 | ``Erik | I might be completely in err, I have a vague recollection of 1.2m, and I THINK that was on a certain machine... |
| 22:47.58 | Maloeran | I see. How many triangles in there? |
| 22:48.20 | ``Erik | I d'no, a few million? triagle number should be a very minor influence |
| 22:48.45 | Maloeran | Triangle count is a very minor difference as long as I can use my ray sources to exploit locality... Grah :) |
| 22:49.05 | ``Erik | adrt is built for cache coherency, so the hope is that the na�ve approach I'm taking (which maps exactly to the 'target' app) equally disadvantages both engines |
| 22:49.30 | ``Erik | like I said... we'll give it a whack... if the mark isn't met, we'll look why and try to fair things up a bit :) |
| 22:49.43 | Maloeran | 1.2m is first-hit only, right? |
| 22:49.45 | ``Erik | <-- ain't trying to jack you, just trying to get the green light with as little effort as possible |
| 22:49.53 | ``Erik | um, I think full shot? might be first hit, I don't recall |
| 22:50.08 | Maloeran | There's quite a difference between the two... :) |
| 22:50.11 | ``Erik | adrt suffers from full depth tracing as it calls a function every hit |
| 22:50.21 | ``Erik | and I'm testing full depth |
| 22:50.52 | ``Erik | (might be worth doing both... also; the 5x is awfully vague...) |
| 22:50.56 | Maloeran | I call a function per "batch" of hits too, so that the user can prematurely cancel traversal |
| 22:51.05 | ``Erik | in fact, of that entire contract, the 5x one is the one that irks me the most O:-) |
| 22:51.44 | Maloeran | I really think it should be 5x times faster to solve specific problems, presented in the optimal manner for both engines |
| 22:52.00 | brlcad | ``Erik: yeah, ohloh is pretty nifty .. i've been working lightly with them to fix some of their processing problems -- our stats are outright wrong atm |
| 22:52.36 | brlcad | added the project a few weeks ago |
| 22:56.40 | brlcad | hm, i did account for ws commits and major moves with statcvs -- that mostly affected user 'morrison' |
| 22:57.29 | IriX64 | ahha the guardian of the "boxen" :) |
| 22:58.16 | ``Erik | collapsing pre and post results woulda been nice :) woulda put me on the first page, heh |
| 22:58.30 | brlcad | not normalized, here is a snapshot of the most recent: http://ftp.brlcad.org/statcvs/cvs.html |
| 22:58.33 | ``Erik | an "aka" knob |
| 22:58.54 | ``Erik | was '83 the first year of rcs? |
| 22:59.13 | brlcad | yep |
| 22:59.31 | ``Erik | huh, bob's been hittin' it hard the last decade |
| 23:00.01 | ``Erik | see, in '04, I have both names... if those were combined, I wonder if I woulda stepped up above lee... |
| 23:00.25 | ``Erik | nice to see I'm a standing name in '03, for a whole 2.5 months heh |
| 23:00.27 | brlcad | Maloeran: of course not ;) |
| 23:00.55 | ``Erik | mal: it's about as useful as measuring programmer expertise by LOC |
| 23:01.15 | IriX64 | 48? how does the left hand ahhhh never mind ;) |
| 23:01.29 | ``Erik | one of the very few impressive things microsoft has done is try to debunk that notion in the early 80's, yet here we still use it, heh |
| 23:02.09 | Maloeran | I heard that mesuring LOC/month was common in some environments, scary |
| 23:02.41 | ``Erik | what's keeping you, irix? hop to, submit patches, one of us will review it and either bounce it back with feedback or apply it and shove your name in the contributors file |
| 23:03.03 | ``Erik | if you don't know where to start, look at the bugs and feature request trackers on sf... grab one owned by 'nobody' |
| 23:03.16 | IriX64 | for(i=1;toinfinity;i++) printf("Line 1 %d\n",i); |
| 23:03.32 | ``Erik | 10 print "Hi" |
| 23:03.34 | ``Erik | 20 goto 10 |
| 23:03.36 | Maloeran | I also read ( from efnet's #c ) that the average productivity was 300-500 lines of code per month, which is even scarier |
| 23:03.36 | ``Erik | :D |
| 23:03.49 | IriX64 | mines generating LOC ;) |
| 23:04.02 | ``Erik | bear in mind, mal, the average environment is rife with meetings, training, email, and other bullshit |
| 23:04.20 | ``Erik | 40 hours a work week, you might get 5-10 hours of productive code time |
| 23:04.27 | Maloeran | Ouch :) |
| 23:05.18 | ``Erik | (tht's after taking the cut for ramp-up and ramp-down from interruptions as well as 'dain bread because I'm here during specified hours') |
| 23:06.04 | brlcad | Maloeran: there was a study done several months back that showed, on average across the entire industry that programmers only generate about 2000 lines of maintainable/sustainable code per year |
| 23:07.51 | brlcad | a dev might be able to generate 2000 in a given month, but it's mostly useless/unmaintainable and is either thrown away or becomes obsolete or is rewritten |
| 23:07.52 | Maloeran | This is terrifying. Considering this is an average and some must do 10 times that, there are a lot of bad programmers roaming around |
| 23:08.07 | ``Erik | every time I crank up an editor on some code, put my feet up and get ready to code, SOMEONE walks into my office with a stupid question or something |
| 23:08.11 | ``Erik | actually |
| 23:08.29 | ``Erik | it happens about when I'm ready to write code, after I remember all of what I was doing last |
| 23:09.06 | ``Erik | (heh, and I do it to brlcad allllll the time) |
| 23:09.33 | brlcad | the report more showed that most code is useless from a long-term perspective -- how useful is most of the code you've written today going to be unmodified 10 years from now sorts of implications |
| 23:09.46 | Maloeran | Ah yes, 10 years is a long time |
| 23:10.03 | brlcad | it's easy to churn out tons of code, just like it's easy to write long crappy essays ones whole life |
| 23:10.09 | Maloeran | I don't think my SSE code will survive that long, but I hope the rest is mostly good |
| 23:10.33 | brlcad | i think you'll be survived about even "the rest" if you divert onto different projects |
| 23:10.36 | ``Erik | hm, 2 (sorta 3) with over 20 years legacy |
| 23:10.58 | brlcad | i've revisited code after 10-15 years only to see it all totally alien |
| 23:11.09 | brlcad | code i've written that is |
| 23:11.15 | Maloeran | Ahah, neat |
| 23:11.18 | ``Erik | heh, me too |
| 23:11.25 | Maloeran | Frankly, I don't remember my code too well either after a couple years |
| 23:11.33 | brlcad | some of it I grok'd right away.. but a lot of it not so well |
| 23:11.43 | ``Erik | code from even 10 years ago makes me go "wtf was I thinking?" |
| 23:12.08 | brlcad | wasn't until probably a good decade that a good balance of comments, structure, and conventions settled down |
| 23:12.22 | ``Erik | I hope that means I've drastically improved... and I hope in 10 years, I look at todays code and say the same thing, otherwise I'm not improving... *cough* |
| 23:12.31 | brlcad | exactly |
| 23:12.36 | Maloeran | In fact, barely a few months later, when trying to document the graph preparation code... I had to pause for 30 minutes to understand how some weird pass worked |
| 23:12.46 | ``Erik | I'd be scared to see the code I wrote 20 yrs ago, heh |
| 23:13.09 | brlcad | heh, if that happens in just a couple months.. you've got a ways to go :) |
| 23:14.02 | Maloeran | Ah the code isn't bad :), it's just both complex and optimized |
| 23:14.09 | ``Erik | I lost all my code from '83 to '96 :( |
| 23:14.26 | ``Erik | but it was all cbm stuff |
| 23:14.38 | brlcad | Maloeran: complexity and documentation are two factors on code, not just functionality |
| 23:15.08 | ``Erik | 'unmaintable' becomes 'obsolete' very very fast |
| 23:15.15 | ``Erik | like, 2 days after it's "done" |
| 23:15.41 | brlcad | readability, maintainability, optimization clarity (sometimes semi-contradictory), complexity/simplicity, quantity, hmm.. |
| 23:15.45 | ``Erik | unmainainable |
| 23:16.14 | ``Erik | maintainability infers readability and clarity :D |
| 23:16.24 | Maloeran | Yes yes, I'm complete writing the documentation... when I read about how to generate "summaries", several paragraphs not attached to functions or files in Doxygen |
| 23:16.38 | Maloeran | I'll* complete |
| 23:16.57 | brlcad | ``Erik: to an extent.. maintainability has other factors including familiarity, language choices, patterns/paradigms, etc |
| 23:18.11 | Maloeran | Any keyword to look up on how to generate overviews, summaries, general explanations in Doxygen? |
| 23:19.16 | ``Erik | ah, if only it were all in scheme *sigh* |
