| 00:10.19 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/other/libtermlib/termcap.c: prevent crashes if termcap is asked to perform a tgetnum() after a tgetent() fails |
| 00:13.01 | IriX64 | it bounces, cause i'm a rubber necker |
| 00:26.57 | IriX64 | that ultrasparc do solaris64? |
| 00:28.54 | ``Erik | .... don't they all? |
| 00:29.22 | IriX64 | interesting, a sparc32 running solaris64, quick call Sun Microsystems :) |
| 00:29.36 | ``Erik | ultra is the v9, they're all 64b |
| 00:30.38 | ``Erik | they can run 32b code... but the core can do 64b... :) |
| 00:31.14 | IriX64 | you and Maloeran and you're cores, dunno how to talk to you :) |
| 00:31.58 | ``Erik | we used to say 'chip' before the multi-core chips started showing up... |
| 00:32.08 | ``Erik | and in some arenas, alu is more accurate |
| 00:32.09 | ``Erik | *shrug* |
| 00:32.23 | ``Erik | heh, nybbles |
| 00:32.25 | IriX64 | industrial its all alu or used to be. |
| 00:32.42 | IriX64 | vic forever. |
| 00:32.45 | ``Erik | alu is just part of a core, though |
| 00:32.58 | Twingy | commadores were a 70's band no? |
| 00:33.09 | ``Erik | cache and mmu's and stuff get slapped in, too |
| 00:33.21 | IriX64 | it could be argued that the core comprimises the entire system |
| 00:33.28 | IriX64 | beat me to it :) |
| 00:33.53 | ``Erik | yeah, twinky, but their mommies dressed them funny ;) |
| 00:37.02 | IriX64 | ka-click -- 128bit xfer. |
| 00:38.00 | IriX64 | how would you do parallel pipling ``Erik, or maybe we should first define pipeling. |
| 00:38.13 | IriX64 | piplining too. |
| 00:38.23 | IriX64 | bother |
| 00:38.38 | Twingy | I need like 50 pounds of play-doh |
| 00:38.51 | IriX64 | to plug something obviously. |
| 00:39.05 | IriX64 | make your own, flour and water. |
| 00:41.11 | IriX64 | ``Erik, the bird of discretion just whispered in my ear ;) |
| 00:42.44 | IriX64 | louipc my hardly *nix system rendered havoc at a new angle, visit www.spaces.live.com/Irix64 |
| 00:44.49 | ``Erik | ... |
| 00:45.00 | ``Erik | back off the wallcandy, dude |
| 00:45.15 | IriX64 | urf blacklisted? |
| 00:45.34 | IriX64 | will tend to it. |
| 00:47.54 | ``Erik | if you want to get the same angle every time, check out the 'ae' command |
| 00:49.02 | IriX64 | got it. |
| 00:50.49 | ``Erik | hm, "help" shows a list of commands |
| 00:51.14 | IriX64 | I always overlook the obvious for some reason :) |
| 00:51.26 | ``Erik | (and that's not even all of them) |
| 00:51.44 | IriX64 | he just do a ls is that right in the bin dir? |
| 00:51.50 | IriX64 | heh i mean. |
| 00:52.45 | ``Erik | a lot of the programs in bin/ have commands in the tcl interpreter in mged, but there're other commands that don't have a bin/ correlary |
| 00:53.21 | IriX64 | so moral of the story is "IriX64, just take a look in all those lovely direcories". |
| 00:53.36 | ``Erik | more like "rtfm" |
| 00:53.36 | ``Erik | :D |
| 00:56.52 | brlcad | ahhhh, finally found out why jove is now busted on os x |
| 00:58.12 | ``Erik | it's an emacs variant, it's broken by design O:-) |
| 00:59.58 | ``Erik | it's been so long since I learned vi, I don't remember if I was as dysfunctional initially as I am with emacs now... :/ |
| 01:00.28 | brlcad | it's barely a variant |
| 01:01.36 | brlcad | I had a cheat sheet sitting on my desk for about a week of non-stop coding before it became effective |
| 01:01.51 | brlcad | but then also by then, nothing else could compete |
| 01:02.03 | brlcad | and it just got better and better |
| 01:02.40 | ``Erik | <-- still learning more about vi o.O |
| 01:03.24 | louipc | read the fine manual ;) |
| 01:32.23 | ``Erik | http://www.achewood.com/index.php?date=08222002 |
| 01:32.24 | ``Erik | hehehe |
| 03:06.05 | *** join/#brlcad IriX64 (n=mario_du@bas3-sudbury98-1168054557.dsl.bell.ca) |
| 03:06.56 | IriX64 | This windows archer.... it's quite interesting. |
| 03:07.53 | IriX64 | are you planning on putting photon mapping into it? |
| 03:08.27 | brlcad | i believe the ray-tracer is already integrated, just a matter of feeding it the right options |
| 03:08.39 | brlcad | there's no gui if that's what you mean, like the lighting menu in mged |
| 03:08.52 | IriX64 | urmf, i'll learn, I just started looking at it. |
| 03:09.15 | brlcad | it's good stuff, it should be improved and integrated more with mged |
| 03:09.34 | IriX64 | agreed, some really good work here. |
| 03:11.01 | IriX64 | the ability to extract selected components and color them is neat. |
| 03:12.56 | IriX64 | s.nos1 in blue... nice. |
| 03:15.16 | IriX64 | hahah s.nos1 rt'ed beautiful job. |
| 03:32.23 | *** part/#brlcad IriX64 (n=mario_du@bas3-sudbury98-1168054557.dsl.bell.ca) |
| 03:35.23 | *** join/#brlcad bewt (n=mario_du@bas3-sudbury98-1168054557.dsl.bell.ca) |
| 03:35.57 | bewt | was worried people would think I know something about the IriX64 system. |
| 03:39.03 | ``Erik | heh |
| 03:52.53 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/ (configure.ac src/other/jove/teach-jove.in): add automatic generation of the teach-jove script during configure |
| 03:53.05 | bewt | libtool, it's gotta be libtool. :( |
| 04:14.18 | bewt | sorry i mentioned apache here but brlcad is sometimes too big :) |
| 04:14.27 | bewt | err BRL-CAD. |
| 04:16.30 | bewt | bah i quit, it wasn't libtool. |
| 04:23.31 | bewt | tried it showed me nothing, but here's something, the rev on libapr-0.la doesn't mach the libtool i'm using. |
| 04:25.53 | bewt | and their ltmain bombs. |
| 04:28.55 | *** join/#brlcad cad19 (n=59ac9221@bz.bzflag.bz) |
| 05:17.57 | Maloeran | Am I missing something or there's no efficient way to do triple or N buffering with SDL? |
| 05:45.50 | Maloeran | There's no way around the extra and wasteful copy from a frame surface to the pseudo-video surface, which in turn needs a copy to the actual video surface to be visible. Oh well, that wouldn't be a problem with X shared memory pixmaps |
| 05:52.36 | brlcad | it does it that way because you can't necessarily get access to the video surface |
| 05:52.50 | brlcad | depends on the video card and driver heavily |
| 05:53.34 | brlcad | so they do what works regardless (and apparently haven't gotten to an optimization of doing the direct blit when possible, though that has it's tradeoffs) |
| 05:54.00 | *** join/#brlcad bewt (n=mario_du@bas3-sudbury98-1168054557.dsl.bell.ca) |
| 05:55.05 | brlcad | you can do triple, N buffering, but not without getting a handle on the SDL internal for whatever platform you're on |
| 05:55.38 | brlcad | and if you're going to go that route, might as well write your own X code and forget portability |
| 05:56.59 | Maloeran | SDL could have exposed capabilities to do N buffering without too much trouble, it would always have avoided the extra copy no matter the platform |
| 05:58.55 | Maloeran | Having one software surface being copied to the video surface, or having multiple software surfaces being copied in turn, it's pretty much the same really |
| 05:59.44 | brlcad | and i'm sure you would have heard "patches welcome" |
| 05:59.51 | brlcad | sounds like a great feature, implement it ;) |
| 06:00.03 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/autogen.sh: |
| 06:00.03 | CIA-7 | BRL-CAD: hmm.. such a conundrum.. it is nice to clean up and blow away the aclocal.m4 |
| 06:00.03 | CIA-7 | BRL-CAD: that configure drops in but now that recursive configure works, tcl/tk actually |
| 06:00.03 | CIA-7 | BRL-CAD: use their own custom aclocal.m4 (instead of acinclude.m4) so deleting the file |
| 06:00.03 | CIA-7 | BRL-CAD: has undesireable impact on build prep. disable aclocal.m4 deletion for now. |
| 06:00.42 | brlcad | reality is that it's quite a bit more complicated than you give it credit for to do reliably across various cards and without undesirable impact |
| 06:01.27 | Maloeran | It's purely a software, API and logic problem really... |
| 06:01.44 | brlcad | say you were on a card that actually a) had a means to get at video memory that you could b) reliably detect via sdl/opengl facilities .. as to whether to use it |
| 06:02.22 | Maloeran | brlcad, all the surfaces can be in system memory, you just need to be able to copy from any of the directly to the video surface |
| 06:02.26 | bewt | ``Erik, private wall candy is getting better ;) |
| 06:02.28 | brlcad | then take for example you have a card that only has 16 or 32 MB of memory.. you could perhaps do in-memory buffering, but leaving little to nothing to the app |
| 06:03.00 | Maloeran | any of them* directly |
| 06:03.07 | brlcad | Maloeran: sure, they can all be in memory -- that's what they do for double buffering now iirc |
| 06:03.29 | brlcad | system memory that is |
| 06:03.39 | Maloeran | Yes, and there's absolutely no reason not to allow triple, quad or quntillion buffering if one has the system memory for it |
| 06:03.48 | bewt | brlcad, virtual memory comes to mind, but then so does disk thrashing. |
| 06:03.52 | brlcad | even better is to actually write directly to video memory if you wanted to tune for the best performance |
| 06:04.19 | Maloeran | It's better to write pixels to system memory and DMA the whole thing afterwards |
| 06:04.32 | brlcad | if that is available, sure |
| 06:04.55 | bewt | err a pixel has numerous bits. |
| 06:05.11 | bewt | you would slow it down using DMA. |
| 06:05.44 | Maloeran | Oh well, copying 150 frames of 800x600 twice per second instead of once does not sound appealing, just because of a SDL limitation |
| 06:05.55 | bewt | DVA is preferred but certainly not portable. |
| 06:06.02 | brlcad | Maloeran: if I remember back correctly, you can create your own sdl surfaces and do your own buffering too, providing your quintillion buffering |
| 06:06.41 | Maloeran | Really? Any clue on what to look for? I really didn't see anything like that |
| 06:07.28 | Maloeran | You can create surfaces, but to actually get them to show on the screen, you would have to : copy them to the SDL's "screen" surface, ask SDL to copy the "screen" surface to the actual video surface |
| 06:07.58 | brlcad | you create an sdl sw surface, and then use that with sdl_flip |
| 06:08.21 | brlcad | you can toggle between arbitrary surfaces on a flip |
| 06:08.21 | Maloeran | SDL_flip is for the one double buffered "screen" surface |
| 06:09.10 | Maloeran | SDL_Flip() takes one parameter and it's SDL's "screen" surface which may have a back buffer built-in, but that's very limited |
| 06:10.24 | brlcad | that's what I'm referring too .. this goes back a while, but the idea is to create multiple sdl_surface screens in sw mode |
| 06:11.03 | Maloeran | There's no way to render these without copying them to "screen", then asking SDL to update "screen" to video, is there? |
| 06:11.04 | brlcad | they the video mode has to be double buffered regardless, just so you can flip |
| 06:11.33 | Maloeran | Create multiple screen surfaces? Oh hum |
| 06:11.35 | brlcad | you maintain one "screen" for each of your surfaces |
| 06:11.39 | brlcad | right |
| 06:12.06 | Maloeran | I didn't read anything about that, I'll try something |
| 06:12.17 | brlcad | that's just the old sdl way to do your own buffering |
| 06:12.17 | Maloeran | If you have any example or documentation, it could be nice |
| 06:12.26 | brlcad | e.g. if you had no video memory |
| 06:12.34 | brlcad | ideally, you'd try to get as many screens with SDL_HWSURFACE first |
| 06:13.05 | brlcad | since should try to do direct mapped video memory if the card supports it |
| 06:13.24 | brlcad | but the code is a bit nasty to be fault tolerance to detect the failure and fall back to SDL_SWSURFACE |
| 06:13.33 | Maloeran | Writing pixels to hardware surfaces is a bit too slow, I'm fine with them being in software |
| 06:13.43 | brlcad | and then wierd things can happen if you have two hw and one sw, etc |
| 06:13.44 | Maloeran | I just want them to get directly in the real video surface with just one copy |
| 06:14.33 | brlcad | if you're doing your own buffering, the hw surface is going to be darn faster than doing sw -- you're just making sdl do the write to a hw surface |
| 06:16.10 | Maloeran | Yes, that's probably right... HW only works fullscreen though, usually, but I'll play around once I get the buffering working |
| 06:16.34 | Maloeran | I'm surprised there's not a word about this in the SDL docs |
| 06:16.40 | brlcad | ahh, yeah that's true.. lots of cards won't let you get a hw surface in various modes |
| 06:16.49 | brlcad | that's part of the whole robustness problem i mentioned |
| 06:20.04 | brlcad | Maloeran: it's rare for an app to actually benefit from triple buffering .. exceedingly rare even for games |
| 06:20.52 | brlcad | and many display systems are providing double-buffering of their own these days, so you get triple for free when you double-buffer your own |
| 06:21.33 | Maloeran | Indeed, but it's a different when dealing with software rendering multiple frames at the same time |
| 06:21.34 | brlcad | depends on the OS and system, of course .. not too common on linux iirc |
| 06:23.28 | Maloeran | a bit* different |
| 06:24.17 | brlcad | yep, and the variety of apps that need to render frames is a tiny "market" |
| 06:25.02 | brlcad | ray-tracers .. fractal generators .. maybe screensavers.. |
| 06:25.27 | bewt | brlcad: my on board video cheats, it uses system ram for video memory. |
| 06:25.33 | brlcad | i think what you're wanting to do used to be a lot more popular a decade or two ago |
| 06:25.47 | brlcad | when you couldn't get the hardware to double-buffer |
| 06:26.43 | brlcad | bewt: yep, pretty common to push the app to video so the mod can modify the frames on the fly |
| 06:26.58 | bewt | reserved for video 64-256m |
| 06:27.02 | Maloeran | Other APIs have good support for that kind of stuff, it was rather trivial with X and... DX3 ( okay, a long time ago :) ) |
| 06:27.35 | brlcad | yeah, it's fairly trivial in win32 and with cocoa .. |
| 06:28.49 | brlcad | another side effect of there not being many serious games on linux .. issues like this have always been a problem -- X11 being an absolute pig in most respects until very very recently |
| 06:29.56 | Maloeran | X isn't that bad with shared memory pixmaps |
| 06:30.16 | bewt | X isn't bad with opengl either. |
| 06:30.31 | brlcad | heh, compared to the other systems, X11 is one of the worst |
| 06:30.41 | bewt | define other systems. |
| 06:30.44 | brlcad | it's really been only in the past 5-10 years that it's improved |
| 06:31.06 | brlcad | closer to 5 for that matter, Xorg corrected a lot of the boneheadness of X11 |
| 06:31.09 | bewt | granted, but many systems go thru a learning/growing curve. |
| 06:31.27 | bewt | look at the roots of windows :) |
| 06:31.33 | brlcad | that doesn't hold for X11, it's older than all of the others |
| 06:31.44 | Maloeran | Ah well. That's probably right, but I was beginning high school 10 years ago and writing my first lines of code :) |
| 06:31.53 | bewt | so X is a little slow, big deal |
| 06:32.09 | brlcad | heck, even having shared memory on linux used to be problematic |
| 06:32.44 | brlcad | it's only been really recent that you could get direct opengl access through X11, and it's still somewhat flaky |
| 06:32.50 | bewt | X was at inception problematic, but then so was the Model T |
| 06:33.10 | bewt | try it on windows xp pro |
| 06:33.29 | brlcad | I dont' think it was "problematic", but it was fundamentally flawed from a performance perspective because it had a network-oriented design |
| 06:34.09 | bewt | that network design led to many Xterminal, (X in hardware at least the client side) |
| 06:34.11 | Maloeran | It's far more complex than other APIs for this reason, but it's still rather elegant, I have no problem with it |
| 06:34.15 | brlcad | when everything is a client->server->client->hw communication .. you're going to seriously suck compared to something doing app->hw |
| 06:34.33 | brlcad | it's been recent that X11 changed so that you could do client->hw more reliably |
| 06:34.42 | bewt | that should read app->os>hardware |
| 06:34.54 | brlcad | elegant? .. heh .. er .. wow |
| 06:35.06 | brlcad | comprehensive.. yes |
| 06:35.12 | brlcad | i wouldn't call it elegant in the least though |
| 06:35.13 | Maloeran | It solves a fairly complex problem |
| 06:35.26 | bewt | quite well at that |
| 06:35.27 | brlcad | it makes the problem considerably more complex than it needs tob e |
| 06:36.21 | brlcad | it does have a lot of great aspects, that can be said |
| 06:36.51 | Maloeran | Right |
| 06:36.54 | bewt | making the root window, hidden makes it faster yet |
| 06:37.15 | brlcad | but from an overall utility, and compared to the other APIs out there, it's a big reason GUI development on linux/unix/bsd has been so slow for two decades compared to the other platforms |
| 06:37.54 | Maloeran | Is there? X is extremely low-level in comparison to other "native" APIs, one generally uses toolkits built on top of it |
| 06:37.55 | brlcad | granted, a lot of the problems were actually political, and not technical |
| 06:39.24 | bewt | and not a very good one :) |
| 06:40.32 | brlcad | i'm talking about equivalent "base" api kits for managing the display -- things like core graphics or even the old toolbox on mac, the mfc/win32 foundation libraries, be's graphic server, etc |
| 06:40.35 | Maloeran | I think I just really like the low-level and flexibility aspects of X, it's really powerful. It's the assembly of GUI programming ;) |
| 06:41.04 | Maloeran | win32 remains quite a mess, but it's very limiting and high-level, it can afford to be simpler |
| 06:41.22 | brlcad | win32 goes high and low |
| 06:41.30 | brlcad | which is what makes it seem not simple |
| 06:41.52 | brlcad | there are calls for everything low level too, though |
| 06:42.12 | bewt | sadly no more inportb() |
| 06:42.16 | Maloeran | Ah yes, perhaps, I try to forget my win32 days |
| 06:42.49 | brlcad | the other two are much better examples of pretty APIs, clean low fast nice |
| 06:43.15 | brlcad | Be's was spectacular, but alas.. |
| 06:43.18 | bewt | would that they would adopt a universal API |
| 06:44.00 | brlcad | bewt: how's that compile coming with LDFLAGS=-verbose ? |
| 06:44.01 | Maloeran | BeOS and its famous is_computer_on_fire() :). I never tried any native Mac programming |
| 06:44.13 | Maloeran | In fact, I think I never used a Mac |
| 06:44.58 | brlcad | core graphics isn't too shabby |
| 06:46.29 | brlcad | cocoa is sweet, but is a higher level api akin to gtk/qt |
| 06:47.05 | Maloeran | gtk2 I liked, but I don't do much GUI |
| 06:49.53 | brlcad | it's a bit of a beast, and lives in dependency hell, but great featureset |
| 06:50.03 | brlcad | and the predominant industry momentum |
| 07:59.46 | bewt | brlcad: building rt for you now. |
| 07:59.53 | bewt | err rtlib. |
| 08:00.09 | bewt | doh librt. |
| 08:03.59 | IriX64 | http://www.pastebin.ca/374105 |
| 08:06.11 | IriX64 | btw, that wall candy is still doing its thing. |
| 08:11.41 | IriX64 | http://www.pastebin.ca/374109 |
| 08:22.18 | brlcad | librt is not the situation that was causing problems |
| 08:22.46 | brlcad | you're starting from flawed premises.. you can't just start tossing stuff in the middle like that |
| 08:23.54 | brlcad | from a *fresh* build .. the point was to add the --verbose ld flag *after* you encountered the libz and/or libpng build failure (*without* using --disable-shared) |
| 08:24.46 | brlcad | seriously.. all the rest is distracting from making any progress on identifying the first problem .. |
| 08:25.10 | brlcad | stuff failing farther down the build line is not interesting at all until the first failure is taken care of properly |
| 08:25.30 | IriX64 | whats the point of adding the flag *after the error with libpng |
| 09:07.31 | brlcad | for several reasons, to be sure that it errors (it should still error), and so that the output is just the relevant verbose linkage details and not pages of irrelevant log |
| 09:08.29 | brlcad | otherwise the signal noise ratio begins to be practically useless -- too much useless garbage that doesn't get us anywhere closer to finding out what the actual problem is |
| 09:24.04 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) [NETSPLIT VICTIM] |
| 09:29.48 | *** join/#brlcad archivist (n=archivis@host217-35-76-52.in-addr.btopenworld.com) |
| 12:15.42 | *** join/#brlcad dli (n=dli@adsl-75-33-245-220.dsl.chcgil.sbcglobal.net) |
| 12:16.13 | dli | I wonder how do I show screw thread in brlcad |
| 12:37.53 | *** join/#brlcad rossberg (n=rossberg@bz.bzflag.bz) |
| 12:42.41 | dli | how do I print out the 3d image? |
| 12:43.07 | CIA-7 | BRL-CAD: 03d_rossberg * 10brlcad/configure.ac: test for strlcpy |
| 12:46.48 | CIA-7 | BRL-CAD: 03d_rossberg * 10brlcad/src/libsysv/strlcpy.c: initial addition of strlcpy() |
| 12:48.30 | CIA-7 | BRL-CAD: 03d_rossberg * 10brlcad/include/sysv.h: |
| 12:48.30 | CIA-7 | BRL-CAD: initial addition of strlcpy() |
| 12:48.30 | CIA-7 | BRL-CAD: typo in basename declaration |
| 12:50.12 | CIA-7 | BRL-CAD: 03d_rossberg * 10brlcad/include/config_win.h: HAVE_MEMSET and HAVE_STRTOK added |
| 12:52.12 | CIA-7 | BRL-CAD: 03d_rossberg * 10brlcad/src/libsysv/basename.c: |
| 12:52.12 | CIA-7 | BRL-CAD: errno.h defines ENAMETOOLONG |
| 12:52.12 | CIA-7 | BRL-CAD: should know its own prototype |
| 12:54.39 | CIA-7 | BRL-CAD: 03d_rossberg * 10brlcad/src/libsysv/strlcpy.c: should know its own prototype |
| 12:56.28 | CIA-7 | BRL-CAD: 03d_rossberg * 10brlcad/src/libsysv/libsysv.dsp: basename.c and strlcpy.c added |
| 12:57.36 | CIA-7 | BRL-CAD: 03d_rossberg * 10brlcad/src/libsysv/Makefile.am: strlcpy.c added |
| 13:03.57 | CIA-7 | BRL-CAD: 03d_rossberg * 10brlcad/src/libbu/brlcad_path.c: include sysv.h to get the basename prototype (in case HAVE_BASENAME is not defined) |
| 13:09.05 | CIA-7 | BRL-CAD: 03johnranderson * 10brlcad/src/librtserver/rtserver.c: Added mutex protection for session open and close |
| 13:31.40 | rossberg | dli: what's a 3d image? |
| 13:31.59 | dli | rossberg, from raytracing |
| 13:32.43 | dli | rendering as postscript is ugly, and not what I see on screen |
| 13:35.05 | rossberg | i'm using the ray trace panel in mged, it has an option to write the result into a *.pix file |
| 13:35.40 | dli | rossberg, howto? |
| 13:35.53 | rossberg | there are programs to convert the pix format e.g. into png |
| 13:36.19 | dli | rossberg, how to output to .pix? |
| 13:36.51 | rossberg | menubar -> Tools -> Raytrace Control Panel |
| 13:38.06 | rossberg | there you have to change the "Destination" |
| 13:38.15 | dli | rossberg, that's the same panel as in File ->Raytrace |
| 13:38.46 | dli | rossberg, great, thanks |
| 13:49.14 | dli | rossberg, the .pix is not valid for imagemagick |
| 13:51.26 | rossberg | dli: you need to convert it e.g. with pix-png |
| 13:51.47 | rossberg | (look at man pix-png first) |
| 13:52.31 | dli | rossberg, no, the file generated is invalid, repeating 0x320000 , nothing else |
| 13:52.53 | dli | indeed, it's 0x000032 |
| 13:53.04 | Maloeran | brlcad, multiple calls to create "screen" surfaces to perform N buffering always return the same surface ; doesn't seem to be the recommended method |
| 13:56.00 | rossberg | dli: did you tried "pix-png -a yourfile.pix > yourfile.png |
| 13:56.41 | Maloeran | The #sdl crowd doesn't seem to know either |
| 13:57.01 | dli | rossberg, only garbage in the .png generated |
| 13:58.14 | dli | rossberg, hold on, it's not all 0x000032 |
| 13:59.21 | dli | <PROTECTED> |
| 13:59.22 | dli | pix-png: unable to autosize |
| 14:05.56 | rossberg | dli: ok, now try pix-png -w <width in pixel> -n <height in pixel> sample-holder.pix > sample-holder.png |
| 14:07.23 | dli | rossberg, great, it's an imagemagick bug then |
| 14:16.25 | *** join/#brlcad Elperion (n=Bariton@p54874995.dip.t-dialin.net) |
| 14:19.27 | *** join/#brlcad Bary (n=Bariton@p54874995.dip.t-dialin.net) |
| 14:20.30 | *** join/#brlcad Elperion (n=Elperion@p54874995.dip.t-dialin.net) |
| 14:25.39 | Elperion | is there a way to export the framebuffer as graphic? |
| 14:34.38 | rossberg | Elperion: (menubar)File -> Raytrace; change "Destination" to pix-file; read the pix-png manual page |
| 14:36.01 | Elperion | ok thx |
| 14:36.24 | Elperion | great |
| 14:36.27 | Elperion | i never looked there |
| 14:36.28 | Elperion | cya |
| 15:08.52 | dli | any way to move a part ( .r range)? like linear shift |
| 15:56.01 | ``Erik | int32 is_computer_on(void) Returns 1 if the computer is on. If the computer isn't on, the value returned by this function is undefined. |
| 15:56.12 | ``Erik | double is_computer_on_fire(void) Returns the temperature of the motherboard if the computer is currently on fire. If the computer isn't on fire, the function returns some other value. |
| 15:56.23 | ``Erik | interesting, those beos kids have a sense of humor :) |
| 16:40.53 | brlcad | wow, the same question twice in one morning |
| 16:44.10 | Maloeran | brlcad, confirmed by SDL folks, SDL can't do N buffering without nasty extra copies |
| 16:45.20 | brlcad | Maloeran: define "nasty extra copies" |
| 16:45.37 | Maloeran | Copy from surface N to "screen" surface, copy from "screen" surface to video memory |
| 16:46.01 | Maloeran | So there are 2 copies per frame when only one should be required with a proper API |
| 16:47.09 | Maloeran | I'm vaguely amused by how much faster non-SDL buffering to record videos is |
| 18:48.49 | brlcad | Maloeran: er .. you only get the one copy with some sort of direct memory access, mapping video memory to some address range in system memory |
| 18:49.36 | brlcad | that much was already pretty much guaranteed to not be portably possible |
| 18:49.40 | brlcad | I thought you understood that just from what we talked about earlier.. |
| 18:50.14 | brlcad | that's why they are SDL_SWSURFACEs |
| 18:51.42 | brlcad | you cannot guarantee just one copy without having the hardware capability irrsepective of the API (which maybe is what you are presuming/assuming) |
| 18:54.14 | Maloeran | brlcad, SDL can copy the content of the software "screen" surface to the actual video memory with just one copy |
| 18:54.43 | Maloeran | If I want to copy another software surface, not the software "screen" surface, I need two whole copy operations |
| 18:55.11 | Maloeran | It's an arbitrary limitation, just to keep the API simple |
| 18:56.58 | brlcad | not sure I follow what you mean by "another software surface, not the software "screen" surface" |
| 18:57.28 | brlcad | you create an sdl_surface .. you write pixels to it |
| 18:57.41 | brlcad | sdl copies those to video memory |
| 18:57.54 | Maloeran | That works for the software "screen" surface, yes |
| 18:58.04 | brlcad | right |
| 18:58.22 | Maloeran | If you want to copy another surface to video memory, you first have to copy it to the software "screen" surface, *then* you have to copy the software "screen" surface to video memory |
| 18:58.34 | Maloeran | Which is terribly wasteful |
| 18:59.15 | brlcad | you have another screen surface |
| 18:59.38 | Maloeran | You can only have one "screen" surface |
| 18:59.49 | brlcad | you have another sdl_surface |
| 19:00.29 | Maloeran | Yes, but you can not copy from it directly to video memory |
| 19:00.35 | brlcad | i'm just not following what you expect "should" be possible, other than it sounding like you wanting hardware surfaces |
| 19:00.40 | Maloeran | You can only copy from it to the "screen" surface, which must in turn be copied to video memory |
| 19:01.06 | brlcad | right, but you CAN'T do that reliably without assuming hardware capabilities |
| 19:01.10 | Maloeran | I should be able to have 10 software "surfaces", and myself copy the data from any of them directly into video memory |
| 19:01.34 | Maloeran | The only limitation is system memory, there's still only one hardware surface |
| 19:01.55 | brlcad | what you're talking about is writing to mapped video memory .. video memory mapped to system memory so you are effectively writing to video memory |
| 19:02.40 | brlcad | there are some cards that will directly reference system memory for you, but even that is not prevalent |
| 19:02.50 | Maloeran | Writing to it, DMA'ing to it ; I should be able to copy from a surface directly to the real video hardware surface ( not SDL's "screen" ) |
| 19:03.14 | brlcad | with DMA .. that's exactly what I'm saying is a hardware characteristic |
| 19:03.20 | brlcad | not something that can be taken for granted |
| 19:03.25 | Maloeran | ... Okay, I think I need to clarify |
| 19:03.51 | Maloeran | SDL already copies from the *software* single and only screen surface directly, with one copy, no matter the underlying method used |
| 19:04.26 | brlcad | sure, you provide the pixels, and it stores them *somewhere* |
| 19:04.28 | Maloeran | It should be possible to have other identical *software* surfaces which could be copied by SDL directly in the video memory, by the same mechanisms. They are all software surfaces, it doesn't even matter which one is being copied |
| 19:05.18 | brlcad | it's only "directly in the video memory" when you have video mapped memory, DMA or equivalence |
| 19:05.33 | Maloeran | I'm not ever accessing that memory directly, SDL is |
| 19:05.42 | brlcad | sure |
| 19:05.58 | Maloeran | SDL is copying from its "screen" software surface directly into the video memory, but it can't copy directly from any other surface |
| 19:06.26 | Maloeran | And that is most arbitrary, it's an API and design limitation ; it's easily done in X or DX |
| 19:07.24 | brlcad | ahh, maybe you mean it copies from what system memory buffer to another system memory buffer before sending to the video card? .. i.e. tying a particular surface to the video mapped hardware? |
| 19:08.27 | Maloeran | Yes, that's the only way to copy from one software surface to video memory, you have to go through the software "screen" surface with SDL first |
| 19:08.56 | brlcad | aah, okay.. that's not what you were initially saying |
| 19:09.04 | brlcad | at least not the way it was worded |
| 19:09.17 | brlcad | but then we only have like three nouns to work with here.. heh |
| 19:09.35 | Maloeran | It sure is what I'm trying to explain by 10 different ways since yesterday :) |
| 19:09.55 | brlcad | i can see that, though I recall there being a way to change swap "screen" surfaces |
| 19:09.57 | *** join/#brlcad cad65 (n=4788598e@bz.bzflag.bz) |
| 19:10.04 | brlcad | maybe that's no longer possible |
| 19:10.26 | brlcad | that's what I was referring to with the flip -- you actually flip to an entirely different screen |
| 19:10.40 | cad65 | i can't access freenode from my irc client today - can anyone here help me out? |
| 19:10.54 | brlcad | that may or may not be a double-buffered hardware surface, or might be a software one |
| 19:10.54 | Maloeran | The built-in SDL flipping capabilities are limited to two surfaces |
| 19:11.27 | cad65 | i'm using a web chat now |
| 19:11.31 | cad65 | here's what i'm getting - http://www.scipisc.com/view_image.php?id=181 |
| 19:11.44 | brlcad | right, that much I know.. but there at least used to be (or at least I remember there being many years ago) a way to point the second buffer to an arbitrary sdl_surface so when you do the flip, it becomes primary |
| 19:12.09 | brlcad | cad65: it's rather obvious you're using web chat ;) |
| 19:12.18 | Maloeran | Very neat, I guess it must have been dropped, most unfortuantely |
| 19:12.35 | brlcad | Maloeran: I bet you can still do it |
| 19:12.36 | cad65 | brlcad: oh |
| 19:12.37 | cad65 | lol |
| 19:12.48 | brlcad | but probably not through the public SDL api |
| 19:13.13 | brlcad | you'd probably have to set some struct values on your own |
| 19:13.14 | brlcad | because the basic operation should be doable |
| 19:13.18 | cad65 | so how do I get help on my irc client connection issue? its only to freenode |
| 19:13.19 | Maloeran | I see, does SDL have a hidden API or must I hack the source to expose its static functions? |
| 19:13.25 | Maloeran | This is messy |
| 19:13.27 | brlcad | dunno, maybe they do a lot more to manage the screen surface these days |
| 19:13.56 | cad65 | i am connected just fine to the mozilla client |
| 19:14.13 | Maloeran | Oh well, it's just annoying to seriously lose performance due to SDL when getting above 100fps |
| 19:14.16 | brlcad | Maloeran: not exactly hidden .. i mean you'd just have to read thier sources to see what they do during sdl_flip to determine what you'd need to update in the associated screen to get it to work |
| 19:14.31 | brlcad | cad65: can you ping irc.freenode.net? |
| 19:14.54 | brlcad | Maloeran: ahh.. you're complaining about 100+fps only? bahhh. :) |
| 19:14.59 | cad65 | let me check |
| 19:15.19 | cad65 | brlcad: since I can connect to different servers, shouldn't I be able to connect to freenode as well? |
| 19:15.30 | brlcad | cad65: of course not, it's a different server :P |
| 19:15.47 | cad65 | well, no problem with pinging |
| 19:15.59 | cad65 | oh...okay (irc rookie here) |
| 19:16.02 | Maloeran | Well, brlcad, I lose a 10% at around 30fps... and I lose 50% due to SDL at 200fps! |
| 19:16.14 | cad65 | so the ping was successful |
| 19:16.21 | cad65 | are there any irc moderators in here? |
| 19:16.33 | brlcad | cad65: you mean network or channel? |
| 19:16.43 | brlcad | cad65: you do realize you're in a cad channel? :) |
| 19:17.07 | brlcad | cad65: you might want to try a different port |
| 19:17.21 | cad65 | hrm |
| 19:17.24 | cad65 | interesting |
| 19:17.46 | cad65 | and a port could block one server to my irc client and not another one? |
| 19:17.56 | brlcad | sure, why not |
| 19:18.25 | brlcad | not likely, but possible |
| 19:18.58 | cad65 | darn...I can't switch rooms in this web interface |
| 19:19.17 | brlcad | yep, it's configured that way on purpose |
| 19:19.36 | brlcad | otherwise you could cause all sorts of trouble and we'd be liable for problems you cause |
| 19:20.07 | brlcad | that web interface is intended for interactive discussion about BRL-CAD |
| 19:20.29 | brlcad | how you got to it as a general means for freenode network support is beyond me |
| 19:21.01 | cad65 | lol - I just found it |
| 19:21.04 | cad65 | sorry to bother you |
| 19:21.07 | brlcad | for starters, you could try a better irc client than chatzilla |
| 19:21.28 | brlcad | something that might give you better output status |
| 19:25.31 | Maloeran | :) Nice |
| 19:30.27 | *** join/#brlcad dli (n=dli@wireless-197-79.uchicago.edu) |
| 19:30.59 | dli | which command to rescale? |
| 19:42.39 | CIA-7 | BRL-CAD: 03jlowenz * 10brlcad/include/ (vector_x86.h vector_fpu.h vector.h): Add vector class, with very initial support for simd operations. |
| 19:43.29 | CIA-7 | BRL-CAD: 03jlowenz * 10brlcad/include/brep.h: Include vector class for use by brep intersection routines |
| 19:44.49 | CIA-7 | BRL-CAD: 03jlowenz * 10brlcad/src/librt/Makefile.am: Add compilation of brep_test program |
| 19:46.08 | CIA-7 | BRL-CAD: 03jlowenz * 10brlcad/src/librt/brep_test.cpp: Add brep_test program for simple unit testing |
| 19:46.32 | Maloeran | I think I'll never understand why people make a class or a struct for a mere "vector" rather than an array, especially to use SIMD instructions |
| 19:50.37 | Maloeran | i.e. If you have 4 packed vectors of x,y,z, you could often operate on the 12 floats with just 3 instructions, try to do nicely that with 4 structs or classes |
| 19:52.21 | *** join/#brlcad Elperion (n=Elperion@p54874995.dip.t-dialin.net) |
| 20:00.00 | *** part/#brlcad Elperion (n=Elperion@p54874995.dip.t-dialin.net) |
| 20:00.04 | *** join/#brlcad Elperion (n=Elperion@p54874995.dip.t-dialin.net) |
| 20:10.07 | *** join/#brlcad clock_ (i=clock@84-72-88-134.dclient.hispeed.ch) |
| 20:18.38 | brlcad | Maloeran: primarily for type transparency and operator overloading |
| 20:20.17 | brlcad | so you're not actually tied to particular simd types, and don't need to resort to *_add() functions where a + b might provide cleaner code |
| 20:21.01 | brlcad | if you don't care about or don't leverage those two features, then yes -- they are completely unnecessary overhead |
| 20:22.05 | clock_ | leverage that is a word used often in PR :) |
| 20:22.25 | brlcad | as are lots of other words, your point? :) |
| 20:23.10 | brlcad | i mean if you made a vector class and still had a ->add() method.. that would be a bit silly, and doesn't utilize the type transparency benefit |
| 20:24.46 | Maloeran | Indeed brlcad, it just really gets in the way of optimisation, especially for SIMD |
| 20:25.07 | brlcad | not when it's done right |
| 20:25.19 | brlcad | it "should" expand out into exactly the same inline'd calls |
| 20:25.28 | brlcad | when it's implemented correctly |
| 20:25.44 | brlcad | no object/function calls, no evil vtable lookups, etc |
| 20:26.27 | Maloeran | Sure sure... I'm just saying I may want to load a x,y,z vector and the x of the following vector into one __m128 |
| 20:26.33 | brlcad | it the coder doesn't make a mistake and the compiler does it's just, you can end up with the same result, but simplified maintainable code |
| 20:28.13 | brlcad | what you suggest isn't orthogonal .. you could write a routine that was overloaded to do exactly that that expands to the same operations |
| 20:28.32 | brlcad | if you can write a macro/inline for it at least, there's a way |
| 20:28.54 | brlcad | just with a class, you can avoid the macro/function syntax for entire classes of problems |
| 20:29.34 | brlcad | that along with automatic initialization and deallocations if any are really the only reasons of value, imho |
| 20:30.18 | brlcad | and there are plenty of codes where that just doesn't matter, like if the library itself is going to act as an abstraction layer and hide the fact that it's doing sse under the hood |
| 20:30.19 | Maloeran | I recognize the general value, it just seems hardly compatible with low-level SIMD optimisation to my eyes |
| 20:30.57 | brlcad | it's not a matter of compatibility, it's just different syntax .. you end up with the same assembly for what I"m referring to |
| 20:31.51 | brlcad | for the implementations where you don't, and there's some penalty (like vtables), I'd completely agree .. that's a bad idea, a very bad idea |
| 20:32.08 | Maloeran | Of course so, but perhaps we are not seeing the same kind of low-level SIMD optimisations... |
| 20:32.28 | Maloeran | I mean, I have mixed floats and pointers in the same __m128 ;) |
| 20:33.01 | brlcad | so long as you're taking about lines of code being written, then we are talking about the same optimizations |
| 20:33.38 | brlcad | all that changes it what functions you write for your data types |
| 20:33.47 | brlcad | it expands to the same operations |
| 20:34.54 | brlcad | and those operations can be whatever you want -- packing and unpacking floats and pointers, maintaining states or not, doing whatever |
| 20:35.28 | Maloeran | Then you end up doing a class API which is identical to the SIMD intrinsics |
| 20:35.31 | brlcad | its JUST a difference in syntax/wrapping, like if you wrote all of your simd operations using a macro |
| 20:37.25 | Maloeran | Right, I agree of course, I guess the only point is to map some common instructions to overloaded operators, and expose an interface similar to intrinsics for all the rest |
| 20:37.27 | brlcad | it could be identical or not, depends on how you write it -- in general there are common patterns |
| 20:38.35 | brlcad | right, that is really the only point -- though once you have that interface, you very likely can translate it to other SIMD implementations too with no change to the code that used those classes |
| 20:40.06 | brlcad | in practice, I don't find that latter to be as much of a benefit as others claim, but some have zealotry on the encapsulation benefit |
| 20:40.29 | Maloeran | Eheh, I noticed |
| 20:40.57 | Maloeran | You could write an interface to wrap the original SIMD intrinsics just as well, anyhow |
| 20:41.57 | brlcad | yep, you can do the same thing in C |
| 20:42.21 | brlcad | only difference of wrapping in a class is operator overloading and automatic init |
| 20:43.46 | brlcad | that was the main/only point from the start -- type transparency and operator overloading .. if you don't care about that or wouldn't use those features much, then it does diminish the benefits |
| 20:44.26 | dli | can I move a part (.r)? like linear motion, or rotation |
| 20:45.16 | brlcad | I just found it odd that you'd "never understand why people make a class" .. their reasoning (whether you like or agree with it) seems perfectly understandable |
| 20:45.49 | brlcad | dli: tra and rot commands |
| 20:46.49 | brlcad | sry, orot and/or rotobj |
| 20:46.59 | Maloeran | brlcad, it does not seem reasonable to me when one needs all the low-level flexibility of SIMD intrinsics to get proper performance |
| 20:47.20 | Maloeran | SIMD intrinsics are a large interface, to makign a class with all these capabilities is a lot of code which serves little actual purpose |
| 20:47.32 | Maloeran | "so making" a class with |
| 20:47.53 | Maloeran | Just my personal view on the matter of course |
| 20:47.53 | brlcad | Maloeran: heh, you keep making the leap to the encapsulation in a class impacting performance and that's hogwash when done correctly |
| 20:48.10 | Maloeran | Of course so, but it's still a lot of code with very little purpose! |
| 20:48.12 | brlcad | it sounds like you just don't agree, and that's fine with me -- your idea |
| 20:48.13 | dli | brlcad, " sed " says object is not solid |
| 20:48.42 | brlcad | dli: sed is to edit primitives, you have to go into object edit mode |
| 20:48.54 | brlcad | oed command or matrix edit via gui |
| 20:48.54 | Maloeran | I don't really like seeing 1000 lines of code just to be a full and exact wrapper around something which would have done the job as well. Anyhow... |
| 20:49.40 | brlcad | only because it rarely is a full and exact wrapper |
| 20:49.52 | brlcad | but that's also just to wrap one interface |
| 20:49.56 | brlcad | throw in two more |
| 20:50.12 | Maloeran | Ah yes, then it serves a purpose |
| 20:50.46 | brlcad | i've seen some people prefer it just for the syntactic sugar though |
| 20:51.02 | brlcad | being able to add two things using +-/ instead of some add(), etc |
| 20:51.29 | brlcad | regardless of needing a pack_pointer_with_float() or whatever other tricks |
| 20:51.45 | brlcad | it keeps the simple simple |
| 20:51.56 | brlcad | dli: have you seen the quick reference cheat sheet? |
| 20:52.03 | brlcad | http://ftp.brlcad.org/MGED_Quick_Reference_Card.pdf |
| 20:52.22 | dli | brlcad, yes, and thr trifold one, very puzzling |
| 20:52.24 | brlcad | on the second page on the back in the first column are the commands related to editing |
| 20:53.01 | brlcad | dli: yeah, it's not meant to be instructional -- it's informative to the modelers that know most of the operations but can't remember the command name or args, etc |
| 20:54.13 | brlcad | dli: oed is likely the command that you want, and is rather tricky to understand at first with the left and right side business |
| 20:55.36 | brlcad | say you have some region named region.r and in there is a combination comb.c with two primitives prim1.s and prim2.s .. to use oed to edit the matrix over comb.c, you'd use oed /region.r comb.c/prim1.s |
| 20:56.19 | brlcad | to rotate all instances of region.r, you'd use oed / region.r/comb.c/prim1.s |
| 20:56.46 | dli | brlcad, I just want to rotate the whole region.r |
| 20:56.47 | brlcad | you have to specify all the way down to a primitive so that it's explicit as to which coordinate axis you are editing about |
| 20:57.49 | brlcad | you have to anchor the edit from a known point -- all primitives have a defined center and coordinate axis orientation |
| 20:58.25 | dli | brlcad, let me play with it a little |
| 20:59.06 | brlcad | the second example, oed / region.r/comb.c/prim1.s, sounds like what you want |
| 20:59.31 | brlcad | if you're just going to translate/rotate, then the primitive doesn't really matter, pick any path down through the region |
| 20:59.50 | brlcad | er, it matters for rotations.. but not translations |
| 21:04.16 | dli | brlcad, oed path must starts from the current showing region? this is hard for me, when the design is complex, and I want to move one part |
| 21:06.54 | *** join/#brlcad Elperion (n=Elperion@p54874995.dip.t-dialin.net) |
| 21:08.11 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
| 21:08.37 | dli | brlcad, I found the "Matrix Selector", easier now |
| 21:12.06 | brlcad | ahh, glad to hear it |
| 21:12.33 | brlcad | for what it's worth, oed has little to nothing to do with what is currently showing |
| 21:13.12 | brlcad | e object.r, oed / object.r/and/path/to/primitive.s |
| 21:13.52 | brlcad | which is what matrix selection does, though first showing you which object's are displayed, then a list of the paths to primtives |
| 21:14.26 | brlcad | so that it can build the "oed / object/path/to/prim" for you |
| 21:31.35 | *** part/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
| 21:33.12 | IriX64 | most beautifull thing, I've ever seen , took all night but it's gorgeous. |
| 21:33.56 | IriX64 | 798.70 seconds. |
| 21:34.43 | IriX64 | kudos to the BRL-CAD team. |
| 21:36.18 | IriX64 | ``Erik, I'd really like to show you what my little machine did :) |
| 21:41.05 | clock_ | brlcad: have you seen the Ronja model? |
| 21:41.36 | clock_ | http://ronja.twibright.com/3d/ronja_3.png |
| 21:41.47 | clock_ | http://ronja.twibright.com/3d/ronja_2.png |
| 21:54.17 | brlcad | clock_: ooh, that's nice! |
| 21:55.12 | *** join/#brlcad IriX64 (n=mario_du@bas3-sudbury98-1168054557.dsl.bell.ca) |
| 21:55.56 | *** join/#brlcad lg_ (n=lg_@88.234.13.222) |
| 21:56.08 | lg_ | hi |
| 21:57.17 | IriX64 | regards |
| 21:57.42 | lg_ | back to brlworld... |
| 21:57.54 | IriX64 | from? |
| 21:58.22 | lg_ | ;-) from offlineland |
| 21:59.48 | lg_ | reboot? wow, brlcad is not pure unix software anymore... |
| 22:00.10 | clock_ | brlcad: thanks |
| 22:00.13 | IriX64 | define "pure unix" |
| 22:00.15 | brlcad | lg_: he reboots for his own benefit |
| 22:00.22 | brlcad | nothing to do with brl-cad :) |
| 22:00.29 | clock_ | brlcad: of course I also have a video of rotating model |
| 22:00.35 | IriX64 | quite right sorry should have mentioned that. |
| 22:00.39 | clock_ | brlcad: but I think last time you were not able to play |
| 22:01.17 | lg_ | ;-) |
| 22:01.51 | IriX64 | lg_ I have yet to finish my cup. |
| 22:02.33 | lg_ | well, i just finished two beers, its a bit late here in turkey |
| 22:02.51 | brlcad | hehe |
| 22:02.58 | IriX64 | heh |
| 22:03.56 | IriX64 | nei eha boh? |
| 22:04.00 | lg_ | but only modeling a cup is mentioned in the manuals, so i was on my own |
| 22:04.33 | brlcad | clock_: is there a really good installation picture that showcases ronja and matches the model closely? |
| 22:04.42 | IriX64 | ha how to model a beer, lets see you start wiith hops or wheat ;) |
| 22:06.41 | lg_ | guess it is a union of both... and as there are material properties to take care of, type will be region... r beer.r u hops + wheat |
| 22:06.42 | IriX64 | haha right. |
| 22:06.44 | *** join/#brlcad rdenatale (n=rick@166-82-49-174.quickclick.ctc.net) |
| 22:09.34 | rdenatale | hello all, does this channel welcome modeling questions from newbies? |
| 22:10.03 | lg_ | ok, all newbies say helloooo... ;-) |
| 22:10.51 | rdenatale | I'm just starting to use brl-cad and I've got a bit of a conceptual block as to using transformations with nested combinations |
| 22:15.20 | clock_ | brlcad: no |
| 22:20.48 | rdenatale | Let's say that I'm modeling an instrument panel. I've got a combination for the basic panel itself which combines primitives to make the right shape... |
| 22:21.22 | rdenatale | ... Then I've got a subassembly consisting of a raised subpanel with a few identical switches. ... |
| 22:23.11 | rdenatale | ... the subassembly in this case is another combination with a primitive shape for the subpanel, and references to a combo for the switch which combines primitives and combos making up... |
| 22:23.28 | rdenatale | ... the switch handle, a nut, and a washer.... |
| 22:24.07 | rdenatale | ... Now I think that I want to build each of these subpart combos and primitives at their own origins, and then... |
| 22:24.53 | rdenatale | ... combine them at the higher level with a transformation matrix to position each subpart within the larger part... |
| 22:25.41 | rdenatale | ... but I'm not sure what's the best way to do this with mged, since it only seems to provide first-class support for positining primitive parts and not combos... |
| 22:25.47 | rdenatale | ... Am I missing something? |
| 22:34.58 | IriX64 | erf... again, think back when I first came here ;) |
| 22:35.36 | brlcad | heh "no" .. funny clock |
| 22:35.56 | brlcad | rdenatale: yes, questions always welcome.. response depends on audience and time of day ;) |
| 22:36.52 | rdenatale | thanks brlcad. |
| 22:37.25 | brlcad | rdenatale: you can do what you suggest, applying arbitrary transformation matrices anywhere in the hierarchy |
| 22:37.50 | IriX64 | btw brlcad: if I hit clear and display in the geometry editor, doesn't clear the frame buffer. |
| 22:38.39 | brlcad | to do this via the gui, you usually will display the geometry, then select Matrix Edit on the Edit menu .. select the assembly/combination/non-primitive object that you wish to apply a matrix over, then a path to a reference coordinate system |
| 22:38.51 | brlcad | IriX64: that's intentional |
| 22:38.56 | IriX64 | ty |
| 22:39.02 | brlcad | framebuffer has it's own concept of clearing |
| 22:39.26 | IriX64 | true, raytrace control panel allows for it so no biggie. |
| 22:39.26 | brlcad | though it wouldn't be an unreasonable feature request to combine them in the geometry editor |
| 22:39.38 | IriX64 | your choice. |
| 22:39.47 | brlcad | actually it's yours ;) |
| 22:39.53 | IriX64 | :) |
| 22:40.49 | brlcad | if it's something you'd like to see added, or for any feature request really .. it helps to make the request at http://sourceforge.net/tracker/?func=add&group_id=105292&atid=640805 |
| 22:40.57 | brlcad | else it get forgotten between releases |
| 22:41.17 | IriX64 | ty i'll visit and add to favorites. |
| 22:41.31 | rdenatale | brlcad: I don't see Matrix Edit on the edit menu (I'm using 7.8.3). I only see matrix selection and that only lets me select primitives. |
| 22:41.32 | brlcad | rdenatale: the command line way to do what you suggest is the oed command, which has tricky semantics to get used to at first, but will eventually make sense ;) |
| 22:43.05 | brlcad | rdenatale: sorry .. my impreciseness |
| 22:43.08 | rdenatale | brlcad: yeah I saw oedit, but I can't figure out what path_lhs and path_rhs are |
| 22:43.37 | brlcad | it is Matrix Selection -- the first primitive selection dialog is your anchor coordinate axis (which mostly only matters for rotations) |
| 22:43.59 | brlcad | select any one of those that include your combination/region |
| 22:44.27 | brlcad | you'll then get another dialog where you can select where to place the matrix along that path |
| 22:45.32 | brlcad | rdenatale: say you have a 'panel' assembly that has a 'button.r' and 'switch.r', each containing a 'cyl.s' primitive |
| 22:45.55 | brlcad | say you want to translate the switch.r .. |
| 22:46.42 | brlcad | you'd "e panel" or "e switch.r" or use the geometry browser and select one of those two .. say for simplicity you "e panel" |
| 22:48.03 | rdenatale | brlcad: do I need these to be regions? The problem is that my end product is going to be an stl file (for stereolithograpy) ... |
| 22:48.08 | brlcad | to apply the transformation via the gui, you select the matrix selection menu option, then select any one of the lines that has switch.r in it .. the primitive only matters as a coordinate axis reference point .. so say you select /panel/switch.r/cyl.c |
| 22:48.32 | rdenatale | ... and as I understand the conversion to stl, it makes each region into a separate part. |
| 22:49.03 | brlcad | rdenatale: ideally, yes -- at some point in the modeling process, regions/parts should be created, and groups/assemblies should be built up from those regions |
| 22:49.16 | brlcad | if you define no regions, there will be one created for you |
| 22:50.06 | brlcad | which for something like the converter, would mean the whole object just ends up as one object .. and stl files can only have one object per file anyways ;) |
| 22:51.26 | brlcad | to complete the example, after selecting /panel/switch.r/cyl.c .. you'd then select switch.r to apply a transformation to the switch.r being used in panel |
| 22:51.44 | brlcad | that corresponds to the oed command of: oed /panel switch.r/cyl.c |
| 22:52.26 | brlcad | if you wanted to just translate some object .. you'd do something like "e switch.r" and "oed / switch.r/cyl.s |
| 22:53.01 | rdenatale | brlcad: so does path_rhs have to start with either a region or a primitive part? ... |
| 22:53.45 | brlcad | it starts with the name of the thing you want to translate .. some combination/region/assembly/part/group object |
| 22:54.07 | brlcad | but it must include the path all the way down to some primitive so it has a coordinate axis to work with |
| 22:54.32 | rdenatale | I've got a tree like panel.c/switch.c/... and if I enter oed panel.c switch.c it says something like "Error: unable to find matching solid part" |
| 22:54.47 | brlcad | that is understandably confusing.. long been a consideration to make more transparent, but there are legacy support issues for the expert modelers |
| 22:55.34 | brlcad | right, that's an error.. it will be something like oed /panel.c switch.c/some/path/to/a/primitive |
| 22:56.27 | rdenatale | brlcad: okay, do I understand this right if I do oed panel.c switch.c/someprimitive_in_switch.c it will still work on the matrix which transforms switch.c relative to panel.c ??? |
| 22:57.57 | brlcad | if I understand you right myself, yes ;) |
| 22:58.06 | brlcad | that will only transform the switch.c being used in panel.c |
| 22:58.54 | brlcad | if you wanted to move all switch.c's, you'd oed / switch.c/someprimitive_in_switch.s (.c suffix is for csg combinations, .s is for solids aka primitives) |
| 22:59.19 | brlcad | the slash on the LHS is of course significant |
| 22:59.43 | rdenatale | brlcad: indicating the root I guess |
| 22:59.50 | dli | brlcad, can I just move one .c instead of all parts? |
| 23:01.04 | brlcad | dli: yes, you can do that by either creating a named reference to the .c (which amounts to creating a group that includes just that .c along with a matrix transform) or you apply the matrix directly in the assembly where it's being used |
| 23:01.56 | dli | brlcad, thanks |
| 23:02.50 | rdenatale | brlcad: so I think I understand but I'm still having trouble. I have to go fairly deep into that switch to get to a primitive... |
| 23:05.19 | rdenatale | The shallowest primitive is in switch.c/switch_nut_and_washer.c/washer.s ... |
| 23:08.57 | rdenatale | brlcad: thanks, I think you got me started. As I said I've got another problem now, but my wife is pressing me to prepare dinner, so I'll likely come back later. |
| 23:08.59 | brlcad | rdenatale: sort of, yes indicating a root .. if you think of all paths sort of like filesystem paths where to modify a *directory* in your root (e.g. etc), you have to specify a file contained therein (e.g. /etc/passwd) .. and to |
| 23:09.21 | brlcad | if your paths are long, it might be easier to use the gui for selection |
| 23:09.27 | brlcad | good luck with dinner :) |
| 23:10.39 | brlcad | dli: oh, third option is to copy that .c since all copies are shallow when using cp |
| 23:11.59 | dli | brlcad, thanks |
| 23:13.31 | Maloeran | Hum, dinner. That reminds me I haven't eaten a thing today yet |
| 23:14.08 | brlcad | (looking for capable developers) |
| 23:14.10 | dli | brlcad, no :( I am just a n00b user |
| 23:14.23 | brlcad | hey, nothing wrong with that ;) |
| 23:14.34 | dli | brlcad, I use qcad for 2d, and brlcad for 3d |
| 23:14.44 | brlcad | sweet |
| 23:15.30 | brlcad | feel free to shovel in the feedback or make requests on the sf.net trackers .. they do get paid attention to |
| 23:19.42 | *** part/#brlcad lg_ (n=lg_@88.234.13.222) |
