| 01:27.36 | *** join/#brlcad b0ef (n=b0ef@062016142244.customer.alfanett.no) [NETSPLIT VICTIM] |
| 01:27.43 | *** join/#brlcad docelic (n=docelic@78.134.203.126) [NETSPLIT VICTIM] |
| 02:44.53 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1178015440.dsl.bell.ca) |
| 02:48.58 | *** join/#brlcad mike (n=mike@cadil21.kaist.ac.kr) |
| 02:49.34 | Mike111 | hi all |
| 02:50.50 | Ralith | hullo |
| 02:51.01 | Mike111 | I want to create an animation of a model. |
| 02:52.05 | Mike111 | for a smooth animation it seems better to save the images (different views) and then combine them into an animation file like a GIF |
| 02:52.23 | Mike111 | is it possible to convert .pix to .png of .gif? |
| 02:52.59 | ``Erik | yeah, pix-png |
| 02:54.05 | Mike111 | that's good. is it mentioned in the manuals? I've reat the rt, pix-fb and anim_script but don't think it was there |
| 02:54.50 | ``Erik | which manuals? the man pages? tutorials? O.o |
| 02:55.01 | Mike111 | man pages |
| 02:55.30 | Mike111 | are there separate tutorial on animation? where? |
| 02:55.33 | ``Erik | there's a pix-png man page, yes |
| 02:55.59 | ``Erik | um, there was an outdated paper sitting somewhere, clock was able to make it work, but it required a lot of change to the process |
| 02:56.56 | Mike111 | I don't think it's mentioned in the rt or pix-fb man pages |
| 02:57.46 | ``Erik | hm, those are other programs O.o |
| 02:58.16 | ``Erik | notes that perl is not mentioned in the ls manpage |
| 02:58.34 | ``Erik | :D |
| 02:59.16 | Ralith | Mike111: I bet you could script an animation render |
| 02:59.22 | Ralith | but... why? |
| 02:59.46 | Mike111 | other but related. users may be interested in converting from pix. reading these man pages gives an impression it is only processed by mged |
| 03:00.20 | Mike111 | Ralith: animating in real-time via mged may be slow. I want to rt first, save the framebuffer output and them create a smooth animaiton |
| 03:00.34 | ``Erik | (hopefully in the reasonably near future, rt will be able to output png directly... rtedge already can) |
| 03:01.31 | Ralith | Mike111: why do you want to animate directly from brlcad at all? |
| 03:02.39 | Mike111 | Ralith: I don't. I want mged to create a rt frame and then save the framebuffer image. I'll have a series of these figures, merge them into one file and have a nice GIF animation |
| 03:03.09 | Ralith | Mike111: why do you want to animate indirectly from brlcad at all? |
| 03:03.46 | Mike111 | for example: circling around a model, that is, viewing it from a different angle (0,45,90...360) |
| 03:05.30 | Ralith | yes, I know what animating is |
| 03:05.32 | Ralith | but *why*? |
| 03:05.59 | Mike111 | there is an animation page on the brl-cad wiki. I'll look there too |
| 03:06.30 | Ralith | what is the purpose of your endeavor? |
| 03:06.40 | Mike111 | Ralith: viewing the model from different directions helps someone else to understand what you are doing |
| 03:07.03 | Ralith | Mike111: okay, so why not export it to something that has a rendering system designed to do animations, and make a proper video of it? |
| 03:07.59 | Mike111 | you mean convert the .pix to .png and then combine all the .png files into a 30fps movie? |
| 03:08.03 | Ralith | no. |
| 03:08.21 | Ralith | I mean exporting the model to something that has a rendering system designed to do animations. |
| 03:09.06 | Mike111 | you mean like saving it as IGES or whatever and then loading it in a movie-editor application? |
| 03:09.29 | Ralith | I don't know of any video editors that can render from IGES geometry |
| 03:09.52 | Mike111 | can you give me a specific working example what you mean? |
| 03:10.27 | Ralith | if you can get a passable tesselation of your model, blender would make a simple animation like you describe trivial and fast. |
| 03:10.43 | Ralith | as would any other visuals-oriented modeler |
| 03:10.48 | Ralith | s/modeler/3D suite/ |
| 03:11.33 | Mike111 | what's a `passable tesselation'? |
| 03:16.28 | Ralith | one that looks mostly like your model |
| 03:21.01 | Mike111 | what is the I need to export my model in? (to read it in blender) |
| 03:22.27 | Ralith | the only format I know for sure would work is STL |
| 03:32.24 | Mike111 | what were the other alternatives to blender? |
| 03:36.43 | Ralith | whatever visually oriented 3D suite you're familiar with |
| 03:42.38 | Mike111 | haven't used any. Blender seems to be well-supported. I wonder if there are alternatives (simpler). |
| 03:45.20 | ``Erik | lightwave3d, 3dstudio max, maya, ... |
| 03:47.33 | Ralith | there's no such thing as a simple 3D suite. |
| 03:58.22 | Mike111 | looking for GPL and linux-compatible |
| 04:00.01 | Ralith | GPL? That's an awfully small scope. |
| 04:00.32 | Ralith | I'm pretty sure blender is the only remotely decent free 3D suite for any non-beer meaning of free, anyway. |
| 04:01.45 | Mike111 | http://en.wikipedia.org/wiki/Blender_(software) gives a few at the bottom of the page |
| 04:02.09 | Mike111 | have you tried K3D? |
| 04:03.58 | Ralith | like I said |
| 04:04.03 | Ralith | I'm pretty sure blender is the only remotely decent free 3D suite for any non-beer meaning of free, anyway. |
| 04:08.20 | ``Erik | "grand theft mariokart" |
| 04:08.36 | Ralith | hehe |
| 04:08.51 | ``Erik | robotchicken++ |
| 04:14.47 | brlcad | notes that getting a 'passable tessellation' of a model can be a project in itself, more complicated than a simple rt animation :) |
| 04:16.13 | Ralith | true, true. |
| 04:16.20 | Ralith | not forever though! |
| 04:16.36 | brlcad | Mike111: give the wiki tutorial a try, it's pretty trivail enough as it is to generate a series of frames for an animation |
| 04:17.21 | Ralith | heey |
| 04:17.29 | Ralith | I bet it wouldn't be hard to extend procedurals to produce a simple animation system |
| 04:17.30 | Mike111 | hi brlcad. that's what I'm doing now. imagemagick's convert doesn't work for the mpeg. |
| 04:17.35 | brlcad | note that brl-cad doesn't render animations -- there are no tools to put those frames together into a video stream, you'll need third party tool for that |
| 04:17.54 | brlcad | convert works fine if you have the video tools installed that they use :) |
| 04:17.54 | Ralith | imagemagick does images, not videos. |
| 04:18.01 | brlcad | Ralith: actually it does |
| 04:18.05 | Ralith | oh really? |
| 04:18.06 | Ralith | cool! |
| 04:18.08 | Mike111 | I'm trying to use ffmpeg |
| 04:18.31 | Ralith | still, I'd use mencoder for creating a video from stills |
| 04:19.19 | brlcad | IM doesn't do it directly, it just parcels out to ffmpeg or mencoder |
| 04:19.50 | brlcad | but does simplify frame compositing, "convert *.png myvideo.mpg" |
| 04:20.37 | Ralith | I do hope it gives you some way to specify compression and framerate at the very least. |
| 04:22.06 | brlcad | *shrug*, if you really need that -- you probably shouldn't be using IM in the first place |
| 04:22.13 | brlcad | but it's great for simple animations |
| 04:22.55 | Mike111 | for a rotating model it seems to be fine. even a GIF animation will do |
| 04:24.09 | brlcad | Mike111: feel free to add additional detail to the wiki if you have something useful to add |
| 04:24.25 | Ralith | brlcad: I think everybody needs to at the very least specify framerate. |
| 04:24.38 | Ralith | considering the use case, 30fps is *not* a reasonable default. |
| 04:24.41 | brlcad | Ralith: 'everybody'? why? |
| 04:24.55 | Ralith | well, most users. |
| 04:25.23 | brlcad | I've made dozens of perfectly acceptable videos without any care whatsoever to the framerate because it was perfectly reasonable default |
| 04:25.31 | Ralith | because a series of images has no intrinsic framerate, and I think it's pretty likely that most imagesets will not compose smooth video, but rather something slower a la hand drawn animation. |
| 04:25.44 | Ralith | I guess not in this case, then. |
| 04:27.59 | brlcad | it's like saying a user must specify a jpeg compression factor when converting images -- there's no intrinsic 'acceptible' compression but sure enough it works just fine to set an arbitrary default |
| 04:28.19 | brlcad | same holds with videos, maybe just slower or faster than expected |
| 04:28.25 | brlcad | big deal |
| 04:28.27 | Ralith | well, you have to consider the common use case |
| 04:28.39 | Ralith | jpegs, you can generally assume that it's going to be a photo or something similar. |
| 04:28.40 | brlcad | exactly |
| 04:28.56 | Ralith | because it'd be silly to use jpeg for most else. |
| 04:29.15 | brlcad | wow, that's a lot of assumptions already :) |
| 04:29.22 | Ralith | and yet it works! |
| 04:29.23 | brlcad | you know that, plenty of people don't |
| 04:30.37 | brlcad | do they need to know that? no, it's (from their perspective) an irrelevant implementation detail |
| 04:30.58 | Ralith | hm. |
| 04:31.01 | brlcad | it's not an issue of whether to provide the knob or not, it's whether they should _have_ to specify it |
| 04:31.10 | Ralith | I guess I started arguing in favor of default framerates without noticing. |
| 04:31.13 | Ralith | wups. |
| 04:32.14 | Ralith | (that explains why things got so confusing just now) |
| 04:33.26 | *** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 04:37.17 | *** join/#brlcad ``Erik (i=erik@c-76-111-12-116.hsd1.md.comcast.net) [NETSPLIT VICTIM] |
| 04:57.52 | CIA-28 | BRL-CAD: 03brlcad * r34626 10/brlcad/trunk/ (242 files in 4 dirs): |
| 04:57.52 | CIA-28 | BRL-CAD: Decouple ged return codes from bu. It was okay when it was just OK/ERROR, but |
| 04:57.52 | CIA-28 | BRL-CAD: not with the ged-specific 'MORE' concept and would have been even worse with the |
| 04:57.52 | CIA-28 | BRL-CAD: new QUIET option. Make the codes maskable for non-OK so multiple codes can be |
| 04:57.53 | CIA-28 | BRL-CAD: returned at the same time. |
| 05:28.38 | Mike111 | is it possilbe to use the `inside command on an ARS primitive? |
| 07:25.48 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 08:32.36 | *** join/#brlcad _clock_ (n=_sushi_@84-72-91-14.dclient.hispeed.ch) |
| 08:54.13 | *** join/#brlcad ``Erik (i=erik@c-76-111-12-116.hsd1.md.comcast.net) [NETSPLIT VICTIM] |
| 08:55.44 | brlcad | Mike111: nope, unimplemented for that primitive |
| 08:56.58 | brlcad | only nmg, eto, ehy, epa, rhc, rpc, part, tor, ell, tgc, and arb8's |
| 08:58.09 | brlcad | wouldn't be too terribly difficult though |
| 09:11.17 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-91-14.dclient.hispeed.ch) |
| 09:45.07 | CIA-28 | BRL-CAD: 0377.120.80.206 07http://brlcad.org * r1460 10/wiki/Main_Page: |
| 10:13.49 | *** join/#brlcad indianlarry (n=indianla@bz.bzflag.bz) |
| 10:39.18 | d-lo | Mornin all! |
| 11:32.02 | brlcad | howyd |
| 11:38.52 | CIA-28 | BRL-CAD: 03brlcad * r34627 10/brlcad/trunk/TODO: inside support for the ARS (requested by Mike111) |
| 11:52.01 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 11:58.08 | CIA-28 | BRL-CAD: 03brlcad * r34628 10/brlcad/trunk/include/ged.h: put the new GED_QUIET to use. if caller requests QUIET, then the ged_result_str should not be modified. |
| 12:02.30 | CIA-28 | BRL-CAD: 03brlcad * r34629 10/brlcad/trunk/include/ged.h: document the four command failure return codes |
| 12:29.12 | d-lo | Ralith: How do you plan on using QT? Make it a requirement to have it installed and compiled seperately or are you planning on including it in the rt^3 repo? |
| 12:36.43 | CIA-28 | BRL-CAD: 03brlcad * r34630 10/brlcad/trunk/src/libged/ (3ptarb.c adjust.c analyze.c): collapse a handful of common code patterns with the corresponding GED_ macro. on a quest to have no command directly peek into the ged structure. |
| 12:39.11 | brlcad | premature to include it as the existing codebase |
| 12:39.22 | brlcad | not enough code yet to warrant the effort |
| 12:40.00 | brlcad | wasn't enough to warrant ogre either but iirc, it required some modifications to integrate cleanly |
| 12:41.27 | d-lo | Okay, I was just curious. QT is a biggun, even if you strip it down to the bare minimum needed. |
| 12:45.00 | brlcad | yep |
| 12:45.06 | CIA-28 | BRL-CAD: 03brlcad * r34631 10/brlcad/trunk/src/libged/arb.c: diradd + put_internal pattern. |
| 12:47.40 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-117.sbndin.btas.verizon.net) |
| 12:48.40 | brlcad | general rule of thumb I've seen (for projects that don't follow always/never bundle) is to manage/include it if their codesize is not larger than yours |
| 12:50.00 | brlcad | shades of gray in-between but seems to be the cutoff in terms of sustainable maintainability (as there is a cost to managing every dep) |
| 12:50.15 | brlcad | (whether bundled or not) |
| 12:58.32 | CIA-28 | BRL-CAD: 03brlcad * r34632 10/brlcad/trunk/src/libged/ (arced.c attr.c bev.c): more GED pattern collapsing |
| 13:07.08 | CIA-28 | BRL-CAD: 03brlcad * r34633 10/brlcad/trunk/src/libged/binary.c: ged_check_exists pattern |
| 13:12.58 | CIA-28 | BRL-CAD: 03brlcad * r34634 10/brlcad/trunk/ (include/ged.h src/libged/binary.c): rename ged_binary() to ged_bo() so it matches the command name. |
| 13:13.57 | CIA-28 | BRL-CAD: 03brlcad * r34635 10/brlcad/trunk/ (6 files in 3 dirs): rename binary.c to bo.c to match the command name |
| 13:29.48 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 13:41.30 | ``Erik | hugs gtk+ |
| 13:42.07 | ``Erik | thinks zlib and libpng shouldn't be bundled anymore, make 'em deps :( |
| 13:44.27 | ``Erik | (and when do we axe jove?) |
| 13:56.46 | *** join/#brlcad samrose_ (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 14:26.34 | *** join/#brlcad docelic (n=docelic@78.134.197.15) |
| 14:53.50 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-117.sbndin.btas.verizon.net) |
| 15:52.23 | *** join/#brlcad _sushi_ (n=_sushi_@77-58-236-197.dclient.hispeed.ch) |
| 16:28.52 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-117.sbndin.btas.verizon.net) |
| 16:59.52 | ``Erik | src/mged/setup.c:71: error: 'ged_binary' undeclared here (not in a function) |
| 17:06.39 | CIA-28 | BRL-CAD: 03erikgreenwald * r34636 10/brlcad/trunk/src/mged/setup.c: ged_binary has been renamed to ged_bo. Reflect that in the cmd table. |
| 17:07.30 | brlcad | hum, musta not committed that file |
| 17:13.01 | CIA-28 | BRL-CAD: 03erikgreenwald * r34637 10/brlcad/trunk/src/libged/arb.c: GED_DB_DIRADD now takes a "struct directory" as a parameter. |
| 17:14.16 | CIA-28 | BRL-CAD: 03erikgreenwald * r34638 10/brlcad/trunk/src/libtclcad/ged_obj.c: ged_binary has been renamed to ged_bo. Reflect that in the cmd table. |
| 17:29.43 | brlcad | ahh, my setup.c was conflicted |
| 17:32.33 | ``Erik | clean build now |
| 17:32.41 | brlcad | cool |
| 17:33.20 | ``Erik | moving the new brlcad.org to a more explicit release tag, btw |
| 17:33.40 | ``Erik | no need to catch the pre-release versions |
| 17:35.23 | ``Erik | (now, I'm saying I have a clean build, I do NOT know if these functions work as advertised...) |
| 17:56.32 | Ralith | d-lo: I think it's fair to expect most *nix users to have Qt already. Windows poses a bit of an issue there, but decent documentation should sort that out. |
| 18:00.50 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) |
| 18:12.27 | ``Erik | would disagree, but *shrug* |
| 18:12.38 | ``Erik | I tend to be more in the gnome camp myself |
| 18:12.51 | d-lo | lolz @ gnomecamp. |
| 18:13.00 | ``Erik | lolz @ dave |
| 18:13.03 | ``Erik | O.o |
| 18:13.13 | ``Erik | casts magic missile |
| 18:13.16 | d-lo | i get that a lot. |
| 18:13.27 | ``Erik | at the DARKNESS! |
| 18:13.51 | d-lo | The Darkness AOE Debuffs #BRLCAD |
| 18:13.54 | d-lo | oh noes! |
| 18:14.05 | ``Erik | aoe dot, even |
| 18:14.19 | ``Erik | </nerd> |
| 18:14.44 | d-lo | heh, refrencing Damage over Time and IRC in same sentence.... |
| 18:14.47 | d-lo | nice. |
| 18:15.06 | ``Erik | yeah, redundant |
| 18:15.25 | ``Erik | wait, wait, "-1 redundant" |
| 18:15.27 | ``Erik | there we go :D |
| 18:16.13 | d-lo | Ralith: QT is a helluva compile on windows :/ |
| 18:16.23 | d-lo | time wise that is. |
| 18:16.31 | Ralith | well, there's always prebuilt binaries! |
| 18:16.35 | starseeker | d-lo: they should have an installer |
| 18:16.40 | ``Erik | qt is a hell of a compile anywhere, g++ is still a pig :( |
| 18:18.13 | d-lo | starseeker: They do, but it doesn't compile the libs :/ |
| 18:18.21 | d-lo | starseeker: Did some dry runs this weekend. |
| 18:18.37 | Ralith | d-lo: well, for practical purposes, binaries will do fine. |
| 18:19.10 | d-lo | Ralith: Good deal. Otherwise, how are things going? |
| 18:19.32 | Ralith | still bogged up with schoolness, but that will be resolved by monday. |
| 18:19.50 | Ralith | I've dig up that old Qt-in-GL demo again for reference |
| 18:19.59 | Ralith | build and runs tidily. |
| 18:20.21 | Ralith | and I have a good idea of how to get Ogre using a third-party context, so to speak. |
| 18:20.41 | Ralith | thanks to a SDL+Ogre tutorial starseeker found |
| 18:21.43 | Ralith | so implementing a proof-of-concept Qt in Ogre, and probably even slipping Qt underneath current g3d, should be straightforward enough. |
| 18:22.58 | Ralith | so, slow but very promising. |
| 18:23.37 | d-lo | outstanding! |
| 18:23.59 | d-lo | Now, lets hope that the plan and the implementation don't deviate by TOO much ;? |
| 18:24.01 | d-lo | ;? |
| 18:24.32 | Ralith | hehe |
| 18:24.34 | Ralith | let's hope. |
| 18:24.46 | ``Erik | no plan survives contact with the enemy. |
| 19:38.13 | starseeker | wonders if LLVM can build BRL-CAD yet |
| 19:38.35 | Ralith | cling would be interesting to try. |
| 19:44.40 | Ralith | er |
| 19:44.41 | Ralith | clang |
| 19:59.27 | starseeker | Ralith: cling should be the name of a de-compiler ;-) |
| 19:59.39 | Ralith | afks for a while |
| 20:02.36 | *** join/#brlcad andax (n=andax__@d213-102-40-191.cust.tele2.ch) |
| 20:06.02 | CIA-28 | BRL-CAD: 03indianlarry * r34639 10/brlcad/trunk/ (4 files in 3 dirs): initial bulk trimming work |
| 20:06.06 | ``Erik | w00t |
| 20:10.44 | *** join/#brlcad andax_ (n=andax__@d213-102-40-19.cust.tele2.ch) |
| 20:24.56 | *** join/#brlcad madant (n=madant@117.196.128.61) |
| 21:34.38 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) |
| 21:41.51 | Ralith | bulk trimming? |
| 21:45.53 | starseeker | there are stages to the trimming algorithm we are implementing |
| 21:46.15 | starseeker | the first does the "easy" cases - the second (harder) stage does the fine work and needs more logic we don't have in there yet |
| 21:47.38 | Ralith | trimming algorithm? >_> |
| 21:48.03 | starseeker | NURBS surfaces usually have trimming curves that "trim away" parts of the surface |
| 21:48.39 | starseeker | makes for more flexible geometry, but you need to be "aware" of the impact of the curves on the surface you are working with |
| 21:48.50 | Ralith | ah, nurbs work. |
| 21:49.00 | starseeker | right |
| 22:05.46 | *** join/#brlcad Elrohir (n=kvirc@p5B14E0CE.dip.t-dialin.net) |
| 22:29.58 | madant | howdy Ralith |
| 22:30.41 | Ralith | hullo |
| 22:36.59 | *** join/#brlcad Elrohir (n=kvirc@p5B14E43B.dip.t-dialin.net) |
| 22:50.15 | madant | how is qt tinkering coming along ? |
| 22:50.23 | madant | i haven't started mine yet :( |
| 23:13.01 | CIA-28 | BRL-CAD: 03brlcad * r34640 10/brlcad/trunk/src/other/openNURBS/ (Makefile.am opennurbs_curve.cpp): temporary tcl header lookup |