| 00:14.15 | *** join/#brlcad iraytrace (n=iraytrac@cocoa.sci.utah.edu) |
| 01:02.04 | *** join/#brlcad andrecastelo (n=chatzill@189.71.41.1) |
| 01:03.06 | andrecastelo | good evening everyone ;) |
| 01:06.47 | hippieindamakin8 | good morning andrecastelo |
| 01:25.12 | brlcad | ahhh, waht a day |
| 01:31.10 | spike_ | waves at everyone |
| 01:38.12 | andrecastelo | hey brlcad |
| 01:38.28 | andrecastelo | is there a problem if i change my mind from implementing MLT in C++ to implement it in C ??? :) |
| 01:41.45 | brlcad | andrecastelo: heh |
| 01:41.51 | brlcad | what's the reasoning? |
| 01:41.57 | andrecastelo | well |
| 01:42.33 | andrecastelo | originally i thought encapsulation, abstraction and operator overloading would benefit the whole algorithm |
| 01:42.40 | *** join/#brlcad DaytonaJohn (n=jra@c-68-55-36-65.hsd1.md.comcast.net) |
| 01:43.14 | brlcad | andrecastelo: yeah, I don't see that as being a good reason to go with it -- I presumed you were merely justifying what is familiar to you ;) |
| 01:43.19 | andrecastelo | but some parts of the code written would eventually be incompatible with existing code.. part of the code written in C++ wouldn't be usable in other C code |
| 01:43.30 | brlcad | do you have a stronger basis in OO or procedural? |
| 01:43.41 | andrecastelo | and there is no need to rewrite basic structures |
| 01:43.48 | andrecastelo | in OO |
| 01:43.48 | brlcad | it just would have to be isolated as c++ |
| 01:44.33 | brlcad | yeah, rewriting basic structures would be frowned -- you'd still be expected to write classes that reuse libbu/libbn/librt as needed |
| 01:45.21 | andrecastelo | the requirement for a patch is a great thing indeed |
| 01:46.04 | andrecastelo | i'll update my application accordingly |
| 01:48.30 | brlcad | great |
| 01:54.54 | brlcad | for what it's worth, erik doesn't like OO (unless it's pure), procedural is probably a step up for him but still below functional ... he's a schemer ;) |
| 01:55.09 | hippieindamakin8 | brlcad i posted a reply |
| 01:55.14 | brlcad | hippieindamakin8: ok |
| 01:55.15 | brlcad | thanks |
| 01:55.28 | hippieindamakin8 | hey can we discuss it rt now ? |
| 01:56.24 | andrecastelo | brlcad: like ruby ? |
| 01:56.57 | brlcad | like smalltalk, can't speak for him re: ruby |
| 01:57.21 | brlcad | likes ruby .. about as impractical as smalltalk, but a nice language |
| 01:58.20 | andrecastelo | (is Ada OO ?) |
| 01:58.22 | brlcad | andrecastelo: either way, you still just need to be able to justify your design decisions regardless of the mentor's preference ;) |
| 01:58.48 | andrecastelo | brlcad: i justified it and i hope it's acceptable |
| 01:59.18 | brlcad | though I would heavily argue against a functional impl for integration/maintainability reasons :) |
| 01:59.46 | brlcad | hippieindamakin8: i'm not sure what you'd like to discuss |
| 02:00.08 | andrecastelo | brlcad: you are pro C++ ? |
| 02:00.39 | brlcad | in general or for your project? |
| 02:00.52 | brlcad | I could see going either way for your project |
| 02:01.37 | brlcad | if it is C++, there are a slew of stipulations like still reusing existing libs as much possible and not mixing C++ into any existing C facilities |
| 02:03.27 | andrecastelo | i see.. |
| 02:03.46 | brlcad | andrecastelo: your app is probably at the point that it should start moving to the wiki too if you haven't started already |
| 02:04.31 | andrecastelo | yeah, it's too big ehhehe |
| 02:05.21 | andrecastelo | on a related note - i'm having some weird issues trying to compile some of the code i've written |
| 02:05.41 | andrecastelo | this is the compile log -> http://pastebin.com/d5eb121ff and this is the code -> http://pastebin.com/d1b8b3aee |
| 02:07.02 | andrecastelo | what you think is wrong ? |
| 02:07.24 | brlcad | "inconsistent dll linkage" .. sounds like you're trying to compile a file as both C and C++ |
| 02:07.55 | brlcad | or both imported and exported |
| 02:08.45 | andrecastelo | actually i haven't compile the version i'm with, i'm guessing that's the problem |
| 02:09.30 | andrecastelo | (i had that warning before and could compile rtarea) |
| 02:09.44 | andrecastelo | i'll build everything and get back to you after hehehe |
| 02:09.45 | brlcad | andrecastelo: OOh.. tsk tsk |
| 02:10.00 | brlcad | http://pastebin.com/d1b8b3aee <-- bad :) |
| 02:10.17 | brlcad | you're compiling C code, not C++ |
| 02:10.25 | brlcad | remember your scoping declaration rules for C |
| 02:13.18 | andrecastelo | bad code?? |
| 02:13.25 | andrecastelo | why exactly ? |
| 02:17.12 | brlcad | that hilighted line is an error .. think about why :) |
| 02:21.47 | andrecastelo | ehhe ok ok |
| 02:21.56 | pacman87 | brlcad: http://brlcad.org/wiki/Revolve_Primitive |
| 02:24.58 | brlcad | pacman87: I read it :) |
| 02:25.05 | brlcad | well, skimmed it for now :) |
| 02:25.59 | brlcad | i'm very dubious as to how you intend to get the profile curve of a given/arbitrary primitive or (even harder) that of a combination |
| 02:26.36 | brlcad | you don't have a reliable method to project the outline onto 2D |
| 02:32.18 | pacman87 | yeah, that's the hardest part |
| 02:32.50 | brlcad | heh, "hardest" is an understatement |
| 02:33.13 | brlcad | makes the shot() routine for sweeps seem like bubble sort |
| 02:33.40 | pacman87 | well, i could calculate it numerically |
| 02:33.57 | pacman87 | it only has to be done once |
| 02:33.59 | pacman87 | then stored |
| 02:36.10 | pacman87 | once the outline is found for each shape, combinations aren't that much more work than getting the outline in the first place |
| 02:37.28 | hippieindamakin8 | ya brlcad i wish not to mix C++ into existinc C facilities but use the existing header and dependancies as it is in the first phase of refactoring the code |
| 02:38.56 | pacman87 | since each shape has a bounding volume, i could do a grid over the plane, and check each point for in/out |
| 02:39.04 | pacman87 | and keep refining the border |
| 02:39.08 | pacman87 | until it meets the tolerance |
| 02:40.53 | brlcad | andrecastelo: hint: search for "declaring variables mid-function" |
| 02:41.03 | pacman87 | for the simpler primitives, it may be possible to solve analytically |
| 02:41.19 | pacman87 | but that's in the 'optimization' phase of my timelime |
| 02:41.25 | andrecastelo | brlcad: oooooohhh |
| 02:41.27 | brlcad | pacman87: yes, but how do you "calculate it numerically" |
| 02:41.53 | pacman87 | given a primitive, get the bounding volume |
| 02:42.16 | pacman87 | intersect that volume with the plane specified for the 2D revolve outline |
| 02:42.20 | brlcad | basically you'd end up point-sampling (i.e. ray-tracing) to find the contour.. :) |
| 02:42.28 | pacman87 | essentially |
| 02:42.35 | andrecastelo | brlcad: i'm building the project i'll try something in a sec |
| 02:42.36 | brlcad | hehe |
| 02:42.41 | pacman87 | but i can ignore everything that's clearly outside or clearly inside |
| 02:43.17 | brlcad | pacman87: well I suppose that will give an approximation -- you'd also then have to derive and fit a series of splines to the contour .. that's not easy |
| 02:43.44 | pacman87 | i never said it'd be easy |
| 02:43.46 | brlcad | just take the case of a projected cube rotated 45 degrees |
| 02:43.49 | pacman87 | just that it's possible |
| 02:44.23 | pacman87 | cutting it somewhere down the middle? |
| 02:44.39 | brlcad | actually finding the four piecewise linear segments would be really hard |
| 02:45.24 | brlcad | especially at each corner .. |
| 02:45.26 | pacman87 | it depends on how the 2D outline is actually stored |
| 02:46.55 | pacman87 | if it's stored as a series of (r,z) points |
| 02:49.50 | pacman87 | check the midpoint of each segment to make sure it's within the tolerance |
| 02:49.56 | pacman87 | if not, add a new point in the middle |
| 02:50.28 | brlcad | hm |
| 02:50.49 | pacman87 | also specify a maximum distance between points |
| 02:51.05 | brlcad | I think there's another way that doesn't require sampling |
| 02:51.08 | pacman87 | to avoid getting (un)lucky on a segment who's midpoint happens to be right |
| 02:51.24 | pacman87 | please share :) |
| 02:51.46 | brlcad | don't know why I didn't think of it |
| 02:52.12 | brlcad | you have the right idea with thinking about it from the perspective of considering the plane |
| 02:53.00 | brlcad | you're already evaluating a given ray during shot() against some contour |
| 02:54.04 | pacman87 | shot() for the revolve? |
| 02:54.49 | brlcad | there's no reason you couldn't just evaluate that same ray against the actual primitive/combination being revolved and just using it's hit/miss characteristic as the inside/outside result |
| 02:55.59 | brlcad | the trick is that you'll have to figure out where the primitivies/combinations are situated in order to evaluate them |
| 02:56.00 | pacman87 | what if that ray is rotated away from the original primitive, such that the ray misses the original, but should hit the revolved part |
| 02:56.07 | brlcad | which is the same problem you have with sweeps |
| 02:57.49 | brlcad | you'd probably have to perform some sort of newtonian iteration to find the extents .. arg, that'd really be slow as hell |
| 02:58.34 | andrecastelo | (compiled perfectly |
| 02:58.36 | andrecastelo | ) |
| 02:59.32 | *** join/#brlcad justin__ (n=justin@74.92.144.217) |
| 02:59.51 | pacman87 | for rev shot(), you're getting the segment intersected with the base shape, and checking it agianst the outline plane? |
| 03:01.04 | brlcad | sort of |
| 03:01.37 | brlcad | consider a ray being shot at a shape that is centered on the axis of rotation |
| 03:01.50 | pacman87 | symmetric shape or not? |
| 03:01.57 | brlcad | doesn't matter |
| 03:02.07 | pacman87 | ok |
| 03:02.44 | brlcad | what you end up doing is solving the min/max rotation of that shape to find the closest and farthest entry/exit spans |
| 03:03.21 | *** join/#brlcad SWPadnos_ (n=Me@dsl107.esjtvtli.sover.net) |
| 03:04.00 | yukonbob | 1 note while pacman87 is here -- in the into to your posting today... did you mean start and end surfaces will be "flat plates", or "flat planes" (or does it matter? typo/grammar editing is the best I can offer on that posting :) |
| 03:04.11 | brlcad | that's the newtonian iteration I was thinking of, you have to solve the aligned rotations that give you maximal extents .. and that basically amounts to shooting the same ray at that shape with different rotations |
| 03:04.53 | pacman87 | right, that method does a lot of calculation for each shot9) |
| 03:04.55 | pacman87 | shot() |
| 03:05.36 | pacman87 | yukonbob: should probably be planes, thanks for the feedback |
| 03:05.44 | yukonbob | laughs |
| 03:05.52 | yukonbob | yw |
| 03:06.05 | brlcad | pacman87: this is all interesting and something to keep thinking about ... BUT ... I have to admit that I'm lacking faith in finding a "useful" solution in reasonable time -- I'd probably say stick with classic 2D sketches being revolved first and proposing in your timeline to revisit with 3D shapes later as time permits :) |
| 03:06.31 | pacman87 | if you find the outline once per shape, then the ray intersection is a 2D problem |
| 03:06.34 | brlcad | pacman87: no more than sampling to find an outline :) .. should be less if the solver can converge fast enough :) |
| 03:06.51 | pacman87 | right, but the outline only happens once per shape |
| 03:06.57 | pacman87 | not once per ray |
| 03:06.58 | brlcad | except like I said earlier, that approach results in sampling and shape extraction problems |
| 03:07.42 | brlcad | the "real solution" is to complete brep support for all of the primitives, then you'd just project the 3D brep curves onto the 2D plan and have your exact curve |
| 03:07.42 | pacman87 | you dont need to extract the shape if you keep the outline as a set of points |
| 03:07.54 | brlcad | brep support, however, is incomplete |
| 03:08.32 | pacman87 | but yeah, i'll move the 3D shapes to the end under 'additional features' |
| 03:09.13 | *** join/#brlcad hippieindamakin8 (n=hippiein@210.212.55.3) |
| 03:15.01 | andrecastelo | hey brlcad.. i'll keep on working on the patch tomorrow |
| 03:15.09 | andrecastelo | i'm too tired, i'm going to get some sleep |
| 03:15.16 | brlcad | the real question is how you intend to solve sweeps as they're a similar problem |
| 03:15.21 | andrecastelo | cya tomorrow |
| 03:15.27 | brlcad | cya andrecastelo |
| 03:15.48 | brlcad | does not comprehend this "sleep" he speaks of |
| 03:16.29 | pacman87 | brlcad: it's sort of like being knocked unconscious, but you feel better when you wake up |
| 03:18.21 | pacman87 | the sweep will probably have to be done how you describe |
| 03:18.58 | brlcad | dunno, I felt pretty good after the only time i've been unconconscious .. wisdom teeth .. god bless those drugs |
| 03:19.55 | CIA-20 | BRL-CAD: 03starseeker * r30658 10/brlcad/trunk/src/proc-db/tire.c: New way of specifying the sides - hopefully somewhat more robust than previous method. |
| 03:20.36 | starseeker | ``Erik: OK, now what were your tire dimensions again? |
| 03:20.53 | starseeker | may stand a chance of getting them now |
| 03:20.56 | brlcad | pacman87: what do you think about implementing the rt_*_brep() routines as part of getting sweep to work? |
| 03:21.27 | pacman87 | that could be easier/more useful than any other way of doing it |
| 03:22.08 | brlcad | are you familiar with what boundary representation spline surfaces are, how to define/create them? :) |
| 03:23.07 | pacman87 | no, but i could learn :) |
| 03:23.31 | pacman87 | i didnt' know anything about raytracing before i started researching it, either :) |
| 03:23.32 | brlcad | heck if you just worked on revolve, rt_*_brep(), and some sort of rt_project_brep_to_sketch() routine, that would be insanely useful/cool |
| 03:23.54 | brlcad | and probably consume all summer |
| 03:24.07 | brlcad | sweeps then become just a generalized solution |
| 03:24.32 | pacman87 | yeah, i'll have to start researching breps |
| 03:24.42 | brlcad | otherwise maybe limiting both sweep and revolve to sketchs for starters, then working on rt_*_brep() as time permits to get generalized shapes |
| 03:24.47 | pacman87 | when do we finalize exactly the scope of my project? |
| 03:25.02 | brlcad | when you're happy with it and we're happy with it |
| 03:25.26 | pacman87 | sketch only first seems to be a good solution |
| 03:25.32 | brlcad | if you keep going the way you're going, there's little chance for unhappiness :) |
| 03:25.53 | pacman87 | because if i do the 3D stuff without the brep, i'd just have to redo it later |
| 03:25.57 | pacman87 | thanks ;) |
| 03:25.58 | brlcad | save for you being happy and capable of learning the solutions :) |
| 03:26.33 | brlcad | rt_project_brep_to_sketch() would be pretty math-intensive, for example |
| 03:27.04 | brlcad | even just implementing sweep/revolve with sketches isn't easy, but extrude is a good example |
| 03:27.27 | pacman87 | would you want a different project() and intersection() for total outline vs outline in a specified plane? |
| 03:28.09 | brlcad | total outline? |
| 03:28.17 | pacman87 | total outline = shadow |
| 03:28.32 | brlcad | don't see what you mean |
| 03:28.35 | pacman87 | plane outline = slice, ink, and stamp |
| 03:28.53 | pacman87 | ex: sphere |
| 03:28.57 | pacman87 | total outline is great circle |
| 03:29.03 | pacman87 | plane outline is smaller circle |
| 03:29.13 | pacman87 | depending on where the plane cuts the circle |
| 03:29.35 | brlcad | ah, you mean some sort of arbitrary cross-section |
| 03:29.40 | pacman87 | right |
| 03:30.00 | pacman87 | which could also be useful for section views |
| 03:33.03 | brlcad | not sure how useful that would be actually -- even for generating scalable vector draft images you have all curves just projected onto a 2D plane, maybe with hidden edge removal (via projecting surfaces too to 2d patches) |
| 03:33.45 | brlcad | even for revolve, you just need the projected curves |
| 03:34.09 | brlcad | as hm, that's not entirely true I suppose |
| 03:34.16 | starseeker | does little happy dance that things are finally close to Working As Desired and hits the hay |
| 03:34.34 | brlcad | you want just the projected surfaces, not their edges |
| 03:35.03 | brlcad | is thinking out loud |
| 03:36.42 | pacman87 | i'm thinking something like this: http://www.solidsmack.com/wp-content/uploads/2007/08/solidworks-iso-section-04.jpg |
| 03:37.05 | brlcad | nods |
| 03:39.29 | brlcad | pacman87: for that specific image, though, you have other facilities at your disposal since it's still 3D -- you basically evaluate the cut plane as a trimming curve for each surface it itersects |
| 03:40.02 | brlcad | hehe, which maybe is just what you should do too :) |
| 03:40.45 | pacman87 | right, but for a adding a section view to the drawing, you'll need the plane cut outline, not just the shadow |
| 03:40.49 | brlcad | tricky operations -- borderlines implementation of the CSG evaluation of BREP-on-BREP surfaces |
| 03:41.16 | pacman87 | wasn't BREP representations a different GSoC topic? |
| 03:41.19 | brlcad | yep |
| 03:41.26 | pacman87 | anyone interested in it? |
| 03:41.34 | brlcad | there's one proposal for it |
| 03:43.01 | brlcad | what I was saying, though, is that you can get what you're calling a plane cut outline directly .. by evaluating the intersection of the plane surface as a trimming surface on the surfaces of the brep it cuts |
| 03:43.18 | brlcad | you get a series of trimming curves in 3D .. that are all planar |
| 03:43.46 | pacman87 | so brep csg will give you the plane outline already |
| 03:44.30 | brlcad | kinda, that same operation is required to evaluate breps with csg |
| 03:45.28 | brlcad | but it also requires even harder non-planar evaluations .. two arbitrary spline surfaces intersecting in arbitrary ways generating sets of non-planar 3d curves |
| 03:45.52 | brlcad | numerically unstable and hard |
| 03:46.01 | pacman87 | really needs to get some background info |
| 03:46.10 | brlcad | but still critical for what we need ;) |
| 03:47.09 | pacman87 | so the rt_*_brep() function does what exactly? |
| 03:47.16 | brlcad | pacman87: search for "BOOLE" and "ESOLID" -- they were research from a few years ago that implemented what we need (in a manner of speaking), but not production code to say the least |
| 03:47.44 | brlcad | they are good reading material for background information though, as well as just general searches on boundary representation geometry |
| 03:48.04 | brlcad | do you recall the rt_*_nurb() function? |
| 03:48.15 | brlcad | it's the same thing |
| 03:49.12 | brlcad | just that the nurbs routines were never completed and use an obsolete data structure |
| 03:49.57 | brlcad | so the function is actually already implemented for several of the primitives, just needs to be renamed to rt_*_brep() and have the data structures updated to the new openNURBS-based structures |
| 03:51.12 | pacman87 | to summarize: start with revolve using sketch, then sweep using sketch, then rt_*_brep(), then project_brep_to_sketch() |
| 03:52.02 | pacman87 | then add 3D support to sweep (and revolve?) using brep |
| 03:53.17 | brlcad | the basic difference is implicit vs explicit evaluation -- your g_hyp.c uses implicit evaluation in the shot() routine .. the hyperboloid is defined by an implicit equation where you have x^2/a^2 + y^2/a^2 - z^2/c^2 = 1 being solved for a given t parameter |
| 03:54.26 | brlcad | another approach would be to actually have that actual surface in parametric form as a spline surface .. evaluation is considerably different |
| 03:54.56 | brlcad | pacman87: yeah, that sounds like a strong plan I'd be happy with :) |
| 03:55.54 | brlcad | even the reverse order would be fine with me, e.g. brep() then project() then revolve then sweep |
| 03:56.17 | pacman87 | the only difference between the 3D and sketchs is that for 3D, the sketch comes from the brep, right? |
| 03:56.18 | brlcad | as these are all "core tasks" with really high value |
| 03:57.15 | brlcad | what do you mean? |
| 03:57.57 | pacman87 | the initial problem with revolving the 3D shape was in getting the 2D outline |
| 03:58.29 | pacman87 | and project() solves that problem |
| 03:58.46 | brlcad | yes |
| 03:58.48 | pacman87 | but it's not the same as revolving/sweeping the actual 3D shape |
| 03:58.51 | brlcad | should solve it exactly |
| 04:02.11 | pacman87 | because the maximum extents of the projection could happen at different distances along the sweep or different angles around the revolve |
| 04:02.25 | brlcad | yeah, it's not the same ... I believe it is the same if you constrain the revolve/sweep to maintain the object's normal/orientation in the direction of the sweep/rotate |
| 04:03.10 | brlcad | but if you allow the more generalized case that allows the object to reorient/rotate while being swept/revolved, there's a problem |
| 04:03.11 | pacman87 | not quite |
| 04:04.11 | pacman87 | revolving an ellipse with focii at (4,1) and (6, -1) about the z axis |
| 04:05.01 | pacman87 | you can't just project it in the direction of Z cross R |
| 04:05.08 | pacman87 | because the path is curved |
| 04:05.19 | pacman87 | so to get the real outline, you'd need a curved projection |
| 04:06.44 | pacman87 | in the simple case, just take the line segment between them |
| 04:06.59 | pacman87 | if you use the linear projection, Rmin = 4 and Rmax = 6 |
| 04:07.41 | pacman87 | but really, Rmin = sqrt(4^2 + 1^2) and Rmax = sqrt(6^2 + 1^2) |
| 04:09.11 | brlcad | hm, i'm still not seeing the issue -- the ellipse you describe results in an elliptical torus, yes? |
| 04:09.29 | pacman87 | ok, forget the ellipse |
| 04:09.38 | pacman87 | just look at the 2D line segment |
| 04:09.43 | pacman87 | revolve it around the z axis |
| 04:10.13 | pacman87 | the center of the 'object' is at (5,0) |
| 04:10.28 | pacman87 | so it'd be projected along the y axis |
| 04:10.36 | pacman87 | (Z cross R) |
| 04:11.28 | pacman87 | that rotation would give you a donut with Rmin = 4 and Rmax = 6, from projection along y |
| 04:12.09 | pacman87 | you follow up to this point? |
| 04:13.00 | brlcad | probably just needs a visual aid, but so far sounds good |
| 04:13.21 | pacman87 | you get a different width if you take a paintbrush and paint | -> vs / -> |
| 04:14.22 | pacman87 | i'll throw together a diagram |
| 04:17.31 | brlcad | i think we may just be saying the same thing in two different ways too -- I was saying that you *have* to maintain the object's orientation with respect to the rotation, so your / segment (presume facing into display, for example) at the 180 rotation angle is now on the other side of the axis as \ (now facing out of your display) |
| 04:18.25 | brlcad | everything should work out if you keep it oriented, else it can self-intersect, pinch solidity, and other nasty effects |
| 04:18.56 | brlcad | (at least for 3d) |
| 04:20.37 | brlcad | starseeker: if you intend to add units support, see src/libbu/units.c |
| 04:20.50 | pacman87 | https://webspace.utexas.edu/trv82/www/revolve.png |
| 04:20.56 | brlcad | otherwise default should always be mm :) |
| 04:22.09 | pacman87 | medium blue is original shape, cyan is the projected shape, green circle is true revolve bounds, red circle is revolve bounds from projection |
| 04:23.36 | brlcad | AHA, I see what you're trying to show me now, heh :) |
| 04:23.52 | pacman87 | yeah, saved me 1k words :) |
| 04:24.16 | brlcad | I was talking about something a bit different :) |
| 04:25.35 | pacman87 | right, but i'm saying keepign the 2D plane's normal vector along the sweep path won't help my problem |
| 04:26.09 | brlcad | for the general projected 3D case |
| 04:26.11 | pacman87 | if the sweep path is curved |
| 04:26.36 | pacman87 | yes, sweeping with the 2D projection of a 3D shape |
| 04:27.16 | pacman87 | you also have trouble on the sweep if you allow rotation of the 2D outline about the sweep direction |
| 04:27.23 | pacman87 | even if the sweep direction is straight |
| 04:27.48 | brlcad | definitely |
| 04:28.50 | pacman87 | and i can't think of a 'nice' solution to these problems |
| 04:28.50 | brlcad | that's what I was getting at at first about maintaining the orientation |
| 04:29.19 | pacman87 | meaning keep plane normal in line with sweep, and no rotation? |
| 04:29.23 | brlcad | I can see one, but it's still pretty hard |
| 04:31.15 | pacman87 | if i can work out a curved project(), the revolve would be possible |
| 04:31.17 | brlcad | you end up taking your sweep curves (e.g. your green lines in your diagram) and actually create a brep surfaces using those curves and use the original object as the surface coefficients |
| 04:31.50 | brlcad | that, however, is paramount to "cheating" imo -- it's an explicit parametric solution as opposed to an implicit one |
| 04:32.41 | brlcad | could do some research in the literature on implicit sweep objects, there are some papers on the subject (that I lamentably admit I've not read yet) |
| 04:34.35 | pacman87 | the problem with a sweep is that the green curves depend on the curvature of the sweep path |
| 04:34.44 | pacman87 | which is constnat for the revolve, so it's a lot easier |
| 04:35.43 | brlcad | for sweeps, you could start by saying the swept object must be rotationally invariant -- keep if fixed |
| 04:36.49 | pacman87 | disallow rotation about the sweep path? |
| 04:37.34 | brlcad | object rotation, yes |
| 04:37.47 | brlcad | the path is still some arbitrary spline path |
| 04:38.10 | brlcad | hm, somewhat interesting http://www.unknownroad.com/publications/SweepsTRApril2005.pdf |
| 04:39.27 | pacman87 | reads |
| 04:39.46 | brlcad | files for later |
| 04:39.58 | pacman87 | s/reads/skims ;) |
| 04:43.47 | brlcad | mm, interesting http://dimacs.rutgers.edu/Workshops/CompAided/slides/blackmore2.pdf |
| 04:45.20 | brlcad | very similar to what you suggested |
| 04:45.29 | brlcad | 2D scalar fields |
| 05:01.53 | pacman87 | i didnt really read in depth, but it looks like the links just deal with 2D shapes |
| 05:05.27 | brlcad | implicit 2D shapes though |
| 05:06.09 | brlcad | you could leverage that directly with sampling if you *had* to |
| 05:39.28 | *** join/#brlcad clock_ (n=clock@77-56-93-95.dclient.hispeed.ch) |
| 07:04.03 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 07:50.37 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 08:28.09 | brlcad | waves and wanders a bit |
| 10:00.48 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT VICTIM] |
| 10:00.48 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) [NETSPLIT VICTIM] |
| 10:00.49 | *** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos) [NETSPLIT VICTIM] |
| 10:00.49 | *** join/#brlcad Twingy (n=justin@74.92.144.217) [NETSPLIT VICTIM] |
| 10:00.49 | *** join/#brlcad prasad_ (n=psilva@static-70-108-244-218.res.east.verizon.net) [NETSPLIT VICTIM] |
| 10:00.49 | *** join/#brlcad pacman87 (i=127@resnet-45-192.dorm.utexas.edu) [NETSPLIT VICTIM] |
| 10:00.49 | *** join/#brlcad CIA-20 (n=CIA@208.69.182.149) [NETSPLIT VICTIM] |
| 10:00.49 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) [NETSPLIT VICTIM] |
| 10:00.49 | *** join/#brlcad b0ef (n=b0ef@062016141231.customer.alfanett.no) [NETSPLIT VICTIM] |
| 10:00.49 | *** join/#brlcad alex_joni (n=juve@emc/board-of-directors/alexjoni) [NETSPLIT VICTIM] |
| 10:00.49 | *** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 10:23.27 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) |
| 10:25.16 | mafm | hallo |
| 10:35.42 | Axman6 | o/ |
| 10:44.37 | *** join/#brlcad camcorder (n=draco@81.213.157.51) |
| 11:51.17 | starseeker | brlcad: OK, thanks :-). Apparently a lot of US tire size specifications use Inches, so conversion will be needed... |
| 12:00.40 | clock_ | brlcad: I wonder have you ever modelled a ball bearing? |
| 12:00.59 | clock_ | Do the raceways have the same inner diameter as the diameter of the balls? |
| 12:01.05 | clock_ | Some people claim that I think it's bullshit |
| 12:03.05 | archivist | no balls need some clearance |
| 12:03.31 | archivist | also press fit is allowed for in the clearance |
| 12:03.52 | clock_ | I wonder how they get the balls inside |
| 12:04.41 | archivist | without the retaining plates (before they get riveted |
| 12:04.42 | clock_ | do they ram them with such a pressure that the hardened rings elastically deform and make way? |
| 12:05.07 | clock_ | you mean without the cage? |
| 12:05.10 | archivist | all metal is elastic |
| 12:05.41 | clock_ | I may need to model my skateboard in the BRL-CAD |
| 12:05.59 | archivist | yes except for crowded large ring bearings, they have a small groove to let in the balls |
| 12:06.14 | clock_ | yesterday I have mounted my superheavy 30kg 21'' CRT on a wall using a unique DIY space frame design wall mount |
| 12:06.45 | archivist | btw your quit message has an XML error |
| 12:07.11 | clock_ | Oh I see fixed thanks |
| 12:08.14 | clock_ | this space frame is amazing |
| 12:08.30 | clock_ | if you poke at the monitor with a finger slightly, it swings. |
| 12:08.46 | clock_ | But if you grab the holder with two hands and push it forth and back, the monitor stays without movement. |
| 12:08.56 | clock_ | It weighs only 3kg, but is rock solid |
| 12:09.12 | clock_ | Now I understand fully why they use it in cosmic vehicles |
| 13:49.43 | CIA-20 | BRL-CAD: 03starseeker * r30659 10/brlcad/trunk/src/proc-db/tire.c: Clean up unused variables in new specification scheme. |
| 13:58.17 | *** join/#brlcad docelic (n=docelic@78.134.198.227) |
| 14:03.06 | *** part/#brlcad camcorder (n=draco@81.213.157.51) |
| 14:04.03 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 14:33.18 | brlcad | d_rossberg: good morning |
| 14:35.23 | d_rossberg | isn't it almost lunch time? |
| 14:35.32 | prasad_ | indeed |
| 14:37.14 | brlcad | hour or so |
| 14:38.00 | brlcad | ~ugt |
| 14:38.01 | ibot | i heard ugt is Universal Greeting Time. Created in #mipslinux, it is a rule that states that whenever somebody enters an IRC channel it is always morning, and it is always late when the person leaves. The local time of any other people in the channel, including the greeter, is irrelevant. http://www.total-knowledge.com/~ilya/mips/ugt.html |
| 14:40.04 | d_rossberg | ah, somebody spend its rare time creating a rule for it :) |
| 14:57.20 | brlcad | =) |
| 14:58.50 | clock_ | and someone else spent his rare time commenting that somebody spend its rare time creating a rule for it |
| 14:59.41 | brlcad | clock_: curious if john's -k option help your 210x report |
| 15:00.12 | brlcad | it's not a fix, but potentially a big performance opt |
| 15:00.27 | clock_ | brlcad: I don't have rt available here, what does -k do? |
| 15:00.39 | brlcad | it was just added |
| 15:00.42 | brlcad | see your report |
| 15:00.47 | clock_ | what does it do? |
| 15:00.56 | clock_ | the report doesn't say what it does |
| 15:06.59 | brlcad | it's a -k cutting plane option |
| 15:12.43 | yukonbob | morning |
| 15:13.40 | clock_ | http://www.theregister.co.uk/2008/04/11/us_war_robot_rebellion_iraq/ |
| 15:15.33 | brlcad | g'mornin yukonbob |
| 15:21.31 | ``Erik | *readreadread* |
| 15:24.10 | ``Erik | starseeker: 255/40ZR18 (mm/aspect rating inches) |
| 15:26.29 | ``Erik | likes ruby, smalltalk, ocaml, erlang, even objc... was not trying to say "use C, not C++", was just asking for support to the argument that MLT would benefit greatly from classes, encapsulation and operator overloading... |
| 15:26.58 | ``Erik | I do *NOT* like operator overloading :D but classes, namespaces, etc, *shrug* sometimes they're the right tool |
| 15:33.46 | *** join/#brlcad andrecastelo (n=chatzill@189.71.41.1) |
| 15:34.06 | andrecastelo | good morning folks |
| 15:34.14 | ``Erik | greetings, andre |
| 15:34.21 | ``Erik | jabs brlcad with a cattleprod |
| 15:35.06 | ``Erik | <-- wanders off to lunch, bbiab |
| 15:38.55 | *** join/#brlcad docelic (n=docelic@78.134.198.227) |
| 16:45.26 | *** join/#brlcad Elperion (n=Bary@p54873D12.dip.t-dialin.net) |
| 16:47.59 | brlcad | ``Erik: I was at korean |
| 17:13.43 | *** join/#brlcad clock_ (n=clock@77-56-87-36.dclient.hispeed.ch) |
| 17:15.09 | *** join/#brlcad Elperion (n=Bary@p54873D12.dip.t-dialin.net) |
| 17:33.14 | yukonbob | tries to figure out the GSoC spreadsheet... |
| 17:33.47 | yukonbob | ahhh... got it |
| 17:35.00 | yukonbob | (couldn't find "sheet" selector) |
| 17:45.41 | brlcad | :) |
| 18:21.29 | *** join/#brlcad Elperion (n=Bary@p54873D12.dip.t-dialin.net) |
| 18:22.52 | mafm | bye |
| 18:23.59 | CIA-20 | BRL-CAD: 03brlcad * r30660 10/brlcad/trunk/src/libbu/htond.c: cleanup header |
| 18:29.10 | *** join/#brlcad Elperion (n=Bary@p54873D12.dip.t-dialin.net) |
| 18:34.39 | andrecastelo | hey brlcad.. |
| 18:35.23 | andrecastelo | the exposed area center is rather straight forward - get the hit points for the area and do the median |
| 18:35.30 | andrecastelo | but what about the presented area ? |
| 18:36.35 | *** join/#brlcad pacman_87 (i=127@resnet-45-192.dorm.utexas.edu) |
| 18:38.39 | *** join/#brlcad Elperion (n=Bary@p54873D12.dip.t-dialin.net) |
| 18:55.46 | CIA-20 | BRL-CAD: 03starseeker * r30661 10/brlcad/trunk/src/proc-db/tire.c: Experimenting with ways to make reasonable tire shapes from standard input data. |
| 18:59.19 | brlcad | andrecastelo: presented is same as exposed.. just a different set of points |
| 19:00.40 | andrecastelo | yeah but for example, for the exposed area i just recorded every point in the partition->inhit->hitpoint |
| 19:00.56 | andrecastelo | because if the ray hit those points, then the area is exposed, right ? |
| 19:02.11 | brlcad | you're evaluating entire shotlines, there are multiple in/out hits along the shotline -- rays are evaluated all the way through |
| 19:02.29 | brlcad | multiple hits, not just first hit |
| 19:05.21 | andrecastelo | brlcad: so this is wrong ? http://pastebin.com/d4fd4025d (code is from line 45 to 56) |
| 19:05.41 | brlcad | can't get to pastebin.com from here |
| 19:06.07 | andrecastelo | hm ok |
| 19:07.00 | andrecastelo | brlcad: http://rafb.net/p/WQdS4J26.html |
| 19:08.28 | *** join/#brlcad Elperion (n=Bary@p54873D12.dip.t-dialin.net) |
| 19:15.57 | ``Erik | wiggles his toes |
| 19:16.10 | *** join/#brlcad Elperion (n=Bary@p54873D12.dip.t-dialin.net) |
| 19:17.07 | andrecastelo | hey ``Erik, i've responded to your comment on the app |
| 19:17.19 | andrecastelo | did you have the time to see it yet ? |
| 19:17.25 | ``Erik | just read it |
| 19:17.59 | andrecastelo | what did you think ? |
| 19:18.20 | ``Erik | d'no yet, looks like you looked around and thought, which was really what I was trying to kick off :) |
| 19:18.30 | ``Erik | btw, your 'home page' doesn't work, I get a 404 |
| 19:18.34 | brlcad | andrecastelo: exposures are handled in increment_assembly_counter() |
| 19:18.41 | andrecastelo | really? i'll check |
| 19:19.55 | brlcad | andrecastelo: if you look at the struct area, you'll see there are two counters --> "exposures" and "hits" .. just follow the logic where those are incremented |
| 19:19.56 | ``Erik | <-- kinda feels unanswered wrt c vs c++... |
| 19:20.22 | andrecastelo | brlcad: hm ok |
| 19:20.44 | ``Erik | I'm not going to advocate one language or the other, I just want to know exactly why you'd choose one over the other |
| 19:21.57 | ``Erik | brlcad is trying to mkae it sound like I'm gonna ask why you don't propose to write it in scheme, heh :D I just want to know that you understand the various paradigms, the algorithm, and the existing code base well enough to make an informed decision *shrug* |
| 19:22.37 | andrecastelo | ``Erik: i discussed this with brlcad the other night.. i proposed C++ because i'm familiar with it and i thought classes, abstraction and overloading would benefit the project as a whole |
| 19:23.11 | andrecastelo | and in the end, when assembling the algorithm together, the end result would be more readable and simple |
| 19:23.29 | ``Erik | yeah, I saw, and sorry, but that statement seems like fluff to me, I've done enought c++ and java and those to know the broad brush statements *shrug* :) |
| 19:23.31 | andrecastelo | but since there are already basic structures, rewriting them would be a big no no |
| 19:24.31 | ``Erik | re-writing, yes... but wrapping or interfacing is fine *shrug* |
| 19:25.06 | ``Erik | indeed, one of the ideas brlcad put forth at the beginning was a full OO wrapping of the core libraries functionality |
| 19:25.45 | andrecastelo | sorry i thought that wasn't the ideal |
| 19:25.58 | andrecastelo | i thought the general consensus was to keep everything in simple C |
| 19:26.08 | andrecastelo | (i mean standard C) |
| 19:26.36 | ``Erik | opennurbs is c++, we already have c++ in librt *shrug* it wouldn't be a huge issue to go with c++... |
| 19:27.52 | ``Erik | you made a statement that the task would benefit from using features of c++, and then some bland sales pitch on c++, I want to know exactly why those features would aid this... if it's just familiarity, that's cool, if there's something more, I want to know :D |
| 19:28.32 | ``Erik | (sorry if I seem a bit aggressive, I'm a language geek so I'm keen to understanding the various trade-offs when engineering software) |
| 19:29.06 | andrecastelo | i thought of using some oo features because i thought of them as a natural with point and vector handling, you know ? |
| 19:29.19 | andrecastelo | and because i'm more familiar with it and all |
| 19:29.29 | andrecastelo | but i have no problem programming in either language |
| 19:29.35 | ``Erik | hum, we already have point vector and matrix handling in vmath.h (and in tiemath.h, but that's going away) |
| 19:30.41 | andrecastelo | couldn't those functions and macros in vmath.h be wrapped up in a class ? |
| 19:30.54 | ``Erik | sure, what would the advantage of that be? |
| 19:32.53 | andrecastelo | essentially, it would be easier to use points and vectors by those who do not know vmath.h by memory |
| 19:33.03 | ``Erik | hummmm, possibly, I know I have to keep looking stuff up in vmath :D "is it v2add, or vadd2, or ..." :) |
| 19:33.04 | brlcad | with a new class that none of the rest of the devs know by memory? :) |
| 19:33.21 | archivist | andrecastelo, speed of running is often more important than speed of writing software |
| 19:33.33 | brlcad | you'd only know it because you wrote it, otherwise you'd still have to look up the API when you use it |
| 19:33.38 | ``Erik | heh, in this case, yes... in most cases, I'd disagree, archivist :) |
| 19:34.02 | ``Erik | most software spends most of its time waiting for users or network or disk... developer time is far more expensive than cpu time |
| 19:34.21 | archivist | except deep in graphics |
| 19:34.25 | andrecastelo | ``Erik: but he has a point |
| 19:34.44 | andrecastelo | the MLT algorithm is processor intensive, any advantage is welcome, right ? |
| 19:34.49 | ``Erik | (also; it's possible to make very very fast c++... hell, it's even possible to make very fast java if you know how to code) |
| 19:35.06 | ``Erik | <-- likes to play devils advocate, btw... |
| 19:35.10 | brlcad | vmath is very simple and high-performance simply because it's inline'd math -- it's actually rather tricky to get oo-based math that actually out-performs (usually requires some specific templatized foo) |
| 19:35.45 | ``Erik | still wants to ugly up vmath with sse/altivec intrinsics |
| 19:36.43 | brlcad | the tradeoff is maintainability and integration in this case, we have a math lib so I'd be for using that, not wrapping up some new layer for OO sake -- it's enough work to implement MLT without spending time on that |
| 19:37.50 | ``Erik | well, if the lead time in wrapping it is made up for in fast implementation (and still maintainable), then it is worth it... *shrug* that can be a hard call to be correct one, though |
| 19:37.51 | brlcad | ``Erik: that's where it actually gets kinda interesting to abstract it .. multiple impl types in macros is fugly as hell, few things that make templates actually look "good" |
| 19:38.08 | ``Erik | *nod* |
| 19:38.46 | ``Erik | I'm wondering if being compile time specified is acceptable... high performance stuff often has multiple codepaths compiled and does a runtime detect to see which one to use |
| 19:39.04 | ``Erik | so binaries can be used on a 486, but still take advantage of a p4 or athlon |
| 19:39.11 | brlcad | i'd not be convinced of the wrapper though, without lots of profile and cross-platform multi-compiler testing, and that starts adding up to weeks of work/research in itself (especially if mixing in vectorization) |
| 19:39.47 | ``Erik | that'd be a good pub topic :) |
| 19:39.54 | CIA-20 | BRL-CAD: 03starseeker * r30662 10/brlcad/trunk/src/proc-db/tire.c: Whoops - set scale factor to one for this part. |
| 19:39.59 | andrecastelo | the math wrapping up could be something for after the summer |
| 19:40.02 | brlcad | andrecastelo: and yes .. any path tracing is slow as all hell .. it's a brute force solution |
| 19:40.27 | ``Erik | well, a statistical method, anyways |
| 19:40.50 | ``Erik | metropolis tries to cull a lot of the brute force 'waste' off |
| 19:41.07 | brlcad | it's still slow as balls compared to ray-tracing :) |
| 19:41.40 | ``Erik | hehehhee, but mlt IS raytracing :D slow compared to the simple phong+shadow rays approach, sure |
| 19:41.41 | brlcad | like one-to-two orders, the optimizations usually cull some linear time component (like /2) |
| 19:41.52 | yukonbob | ``Erik: re: run-time optimization -- I can't speak from coding experience, but in the case of mplayer for example, runtime cpu detection is available, but contraindicated... one would be better off knowing the arch that is the target and installing the proper CPUFLAGS, no? |
| 19:42.44 | ``Erik | most of my experience with multiple code path stuff comes from proprietary binary distribution stuff, yukon :( chumming with 'tards trying to make the next ultimate video game, etc |
| 19:43.22 | ``Erik | so the object bloat is accepted for the handful of common configurations expected |
| 19:48.17 | brlcad | yeah most games can take a wrapper hit, or poor design hit - they often spend most of their time in the graphics loop |
| 19:48.54 | ``Erik | heh |
| 19:49.21 | ``Erik | and I've seen too much "my game will be fast because I'm writing it in assembly" or "this is going to rock, I'm using pascal with assembly where performance is needed" :/ |
| 19:49.46 | brlcad | I actually implemented a series of vector/matrix replacements for vmath many years ago, as C++ -- it was actually rather complicated and unreliable at the time to match performance, compilers that would ignore the inline directives for example |
| 19:50.12 | brlcad | likes to write in posix shell scripting and drop to assembly where performance is needed |
| 19:50.23 | archivist | ya have to know your algorythm, never mind the language |
| 19:50.43 | archivist | used to do assembler |
| 19:51.27 | brlcad | mips assembler ftw |
| 19:51.29 | ``Erik | has layed down a lot of 6510, 6812, and 80286 assembly :( |
| 19:51.35 | ``Erik | r2k was sweeeet |
| 19:51.56 | ``Erik | the bsd guys would call it "teh sex0rz" |
| 19:51.59 | archivist | I started on 6502 oops that shows my age |
| 19:52.11 | prasad_ | ecmascript ftw |
| 19:52.16 | prasad_ | lolz |
| 19:52.26 | ``Erik | 6510 and 6511 were essentially 6502 with minor tweaks |
| 19:52.33 | ``Erik | c64, c64c, c128... good little boxes |
| 19:52.46 | ``Erik | actually, my first was a z80 cp/m machine |
| 19:52.47 | brlcad | wonders who poisoned prasad_'s coffee |
| 19:53.15 | ``Erik | ecma script because javascript has become a four letter word? :D |
| 19:53.38 | archivist | eczma script |
| 19:53.41 | andrecastelo | realizes he is way too young |
| 19:53.52 | prasad_ | archivist: sounds about right |
| 19:54.16 | ``Erik | heh, everyone was young at some point :D |
| 19:54.44 | andrecastelo | i started programming in mirc script :p |
| 19:54.46 | prasad_ | c++ is where it's at :o |
| 19:54.58 | andrecastelo | then i tried my hand with delphi when i was 13 or 14 |
| 19:55.20 | andrecastelo | i forgot about programming for a while, returning when in college, where i learned java, c and c++ |
| 19:55.21 | ``Erik | winiot *cough* O:-) |
| 19:56.04 | andrecastelo | ``Erik: the 404 is fixed (i hope) |
| 19:56.12 | ``Erik | "like Montezuma's revenge on discount taco night..." |
| 19:57.13 | ``Erik | http://www.smbc-comics.com/comics/20080410.gif |
| 19:58.20 | andrecastelo | lol |
| 20:00.18 | prasad_ | haha |
| 20:27.22 | andrecastelo | well guys |
| 20:27.26 | andrecastelo | off to class |
| 20:27.28 | andrecastelo | cya later |
| 20:31.04 | ``Erik | If you want to make an omelet, you have to kill a few people. |
| 21:04.08 | CIA-20 | BRL-CAD: 03brlcad * r30663 10/brlcad/trunk/regress/flawfinder.sh: fix test failure |
| 21:17.06 | *** join/#brlcad Elperion (n=Bary@p54873D12.dip.t-dialin.net) |
| 21:43.52 | *** join/#brlcad Elperion (n=Bary@p54873D12.dip.t-dialin.net) |
| 21:53.27 | yukonbob | remembers "Montezuma's Revenge" game on the C=64 |
| 22:52.37 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177593626.dsl.bell.ca) |
| 22:53.49 | IriX64 | http://www3.sympatico.ca/mario.dulisse2/jeep.png <---- a usefull motor vehicle :) |
| 22:56.41 | IriX64 | what? nobody else here is a hobbyist? :) |
| 22:57.55 | IriX64 | ``Erik, you were right, found somebody here with 500g drive (sigh) |
| 22:59.26 | brlcad | yukonbob: http://mapy.atari8.info/l-o/montezuma.png :) |
| 22:59.57 | louipc | IriX64: too dark. You don't really get the essense of the hot pink and violet |
| 23:00.43 | IriX64 | louipc: blame brlcads photon mapping |
| 23:01.25 | IriX64 | "hot" pink :) |
| 23:01.57 | brlcad | IriX64: it's like we've told you before -- photon mapping is pointless if you're not going to put the model in a box with a custom light source |
| 23:02.26 | IriX64 | i extracetd all, thought the light source was there |
| 23:02.42 | IriX64 | ill look again |
| 23:02.53 | brlcad | eh, there's still no box |
| 23:02.59 | IriX64 | true |
| 23:03.01 | brlcad | so it isn't going to work |
| 23:03.22 | IriX64 | so you enclose it, map it and then remove the box ;) |
