| 00:04.25 | poolio | returns from his bike ride :) |
| 00:06.38 | starseeker | brlcad: How do I print a substring to a vls, knowing the starting and ending offsets? |
| 00:08.47 | starseeker | nevermind, got it |
| 00:26.10 | *** join/#brlcad homovulgaris (n=d@117.196.140.116) | |
| 00:34.53 | starseeker | um. pastebin is saying forbidden |
| 00:36.14 | brlcad | it's a one-liner .. here :) |
| 00:36.27 | CIA-22 | BRL-CAD: 03brlcad * r31939 10/brlcad/trunk/src/tclscripts/ (9 files in 8 dirs): revert the inadvertent index mods. someone(tm) should make it so this doesn't keep happening. |
| 00:36.45 | starseeker | ret=regcomp(&compiled_regex, "([co]*)([re]*)", 0); |
| 00:36.46 | brlcad | otherwise works for me here |
| 00:37.08 | brlcad | k, that seems alright I think |
| 00:37.33 | starseeker | Then I must be doing the array wrong |
| 00:37.48 | starseeker | regmatch_t result_locations[10]; |
| 00:37.58 | starseeker | <PROTECTED> |
| 00:38.28 | starseeker | When I look in gdb, I have nonsense for positions |
| 00:38.29 | brlcad | ah, I think it's your 0 |
| 00:38.42 | starseeker | checks docs... |
| 00:39.57 | brlcad | regcomp() |
| 00:40.11 | starseeker | It's just cflags |
| 00:40.46 | brlcad | try REG_EXTENDED | REG_ICASE |
| 00:42.14 | brlcad | REG_EXTENDED is what you want regardless as those are POSIX expressions |
| 00:42.19 | starseeker | OK, that runs at least... |
| 00:43.00 | starseeker | Ah, cool |
| 00:43.10 | starseeker | brlcad: thanks |
| 00:43.56 | brlcad | icase is case-insensitive, if it wasn't obvious |
| 00:44.10 | starseeker | :-) |
| 00:46.00 | brlcad | not to imply that you need or want it, maybe - maybe not |
| 00:47.54 | starseeker | hard to tell, just yet |
| 00:48.18 | starseeker | I don't see a way to tell how many substrings were actually matched, short of checking the array |
| 01:14.04 | yukonbob | hello, cadheads |
| 01:17.23 | pacman87 | hi yukonbob |
| 01:36.11 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 02:10.01 | CIA-22 | BRL-CAD: 03starseeker * r31940 10/brlcad/trunk/src/librt/namegen.c: Preliminary test work to use regex matching for breaking up names. Two patterns defined which break up two test names successfully - much more work and testing to do but the essentials are here. |
| 03:43.34 | CIA-22 | BRL-CAD: 03poolio * r31941 10/brlcad/trunk/src/librt/primitives/ell/ell_brep.cpp: Working ellipsoid to brep conversion. |
| 03:45.21 | CIA-22 | BRL-CAD: 03poolio * r31942 10/brlcad/trunk/include/brep.h: redefine X,Y,Z,W,H after including the opennurbs headers. removed author |
| 04:38.55 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 04:42.21 | brlcad | starseeker: "note fix to tire tool in NEWS file." .. not very informative :) |
| 04:43.23 | brlcad | should say what fix to what problem ideally since it's the commit message that is useful down the road |
| 04:43.39 | brlcad | to the news file is a given.. :) |
| 04:47.55 | brlcad | poolio: woo hoo! |
| 04:48.02 | brlcad | just read the diff |
| 04:52.17 | CIA-22 | BRL-CAD: 03brlcad * r31943 10/brlcad/trunk/src/librt/namegen.c: strcat has less overhead than printf if you're not actually going to use a print specifier |
| 04:57.21 | CIA-22 | BRL-CAD: 03brlcad * r31944 10/brlcad/trunk/src/librt/namegen.c: ws, add missing footer, M-q paragraphs, and don't put semicolons after functions (only after structs/classes). |
| 06:31.28 | *** join/#brlcad clock_ (n=clock@77-56-95-247.dclient.hispeed.ch) | |
| 07:15.44 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) | |
| 09:06.22 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 09:12.15 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 09:13.04 | mafm | ho ho ho |
| 09:25.11 | *** join/#brlcad Elperion (n=Bary@p5B14F9FE.dip.t-dialin.net) | |
| 09:37.35 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) | |
| 10:04.19 | *** join/#brlcad testtt (n=53ba486e@bz.bzflag.bz) | |
| 10:07.54 | brlcad | green giant |
| 10:09.30 | mafm | green giant? |
| 10:38.07 | brlcad | ho ho ho |
| 10:38.21 | brlcad | old 80's commercial, never mind :) |
| 10:39.50 | mafm | I was pretending to be Santa |
| 10:39.58 | mafm | it's raining in Lisbon |
| 10:42.30 | mafm | I think that St. James (Galiza's patron, my home) is blinking an eye to me |
| 10:44.25 | brlcad | mafm: naturally, that's part of the .. joke :) |
| 10:44.35 | brlcad | http://en.wikipedia.org/wiki/Ho_ho_ho |
| 10:44.57 | brlcad | http://www.youtube.com/watch?v=mxW1AZ_klVQ |
| 10:45.15 | brlcad | ho ho ho, green giant! |
| 10:46.21 | mafm | while the idiots managing the network at the lab continue to disconnect me every few minutes :P |
| 10:46.30 | mafm | oh, the giant of the vegetables |
| 10:46.36 | brlcad | hehe |
| 10:51.43 | mafm | 1 week of migration |
| 10:52.12 | mafm | router, switches, 80 new workner nodes and around 20 storage machines and misc crap |
| 10:52.20 | brlcad | fun |
| 10:52.23 | mafm | and they migrate everything at once without making tests |
| 10:52.50 | mafm | so they discovered bugs on the firmware and things like that after the migration |
| 10:53.30 | mafm | and half of the people (many of them are on holidays) have to spend the afternoon walking in the nearby parks |
| 10:53.50 | mafm | for a whole week (and maybe the next one too, who knows) |
| 10:54.13 | mafm | the thing of the parks is not bad, except when you have deadlines to meet :P |
| 10:58.53 | mafm | brlcad: so about the evaluations, anything new? |
| 11:47.00 | starseeker_ | brlcad: Oops, sorry |
| 11:47.09 | starseeker_ | brlcad: any way to fix it? |
| 11:47.39 | starseeker_ | should have committed the NEWS file fix at the same time, but didn't think about it being (potentially) user visible until too late |
| 12:02.09 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) | |
| 12:02.24 | *** join/#brlcad thing0 (n=ric@124-169-165-41.dyn.iinet.net.au) | |
| 12:29.40 | starseeker_ | makes note to self: set up cindent properly |
| 12:39.37 | poolio | pokes CIA-22 |
| 12:50.46 | andrecastelo | brlcad: can i use the phong model implementation to get a new vector direction ? |
| 12:57.19 | poolio | I think CIA-22 is dead. |
| 12:59.09 | clock_ | CAPTCHA 22 |
| 13:00.19 | poolio | Heh, one of my professors last semester invented CAPTCHAs :) |
| 13:01.57 | mafm | for the tests? |
| 13:18.13 | poolio | mafm: No, he's the guy who came up with the idea of CAPTCHAs |
| 13:18.46 | mafm | kidding ;) |
| 13:19.17 | mafm | where are you studying at? |
| 13:21.31 | *** join/#brlcad thing0 (n=ric@124-169-165-41.dyn.iinet.net.au) | |
| 13:40.02 | poolio | mafm: CMU |
| 13:40.06 | poolio | in pittsburgh, PA, USA |
| 13:40.29 | mafm | heh, nice :D |
| 13:42.05 | poolio | mafm: thanks I guess :P Where are you studying? |
| 13:46.08 | mafm | some random spanish univ |
| 13:46.44 | mafm | one of my teachers and formers boss was making the doctorate at CMU |
| 13:51.08 | mafm | did you also have classes with Randy Pausch (sp?) ? |
| 13:54.39 | poolio | Nope, I did see "The Last Lecture" though. |
| 13:56.58 | mafm | :D |
| 13:57.19 | PrezKennedy | the next step for captchas should be identifying the object in the picture |
| 13:57.35 | mafm | very emotive video, yep |
| 13:57.53 | poolio | PrezKennedy: I really like what he's doing with reCAPTCHA...putting all those human hours to good use |
| 13:58.29 | poolio | mafm: heh yeah. in person it was really crazy. Everyone in the audience was almost in tears by the end |
| 13:58.51 | mafm | it's the same of recaptcha? very good, yep |
| 13:59.06 | mafm | although I read some criticism to the idea |
| 14:00.17 | poolio | Well, computer vision has gotten much better, so it's being broken all the time. But you can always make it a little bit harder, etc... recaptcha is basically working to digitize an immense number of books |
| 14:00.18 | louipc | I'm not a fan of captchas really |
| 14:00.44 | louipc | at least the type where they take some random string and distort it so it's hard to read |
| 14:01.47 | poolio | In the case of recaptcha it's a random word, and that word is from a book they're trying to digitize where OCR has failed. |
| 14:04.22 | louipc | heh I can't even read it 60% of the time http://louipc.yi.org/images/image.jpeg |
| 14:05.24 | louipc | maybe they should put some context and underline the words they want, and not distort them at all |
| 14:05.26 | homovulgaris | same with me.. most times images are pretty tough to be "even" human-readable |
| 14:06.09 | poolio | louipc: true true. they're working on it :) |
| 14:06.22 | homovulgaris | but i have to agree recaptcha is kind of cool human computing idea |
| 14:06.56 | clock_ | at Loton |
| 14:07.44 | poolio | mafm: Holy cow. I just got an e-mail from the CMU President. Randy Pausch died today :( |
| 14:08.16 | homovulgaris | hmm.. well he had a blast at least. |
| 14:09.43 | clock_ | louipc: http://louipc.yi.org/images/venice_beach-small.jpg |
| 14:09.48 | clock_ | louipc: have you been to Venice Beach? |
| 14:09.52 | louipc | yea |
| 14:10.10 | clock_ | louipc: you live close? |
| 14:10.28 | clock_ | Venice, that's Dogtown and Z-Boys! |
| 14:10.48 | poolio | clock_: That's 'small' heh |
| 14:11.00 | clock_ | poolio: :) |
| 14:11.05 | louipc | santa monica/venice yea |
| 14:11.13 | clock_ | louipc: you live there? |
| 14:11.20 | louipc | no |
| 14:11.50 | louipc | I spent a week in Los Angeles area |
| 14:11.58 | clock_ | oh |
| 14:12.12 | clock_ | louipc: is there a lot of skaters? |
| 14:12.25 | louipc | not that I saw |
| 14:20.31 | mafm | oh, died today? I thought that it might be already dead... his illness is quick and I saw the video about 6 months ago |
| 14:23.33 | clock_ | what does it mean to have a blast? |
| 14:25.23 | louipc | It's like having a banging good time :D |
| 14:27.25 | mafm | huh, does anybody here models with MGED actually? |
| 14:27.40 | clock_ | oh randy pausch has an extensive article on wikipedia |
| 14:27.44 | clock_ | mafm: me |
| 14:27.52 | clock_ | mafm: http://ronja.twibright.com/3d/ |
| 14:28.27 | mafm | do you use shift-grips mode? |
| 14:28.39 | clock_ | no |
| 14:28.44 | mafm | trackball? |
| 14:29.20 | clock_ | shift-mouse |
| 14:29.23 | clock_ | is that shift-grip? |
| 14:29.31 | mafm | yes |
| 14:29.41 | clock_ | oh that i use it and dont know it |
| 14:29.50 | louipc | shift/ctrl/etc |
| 14:30.03 | mafm | is the current way to perform rotation important, or it can as well be random rotation? |
| 14:31.37 | louipc | well it's better than random :P |
| 14:32.00 | mafm | sorry, I meant free rotation, similar to blender |
| 14:32.25 | louipc | blender is probably better |
| 14:32.34 | louipc | I remember I could use the keypad too :D |
| 14:33.05 | mafm | I'm creating two camera modes: blender and shift-grips |
| 14:33.17 | mafm | I think that the blender one is superior, and much simpler anyway |
| 14:33.45 | brlcad | starseeker_: you can run sh/indent.sh and sh/ws.sh to help with style -- the way to 'fix' it is to re-edit the line and commit it again with a new message |
| 14:34.34 | brlcad | andrecastelo: what do you mean about using the phong model -- using what's already implemented, or using that algorithmic technique? |
| 14:35.42 | andrecastelo | brlcad: using what's already implemented, in liboptical, right? |
| 14:56.50 | brlcad | andrecastelo: right |
| 14:57.27 | starseeker | poolio: Jeez, that's sad - of all the guys to get terminal cancer... |
| 14:57.28 | brlcad | you could use it, but the goal isn't to understand/implement phong so much as it is to learn how to shoot your own secondary rays properly (since that's what you need to build up a path) |
| 14:58.08 | brlcad | mafm: familiarity makes one much more superior to the other |
| 14:58.55 | brlcad | for the folks that have been using shift-grips for over a decade, mged's style is far more effective |
| 14:59.33 | mafm | but it doesn't event rotate completely? or I can't seem to get to do it |
| 15:01.50 | brlcad | not sure what you mean? can get any orientation I want with just a few motions |
| 15:02.00 | andrecastelo | i managed to shoot the secondary rays, setting up an application and the ray direction and origin |
| 15:02.11 | brlcad | andrecastelo: i saw the commits |
| 15:02.20 | brlcad | they didn't seem right for the purpose of shadows :) |
| 15:02.27 | brlcad | does it actually work for shadows? :) |
| 15:03.04 | mafm | that with control+mouse drag you can't orbit freely, some angles are missing |
| 15:03.44 | andrecastelo | that's what i thought, perhaps the shadows can be achieved with the secondary callback function? (also, we're talking about some kind of gouraud shading right?) |
| 15:05.02 | andrecastelo | i asked about the phong model because that could be used to determine the direction of the secondary rays, instead of using (0,0,-1) |
| 15:06.52 | brlcad | mafm: I'm not sure what you mean, works for me -- it's basically a free rotation mode |
| 15:07.32 | mafm | dunno, in my case is not complete |
| 15:07.50 | mafm | i.e., if viewing the earth I would be missing zenithal view of poles |
| 15:07.51 | brlcad | you can get angled rotations by going CC or CCW around the center too for alignment |
| 15:08.32 | brlcad | you mean in mged, or the rotation mode you've implemented thusfar for "mged style"? |
| 15:08.43 | mafm | mged |
| 15:09.17 | mafm | but anyway, what I've just implemented is a free rotation |
| 15:09.30 | mafm | my original question is if it has to be exactly the same |
| 15:09.35 | brlcad | sounds like you're doing something wrong |
| 15:10.01 | brlcad | it really should be, but then that depends on what is meant by "exact" too |
| 15:10.32 | brlcad | doesn't have to be numerically identical such that X drag events correspond to exactly Y rotation degrees for example, just the overall behavior should match |
| 15:11.02 | brlcad | andrecastelo: that 0,0,-1 is what was "wrong" |
| 15:11.21 | mafm | yes, I meant more like the second :) |
| 15:11.56 | mafm | shift grips/pans, control rotates freely, ctl+alt+shift scales... |
| 15:12.03 | mafm | are also the constrained modes important? |
| 15:12.13 | brlcad | andrecastelo: the original goal that you're aiming for was implementing secondary rays to render a shadow yes? |
| 15:12.42 | starseeker | prods CIA-22 |
| 15:12.54 | brlcad | yes, the constrained are very important |
| 15:13.15 | brlcad | they've been crying that they're not provided on one of our ported platforms (mac) for quite some time |
| 15:13.36 | brlcad | shift+ctrl freely zooms |
| 15:13.59 | andrecastelo | brlcad: yes, i was thinking something like shading.. |
| 15:14.14 | brlcad | meta/alt translates to fixed point |
| 15:14.17 | andrecastelo | perhaps that can be achieved later, with the path tracing and all? |
| 15:14.28 | brlcad | andrecastelo: shading != shadows |
| 15:14.51 | andrecastelo | brlcad: drop shadows? |
| 15:14.57 | brlcad | you have a simplistic flat shading implemented now |
| 15:15.25 | brlcad | based on surface orientation from the view plane |
| 15:15.56 | brlcad | drop shadows? this aint photoshop :) |
| 15:17.31 | andrecastelo | brlcad: sorry, i was r cast shadows |
| 15:17.38 | andrecastelo | s/r/thinking of |
| 15:17.40 | andrecastelo | :S |
| 15:19.06 | brlcad | yes, things that cast a shadow -- and if you think about what it means to have a shadow, it's based on visibility of a given surface point your light source(s) .. think about that for a bit and what you need secondary rays to do should become obvious |
| 15:21.07 | pacman87 | for shadows, shouldn;t the secondary ray point towards the light source? |
| 15:32.03 | brlcad | pacman87: ;) |
| 15:32.17 | brlcad | that would be a far better direction than 0,0,-1 ;) |
| 15:32.36 | pacman87 | that research i did during the application period pays off |
| 15:40.18 | andrecastelo | brlcad: i'm trying the origin point being the first hit point and the new direction being the same direction as the first direction.. and then, on the secondary function, set ap->a_color to a dark value.. in theory it should work.. or not? |
| 15:42.22 | *** join/#brlcad homovulgaris (n=d@117.196.132.132) | |
| 15:43.12 | pacman87 | andrecastelo: i'd think that'd be more for semitransparent shapes |
| 15:43.53 | pacman87 | once you have the hitpoint from the primary ray, you shoot a secondary ray from that point to your light source |
| 15:44.23 | pacman87 | if the secondary ray doesn't intersect anything else before it gets to the source, you dont have a shadow |
| 15:44.35 | pacman87 | if the secondary ray does hit something, you have a shadow |
| 15:47.05 | andrecastelo | hmm, it would need a third ray then, to generate the shadows |
| 15:47.19 | pacman87 | what's your first secondary ray doing? |
| 15:47.59 | andrecastelo | i think i'll set up the secondary ray as you said |
| 15:48.48 | andrecastelo | currently it is shot from the first hit point, in the same direction, and when it intersects, it paints it black |
| 15:49.37 | pacman87 | your primary ray is from your eye to the environment, right? |
| 15:49.58 | pacman87 | once that ray hits something, why do you care what's behind it? |
| 15:52.00 | andrecastelo | good point, let me try something |
| 15:56.39 | mafm | heh, my panning for shift-grips is most funny |
| 15:57.08 | mafm | starseeker: homovulgaris: did you test the camera modes lately? |
| 15:58.24 | pacman87 | to my understanding, there's three main classes of secondary rays: shadow (directed toward light sources); reflections (reflect primary using hitpoint normal); and transmitted (passing through the object, used for transparency). |
| 16:00.34 | pacman87 | reflected rays would be somewhat offset depending on the surface characteristics |
| 16:00.56 | pacman87 | as would transmitted rays depending on the material characteristics |
| 16:01.21 | pacman87 | and offset using snell's law for differing indices of refraction |
| 16:15.35 | mafm | brlcad: the one of "constrained scale" that you mentioned before was only an example but all of them are important, or is it only important for scaling? |
| 16:17.35 | homovulgaris | mafm: Link error :( Undefined reference to CameraModeMGED::CameraModeMGED() .. do i need to copy stuff to /usr/lib ? |
| 16:19.32 | andrecastelo | what i tried didn't work.. |
| 16:19.35 | andrecastelo | brb, lunch |
| 16:19.52 | homovulgaris | ok .. works now .. my bad i think :P |
| 16:19.58 | mafm | homovulgaris: maybe you should do a clean rebuild or something? |
| 16:20.00 | mafm | ah ok |
| 16:20.57 | homovulgaris | oh it is more like mged now .. i liked the way it was earlier :) |
| 16:21.34 | homovulgaris | cameramode: blender is freer :) |
| 16:21.44 | mafm | homovulgaris: click on the top button about camera... |
| 16:21.51 | homovulgaris | there should be a word free-er :P |
| 16:22.18 | mafm | (and can issue the command "p<tab> w" for prettier view) |
| 16:22.48 | homovulgaris | is there a no hidden-lines command ? |
| 16:23.41 | mafm | no hidden lines? which lines? |
| 16:23.59 | homovulgaris | mafm: g3d working smooth on my end working smooth |
| 16:24.05 | CIA-22 | BRL-CAD: 03poolio * r31945 10/brlcad/trunk/src/librt/primitives/tor/tor_brep.cpp: working torus to brep conversion. needs more error checking, but should work for valid tori. |
| 16:24.10 | homovulgaris | i mean for example wireframe view |
| 16:24.59 | mafm | that's what "polygonmode w" should do |
| 16:25.17 | mafm | can type "help" in the console, w is short for "wireframe" |
| 16:25.29 | mafm | and it works on my end, what it doesn't seem to work is "point" |
| 16:28.31 | mafm | homovulgaris: so can you view in wireframe or not? |
| 16:29.15 | CIA-22 | BRL-CAD: 03mafm * r31947 10/rt^3/trunk/src/g3d/ (4 files): More work (in progress) in panning and rotation for MGED shift-grips mode -- rotation works pretty well but panning does funny things |
| 16:31.04 | brlcad | almost any new user is guaranteed to probably prefer and expect 'blender-style" since that's what a lot of 3D apps do now |
| 16:31.33 | brlcad | shift-grips really is primarily to support our existing users that have their fingers and mice hard-wired to shift grips |
| 16:32.01 | brlcad | kinda like trying to make a vi user suddenly start using emacs |
| 16:32.19 | brlcad | doesn't matter how much better it is, it's painful to unlearn and relearn ;) |
| 16:33.34 | homovulgaris | brlcad: true :) |
| 16:33.54 | homovulgaris | mafm: in polygon mode the lines are hidden by faces if they are behind them right |
| 16:34.17 | mafm | yes |
| 16:34.26 | homovulgaris | i meant is there a mode which shows only the edges .. :) this polygonmode is neat too :) |
| 16:35.46 | homovulgaris | mafm: so we can support as many cameramodes as we want ? i mean later if some rhino ppl ask for their mode ;) |
| 16:36.56 | homovulgaris | brlcad: i am also sure lots of ppl will continue using mged.. :) i like vim more than gvim ;) |
| 16:37.38 | brlcad | didn't recall mentioning "constrained scale", no entiendo |
| 16:39.11 | brlcad | homovulgaris: yeah, there are still mged users that prefer 'ged' .. our old classic mode that doesn't have the tcl/tk gui |
| 16:40.36 | brlcad | when I first learned mged, I preferred classic mode -- some things are just more efficient than via the new interface, there's just a lot more functionality in the new interface overall that you end up wanting to convert |
| 16:40.48 | brlcad | then just turning on the faceplate gui so you get the best of both worlds |
| 16:43.28 | mafm | homovulgaris: many camera modes yes, in fact there are already 3 |
| 16:44.12 | mafm | homovulgaris: the polygon modes are direct translations of opengl inner workings, I just used those at the moment |
| 16:46.14 | mafm | <brlcad> they've been crying that they're not provided on one of our ported platforms (mac) for quite some time | shift+ctrl freely zooms | meta/alt translates to fixed point |
| 16:46.44 | mafm | I already implemented that for scale, and I see no point in non-constrained scaling -- it's hellish to control with a mouse :D |
| 16:47.48 | louipc | why not make the controls fully configurable and shift-grips, etc could be handy presets? |
| 16:47.53 | mafm | but I mea if it's also important for translation/panning (I think so) and rotation (I don't find it very useful here, specially after you're not in the initial position, because you don't know where are you rotating from :D) |
| 16:47.57 | brlcad | what do you mean by non-constrained scaling? |
| 16:48.18 | mafm | non-constrained to three-axes together |
| 16:48.22 | brlcad | to me that sounds like scaling the view in the horizontal or something (affecting perspective) .. which I don't see a need for |
| 16:48.57 | brlcad | view scaling == zooming in/out |
| 16:49.01 | mafm | I understood that in mac, shift+control scales freely, so in any direction independently (not fixing) |
| 16:49.15 | brlcad | oh, no |
| 16:49.24 | brlcad | those were three separate statements :) |
| 16:50.03 | brlcad | if you mean edit deformations, that's a different story |
| 16:50.53 | mafm | at the moment with shift-grips, I have scaling, freely rotating (not constraining to axes, i.e. meta/alt doesn't act) |
| 16:51.03 | mafm | and funny panning with shift |
| 16:51.07 | brlcad | what I meant with the mac is that there's a couple bindings missing (due to the keyboard differences) that let you constrain to just one axis while translating (or while scaling when editing) |
| 16:51.08 | mafm | (rotating is control) |
| 16:52.10 | brlcad | funny panning? |
| 16:53.04 | brlcad | it's pretty standard/simple panning |
| 16:53.13 | mafm | yes, it rotates at the same time :D |
| 16:53.19 | brlcad | it shouldn't |
| 16:53.28 | mafm | I know |
| 16:53.54 | brlcad | i.e. it doesn't (in mged) :) |
| 16:55.11 | brlcad | mafm: oh, another thing that might help you -> when comparing to mged, turn on Misc->Faceplate .. that will show you the view values as they change |
| 16:56.57 | mafm | btw, for voyeurs :P -- http://brlcad.org/~mafm/g3d-screenshots/brlcad_rbgui_20080725-1.png |
| 16:57.42 | andrecastelo | mafm: looking good! |
| 16:57.52 | CIA-22 | BRL-CAD: 03starseeker * r31946 10/brlcad/trunk/NEWS: Fix problem in tire with nicks being removed from tread due to the trimming method used for the inside cut of the tread shape. |
| 16:58.13 | brlcad | since some behaviors might not do what you think they do (e.g. you can implement zooming as changing the view size (i.e. moving the eye point) or by changing perspective (yuck)) |
| 16:58.19 | brlcad | ~starseeker++ |
| 16:58.54 | brlcad | woo hoo, that's looking much better :) |
| 16:58.56 | brlcad | ~mafm++ |
| 16:59.07 | mafm | much better than what? |
| 16:59.28 | mafm | it's similar to the last ones |
| 17:00.08 | brlcad | similar but not the same |
| 17:00.20 | brlcad | the first screenshot that shows it's actually a 3d context ;) |
| 17:01.12 | mafm | oh |
| 17:01.23 | mafm | that's because I think that I haven't made since I started with camera controls |
| 17:04.13 | mafm | btw I think that copied pretty well Blender mode |
| 17:04.46 | mafm | hopefully it won't need many changes to be production re |
| 17:04.48 | mafm | ready |
| 17:05.16 | mafm | (only one rotation glitch, and maybe missing keys that are for advanced users) |
| 17:05.57 | brlcad | sounds good |
| 17:08.14 | mafm | and my Orbital mode, of course, but maybe we should remove it because it's doesn't give you much more than Blender's... |
| 17:36.57 | louipc | is there a more generic term than 'blender' hehe |
| 17:44.18 | brlcad | 'kitchen appliance'? :) |
| 17:44.37 | homovulgaris | yikes :P |
| 17:44.45 | brlcad | "liquidizer mode" |
| 17:44.50 | louipc | HA HA |
| 17:47.17 | louipc | http://louipc.yi.org/images/haha.jpeg |
| 17:47.21 | mafm | well, it's blender because it tries to mimic blender |
| 17:47.33 | mafm | rotations with keyboard step in 15 degrees, etc |
| 17:47.51 | mafm | every program implementing similar ones would have different details |
| 17:49.36 | mafm | if you find a good name, I don't mind to use it :) |
| 18:02.25 | andrecastelo | hey ``Erik, how do I find the light source point? I've tried a few suggestions made by brlcad and pacman87, regarding shooting 2ndary rays from the hit points to the light source, but I think I made a few wrong assumptions about rt |
| 18:02.30 | andrecastelo | also I think I'm doing something wrong - the secondary rays are shot from the first hit point and if I set ap->a_color based on whether these rays hit or not, it doesn't show any difference |
| 18:05.15 | pacman87 | andrecastelo: i think the light source is a user-defined point |
| 18:06.39 | andrecastelo | pacman87: what about when you run rt (or rtmlt, i think they are similar in this point) with just the database file and the objects as arguments, what is assumed to be the light source? |
| 18:07.23 | brlcad | rt makes specific default lights for you if none are specified |
| 18:07.55 | mafm | I hate panning, let's ban this from the program |
| 18:08.04 | mafm | panning is for pussies! :P |
| 18:08.07 | brlcad | heh |
| 18:09.27 | pacman87 | for your color setting, are you doing grayscale, or black/white, or full color? |
| 18:09.42 | mafm | theres a slight rotation in any step, and I don't know why -- maybe it's natural when changing the perspective? |
| 18:10.07 | *** join/#brlcad geocalc (n=geocalc@91-171-203-118.rev.libertysurf.net) | |
| 18:12.09 | mafm | say, if you're looking a cube directly ahead you don't see the sides, but if you pan 5m and look in straight ahead, you should now see one side, right? |
| 18:12.23 | mafm | I think that MGED doesn't work like that |
| 18:14.37 | andrecastelo | pacman87: currently just grayscale |
| 18:21.13 | mafm | so I go home |
| 18:21.17 | mafm | see you guys |
| 18:21.52 | homovulgaris | ciao mafm |
| 18:22.05 | mafm | (and girls? :PPPPP) |
| 18:22.10 | mafm | bye :) |
| 18:24.03 | pacman87 | if ( !shadow ) brightness = (light source direction) DOT ( reflected primary ray direction from surface normal) |
| 18:24.21 | pacman87 | andrecastelo: somethign like that ^^ |
| 18:24.24 | pacman87 | ? |
| 18:25.50 | brlcad | eh, no you shouldn't be able to see one side .. yeesh |
| 18:26.01 | brlcad | at least not with an orthogonal view, that's probably what's screwing him up |
| 18:26.57 | andrecastelo | pacman87: hm, i see what you mean, something like 'only shade if not in the shadow' ? |
| 18:28.31 | pacman87 | strictly speaking, if there's only one light source, then you wouldnt be able to see the shadow side |
| 18:28.49 | pacman87 | like you cant' see the dark side of a cresent moon |
| 18:31.15 | pacman87 | i don't know the specifics of mlt or how it differs from standard raytracing |
| 18:32.05 | pacman87 | you might add a dim light at the eye source by default, so you can see the whole shape |
| 18:32.41 | andrecastelo | pacman87: i'd be happy if half the truck were in the shadow, :D |
| 18:32.56 | andrecastelo | and currently it's basically a raytracer |
| 18:37.47 | andrecastelo | i've added something like what you suggested |
| 18:38.22 | andrecastelo | but i think the problem lies in the secondary ray shooting, it just doesn't intersect anything |
| 18:38.57 | andrecastelo | (the secondary rays direction isn't good) |
| 18:39.24 | pacman87 | you need to specify the light source point |
| 18:39.57 | pacman87 | vector subtraction between hitpoint and light source, and unitize for your new direction |
| 18:40.28 | pacman87 | check if the closest hit on secondary ray is in front or behind the light source |
| 18:55.07 | ``Erik | iirc, there are two ways to specify lights in BRL-CAD; either a point light (like automatically generated by rt of no lights exist), or by applying a light shader (which photon mapping requires) |
| 18:55.25 | ``Erik | the point light is dimensionless, so you'll never intersect it with a shot |
| 18:55.28 | ``Erik | iirc |
| 18:56.11 | pacman87 | ``Erik: right, for the shadow secondary ray, you care about whether the first intersection is closer than the light source |
| 18:56.55 | andrecastelo | so, in view2init, the default lightmaker creates one coming from (1, 0, 1) |
| 18:57.13 | ``Erik | for point lights, pacman, yes |
| 18:58.58 | andrecastelo | when i set the direction of the secondary rays to that direction, everything is shadowed (i set a constant color for the cast shadow) |
| 18:59.17 | ``Erik | you fire a ray from your intersect point towards the light source, then compare the first hit against the distance to the light source? |
| 19:01.58 | andrecastelo | nope. I've tried something simple like what pacman87 suggested |
| 19:02.22 | andrecastelo | if (!shadow) shade; else paint it black |
| 19:02.29 | pacman87 | if your shadow ray is into the shape (shadow ray)DOT(normal) < 0, then it's shadowed |
| 19:02.36 | andrecastelo | hm |
| 19:03.04 | andrecastelo | let me try that |
| 19:03.05 | pacman87 | andrecastelo: so currently, everything is in shadow? |
| 19:03.06 | ``Erik | that's shading, not a cast shadow |
| 19:03.32 | pacman87 | ``Erik: it's in its own shadow |
| 19:03.41 | pacman87 | but yeah, i see your point |
| 19:03.56 | ``Erik | if your initial fire point is ON the surface, it probably won't hit itself trying to go to the light |
| 19:04.02 | ``Erik | or it'll always hit itself |
| 19:04.42 | ``Erik | so usually it's punted by shading on the surface and firing shadow rays to see if something else is casting a shadow on it |
| 19:05.27 | pacman87 | makes sense |
| 19:05.51 | andrecastelo | but when i shoot it, from the surface, to other directions, it doesn't intersect |
| 19:07.59 | pacman87 | have you tried simple tests |
| 19:08.28 | pacman87 | ie, two different sized spheres, with the light source on the line connecting the centers |
| 19:08.30 | pacman87 | ? |
| 19:09.18 | ``Erik | or an arb8 with a cylinder sticking out of it and a light source off to one side? |
| 19:09.22 | ``Erik | (post in the earth style?) |
| 19:10.54 | andrecastelo | no, haven't tried those.. I pretty much got some .g files and test on them :S |
| 19:20.13 | andrecastelo | i told it to output the distance from the second ray starting point and the first intersection, and it flooded me with the same number :S |
| 19:20.44 | pacman87 | should that be zero? |
| 19:21.01 | pacman87 | er, first intersection of secondary ray. right. |
| 19:21.07 | pacman87 | ignore me |
| 19:21.58 | andrecastelo | got something around 1954 o.O |
| 19:22.17 | pacman87 | you built a time machine? |
| 19:22.54 | *** join/#brlcad elmom (n=elmom@hoasnet-ff04dd00-187.dhcp.inet.fi) | |
| 19:23.33 | *** part/#brlcad prasad1 (n=psilva@h-72-245-122-226.mclnva23.covad.net) | |
| 19:30.17 | andrecastelo | heheh |
| 19:43.57 | *** join/#brlcad CIA-23 (n=CIA@208.69.182.149.simpli.biz) | |
| 19:51.04 | *** join/#brlcad saltan (n=lievensa@d51530284.access.telenet.be) | |
| 19:53.52 | CIA-23 | BRL-CAD: 03starseeker * r31952 10/brlcad/trunk/src/librt/namegen.c: |
| 19:53.52 | CIA-23 | BRL-CAD: test more names, add regex logic for build_region style endings. need to think |
| 19:53.52 | CIA-23 | BRL-CAD: abou thow to handle potential incrementors - apparently regex can't tell me how |
| 19:53.52 | CIA-23 | BRL-CAD: many numbers are tucked in the string. I can check and generate a regex string |
| 19:53.52 | CIA-23 | BRL-CAD: based on that, always use the first number before a period as the iterator |
| 19:53.55 | CIA-23 | BRL-CAD: (probably a bad idea), or...? |
| 20:14.44 | CIA-23 | BRL-CAD: 03starseeker * r31953 10/brlcad/trunk/src/librt/namegen.c: |
| 20:14.44 | CIA-23 | BRL-CAD: check components that aren't numbers to see if they contain numbers - if they |
| 20:14.44 | CIA-23 | BRL-CAD: do, flag them in the array. Will need to create a secondary regex substring |
| 20:14.44 | CIA-23 | BRL-CAD: routine to handle up to some large number of numbers in such a string, and then |
| 20:14.44 | CIA-23 | BRL-CAD: when identifying which number to use for an iterator branch out to subarrays if |
| 20:14.47 | CIA-23 | BRL-CAD: a value of 2 is found. |
| 20:26.08 | *** join/#brlcad elmom (n=elmom@hoasnet-ff04dd00-187.dhcp.inet.fi) | |
| 20:42.11 | *** join/#brlcad andrecastelo (n=chatzill@189.71.21.218) | |
| 21:39.53 | *** join/#brlcad jonored (n=jonored@pool-71-184-19-43.bstnma.east.verizon.net) | |
| 23:13.25 | brlcad | ~seen ralith |
| 23:13.28 | ibot | ralith <n=ralith@216.162.199.202> was last seen on IRC in channel #brlcad, 1d 18h 22m 55s ago, saying: 'I have a full on citizen militia'. |
