| 00:07.51 | starseeker | Ralith: I'm sure there would be, but I doubt it would be easy |
| 00:07.56 | starseeker | what did you have in mind? |
| 00:08.38 | starseeker | ezzieyguywuf: with what fidelity? real airfoil modeling is usually done with NURBS as far as I know, due to the need for precision surface contour control |
| 00:12.32 | starseeker | we can raytrace NURBS, but we can't yet model them |
| 00:14.05 | starseeker | brlcad: this looks interesting: http://snap.lbl.gov/pubdocs/SNAP_Solid_Model_Rev_A.stp |
| 00:15.02 | starseeker | another one here: http://planetquest.jpl.nasa.gov/documents/TPF-C_assy.stp |
| 00:15.49 | starseeker | http://www.pppl.gov/tritium/ |
| 00:19.27 | Ralith | starseeker: been playing around with OpenCL lately and having fun, mostly |
| 00:19.35 | starseeker | cool |
| 00:19.56 | starseeker | Ralith: brlcad knows more about how that would apply - I know it's of interest |
| 00:20.01 | Ralith | kk |
| 00:25.25 | starseeker | brlcad: if step-g is right, the snap, tpf-c, and tritium models all contain solid breps |
| 00:32.13 | starseeker | http://des-docdb.fnal.gov/cgi-bin/ShowDocument?docid=4041&version=1 - iges files |
| 00:34.51 | starseeker | http://www-eng.lbl.gov/~hoff/ALICE/ |
| 01:04.39 | starseeker | that's actually fairly nifty: http://des-docdb.fnal.gov/0040/004041/001/BLANCO-DECAM%20MODEL.bmp |
| 01:25.01 | starseeker | oh, wow |
| 01:25.05 | starseeker | http://des-docdb.fnal.gov/cgi-bin/ShowDocument?docid=336&version=22 |
| 01:25.11 | starseeker | http://des-docdb.fnal.gov/0003/000336/022/BLANCO%20STEP%20FILE%20AUG%2031%202009.jpg |
| 01:40.57 | brlcad | ezzieyguywuf: you shouldn't have to draw to cp -- you only have to draw if you intend to modify/edit them |
| 01:49.32 | brlcad | vtts: yes, they pretty much are all accessible, though some are really tricky on the command line or are completely undocumented or assume tk or ... |
| 01:52.04 | brlcad | vtts: to turn model axes on/off, see the 'rset' command -- in particular "rset ax", "rset ax model_draw 1" |
| 02:06.07 | brlcad | to set multipane, it takes two commands: set mged_gui(id_0,multi_pande) 1 ; setmv id_0 |
| 02:07.50 | brlcad | oops, not pande :) pane |
| 02:13.14 | brlcad | setting the active pane is similar: set mged_gui(id_0,dm_loc) ul ; set_active_dm id_0 |
| 02:13.27 | brlcad | ul | ur | ll | lr |
| 02:17.38 | brlcad | ezzieyguywuf: yeah, something doesn't sound right -- that should be nearly instantaneous, can post your .g and I'll take a look at it, but from your cpu monitor something is definitely fishy with them both reporting ~90% |
| 02:18.59 | brlcad | Ralith: there's always interest in improving raytrace performance, so long as it's validated too ... it's really easy to go fast, it's a lot harder to go fast and be verifiably correct |
| 02:20.48 | brlcad | starseeker: woot! that's an awesome iges find ... |
| 02:21.07 | brlcad | 220MB engine model |
| 02:26.08 | Ralith | brlcad: what all's involved in ensuring validity? |
| 02:28.01 | brlcad | depends on the type of changes |
| 02:29.41 | brlcad | but usually, current behavior is considered a baseline, regression tests are set up, then the new implementation is compared to the existing/old implementation, and any differences beyond floating point tolerance have to be explainable (or ideally, no differences) |
| 02:30.28 | brlcad | basically the new has to be compared to the current and differences have to be explainable |
| 02:30.42 | brlcad | even subtle grazing cases |
| 02:32.26 | brlcad | for our practical purposes, the common testing we usually perform are to have baseline raytrace images, then generate a new set of images with the new code |
| 02:33.16 | cjdevlin | could this (eventually) be useful in maintaining a windows build: http://coapp.org/ ?\ |
| 02:33.45 | brlcad | 1 RGB value difference in any one channel ("off-by-one") is considered ok; anything more is considered a deviation that is an error in one of the two implementations |
| 02:34.45 | brlcad | cjdevlin: for smaller projects that don't do proper external dependency management, probably |
| 02:35.22 | brlcad | otherwise, it's not very interesting since we ship an exe that has everthing needed to run, and we have everything needed to compile from source with a checkout |
| 03:14.14 | Ralith | sounds fairly straightforward |
| 03:17.54 | brlcad | yep, the process is pretty simple -- actually figuring out why something ends up different is the hard part |
| 03:18.08 | brlcad | especially for grazing |
| 03:18.34 | brlcad | can't brush anything off as just computation difference |
| 03:41.54 | brlcad | starseeker: I think I've now downloaded almost everything you listed and a lot more :) |
| 04:17.43 | starseeker | brlcad: heh - what else did you find? |
| 04:18.23 | starseeker | concentrated on the BLANCO models from fermi due to bandwidth issues... |
| 04:19.49 | starseeker | dunno for the life of me why they didn't gzip the step/iges files, it makes an enormous difference |
| 06:05.45 | brlcad | just more models |
| 06:06.04 | brlcad | all related to those projects |
| 06:06.17 | brlcad | a few other peripheral items, drawings |
| 06:19.11 | ezzieyguywuf | brlcad: still want to see the .g for my toy truck? I moved on to the walkie-talkie and had no slowness with that. |
| 06:19.36 | ezzieyguywuf | as far as my airfoil questions, I have some x-y coordinate files with about, I dunno, 200 points. That's as high a fidelity as I need. |
| 06:19.53 | ezzieyguywuf | I know NACA airfoils have an equation associated with them, and it'd be great to be able to model those... |
| 06:20.11 | ezzieyguywuf | http://ompldr.org/vN29sMg <--- truck.g |
| 07:29.26 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 09:23.10 | *** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no) | |
| 12:24.50 | starseeker | ezzieyguywuf: airfoil shapes are a little bit tricky |
| 12:26.34 | starseeker | you might be able to get close-ish with ell, rpc, rhc, and friends in various combinations but the primitive paramaters there aren't likely to correspond to the airfoil parameters, and to really do an airfoil shape properly you almost certainly need NURBS |
| 12:27.18 | starseeker | if you have xy points, an interesting possibility might be to create a proc-db that took those xy points and generated spline curves with them... |
| 12:27.42 | starseeker | but that's not going to be easy |
| 12:33.04 | vtts | whats is the command equivalent for "Move Face 1234" for later use with tra? |
| 12:36.14 | starseeker | vtts: um... unfortunately, I don't know of any way to select a particular face other than the gui |
| 12:36.37 | starseeker | there may be one, but if so I don't know offhand what it is |
| 12:37.01 | starseeker | would have to dig into the source code |
| 12:37.27 | vtts | the menu executes: press "Move Face 1234" |
| 12:38.40 | vtts | or something like that |
| 12:40.05 | vtts | although facedef does something like that in one shot |
| 12:43.17 | vtts | just would be nice to have an alternative which works with offsets |
| 16:13.34 | *** join/#brlcad Stattrav (~Stattrav@117.192.130.135) | |
| 16:13.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:43.06 | starseeker | turns on all the warnings for opennurbs and watches the slaughter... ho boy |
| 17:44.14 | starseeker | lot of unsafe floating point comparisons... wonder if I can safely script a search/replace for those with a near_zero macro... |
| 17:45.27 | starseeker | mutter... unused params too... may need the UNUSED macro |
| 17:46.16 | starseeker | yeah, probably not scriptable |
| 19:38.44 | ezzieyguywuf | starseeker: so, tl;dr is that there is not really a good way to make an accurate airfoil using brl-cad at the moment? |
| 19:38.55 | ezzieyguywuf | I'll be rapid-prototyping this thing, so a 'ruff estimate' won't suffice. |
| 19:39.32 | starseeker | ezzieyguywuf: yeah, that's an accurate statement |
| 19:43.53 | ezzieyguywuf | grumbles. |
| 20:00.38 | brlcad | ezzieyguywuf: you could import your 200ish points into BRL-CAD directly as a point cloud or polygonal mesh data, but the problem will be deriving a smooth surface that fit those points |
| 20:01.09 | brlcad | without knowing the equations, anything you create is going to be an approximation |
| 20:01.28 | ezzieyguywuf | brlcad: I know the equation, I found it in wikipedia :-P |
| 20:01.39 | brlcad | you can make a perfect-fit surface for those 200ish points (using a smoothed mesh), but it'll still be a mesh |
| 20:02.02 | ezzieyguywuf | I see where the problem is though: usually, I import the 2D airfoil data and extrude it, but in brl-cad we work with solid primitives from the get-go |
| 20:02.25 | brlcad | we support extrusions from 2D |
| 20:02.33 | ezzieyguywuf | really? how? |
| 20:02.38 | brlcad | our 2D shapes support points, polylines, arcs, and bsplines |
| 20:03.09 | brlcad | it's not great for interactive editing, to say the least -- meant more for data import -- but it's possible |
| 20:03.12 | brlcad | http://brlcad.org/wiki/Sketch |
| 20:03.36 | ezzieyguywuf | Hrm, maybe I haven't read enough of the documenation, but from everything I've done its 'create a box, create another smaller one and subtract that from the first' etc etc |
| 20:03.48 | brlcad | easier would probably be to mode the 2D sketch in QCAD, export that as dxf, import into BRL-CAD as a sketch, then extrude |
| 20:04.06 | brlcad | sketch isn't going to be covered by that tutorial series |
| 20:04.19 | brlcad | there are a half dozen or more advanced primitives like that |
| 20:04.55 | ezzieyguywuf | interesting. |
| 20:07.55 | starseeker | needs to study doxygen some.. will have to be careful here. |
| 20:08.11 | starseeker | conversion isn't automatable, from the looks of it |
| 20:09.35 | starseeker | icu is a good example at least... *read*read*read* |
| 21:07.42 | *** join/#brlcad Stattrav (~Stattrav@117.192.135.227) | |
| 21:07.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:12.06 | vtts | how to make wireframe with hidden lines? "z clipping" doesn't seem to work :/ |
| 21:52.20 | *** join/#brlcad kanzure_ (~kanzure@bioinformatics.org) | |
| 21:53.02 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
