| 01:31.15 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 03:50.09 | *** join/#brlcad andrecastelo (n=chatzill@189.71.31.179) |
| 05:46.54 | *** join/#brlcad clock_ (n=clock@77-56-87-218.dclient.hispeed.ch) |
| 06:14.41 | yukonbob | hello , cadheds |
| 06:14.47 | yukonbob | *cadheads |
| 06:15.30 | *** join/#brlcad andrecastelo_ (n=chatzill@189.71.14.236) |
| 06:15.59 | yukonbob | uhhhhhhh |
| 06:16.29 | yukonbob | there are andrecastelo's popping up like mushrooms in here.. |
| 06:16.37 | yukonbob | set out the traps... |
| 06:52.29 | brlcad | howdy yukonbob |
| 07:13.24 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 07:33.13 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 08:30.09 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) |
| 10:08.06 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) |
| 10:10.02 | mafm | hello |
| 10:13.28 | *** join/#brlcad Mouette (n=root@fw1.phys.sinica.edu.tw) |
| 10:39.18 | *** join/#brlcad andrecastelo__ (n=chatzill@189.71.13.212) |
| 12:21.11 | *** join/#brlcad andrecastelo__ (n=chatzill@189.71.13.212) |
| 12:38.06 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) |
| 13:11.59 | pacman87 | morning, all |
| 13:14.09 | mafm | morning |
| 13:56.36 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 14:42.22 | pacman87 | d_rossberg & brlcad: the revolve axis is currently set as the sketch's y-axis. it would be fairly easy to allow the user to specify a different x coordinate to revolve about -- would this be useful, or would it be better assume that the sketch is setup properly? |
| 14:43.24 | pacman87 | if the sketch editor could be extended to handle transformations (translation, rotation, scale) |
| 14:43.58 | pacman87 | that would probably work better |
| 14:44.31 | pacman87 | allow more flexablilty with sketches, and avoid the extra computation doing the translation each time in revolve |
| 14:45.50 | brlcad | ewilhelm: yes |
| 14:51.33 | *** join/#brlcad prasad_ (n=psilva@h-67-103-183-185.mclnva23.covad.net) |
| 14:59.45 | ``Erik | O.o |
| 15:05.09 | brlcad | pacman87: "no comment" .. i.e. I defer to you and d_rossberg on that one |
| 15:05.47 | pacman87 | i'm assuming the curent sketch editor doesnt already do that... |
| 15:08.26 | brlcad | present sketch editor is crappy |
| 15:09.11 | ``Erik | hum, now tcl and tk have 8.5.3 out |
| 15:09.13 | brlcad | it'll let you translate, but only edge/curve at a time |
| 15:09.35 | brlcad | presently no scaling or rotation, though they would be trivial to add |
| 15:10.02 | brlcad | you just have this absolute 2D coordinate space that you work in, create your sketch |
| 15:11.13 | pacman87 | should i start a 'wish list' for the editor? |
| 15:13.06 | brlcad | sure |
| 15:14.11 | brlcad | could add a section to the TODO specifically for it or a new file somewhere in doc or in src/primitives/sketch etc |
| 15:14.52 | ``Erik | it might be better to add it to the orange page or make something similar to that, then migrate those to the TODO in svn when people agree? |
| 15:15.46 | d_rossberg | pacman87: to use the y-axis as the revolve axis is ok for now |
| 15:16.35 | pacman87 | how much sketch checking should i do? |
| 15:17.00 | pacman87 | ie, make sure it's a closed loop? |
| 15:17.07 | d_rossberg | what kind of checks do you need |
| 15:17.52 | d_rossberg | you could also have some kind of default behavior if it's not closed |
| 15:18.02 | pacman87 | closed loop, everything on the + side of the y-axis |
| 15:18.49 | d_rossberg | why not on the - side? |
| 15:19.26 | pacman87 | my algorithm for partial revolves assumes + only |
| 15:20.25 | pacman87 | is there an application for partial revolves on the - side too? |
| 15:22.49 | d_rossberg | i don't know (at the moment) but you can have a sketch with the rotation axis moving through (but this can be done by two rotatons too) |
| 15:23.14 | d_rossberg | pacman97: BTW the sketch_name in rt_revolve_internal has a problem |
| 15:23.53 | d_rossberg | in asc2g there will be no memory allocated for it, and in ifree not freed |
| 15:24.13 | pacman87 | i noticed the asc2g problem |
| 15:24.18 | d_rossberg | maybe you should use bu_vls there |
| 15:25.02 | d_rossberg | (%S format in bu_structparse) |
| 15:25.21 | d_rossberg | see the dsp primitive for reference |
| 15:25.41 | pacman87 | ok, i was basing it more on the extrude |
| 15:27.00 | d_rossberg | the extrude has it's own adjust function |
| 15:40.56 | *** join/#brlcad louipc (n=louipc@206-248-164-28.dsl.teksavvy.com) |
| 15:51.08 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) |
| 16:57.20 | *** join/#brlcad docelic (n=docelic@78.134.201.30) |
| 17:00.34 | brlcad | ``Erik: possibly, though the TODO doesn't cover "big picture"/project goals like the orange page, they tend to be much smaller tasks |
| 17:00.52 | brlcad | a section on the website/wiki would be good for that though, for sure |
| 17:34.03 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 18:05.17 | *** join/#brlcad ilya0044566 (n=q@217.118.79.36) |
| 18:08.05 | ilya0044566 | after the installation, brlcad 7.10 has not offered mr graphical mode in ubuntu 8.04, and i have problems with some libraries for X as Xlib.h. What librarie(s) shall I use? |
| 18:09.47 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) |
| 18:10.47 | ilya0044566 | in linux [ubuntu] - what libraries for X Window system shall I use? do i need something 'huge' as OpenGL? |
| 18:12.28 | ilya0044566 | People leave the room, than they enter the room. It's kind of-a life, it is kind of-a "this's the way life is, yeah..." |
| 18:23.14 | d_rossberg | ilya0044566: you should use the head version from the subversion repository for Ubuntu 8.04 |
| 18:25.00 | mafm | I go now, bye |
| 18:25.06 | ilya0044566 | head version of which librarie - I have non-cheap internet traffic - this is a problem... |
| 18:26.12 | d_rossberg | and for the xlib you need some X development package (xserver-xorg-dev?) |
| 18:28.17 | ilya0044566 | so, after the installation into new system it has offered me only [nu] at the startup... Is it something well-known, or I just 2 greedy 2 install libraries? I'lltry xorg-dev and others... |
| 18:30.11 | d_rossberg | ~brlsvn |
| 18:30.40 | pacman87 | ~svncad |
| 18:30.47 | pacman87 | ~cadsvn |
| 18:30.47 | ibot | To obtain BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad |
| 18:30.49 | ilya0044566 | ~brlsvn - what is it? |
| 18:30.51 | ibot | ilya0044566: okay |
| 18:31.39 | ilya0044566 | "okay" - what is it? |
| 18:31.56 | d_rossberg | ilya0044566: ~cadsvn shown the url uf brl-cad's subversion repository |
| 18:32.23 | ilya0044566 | okay |
| 18:32.28 | d_rossberg | use your subversion client wih this url to check out the latest version of brlcad |
| 18:33.03 | d_rossberg | (~brlsvn was mistyped) |
| 18:34.04 | ilya0044566 | ok, but i'm 2 greedy 2 spend 20 mb of traffic, i'm www.ansysED.narod.ru and i'm new 2 open source... |
| 18:36.21 | d_rossberg | that's probable a problem, brl-cad version 7.12.4 (and probable the versions before) has a problem with Ubuntu 8.04 |
| 18:37.12 | d_rossberg | however, you could try to get the X window working |
| 18:37.27 | ilya0044566 | yes, and ubuntu, probably, might have a lot more libraries at the "plain" installation... |
| 18:38.19 | d_rossberg | by instaling did you install the xserver-xorg-dev package of Ubuntu? |
| 18:39.57 | d_rossberg | or the xorg-dev package? |
| 18:40.08 | ilya0044566 | ther were no any options... it's a cd image... only onr cd, but kubuntu's dvd I had was 'empty' too - I compare it with versions of ASPLinux on 4 cd's... |
| 18:41.13 | pacman87 | d_rossberg: the other thing for checking sketches is the order of the spline curves |
| 18:42.10 | ilya0044566 | i don't really know... "essentials libraries for X window system" - this make a sence... I just can't spend traffic for a while... but i surely will have a brlcad installed! |
| 18:42.25 | d_rossberg | ilya0044566: do you update or upgrade your system via internet? |
| 18:43.13 | ilya0044566 | no, 1mb equals 0.1 US $ |
| 18:44.01 | d_rossberg | ilya0044566: you probaly have to install the development packeges via internet (because they are not essential for using the other software) |
| 18:44.19 | ilya0044566 | ok, ...corporations still 'milking' good guys :( |
| 18:45.27 | ilya0044566 | ok. i need 2 quit now... My frien says his program Pro-Engeneer can point the dimensions to the model, and to prepare views... Without autocad, i want to mix BRLCAD with QCAD... Am I right, or there are another ways? |
| 18:46.42 | ilya0044566 | 'other ways' - to be correct... |
| 18:47.58 | d_rossberg | pacman87: sure, they have to have a low degree (2 or so), will it be done in the prep function? |
| 18:48.11 | ilya0044566 | ok, i quit for about 1.5 days |
| 18:48.27 | *** part/#brlcad ilya0044566 (n=q@217.118.79.36) |
| 18:48.47 | pacman87 | i was thinking about adding a function to sketch.c |
| 18:48.58 | pacman87 | and calling it from rt_revolve_prep() |
| 18:49.07 | pacman87 | since the sweep will need that check too |
| 18:50.25 | d_rossberg | will sweep work with the same degree of spline (i.e. sketch) curves as the revolve? |
| 18:51.09 | pacman87 | yes, that's the plan |
| 18:51.16 | d_rossberg | ... maybe yes if we think of a sweep as a series of revolves (?) |
| 18:53.26 | pacman87 | essentially, yes |
| 18:53.51 | pacman87 | for revolve, i'm mappign the ray into 2d, then finding intersections |
| 18:55.08 | d_rossberg | pacman87: therefore you plan to implement a function which checks the maximum degree of a sketch in sketch.c and call it from revolve.c and sweep.c, that sounds good for me |
| 18:55.49 | pacman87 | what should i name it? |
| 18:56.11 | d_rossberg | as for the closed loop: you can require a closed loop or close it with a default method |
| 18:57.25 | d_rossberg | are there any similar functions to guess the name? |
| 18:57.26 | pacman87 | if it's not closed, the only thing that makes sense is if the two endpoints are on the y-axis |
| 18:58.27 | pacman87 | there's an rt_check_curve() |
| 18:59.11 | d_rossberg | for example, closing the sketch automatically would make the primitive more robust |
| 18:59.27 | pacman87 | ideally, i'd return the degree of the sketch, so if someone else needs it, it's there |
| 18:59.50 | d_rossberg | rt_check_sketch_degree() |
| 18:59.51 | pacman87 | close by line segment from end to start? |
| 19:02.57 | d_rossberg | closing the sketch: from the y-axis to the first point by a straight line, from the last point of one segment to the first point of the next segment by a straight line, from the last point to the y-axis by a straight line (for all: if it is not already closed) |
| 19:04.38 | d_rossberg | the result of automatic closing may be not what the user want but he sees what he did |
| 19:05.15 | d_rossberg | this is better than seeing nothing but the error message |
| 19:05.16 | pacman87 | yeah, depends on how 'smart' i make the algorithm |
| 19:05.31 | pacman87 | since there could be several disjointed segments |
| 19:06.04 | pacman87 | or unconnected sets of segments |
| 19:06.54 | d_rossberg | yes, the sketch can be very ugly, even if it is closed |
| 19:07.11 | pacman87 | self intersecting |
| 19:07.27 | d_rossberg | exactly |
| 19:07.37 | pacman87 | which i don't think will be a problem, other than looking ugly |
| 19:08.35 | d_rossberg | it could be intended to get holes in the solid |
| 19:09.11 | pacman87 | if you have two seperate, independantly closed loops |
| 19:10.14 | pacman87 | the other way to handle open loops is to duplicate all the segments |
| 19:10.18 | pacman87 | forming a shell |
| 19:10.27 | pacman87 | since the hitpoints would be duplicated |
| 19:10.38 | pacman87 | (i ran into this problem with an ill-formed sketch earlier) |
| 19:11.56 | d_rossberg | yes, a double line in the sketch means nothing (no hit) |
| 19:12.29 | pacman87 | i though it was a hit with a zero-length hit segment |
| 19:12.48 | pacman87 | ie, identical in and out points |
| 19:13.47 | d_rossberg | double lines are a common trick to conect two regions in one border line |
| 19:14.33 | d_rossberg | they should be trated as "not there" |
| 19:15.06 | pacman87 | hmmm |
| 19:16.19 | pacman87 | is trying to think of the best way to detect this |
| 19:16.33 | d_rossberg | with double lines you may cut holes in plates if you have to deskribe the plate by one closed borderline |
| 19:17.45 | pacman87 | i'm not seeing it |
| 19:18.37 | pacman87 | say you have three points: (0,0); (0,2); and (1,1) |
| 19:18.51 | pacman87 | and the sketch just has line segments |
| 19:18.54 | pacman87 | so it's a triangle |
| 19:19.04 | d_rossberg | e.g. a wall with a window in it |
| 19:19.51 | d_rossberg | how would you describe this with a single closed border? |
| 19:20.16 | pacman87 | oh, so the sketch outline traces along the middle of the wall, around the window, and back to the edge of teh wall on the same path |
| 19:20.25 | pacman87 | and the overlapping segments cancel |
| 19:20.35 | pacman87 | leaving a window in a wall |
| 19:20.52 | d_rossberg | yep |
| 19:21.22 | pacman87 | where does the 'single' part of the 'single closed border' requirement come from? |
| 19:22.26 | d_rossberg | the structure is much simpler than having a list of closed non overlapping borders |
| 19:24.08 | d_rossberg | a surface has a border and a border is a list of points |
| 19:24.28 | d_rossberg | this is much simpler than "list of list of points" |
| 19:25.23 | d_rossberg | if you need the second you have to compute it from the first one |
| 19:27.21 | pacman87 | i though the sketch primitive could handle multiple closed loops |
| 19:28.30 | pacman87 | and if those loops overlap, then that'd be the same as a self-intersecting closed loop |
| 19:29.46 | d_rossberg | the sketch primitive has no problem with it |
| 19:30.30 | d_rossberg | but you have to decide if two intersection points are identical or not |
| 19:32.22 | pacman87 | so i'd have to check for zero length segments, and for zero distance between the end/start of adjacent segments |
| 19:35.13 | d_rossberg | i would say yes |
| 19:39.44 | *** join/#brlcad clock_ (n=clock@77-56-95-134.dclient.hispeed.ch) |
| 20:30.17 | brlcad | ~brlsvn is <reply>try ~cadsvn instead |
| 20:30.18 | ibot | brlcad: okay |
| 20:33.07 | brlcad | pacman87: feel free to refactor code needed by multiple primitives into files in src/librt/primitives ;) |
| 20:33.27 | brlcad | nice working pic too :) |
| 20:40.30 | brlcad | pacman87: also adding to the previous discussion, being a solid shotline ray-tracer, no primitives should return zero-thickness ray segments as hits -- they shoule have a non-zero thickness or it's a miss |
| 20:54.37 | *** join/#brlcad homovulgaris (n=homovulg@117.196.130.46) |
| 20:56.05 | pacman87 | so do a NEAR_ZERO( dist1-dist2, SMALL_FASTF)? |
| 21:31.20 | brlcad | that'd be one way |
| 21:32.10 | brlcad | isolates which of his memory chips is bad after about a dozen reboots and tests |
| 21:32.26 | pacman87 | mmmm, memory chips :) |
| 21:38.39 | brlcad | excessively obscure file corruption errors .. that took a while to pin down |
| 21:40.14 | pacman87 | brlcad: what's your opinion on how to handle non-closed sketches? |
| 21:44.21 | brlcad | pacman87: if they're implicitly 'closed' wrt the rotation axis, I think it should behave accordingly -- e.g. points/edges 0,0 -> 1,1 -> 0,1 would be 'implicitly' closed even though there is no 0,1 -> 0,0 closure |
| 21:45.02 | brlcad | where accordingly means that it'd revolve and ray-trace successfully (as an upside-down cone in that example) |
| 21:45.36 | brlcad | if someone defined 0,0 -> 0,1 -> 1,1 though .. hm, dunno |
| 21:46.52 | brlcad | you could close it automatically by implicitly forming an edge to the 0,y value or throw an error (not so useful but not unreasonable) |
| 21:47.46 | brlcad | i suppose you could also auto-close to the original point if they don't form a closed loop (e.g. to 0,0 in that second example instead of to 0,y) .. but that'd be .. wierd |
| 21:48.55 | pacman87 | most 'auto-closing' ends up rather complicated; ie for multiple open sections |
| 21:51.00 | brlcad | determining what it means might get complicated, but the closure itself could be fairly simple |
| 21:52.25 | brlcad | something like "if a segment/curve endpoint has no connected endpoints, connect it to a line segment that goes from the unconnected x,y point to the corresponding 0,y point |
| 21:53.41 | brlcad | you would probably want to throw an error if you close it for the user since I'd still probably consider that an "invalid" ill-defined revolve sketch, but it'd probably be closer to what was expected |
| 21:54.43 | brlcad | so if someone models a simple open 0,0 -> 1,1 straight segment as the curve, it'd make the cone |
| 21:55.11 | brlcad | 1,0 -> 1,1 would make a cylinder, etc |
| 21:55.26 | pacman87 | ok, will do |
| 21:56.45 | brlcad | as if they'd modeled those as 0,0 -> 1,1 -> 0,1 -> 0,0 for the cone and 1,0 -> 1,1 -> 0,1 -> 0,0 -> 1,0 respectively for the cylinder |
| 21:57.51 | brlcad | probably need to test each edge/curve against the y-axis as a bisector, so you can insert the corresponding points/edges |
| 21:58.55 | pacman87 | so we're still ignoring everything on the (-) side of y? |
| 22:00.31 | pacman87 | one other question: should i modify the actual sketch (add the extra points/segments) or leave it alone? |
| 22:00.48 | pacman87 | modifying the sketch would be easier for me |
| 22:00.51 | brlcad | hm? not really ignoring it |
| 22:02.14 | brlcad | 0,0 -> -1,0 -> 1,1 -> 0,1 would be perfectly valid I would think (two cones that touch tip to tip) |
| 22:02.35 | pacman87 | that's the -x side |
| 22:02.41 | pacman87 | i was referring to the -y side |
| 22:02.45 | brlcad | ah ah |
| 22:03.23 | brlcad | how's -y any different? |
| 22:03.35 | pacman87 | wait, i just confused myself |
| 22:03.41 | brlcad | translate all the values down and it works just fine |
| 22:04.05 | pacman87 | invalid | valid |
| 22:04.08 | pacman87 | axis ^ |
| 22:04.32 | brlcad | in fact, to make your processing simple, you may want to do exactly that -- translate all values into positive xy 'normalized' coordinates |
| 22:05.41 | brlcad | you'd have to translate the ray by the same amount, but it should remove sign problems when evaluating |
| 22:06.11 | pacman87 | let me ask as an open question: what should happen when a circle centered at 0,0 is revolved through 90 degrees? |
| 22:07.29 | brlcad | two quarter-sphere wedges |
| 22:08.08 | pacman87 | ok, that gets a bit more difficult |
| 22:10.03 | brlcad | hm, I take it back about translating to positive first-quadrant coordinates .. that might cause more problems than it solves |
| 22:10.34 | pacman87 | yeah, it's working perfectly when everything has a positive x coord |
| 22:10.57 | pacman87 | s/perfectly/perfectly for straight lines ;) |
| 22:11.57 | brlcad | what about automatically trimming the curves like I suggested -- bisect all curves against the x and y axis so you can evaluate all curves for each of the four quadrants consistently? |
| 22:12.45 | brlcad | since if you got it working for +x, should be a few flips of sign to get the other quadrants |
| 22:12.48 | pacman87 | the y coordinate doesn't working |
| 22:12.55 | pacman87 | doesn't matter* |
| 22:13.25 | brlcad | so only bisect with the x-axis |
| 22:13.37 | brlcad | er, y-axis |
| 22:14.12 | pacman87 | what should result from a triangle at -1,0 1,0 1,2? |
| 22:14.21 | brlcad | then all your x coordinate signs are flipped and only solid for angles 90->270 |
| 22:15.40 | pacman87 | i could pick up the hits with -x coords by using both sides of my projected hyperbola |
| 22:15.44 | brlcad | I'd think a cylinder, no different than 0,0 -> 1,0 -> 1,2 -> 1,0 |
| 22:16.28 | brlcad | testing hits, you'd get solids on both the left and right, but the segments would overlap so you'd combine them (and get the cynlinder since the +x side encompasses) |
| 22:16.54 | pacman87 | so i'd have to keep the hit lists seperate |
| 22:17.43 | brlcad | yeah, you wouldn't have your answer until you evaluate both sides |
| 22:18.14 | pacman87 | which doesnt' really have any computational advantages over just using two revolves |
| 22:18.18 | brlcad | pretty simple book-keeping though, some of the other primitives have to do that |
| 22:18.35 | pacman87 | which primitives? |
| 22:19.10 | brlcad | yeah, don't think there are any computational advantages other than they overlap as *one* primitive so you would only ever get one segment back |
| 22:19.44 | brlcad | whereas if I actually made two revolve primitives, that would be an overlap -- I'd have to union them at a sub-region level |
| 22:21.17 | pacman87 | is that really a problem? |
| 22:22.53 | brlcad | not really -- they are able to do that regardless |
| 22:23.25 | brlcad | the question is more what should a single primitive do -- your -1,0 1,0 1,2 should work I think |
| 22:24.03 | pacman87 | it would do the same by ignoring the -x hits (only for full revolve, though) |
| 22:24.25 | brlcad | in that case it would |
| 22:24.39 | pacman87 | if it was flipped, it'd be different |
| 22:24.44 | brlcad | for other cases, it wouldn't (like your sphere rotated by 90) |
| 22:25.13 | brlcad | s/sphere/circle/ |
| 22:25.46 | brlcad | or even -1,-1 -> 1,1 (two cones) |
| 22:27.17 | pacman87 | yeah, partial revolves are a major difference |
| 22:30.02 | brlcad | if you a) break up prep()/shot() into a left/right case for +-x and b) close all open edges to the y-axis .. should give you a consistent means to test intersection |
| 22:31.24 | brlcad | kicks CIA-22 |
| 22:31.25 | CIA-22 | ow |
| 22:32.15 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 22:50.57 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) |