| 00:32.27 | brlcad | elf_: what is the first error you see in http://paste.ubuntu.com/1205747/ ? |
| 00:33.20 | brlcad | that error is you mistyping what I said to add.. :) |
| 00:33.45 | brlcad | the other problem is you're trying to kill something that you didn't even add |
| 03:44.01 | starseeker | woot - built the Qt5 beta, Ogre 1.8, and the qmlogre demo |
| 03:48.12 | starseeker | http://bzflag.bz/~starseeker/qmlogre.png |
| 03:59.57 | brlcad | neat |
| 04:02.09 | starseeker | first time I've ever gotten that complete stack built on my Linux box |
| 04:03.04 | starseeker | not that it does us much good in its current form, but it would be interesting to see how much of the old gsoc work could forward port to a modified qmlogre |
| 04:08.23 | starseeker | really really really wishes the Qt guys would move to a CMake based build after they get Qt5 out the door... |
| 04:09.19 | starseeker | not that we're ever likely to include it in the svn tree, but I can think of one or two nice ways to make it easy to build iff it's present in src/other |
| 04:11.24 | elf_ | line 17-19 |
| 04:11.25 | elf_ | http://paste.ubuntu.com/1206151/ |
| 04:15.33 | brlcad | elf_: yes, what does that error mean? |
| 04:15.46 | brlcad | looks like you fixed the other two issues |
| 04:17.36 | elf_ | damn the server is not starting |
| 04:17.48 | elf_ | I forgot to add the first line you told me to add haven't I? |
| 04:18.13 | brlcad | starseeker: at the point that we are *shipping* something using qt and/or ogre, it becomes strong incentive for having a separate repo for external dependencies |
| 04:18.32 | brlcad | elf_: :) |
| 04:20.14 | elf_ | okay added fbserv -W 360 -N 640 5 /dev/X & at the beginning but I get a complete black image |
| 04:20.43 | brlcad | it should be black until the first rt |
| 04:25.31 | elf_ | it's still black after 5 iterations |
| 04:25.33 | elf_ | http://imageshack.us/a/img821/8387/image5zb.png |
| 04:25.50 | elf_ | http://paste.ubuntu.com/1206165/ |
| 04:31.16 | brlcad | elf_: first up, change the kill line to this: |
| 04:31.16 | brlcad | kill `ps auxwww|grep [f]bserv | awk '{print $2}'` |
| 04:31.46 | brlcad | second, do the image2.png files look right or are they black too? |
| 04:31.58 | brlcad | you just have to debug it, figure out what's wrong |
| 04:32.18 | brlcad | walk through each piece of your script and verify that it's doing what it should be doing |
| 04:32.32 | elf_ | I did an 5 step iteration all of the images are black like the one I posted |
| 04:33.05 | brlcad | run fbserv manually and render into it, just to make sure you understand how that works |
| 04:33.17 | brlcad | read the rt log files that your script is saving |
| 04:34.09 | brlcad | see if there's an error messsage in there |
| 04:36.23 | elf_ | I think the database is corrupted again, I mentioned it that if the scripts run over 190steps the database gets corrupted and after you have to create another one |
| 04:36.25 | brlcad | starseeker: you can see the nurbs bug in my ~sean/tmp folder |
| 04:36.38 | brlcad | elf_: woah, that's bad! |
| 04:36.50 | elf_ | I know |
| 04:37.32 | brlcad | that might be the first place to start after you finish the animations |
| 04:37.55 | elf_ | it's from the simulate command, no matter for how long you seem to run the simulation after the 191 image it doesn't generate anymore images, you get the database corrupt failure |
| 04:38.05 | brlcad | need to move on to other things next week, so hopefully you can get them rendered up and the tutorial finished by then |
| 04:38.54 | brlcad | you'd have to figure out what exactly is "corrupt" and what is failing |
| 04:39.13 | starseeker | brlcad: erm. yeah, not good - that one may need Keith's debugging skills |
| 04:39.43 | brlcad | impressive, handled all those surfaces well otherwise |
| 04:42.04 | brlcad | been keeping an eye out for a great model that really calls for nurbs |
| 04:42.13 | elf_ | The database was not the problem this time |
| 04:42.26 | starseeker | wonder if there's something odd about that surface - doesn't look like it should be a problem |
| 04:42.58 | brlcad | that one turned out to be a bit too sexy, but was still impressed that it converted so well |
| 04:43.09 | brlcad | it's a lot of surfaces |
| 04:43.51 | starseeker | we may need to put something together that will let us extract surfaces hit by a ray into their own individual breps |
| 04:44.05 | elf_ | I get this after every simulation http://paste.ubuntu.com/1206178/ |
| 04:44.16 | elf_ | every step of the simulation* |
| 04:46.11 | brlcad | elf_: ! |
| 04:46.19 | brlcad | elf_: and what does that mean... |
| 04:46.57 | brlcad | or you mean you get that error after 191 |
| 04:47.51 | elf_ | No, this is the error I get now, when running the simulation for 5 steps |
| 04:48.12 | brlcad | ah, and what is it saying? |
| 04:49.14 | elf_ | overlaps? |
| 04:49.22 | brlcad | no |
| 04:50.03 | brlcad | ls -la /home/brlcad/brlcad/s3.g |
| 04:50.28 | brlcad | mged /home/brlcad/brlcad/s3.g ls |
| 04:52.00 | elf_ | bb_reg_sim_cube.r/ cube sim.c/ |
| 04:52.00 | elf_ | bb_reg_sim_gp.r/ cube.r/R sim_cube.r/R |
| 04:52.00 | elf_ | bb_sim_cube.r gp sim_gp.r/R |
| 04:52.00 | elf_ | bb_sim_gp.r gp.r/R |
| 04:52.55 | brlcad | elf_: so you need to take a step back and make sure you understand each and EVERY step in your script |
| 04:53.01 | brlcad | by running them outside the script |
| 04:53.07 | brlcad | forget the loop |
| 04:53.32 | brlcad | you should be able to start up an fbserv, render rt into it, render rtedge into it, and close the fbserv |
| 04:53.35 | brlcad | try to do that |
| 04:53.49 | brlcad | if you can't, then there's something you need to learn |
| 04:54.33 | elf_ | okay :) |
| 04:55.30 | brlcad | start simple, just one object like cube.r, no custom view, default size, etc |
| 04:56.15 | brlcad | assuming you get that working |
| 04:56.45 | brlcad | then just change ONE thing, like making the size match 360x640, and see if it still works |
| 04:57.14 | brlcad | make sure they'll render non-black window without fbserv |
| 04:57.59 | brlcad | make sure rt will render into an fbser |
| 04:58.09 | brlcad | do the same with rtedge independently |
| 04:58.20 | brlcad | then try rt+rtedge using the ov=1 overlay option |
| 05:05.50 | elf_ | It did work when I tried the commands one after the other in the terminal http://imageshack.us/a/img214/8175/imagepf.png |
| 05:06.37 | brlcad | keep goin |
| 05:07.17 | brlcad | should eventually get to running the *exact* same command and it'll work .. or you'll find the bug |
| 05:08.37 | brlcad | just keep adding each option/feature/step one at a time |
| 05:09.32 | elf_ | http://imageshack.us/a/img827/6959/imagetdb.png |
| 05:09.46 | elf_ | this is what it looks like without the -M option though |
| 05:10.03 | elf_ | with rt+rtedge and ov set |
| 05:10.27 | brlcad | so maybe you messed up the view script |
| 05:10.35 | brlcad | it was working, obviously |
| 05:10.41 | elf_ | yep |
| 05:13.41 | elf_ | that's not it, I redid the view script, and I still get completely black images |
| 05:16.08 | brlcad | well this one I can't find for you, you're just going to have to keep looking, rebuild the script, add debugging messages, etc |
| 05:16.18 | brlcad | good luck :) |
| 05:18.56 | elf_ | I just observed that the rtedge command when I run it out of the script it takes effect only the second time it is run |
| 05:19.14 | elf_ | like you have to run it 2 times in a row to take effect once |
| 05:21.16 | elf_ | Okay that wasn't it, solved it |
| 05:21.55 | elf_ | but it looks a little strange the image 360X640.... like the little cube is smashed on the sides maybe another dimensions size will look better |
| 05:27.33 | brlcad | brlman rt |
| 05:28.02 | brlcad | see the -V option, you need that |
| 06:40.41 | CIA-69 | BRL-CAD: 03Elf11 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded a new version of "[[Image:Simulation 256x256.gif]]" |
| 06:49.22 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) |
| 06:49.22 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) |
| 07:10.58 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) |
| 07:10.58 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) |
| 08:06.57 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 08:06.57 | *** mode/#brlcad [+o ChanServ] by lindbohm.freenode.net |
| 08:34.01 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 08:34.01 | *** mode/#brlcad [+o ChanServ] by lindbohm.freenode.net |
| 09:43.26 | *** join/#brlcad elf11_ (~elf11_@109.97.136.125) |
| 09:49.22 | elf11_ | Am I the only one who can't access the brlcad.org website? |
| 10:16.07 | *** join/#brlcad [1]elf11_ (~elf11_@92.80.49.11) |
| 10:51.37 | ``Erik | the server seems to be down |
| 11:27.29 | *** join/#brlcad elf11_ (~elf11_@92.80.49.11) |
| 12:48.39 | *** join/#brlcad Al_Da_Best (~Al_Da_Bes@5ad7b297.bb.sky.com) |
| 16:07.52 | *** join/#brlcad elf (~elf@92.80.49.11) |
| 16:19.24 | *** join/#brlcad elf_ (~elf@92.80.49.11) |
| 17:38.48 | elf_ | Hmm the server looks still down... |
| 17:51.59 | CIA-69 | BRL-CAD: 03starseeker * r52449 10/brlcad/trunk/src/other/libpng/ (52 files in 7 dirs): Update libpng to 1.5.12 - CVE-2012-3386 |
| 18:20.09 | *** join/#brlcad vsrinivas (U2FsdGVkX1@batman.acm.jhu.edu) |
| 18:40.43 | *** join/#brlcad ohworkshop (U2FsdGVkX1@batman.acm.jhu.edu) |
| 18:40.49 | ohworkshop | waves to vsrinivas |
| 18:43.32 | vsrinivas | hiya folks! |
| 18:43.46 | vsrinivas | hi BRL-CADders ... the website seems down. |
| 18:43.59 | elf_ | hello, yes it's down |
| 19:14.29 | CIA-69 | BRL-CAD: 03starseeker * r52450 10/brlcad/trunk/src/librt/test_botpatches.cpp: Don't expose the internal patch processing in the final patch numbers assigned. |
| 19:47.36 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) |
| 19:51.34 | *** join/#brlcad todayman (~paul@128.220.159.17) |
| 20:02.46 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) |
| 20:17.15 | brlcad | elf_: you video killed the web serer :) |
| 20:17.20 | brlcad | server even |
| 20:17.37 | brlcad | more specifically, imagemagick is to blame |
| 20:21.45 | CIA-69 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Image:Simulation 256x256.gif]]" |
| 20:28.07 | brlcad | hi todayman |
| 20:28.39 | brlcad | recognizes that ip address anywhere |
| 20:31.32 | todayman | hello brlcad |
| 20:33.26 | brlcad | how'd the event go? |
| 20:33.37 | brlcad | (I presume it's still going?) |
| 20:36.56 | todayman | It's still going |
| 20:37.29 | todayman | I think i'm the only one looking at brlcad right now, since the website was not responding earlier |
| 20:45.46 | brlcad | sincerest of apologies about that -- ISP was giving hell today and the server was misbehaving in a big way |
| 20:45.50 | brlcad | took hours to sort out |
| 20:50.53 | paulproteuss | waves to todayman |
| 20:51.55 | todayman | I found a bug ~30 mins ago, but I've become more confused by it since then. |
| 20:52.55 | todayman | I'm running "mged -c cup.g" and telling it to create an ogl display manager. |
| 20:53.29 | todayman | The black background is entirely transparent - I can see the windows underneath the mged window |
| 20:54.49 | todayman | In fact, I can drag another window on top of the mged window, then select the mged window, and watch the other window become unfocused |
| 20:55.16 | todayman | It appears to me that the background is not getting drawn at all |
| 20:56.27 | paulproteuss | Well that's good, at least. |
| 20:56.40 | todayman | However, I have modified ogl_setBGColor() to print out when it gets called (it does in fact get called) |
| 20:56.56 | todayman | and also make the background cyan and set the alpha value to 1.0 |
| 20:57.03 | todayman | I still get the same behaviour though |
| 20:57.57 | todayman | paulproteuss: I'm really confused by your comment. |
| 20:58.11 | paulproteuss | I mean, finding a bug is good. |
| 20:58.13 | paulproteuss | At least you can report it. |
| 20:58.16 | todayman | ok |
| 20:58.25 | paulproteuss | From my pedagogical perspective, that's a good thing! |
| 20:59.02 | todayman | I'm not even completely sure that this is a BRL-CAD problem - |
| 20:59.14 | paulproteuss | What does brlcad think? |
| 20:59.55 | todayman | I find the windows underneath the mged window changing to be very unsettling |
| 21:00.48 | CIA-69 | BRL-CAD: 03starseeker * r52451 10/brlcad/trunk/src/librt/test_botpatches.cpp: Generate brep edges, not just nurbs curves. |
| 21:01.49 | brlcad | todayman: you're the second person in as many days to report a background issue |
| 21:02.29 | todayman | I also get different behavior when I run it through gdb |
| 21:02.43 | brlcad | so it's very likely that you have encountered a very-recently introduced bug |
| 21:03.31 | brlcad | at least it's possible, I'd need a little more information with exact steps to see if we can reproduce the issue here |
| 21:03.34 | todayman | In that case, the mged window doesn't update the same way |
| 21:04.11 | brlcad | if you run "rt" within mged, it should pop up a window -- does that window have a background? |
| 21:04.35 | brlcad | you can try a variety of windowing methods |
| 21:04.58 | brlcad | rt # uses the default windowing mechanism |
| 21:05.09 | brlcad | rt -F/dev/X |
| 21:05.14 | brlcad | rt -F/dev/ogl |
| 21:05.29 | todayman | Do I need to pass anything to rt? |
| 21:05.43 | brlcad | you have to have drawn some geometry |
| 21:05.54 | brlcad | if you have a database open, can just run "make sph sph" |
| 21:05.58 | brlcad | if not, opendb test.g |
| 21:06.32 | brlcad | otherwise, run "draw ..." or "e ..." to display something first |
| 21:06.34 | todayman | made the geometry |
| 21:06.43 | todayman | running just "rt" does not have a background |
| 21:06.58 | brlcad | can you paste a screenshot somewhere? |
| 21:07.16 | todayman | running with "rt- F/dev/X" does have a background |
| 21:07.29 | todayman | I also get the background when I select the X display manager at the initial prompt |
| 21:08.00 | brlcad | can paste here: http://imageshack.us/ |
| 21:08.47 | brlcad | what about -F/dev/oglD ? |
| 21:09.45 | todayman | oglD does not have a background |
| 21:10.00 | todayman | I don't have a screenshot program on my laptop right now, so I'm working on that |
| 21:10.25 | brlcad | you have x11? :) |
| 21:10.44 | todayman | yes |
| 21:11.10 | brlcad | x11 has an ancient tool for screenshotting, xwd |
| 21:11.51 | brlcad | if you run xwininfo |
| 21:12.12 | brlcad | and click in one of the transparent mged or rt windows, it'll dump window information |
| 21:12.35 | brlcad | xwd -id window_id | convert xwd:- window.png |
| 21:12.43 | brlcad | (assuming you have image magick installed |
| 21:13.15 | brlcad | or "xwd -root | convert xwd:- screenshot.png" for your whole screen |
| 21:13.40 | brlcad | if you don't have imagemagic, can pipe it through xwdtopnm |
| 21:13.57 | brlcad | xwd -root | xwdtopnm | pnmtopng > screen.png |
| 21:14.19 | brlcad | stops :) |
| 21:14.32 | todayman | They're at http://acm.jhu.edu/~poneil/brlcad/ |
| 21:15.07 | todayman | Venkatesh remembers something like this with NVidia drivers from a while back |
| 21:15.09 | brlcad | wow, that's worse than I was imagining |
| 21:16.37 | todayman | I'm not sure how this bug is able to determine the difference between the pixels drawn by glClear and how the lines get drawn |
| 21:17.18 | todayman | I'm not sure what part of the graphics stack would know that and mess it up |
| 21:17.31 | brlcad | yeah, that is bizarre |
| 21:18.11 | brlcad | well, the good news is that is pretty isolated code |
| 21:20.20 | brlcad | and it's gotta be something new/simple |
| 21:20.41 | brlcad | the only change that comes to mind isn't even in that library |
| 21:21.06 | brlcad | so fixing that bug would be awesome if you can figure out what's going on -- glad to help point you at the sources involved |
| 21:24.15 | brlcad | todayman: out of curiosity, does the "archer" command line tool start up with a background? |
| 21:26.10 | todayman | archer looks OK: http://acm.jhu.edu/~poneil/brlcad/archer.png |
| 21:26.39 | brlcad | so that's telling and even more perplexing -- they're using almost identical display code |
| 21:27.32 | todayman | I'm wondering if it is worth attempting to restart with different GL drivers |
| 21:27.45 | brlcad | so the directories involved are src/mged and src/libdm (and src/libfb for the windows that pop up when you ran "rt") |
| 21:28.22 | brlcad | the rt framebuffers should be easier to debug if they exhibit the problem |
| 21:28.59 | brlcad | because you can run those outside of mged and it's literally just a couple files to look at |
| 21:29.15 | brlcad | you said "rt" gave a transparent window? |
| 21:29.17 | todayman | I looked at src/libdm/dm-ogl.c a little bit |
| 21:29.28 | todayman | yes, "rt" gave a transparent window |
| 21:30.07 | brlcad | okay, so that's probably best then -- outside of mged, can run "rt file.g sph" and it should give the transparent window |
| 21:30.38 | brlcad | if so, then whatever is going wrong should be isolated to src/libfb, probably to the if_ogl.c file |
| 21:31.15 | todayman | "rt file.g sph" gives the transparent window |
| 21:35.58 | *** join/#brlcad todayman1 (~paul@128.220.159.17) |
| 21:38.51 | todayman1 | I've just set breakpoints on glClear and glClearColor while I ran "rt cup.g sph" and they didn't get hit |
| 21:44.41 | todayman1 | glClear does get called when I run mged, though |
| 21:46.31 | brlcad | that's interesting for the fb window |
| 21:46.50 | brlcad | glClear should get called on expose events and on directed ogl_clear() calls |
| 21:47.26 | brlcad | so your window manager might not be sending an expose event, or something may be needed to provoke it |
| 21:48.12 | brlcad | ogl_do_event() is where the Expose callback should be coming after calling XCheckWindowEvent() |
| 21:49.25 | brlcad | could add breaks on ogl_clear and on expose_callback to see if either are called |
| 21:49.37 | brlcad | does the "fbhelp" command display a transparent window? |
| 21:50.19 | brlcad | "fbclear 255 0 0" should display a red window |
| 21:55.03 | CIA-69 | BRL-CAD: 03starseeker * r52452 10/brlcad/trunk/src/librt/test_botpatches.cpp: Generate loops - not doing anything with them yet, as we need to generate faces and surfaces first, but restore basic loop building logic with BrepEdge input. Still need to rework outer loop detection. |
| 21:55.30 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) |
| 21:57.55 | starseeker | wow - haven't had to restart screen in a while |
| 21:58.30 | brlcad | starseeker: yeah, server went through hell in the AM |
| 21:58.36 | brlcad | lost our screen sessions |
| 21:59.04 | starseeker | glad it's back :-) |
| 21:59.14 | starseeker | 's withdrawal twitching subsides :-P |
| 22:03.08 | brlcad | missed out on a nice opportunity, though -- a crash course on contributing to open source was going on at jhu today and we were set up for it |
| 22:04.14 | elf_ | brlcad, how was that possible, I don't think it was over 1mb... |
| 22:11.27 | brlcad | elf_: it's not, but somehow it made imagemagick massively misbehave |
| 22:12.02 | brlcad | I'd hold off on uploading another until it can be tested more carefully |
| 22:13.02 | elf_ | okay, so I won't upload it then, will just modify the script, to the latest version and will add the youtube links |
| 22:22.45 | CIA-69 | BRL-CAD: 03Elf11 07http://brlcad.org * r4439 10/wiki/Mged_simulation: |
| 22:31.58 | CIA-69 | BRL-CAD: 03starseeker * r52453 10/brlcad/trunk/src/librt/test_botpatches.cpp: |
| 22:31.58 | CIA-69 | BRL-CAD: Move the surface fitting code into its own function, add in some edge points |
| 22:31.58 | CIA-69 | BRL-CAD: from the nurbs curves to the fit, change the face generation to not |
| 22:31.58 | CIA-69 | BRL-CAD: automatically create loops for the surfaces. This currently produces an invalid |
| 22:31.59 | CIA-69 | BRL-CAD: brep with a 'has no loops' error, but that's expected - we now need to generate |
| 22:31.59 | CIA-69 | BRL-CAD: our own trimming loops using the surface/loop/edge information and |
| 22:32.00 | CIA-69 | BRL-CAD: pullback_curve. |
