| 01:01.59 | starseeker | ``Erik: last patch to Movitz Dec 2009 |
| 01:02.02 | starseeker | :-/ |
| 01:08.08 | CIA-40 | BRL-CAD: 03brlcad * r39600 10/brlcad/trunk/NEWS: jesica provided spanish translations for lessons 4, 5, 7, 8, 10, 11, and 12 of the mged vol II tutorials. |
| 01:09.15 | ``Erik | how retarded, jogre has absolutely nothing to do with ogre3d |
| 01:22.39 | *** part/#brlcad Sh1fty (~Sh1fty@unaffiliated/sh1fty) |
| 01:43.19 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) |
| 05:58.39 | *** join/#brlcad PrezKennedy (~Prez@96.31.84.96) |
| 10:50.15 | *** join/#brlcad Elrohir (~kvirc@p4FC5B0AF.dip.t-dialin.net) |
| 10:57.26 | *** join/#brlcad Stattrav (~Stattrav@117.192.143.180) |
| 11:00.51 | mafm | ``Erik: hopefully they fixed the singleton implementation so a singletton pattern is a singleton pattern, unlike C++ Ogre? |
| 11:01.13 | mafm | that would be ++ for them |
| 11:06.38 | *** join/#brlcad |Elrohir| (~kvirc@p4FC595DB.dip.t-dialin.net) |
| 12:33.40 | *** join/#brlcad |Elrohir| (~kvirc@p4FC595DB.dip.t-dialin.net) |
| 12:48.01 | CIA-40 | BRL-CAD: 03starseeker * r39601 10/brlcad/branches/dmtogl/ (Makefile.am TODO.togl): Make a list of togl stuff to be handled before its 'ready for prime time' |
| 13:48.40 | brlcad | mafm: he was messing with "jogre" .. probably hoping it had something to do with the ogre project, yet it doesn't |
| 13:49.51 | ``Erik | was doing a survey of scenegraph/game engines |
| 13:54.09 | mafm | ``Erik: I would go for OpenSceneGraph |
| 14:30.26 | ``Erik | openscenegraph seems optimal for scientific display, cad, etc... ogre looks very game oriented, and my survey was ... game oriented :D |
| 14:30.31 | ``Erik | (for a personal project) |
| 14:31.10 | ``Erik | panda3d came out on top last time I did it, wanted to see if anything'd changed *shrug* |
| 14:41.07 | CIA-40 | BRL-CAD: 03starseeker * r39602 10/brlcad/branches/dmtogl/src/libfb/if_togl.c: Take a hint (hopefully correctly) from the ogl framebuffer code and get rid of the globals - put everything into a struct and pass it around in ifp. |
| 14:50.28 | brlcad | starseeker: nice! |
| 14:51.06 | starseeker | brlcad: heh - thanks, but it doesn't do anything yet ;-) |
| 14:52.25 | starseeker | is eyeing the texture code in isst_tcltk.c... |
| 14:52.28 | starseeker | hmm |
| 14:54.01 | CIA-40 | BRL-CAD: 03starseeker * r39603 10/brlcad/branches/dmtogl/src/libfb/if_togl.c: Well, this doesn't crash outright, so hopefully it's somewhat close to correct... |
| 14:54.39 | brlcad | starseeker: was referring to the elimination of globals |
| 14:54.55 | starseeker | ah, thanks :-) |
| 14:55.00 | brlcad | simple change, but super good stuff for maintainability |
| 14:55.07 | starseeker | that always bothered me about the Tk fb code... |
| 14:55.23 | starseeker | in fact, should probably do it there too |
| 14:55.42 | starseeker | (assuming we want the vanilla Tk code after togl is fully fleshed out...) |
| 14:56.49 | ``Erik | hm, new stellarium out |
| 14:57.58 | ``Erik | plugins, artificial satellites, improved ui, aztec stuff |
| 15:03.16 | starseeker | don't suppose they went LGPL? |
| 15:03.59 | ``Erik | wtffff... http://www.asylum.com/2010/06/09/phoneballs-makes-teabagging-a-snap/ |
| 15:05.05 | starseeker | er... hmm. "GNU GPL v2, Public Domain (The bulk of the code is GPLv2/LGPL with some sections of code with BSD-like licenses." |
| 15:05.58 | starseeker | https://launchpad.net/stellarium |
| 15:06.31 | CIA-40 | BRL-CAD: 03r_weiss * r39604 10/brlcad/trunk/src/conv/obj-g_new.c: adding function documentation |
| 15:06.33 | starseeker | did they switch off of sourceforge?? |
| 15:09.08 | starseeker | humph. only a library they use is GPL |
| 15:09.13 | starseeker | er LGPL rather |
| 15:09.43 | starseeker | supposes he could ask nicely, but it probably wouldn't help us much anyway... |
| 15:24.18 | ``Erik | "linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134) |
| 15:24.19 | ``Erik | nice |
| 15:40.00 | mafm | ``Erik: maybe for game oriented-ness is better, and I think that it has ports for consoles and everything |
| 15:40.10 | mafm | but they are sometimes a bit hardnosed/dumb |
| 15:40.41 | mafm | they took months to acknowledge patches from me fixing X-Windows/GLX problems with their code |
| 15:40.50 | mafm | discussing that it was not the right solution |
| 15:41.25 | mafm | I gave up, and 6 months later they said something along the lines of "OK, we applied your patch at last" |
| 15:41.50 | mafm | it was something like they disabled key repetition in X |
| 15:42.06 | brlcad | that's some mad function documentation |
| 15:42.32 | mafm | so if your application crashed or something, the rest of the apps in your x session wouldn't have autorepeat anymore |
| 15:42.39 | brlcad | fun :) |
| 15:43.00 | mafm | and they didn't acknowled it as a misbehaviour/bug |
| 15:43.19 | brlcad | that's not unique to them, change in almost every open source project takes a disproportionate amount of discussion and long time for a change to take effect |
| 15:43.20 | mafm | it was not the leader, but some of the minions taking care of GLX port, IIRC |
| 15:44.02 | mafm | well, I don't mind the discussion, Debian flamewars are epic |
| 15:44.05 | *** join/#brlcad |Elrohir| (~kvirc@p4FC595DB.dip.t-dialin.net) |
| 15:44.25 | mafm | and I didn't mind it by that time, I just provided the patch and pointed the problem |
| 15:44.40 | mafm | the thing is that they didn't think that this was a problem, or not their problem anyway |
| 15:44.59 | mafm | when they were in effect fucking up all your X session |
| 15:45.12 | mafm | (probably that's a shortcoming in X, but still...) |
| 15:45.22 | brlcad | things are only quick when a) you have commit access or b) you have an open line of communication with someone that does and the change is trivial and/or completely obvious |
| 15:45.33 | mafm | another patch that I provided is that, if your windows is idle/minimized/etc, -> sleep() |
| 15:46.00 | mafm | so you get 0 or 1% processor usage when not viewing the application |
| 15:46.09 | brlcad | hm, that could be bad for some apps, a network game for example, that needs to keep receiving events |
| 15:46.17 | brlcad | at a given rate |
| 15:46.31 | mafm | brlcad: that sounds like a corrupt cartel of drug dealers or something :D |
| 15:47.00 | mafm | the sleep was something like 0.01s or so, not bad for anything |
| 15:47.05 | brlcad | most real-time gaves have that requirement, they lock clocks together so that the game state stays synchronized |
| 15:47.27 | mafm | or maybe just avoiding repainting, remember that it was GLX! |
| 15:47.46 | mafm | that one was accepted much sooner or immediately, IIRC |
| 15:47.47 | brlcad | the window manager should be taking care of that if it's minimized |
| 15:47.52 | mafm | but that was like 5 years back... |
| 15:48.38 | mafm | so? the window manager does that, but the app has to react |
| 15:49.26 | mafm | if you're playing a youtube video but are in another workspace, you can just continue the playback and output audio, but no need to waste resources on updating the video window |
| 15:49.57 | brlcad | presuming there's no logic being calculated in the draw portion, that's a big assumption even if it's a reasonable common way to structure the loop |
| 15:50.27 | mafm | well, that's their part to know about |
| 15:50.36 | brlcad | that's the apps job to know about it |
| 15:50.39 | mafm | mine was to point the problem and provide a simple patch :) |
| 15:50.49 | brlcad | not the underlying thing I'm drawing into |
| 15:51.17 | brlcad | really depends on the specifics of the API routines in question |
| 15:51.27 | mafm | well, it was the glx driver |
| 15:51.48 | mafm | just to repaint the buffers or something like that |
| 15:51.52 | brlcad | you mean ogre's glx driver? |
| 15:51.57 | mafm | yes |
| 15:51.58 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) |
| 15:52.22 | mafm | ogre has different drivers for X, windows etc... loaded as plugins or something like that |
| 16:33.07 | brlcad | http://www.opendesign.com/guestfiles |
| 16:33.21 | brlcad | intersting, a 225 page overview of their discoveries on the .dwg file format |
| 17:29.30 | CIA-40 | BRL-CAD: 03erikgreenwald * r39605 10/brlcad/trunk/src/libicv/Makefile.am: need tcl cpp flags for bu.h |
| 17:34.27 | ``Erik | hm, machine with 512 atom cpu's |
| 18:02.30 | *** join/#brlcad akafubu (~akafubu@unaffiliated/akafubu) |
| 19:07.50 | *** join/#brlcad Stattrav (~Stattrav@117.192.134.128) |
| 19:18.16 | starseeker | brlcad: what's that "US Government Restricted Rights" statement amount to? |
| 19:26.19 | *** join/#brlcad akafubu (~akafubu@unaffiliated/akafubu) |
| 19:35.22 | CIA-40 | BRL-CAD: 03starseeker * r39606 10/brlcad/branches/dmtogl/src/libfb/ (Makefile.am if_togl.c): For some reason, not getting a legal AGL context. |
| 19:49.37 | starseeker | successfully hard crashes his Mac again |
| 19:53.27 | brlcad | starseeker: what statement and what context? |
| 19:53.57 | starseeker | that dwg overview |
| 20:14.50 | *** join/#brlcad Stattrav (~Stattrav@117.192.129.219) |
| 20:44.33 | CIA-40 | BRL-CAD: 03starseeker * r39607 10/brlcad/branches/dmtogl/src/libfb/if_togl.c: Whoops - let's give Togl_GetToglFromObj the right info... |
| 20:47.59 | *** join/#brlcad Stattrav (~Stattrav@117.192.129.219) |
| 21:27.45 | brlcad | starseeker: ah, there are a few basic categories that describe what rights the government has with respect to a given work including limited rights, unlimited rights, and restricted rights |
| 21:30.28 | brlcad | gov usually aims for unlimited rights on a gov-produced work, limited rights on a non-gov (i.e. contractor) works, and restricted rights on non-gov software |
| 21:31.04 | starseeker | nods - so does that preclude us using that document as a basis for a dwg importer? |
| 21:33.46 | brlcad | it's SORT OF like, if this were copyrights, the difference between being the copyright owner (unlimited rights), being granted a usage license by a copyright holder (limited rights, like how you can use a movie DVD), or being granted an irrevocable shared license/copyright (restricted rights) |
| 21:36.34 | brlcad | so with regards to most software, telling the gov they have restricted rights basically lets them know that they don't have exclusive rights and they don't have useless rights |
| 21:36.51 | brlcad | i.e., they get to behave like people do wrt the copyright |
| 21:36.57 | starseeker | nods |
| 21:36.58 | starseeker | got it |
| 21:37.29 | brlcad | at least that's a loose explanation |
| 21:37.58 | brlcad | it doesn't affect our (or ARL) from using it |
| 21:38.14 | starseeker | scowls at Togl_SwapBuffers |
| 21:38.21 | starseeker | wow what a performance hog |
| 21:38.42 | brlcad | restricted rights in that context basically just means ARL can't claim it as theirs (exclusively), e.g., can't try to stop others from using it |
| 21:39.00 | starseeker | cool |
| 21:39.34 | brlcad | if they had limited rights, they could use it internally but not necessarily redistribute it, derive off of it, etc |
| 21:39.50 | brlcad | if they had unlimited, they could go after how everyone else uses it |
| 21:41.02 | starseeker | has been in open source too long - the idea of going after how someone else uses something is relatively foreign to his thinking ;-) |
| 21:43.08 | starseeker | brlcad: well, with ``Erik |
| 21:43.18 | starseeker | 's help we now have a functioning togl framebuffer |
| 21:46.04 | starseeker | albeit a very slow one |
| 21:46.32 | starseeker | looks like both isst and the togl framebuffer may benefit from the timing code |
| 21:52.15 | CIA-40 | BRL-CAD: 03r_weiss * r39608 10/brlcad/trunk/src/conv/obj-g_new.c: documenting functions, some cleanup |
| 21:55.58 | starseeker | brlcad: is BzTime.h the place to start in bzflag for the timing code? |
| 21:59.09 | starseeker | or rather, common/BzTime.cxx? |
| 22:02.49 | starseeker | winces... I wonder if semaphores are going to be a performance issue when redoing this code in libbu... |
| 22:07.44 | ``Erik | SwapBuffers wont' be the "performance hog", it's basically just saying "hey, uh, card? all that stuff I sent over for you to do? yeah, uh, I'm gonna wait until it's all done." |
| 22:08.31 | starseeker | nods - so that's why CPU use is piddling on easy raytraces, and still maxed out on the hard ones |
| 22:09.17 | ``Erik | 's why I was talking about moving the draw code out of the function, parallelize the gpu and cpu work |
| 22:09.39 | ``Erik | the glFlush toglSwapBuffers() calls is serializing things |
| 22:09.40 | starseeker | time for bu_time and associated functions :-) |
| 22:10.18 | starseeker | ``Erik: that might be possible, but my initial attempt wasn't very happy - I think there might be an issue due to our "driving" things from the C side |
| 22:10.29 | ``Erik | to what end? if timesincelastdrawn > magicnumber draw ? |
| 22:10.40 | starseeker | nods |
| 22:11.36 | ``Erik | would # of lines be an adequate and simpler compromise? |
| 22:11.54 | starseeker | possibly, but that wouldn't handle isst |
| 22:12.31 | ``Erik | isst/tcl is driven by the togl event loop which does what you attempted to do earlier |
| 22:12.52 | ``Erik | isst/gtk and isst/sdl are just so chock full of awesomesauce, it's irrelevant :D |
| 22:13.58 | starseeker | so, what are you advising? |
| 22:14.54 | ``Erik | I'm advising an evening of simpsons, family guy, and kicking my feet up :D |
| 22:15.03 | starseeker | lol |
| 22:15.14 | starseeker | fair enough - I need to get to the gym anyhow |
| 22:15.22 | ``Erik | I don't think the issues you're seeing in the fb are terribly relevant to the isst stuff *shrug* but I could be mistaken |
| 22:16.19 | ``Erik | if we can guarantee threading in the fb, I'd save have an opengl interactor thread that paints when the context is dirty, otherwise just hangs out |
| 22:17.00 | ``Erik | if not, the cheap&easy solution might be if(!(nframes&0xf)){nframes=0; draw();} nframes++; |
| 22:17.02 | starseeker | ``Erik: as it stands, I don't think we assume that? |
| 22:17.40 | ``Erik | or suck it up and be slow on trivial raytraces |
| 22:17.43 | starseeker | threading is in librt, not libfb (I think...) |
| 22:18.02 | starseeker | what's wrong with if timesincelastdrawn > magicnumber draw ? |
| 22:18.11 | ``Erik | I think librt used to be set up so it could be used in environments that do not support threading |
| 22:19.06 | ``Erik | well, I suppose if you want to do the math, you can do some gettimeofday() stuff *shrug* um, the sdl isst has that in an older revision, I switched to SDL_GetTicks() though |
| 22:19.53 | starseeker | nods - that's what I was looking at with the BzFlag timing code - using either a version of that logic, SDL_GetTicks stuff, or some hybrid in a libbu routine |
| 22:19.56 | ``Erik | just be careful, fbsd, solaris, and windows can provide microsecond accuracy, linux does it in 10 |
| 22:20.09 | ``Erik | 10microsecond increments |
| 22:20.16 | ``Erik | so if you care about timing that fine grained, ... |
| 22:20.18 | starseeker | brlcad and I were discussing that earlier - apparently they've had to handle such things for BzFlag |
| 22:20.35 | ``Erik | bz might do scary things like use rtdsc or something O.o |
| 22:21.06 | ``Erik | rdtsc rather |
| 22:21.24 | starseeker | don't see it here at least: http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/src/common/BzTime.cxx?revision=21083&view=markup |
| 22:25.01 | ``Erik | ah, gettimeofday(), is the call frequency being throttled somehow, mebbe vsync is on in the ogl display? |
| 22:26.31 | starseeker | dunno, haven't dug that deep yet |
| 22:27.09 | ``Erik | looks like how sdl gets time, too heh :) |
| 22:27.14 | ``Erik | on unix, anyways |
| 22:27.29 | starseeker | which is what you're using in isst/sdl? |
| 22:27.39 | ``Erik | yup |
| 22:27.50 | starseeker | not a major performance impact? |
| 22:27.59 | ``Erik | doesn't port to windows, so I went with the sdl variant *shrug* |
| 22:28.06 | ``Erik | well, it's floating point math and a system call |
| 22:28.31 | ``Erik | but scanlines are pretty low cost |
| 22:28.34 | starseeker | still should be quicker than waiting for SwapBuffer though... |
| 22:29.23 | ``Erik | (still serializes it, it just stops progress once every X microseconds instead of once every Y microseconds... parallelizing it would be better resource utilization) |
| 22:30.03 | starseeker | ``Erik: but how much of a todo would parallelizing it be? mightn't that require altering rt, mged, and other such clients? |
| 22:30.37 | starseeker | (that was one of the things I was headed towards having to deal with with TclThreads and tk framebuffer...) |
| 22:30.46 | starseeker | sounded a bit scary |
| 22:31.50 | starseeker | as far as I know, we don't use threading very much outside of librt itself, although I could be wrong |
| 22:32.15 | ``Erik | does librt itself do threading? or is that all in the rt's? |
| 22:32.36 | starseeker | good question... it might be in the rt's |
| 22:32.59 | ``Erik | cut.c db_tree.c and many.c |
| 22:33.23 | ``Erik | rt/view.c and rt/worker.c use it, too |
| 22:33.26 | ``Erik | bu_parallel is the func... |
| 22:33.52 | ``Erik | one of these days, I'll make adrt use it |
| 22:34.02 | starseeker | yeah, view.c, worker.c, and viewmlt.c |
| 22:34.12 | ``Erik | wasn't gonna count viewmlt.c |
| 22:34.18 | ``Erik | it doesn't really do too much :D |
| 22:34.29 | starseeker | there are a couple calls to it in librt |
| 22:34.36 | ``Erik | <-- points where he noted them |
| 22:37.19 | ``Erik | http://brlcad.org/~erik/bdayskelly.jpg |
| 22:37.23 | starseeker | yeah, it's not used much (and not at all in libfb) |
| 22:37.47 | starseeker | or libdm for that matter |
| 22:39.25 | starseeker | sounds like a whiteboard discussion |
| 22:40.14 | starseeker | well, the timing thing may be fairly straightforward and a useful crutch until the more radical multithreaded design discussions can be hashed out |
| 22:40.32 | ``Erik | yeh *shrug* |
| 22:40.57 | ``Erik | bz and sdl seem to use the same thing, my old game stuff looks the same *shrug* |
| 22:41.31 | starseeker | well, bz is certainly interactive enough (and your isst/sdl looks pretty awesome too) |
| 22:42.07 | starseeker | (note to self - bug Bob to make is tree widget in Archer a packable stand-alone megawidget) |
| 22:43.07 | starseeker | alrightie, gym |
| 23:10.34 | brlcad | the critical bits for stability, since it uses gettimeofday, are ensuring we don't go back in time and affixing a processor affinity |
| 23:11.53 | ``Erik | well, in this certain situation, affinity shouldn't matter and going backwards falls out in the equation |
| 23:11.58 | brlcad | that and windows timing is particularly tricky |
| 23:12.12 | brlcad | using the qpc is riddled with pot holes |
| 23:12.27 | ``Erik | if( (nowtime() - lasttime) > WAITTIME ) { lasttime = nowtime(); draw(); } |
| 23:12.45 | ``Erik | not like we're doing a physics sim in it |
| 23:12.54 | brlcad | going backwards was surprisingly hard to detect -- there were some CPUs that actually had an unstable gettimeofday() during normal use |
| 23:13.31 | brlcad | some that would throttle clock ticks and slow the system clock down during power management |
| 23:13.42 | ``Erik | heh, going backwards sends a kernel scheduler into all sorts of fits, fun seeing the warning logs in bsd :D |
| 23:13.52 | brlcad | linux 2.6 and amd64 was a problem child for a while, iirc |
| 23:14.42 | brlcad | a sudden ntp change can also occur causing a one-in-a-billion style bug to detect without the negative time compensation |
| 23:15.18 | brlcad | fun stuff |
| 23:16.24 | ``Erik | still shouldn't be an issue for this application, provided we have something at the very end that forces a draw to cope with the possible condition of the next requested render being way after the last scanline is posted |
| 23:16.53 | brlcad | starseeker: bz's timer was originally non-mutexed if you want a simplified version |
| 23:17.12 | brlcad | starseeker: but they're basically equivalent to BU_SEMSYSCALL protections |
| 23:18.37 | brlcad | it'd be an issue if you did "if( (nowtime() - lasttime) > WAITTIME ) { lasttime = nowtime(); draw(); }" |
| 23:18.52 | brlcad | nowtime would be negative and would stall the draw until it catches up |
| 23:19.51 | ``Erik | yeah, thus the flush at the end *shrug* and negative? I was thinking unsigned counting from epoch |
| 23:21.06 | brlcad | "nowtime() - lasttime" would be negative as lasttime would be (unsigned)1234, now would be back in time at (unsigned)123, making it perpetually < WAITTIME until nowtime catches up |
| 23:21.34 | brlcad | flush would help, but it'd still potentially stall in bizarre odd ways |
| 23:21.59 | brlcad | easy to account for, especially with something like bz's timer -- be surprised if sdl doesn't have something similar |
| 23:22.12 | brlcad | (in their timer code) |
| 23:22.33 | ``Erik | the flush at the very end would be necessary anyways, just in case the last scanline didn't happen to trigger the draw |
| 23:23.14 | ``Erik | yeah, sdl does, they break things up by platform into different files instead of #if stuff |
| 23:23.20 | ``Erik | they also support more platforms :) |
| 23:23.38 | ``Erik | dunno if we care about consoles and qnx and those, though |
| 23:25.13 | brlcad | "more platforms" .. such as? |
| 23:25.24 | brlcad | ah, qnx and consoles, gotcha |
| 23:26.01 | brlcad | I'd trust bz's windows code over sdl's |
| 23:26.11 | brlcad | the nix code is a wash, pretty simple |
| 23:26.38 | ``Erik | http://hg.libsdl.org/SDL/file/f67139f6d87f/src/timer |
| 23:26.48 | ``Erik | the bz code, sdl code, my ancient crap, and everyone elses is the same |
| 23:26.49 | ``Erik | :D |
| 23:27.11 | ``Erik | gettimeofday(); do some math to pack the #. |
| 23:28.00 | ``Erik | hm, beos has system_time(void); nice |
| 23:35.54 | brlcad | er, doesn't look the same to me |
| 23:36.15 | brlcad | their GetTicks is basically bz's getEpochMicroseconds() |
| 23:37.06 | brlcad | bz's "get now time" is getCurrent() which is what does the critical logic |
| 23:38.01 | brlcad | hm, no time compensation in sdl, though they do have a nice delay func and alarm registers |
