| 00:37.19 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2999 10/wiki/Density_functions: initial page on material (density) objects |
| 00:37.29 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3000 10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas: link to all of the new articles |
| 00:41.24 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) |
| 00:46.03 | *** join/#brlcad bhinesley (~bhinesley@99.125.86.110) |
| 00:55.46 | *** join/#brlcad ibot (~ibot@rikers.org) |
| 00:55.46 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 being tagged today (20110701) || BRL-CAD has applied to participate in the ESA Summer of Code in Space! |
| 02:09.13 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3001 10/wiki/Community_Publication_Portal: initial stub of 7.20.2 release announcement |
| 02:46.34 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3002 10/wiki/Community_Publication_Portal: /* Release 7.20.2 */ restructure |
| 03:47.28 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3003 10/wiki/Community_Publication_Portal: /* Release 7.20.2 */ expand writeup, consolidate contributors |
| 03:52.36 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3004 10/wiki/Community_Publication_Portal: /* Release 7.20.2 */ |
| 03:57.38 | CIA-62 | BRL-CAD: 03brlcad * r45418 10/brlcad/trunk/NEWS: reword the writeup for brevity/clarity |
| 04:15.18 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3005 10/wiki/Community_Publication_Portal: /* Final Editorial Review */ release 7.20.2 posted |
| 04:42.53 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 06:50.32 | *** join/#brlcad merzo (~merzo@193.254.217.44) |
| 08:05.10 | CIA-62 | BRL-CAD: 03d_rossberg * r45419 10/brlcad/trunk/CMakeLists.txt: corrected comment on brlcad.dll flag |
| 08:18.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 09:32.40 | *** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ) |
| 09:47.43 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 09:50.30 | *** join/#brlcad mafm (~mafm@12.Red-193-153-199.dynamicIP.rima-tde.net) |
| 10:01.09 | *** join/#brlcad piksi_ (piksi@pi-xi.net) |
| 11:31.48 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) |
| 12:46.26 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 13:57.35 | CIA-62 | BRL-CAD: 03brlcad * r45420 10/brlcad/trunk/src/liboptical/material.c: two found: labels in the same file, bad ju ju |
| 14:20.50 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) |
| 14:27.34 | d_rossberg | kunigami: could you solve the refraction issue? |
| 14:29.39 | kunigami | d_rossberg: nope. I think I'll redo the tests and attach the images in the email. Maybe they give a better idea on what's going on |
| 14:32.13 | d_rossberg | do you know now whats the difference between pt_inhit and pt_outhit? |
| 14:32.23 | CIA-62 | BRL-CAD: 03erikgreenwald * r45421 10/brlcad/trunk/src/libgcv/bottess.c: add precomputed face add to avoid fp fuzz on the plane equation |
| 14:45.10 | *** join/#brlcad silvap (~silvap@static-96-255-52-7.washdc.fios.verizon.net) |
| 14:53.39 | kunigami | I'm not sure if I understand them correctly. As far as I understand, the outhit is the intersection of the ray as if I were refracted |
| 15:14.36 | d_rossberg | the ray-trace gives you a series of hits with solids (regions or primitives) |
| 15:15.36 | d_rossberg | a hit with a solid is the part of the ray which lies inside the solid |
| 15:16.25 | d_rossberg | and it is determi |
| 15:16.55 | d_rossberg | ... sorry, defined by the entry and exit point |
| 15:18.40 | d_rossberg | i.e. pt_inhit descibes the point where your ray enters a solid (point, distance from the rays origin normal of the solin in this point, ...) |
| 15:19.23 | d_rossberg | and pt_outhit does the same for the point where the ray leaves the solid |
| 15:20.38 | d_rossberg | normaly the light goes outside the solids, but in case of refraction you are interested in the lights way inside a solid |
| 16:34.09 | brlcad | kunigami: make sense? |
| 16:36.02 | brlcad | if you shot a ray towards a sphere, you'll get an inhit at the point where it hits, then an outhit on the other side of the sphere where it would exit |
| 16:36.34 | brlcad | remember you're dealing with solid geometry, not just surfaces, so a sphere isn't just the outer surface -- it's solid all the way through |
| 16:42.34 | brlcad | so the ray tracer gives you sets of inhit/outhit (i.e., partitions) |
| 16:43.34 | brlcad | you might want to see how our existing phong shader -- src/liboptical/sh_plastic.c -- deals with refraction and transmission, calls rr_render() from refract.c |
| 16:56.37 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 17:02.16 | kunigami | brlcad: but this outhit takes into account the index of refraction, right? |
| 17:02.50 | kunigami | I read the code in refract.c. I borrowed part of that code to implement the refraction callback of sh_osl |
| 17:04.14 | brlcad | it depends what you mean by taking it into account |
| 17:05.04 | brlcad | if you rt_shootray an application struct with index of refraction set, then NO .. it won't take it into account for *that* ray being fired |
| 17:05.31 | brlcad | inhit/outhit will always be along the ray pnt->dir being fired |
| 17:05.46 | brlcad | the index of refraction controls the next ray being fired |
| 17:10.22 | kunigami | hmm, interesting. I had the impression that changing the index of refraction did changed the way the glass looked. maybe I had changed something else |
| 17:10.28 | kunigami | I'll check again |
| 19:29.54 | *** join/#brlcad mafm_ (~mafm@12.Red-193-153-199.dynamicIP.rima-tde.net) |
| 19:45.21 | CIA-62 | BRL-CAD: 03bhinesley * r45422 10/brlcad/trunk/src/libged/alter.c: Added a few examples to the scale manual to help work out issues. It is straightforward compared to the rotate command. These examples are probably sufficient. |
| 19:56.48 | bhinesley | brlcad: I'm starting to work on the argument handler (alter) for translate/rotate/scale. |
| 19:56.48 | bhinesley | While all 3 commands accept different arguments, the methods of grouping them are all based on the same concepts. I'm building a sort of argument handling system for alter, so that adding another command, or altering an existing one will be easy enough. What I'm implying is that you can check out the mock manuals at your leisure, and just let me know what changes you'd like. |
| 20:32.29 | *** part/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) |
| 21:49.33 | brlcad | bhinesley: okay |
| 21:49.50 | brlcad | haven't had a chance to read up in detail since you started on rotate, but will this week |
| 21:50.33 | brlcad | at a glance, would really like scale to accept simple uniform scaling via single arg |
| 21:50.39 | brlcad | like scale 2.0 foo |
| 21:51.08 | brlcad | since that's the most common use case, it should be the most brief |
| 21:51.15 | bhinesley | nods |
| 21:53.58 | bhinesley | I could make 'scale 2.0' == 'scale 2.0 2.0 2.0' while 'scale -x 2.0' performs a stretch |
| 21:56.28 | bhinesley | but then, should 'scale 2.0 3.0' == 'scale -x 2.0 -y 3.0'? This would seem weird: 'scale 2.0 3.0' == 'scale 2.0 3.0 3.0' |
| 21:58.11 | bhinesley | looks like 'sca' would do the prior |
| 22:06.45 | CIA-62 | BRL-CAD: 03bhinesley * r45423 10/brlcad/trunk/src/libged/alter.c: All 3 FACTOR_TO_POS arguments areset to its first argument, if it is the only one given. |
| 22:07.55 | CIA-62 | BRL-CAD: 03bhinesley * r45424 10/brlcad/trunk/src/libged/alter.c: accidentally removed a brace in the last commit |
| 23:31.03 | ``Erik | mebbe scale 2/2/2 ? so'z you can do 2// or whatever? |
| 23:35.56 | ``Erik | (defmethod scale-x (obj val) (* (x-of obj) val)) (defmethod scale (obj val) (scale-x obj val) (scale-y obj val) (scale-z obj val)) ... :D |
| 23:41.59 | bhinesley | ``Erik see libged/alter.c for the manuals I've cooked up so far |
| 23:43.12 | bhinesley | notably: {xyz_factor | {x y [z]}} | {[-x {x | X_OBJ}] [-y {y | Y_OBJ}] [-z {z | Z_OBJ}]} |
| 23:45.18 | bhinesley | 2// would be a stretch in the x-axis |
| 23:45.29 | bhinesley | while 2/2/2 would be a uniform scale |
| 23:47.06 | bhinesley | the slashes would actually work pretty well though, as far as trimming the size of the commands |
| 23:50.37 | bhinesley | it means we could do things like './sphere.s 1 4 5/7' rather than '-x . -y sphere.s 1 4 5 -z 7' |
| 23:51.48 | bhinesley | (which means: use the x-coordinate of each argument we're scaling, the y-coordinate of the center of sphere.s offset (1,4,5), and the z-coordinate of 7) |
| 23:53.38 | bhinesley | not that the '.' makes much sense for that particular usage of 'scale', but it is very useful for translate/rotate, which use a similar syntax |
| 23:59.08 | CIA-62 | BRL-CAD: 03bhinesley * r45425 10/brlcad/trunk/src/libged/alter.c: expand upon the definition of OFFSET_DIST, to clarify its dissimilarities from *POS arguments |