| 00:07.29 | Twingy | I added the voxel stuff :} |
| 00:07.55 | ``Erik | heh |
| 00:08.22 | Twingy | but I'm sure Lee will tell you he added it :) |
| 00:09.48 | ``Erik | hahha |
| 00:10.47 | Twingy | forizzle |
| 00:11.14 | ``Erik | he doesn't seem to appreciate it when you call him on that shit in public forum... but he seems to swallow it and move on. |
| 00:11.17 | ``Erik | O:-) |
| 00:11.31 | Twingy | ask me if I care :) |
| 00:11.45 | ``Erik | I already know your answer, bitch |
| 00:11.59 | Twingy | good, homofaggatus |
| 00:12.09 | ``Erik | *I* intend to keep calling him on it, if people care to join, groovy |
| 00:12.51 | ``Erik | credit given where credit is due, I support the concept of a meritocracy, and I'm willing to make some people look like dumbasses to support it. :D |
| 00:13.00 | ``Erik | if only I did anything worth merit *sigh* |
| 00:13.32 | Twingy | I've mentioned your name on contributing to those cluster build system stuff every muves meeting for the last month |
| 00:13.46 | ``Erik | thnx |
| 00:13.46 | Twingy | "Erik Greenwald did this... Thanks to Erik we have this. Erik just got blah working, etc." |
| 00:14.09 | Twingy | lee hasn't brought your name up once iirc |
| 00:14.11 | ``Erik | I'm sure other parties are attempting to claim that I am 100% commited to muves |
| 00:14.20 | ``Erik | if I'm not there, he won't |
| 00:14.23 | ``Erik | it's not his nature |
| 00:15.16 | ``Erik | I vagually recall some meeting a few months ago where he said he did something and I corrected him, noting that you did it, and he had to agree, but he seemed... uncomfortable. :) |
| 00:15.44 | ``Erik | I have a suspicion I'm gonna piss him off a lot over the next few months. |
| 00:16.18 | Twingy | I suspect everyone who's no passive and agreeable with him annoys him |
| 00:16.26 | ``Erik | I don't mind correcting people in public O:-) dixie got a smackdown infront of the division, tyvm |
| 00:17.57 | ``Erik | but lee is generally open to correction and he generally wants to do 'the right thing', even if he wants to claim credit, so that makes him less odious than ... some other individuals. |
| 00:18.27 | Twingy | he doesn't learn very quick then :) |
| 00:18.35 | ``Erik | speaking of "some other individuals", are you going to try to have a discussion to push that toughbook? |
| 00:18.47 | Twingy | nope, not important |
| 00:19.12 | ``Erik | hehehe, I think he's gotten away with enough that he has a bit of a god complex going, it'll take a good series of rapid smackdown to make an impression :) |
| 00:19.24 | Twingy | go for it :) |
| 00:19.53 | ``Erik | I think your toughbook request IS important... not because of the piece of hardware, but because of the policy and the blind adherence to it |
| 00:20.11 | Twingy | for somone that cares, sure |
| 00:20.17 | ``Erik | you got the letter, bitch, go nail it to the church door. |
| 00:20.18 | ``Erik | :D |
| 00:20.30 | Twingy | I stopped caring :) |
| 00:20.36 | ``Erik | bah |
| 00:20.53 | Twingy | I am collecting a pay check |
| 00:21.13 | Twingy | I can buy toys to get real work done on the weekend |
| 00:21.34 | ``Erik | well, true, I'm there on that, but if I were getting a hw order cockblocked because of general idiocity, I'd feel at least some responsibility to raise a nasty stink on it |
| 00:22.18 | ``Erik | where oh where is that hot 25yo redhead nurse... |
| 00:23.13 | ``Erik | if you want, tell me what else is on the order with that toughbook, and I'll swing by and raise a stink for you... heh |
| 00:27.17 | Twingy | not important |
| 01:16.14 | *** join/#brlcad iday (n=iday@c-68-55-177-228.hsd1.md.comcast.net) |
| 02:07.01 | *** join/#brlcad animall (n=jwmcc@adsl-068-209-088-106.sip.gsp.bellsouth.net) |
| 03:00.09 | *** join/#brlcad ibot_ (i=ibot@rikers.org) |
| 03:00.09 | *** topic/#brlcad is http://brlcad.org/ || BRL-CAD is now Free Software! || Release 7.8.0 is Posted! |
| 06:15.01 | Maloeran | Ah Justin :), so you need voxel support somewhere? I just wouldn't have expected that |
| 10:21.05 | *** join/#brlcad dpy (n=marcel@k17242.upc-k.chello.nl) |
| 10:21.12 | dpy | hi |
| 10:21.15 | dpy | anyone around ? |
| 10:39.24 | dpy | does anyone here know how to get this effect in opengl: http://www.cadcamnet.com/Online/03/nov/04nov-sw1hsSE_15.jpg |
| 10:41.16 | archivist | I would draw that in solidworks or solid edge |
| 11:56.19 | dpy | yes |
| 11:56.26 | dpy | but I want to render it in opengl |
| 11:56.39 | dpy | the whole point is... I save the model as xgl |
| 11:56.46 | dpy | then import it in my program |
| 11:57.03 | dpy | but then I want to render it again as solid edge does |
| 12:49.56 | pra5ad | hah |
| 12:50.05 | pra5ad | gooch shader from the orange book |
| 12:50.13 | pra5ad | cept the cool color is red |
| 12:50.18 | pra5ad | nothing special there |
| 13:31.51 | dpy | pra5ad: where I can download example code that does this ? |
| 13:34.55 | dpy | do you know ? |
| 14:07.58 | Maloeran | What is troublesome specifically? Rendering the outlines? |
| 14:10.40 | Maloeran | You could render the contours as a GL_LINE_LOOP, with a little tweak on glDepthRange or glPolygonOffset to prevent Z fighting issues while still getting mostly accurate Z buffering ( so you don't see lines rendered for culled surfaces ) |
| 14:25.07 | *** join/#brlcad animall (n=jwmcc@adsl-068-209-088-106.sip.gsp.bellsouth.net) |
| 14:27.39 | *** join/#brlcad digitalfredy (n=digitalf@200.119.94.25) |
| 14:53.40 | dpy | Okay, I'm now manually trying to detect edges |
| 14:54.06 | dpy | and I will create a 3d outline model for this |
| 14:54.27 | dpy | but what I was afraid off is happening, I can't seem to find faces belonging to edges |
| 14:54.58 | dpy | http://rafb.net/paste/results/0efP5u82.html |
| 14:59.54 | Maloeran | Mmm, ruby. The "external" outline is simply defined as separating triangles facing towards or away from the eye |
| 15:01.11 | dpy | no I need all edges |
| 15:01.19 | dpy | not just the "outline" of the object |
| 15:01.56 | dpy | e.g. when you look straight down at: /\ |
| 15:02.13 | dpy | neither will be facing away from the eye, but there still is an edge |
| 15:02.32 | Maloeran | Right, I'm just mentionning that this outline is different and dynamic as the eye moves. For the rest... I suppose I would group triangles by connectivity and similar normals up to a breaking point |
| 15:03.10 | dpy | so what I'm doing right now is, I calculate all face normals, then flag all edges with 2 face normals that are angled > than some threshold |
| 15:03.13 | Maloeran | A good robust solution is going to be much more complex than what you have there |
| 15:03.53 | dpy | can't I just combine both ? |
| 15:04.33 | dpy | combine the view direction dependend outline (the one you suggest above) with the detected edges |
| 15:04.33 | Maloeran | It depends what you want. Do you want any contour to pop up if you have a sphere for example? |
| 15:04.50 | dpy | depends on the threshold |
| 15:04.56 | Maloeran | Of course, I'm just saying that the "external" outline is to be computed at run-time, the surface contours can be precalculated |
| 15:05.14 | dpy | anyway |
| 15:05.28 | dpy | currently I can't even find two faces belonging to the same edge |
| 15:05.29 | dpy | grrr |
| 15:05.57 | Maloeran | You'll need to build yourself some table for this, first of all |
| 15:07.26 | dpy | I'm doign so, didn't you see the pastebin ? |
| 15:07.50 | Maloeran | Only briefly |
| 15:07.51 | dpy | I take the sum of the two vertices belonging to the edge as a key into a hashtable |
| 15:08.03 | dpy | because summation is commutative |
| 15:09.02 | Maloeran | That doesn't sound right. 1+5 = 2+4, you want to find another triangle that has the same vertex indices but in the opposite order |
| 15:10.02 | Maloeran | The "external" outline calculation is a common need for stencil shadows, if you want to get some reading material on the first part |
| 15:10.41 | dpy | stencilling is extremely slow on my ATI 7500 |
| 15:16.57 | Maloeran | I'm just saying the connectivity and silhouette determination problems are the same, if you are looking for some guide on that part |
| 15:17.24 | Maloeran | After that, you can worry about precalculating surface contours |
| 15:19.50 | dpy | oh okay, so you are suggesting I'm going the wrong way around ? |
| 15:20.57 | Maloeran | First of all, you certainly need to gather connectivity information, and what you presently have won't work :) |
| 15:24.39 | dpy | you mean, I need a better way to turn two vertices into a key |
| 15:26.27 | Maloeran | Correct. If you got the pair 2,4 for example, you need to find the pair 4,2 to get the connected triangle and not just some pair with a sum of 6 |
| 15:26.53 | dpy | Maloeran: it depends |
| 15:27.04 | dpy | if they are floats you will not have that many collisions |
| 15:27.20 | dpy | but I already started a new class: MatchKey |
| 15:27.21 | Maloeran | Floats? We are talking about vertex indices, right? |
| 15:27.52 | dpy | yes, now we are |
| 15:28.41 | Maloeran | Right, the same indices that would be used by glDrawElements() for rendering |
| 15:29.49 | dpy | http://rafb.net/paste/results/sthQy870.html |
| 15:31.26 | Maloeran | Generally, indices will be in the reverse order. You can still build a single key for fast lookup by the way |
| 15:31.47 | Maloeran | Such as A*IndiceCount+B where A or B is always the lowest indice of the two |
| 15:59.20 | Maloeran | Any better success? |
| 16:03.07 | *** join/#brlcad iday (n=iday@c-68-55-177-228.hsd1.md.comcast.net) |
| 16:07.25 | *** part/#brlcad digitalfredy (n=digitalf@200.119.94.25) |
| 16:08.40 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 16:08.41 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net |
| 16:19.30 | dpy | Maloeran: no, I don't get any matches |
| 16:53.46 | dpy | I got ittttttttttttttt |
| 16:53.48 | dpy | !!!!!!!!!!!!!!!! |
| 16:54.27 | dpy | you gotta see this (step 1) |
| 16:55.53 | dpy | http://www.dwarfhouse.org/mtoele/edge_image.png |
| 16:58.07 | *** join/#brlcad pier (n=pier@151.56.236.140) |
| 17:01.52 | Maloeran | Nice dpy :) |
| 17:02.22 | dpy | if I adjust the threshold, it also puts strokes on curvatures |
| 17:02.52 | Maloeran | Are you just looking for sharp edges, or building surfaces up to a certain treshold for the whole surface? |
| 17:03.13 | dpy | no I need two more things: 1: the outline using your pointers, 2: combine this with the shaded model and avoid Z buffer errors |
| 17:03.48 | Maloeran | Ah, right |
| 17:03.49 | dpy | Maloeran: ultimately I want that yes, but for now I'll settle with edges only |
| 17:04.34 | dpy | but I know what you mean, a sloped surface that stays under the threshold all the time should also have a stroke somewhere I think |
| 17:04.57 | dpy | but now it's food time |
| 17:05.02 | Maloeran | Yes, it does in the curvy door picture you pasted a while ago |
| 17:05.36 | dpy | up to now, it was pretty much doable |
| 17:05.48 | dpy | and I wasted again too much time looking for source code to spoonfeed me |
| 19:25.23 | *** join/#brlcad Erroneous (n=DTRemena@c-24-23-59-104.hsd1.ca.comcast.net) |
| 19:53.40 | brlcad | /db/ goto -50 |
| 19:56.28 | brlcad | dpy: if you have brl-cad geometry, there is an edge raytracer for that sort of shaded edge rendering |
| 19:56.51 | brlcad | an example is in the screenshots section even iirc.. ah yes: http://sourceforge.net/project/screenshots.php?group_id=105292&ssid=4470 |
| 20:09.08 | Maloeran | Raytracing edges, curious |
| 20:12.09 | brlcad | yep, pretty nifty |
| 20:12.11 | brlcad | http://brlcad.org/images/havoc_rtedge.png |
| 20:13.31 | brlcad | utilizes identification of unique regions, local neighbor information, and curvature to determine whether the current pixel is an edge or not |
| 20:14.01 | Maloeran | I was just typing a long question, which included how I was guessing it was done :) |
| 20:14.30 | Maloeran | So it precalculates edges for specific groups and determine if the ray lies on an edge during raytracing |
| 20:14.43 | Maloeran | within the border thickness anyhow |
| 20:14.49 | brlcad | not really |
| 20:15.03 | Maloeran | Okay, so I didn't get it |
| 20:15.35 | brlcad | it uses the hit point details of the neighbors, they come back during the raytrace as reporting that you hit a given region/object |
| 20:15.52 | Maloeran | Ah I see |
| 20:15.59 | brlcad | if you go from one object to another object on two neighboring pixels, there's an edge there |
| 20:16.28 | brlcad | or if the distance along the ray is significantly different, you've got an edge |
| 20:16.39 | Maloeran | Simple enough |
| 20:16.45 | brlcad | or if the curvature between two neighboring pixels is significantly different, you've got an edge |
| 20:16.59 | brlcad | yeah, not really a complex idea, works pretty well |
| 20:17.04 | Maloeran | *nods* Thanks |
| 20:17.33 | Maloeran | Completely unrelated, I don't suppose Lee hangs around here? |
| 20:18.00 | brlcad | he shows up once or twice a month sometimes, never hangs around for very long |
| 20:18.37 | Maloeran | Okay. I was wondering a couple things about the SOW for raytracing software but it can wait |
| 20:19.02 | brlcad | wouldn't be a good idea to discuss that here regardless |
| 20:20.21 | brlcad | this channel and/or irc in general is not really appropriate for topics that concern ARL business directly |
| 20:20.50 | brlcad | s/business/business, people, places, tasks, etc/ |
| 20:21.03 | brlcad | grr, ibot_ |
| 20:21.14 | Maloeran | :) Understood |
| 20:23.34 | brlcad | woot, fixed |
| 20:23.43 | brlcad | s/fixed/should be fixed/ |
| 20:23.46 | brlcad | excellent |
| 20:25.13 | pier | hi everybody |
| 20:25.19 | animall | greetings |
| 20:25.47 | pier | I got last 7.8.0 version on my pc |
| 20:26.29 | pier | but there must be something wrong with former ones that don't want to work any more |
| 20:26.48 | pier | I get thi error |
| 20:27.02 | pier | /usr/brlcad_7.6.4/stable/bin/mged: symbol lookup error: /usr/brlcad_7.6.4/stable/bin/mged: undefined symbol: bu_argv0 |
| 20:27.03 | dpy | brlcad: looks cool, although for now I'm satisfied with my own results |
| 20:27.26 | dpy | also, I'm too stupid to work effectively with brlcad, I use solid edge for making parts and assemblies |
| 20:30.38 | brlcad | howdy pier |
| 20:31.20 | brlcad | dpy: understood, just thought you might like to know that it was there just in case ;) |
| 20:31.57 | brlcad | pier: odd error.. do you have LD_LIBRARY_PATH or BRLCAD_ROOT set? |
| 20:32.47 | pier | mmm |
| 20:32.56 | pier | let's see |
| 20:33.12 | pier | I noticed I got this error too |
| 20:33.25 | brlcad | and why is it running /usr/brlcad_7.6.4 if you have 7.8.0 installed? |
| 20:34.01 | pier | difficult question :) |
| 20:34.41 | Maloeran | A mismatch of versions between binaries and libraries may have such interesting results |
| 20:34.44 | pier | when I rename brlcad dir to i.e. brlcad_7.8.0 |
| 20:34.53 | brlcad | eep, don't do that |
| 20:35.11 | brlcad | a renamed install directory is considered a relocation |
| 20:35.15 | pier | I wanted to preserve all the old versions |
| 20:35.24 | brlcad | brl-cad has compiled-in data-search paths |
| 20:35.32 | pier | ok |
| 20:35.48 | brlcad | you can override them at run-time with BRLCAD_ROOT, but you shouldn't relocate if you don't have to |
| 20:35.55 | brlcad | did you compile yourself, or downloaded binary? |
| 20:35.56 | pier | ok |
| 20:36.16 | pier | I happened to download binary |
| 20:36.18 | brlcad | you should NOT have BRLCAD_ROOT (or LD_LIB..) set if you did not relocate |
| 20:36.47 | brlcad | depending on the platform, for newer versions at least, they will all happily coexist in /usr/brlcad |
| 20:37.07 | brlcad | there should be a /usr/brlcad/stable symbolic link that points to the last installed |
| 20:37.28 | brlcad | with each new version installed as /usr/brlcad/rel-7.8.0 for example |
| 20:38.02 | brlcad | so you only add /usr/brlcad/bin to your path to always use the latest mged for example, or run /usr/brlcad/rel-7.6.4/bin/mged to get that specific version |
| 20:38.26 | pier | ok thanks very much |
| 20:38.53 | brlcad | i don't think the mergeable installs were done fro 7.6.4 though.. don't remember |
| 20:38.59 | brlcad | maybe |
| 20:39.22 | brlcad | have to see what's in /usr/brlcad_7.6.4 (which I presume WAS /usr/brlcad and you renamed it?) |
| 20:39.52 | pier | yes |
| 20:40.02 | brlcad | if there's no symbolic link, then you can leave it as /usr/brlcad_7.6.4 and set BRLCAD_ROOT to that when you want to use it |
| 20:40.49 | pier | can't I just cd to /usr/brlcad_7.6.4/bin and run mged? |
| 20:41.13 | pier | no as a matter of fact |
| 20:41.18 | brlcad | nope |
| 20:41.29 | brlcad | mged needs to locate several resources in order to start up |
| 20:41.48 | pier | yes |
| 20:41.50 | brlcad | it has no idea how to search for them since you effectively "moved" it |
| 20:42.01 | brlcad | it'll dump out with a gui or other tcl error |
| 20:42.15 | brlcad | setting BRLCAD_ROOT will make it work |
| 20:42.22 | brlcad | and/or BRLCAD_DATA |
| 20:42.31 | brlcad | albeit to a different path |
| 20:42.41 | pier | ok |
| 20:43.03 | pier | at least now I know how to deal with it |
| 20:48.37 | brlcad | there is actually code written that will let mged 'discover' that it was relocated and utilize a relative search ordering priority to try to find if it's resources were also relocated |
| 20:48.52 | brlcad | the code is just not activated.. needs to be tested more before being made active |
| 20:49.37 | brlcad | hardly any program that loads resources dynamically find them automatically, involved a nice hack based on where the binary lives on the filesystem |
| 20:52.26 | pier | ok but with a link it works fine |
| 20:54.21 | pier | I'll move to 7.8.0 and hopefully finish my new router (got a bit busy with an exam lately) |
| 20:55.56 | pier | do you think that compiling from the source the code would be better optimized? I mean is it worthwhile compiling now that I see that new version works? |
| 20:58.31 | brlcad | shouldn't gain you a whole lot really |
| 20:58.35 | brlcad | but you certainly could |
| 20:59.04 | brlcad | you could add your own platform-specific optimizations to squeeze another 10% or so performance out |
| 20:59.35 | brlcad | default distributed binaries are high optimization, but not platform-limited |
| 21:03.23 | pier | is there a way to get mget pointing to a project dir at startup? |
| 21:06.31 | dpy | http://www.dwarfhouse.org/mtoele/c_bracketed_servo.png |
| 21:09.07 | brlcad | pier: what do you mean? |
| 21:09.46 | pier | the startup windows alwais point to the actual dir |
| 21:09.47 | brlcad | pier: mged will process a .mgedrc in your home dir on startup, you can add just about any tcl scripting in there |
| 21:09.54 | pier | azz |
| 21:09.58 | pier | sorry |
| 21:10.28 | brlcad | dpy: nifty, though wierd tolerancing issues |
| 21:10.43 | dpy | what ? |
| 21:10.48 | dpy | you mean the Z buffer fighting? |
| 21:11.20 | dpy | self.scale = 1.008; #TODO: more robust way of doing this |
| 21:11.32 | dpy | I have to find a good way of doing this |
| 21:11.43 | dpy | I haven't been able to find the "offset" documentation yet |
| 21:16.29 | brlcad | yep |
| 21:19.18 | pier | buona notte atutti! |
| 21:19.33 | brlcad | heh :) |
| 21:19.57 | *** part/#brlcad pier (n=pier@151.56.236.140) |
| 21:27.47 | dpy | notte ? isn't it noche or something ? |
| 21:29.22 | brlcad | ~translate en it good night to you |
| 21:29.37 | brlcad | ~translate en es good night to you |
| 21:30.08 | brlcad | tutti is just the familiar tense |
| 21:31.18 | dpy | ah ok |
| 21:31.44 | dpy | no he said: good night to all |
| 21:31.46 | dpy | a tutti |
| 21:32.19 | dpy | one day I'll learn to speak italian |
| 21:32.27 | dpy | it just has to wait until I have more time :) |
| 21:33.15 | brlcad | ~translate it en a tutti |
| 21:34.02 | dpy | ~translate it en tutti fruti |
| 21:34.03 | brlcad | hmm |
| 21:34.10 | dpy | ~translate it en tutti frutti |
| 21:35.09 | dpy | ~translate it en prego parlare inglese |
| 21:35.19 | dpy | lol |
| 21:35.22 | dpy | that's wrong |
| 21:35.36 | dpy | "please speak english" |
| 21:35.46 | dpy | ~translate en it please speak english |
| 21:36.44 | brlcad | literally, i believe it was right |
| 21:37.02 | brlcad | please is most translations is a form of begging/praying |
| 21:37.13 | brlcad | prego is first person |
| 21:37.34 | brlcad | in that order at least, not imperative |
| 21:37.54 | brlcad | funny either way ;) |
| 21:39.41 | dpy | yes |
| 21:39.52 | dpy | but that's where computers always go wrong |
| 21:39.57 | dpy | the interpretation |
| 21:40.10 | dpy | computers can't interprete |
| 21:40.42 | dpy | I've researched it a bit now I understand what information means, and data and that it is not the same |
| 21:40.49 | dpy | computers transform data, not information |
| 21:40.56 | ``Erik | impregnate what? huh? |
| 21:41.05 | dpy | lol |
| 21:41.06 | dpy | preggo |
| 21:52.28 | Maloeran | ~translate s'il vous plaît |
| 21:52.42 | Maloeran | So it doesn't do french or it doesn't like me :) |
| 21:52.45 | pra5ad | si non oscillas, noli tintinnares |
| 21:55.33 | pra5ad | blame hugh hefner |
| 21:58.12 | brlcad | Maloeran: you have to tell it the languages to and from |
| 21:58.20 | brlcad | ~translate fr en s'il vous pla?t |
| 21:58.44 | brlcad | pasting that char didn't go so well here |
| 22:00.27 | Maloeran | ~translate fr en s'il vous plaît |
| 22:00.45 | Maloeran | Not much better. Anyhow, it's the closest french translation for "please" |
| 22:00.51 | brlcad | ~translate en fr please |
| 22:01.00 | brlcad | heh |
| 22:01.14 | brlcad | cheater |
| 22:01.58 | Maloeran | Ahah |
| 22:16.40 | dpy | ~translate fr en s'il vous plait |
| 22:17.22 | dpy | I guess it doesn't like circonflex or the encoding is off |
| 22:38.32 | brlcad | i believe it just passes it on to babelfish, so whatever babelfish wants though there is undoubtedly a few encoding conversions possible along the way |
| 23:25.49 | *** join/#brlcad PrezKennedy (n=Apathy@c-68-33-243-45.hsd1.md.comcast.net) |
| 23:44.36 | *** join/#brlcad DTRemenak|RDP (n=DTRemena@c-24-23-59-104.hsd1.ca.comcast.net) |
