| 00:19.26 | *** join/#brlcad infobot (ibot@rikers.org) | |
| 00:19.26 | *** topic/#brlcad is BRL-CAD and open source CAx discussion ! Also @ http://brlcad.zulipchat.com ! Logs @ http://infobot.rikers.org/%23brlcad/ | |
| 01:25.03 | brlcad | starseeker: fyi, nirt debug doesn't work in the new version -- you have it setting a var but it's never used. old code accesses a global. |
| 01:25.30 | brlcad | I got what I needed from --old, but thought you might like to know |
| 01:30.08 | *** join/#brlcad oawzvyyaexfqqgup (~armin@dslb-088-066-159-125.088.066.pools.vodafone-ip.de) | |
| 03:28.48 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 03:48.15 | DenisP_ | brlcad: Before starting to write a gsoc proposal I'd like to discuss the implementation of material system. |
| 03:48.29 | DenisP_ | We are using Appleseed's materials, right (and not translating BRL-CAD's materials to Appleseed's ones)? So I will have to write a small comand-line routine for materials/lightsources/e.t.c. and rewrite writing/reading routines of databases (.g files)? Is that it? |
| 03:52.25 | brlcad | we're certainly using their materials, but the material definitions need to come from BRL-CAD geometry |
| 03:53.53 | brlcad | now there's lots of ways to go about that from where things are at now, but translating is probably the best starting point |
| 03:55.03 | brlcad | at a most basic level, it just means scanning geometry during prep to instantiate appleseed materials before shooting rays |
| 03:59.22 | brlcad | currently materials are expressed as an rgb color and/or a simple keyword string (e.g., "light" and "plastic") followed by parameters (like how transparent/reflective/etc) |
| 04:05.03 | brlcad | now using that and making appleseed materials is pretty straightforward (e.g., most will probably simply default to the disney material, akin to our 'plastic') -- the complication later will be figuring out a good way to persist new shader settings in the .g file because we'll need to find a way that works across multiple different renderers (e.g., appleseed, ospray, optical, and osl) |
| 04:08.00 | brlcad | the TODO file has some thoughts on this -- namely having a new entity type, material objects, stored in the .g file that objects could refer to by name instead of the built-in optical shader keywords |
| 04:09.41 | brlcad | DenisP_: for gsoc, the first main goal will be to get awesome renderings of .g files without user intervention, so you'll want to use as much existing information as possible and treat the .g files as read-only (for starters) |
| 04:14.26 | brlcad | starseeker: I think I've figured out what's going on with the grazing cylinder. the ray isn't grazing the cylinder, it's grazing the bounding box and getting different behavior due to an inf inverse vector (which I still have to track down) |
| 04:18.42 | brlcad | starseeker: unexpectedly, c90 mode is restoring behavior from 7.20 days so we'll have to figure out what the right behavior should be .. at my first glance, I would have said that the new c90 mode is right and the 7.26.* behavior is "wrong" except that spatial partitioning shouldn't eliminate hits |
| 04:25.49 | DenisP_ | Okay, then I start with parsing brl-cad's materials and choosing somewhat similar by appearence BRDFs. And then expand it with some keywords/parameters for choosing different BRDFs? |
| 04:26.06 | DenisP_ | For example, let's say we have plastic material. In BRL-CAD it's rendered with Phong BRDF. When I parse .g file, I read the keyword, read diffuse/specular terms, color, then create in Appleseed, let's say Disney BRDF with our parameters(somehow tweaked). Okay, we will have a working renderer at this point. Next, should I add let's say a plastic material that's rendered with CookTorrance or any other BRDF? Should I cover all the stuf |
| 04:32.15 | brlcad | DenisP_: we need to talk it over but I don't think you need to cover everything -- just the most commonly used ones (light, plastic, mirror, glass) just so there's some sensible defaults and a way to expand mappings later if we want to support others (e.g., checker, texture, bump, flat, camo, etc) |
| 04:32.54 | brlcad | frankly, pulling color and lights is probably the most important aspect |
| 04:34.20 | brlcad | if it just did that or even just color, but then had sensible general default lighting (e.g., rt has lights behind the view frame and an ambient light by default) |
| 04:40.55 | brlcad | it doesn't have to be or behave the same, but conceptually I suggest a 3-stage effort where you work on making a command-line renderer like rt that goes through appleseed (maybe call it "art"), then sort through how to present and integrate it via GUI (we should talk about this more later), then how to persist and make appearance customizations (appleseed and/or other shader definitions) |
| 04:45.45 | DenisP_ | hmm, what does that mean exactly? |
| 04:45.46 | DenisP_ | >how to present and integrate it via GUI |
| 04:46.58 | DenisP_ | present what? some rendering parameters? |
| 06:13.21 | brlcad | DenisP_: it's TBD (or TBP) but basically some GUI integration of appleseed rendering and rendering options, ideally interactively and adaptively ala appleseed studio but more focused on CAD requirements and new GUI than exactly all the controls one might want for production rendering purposes |
| 06:19.00 | DenisP_ | Okay I got it, thanks. |
| 06:19.18 | DenisP_ | I will post here a proposal as soon as I finish it. |
| 06:39.36 | *** join/#brlcad merzo (~merzo@43-15-132-95.pool.ukrtel.net) | |
| 07:33.41 | brlcad | looking forward to reading it! |
| 07:33.51 | brlcad | (and seeing a patch) |
| 07:35.09 | Stragus | Cool stuff :), physically based rendering of .g it is |
| 07:35.35 | Stragus | Ray tracing would have quite the advantage over rasterization for sub-surface scattering, but that's probably not a concern for typical .g models |
| 09:18.35 | *** join/#brlcad KimK (~KimK@2001:579:d00c:800:4a5b:39ff:fe0b:57d2) | |
| 10:18.13 | starseeker | brlcad: I vaguely remember tightening up the bboxes for some of the primitives a long while back - perhaps the tgc bbox is too tight under certain conditions? |
| 10:20.07 | *** join/#brlcad KimK (~KimK@2001:579:d00c:800:4a5b:39ff:fe0b:57d2) | |
| 10:20.09 | Stragus | Ideally, the bounding box border would have to be proportional to its distance from the origin (okay) or the ray origin (darn it) |
| 10:24.58 | starseeker | it's been a long time since those changes, and I don't remember the motivation other than the generic "bboxes should be as tight as possible to skip as many ray tests as possible" |
| 10:25.32 | starseeker | but it may be that (especially for axis aligned situations) I overdid it |
| 10:26.40 | Stragus | Right. I'm just saying that the loss of mantissa bits depends how far your ray origin from the box is, so it's a bit... annoying by design |
| 10:26.49 | starseeker | nods |
| 10:27.06 | starseeker | the safe thing is of course increase by the maximum possible necessary delta |
| 10:27.36 | starseeker | which may very well be why the original bbox logic was in place that I "improved"... wouldn't be the first time I did something like that |
| 10:27.57 | Stragus | While documenting the maximum magnitude of a ray origin ensuring robustness |
| 10:28.16 | Stragus | Kind of hard to trace rays from a source at 0,FLT_MAX,0 |
| 10:28.21 | starseeker | (autotools -> CMake could be characterized as a long continous series of toe stubbings in that regard...) |
| 10:29.18 | starseeker | Stragus: that's a point, actually... I'm not sure if we call out the limits of a valid ray origin explicitly |
| 10:29.48 | Stragus | If you can set limits, then you can precisely compute the border you need for your bounding boxes |
| 10:31.47 | starseeker | nods |
| 10:33.12 | Stragus | Besides the big_number_a - big_number_b accuracy, also assume a loss of 0.5 mantissa bits per FLOP while computing bbox-ray intersection, and you are good to go |
| 10:48.51 | ``Erik | that's a bummer, Hawking passed http://www.bbc.com/news/uk-43396008 |
| 10:48.52 | gcibot | [ Stephen Hawking: Visionary physicist dies aged 76 - BBC News ] |
| 10:53.44 | Stragus | Ah crap :( |
| 10:54.52 | Stragus | Erik, we haven't chatted in forever squared, but I'll probably travel to Maryland later in March if you want to meet and chat |
| 10:57.56 | ``Erik | Stragus: definitely, lemme know when you have the dates |
| 10:58.26 | Stragus | Sure, cool |
| 11:28.00 | *** join/#brlcad merzo (~merzo@185.39.197.205) | |
| 13:00.52 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 13:32.36 | *** join/#brlcad merzo (~merzo@185.39.197.205) | |
| 13:46.12 | *** join/#brlcad yorik (~yorik@2804:431:f721:6f54:290:f5ff:fedc:3bb2) | |
| 13:47.52 | brlcad | that's exactly the case, the ray origin was about 10^4 units away, nearly perfectly slicing down through the side of the bbox -- deciding it was a miss of the bbox, but a hit on the enclosed cylinder face (perfectly aligned with the bbox face) |
| 13:48.02 | brlcad | "perfectly" of course |
| 13:53.24 | *** join/#brlcad merzo (~merzo@185.39.197.205) | |
| 13:57.05 | brlcad | starseeker: cmake error linking src/librt/tests/rt_pattern.c .. missing tinycthread symbol during link |
| 22:00.57 | *** mode/#brlcad [+o brlcad] by ChanServ | |
| 23:22.19 | *** join/#brlcad merzo (~merzo@43-15-132-95.pool.ukrtel.net) | |
| 23:23.58 | *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar) | |