| 00:10.03 | *** join/#brlcad iraytrace (n=iraytrac@cocoa.sci.utah.edu) | |
| 00:13.40 | brlcad | jdoliner: howdy |
| 01:08.59 | jdoliner | brlcad: are you present |
| 01:10.49 | brlcad | i am present |
| 01:12.04 | jdoliner | great |
| 01:12.34 | jdoliner | I've been looking over some papers on CSG algorithms for BREP |
| 01:14.12 | brlcad | great |
| 01:14.57 | brlcad | so how do things look? |
| 01:15.14 | jdoliner | well the algorithms seem understandable enough |
| 01:15.57 | jdoliner | they just involve extending the features to affine spaces and then detecting their intersections with the other features |
| 01:17.27 | brlcad | please do reference the papers you read in your submission |
| 01:17.38 | jdoliner | of course |
| 01:17.52 | jdoliner | however I have a few questions |
| 01:18.02 | brlcad | sure |
| 01:19.52 | jdoliner | firstly I'm afraid I'm not yet that knowledgeable about the brlcad code base, so I haven't seen precisely what our BREP structures look like so I wonder if you could tell me exactly where in the src they're located |
| 01:21.51 | jdoliner | also are there any major constraints for the algorithm that you think wouldn't be immediately obvious, for example is it important that polygonal structures maintain quads or not |
| 01:23.41 | brlcad | okay, this is mildly complicated to explain, so bear with me |
| 01:25.26 | brlcad | we actually have two brep implementations in our codebase, one is the n-manifold support (i.e. "NMGs") in our librt library the other is through the openNURBS library |
| 01:26.26 | brlcad | our nmgs support both polygonal and spline surface breps, but there are rather significant differences between the two |
| 01:27.56 | jdoliner | such as |
| 01:28.28 | brlcad | nmgs are huge body of code in src/librt/nmg*.c and that is the code that is called if you create an 'nmg' (polygonal), a 'bot' (bag of triangles), or a 'nurbs' brl-cad primitive |
| 01:29.07 | brlcad | the code for nurbs is in src/librt/nurb*.c .. it's another rather extensive body of code |
| 01:30.27 | brlcad | we're in the process of replacing the nurbs body of code (and 'maybe' later the nmg/bot implementations) with the openNURBS library facilities via the implementation of a new 'brep' primitive type |
| 01:31.08 | brlcad | your work relates to that latter new effort, part of the 'brep' implementation |
| 01:31.23 | jdoliner | yes |
| 01:32.27 | brlcad | so as I mentioned, we're using openNURBS for that implementation -- but openNURBS doesn't provide *any* geometry evaluation routines (such as CSG evaluation) |
| 01:32.28 | jdoliner | So possibly my proposal could contain a new implementation of a 'brep' primitive and then CSG operations to go with it |
| 01:33.04 | brlcad | no, no -- you really couldn't possibly implement a new brep primitive nor do you need to |
| 01:33.07 | brlcad | we've already started on that |
| 01:33.14 | brlcad | src/librt/g_brep.c among other files |
| 01:33.18 | jdoliner | oh I see |
| 01:33.25 | brlcad | it's about 90% complete for that matter |
| 01:33.49 | brlcad | where your work comes into play is that we have about 30 other primitives |
| 01:34.28 | brlcad | those primitives are presently represented in implicit form -- so we have plans to implement the necessary "describe be in brep form" function |
| 01:34.29 | jdoliner | so the CSG algorithm needs to work on those primitives |
| 01:34.50 | jdoliner | in brep form that is |
| 01:34.59 | brlcad | right |
| 01:35.41 | brlcad | so we can take an existing CSG model, that is stored in implicit form .. ask for it in brep form, evaluate the brep-on-brep csg to generate an evaluated brep result |
| 01:36.58 | jdoliner | right that seems doable to me |
| 01:37.41 | jdoliner | what level of specificity is good for my proposal |
| 01:37.49 | brlcad | this might just amount to implementing functions that were removed from openNURBS for evaluating ON_Brep objects |
| 01:38.32 | brlcad | they removed most of their evaluation functions as they only intend/want the library to be used for reading/writing the 3dm file format -- we're extending the library, though |
| 01:39.21 | brlcad | (which is all kosher, just means we have a LOT of heavy/hard coding to do) |
| 01:39.56 | brlcad | be as specific as you care to be, the more detail the better |
| 01:40.27 | brlcad | this is a hot hot topic for us, so an outstanding proposal will easily be a high-priority contender for a slot |
| 01:41.55 | brlcad | show that you understand the algorithm and how to go about implementing it, how it relates to brl-cad (even if it includes rewording and reiterating what i've said here) |
| 01:44.22 | brlcad | you don't have to talk about what files you'd be editing, there is too much detail -- don't expect everything to be figured out, but the proposal needs to instill confidence that you understand the task, are passionate about the work, interested in long term development (which I hope you are!) :), and can communicate your ideas well |
| 01:44.41 | jdoliner | okay so basically the project boils down to: implement all of our 30 primitives as BREP objects, then implement CSG for BREP such that CSG model in implicit form could be converted into a BREP form |
| 01:45.47 | jdoliner | also where are the primitives implemented |
| 01:45.49 | brlcad | hehe |
| 01:46.02 | brlcad | well, I wouldn't include the 30 primitives |
| 01:46.16 | brlcad | focus on the implementation of the CSG BREP evaluation routine first as the core |
| 01:46.36 | brlcad | then maybe add in room to start on the 30 primitives if time allows it |
| 01:46.46 | jdoliner | okay that seems reasonable |
| 01:47.02 | brlcad | some of the existing primitives will be very hard to describe in brep form |
| 01:47.17 | brlcad | there are several, however that are already done |
| 01:47.29 | brlcad | they're just implemented using the old nurbs code |
| 01:47.41 | brlcad | all the primitives for brl-cad are in src/librt/g_*.c |
| 01:48.26 | jdoliner | right |
| 01:49.15 | jdoliner | Okay I think that's all I have for right now |
| 01:49.22 | jdoliner | thanks a bunch |
| 01:49.31 | brlcad | look forward to seeing yours... |
| 01:49.52 | brlcad | what's your background coding? |
| 01:51.24 | jdoliner | I've had formal education in both C and Scheme as I mentioned |
| 01:52.00 | brlcad | yeah, sorry -- been talking to a lot of folks, so need reminders :) |
| 01:52.01 | jdoliner | I really haven't been coding all that long |
| 01:52.13 | jdoliner | So formal in those two |
| 01:52.24 | brlcad | have you ever read/written any C++ ? |
| 01:52.58 | jdoliner | Then I spent the summer coding at Fermilab |
| 01:53.41 | jdoliner | Yeah physics programs are all very hacked together so I saw and wrote some C++, as well as Fortran over the summer |
| 01:54.40 | jdoliner | I can't claim to know the nuances by any means but I can hack |
| 01:55.07 | brlcad | fortunately, you can conceivably stick "mostly" with C .. but openNURBS is a C++ API, so to dig in deep there in figuring out the ON_Brep object structure is going to require some getting up to speed |
| 01:59.50 | jdoliner | I might have to brush up a bit before the summer starts then |
| 02:01.12 | brlcad | nods |
| 02:01.22 | brlcad | certainly not a show-stopper, it's not that much of a hurdle |
| 02:01.28 | brlcad | particularly for what you're doing |
| 02:01.57 | brlcad | and all else failing, there's plenty of C routines related to this task that you could be refocused onto if you true do get stuck |
| 02:02.03 | brlcad | s/true/truly/ |
| 02:31.04 | pacman87 | brlcad: mged works only after minimizing the graphics window |
| 02:31.54 | starseeker | tries inkscape for importing a .fig file and it seems to do pretty well - just needs a little scaling |
| 02:33.15 | brlcad | pacman87: you mean that undoes the lockup? |
| 02:33.51 | pacman87 | brlcad: yes, after minimizing, the mged> window opens |
| 02:34.53 | pacman87 | and cpu usages returns to ~0 |
| 02:35.35 | brlcad | wow, wierd .. almost like it's stuck in a loop expecting an expose event |
| 02:36.21 | pacman87 | and if i click on a menu while it's locked up, it opens the menu after it's minimized (floating on my screen) and gives the 'window not visible' error |
| 02:36.35 | brlcad | yeah, that makes sense |
| 02:36.47 | brlcad | the events are just queue'd up |
| 02:38.30 | brlcad | if you want to go old-school debug style, you could add printf's incrementally to find the call or loop it's blocking on |
| 02:38.41 | brlcad | src/mged/ged.c is where mged's main starts |
| 02:41.46 | pacman87 | what compile flag do i need for gdb? |
| 02:42.12 | pacman87 | i need to learn real debugging sometime, why not now |
| 02:44.10 | brlcad | gdb only needs -g (which is on by default for both optimized and unoptimized) |
| 02:44.25 | brlcad | so unless you add --disable-debug, it should be debuggable |
| 02:44.42 | brlcad | if it's optimized, symbols and line numbers may be off, but it should work |
| 02:56.22 | CIA-33 | BRL-CAD: 03johnranderson * r30573 10/brlcad/trunk/src/librt/db5_bin.c: eliminated excess logging |
| 02:59.27 | brlcad | pacman87: it is really appreciated that you're working on a patch (at least it seems like that's what you're doing) but you can put in your submission in before the patch if you like |
| 03:00.34 | yukonbob | waves in |
| 03:00.38 | yukonbob | hello cadheads |
| 03:01.03 | brlcad | it is important that the application be solid regardless of the patch, the patch is then a major criteria to help differentiate the finalists |
| 03:01.11 | brlcad | howdy yukonbob |
| 03:01.22 | yukonbob | what's shaking, brlcad? |
| 03:03.20 | CIA-33 | BRL-CAD: 03johnranderson * r30574 10/brlcad/trunk/src/tclscripts/mged/ (make_solid.tcl openw.tcl tclIndex): added binunif to create menu |
| 03:03.45 | brlcad | o.0 |
| 03:03.48 | brlcad | not much |
| 03:04.10 | brlcad | Mr. Anderson has been busy! |
| 03:05.27 | *** join/#brlcad ibot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) | |
| 03:05.27 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || Channel logs at http://ibot.rikers.org/%23brlcad/ || Release 7.12.0 imminent (no really!) || BRL-CAD is participating in the 2008 Google Summer of Code, see http://brlcad.org/wiki/Google_Summer_of_Code and join the developer mailing list || GSoC application submissions are now open, submission deadline is March 31st | |
| 03:05.33 | yukonbob | <PROTECTED> |
| 03:06.19 | brlcad | <PROTECTED> |
| 03:06.49 | yukonbob | heh -- /me locked self out of ssh'd/screen'd session w/ ipfw -- hence the (non)garbage |
| 03:07.13 | brlcad | fun |
| 03:07.46 | yukonbob | only briefly, thank goodness -- both machines happen to be in front of me too, so not that scary. |
| 03:08.50 | yukonbob | brlcad: you catch the brief dialogue other day (I don't remember if you were directly involved) about text in BRL-CAD? |
| 03:10.19 | brlcad | musta missed that |
| 03:11.03 | brlcad | it needs to be better documented and exposed in simple routines (like "draw this text here in 2D/3D") |
| 03:11.42 | brlcad | brb |
| 03:11.46 | yukonbob | hrmm -- ok -- part of it was about displaying text, and I think there are two basic options (iiuc) text-as-objects (a la POVRay (which is awesome)), or using the attributes of objects, and some auxillary display mech. |
| 03:11.50 | yukonbob | waits |
| 03:19.46 | yukonbob | grabs other 'puter, starts playing with graphing software |
| 03:43.25 | brlcad | yeah, text-as-objects would be annotation support |
| 03:43.37 | *** join/#brlcad iraytrace (n=iraytrac@c-67-172-239-24.hsd1.ut.comcast.net) | |
| 03:43.46 | brlcad | you can use attributes to stash pretty much any random info, but not quite the same beast |
| 03:51.00 | yukonbob | returns -- ok -- here's my "I wonder" though: if one had text attributes, could one parse the attributes and annotate a display... so my question I guess is: "What is the display?", including the on-screen version, and a dumpted-to-file version -- does rt do the rendering and pass it off to something else, or is rt's work the end-all-be-all? Is Tcl involved in a pipeline here? |
| 03:51.16 | yukonbob | *dumped-to-file |
| 03:59.32 | yukonbob | hits hay -- ciao, all. |
| 04:18.21 | brlcad | rt is the end-all-be-all of geometric display -- it certainly "could" pass it through another filter later, but that certainly would not be ray-tracing (and doe not presently occur) |
| 04:19.32 | yukonbob | returns briefly |
| 04:20.07 | brlcad | there is also a question of what you mean by display -- there is a "wireframe" display both projectable in 2D and in 3D, and possible 3D visualization (e.g. opengl), and 3D projected to 2D rasterization (i.e. ray-tracing) |
| 04:21.14 | yukonbob | ok -- imagine if rt generated 'hints' for attributes to look-up and x,y positions to locate the attribute values, one could have the bitmap returned by rt annotated after-the-fact; not by ray-tracing, but some simple 2d-based annotation... |
| 04:21.31 | brlcad | so an object could have some textual label attribute, for example -- you could easily show a wireframe for it (perhaps even in a given font) and in 2D or 3D |
| 04:21.57 | brlcad | but then that same label wouldn't ray-trace unless you give it "thickness" |
| 04:23.17 | brlcad | which we could do too .. e.g. assign annotations a default thickness of the current rendering cell size by default |
| 04:23.50 | brlcad | so the text would rasterize during ray-trace |
| 04:24.05 | brlcad | another possibility would be a separate render pass similar to what rtwizard does |
| 04:24.24 | brlcad | where you'd have a tool that would just rasterize the annotations onto a given image context |
| 04:24.32 | yukonbob | what if rt said in it's output "here's some meta-info about what I just gave you: there's an object foo, with center-of-mass at 200x99; there's an object bar with a center-of-mass at 40x90; there's an object baz with c-o-m @ 1000x777", and some other program took that, looked up the attributes (if available) for those objects, and then printed at the c-o-m appropriate labels (gleened from attributes) on the bitmap? |
| 04:25.42 | brlcad | that would be the separate pass tool I mentioned, albeit a slight variation for it to use the output -- it really just needs the view and it could figure out the rest |
| 04:26.10 | yukonbob | is there such a tool atm? |
| 04:29.46 | yukonbob | really hits hay -- chat later :) (I'll check for response in AM) |
| 04:29.57 | brlcad | there is not such a tool at the moment |
| 04:30.10 | brlcad | there are no annotations at the moment |
| 04:30.15 | brlcad | that's why it's on the list :) |
| 04:52.14 | CIA-33 | BRL-CAD: 03brlcad * r30575 10/brlcad/trunk/NEWS: john added support to mged for creating binunif objects via the Create menu |
| 05:03.40 | CIA-33 | BRL-CAD: 03brlcad * r30576 10/brlcad/trunk/TODO: next release should be 'soon' so only promote rtarea, clone, and itcl build support |
| 05:05.52 | CIA-33 | BRL-CAD: 03brlcad * r30577 10/brlcad/trunk/src/ (9 files in 3 dirs): consistently spell out all references to 'prims' as primitives to help usability. not documenting in news cause it's stupid.. |
| 05:15.46 | CIA-33 | BRL-CAD: 03brlcad * r30578 10/brlcad/trunk/src/ (conv/off/off-g.c irprep/all_sf.c libpkg/pkg.c): remove t parameter from open calls. it's not posix and not needed (text mode is default on windows). |
| 05:29.59 | CIA-33 | BRL-CAD: 03brlcad * r30579 10/brlcad/trunk/src/libbu/log.c: cleanup, remove dead code |
| 06:28.46 | CIA-33 | BRL-CAD: 03brlcad * r30580 10/brlcad/trunk/src/util/pl-dm.c: make pl-dm compile once again, de knrify it, remove code not longer relevant |
| 06:33.40 | CIA-33 | BRL-CAD: 03brlcad * r30581 10/brlcad/trunk/src/util/pl-dm.c: |
| 06:33.40 | CIA-33 | BRL-CAD: rip out the ogl and wgl code. it's highly unlikely that wgl will work without |
| 06:33.40 | CIA-33 | BRL-CAD: modifications given X is required. also, it's just a horrible way to support N |
| 06:33.40 | CIA-33 | BRL-CAD: dm interfaces .. the point is supposed to be that the dm interface incapsulates |
| 06:33.40 | CIA-33 | BRL-CAD: against doing this kind of stuff. |
| 06:38.09 | CIA-33 | BRL-CAD: 03brlcad * r30582 10/brlcad/trunk/src/util/Makefile.am: add pl-dm back to the build if X is available |
| 06:39.38 | CIA-33 | BRL-CAD: 03brlcad * r30583 10/brlcad/trunk/src/util/Makefile.am: ws |
| 07:02.03 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 07:59.20 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 08:28.46 | *** part/#brlcad jdoliner (n=jdoliner@cpe-24-59-109-153.twcny.res.rr.com) | |
| 08:46.56 | *** join/#brlcad cad88 (n=3af7f95b@bz.bzflag.bz) | |
| 09:17.14 | *** join/#brlcad pacman87 (i=127@resnet-45-192.dorm.utexas.edu) | |
| 10:18.17 | *** join/#brlcad hippieindamakin8 (n=hippiein@203.200.95.130) | |
| 13:12.23 | CIA-33 | BRL-CAD: 03brlcad * r30584 10/brlcad/trunk/BUGS: |
| 13:12.23 | CIA-33 | BRL-CAD: the opengl framebuffer problem on mac os x where parallel rendering was causing |
| 13:12.23 | CIA-33 | BRL-CAD: it to fail was indeed fixed (by adding the necessary requests for each thread to |
| 13:12.23 | CIA-33 | BRL-CAD: acquire the context), but something since then has changed -- it's just giving a |
| 13:12.23 | CIA-33 | BRL-CAD: blank window at the moment |
| 13:14.45 | CIA-33 | BRL-CAD: 03brlcad * r30585 10/brlcad/trunk/BUGS: actually it is rendering, just not updating the window apparently until it gets expose events |
| 13:21.10 | starseeker | scowls at Axiom and fires up Maxima instead... |
| 13:51.48 | *** join/#brlcad PrezKennedy (i=Matthew@74.86.45.130) | |
| 13:55.52 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 14:22.09 | brlcad | hello d_rossberg ! |
| 14:38.13 | ``Erik | *yargn* |
| 14:50.06 | d_rossberg | hello brlcad! |
| 14:51.17 | d_rossberg | i had to feed the rabbits |
| 14:58.57 | brlcad | heh |
| 14:59.05 | brlcad | did not know you had rabbits |
| 15:03.28 | d_rossberg | i don't have rabbits - i have to feed them (at least today) |
| 15:04.48 | d_rossberg | feeds the rabits of his daughter |
| 15:10.22 | brlcad | mmm.. good eating |
| 15:10.27 | brlcad | :) |
| 15:16.59 | d_rossberg | ??? i hope there is a difference between "of" and "to" |
| 15:17.49 | *** join/#brlcad Elperion (n=Bary@p54875FAB.dip.t-dialin.net) | |
| 15:21.56 | brlcad | hehe |
| 16:20.27 | *** join/#brlcad docelic (n=docelic@78.134.200.134) | |
| 16:26.49 | *** join/#brlcad pacman87 (i=127@resnet-45-192.dorm.utexas.edu) | |
| 18:04.39 | *** join/#brlcad b0ef (n=b0ef@062016141231.customer.alfanett.no) | |
| 19:13.13 | ``Erik | holy hand grenade of antioch? |
| 19:51.11 | brlcad | heya pacman87 |
| 19:57.03 | pacman87 | brlcad: hi |
| 20:00.47 | brlcad | make any progress on that bug? |
| 20:02.41 | pacman87 | line 570 in ged.c |
| 20:03.18 | pacman87 | then it runs into a whole mess of tcl stuff |
| 20:04.23 | pacman87 | though when i just let it run, and did a ctrl+c at the hang, 'where' told me i was in the openGL libs |
| 20:09.47 | brlcad | yeah, it's definitely related to the embedded display manager |
| 20:10.04 | pacman87 | i got the latest nvidia driver last night, hoping to improve my bzflag framerate (from 100.xx to 169.12) |
| 20:10.09 | pacman87 | and now it doesn't hang anymore |
| 20:10.18 | brlcad | heh |
| 20:11.50 | pacman87 | though when i click in the graphics window, my other open windows get messed up |
| 20:11.58 | pacman87 | and that didn't happen before |
| 20:12.36 | pacman87 | the horizontal lines seem to be drawing at the wrong height |
| 20:13.05 | pacman87 | offset +/- a bit |
| 20:13.07 | *** join/#brlcad naomi_ (n=naomi@c-71-233-212-32.hsd1.ma.comcast.net) | |
| 20:18.12 | pacman87 | brb, restarting X |
| 20:19.51 | *** join/#brlcad pacman87 (i=127@resnet-45-192.dorm.utexas.edu) | |
| 20:31.32 | *** join/#brlcad cad61 (n=50cab12a@bz.bzflag.bz) | |
| 21:11.03 | *** join/#brlcad clock_ (n=clock@77-56-82-138.dclient.hispeed.ch) | |
| 21:16.56 | CIA-33 | BRL-CAD: 03starseeker * r30586 10/brlcad/trunk/src/proc-db/tire.c: Add first exploratory coding efforts related to tire proc-db. |
| 21:17.25 | CIA-33 | BRL-CAD: 03starseeker * r30587 10/brlcad/trunk/src/proc-db/Makefile.am: Add tire.c to proc-db Makefile. |
| 21:21.56 | *** join/#brlcad Elperion (n=Bary@p54875FAB.dip.t-dialin.net) | |
| 21:34.26 | *** join/#brlcad naomi__ (n=naomi@c-71-233-212-32.hsd1.ma.comcast.net) | |
| 21:35.06 | *** join/#brlcad Elperion (n=Bary@p54875FAB.dip.t-dialin.net) | |
| 21:37.22 | *** join/#brlcad Elperion (n=Bary@p54875FAB.dip.t-dialin.net) | |
| 21:55.09 | brlcad | pacman87: hum -- you might have better experience with 7.10.4 then .. there were changes made in 7.12.0 related to the display manager (that fixed several other bugs but apparently are causing your poblems) -- it's related to directcolor and colormapping |
| 22:07.51 | brlcad | if you want another point you can break on you could probably add a breakpoint for either ogl_open or dm_open in the debugger before that 'gui' tcl eval line on 570 |
| 22:27.08 | CIA-33 | BRL-CAD: 03brlcad * r30588 10/brlcad/trunk/src/util/Makefile.am: need tk_cppflags |
| 22:52.12 | *** join/#brlcad naomi_ (n=naomi@c-71-192-44-55.hsd1.ma.comcast.net) | |
| 23:32.41 | yukonbob | waves in, reads scrollback |
| 23:36.11 | starseeker | waves back |
| 23:39.51 | yukonbob | hey starseeker |
| 23:40.23 | starseeker | how goes it? |
| 23:41.05 | yukonbob | not bad, I guess... I've been spending too much time on airplanes, and I don't have 7.12 running yet, but I'm alright :) |
| 23:42.44 | brlcad | so there's a slim chance that there might be a gsoc submission extension -- I wouldn't bank on it, but it'll depend how many students storm in over the weekend |
| 23:43.39 | yukonbob | when is the deadline (as it stands atm)? |
| 23:43.56 | brlcad | late monday |
| 23:44.07 | yukonbob | nods |
| 23:44.26 | pacman87 | what's the current application count? |
| 23:44.51 | brlcad | last year, 75% of the submissions came in over the last weekend iirc, but apps were also open for two weeks instead of one, and easter wasn't so early |
| 23:45.25 | brlcad | pacman87: *very* few .. many orgs are at about 1/5th the level they were last year by this time |
| 23:46.03 | brlcad | so that bodes really well for the folks that have been in here and interacting for a while already ;) |
| 23:46.41 | brlcad | especially since we really only want/need about 3 really good students .. |
| 23:50.38 | pacman87 | after running through the 'mug' Mged tutorial, i'm wondering if there's a vector-scale command to stretch/shrink primitives differently along different axes |
| 23:51.54 | brlcad | primitives can be scaled non-uniformly, except the torus |
| 23:52.03 | brlcad | they can't be skewed, though |
| 23:52.09 | brlcad | that's by design |
| 23:52.50 | pacman87 | and the torus was what i wanted to scale (for a better looking handle) |
| 23:53.01 | brlcad | heh |
| 23:53.22 | brlcad | I was just talking about that earlier today |
| 23:53.35 | pacman87 | i could be done using a sweep about an ellipse |
| 23:53.40 | brlcad | I'm thinking to add in support for non-uniform scaling to torus and skewing |
| 23:53.53 | pacman87 | *it could |
| 23:54.09 | brlcad | sweeps are on the gsoc new primitives list |
| 23:54.59 | pacman87 | yeah, i figured i would start with the revolve, then do the sweep next |
| 23:55.43 | brlcad | yeah, revolve should be pretty easy |
| 23:55.54 | brlcad | sweep can get *really* tricky |
| 23:56.12 | brlcad | especially if you allow 2D and 3D sweeps and if you allow an orientation vector |
| 23:56.33 | pacman87 | path + orientation vector normal to path? |
| 23:57.15 | pacman87 | that was another question i had about using 3D shapes as the base for these new primitives |
| 23:57.17 | brlcad | i mean an orientation vector maybe not normal to path |
| 23:57.26 | brlcad | as well as a twist |
| 23:58.03 | brlcad | i.e. two vectors and the path |
| 23:59.53 | pacman87 | twist = rotation about the path, and orientation = offset between path and shape's surface normal? |