| 00:33.25 | *** join/#brlcad guu (guu@myth.gibbscam.com) |
| 01:04.44 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/ (configure.ac db/Makefile.am): add a --enable-models-install option with aliases for conditionally installing the example geometry models. benchmark geometry are still converted/installed as they are required for the installed benchmark tool |
| 01:08.31 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/NEWS: include release note details on the benchmark suite changes/installation as well as the addition of example geometry databases |
| 05:23.08 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/librt/cmd.c: the command string to rt_do_cmd is no longer modified by this routine so that the caller may use static command strings |
| 05:24.44 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/rt/opt.c: add a -W option to all of the raytracers that specifies that a 'non-default' (usually inverted) background color should be used. for rt, this is a white background. |
| 05:26.47 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/rt/ (viewedge.c rtedge.1): the new -W option on rtedge means that the foreground and background colors need to be inverted so that it's black lines on a white background by default. (this implements sf request 1177331) |
| 05:27.35 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/rt/rt.1: document the new -W option stating that it draws a white background for rt |
| 05:31.35 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/NEWS: added -W option to raytracers for white background (implements sf request 1177331) |
| 05:35.28 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/rt/viewedge.c: only swap the colors once otherwise the frame backgrounds will flop back and forth |
| 05:53.29 | *** join/#brlcad PKMOBILE (~Matthew@pcp0011643451pcs.aberdn01.md.comcast.net) |
| 06:01.17 | PKMOBILE | http://www.monstercrawler.com/beta-bin/nph-beta.pl?qry=nutcase+liberal+websites |
| 06:01.40 | PKMOBILE | good to know thats how people find me :-\ |
| 09:56.35 | *** join/#brlcad ping (~ping@ping.phys.ntu.edu.tw) |
| 09:59.27 | ping | hello! |
| 10:01.46 | ping | It is great that result of such a long time project is now free software. I'm in a small telescope design team and I'm thinking whether or not I can use BRL-CAD to simulate the imaging of a set of lenses with known surface (shape, size) and material (index of refraction, reflectivity). |
| 10:02.18 | ping | Any advices are appreciated! |
| 11:44.24 | learner | hello ping |
| 11:45.56 | learner | that sounds like a neat project, similar to one I worked on a few years back |
| 11:47.08 | *** join/#brlcad d_rossberg (~c28bf505@bz.bzflag.bz) |
| 11:47.58 | learner | you can definitely use brl-cad for simulating the lens though the default optics may be tricky to get looking realistic |
| 11:51.01 | learner | gutenmorgen herr d_rossberg |
| 11:51.50 | d_rossberg | good night Mr. learner |
| 11:52.29 | d_rossberg | i think i have found a problem in creating bots in mged |
| 11:52.49 | d_rossberg | the unit taken is always mm |
| 11:53.27 | learner | creating bots how? |
| 11:53.47 | d_rossberg | try "units m; in foo bot ...; l foo" |
| 11:54.04 | learner | ahh |
| 11:54.46 | d_rossberg | version is 7.2.4, if i remember right |
| 11:55.36 | learner | sure enough.. just looked at the code and it's missing the local2base conversion |
| 11:56.43 | d_rossberg | i looked at typein.c, but it look like the conversion is done somewhere else |
| 11:57.43 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/BUGS: typein of a bot is not performing a local2base units conversion |
| 11:57.46 | d_rossberg | OK, i found a call to local2base |
| 11:58.14 | learner | yeah, it's there -- it's just a simple multiply |
| 11:58.20 | learner | on the read |
| 11:58.59 | learner | local2base is already set up with the correct units conversion scaling factor |
| 11:59.12 | d_rossberg | i took arbn_in as a reference, but couldn't find a significant difference in vertex-handling |
| 12:00.18 | learner | shoudl be a matter of multiplying just the atof's by local2base, but I'll have to test it some |
| 12:04.25 | learner | don't forget the thinkness atof if it's a plate |
| 12:04.37 | learner | er, thickness |
| 12:05.35 | learner | yeah, looks like it's just those four |
| 12:05.43 | learner | can you test to make sure that works how you expect? |
| 12:07.21 | d_rossberg | i hope so (i'll try it) |
| 12:08.02 | d_rossberg | looks like arbn_in has a similar problem |
| 12:08.20 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/typein.c: rossberg identifies a bug in bot typein where units conversion was apparently overlooked. |
| 12:08.44 | d_rossberg | it's not important for the normals, but for the distance parameters there, i would say |
| 12:10.12 | learner | hmm |
| 12:12.10 | learner | ahh, yep, sure enough.. |
| 12:12.32 | learner | the rt_arbn_import in librt/g_arbn.c |
| 12:12.39 | learner | <PROTECTED> |
| 12:12.53 | learner | <PROTECTED> |
| 12:13.42 | learner | good catch! |
| 12:15.29 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/typein.c: rossberg finds another units problem in the arbn typein where the distance paramater is not taking units into account. |
| 12:18.30 | d_rossberg | i will now check out the developer sources and build it, this may take a while ... |
| 12:19.08 | d_rossberg | BTW: i can ssh at sourceforge.net :-) |
| 12:19.37 | learner | :) great |
| 12:20.06 | learner | i believe the news file is now going to have to be utf-8 :) |
| 12:25.37 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/NEWS: fixed units bug in mged typein of bot and arbn |
| 12:37.12 | learner | heh, i think CIA-5 choked on some utf chars |
| 12:37.53 | ping | learner: sorry that I left for dinner, and thanks! |
| 12:38.31 | learner | no problem, and now I go shower :) |
| 12:38.36 | ping | learner: any pointers to your project? With your permission I'd like to take a look at the code. |
| 12:42.03 | learner | you don't need my permission, it's openly available |
| 12:42.21 | learner | or rather 'sure!' you have my permission ;) |
| 12:42.58 | learner | ping: you can download it from http://sourceforge.net/projects/brlcad/, I'd suggest getting it from CVS if you're a developer |
| 12:43.38 | learner | and that's a rather interesting choice of irc nicks.. any particular significance? |
| 12:45.27 | ping | well, that's the transliteration of my first name in Chinese... :) |
| 12:45.46 | learner | ahh okay :) |
| 12:46.57 | learner | there's more documentation on the website at http://brlcad.org |
| 12:47.57 | ping | checking out the codes from CVS now... |
| 12:48.48 | ping | while waiting for CVS co to finish, I'd like to ask more questions. :) |
| 12:49.39 | ping | Is there a way to find the size of image on the focal surface for parallel light rays coming from a fixed direction? |
| 12:53.04 | learner | the image size _on_ the focal surface? |
| 12:54.45 | ping | yes. The parallel light rays will be focused by the lens not into a point but an image with finite size. The size is a very important parameter in telescope design. |
| 12:58.11 | learner | there is definitely a means to calculate the size in code since you can traverse the rays and introspect them however you like |
| 12:58.49 | learner | and similarly the rays are parallel coming from a fixed viewpoint/viewsize by default |
| 12:59.06 | ping | okay, great. I'll read the documents and learn how to do that. Is this part in the rt library? |
| 12:59.23 | learner | yes, that would be part of librt |
| 12:59.32 | learner | as well as parts of liboptical |
| 13:00.22 | learner | sounds like you either want some information out of liboptical or perhaps even your own varient of liboptical that has you optics behavior |
| 13:00.35 | learner | perhaps just another shader type |
| 13:02.36 | ping | I didn't see liboptical in the "top level" of documents, any reference? |
| 13:02.46 | learner | you could actually draw the light rays in mged and visualize the rays in 3D to observe how they converge.. that would be neat |
| 13:05.47 | ping | oh, that is cool! I'll try that. |
| 13:06.26 | learner | basically in the modeler, you can issue plotting commands (actual old-school .pl code) |
| 13:06.34 | learner | that will draw lines |
| 13:08.00 | learner | you could run the raytracer in either debug mode, or add some additional printing to give you ray trajectories as they are traversed, and then feed that into something that plots them in mged |
| 13:08.01 | ping | hmm... does that mean I have to learn a scripting language (.pl)? |
| 13:08.21 | learner | no no, pl is a simple plotting instruction |
| 13:08.41 | learner | used on the old plotter devices that used to make schematics |
| 13:10.49 | ping | that sounds somewhat familiar... :) |
| 13:15.04 | learner | it depends a lot on what your ultimate goal is, but is sounds like you want to simulate different lenses and observe how they behave? |
| 13:15.41 | learner | the existing raytrace logic will deal with "pure" lenses as it is |
| 13:16.17 | ping | that's right. I want to determine the configuration of lenses (size, location, radius of curvature, etc) that produces the smallest image size within budget constraint. |
| 13:16.34 | learner | but is not set up for the variety of optics effects you encounter in real lenses like subsurface scattering, microfractures, dust/particulates, etc |
| 13:16.57 | learner | for that you'd have to modify liboptical or write a similar variety that takes those into account |
| 13:18.14 | ping | I think I'm doing an "idealistic" simulation for now so microfractures can be ignored. |
| 13:18.44 | ping | I think one big challenge might be the "Fresnel lens" where the surface of the lens has many "teeth". |
| 13:19.09 | learner | the raytracers (e.g. 'rt') deal with generating the rays, librt takes over and shoots/propagates the rays through a given scene reporting on when/where objects are hit, liboptical takes over when objects are hit telling it how the ray should react (does it scatter, diffuse, reflect back, etc) |
| 13:20.39 | learner | then the results are passed back to the raytracer from librt and liboptical for it to decide what to do with those events/values |
| 13:21.19 | learner | which is usually something like generate a picture (rt), report on some mass/volume (rtweight), draw object outlines (rtedge), etc |
| 13:22.20 | learner | sounds to me like you're sort of wanting a raytracer that generates plot lines which wouldn't be too difficult at all |
| 13:22.33 | learner | in fact there was a debug flag at one point that did that.. hrm |
| 13:23.58 | ping | oh, where is that debug flag? |
| 13:26.37 | learner | i'd have to hunt, but it should be either the -x flag to rt, with flags described in include/raytrace.h |
| 13:27.00 | learner | I'd love to continue this but I unfortunately have a meeting .. i'll be back in a bit |
| 13:27.45 | ping | sure! (am compiling the source code right now) |
| 14:54.12 | CIA-5 | BRL-CAD: 03d_rossberg * 10brlcad/include/raytrace.h: the caller may use static command strings to rt_do_cmd |
| 14:59.34 | ping | the CVS version has a compile error in src/librt/cmd.c:193... need to replace "const char *ilp" by "char *ilp" and "register const ..." by "const ..." to get it compiled. |
| 15:02.19 | d_rossberg | learner: i couldn't build BRL-CAD from CVS because of undefined "yyin" etc. in brlcad/src/tab/scriptsort.o |
| 15:02.46 | d_rossberg | ping: my last commit fixed this problem |
| 15:05.17 | d_rossberg | ping: but because of slow replication it may be better to fix it by hand now: |
| 15:08.01 | d_rossberg | ping: include/raytrace.h line 2701 should be "const char *ilp," |
| 15:22.23 | ping | oh I fixed it by replacing the function argument types in src/librt.cmd.c |
| 17:53.30 | brlcad | yeah, sorry about that -- I forgot to commit a header file last night |
| 20:27.43 | *** join/#brlcad PKMOBILE (~Matthew@pcp0011643451pcs.aberdn01.md.comcast.net) |
| 20:28.13 | PKMOBILE | stop drop and roll... the nutcase liberal with a website is here! |
| 21:16.06 | *** join/#brlcad CIA-5 (~CIA@flapjack.navi.cx) |