| 00:37.16 | brlcad | [A |
| 00:38.08 | brlcad | zero_level: I replies regarding your wiki page, please make sure the patches themselves are clear |
| 00:38.27 | brlcad | ALL of your patches -- if a newer patch replaces an older patch, close the old patch (or leave a comment) |
| 04:02.20 | *** join/#brlcad Samooka (~sam@187.39.188.121) | |
| 04:02.59 | Samooka | hello |
| 04:04.34 | Samooka | I would like to edit a combination using oed, however I am missing something as the rotation is not applied to the combination, but to one of its parts only. Can anyone help me understand this? |
| 04:04.40 | Samooka | this is the tree: |
| 04:05.00 | Samooka | forno.s/ |
| 04:05.02 | Samooka | u domo_aberto.s/ |
| 04:05.02 | Samooka | u casca_domo.s/ |
| 04:05.02 | Samooka | u solido1_domo.s |
| 04:05.02 | Samooka | - vazio2_domo.s |
| 04:05.02 | Samooka | - vazio1_domo.s |
| 04:05.03 | Samooka | - vazio1_tunel.s/ |
| 04:05.05 | Samooka | u solido1_tunel.s |
| 04:05.07 | Samooka | u solido2_tunel.s |
| 04:05.09 | Samooka | u tunel.s/ |
| 04:05.11 | Samooka | u solido3_tunel.s/ |
| 04:05.13 | Samooka | u solido1_tunel.s |
| 04:05.15 | Samooka | u solido2_tunel.s |
| 04:05.17 | Samooka | - vazio2_tunel.s/ |
| 04:05.21 | Samooka | u solido1_tunel.s |
| 04:05.23 | Samooka | u solido2_tunel.s |
| 04:06.06 | brlcad | Samooka: what's our oed command look like? |
| 04:06.12 | Samooka | using "oed forno.s domo_aberto.s/casca_domo.s/solido1_domo.s" will enter edit mode, however tunel.s is ignored: it is not selected and transformations applied to forno.s do not apply to it. |
| 04:06.18 | Samooka | What am I missing? |
| 04:07.09 | brlcad | so that's "oed rightpath leftpath" and it puts the matrix over the leftpath |
| 04:07.19 | brlcad | so if you want the matrix over forno.s, you need it on the left |
| 04:07.34 | brlcad | bah, and I have my right and left REVERSED! |
| 04:07.52 | brlcad | "oed leftpath rightpath" .. puts it over rightpath |
| 04:08.14 | brlcad | so you realize, /this/is/the/full/path |
| 04:08.57 | brlcad | so what you wrote properly formatted would have been "oed /forno.s domo_aberto.s/casca_domo.s/solido1_domo.s" |
| 04:09.01 | Samooka | brlcad, wasn't leftpath supposed to be the path to a primitive? |
| 04:09.15 | brlcad | yes, it's also that |
| 04:09.22 | brlcad | what you probably are wanting is |
| 04:09.39 | brlcad | oed / forno.s/domo_aberto.s/casca_domo.s/solido1_domo.s |
| 04:10.23 | Samooka | brlcad, so this line you just gave me will apply the matrix to forno.s? |
| 04:10.32 | brlcad | last comment, your naming convention there is suboptimal ... the .s suffix implies a primitive shape (like ell or tor) but clearly many of those are not primitives |
| 04:10.45 | brlcad | Samooka: yep |
| 04:10.53 | Samooka | brlcad, right, they are combinations |
| 04:11.09 | brlcad | combs usually have a .c, .r, .g or no suffix |
| 04:11.15 | Samooka | I guess I should do away with the .s's... |
| 04:11.17 | brlcad | .c is most common |
| 04:11.33 | brlcad | below the region level at least, .c is common |
| 04:11.41 | brlcad | then .r for your actual regions |
| 04:11.47 | brlcad | and no suffix above the region level |
| 04:13.18 | Samooka | brlcad, it worked, thanks a lot... let me re-read your posts; why is it that the left path has to be the root (/)? |
| 04:15.31 | Samooka | if I understand correctly, "oed /forno.s domo_aberto.s/casca_domo.s/solido1_domo.s" tells oed that I want to modify domo_aberto.s, and not forno.s? |
| 04:16.17 | brlcad | it says to modify the instance of domo_aberto.s referenced within forno.s |
| 04:16.21 | brlcad | there can be other references |
| 04:16.34 | brlcad | such as domo_aberto.s by itself |
| 04:16.50 | Samooka | got it. |
| 04:16.59 | brlcad | if you wanted to update all referenes to domo_aberto.s, you'd run "oed / domo_aberto.s/...." |
| 04:17.13 | brlcad | think of it as ONE path like a filesystem |
| 04:17.19 | brlcad | /path/to/file |
| 04:17.41 | brlcad | and depending on what you want to manipulate, you insert a space and put oed at the front ;) |
| 04:18.27 | brlcad | we will eventually get rid of the need to specify the left and right hand sides, but that's the current usage for a variety of reasons |
| 04:19.48 | Samooka | so everytime I want to modify a comb or region in the top level, leftpath will be (/); if I have a region composed of several combs and want to modify just one instance, then I will have leftpath point to the region (/top_level_object) |
| 04:20.36 | brlcad | exactamente |
| 04:20.36 | Samooka | I've got to remember that!! |
| 04:20.56 | brlcad | if we can make that any more clear in the documentation or on the wiki, let us know what to say :) |
| 04:24.20 | Samooka | brlcad, I read through "Object editing: the oed command" but did not get this insight. If I can find another way of explaining it, I might submit a proposal... |
| 04:24.30 | brlcad | great |
| 04:24.45 | brlcad | especially considering that's the document specifically written to help explain this :) |
| 04:25.09 | Samooka | for now, thank you so very much for the clarification |
| 04:25.18 | Samooka | :) |
| 04:25.23 | brlcad | any time |
| 05:20.09 | *** join/#brlcad caen23 (~caen23@92.81.178.221) | |
| 06:44.19 | Notify | 03BRL-CAD:phoenixyjll * 55887 brlcad/trunk/src/libbrep/intersect.cpp: According to openNURBS's declaration, for ccx_point events, m_a[0] should be equal to m_a[1] (m_b[0] == m_b[1], m_A[0] == m_A[1], m_B[0] == m_B[1]...). And change the logic so that if it's not an overlap event, two ccx_point events may be generated. |
| 06:48.50 | Notify | 03BRL-CAD:phoenixyjll * 55888 brlcad/trunk/src/libbrep/intersect.cpp: Used a wrong curve in point-curve intersection to test overlap. |
| 07:11.51 | Notify | 03BRL-CAD:phoenixyjll * 55889 brlcad/trunk/src/libbrep/intersect.cpp: More comment to document the intersection approaches, and style conformance. |
| 07:29.26 | Notify | 03BRL-CAD Wiki:Phoenix * 5531 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 2 */ |
| 08:09.57 | *** part/#brlcad Mahi (~Mahi@ec2-54-226-39-211.compute-1.amazonaws.com) | |
| 08:22.58 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) | |
| 08:25.37 | d_rossberg | brlcad: i thought using -fPIC is common sense |
| 08:25.47 | d_rossberg | see e.g. www.akkadia.org/drepper/dsohowto.pdf |
| 08:26.38 | d_rossberg | and that's the error i get w/o -fPIC: /usr/bin/ld: ../../../lib/libbn.a(mat.c.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC |
| 09:03.04 | *** join/#brlcad caen23 (~caen23@92.81.178.221) | |
| 09:15.05 | *** join/#brlcad infobot (~infobot@rikers.org) | |
| 09:15.06 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || GSoC 2013! http://brlcad.org/wiki/Google_Summer_of_Code | |
| 10:27.22 | *** join/#brlcad kesha (~kesha@49.249.1.165) | |
| 10:48.01 | *** join/#brlcad kesha (~kesha@49.249.1.165) | |
| 12:04.02 | ``Erik | http://www.youtube.com/watch?v=WV4qXzM641o raytracing in '78 |
| 12:04.22 | ``Erik | http://www.youtube.com/watch?v=lAYaX6NuI4M MAGI synthavision in '80 :o |
| 12:48.23 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 13:25.32 | starseeker | sweet! scintilla has some built-in Qt support now, not limited to the GPL 3rd party add-on |
| 13:26.12 | starseeker | dreams of replacing all the "use external editor" commands with a BRL-CAD ascii format aware Qt editing widget... |
| 13:34.22 | starseeker | hah, don't even need to wait for Qt: http://sourceforge.net/projects/scintillatk/ |
| 13:55.36 | ``Erik | did an ascii aware text widget long ago for a gtk+ mud client... handling the codes was easy, making it fast was not |
| 14:02.33 | zero_level | ``Erik I found ap->a_color. but this get converted to uchar using two methods 1.(GAMMA CORRECTION) 2. Straight method with addition of random number(BW 0to 1). |
| 14:03.19 | zero_level | when i write this to ICV image how do i procced with this |
| 14:08.33 | ``Erik | since some image formats cope with gamma correction, I'd imagine a good approach would be to add a gamma to the internal representation, then apply it when converting to the external format... as a very rough C like psuedocode with important bookkeeping bits missing: save_pix() { char *bytes; bytes=bu_alloc(img.w*img.h*3*sizeof(uchar); apply_gamma(img); img2rgb24(img, bytes); fwrite(fd, bytes, img.w*img.h*3*sizeof(uchar)); } |
| 14:12.22 | *** join/#brlcad cstirk (~quassel@96.255.19.39) | |
| 14:12.22 | ``Erik | (and save_png would lack the apply_gamma() call, it would just set the gamma using the png api) |
| 14:15.58 | ``Erik | does that make sense? |
| 14:18.38 | zero_level | and i add gamma to internal structure of ICV_IMAGE struct ? |
| 14:19.46 | ``Erik | yeh |
| 14:19.53 | zero_level | ok. |
| 14:21.49 | ``Erik | icv_image should contain enough information to generate any format without any extra information... then the output functions will just need the icv_image struct and a place to put the output... |
| 14:23.50 | ``Erik | daydreams of an rt mode that uses icv to fill frames for ffmpeg to make animations directly :) |
| 14:34.48 | *** join/#brlcad zero_level (~mohit@66-118-151-70.static.sagonet.net) | |
| 15:06.36 | Notify | 03BRL-CAD:carlmoore * 55890 brlcad/trunk/src/fb/fbfade.c: fix a comment because -h became -H |
| 15:22.38 | Notify | 03BRL-CAD:carlmoore * 55891 brlcad/trunk/HACKING: make repairs to SoureForge and DocBook names, and fix a spelling |
| 15:46.13 | Notify | 03BRL-CAD:carlmoore * 55892 (brlcad/trunk/CMakeLists.txt brlcad/trunk/ChangeLog): remove trailing blanks/tabs |
| 16:30.16 | zero_level | ``Erik how does bif work in rt/view.c i dont see an icv_image_save_open does it use some extern function ? |
| 16:39.30 | Notify | 03BRL-CAD Wiki:Level zero * 5532 /wiki/User:Level_zero/GSOC13/logs: /* WEEK 2 */ |
| 16:40.38 | Notify | 03BRL-CAD Wiki:Level zero * 5533 /wiki/User:Level_zero/GSOC13/logs: /* WEEK 2 */ |
| 16:41.54 | ``Erik | it's in do.c |
| 16:48.03 | starseeker | ``Erik: I'm hoping that scintilla would help with the speed part |
| 16:48.23 | zero_level | ``Erik see brlcad.org/wiki/User:Level_zero/GSOC13/logs I have put links to the current status of the code |
| 17:28.03 | Notify | 03BRL-CAD Wiki:Harman052 * 5534 /wiki/User:Harman052/GSoc2013/Logs: |
| 18:05.42 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 18:24.18 | *** join/#brlcad caen23 (~caen23@92.81.178.221) | |
| 18:46.28 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5535 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 24 June - 30 June */ |
| 19:16.34 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5536 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 24 June - 30 June */ |
| 19:50.00 | ``Erik | very cool... (if alf aho and jeff ullman sound familiar, they're the dudes that did the "dragon book" on compilers) http://i.stanford.edu/~ullman/focs.html |
| 19:57.34 | Notify | 03BRL-CAD:carlmoore * 55893 brlcad/trunk/doc/docbook/system/man1/en/fblabel.xml: new man page for fblabel |
| 19:58.30 | *** join/#brlcad Ch3ck (295cd22a@gateway/web/freenode/ip.41.92.210.42) | |
| 20:00.26 | Ch3ck | hey guys working on the code for adding orthogonal matrix support to the bn_mat_inverse() routine in /src/libbn/mat. |
| 20:00.28 | Ch3ck | mat.c |
| 20:00.50 | Ch3ck | and although the code compiles it don't still get why it fails 3 regression tests.. |
| 20:02.38 | Ch3ck | need some more eyes on this... |
| 20:10.35 | zero_level | ``Erik the issue with write pixel is clear now. But viewedge.c and view.c also writesline in the image. They use scanline(struct in view.c and char buff in viewedge.c) |
| 20:10.50 | zero_level | i am not getting hold of double data in these case. |
| 20:17.45 | ``Erik | view.c uses a_color to construct the scanlines, view_edge.c keeps a 'scanline buffer' and compares neighbors to generate pixel values for the scanlines... (viewedge is also a bit weak in accomplishing it's task) |
| 20:24.21 | Notify | 03BRL-CAD Wiki:41.92.210.42 * 5537 /wiki/User:Izak/GSOC_2013_logs: /* From June 24th to June 28th */ |
| 20:39.44 | brlcad | ``Erik: in issac's patch, he changed it to "hrt?" .. not "her?" |
| 20:40.19 | brlcad | so his latest does "match" .. just no longer the clever 'herz' value |
| 20:53.10 | Notify | 03BRL-CAD:r_weiss * 55894 (brlcad/trunk/include/common.h brlcad/trunk/src/libbrep/libbrep_brep_tools.cpp brlcad/trunk/src/libbrep/libbrep_brep_tools.h): Fixed some DLL errors in the Windows build. |
| 21:07.37 | ``Erik | yeh, I was more concerned that he change it and said "does this match?" instead of having some confidence in what he did... so I'm trying to push an "if you're not sure, try it and see" |
| 21:10.54 | brlcad | starseeker: http://www.dune-project.org/ |
| 21:11.12 | brlcad | ``Erik: yeah, I noticed that as well |
| 21:16.34 | brlcad | not license compatible, but interesting nonetheless |
| 21:34.51 | *** join/#brlcad mpictor (~mark@2601:d:b280:9:d63d:7eff:fe2d:2505) | |
| 21:43.18 | Notify | 03BRL-CAD:carlmoore * 55895 brlcad/trunk/src/fb/fbline.c: remove -h (use -S 1024 instead); implement h,? help; notice that S is a new option |
| 21:57.39 | zero_level | ``Erik: are there functions in different files which modify scanlines ? |
| 22:00.42 | zero_level | because all i dont find the scanlines getting the data from double ap->a_color |
| 22:18.52 | zero_level | although pixels are easy to trace from ap->a_color |