| 00:18.44 | *** join/#brlcad kesha__ (~kesha@49.249.0.218) | |
| 01:16.01 | *** join/#brlcad kesha__ (~kesha@49.249.0.218) | |
| 01:40.45 | brlcad | ``Erik: huh, interesting |
| 01:46.38 | brlcad | zero_level: nice work isolating the expr error |
| 01:47.06 | Notify | 03BRL-CAD:brlcad * 57248 (brlcad/trunk/regress/dsp/run-dsp-case-set-0.sh brlcad/trunk/regress/dsp/run-dsp-case-set-1.sh and 2 others): avoid expr error when there IS a failure, init the right var. |
| 01:47.12 | brlcad | note however that it just fixes the expr message, but the reason it was even encountering that expr line is because something else went wrong before that |
| 01:52.55 | *** join/#brlcad jarray52 (~purplehaz@unaffiliated/jarray52) | |
| 01:53.17 | jarray52 | Is there any way to rotate rendered views using brlcad? |
| 02:03.19 | *** join/#brlcad kesha__ (~kesha@49.249.0.218) | |
| 02:30.32 | *** join/#brlcad maths22_ (~gcimaths@66-118-151-70.static.sagonet.net) | |
| 02:30.46 | *** join/#brlcad hickoryknoll (~hickorykn@66-118-151-70.static.sagonet.net) | |
| 02:33.36 | *** join/#brlcad brlcad (~sean@66-118-151-70.static.sagonet.net) | |
| 02:35.24 | *** join/#brlcad zero_level (~mohit@66-118-151-70.static.sagonet.net) | |
| 02:35.30 | *** join/#brlcad n_reed (~molto_cre@66-118-151-70.static.sagonet.net) | |
| 02:35.31 | *** join/#brlcad Ch3ck (~Ch3ck@66-118-151-70.static.sagonet.net) | |
| 02:35.33 | *** join/#brlcad Izak_ (~Izak@66-118-151-70.static.sagonet.net) | |
| 02:35.36 | *** join/#brlcad ejno (~ejno@unaffiliated/kazaik) | |
| 03:07.19 | brlcad | jarray52: yes and no |
| 03:07.53 | brlcad | I believe you're wanting to see a shaded display of geometry, which is a feature in archer and a raw option in mged |
| 03:08.36 | brlcad | an actual "rendered" view cannot be rotated because it is exactly that -- rendered -- it's an image |
| 03:09.10 | brlcad | you could certainly keep re-rendering new views but doing so interactively usually entails a shaded display (e.g., via OpenGL like most games) |
| 03:17.04 | jarray52 | brlcad: has anyone developed a convenient way to render brlcad objects in a browser? |
| 03:17.23 | jarray52 | brlcad: I know it is not hard... just wonder if there is a prepackaged solution? |
| 03:42.18 | jarray52 | brlcad: I found that it is possible to export objects as obj files, convert them to useable obj files, and then use three.js to render them. |
| 03:46.39 | *** join/#brlcad kimzzzz (~AndChat31@1.38.30.243) | |
| 03:58.50 | brlcad | jarray52: what do you do that makes them "usable" vs unusable? |
| 03:59.25 | brlcad | we should probably update our converter |
| 04:02.43 | jarray52 | I used Three.js as the rendering javascript library, which allowed me to render the objects on a web page. However, the Wavefront OBJ files generated by BRLcad cannot be used directly. So, I used convert_obj_three.py to do the conversion after exporting as a Wavefront obj file. |
| 04:03.35 | jarray52 | However, it has been a while since I've done this. I just recently started working on the project again. |
| 04:03.57 | jarray52 | I was a bit busy with work in the last several months. |
| 04:04.23 | jarray52 | Maybe in a few days I can give better feedback. |
| 04:05.05 | jarray52 | Last we spoke, the CAD to CAM project was on the drawing board but not yet started. Has that project been started for BRLCAD? |
| 04:12.02 | Notify | 03BRL-CAD:phoenixyjll * 57249 brlcad/trunk/src/librt/primitives/brep/brep_debug.cpp: Plot the normal with a scale computed from the size of the surface. |
| 04:36.14 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 06:27.29 | Notify | 03BRL-CAD:phoenixyjll * 57250 brlcad/trunk/src/librt/primitives/brep/brep_debug.cpp: Add blank lines to make the format consistent. |
| 06:47.27 | Notify | 03BRL-CAD:phoenixyjll * 57251 brlcad/trunk/src/libbrep/boolean.cpp: Fix wrong operation type. |
| 06:49.46 | *** part/#brlcad jarray52 (~purplehaz@unaffiliated/jarray52) | |
| 07:04.06 | Notify | 03BRL-CAD:phoenixyjll * 57252 brlcad/trunk/src/libbrep/boolean.cpp: No need to flip the face if it belongs to the brep being substracted. |
| 07:10.15 | Notify | 03BRL-CAD:phoenixyjll * 57253 (brlcad/trunk/include/brep.h brlcad/trunk/src/libbrep/boolean.cpp): Support XOR operation - also used in combinations in BRL-CAD. |
| 07:16.23 | Notify | 03BRL-CAD:phoenixyjll * 57254 (brlcad/trunk/src/libged/brep.c brlcad/trunk/src/librt/primitives/brep/brep.cpp): Extend the command for XOR support. |
| 07:29.41 | Notify | 03BRL-CAD:phoenixyjll * 57255 brlcad/trunk/src/librt/primitives/brep/brep.cpp: Oops.. It should be an assignment.. |
| 08:18.35 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 08:52.56 | Notify | 03BRL-CAD:phoenixyjll * 57256 brlcad/trunk/src/librt/primitives/brep/brep.cpp: Remove the old evaluation code in librt. |
| 09:12.11 | Notify | 03BRL-CAD:phoenixyjll * 57257 brlcad/trunk/src/librt/primitives/brep/brep.cpp: Add header comment. |
| 09:24.38 | Notify | 03BRL-CAD:indianlarry * 57258 brlcad/branches/nurbs/include/brep.h: added UV interval assignments for BANode class variables m_u,m_v in constructor, these were being used without being assigned. since we split the trim curve interval on Horz/Vert tangents we can use the m_start/m_end points to bound the curve the trim |
| 09:26.13 | Notify | 03BRL-CAD Wiki:Phoenix * 6063 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 11 */ |
| 09:28.14 | Notify | 03BRL-CAD Wiki:Phoenix * 6064 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 11 */ |
| 09:34.29 | Notify | 03BRL-CAD Wiki:Phoenix * 0 /wiki/File:Union_sph.png: |
| 09:34.49 | Notify | 03BRL-CAD Wiki:Phoenix * 0 /wiki/File:Diff_sph.png: |
| 09:38.09 | Notify | 03BRL-CAD Wiki:Phoenix * 6067 /wiki/User:Phoenix/GSoc2013/Reports: /* Test Results */ |
| 09:44.14 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 10:05.33 | Notify | 03BRL-CAD:indianlarry * 57259 (brlcad/branches/nurbs/doc/docbook/system/man1/en/bwfilter.xml brlcad/branches/nurbs/include/brep.h and 19 others): Merging trunk into branch 'nurbs' r:57224:57257 |
| 10:06.47 | Notify | 03BRL-CAD Wiki:Huskmate13 * 0 /wiki/User:Huskmate13: |
| 10:23.47 | Notify | 03BRL-CAD:tbrowder2 * 57260 brlcad/trunk/src/libbu/date-time.c: handle error upon call to gmtime |
| 10:39.20 | *** join/#brlcad Ch3ck_ (~Ch3ck@195.24.220.16) | |
| 10:42.29 | Notify | 03BRL-CAD:tbrowder2 * 57261 brlcad/trunk/include/bu.h: revert bu_attribute_value_pair to original definition |
| 10:45.39 | Notify | 03BRL-CAD:tbrowder2 * 57262 brlcad/trunk/src/libbu/avs.c: don't use new function on attributes yet |
| 10:55.42 | Notify | 03BRL-CAD:tbrowder2 * 57263 brlcad/trunk/include/bu.h: remove decl of func which is not yet needed |
| 10:57.11 | Notify | 03BRL-CAD:tbrowder2 * 57264 brlcad/trunk/src/libbu/avs.c: remove func not ready for prime time; restore missing return |
| 11:02.15 | Notify | 03BRL-CAD:tbrowder2 * 57265 brlcad/trunk/src/libged/attr.c: remove untested new attribute attributes |
| 11:36.13 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 11:52.01 | starseeker | http://scribu.net/wordpress/svn-patches-from-git.html |
| 12:23.16 | *** join/#brlcad sobaah (~sober@user-160u7km.cable.mindspring.com) | |
| 13:24.26 | Notify | 03BRL-CAD:tbrowder2 * 57266 NIL: creating a private branch for working on bu_avs_attribute_value_pair |
| 14:28.55 | starseeker | http://arstechnica.com/information-technology/2013/06/c99-acknowledged-at-last-as-microsoft-lays-out-its-path-to-c14/ |
| 14:38.51 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 14:42.27 | Notify | 03BRL-CAD:starseeker * 57267 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Use edge curve index |
| 14:44.42 | Notify | 03BRL-CAD:starseeker * 57268 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: whoops - e_curve, not curve |
| 15:19.01 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b111:f121:0:47:294:f801) | |
| 15:22.42 | Notify | 03BRL-CAD:indianlarry * 57269 brlcad/trunk/src/librt/primitives/pipe/pipe.c: Changed logic in the 'pipe' solid raytracing code in function rt_pipe_elim_dups(). This code removed single hit from hit list when next hit dist < 0.00001 and next hit from same surface. This caused an error in grazing cases where you have legitimate in/out hits on same surface but less than 0.00001 dist. For the pipe we don't expect to |
| 15:22.44 | Notify | hit the same surface within such a small distance unless it is a grazing case in which we really want to remove both hits. Also changed the hardcoded '0.00001' constant to the internal distance tolerence. Also removed related conditional that reported the original error and bailed. |
| 15:23.37 | sobaah | this place has more activity than #freecad which has almost twice as many users |
| 15:41.21 | Notify | 03BRL-CAD:starseeker * 57270 (brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp brlcad/trunk/src/conv/step/g-step/ON_Brep.h): Start setting up instance list population so we have some control over the ordering. Need to change how surface cartesian points are handled, but getting closer. |
| 15:42.14 | starseeker | sobaah: at the moment they have better screenshots ;-) |
| 15:43.01 | starseeker | all IRC channels have their quiet periods |
| 15:44.36 | sobaah | hehe, I see starseeker |
| 15:44.47 | sobaah | =) |
| 16:10.22 | Ch3ck_ | starseeker: just need some clarification here with the regression tests i've written for the pull |
| 16:11.29 | Ch3ck_ | <PROTECTED> |
| 16:12.06 | Ch3ck_ | I also wish to know the command i'll use to compile the test testing the routine or the regression tests should work? |
| 16:43.40 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 6068 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* Aug 26 - Sept 01 */ |
| 16:51.51 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b111:f121:0:47:294:f801) | |
| 16:52.50 | brlcad | hello sobaah |
| 16:54.47 | sobaah | hi brlcad =D |
| 16:57.04 | sobaah | quick question for all: can I use BRL-CAD to do measurements in STEP (.stp) files? Does it snap to planes/features? Last, but not least: can the measurement tool follow an axis; in other words, can it follow a straight line when measuring? |
| 17:29.46 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b111:f121:0:47:294:f801) | |
| 17:55.50 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 17:56.51 | Notify | 03BRL-CAD:mohitdaga * 57271 (brlcad/trunk/regress/asc2dsp.sh brlcad/trunk/regress/dsp/run-dsp-case-set-1.sh and 2 others): Add input arguments in rgress options for pix-bw. These argguments are added as per the recent changes in pix-bw (adding icv in pix-bw.) |
| 18:04.34 | zero_level | feels relieved. |
| 18:27.31 | brlcad | sobaah: we do have a variety of measurement tools, some unconventional, some fairly standard |
| 18:27.54 | brlcad | there is snap to grid |
| 18:28.30 | brlcad | one of our measurement tools is the "angle distance cursor" (ADC) which lets you measure angles and distances |
| 18:29.12 | brlcad | our "nirt" measurement tool shoots a straight ray and reports distances/measurements along that axis |
| 18:31.38 | brlcad | Ch3ck_: have you actuallyy run your new test? |
| 18:32.09 | brlcad | it it runs and tests the command (with clear failure criteria), then that should be just fine |
| 18:32.25 | zero_level | brlcad : Does regress succeds on your machine after 57271 ? |
| 18:33.08 | brlcad | zero_level: rebuilding now, let you know in a couple minutes |
| 18:34.03 | Ch3ck_ | brlcad: well code compiles i have integrated the test into the regress directory. But however when code compiles i don't actually see the pull there |
| 18:34.07 | Ch3ck_ | among mged's command |
| 18:34.23 | Ch3ck_ | and its like the installed version of BRL-CAD interferes |
| 18:34.32 | Ch3ck_ | with my modified version |
| 18:34.51 | Ch3ck_ | so i don't know if i'll have to install the modified version to see how it works |
| 18:34.58 | brlcad | zero_level: so is -B1.0 the final state or do you plan to add -r -g -b? |
| 18:35.18 | brlcad | it's fine if it is, be we have to announce this change because you changed the interface |
| 18:36.34 | Ch3ck_ | brlcad: as concerning the interface, I have integrated the pull into the following( src/ligbed.wdb_obj.c, src/mged, src/tclscripts, src/regress, doc/) others |
| 18:36.47 | Ch3ck_ | wrote the xml file for pull |
| 18:36.51 | Ch3ck_ | for the doc |
| 18:37.03 | Ch3ck_ | but whenever i try to run the binaries in bin/mged |
| 18:37.15 | Ch3ck_ | i see an inteference with usr/dev.../bin |
| 18:37.34 | Ch3ck_ | so I don't know how to resolve this and test what i'm currently working on |
| 18:38.51 | brlcad | that sounds like several different distinct problems |
| 18:39.39 | brlcad | start with what you are running, how are you starting mged? |
| 18:44.34 | zero_level | but brlcad, on bz it is showning different behaviour. |
| 18:45.37 | zero_level | I wish if you could run regress-dsp on your machine. |
| 18:46.27 | zero_level | brlcad : taking about the interface. Lets first see if the regress is on the mark. |
| 18:48.11 | zero_level | I think interface resurrection will require some thinking. I will make suitable changes to doc and other files as in when i see that regress is on the mark :) |
| 18:50.58 | Notify | 03BRL-CAD:brlcad * 57272 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: clean up the AddEdge() function with some comments and spacing for readability, collapse an unnecessary scope |
| 18:54.06 | Notify | 03BRL-CAD:brlcad * 57273 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: understanding a little awry, regroup to reflect where what lines are actually involved in adding the edge |
| 18:54.45 | brlcad | zero_level: regress-dsp fails for me with pix-bw usage statemetns |
| 18:55.27 | brlcad | zero_level: I intend to fork a release branch either later tonight or tomorrow, so this needs to be resolved really quickly |
| 18:55.41 | brlcad | usually a regression failure like this would be reverted if not fixed within 24 hours |
| 18:56.00 | brlcad | it's been a week, so time is running out :) |
| 18:57.13 | zero_level | brlcad : after 57272 ? |
| 18:57.54 | zero_level | brlcad : I mean after 57271 ? |
| 18:58.42 | brlcad | maybe not, checking again |
| 18:58.50 | brlcad | okay, yes that works |
| 18:59.00 | brlcad | but I assume thats the -B -> -B1.0 change yes? |
| 18:59.34 | zero_level | the change also requires adding file size |
| 18:59.44 | brlcad | o.O |
| 18:59.59 | zero_level | I have added that in 57271. |
| 19:00.05 | zero_level | s1 s2 s3/ |
| 19:00.45 | brlcad | eh, what do those options mean?? |
| 19:01.03 | zero_level | the file is of 1X1 2X2 and 3X3 size. |
| 19:01.23 | brlcad | ah, so that's literally the square size |
| 19:01.30 | zero_level | yes. |
| 19:01.39 | zero_level | but the default is set to 512. |
| 19:02.02 | zero_level | I am currently finding the file size in asc2dsp.sh |
| 19:02.46 | brlcad | hm, that is potentially not a minimally impacting change |
| 19:03.12 | zero_level | these are the cons of using icv. ;) |
| 19:03.17 | brlcad | why is the size needed exactly? |
| 19:03.21 | brlcad | codewise |
| 19:03.28 | zero_level | because i want to read the image. |
| 19:03.35 | brlcad | so you read the image |
| 19:03.39 | zero_level | s the code architecture goes this way. |
| 19:03.47 | brlcad | again, codewise |
| 19:03.49 | brlcad | not notionally |
| 19:03.52 | brlcad | what's the code reason |
| 19:03.58 | zero_level | icv_read(..) icv_rgb2gray() icv_write() |
| 19:04.21 | brlcad | that's not a reason |
| 19:04.48 | brlcad | i'm not trying to be difficult or funny, promist |
| 19:04.50 | brlcad | promise |
| 19:04.57 | brlcad | just wondering what the actual technical reason is |
| 19:05.27 | brlcad | icv_read() could specify "read to end of file" instead of a size, for example |
| 19:05.34 | brlcad | so that's not exactly the problem |
| 19:05.45 | brlcad | is there something in icv_read that must know a size? |
| 19:06.09 | zero_level | specifing the size of the image struct. |
| 19:06.15 | zero_level | *specifying |
| 19:06.24 | zero_level | that is the data channel. |
| 19:06.44 | brlcad | can you point me at a line of code? |
| 19:07.03 | brlcad | a place where the size is required where something implicit couldn't be added to mean end-of-file |
| 19:07.25 | zero_level | src/libicv/bw.c |
| 19:07.27 | Ch3ck_ | brlcad: by running bin/mged from the brlcad_build directory |
| 19:07.38 | Ch3ck_ | this is to enable me test the new changes i've made |
| 19:07.38 | zero_level | in line 81 to end. |
| 19:08.19 | brlcad | that's a function, not a line :P |
| 19:08.22 | brlcad | okay so in that function |
| 19:08.26 | zero_level | 102. |
| 19:08.32 | brlcad | presumably the read() call on 103 |
| 19:08.43 | zero_level | malloc call on 102. |
| 19:08.57 | brlcad | except I could hold on the malloc until I know the size |
| 19:09.04 | brlcad | or malloc and realloc |
| 19:09.41 | brlcad | okay, I think I see it |
| 19:10.00 | zero_level | I can do it, |
| 19:10.05 | brlcad | it looks like there's certainly a way to handle this, but it'll require changing all of those read() calls into loops |
| 19:10.46 | brlcad | OR ... hmm |
| 19:10.49 | zero_level | is that advisable ? |
| 19:10.55 | brlcad | who calls bw_read()? |
| 19:11.03 | zero_level | icv_read(..) |
| 19:11.26 | brlcad | and the app calls that, right? |
| 19:11.34 | zero_level | yes. |
| 19:11.46 | zero_level | icv_read is in libicv/fileformat.c |
| 19:12.07 | brlcad | yep |
| 19:12.26 | zero_level | ? |
| 19:13.15 | brlcad | still thinking |
| 19:13.42 | brlcad | to handle potentially streaming applications, you may not know a size |
| 19:13.56 | brlcad | hell, the size may be unended on a real pipe |
| 19:14.31 | brlcad | video streams tend to just be unending data |
| 19:14.50 | zero_level | yes because bw_read can also read from pipes. |
| 19:15.05 | zero_level | u just pass "NULL" for image name |
| 19:15.22 | brlcad | e.g., could see wanting to do something like: cat *.pix | pix-bw | mencode file.avi |
| 19:16.24 | brlcad | I was thinking that you could have some corrollary like icv_guess_file_format() ... you know an icv_guess_file_size() |
| 19:16.31 | brlcad | but even that breaks on the streaming example |
| 19:16.46 | brlcad | (we already have a guess size function somewhere) |
| 19:17.04 | brlcad | so back to the immediate issue at hand |
| 19:17.09 | brlcad | -B to -B1.0 is fine |
| 19:17.14 | brlcad | that is minimally impacting |
| 19:17.23 | brlcad | assuming the output is the same |
| 19:17.54 | brlcad | so it's the requirement to specify a size when the size is not 512x512 that becomes an issue, on a tool that previously could stream |
| 19:18.21 | brlcad | just thinking out loud here |
| 19:18.48 | brlcad | one could argue that it was undocumented behaviour |
| 19:18.57 | brlcad | especially since most tools "default" to 512 |
| 19:19.19 | brlcad | unless we actually document the pipe streaming capability where you don't need to specify a size |
| 19:19.46 | sobaah | brlcad: cool@measurement tools, I see |
| 19:19.49 | sobaah | I will give it a try |
| 19:19.55 | zero_level | brlcad this worked on the previous tool because |
| 19:19.59 | sobaah | thanks for the info brlcad |
| 19:20.29 | zero_level | I mean on the previous rev. because. |
| 19:21.04 | zero_level | pix-bw utility just demand read a pixel do some operations write a pixel |
| 19:33.36 | brlcad | sobaah: yeah, no problem -- we're here to help |
| 19:34.42 | brlcad | zero_level: I'm thinking that it might make sense to implement a buffering option |
| 19:35.02 | brlcad | along with an "unknown" size specification |
| 19:35.46 | brlcad | so you could do per-pixel buffering, scanline buffering, or full frame buffering |
| 19:36.58 | zero_level | brlcad : do u mean in the read function iteself ? |
| 19:37.19 | brlcad | i'm not sure where that would belong just yet, but possibly |
| 19:38.02 | zero_level | can u tell me in icv terms notationally. |
| 19:38.08 | brlcad | the shortest path to make -ssize not necessary for pix-bw however is even more simple |
| 19:38.17 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 19:39.11 | zero_level | do we mean we put everything in the loop. while(flag){ flag = icv_read(..) icv_rgb2gray() icv_write(..) } |
| 19:39.50 | zero_level | but that might not work because we have got rid of file descriptors from icv struct. |
| 19:39.52 | brlcad | no, I don't think that would be good to have in the front-end application |
| 19:40.32 | brlcad | it would probably make the most sense in icv_read() where 'format' becomes a 'mode' bitfield |
| 19:40.48 | brlcad | supporting the data type and the buffering type |
| 19:40.52 | zero_level | is listening. |
| 19:42.07 | brlcad | os icv_read("file.pix", ICV_IMAGE_AUTO|ICV_BUFFER_FRAME, 1024, 1024); would read the whole file in like it does now |
| 19:42.16 | brlcad | s/os/e.g.,/ |
| 19:42.46 | zero_level | and ? |
| 19:43.04 | brlcad | icv_read("file.pix", ICV_IMAGE_AUTO|ICV_BUFFER_PIXEL, 1024, 1024); would read the same number of pixels, but would end up making 1024x1024 calls to read() instead of just 1 |
| 19:43.47 | brlcad | icv_read("file.pix", ICV_IMAGE_AUTO, 0, 0); would read from file.pix until there was no more data to be read? |
| 19:44.10 | brlcad | how does icv deal with stdin data now? |
| 19:44.31 | brlcad | i.e., no filename |
| 19:44.32 | zero_level | you just pass NULL instead of filename. |
| 19:44.36 | brlcad | okay, neat |
| 19:45.37 | zero_level | brlcad : Should I prioritize this work ? |
| 19:45.43 | zero_level | or put this on hold ? |
| 19:45.52 | brlcad | lets not get ahead :) |
| 19:45.53 | zero_level | and work on other formats ? |
| 19:45.57 | brlcad | this is just a discussion :) |
| 19:46.08 | zero_level | pk. |
| 19:46.15 | brlcad | the immediate issue is -s# being required on pix-bw |
| 19:46.33 | brlcad | that is arguably a non-minimally impacting change so it would not be allowed until later |
| 19:46.56 | brlcad | so the question is what minimal change might be possible now to make that option go away |
| 19:47.34 | brlcad | I'm thinking the easiest way is to let a zero-size not imply 512, but instead imply "read until read() fails" |
| 19:48.08 | brlcad | is reminded of wargames... |
| 19:49.42 | zero_level | brlcad : in icv_read ? |
| 19:49.47 | zero_level | or in the app ? |
| 19:50.05 | brlcad | both, no? |
| 19:50.20 | brlcad | the app calls icv_read(..., 0, 0) |
| 19:51.03 | brlcad | then icv_read() in fileformat.c has to handle a zero-size with a loop for read() instead of just one call |
| 19:51.28 | zero_level | ok. |
| 19:51.43 | zero_level | brlcad : thanks for guiding me. |
| 19:51.57 | zero_level | Till what time will u be forking a trunk ? |
| 19:52.27 | zero_level | s/trunk/branch |
| 19:52.29 | brlcad | depends how long it takes to fix this :) |
| 19:52.36 | zero_level | alright. :) |
| 19:53.40 | brlcad | it's a little tricky because basically the size is unknown .. until read() fails, then you know a 1xSIZE image size |
| 19:53.58 | brlcad | it's basically a 1-dimensional image (a pixel stream) |
| 19:54.27 | brlcad | but it could get recorded in icv_image_t as exactly that (height=1, width=N) |
| 19:54.28 | zero_level | but altleast for pix-bw we dont need the file dimensions. ;) |
| 19:54.41 | brlcad | for MANY of them we don't need the dimensions |
| 19:54.49 | zero_level | yes. |
| 19:54.50 | brlcad | that's why this will be interesting to figure out |
| 19:55.04 | zero_level | I did the similar mistake in pixrect and bwrect |
| 19:55.42 | brlcad | I wouldn't call it a mistake |
| 19:56.11 | brlcad | there's nothing wrong with requiring an image size where one was previously implicit |
| 19:56.27 | brlcad | it's really how it affects a user (and will it) |
| 19:56.50 | brlcad | pixrect/bwrect aren't nearly as widely known as our image conversion tools |
| 19:57.07 | zero_level | ok. |
| 19:57.14 | brlcad | there's an argument that their behavior isn't documented, so it can change more easily |
| 19:57.25 | brlcad | I'd have to re-read their manpage to be sure |
| 19:59.46 | brlcad | why does icv_guess_file_format() take a buf? |
| 20:00.15 | brlcad | ah, never mind, I see |
| 20:00.22 | brlcad | yeah, should fix that FIXME |
| 20:00.33 | zero_level | I didnt get a way ? |
| 20:00.53 | zero_level | for the 175th line! |
| 20:01.00 | zero_level | in ppm write. |
| 20:01.35 | brlcad | seems like two functions to me |
| 20:01.52 | brlcad | pass a name in and trim it |
| 20:01.59 | brlcad | or pass a name in and get the format |
| 20:02.16 | brlcad | avoids writing into a buffer, crash, boom |
| 20:02.31 | zero_level | actually we dont need the trimmed name. |
| 20:02.39 | zero_level | so will remove it :) |
| 20:03.15 | brlcad | k |
| 20:03.25 | brlcad | two FIXME comments to remove after you do |
| 20:04.08 | zero_level | can u suggest a trick for ppm_write ? |
| 20:04.21 | zero_level | icv_write i see the way. |
| 20:15.48 | Notify | 03BRL-CAD:starseeker * 57274 (brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp brlcad/trunk/src/conv/step/g-step/ON_Brep.h brlcad/trunk/src/conv/step/g-step/g-step.cpp): Per Keith's advice, just write out directly what we have - face splitting will require a fair bit of work. |
| 20:15.51 | Notify | 03BRL-CAD:indianlarry * 57275 brlcad/branches/nurbs/src/librt/primitives/brep/brep.cpp: just added some debugging code ; currently just hanging up on surface with a singularity so should be pretty easy to work through |
| 20:17.34 | *** join/#brlcad mpictor (~mark@2601:d:b280:3d4:d63d:7eff:fe2d:2505) | |
| 20:24.16 | Notify | 03BRL-CAD:starseeker * 57276 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Allow null edges, use the IsClosed test for surfaces |
| 20:45.59 | Notify | 03BRL-CAD:starseeker * 57277 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: This isn't how we'll eventually have to do this - whole faces will need to be split in addition to curves. Long run we should have some ON_Brep_Split_Closed(ON_Brep *brep) function that does all of that for us and presents this export routine with the final product (such a Brep might be useful in other contexts as well... |
| 21:10.29 | Notify | 03BRL-CAD:starseeker * 57278 (brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp brlcad/trunk/src/conv/step/g-step/ON_Brep.h): More cleanup |
| 21:20.44 | *** join/#brlcad merzo (~merzo@211-113-133-95.pool.ukrtel.net) | |
| 21:26.21 | zero_level | pokes at Notify. |
| 21:26.23 | Notify | 03BRL-CAD:mohitdaga * 57279 brlcad/trunk/src/libicv/bw.c: Add pixel buffer option in bw_read. This makes bw_read more powerfull by having an ability to read without the size specified. Thanks sean for the suggestion. |
| 21:39.01 | Notify | 03BRL-CAD:mohitdaga * 57280 (brlcad/trunk/src/libicv/bw.c brlcad/trunk/src/libicv/pix.c): Make a strict condition regarding the number of pixel read. |
| 21:44.40 | Notify | 03BRL-CAD:mohitdaga * 57281 brlcad/trunk/src/libicv/pix.c: Add pixel buffer option in pix_read(along with r57280). This makes pix_read more powerfull by having an ability to read without the size specified (similar to r57279 for bw_read). |
| 21:49.40 | mpictor | n_reed: perplex, lemon, and re2c do not depend on anything else in src/other do they? |
| 21:50.43 | mpictor | ls |
| 21:50.46 | mpictor | oops |
| 21:53.40 | Notify | 03BRL-CAD:starseeker * 57282 (brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp brlcad/trunk/src/conv/step/g-step/ON_Brep.h): Allow the control points to be inserted into the instance manager after their surface definitions - results in a step file where the 'high level' structure is grouped at the top of the file, making a study of the high level structure slightly easier. |
| 21:54.10 | starseeker | mpictor: that's correct - lemon, re2c and perplex are self contained |
| 21:54.26 | starseeker | (our version, at least - the 'standard' re2c uses bison, iirc...) |
| 21:55.15 | starseeker | n_reed did the work to make re2c use lemon - that's how our Windows build manages to be completely self contained for the lexer/parser bits |
| 21:57.25 | n_reed | I concur. perplex, lemon, and re2c do not depend on anything else is src/other. |
| 21:58.13 | mpictor | ok. I'm going to create a repo with just those 3 |
| 22:03.48 | mpictor | n_reed: are you nreed on github? |
| 22:11.35 | n_reed | nope, that must be somebody else - I've never made a github account as far as I can remember |
| 22:13.54 | mpictor | ok. if you create one, I'll give you access to the repo for perplex/lemon/re2c when I create it |
| 22:18.51 | n_reed | okay, I've signed up as 'nickreed' |
| 22:19.04 | mpictor | ok |
| 22:19.25 | ``Erik | "no snowflake in an avalanche ever feels responsible" http://cheezburger.com/7767875584 |
| 22:23.06 | Notify | 03BRL-CAD:n_reed * 57283 brlcad/trunk/src/libtclcad/tclcad_obj.c: reduce duplicated lines for converting from screen to view coordinates |
| 22:31.25 | Notify | 03BRL-CAD:mohitdaga * 57284 (brlcad/trunk/src/libicv/bw.c brlcad/trunk/src/libicv/pix.c): Allocate image structure before the process starts. |
| 22:35.31 | Notify | 03BRL-CAD:mohitdaga * 57285 brlcad/trunk/src/util/pix-bw.c: Remove in_width and in_height option from pix-bw |
| 22:38.21 | Notify | 03BRL-CAD:mohitdaga * 57286 brlcad/trunk/src/libicv/color_space.c: Avoid recurring division and multiplications. |
| 22:42.37 | Notify | 03BRL-CAD:mohitdaga * 57287 (brlcad/trunk/regress/dsp/run-dsp-case-set-1.sh brlcad/trunk/regress/dsp/run-dsp-case-set-2.sh brlcad/trunk/regress/dsp/run-dsp-case-set-3.sh): Remove square size option from the run-dsp-case-set*.sh |
| 22:43.22 | zero_level | brlcad : the floor is yours. |
| 22:43.55 | zero_level | is feeling rejuvenated. |
| 22:48.22 | mpictor | n_reed: https://github.com/stepcode/baffledCitrus |
| 22:50.15 | Notify | 03BRL-CAD:mohitdaga * 57288 brlcad/trunk/src/util/bw-pix.c: Remove in_width and in_height options. This is possible after latest changes in icv_read function. |
| 22:51.24 | Notify | 03BRL-CAD:mohitdaga * 57289 brlcad/trunk/src/util/bw-pix.c: Correcting app synopsis. |
| 22:52.07 | Notify | 03BRL-CAD:mohitdaga * 57290 brlcad/trunk/src/util/bw-pix.c: Trailing WS |
| 22:56.10 | Notify | 03BRL-CAD:r_weiss * 57291 brlcad/trunk/src/libbrep/PullbackCurve.cpp: Changes to 'libbrep' function 'pullback_samples_from_closed_surface' to correct valgrind warnings that uninitialized memory was being accessed and also fix intermittent seg-faults. The problem was sometimes when 'prev_pt' was used it was undefined. Additional code was added to help debugging. These problems were encountered using the 'step-g' |
| 22:56.12 | Notify | converter. More testing is needed. |
| 23:01.40 | Notify | 03BRL-CAD:mohitdaga * 57292 brlcad/trunk/include/icv.h: Add the information regarding the new feature of icv_read (ability to buffer pixels.) in doxygen comments |
| 23:03.44 | zero_level | ``Erik : brlcad suggested me to change fixed size buffers in libicv/fileformat.c. I think these cases are tricky. I will need your suggestion on how should I go about doing them. |
| 23:04.20 | zero_level | brlcad : I think regress is on the mark now. Pls test it. |
| 23:04.22 | zero_level | thanks |
| 23:04.49 | zero_level | bz gives success, my machine gives success |
| 23:12.21 | brlcad | zero_level: excellent, I'll give it all a look over in a little bit |
| 23:12.26 | brlcad | thank you for the efforts |
| 23:12.40 | brlcad | we'll probably need to do a code review here soon to see what all is needed |
| 23:14.13 | brlcad | zero_level: if you would, I think it's time to start tracking tasks for libicv |
| 23:14.22 | brlcad | woudl you create a src/libicv/TODO file?and put in any items that you think still need to be worked on |
| 23:14.53 | brlcad | you can include things you still have remaining for GSoC, but I'm more thinking about things that need to be worked on that are already there |
| 23:16.29 | brlcad | like making sure this notion of a 0,0 size means "unknown, read until you cannot" for example |
| 23:16.45 | brlcad | or adding support for frame/line/pixel buffering |
| 23:17.02 | brlcad | or turning the supported image types into runtime plugins, etc |
| 23:24.05 | *** join/#brlcad jarray52 (~purplehaz@unaffiliated/jarray52) | |
| 23:28.13 | Notify | 03BRL-CAD:tbrowder2 * 57293 brlcad/trunk/NEWS: update |
| 23:34.28 | Notify | 03BRL-CAD:tbrowder2 * 57294 brlcad/trunk/doc/docbook/system/man1/en/nirt.xml: add missing space |
| 23:35.42 | brlcad | zero_level: there's also some merit towards still retaining/providing a -s size option, because that would define the type of buffering allowed |
| 23:35.52 | brlcad | you want full frame buffering whenever possible, it'll be crazy faster |
| 23:37.06 | Notify | 03BRL-CAD:tbrowder2 * 57295 brlcad/trunk/doc/docbook/system/mann/en/nirt.xml: add space for better appearance |
| 23:40.57 | brlcad | looks like X3D BREP/NURBS support is nearing a stable state |
| 23:45.38 | Notify | 03BRL-CAD:brlcad * 57296 brlcad/trunk/NEWS: tom added an 'attr sort' subcommand with options for sorting case, nocase, value, value-nocase. (recommit/rewording to include this message in log history) |
| 23:46.31 | Notify | 03BRL-CAD:tbrowder2 * 57297 brlcad/trunk/src/nirt/nirt.c: style |