| 00:00.23 | brlcad | unless you just happen to be using an osl shader that returns random reflections |
| 00:00.50 | brlcad | otherwise, it sounds like something they's just default to .. but isn't actually necessary -- should be able to converge much faster |
| 00:01.16 | brlcad | otherwise it sounds like it basically acting like a generalized path tracer |
| 00:01.28 | brlcad | otherwise ;) |
| 00:01.42 | kunigami_ | I think it's a path tracer |
| 00:01.53 | brlcad | it is and it isn't ;) |
| 00:02.02 | brlcad | isn't supposed to be a generalized shader system |
| 00:02.22 | brlcad | meaning you could use it as a path tracer or not |
| 00:02.42 | kunigami_ | hmm makes sense |
| 00:02.42 | brlcad | perhaps it just defaults to path tracing |
| 00:02.55 | ``Erik | accidental negative? it IS supposed to be generalized, no? so'z it can be path trace, radiosity, phong, etc |
| 00:03.26 | brlcad | "isn't it supposed to be" |
| 00:04.06 | brlcad | or s/isn't/it's/ :) |
| 00:04.06 | ``Erik | ah, s/t/ t it/;s/$/?/ |
| 00:04.34 | kunigami_ | the thing is that I based my code in a example and maybe there it was implementing a path tracer |
| 00:05.00 | kunigami_ | I wasn't aware that this could be just a "mode" |
| 00:05.07 | ``Erik | kunigami: sounds so, is there a basic phong OSL script you can slap in there? that'd be a lot quicker on the tests and be a pretty close relative to the current 'default' of rt |
| 00:05.13 | brlcad | so then we (you) have some homework to figure out ;) |
| 00:06.04 | ``Erik | would think pixdiffs of the current C phong/plastic vs the OSL phong would be interesting |
| 00:06.23 | brlcad | for starters, making sure you're working with rt from here forward, not a standalone so we make sure the integration migrations towards something production usable, even if it's the path tracer |
| 00:06.40 | brlcad | I don't think OSL ships phong by default |
| 00:07.22 | ``Erik | any guess on how difficult it'd be to write? I'd hope trivial... |
| 00:08.01 | brlcad | hm, mildly related discussion: http://groups.google.com/group/osl-dev/browse_thread/thread/3350532577b3f8b7/657b1956e545b5ba?lnk=raot |
| 00:08.30 | kunigami_ | I think there's a implementation of a phong shader, but if I remember well, it wasn't much different from the diffuse |
| 00:08.39 | kunigami_ | let me try here |
| 00:09.52 | brlcad | hates it when he searches for some topic like this and the top hits are our own irc log discussions |
| 00:10.35 | brlcad | so phong() is an OSL function |
| 00:10.45 | brlcad | along with cooktorrance() |
| 00:10.52 | brlcad | and a few others |
| 00:11.23 | ``Erik | ok, so we do have the theoretical opportunity for a 1:1 comparison of our own shader system vs osl |
| 00:11.57 | brlcad | still unclear how you drive the phong reflectance/specular rays |
| 00:13.10 | ``Erik | if push comes to shove, we SHOULD be able to re-implement our interpretation in osl, I'd hope? |
| 00:13.30 | brlcad | it's not that |
| 00:13.39 | brlcad | librt is still the one shooting rays and managing geometry |
| 00:13.55 | brlcad | so librt fires, hits an osl surface, calls into osl to figure out what to do |
| 00:14.01 | ``Erik | *shrug* either way, hasta luego, see ya'll tomorrie :) |
| 00:14.15 | brlcad | then it needs to fire more rays .. how it does that isn't clear to me |
| 00:15.41 | brlcad | this should be like a "chapter 1" or intro-to-osl detail spelled out somewhere |
| 00:18.28 | brlcad | aha, language spec talks about it somem |
| 00:19.04 | brlcad | "Effects that would ordinarily require explicit ray tracing, such as reflection and refraction, are simply part of the radiance closure and look like any other BSDF |
| 00:21.07 | brlcad | mm, getting the gist |
| 00:21.11 | brlcad | kunigami_: so I'll have to read through this some more tonight, but I think the first step is to not gang off the -H option since that fires multiple primary rays ... |
| 00:23.21 | brlcad | very expensive |
| 00:23.28 | brlcad | do something trivial like getenv(LIBRT_OSL_SAMPLES) instead of a command line option and use that parameter to toggle how many internal osl samples it needs to acquire per ray |
| 00:24.27 | brlcad | should shave massive amounts of time since it doesn't need to rewalk the spatial partitioning, and still give the same resulting picture |
| 00:25.17 | kunigami_ | ah I was just asking that. ok, so going back to my first implemented hypersampling |
| 00:25.34 | brlcad | we can tie it to command-line options later if it all gets working cleanly |
| 00:25.52 | brlcad | it *shouldn't* need to re-call rt_shootray() |
| 00:26.08 | brlcad | the ray hit is the same for 1 sample as it was for 1 million |
| 00:56.40 | CIA-62 | BRL-CAD: 03kunigami * r45549 10/brlcad/trunk/src/liboptical/sh_osl.cpp: |
| 00:56.40 | CIA-62 | BRL-CAD: added back hypersampling right on sh_osl instead of using the -H parameter. It's |
| 00:56.40 | CIA-62 | BRL-CAD: much less expensive since we dont need to re-calculate the hit point which, in |
| 00:56.40 | CIA-62 | BRL-CAD: the end, will be the same for all samples. It reads the number of samples from |
| 00:56.40 | CIA-62 | BRL-CAD: an environment variable, which is better than having a hardcoded value |
| 01:31.05 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.132.140) |
| 01:37.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 01:42.45 | brlcad | kunigami_: there are several items in your nsamples loop there that do not change across loop iterations -- should pull them out so they're only computed once |
| 02:01.29 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.152.125) |
| 02:06.32 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 02:11.35 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.148.37) |
| 03:03.39 | *** join/#brlcad Stattrav (~Stattrav@117.192.149.58) |
| 03:03.39 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 03:07.41 | CIA-62 | BRL-CAD: 03bhinesley * r45550 10/brlcad/trunk/src/libged/edit.c: |
| 03:07.41 | CIA-62 | BRL-CAD: Cut down on a lot of duplication. Fixed a few issues with subcmd arg helper |
| 03:07.41 | CIA-62 | BRL-CAD: functions (and most are enabled/used now). ged_edit() generic subcommand |
| 03:07.41 | CIA-62 | BRL-CAD: argument parsing is nearly done. Still a WIP. Some option combinations are |
| 03:07.41 | CIA-62 | BRL-CAD: accepted that shouldn't be. It is crashing right now, too. That is to be |
| 03:07.42 | CIA-62 | BRL-CAD: expected, as it needs edit_str_to_arg() to work properly, and that is |
| 03:07.43 | CIA-62 | BRL-CAD: incomplete/needs some modifications. |
| 03:18.01 | *** join/#brlcad Stattrav (~Stattrav@117.192.132.193) |
| 03:18.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 03:34.20 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.157.12) |
| 03:55.43 | *** join/#brlcad Stattrav (~Stattrav@117.202.18.126) |
| 03:55.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 04:00.42 | *** join/#brlcad Stattrav_ (~Stattrav@117.202.16.214) |
| 04:05.44 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 04:25.44 | *** join/#brlcad Stattrav_ (~Stattrav@117.202.23.44) |
| 04:37.55 | *** join/#brlcad Stattrav (~Stattrav@117.202.24.28) |
| 04:37.55 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 04:55.29 | *** join/#brlcad Stattrav (~Stattrav@117.192.156.5) |
| 04:55.29 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 05:00.28 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.146.128) |
| 05:05.26 | *** join/#brlcad Stattrav (~Stattrav@117.202.28.81) |
| 05:05.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 05:16.45 | *** join/#brlcad Stattrav_ (~Stattrav@117.202.22.242) |
| 05:24.24 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded a new version of "[[Image:Industry Diagram.pdf]]": Fifth revision of the BRL-CAD Industry Diagram. |
| 05:27.32 | *** join/#brlcad Stattrav (~Stattrav@117.192.159.51) |
| 05:27.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 05:29.15 | brlcad | starseeker: care to try another attempt at converting the diagram to an open format? :) |
| 05:30.05 | brlcad | been a few years, better fonts, hopefully better rendering |
| 05:31.10 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) |
| 05:31.18 | yukonbob | hello, #brlcad :) |
| 05:33.12 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.154.48) |
| 05:43.41 | brlcad | howdy |
| 05:52.57 | yukonbob | hai |
| 05:53.22 | yukonbob | how're things? |
| 06:47.55 | *** join/#brlcad Stattrav (~Stattrav@117.192.128.91) |
| 06:47.55 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 07:00.39 | *** join/#brlcad merzo (~merzo@193.254.217.44) |
| 07:28.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 08:11.31 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 10:23.10 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 10:51.49 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) |
| 10:51.49 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 12:33.04 | *** join/#brlcad SCD101 (~sam@109.77.120.154) |
| 12:33.19 | SCD101 | Hey there :) |
| 12:37.35 | SCD101 | Many people enquired about the ESA SoC? |
| 12:48.06 | CIA-62 | BRL-CAD: 03kunigami * r45551 10/brlcad/trunk/src/liboptical/sh_osl.cpp: moving constant parts out of the loop |
| 12:56.40 | brlcad | SCD101: I think we're up to approximately 482 |
| 12:57.06 | SCD101 | 482 for just your projects? Wow |
| 12:58.04 | brlcad | SCD101: heh, if you believe that, I have a bridge to sell you |
| 12:58.36 | SCD101 | Well considering there are 20 places in total over all of the organisations :P |
| 12:58.47 | SCD101 | How many really? :L |
| 12:59.10 | SCD101 | Also, how big is the bridge? |
| 12:59.15 | SCD101 | :P |
| 12:59.16 | brlcad | it's a wonderful bridge, connecting reality with Mr. Roger's Neighborhood |
| 12:59.32 | brlcad | just a couple |
| 13:00.24 | brlcad | 20 orgs, but the program isn't exceptionally well known, only affects EU students, and is for students with an interest in a niche domain (space) |
| 13:00.30 | SCD101 | Ah cool. I only know C and am doing GSoC atm. Would I need experience with BRL-CAD or is it only needed for some of the projects? |
| 13:18.02 | brlcad | shouldn't matter for most projects, you's learn what you need as you go |
| 13:18.50 | brlcad | you don't need experience with BRL-CAD, but you should be able to read and comprehend existing source code quickly so anything you work on is properly integrated |
| 13:19.26 | brlcad | none of the projects are stand alone, work-off-in-a-corner tasks |
| 13:19.54 | brlcad | they're all intended to be fully integrated so that when you're done, you've improved BRL-CAD in some fashion |
| 13:33.21 | SCD101 | brlcad, I'm currently working on dpkg for Debian. So I've gotten some good experience with large codebases. However I do hope our codebase has more comments than dpkg :P |
| 13:36.12 | brlcad | at more than 1M lines, you'll find some parts are extensively commented, beautiful lush examples, along with entire continents of code without comments |
| 13:36.34 | brlcad | so it depends where you're working, but there are plenty of devs to help you along |
| 13:36.58 | SCD101 | Ok that's good :) |
| 13:37.21 | SCD101 | And all of the projects are open for submission? I only ask because there can only be one can't there? :P |
| 13:38.46 | brlcad | not sure what you mean |
| 13:39.02 | brlcad | you propose the project |
| 13:39.05 | brlcad | we just suggest ideas |
| 13:39.37 | SCD101 | Nvm got confused :L |
| 13:41.04 | SCD101 | I'm liking the look of this bending light idea :P |
| 13:41.39 | SCD101 | AH you use svn |
| 13:47.51 | SCD101 | Ok I really like the code layout. Looks nice to work with |
| 15:55.38 | *** join/#brlcad SCD101 (~sam@109.77.120.154) |
| 16:04.49 | brlcad | if you have any questions, this is usually the place (or the mailing list) |
| 17:00.04 | kunigami_ | it seems osl shaders have functions named eval_reflect and eval_transmit which must be fed with the view direction and the lighting direction and they return the color |
| 17:05.50 | kunigami_ | hmm so we need to consider the contribution of each light source and get a color? |
| 17:07.21 | kunigami_ | then, if there's reflection/refraction to be done, we compute the directions? |
| 17:45.11 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) |
| 18:15.10 | *** join/#brlcad merzo (~merzo@142-55-132-95.pool.ukrtel.net) |
| 18:30.17 | CIA-62 | BRL-CAD: 03bhinesley * r45552 10/brlcad/trunk/src/libged/edit.c: oops; db_free_full_path() doesn't free bu_malloc'd space for the db_full_path struct itself, so it must be done manually. |
| 18:39.26 | CIA-62 | BRL-CAD: 03bob1961 * r45553 10/brlcad/trunk/src/tclscripts/mged/openw.tcl: This fixes the failed browser launch on windows. |
| 18:56.40 | CIA-62 | BRL-CAD: 03brlcad * r45554 10/brlcad/trunk/NEWS: bob fixed a bug in mged where the browser wasn't getting set properly so the browser wouldn't launch. needed to set mged_browser var but was only setting (web_browser) |
| 19:05.57 | brlcad | kunigami_: so my reading through the osl intro last night, it does change a few notions I had of their system |
| 19:06.40 | brlcad | they are geared towards solving global illumination, which doesn't necessarily mean path tracing, but it does mean that they're not set up for traditional phong-style ray tracing |
| 19:07.33 | kunigami_ | does global illumination imples multiple samples? |
| 19:07.37 | brlcad | actually, their docs seemed a little self-contradicting saying they didn't implement phong-style semantics for a shader but then continue to list a phong function as a possible shader evaluation routine |
| 19:07.37 | kunigami_ | implies* |
| 19:07.51 | brlcad | yes and no |
| 19:08.06 | brlcad | osl evaluates closures |
| 19:08.27 | brlcad | so you can think of every pixel as representing a complex polynomial equation |
| 19:08.57 | brlcad | if solves the equation as far as it can parametrically, then uses the starting view/ray information to solve the remainder |
| 19:09.08 | brlcad | so in theory, they precompute a lot more than you would otherwise |
| 19:10.28 | brlcad | e.g., if you had a lot of reflective shiny surfaces, bright lights but then had a "black-hole sphere" in that scene, then the closure for the pixels of the sphere reduce to .. nothing, black, and there is no need to sample, reshoot, etc |
| 19:10.51 | brlcad | it's not just "absorbed", it figured out that the equation reduced |
| 19:13.16 | kunigami_ | I made two renders using their phong function. one using exponent = 0 and the other exponent = 1. |
| 19:13.18 | brlcad | so not calling -Hbig_number and having any OSL-samples happen internally was a better direction |
| 19:15.13 | kunigami_ | exp = 0 http://dl.dropbox.com/u/1399996/GSoC/green-phong-e0.png |
| 19:15.24 | kunigami_ | exp = 1 http://dl.dropbox.com/u/1399996/GSoC/green-phong-e1.png |
| 19:17.27 | brlcad | mm, too noisy to tell what is going on there |
| 19:20.23 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) |
| 19:20.30 | *** part/#brlcad kunigami_ (~kunigami@201.53.206.27) |
| 19:20.34 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) |
| 19:26.14 | brlcad | kunigami_: did you see a performance difference between shooting with -H and since you refactored out the common code from the loop you readded? |
| 19:27.03 | kunigami_ | didn't measured. Let me do some tests |
| 19:27.27 | brlcad | would have expected it to be noticeable |
| 19:32.47 | kunigami_ | I was wondering if it's desirable to have another incremental mode view for such shaders. At each sample the framebuffer is updated so the image begins noisy and converges to a noise-free one |
| 20:20.08 | CIA-62 | BRL-CAD: 03erikgreenwald * r45555 10/brlcad/trunk/ (include/bu.h src/libbu/simd.c): add support for SSE3, SSE4_1 and SSE4_2. Add a bu_simd_supported function. Minor cleanup and clobberage fixes |
| 20:25.19 | CIA-62 | BRL-CAD: 03r_weiss * r45556 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: (log message trimmed) |
| 20:25.19 | CIA-62 | BRL-CAD: Updated function nmg_class_pt_s within file nmg_class.c. This change supports |
| 20:25.19 | CIA-62 | BRL-CAD: the prototype version of the nmg_triangulate_fu function. Within function |
| 20:25.19 | CIA-62 | BRL-CAD: nmg_class_pt_s it uses the raytracer to classify if a point is in, out or on a |
| 20:25.19 | CIA-62 | BRL-CAD: shell. During the computations of determining this, line intersection functions |
| 20:25.20 | CIA-62 | BRL-CAD: are used where some require finite line segments. To help resolve some of the |
| 20:25.21 | CIA-62 | BRL-CAD: computation problems I added a magnitude to the ray direction vector instead of |
| 20:52.34 | *** join/#brlcad tharis20 (~tharis@bl21-44-216.dsl.telepac.pt) |
| 21:21.23 | tharis20 | hi, I'm Francisco from Portugal and I'm applying to SOCIS |
| 21:21.56 | tharis20 | I don't know what else I should mention, for now I'm just reading and following the checklist |
| 21:23.32 | kunigami_ | brlcad: running with -H 100 and 1 sample per pixel, took 910s. with -H 1 and 100 samples per pixel, took 713s. |
| 21:29.51 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r3020 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ added reports for week 9 |
| 21:31.33 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r3021 10/wiki/User:Kunigami/GSoc2011/Reports: /* Week 9 (July 18th to July 25) */ added more info to week 9 |
| 21:50.20 | brlcad | tharis20: welcome and thanks! |
| 21:50.26 | brlcad | kunigami_: iiiinteresting |
| 21:50.49 | brlcad | I would have expected more of an increase frankly, but maybe osl is just dominating more than I thought |
| 21:51.32 | tharis20 | brlcad: to run archer do I need to compile brlcad with opengl? |
| 21:52.18 | brlcad | kunigami_: so now is oslr->QueryColor() deterministic? does it return the same color every time for a given info? |
| 21:52.25 | brlcad | tharis20: yep |
| 21:52.36 | brlcad | otherwise, you can use 'mged' |
| 21:52.54 | tharis20 | I know, but I wanted to run archer to see the differences |
| 21:53.11 | kunigami_ | brlcad: no, I still don't know how to use eval_reflect / transmit correcly. |
| 21:53.43 | tharis20 | OpenGL is supposed to be shipped with OSX, but I'm getting an error compiling brlcad with it... I'll see if I can fix it, otherwise, I'll ask someone for help |
| 21:54.16 | brlcad | tharis20: it is shipped with osx -- how are you compiling? |
| 21:54.30 | brlcad | tharis20: give the cmake build a try, you'll need to install cmake |
| 21:55.19 | tharis20 | I have cmake installed, but I was using autotools |
| 21:55.27 | tharis20 | I'll give it a shot then |
| 21:56.27 | brlcad | otherwise, you can paste an error snippet and usually someone will respond within a while |
| 21:56.40 | tharis20 | sure ;) thank you |
| 22:13.26 | *** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 22:14.06 | *** join/#brlcad SCD101 (~sam@109.77.120.154) |
| 22:14.07 | tharis20 | ... |
| 22:52.22 | tharis20 | woot 37 minutes, 8 seconds |
| 22:57.59 | ``Erik | for the compile? single core slower machine? o.O nfs over 14.4k modem? :D |
| 22:59.27 | bhinesley | waits about that long for a clean build on a Core 2 6600 @ 2.4Ghz |
| 23:00.34 | *** join/#brlcad SCD101 (~sam@109.77.120.154) |
| 23:13.13 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 23:13.20 | abhi2011 | hi |
| 23:15.09 | abhi2011 | I am trying to write a basic plugin for BRLCAD |
| 23:15.30 | abhi2011 | Is there any tutorial similar to http://brlcad.org/wiki/Developing_applications for plugins ? |
| 23:17.10 | tharis20 | ``Erik: yes, for the compile |
| 23:30.08 | CIA-62 | BRL-CAD: 03r_weiss * r45557 10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: (log message trimmed) |
| 23:30.08 | CIA-62 | BRL-CAD: Updated functions vertex_neighborhood, get_pole_dist_to_face, |
| 23:30.08 | CIA-62 | BRL-CAD: guess_class_from_hitlist_min, guess_class_from_hitlist_max, |
| 23:30.08 | CIA-62 | BRL-CAD: isect_ray_snurb_face, record_face_hit, edge_hit_ray_state, ray_hit_vertex, |
| 23:30.08 | CIA-62 | BRL-CAD: nmg_class_ray_vs_shell within file nmg_rt_isect.c. Many changes are to support |
| 23:30.09 | CIA-62 | BRL-CAD: the prototype version of nmg_triangulate_fu. The changes associated with this |
| 23:30.10 | CIA-62 | BRL-CAD: prototype are disabled by default. The prototype related changes create a |
| 23:37.15 | kunigami_ | To evaluate the contribution of light sources, I'll have to find the light directions for every query point and also if this light is visible or not. For now, I'll just use BRL-CAD lights because this information is already computed |
| 23:58.28 | kunigami_ | Seems there's a bug on sh_toon shader. Currently it is : cosi = VDOT(swp->sw_hit.hit_normal, swp->sw_tolight); |
| 23:58.30 | CIA-62 | BRL-CAD: 03r_weiss * r45558 10/brlcad/trunk/src/libbn/plane.c: |
| 23:58.30 | CIA-62 | BRL-CAD: Updated the protoype function bn_isect_line3_line3_new within file plane.c which |
| 23:58.30 | CIA-62 | BRL-CAD: supports the prototype function nmg_triangulate_fu. These changed are disabled |
| 23:58.30 | CIA-62 | BRL-CAD: by default. Performed code cleanup and improved some of the logic. More cleanup |
| 23:58.30 | CIA-62 | BRL-CAD: is needed. This is a work in progress. |
| 23:59.41 | kunigami_ | but since we're iterating on lights, I think it should be: cosi = VDOT(swp->sw_hit.hit_normal, &sh_swp->sw_tolight + 3*i); |
