| 00:06.29 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 01:18.44 | *** join/#brlcad infobot (ibot@rikers.org) |
| 01:18.44 | *** topic/#brlcad is BRL-CAD and open source CAx discussion ! Also @ http://brlcad.zulipchat.com ! Logs @ http://infobot.rikers.org/%23brlcad/ |
| 01:59.32 | DenisP | Hello guys. I wanted to talk about GSOC Appleseed integration project again. |
| 02:00.21 | DenisP | I have looked through GCI tasks as you adviced and currently I am experimenting with appleseed plugin system. So far, I have implemented two procedural objects, for sphere and ellipse. Basically I just assigned intersection/occlusion callbacks to BLR-CAD intersection functions (for sphere it's rt_sph_shot(...), for ellipse it's rt_ell_shot(...)) and it works fine. |
| 02:01.01 | DenisP | Here is the picture: boxes are rendered with appleseed traversal routines, and sphere/ellipse with brl-cad intersection functions. |
| 02:01.07 | DenisP | dropbox.com/s/13b0ch6fs4u6hay/sphere_ellipse.png?dl=0 |
| 02:02.16 | DenisP | This plugin system is great by the way. I have been using Intel Embree in my renderer for some time already and it's got almost the same API with callbacks for custom geometry. |
| 02:03.40 | DenisP | As for mesh ray tracing, I am not sure yet how to integrate kdtree bulding/traversal into the procedural object and there's also an issue of effective parallelization and resources allocation (for me, at this point brl-cad's memory allocation system seems pretty much complicated). |
| 02:04.36 | DenisP | So, I am not sure yet if this project is possible without rewriting appleseed's core (at least a little). But I think it's better to start with plugin approach anyway even if it may be a bit slower than with native rt_shootray mechanism. |
| 02:04.45 | DenisP | What do you think about it? |
| 02:05.50 | DenisP | Oh, by the way, I have been thinking about making some bugfixes and I liked this ticket: sourceforge.net/p/brlcad/bugs/368/ . Do you know if anyone is working on it right now? And also, is there a FAQ with all Archer commands or something like this? |
| 02:12.12 | *** join/#brlcad DenisP_ (d40d70a2@gateway/web/freenode/ip.212.13.112.162) |
| 02:49.45 | *** join/#brlcad Radicarian (~Radicaria@cpe-72-231-246-183.buffalo.res.rr.com) |
| 03:07.12 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 03:10.23 | *** join/#brlcad merzo (~merzo@179-11-133-95.pool.ukrtel.net) |
| 03:37.53 | brlcad | DenisP_: major props! |
| 03:47.59 | brlcad | that's certainly a way to get attention... awesome demonstration of progress |
| 03:50.49 | brlcad | one major step during GSoC (or perhaps before at the rate you're going) is to implement just one procedural object type for "brl-cad" geometry, and call rt_shootray() for the intersection function |
| 03:51.08 | brlcad | that should then get full rendering of any brl-cad geometry, no matter the representation type |
| 03:52.21 | brlcad | performance isn't even on the table at this point because the goal is high-end rendering features on brl-cad geometry, and production-quality integration with BRL-CAD |
| 03:56.39 | brlcad | once basic intersection is working, next step would probably be displaying some material properties, color at a minimum |
| 03:57.55 | brlcad | at that point, things get a bit more tricky but a bridge to be crossed later |
| 03:59.17 | brlcad | as for integrating kdtree building/traversal, it's probably simpler than you realize -- you just need to call rt_dirbuild() and rt_prep_parallel() prior to all the rt_shootrays(), presumably during some procedural object load |
| 04:00.39 | brlcad | you can rt_shootray() in parallel by initializing brl-cad API resource structures -- many examples of this: grep rt_init_resource src/*/*.c |
| 04:00.49 | brlcad | that's also called during prep |
| 04:01.01 | brlcad | (prior to rt_prep_parallel()) |
| 04:04.39 | DenisP_ | Wait, isn't rt_shootray() working for the whole scene? |
| 04:06.11 | brlcad | what do you mean exactly? |
| 04:09.35 | DenisP_ | Let's say we have a simple program like rtexample. First we load the scene and build the kd-tree. Then we call rt_shootray() which goes through the whole kd-tree and returns some data about the hit, right? |
| 04:10.15 | brlcad | s/kd-tree/spatial partitioning/, but yes |
| 04:10.51 | brlcad | the type of partitioning in brl-cad depends on the type of geometry being prep'd |
| 04:11.39 | DenisP_ | When we make procedural objects in appleseed we override functions for bbox construction around the object and intersection/occlusion. And when the appleseed casts a ray into the scene, depending on the bounding box the ray hits, it calls the correspoding intersection function. So, we kind of already know the object the ray is going to hit. |
| 04:11.42 | brlcad | so you only load the scene and build the spatial partitioning once, during some load or init function |
| 04:12.21 | brlcad | except you don't know :) |
| 04:13.11 | brlcad | brl-cad geometry can be (and often is) super complicated inside a given box, you don't know what's there until you shoot the ray and get hits |
| 04:13.46 | brlcad | simple spheres and boxes are degenerate simple cases that we don't even really think about because they're kind of rare outside of testing |
| 04:14.48 | DenisP_ | Oh, okay, I get it. You want to load the whole scene inside one Procedural object instead of procedural objects for each kind of geometry. |
| 04:14.59 | DenisP_ | Yeah, that's probably will be even simpler |
| 04:15.15 | brlcad | remember (or know) that there is intrinsic support for boolean operations, which by definition means you don't know where the hit is until after the boolean is processed which is after intersections are known |
| 04:17.53 | brlcad | you might also be worrying about performance, but rt_shootray() tracing is generally millions of rays per second per cpu core, and you will need to support shooting in parallel |
| 04:19.06 | brlcad | that material properties bridge will make things a bit more complicated, no longer one procedural object, but again that's a bridge to be crossed later |
| 04:20.07 | brlcad | that requires a bit more in-depth understanding of how CAD geometry differs from content modeling (e.g., region hierarchy vs triangle mesh nodes) |
| 04:22.48 | brlcad | oh also, you can get at bounding boxes after calling rt_prep_parallel() for setting up the procedural bounding box |
| 04:23.20 | brlcad | similar code to what you need in src/libged/bb.c -> src/libged/get_obj_bounds.c |
| 04:23.29 | brlcad | bb command in mged/archer |
| 04:23.56 | brlcad | DenisP_: can you tell me a bit about your background? |
| 04:26.52 | DenisP_ | Sure, one sec. |
| 04:39.29 | DenisP_ | I've got a bachelor degree in software engineering from Higher School of Economics, Moscow, Russia. Currently I am enrolled in master's program in computer science, also there at HSE. I am doing my thesis at Moscow State University's graphics lab. It's about Gradient-domain rendering. Overall, I have been doing computer graphics for about 3 years. First it was real-time rendering, physics engine and stuff, and since my bachelor's t |
| 04:39.55 | DenisP_ | it's physically-based rendering. Regarding open-source, well. For a few years, during summer internships at ROSA lab, I have been contributing to ROSA Fresh linux distro. It's not really computer graphics related, but I have developed a small QT-based Bluetooth app for LXQT and have built a few dozens of Python packages :) I also have been writing some small stuff for the inhouse renderer at the graphics lab I do my thesis at. |
| 05:23.59 | brlcad | DenisP_: thanks, excellent intro |
| 05:24.49 | brlcad | hadn't heard about gradient-domain rendering (or at least not something I've retained if I have come across it before) |
| 05:26.35 | brlcad | sounds like an excellent background for this task, possibly a relevant extension into our performance rendering goals too (converting BRL-CAD's ray pipeline to being a more memory coherent and vectorizable) |
| 05:27.10 | DenisP_ | >hadn't heard |
| 05:27.11 | brlcad | interesting that you're at an econ school studying graphics |
| 05:27.12 | DenisP_ | Well, currently it's not really production-suitable. Though Gradient-domain Path Tracing / MLT gives pretty good results. |
| 05:54.04 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 05:54.58 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 05:55.42 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 05:55.57 | *** join/#brlcad witness (uid10044@gateway/web/irccloud.com/x-rgmcgjjevyxnumdy) |
| 07:41.48 | *** join/#brlcad yukonbob (~bch@S01069050ca2cbf63.ok.shawcable.net) |
| 07:53.37 | *** join/#brlcad merzo (~merzo@239-0-132-95.pool.ukrtel.net) |
| 08:40.00 | *** join/#brlcad yukonbob (~bch@24.70.185.109) |
| 11:34.50 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 12:53.58 | *** join/#brlcad yorik (~yorik@2804:431:f721:5f78:290:f5ff:fedc:3bb2) |
| 12:57.37 | *** join/#brlcad merzo (~merzo@185.39.197.205) |
| 14:07.15 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 15:06.33 | *** join/#brlcad DenisP (d40d70a2@gateway/web/freenode/ip.212.13.112.162) |
| 15:59.19 | *** join/#brlcad sreyansh (cb6ef205@gateway/web/freenode/ip.203.110.242.5) |
| 16:35.48 | *** join/#brlcad yukonbob (~bch@S01069050ca2cbf63.ok.shawcable.net) |
| 17:08.17 | *** join/#brlcad yukonbob (~bch@S01069050ca2cbf63.ok.shawcable.net) |
| 17:56.07 | *** join/#brlcad gabbar1947 (uid205515@gateway/web/irccloud.com/x-hcnysufwkavsiydk) |
| 18:15.16 | *** join/#brlcad yukonbob (~bch@S01069050ca2cbf63.ok.shawcable.net) |
| 18:17.38 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 18:37.17 | *** join/#brlcad yorik (~yorik@2804:431:f720:76fa:290:f5ff:fedc:3bb2) |
| 19:01.54 | *** join/#brlcad yukonbob (~bch@S01069050ca2cbf63.ok.shawcable.net) |
| 19:25.35 | *** join/#brlcad teepee (~teepee@p578EC75F.dip0.t-ipconnect.de) |
| 19:31.52 | *** join/#brlcad Guest53861 (~teepee@unaffiliated/teepee) |
| 19:34.21 | *** join/#brlcad yukonbob (~bch@S01069050ca2cbf63.ok.shawcable.net) |
| 20:27.18 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 20:29.07 | *** join/#brlcad yukonbob (~bch@S01069050ca2cbf63.ok.shawcable.net) |
| 20:42.29 | DenisP | Hi. I have been wondering if I can find somewhere examples of BRL-CAD projects (.g files)? |
| 20:43.11 | DenisP | I think I have got a working implementation of BRL-CAD procedural object, but I wanted to test it on complex scenes. |
| 20:45.15 | DenisP | dropbox.com/s/gsyb99e8o062dqb/brlcadobject.png?dl=0 |
| 22:05.13 | *** join/#brlcad DenisP (d40d70a2@gateway/web/freenode/ip.212.13.112.162) |
| 23:45.29 | *** join/#brlcad DaRock (~Thunderbi@mail.unitedinsong.com.au) |
| 23:57.34 | *** join/#brlcad DaRock1 (~Thunderbi@mail.unitedinsong.com.au) |