| 18:52.14 | *** join/#brlcad infobot (ibot@rikers.org) | |
| 18:52.14 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || Congrats to all GCI 2014 winners Peter & Marc! || Congratulations to our 12 GSoC students! || Don't ask if someone is here, just ask your questions and wait for a response. ;-) | |
| 18:54.25 | *** join/#brlcad sofat (~sofat@202.164.45.204) | |
| 18:56.44 | Notify | 03BRL-CAD Wiki:202.164.45.204 * 8431 /wiki/User:Hitesh/option_for_docbook: |
| 19:00.22 | *** join/#brlcad andrei_il (~andrei@109.100.128.78) | |
| 19:01.56 | Notify | 03BRL-CAD Wiki:202.164.45.204 * 8432 /wiki/User:Hiteshsofat/GSoc15/log_developmen: |
| 19:03.16 | Notify | 03BRL-CAD Wiki:202.164.45.204 * 8433 /wiki/User:Hiteshsofat/GSoc15/log_developmen: |
| 19:10.56 | *** join/#brlcad tofu_ (~sean@66-118-151-70.static.sagonet.net) | |
| 19:10.57 | *** join/#brlcad starseeker (~starseeke@66-118-151-70.static.sagonet.net) | |
| 19:11.01 | *** join/#brlcad ejno_ (~ejno@unaffiliated/kazaik) | |
| 19:11.09 | *** join/#brlcad maths22_ (~maths22@66-118-151-70.static.sagonet.net) | |
| 19:17.03 | Notify | 03BRL-CAD:ejno * 65077 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: work on supporting boolean operations (in progress) |
| 19:21.52 | Notify | 03BRL-CAD:brlcad * 65078 brlcad/trunk/src/librt/primitives/sketch/sketch.c: add missing semicolon |
| 19:24.01 | *** join/#brlcad ih8sum3r (~chatzilla@122.173.183.95) | |
| 19:26.53 | ih8sum3r | brlcad: Hello |
| 19:42.53 | ``Erik | heh, he's using his alt alt nick, I doubt he's looking right now :) if you need help, ask your ask |
| 19:51.40 | ih8sum3r | I just want to ask, I'm planning to use http://codepen.io/zessx/pen/ZGBMXZ such kind of background in OGV landing page. Will it (kind of geometry) match BRL-CAD theme or not. |
| 19:52.47 | Notify | 03BRL-CAD Wiki:Deekaysharma * 8434 /wiki/User:Deekaysharma/logs: |
| 20:01.42 | Notify | 03BRL-CAD:carlmoore * 65079 brlcad/trunk/src/util/pix-bw.c: I have switched int to size_t because that's the type I see in a routine called by this program. |
| 20:01.47 | tofu_ | ih8sum3r: it's fine for now, but it definitely doesn't match our theme or preferred geometry representation type |
| 20:03.14 | ih8sum3r | tofu_: Can you please tell which geometry will match our theme? |
| 20:05.13 | brlcad | ih8sum3r: "not triangles" |
| 20:06.39 | brlcad | triangle geometry is pervasive with content modelers, not CAD |
| 20:07.47 | brlcad | ih8sum3r: there was a great discussion during GCI about using that same framework to display boolean operations interactively |
| 20:08.33 | brlcad | if you search the GCI tasks for the "splash screen" tasks, you should find some of that discussion and a few examples that are closer to fitting our theme |
| 20:09.00 | ih8sum3r | AFAIK was it done by Marc! |
| 20:09.05 | brlcad | yes |
| 20:09.27 | brlcad | had the same talk with him about polygons being inappropriate |
| 20:09.40 | brlcad | but fine for a starting point |
| 20:09.58 | brlcad | he used a style-agnostic gray theme, less movement, more subtle |
| 20:10.20 | ih8sum3r | I remember he made some page whose background was similar to this one http://codepen.io/VincentGarreau/pen/pnlso |
| 20:10.25 | brlcad | didn't get booleans working, but I think that was more a coding experience limitation that you might be able to manage quickly |
| 20:10.58 | brlcad | yes |
| 20:12.55 | brlcad | my suggestion was something along the lines of having it randomly generate ellipses and rectangles, performing union/subtract/unions as they move around |
| 20:13.27 | *** join/#brlcad sofat (~sofat@202.164.45.204) | |
| 20:14.12 | ih8sum3r | If I use similar thing which I send you will it be Okay? My plan is to use such background with the black tint above it on which BRL-CAD logo is there with written text OGV. Along with it there will be a login button. |
| 20:14.24 | ``Erik | why have a moving background for a landing page? O.o |
| 20:14.49 | ih8sum3r | Oh! okay i'll find something similar to ellipse or rectangles. |
| 20:16.00 | ih8sum3r | I thought to use it so that a leaves an impression of something like CAD or 3D to the user in the first look only. |
| 20:18.08 | brlcad | ih8sum3r: whatever you do, it should be very subtle .. the center of attention should be on login or docs or info or something else |
| 20:19.27 | Notify | 03BRL-CAD:carlmoore * 65080 brlcad/trunk/src/util/pix-bw.c: remove the variable named 'multiplier'; it was not being used |
| 20:20.25 | dracarys983 | brlcad: Take a look at the ERROR 1 here. It needs a change in CMakeLists.txt of include/rt. |
| 20:20.27 | dracarys983 | https://docs.google.com/document/d/1SvdoZ6VK1iRiCLrdmNrHDnJePjy5wCpD2s0iMkIOMDo/edit?usp=sharing |
| 20:20.48 | ih8sum3r | Okay i'll try to find out something good and new :). |
| 20:20.59 | *** mode/#brlcad [+o brlcad] by ChanServ | |
| 20:21.02 | *** mode/#brlcad [-q *!*@212.203.58.127] by brlcad | |
| 20:21.42 | brlcad | dracarys983: I can't get to gdocs from my current location -- can you summarize or repost to pastebin.ca |
| 20:23.03 | dracarys983 | brlcad: Present CMakeLists.txt of include/rt installs all headers (including it's subdirectory primitive's) in ${CMAKE_INSTALL_PREFIX}/include/brlcad/rt |
| 20:23.21 | dracarys983 | Hence there is no subdirectory primitives there |
| 20:23.37 | dracarys983 | Outcome are those errors |
| 20:23.48 | dracarys983 | s/are/is |
| 20:25.02 | ``Erik | hm, 'file -> email as attachment', or "file -> download as" and dcc could work |
| 20:25.16 | ``Erik | heh, dcc, there's a blast from the past :D |
| 20:25.38 | brlcad | dracarys983: ah, got it |
| 20:25.46 | brlcad | starseeker: easy fix? |
| 20:26.00 | brlcad | besides creating a subdir CMakeLists.txt file |
| 20:26.33 | dracarys983 | http://pastebin.ca/3012394 <-- rt's CMakeLists.txt changes |
| 20:27.22 | dracarys983 | http://pastebin.ca/3012397 <-- rt/primitive's CMakeLists.txt |
| 20:28.12 | brlcad | ah, so you added a subdir |
| 20:28.14 | brlcad | okay |
| 20:28.28 | brlcad | there's almost certainly a way to avoid that |
| 20:29.00 | brlcad | can you make that into a quick patch? |
| 20:29.01 | dracarys983 | brlcad: I'm all up to do it in a better way if there's one :D |
| 20:29.24 | dracarys983 | With subdir? |
| 20:29.35 | brlcad | that's why I asked starseeker .. he brok^wwrote it that way ;) |
| 20:31.00 | dracarys983 | Should I submit these changes as a patch or leave it to starseeker? |
| 20:32.55 | *** join/#brlcad sofat (~sofat@202.164.45.204) | |
| 20:33.06 | brlcad | if you make a patchfile, I'll apply it now |
| 20:33.14 | ``Erik | brlcad: did you get my email about dns? |
| 20:33.22 | brlcad | ``Erik: maybe |
| 20:33.40 | brlcad | I've not seen half my mail today |
| 20:33.42 | brlcad | (yet) |
| 20:34.00 | ``Erik | ah, I dropped isc on the server, I think it's working but a double check wouldn't hurt |
| 20:34.08 | brlcad | ah, cool |
| 20:35.07 | brlcad | that reminds me.. I got a slew (dozen or so) of rejection e-mails that were obviously either spoofing a brlcad.org address, or the smtp server somehow sent out a bunch of spam and I got the responses |
| 20:36.36 | ``Erik | spoofing an address? I see plenty of spams with malformed 'from' addresses that the server appends .brlcad.org to, is that what you're seeing? |
| 20:36.52 | ``Erik | "From blah@some.bad.host.brlcad.org" |
| 20:36.53 | brlcad | yeah, that's it |
| 20:36.56 | vasc | brlcad, did you get the chance to look at the OpenCL patches? |
| 20:37.26 | brlcad | vasc: I was working on one last night, looking good |
| 20:37.40 | brlcad | should finish it up tonight and can give some feedback/apply |
| 20:38.27 | vasc | cool. i'm looking at the rendering loop to see how i can parallelize it for opencl but its a bit convoluted and recursive |
| 20:38.40 | vasc | as expected |
| 20:38.43 | brlcad | yep :) |
| 20:38.52 | brlcad | I suggest batching first |
| 20:39.03 | brlcad | get all rays dispatching (which can then be parallelized) |
| 20:40.07 | brlcad | aggregate all hits (instead of immediately calling librt to weave them and liboptical to colorize them) |
| 20:40.34 | vasc | the problem is with the secondary rays |
| 20:41.13 | brlcad | could ignore secondary for first steps, or go with a streaming main loop (consumer/producer) |
| 20:41.24 | brlcad | good paper on that method from a couple years ago |
| 20:41.41 | vasc | the traditional ray tracing rendering loops do ray tracing in a depth first manner across the ray tree. but we need to do breadth first on the gpgpu |
| 20:41.50 | brlcad | nods |
| 20:41.58 | brlcad | that's basically what I mean by batching |
| 20:42.03 | vasc | yes |
| 20:43.11 | brlcad | here we go |
| 20:43.18 | vasc | i think i'll ignore secondaries as a first approach, but we'll want them back later on. this should be a rendering pipeline option aka quick path or whatever |
| 20:43.37 | brlcad | don't know if it's online, but from HPG09: "Faster Incoherent Rays: Multi-BVH Ray Stream Tracing" |
| 20:43.41 | vasc | there was an interesting paper a couple of years back |
| 20:44.20 | vasc | that one's too intel specific i think |
| 20:45.14 | brlcad | the optimizations are too intel/simd-specific, but the overall algorithm is pretty sound |
| 20:45.21 | brlcad | and generalizable |
| 20:45.58 | brlcad | anyways, just a thought .. how that applies to our code is still the bigger piece of the pie |
| 20:46.04 | vasc | i think its a single-ray many object intersection routine |
| 20:46.11 | vasc | its good for secondaries but |
| 20:48.52 | Notify | 03BRL-CAD:brlcad * 65081 brlcad/trunk/src/librt/primitives/xxx/xxx.c: actually demonstrate specific allocation and deallocation since calling bu_free() can be wrong if that's not how it was allocated. |
| 20:49.32 | dracarys983 | brlcad: Done. :) |
| 20:50.59 | Notify | 03BRL-CAD:brlcad * 65082 brlcad/trunk/src/librt/primitives/xxx/xxx.c: this is why xxx needs to be enabled for compilation. gets out of sync too easily. add missing cv.h header for SIZEOF |
| 20:51.51 | vasc | the thing is you can increase the branching factor of a bvh to do parallel testing. to a point |
| 20:52.13 | Notify | 03BRL-CAD:brlcad * 65083 brlcad/trunk/src/librt/CMakeLists.txt: enable xxx for continuous compilation. might want to put this into its own noinst lib, but this is a reasonable way to ensure the exact same compilation settings are being used. |
| 20:52.25 | vasc | but its one thing to have a bvh with 4-arity for intel simd and another to make like hundreds of threads arity |
| 20:52.37 | vasc | like for a gpu |
| 20:53.13 | vasc | it can work for a complex scene with thousands of primitives or more but will give no speedup in simpler scenes |
| 20:53.21 | Notify | 03BRL-CAD:brlcad * 65084 brlcad/trunk/src/librt/CMakeLists.txt: too soon |
| 20:53.51 | dracarys983 | vasc: Congratulations for the CGI paper man. Didn't get a chance before :) |
| 20:54.09 | brlcad | dracarys983: link? |
| 20:54.12 | vasc | thx |
| 20:54.35 | dracarys983 | brlcad: https://sourceforge.net/p/brlcad/patches/371/ |
| 20:54.48 | vasc | its just a short paper though. i had too much work back when it was the time window to submit the long papers |
| 20:54.49 | brlcad | vasc: yeah, aren't you supposed to be at a conference this week? :) |
| 20:54.58 | vasc | its next month |
| 20:55.14 | brlcad | ah, got the date wrong on my calendar then |
| 20:55.33 | dracarys983 | vasc: Like a technical brief? |
| 20:55.37 | vasc | http://cgi2015.unistra.fr/ |
| 20:55.55 | vasc | its a short paper. 4 pages. i'll then get a change to submit an extended version though |
| 20:56.10 | vasc | to the visual computer journal |
| 20:56.33 | dracarys983 | Nice. :) |
| 20:56.42 | dracarys983 | All the Best for that! |
| 20:56.59 | vasc | thx. it might be accepted or not. i hope it will. |
| 20:58.14 | Notify | 03BRL-CAD:brlcad * 65085 brlcad/trunk/src/librt/CMakeLists.txt: still ignore headers |
| 20:58.27 | dracarys983 | vasc: We ride on hope most of the time. I believe it will get accepted, though. :) |
| 21:01.29 | vasc | i think the Fast Ray Sorting and BreadthâFirst Packet Traversal for GPU Ray Tracing paper by Garanzha and Loop might be more appropriate |
| 21:02.29 | vasc | than the intel one |
| 21:02.41 | vasc | i think garanzha is at nvidia now |
| 21:03.54 | Notify | 03BRL-CAD:brlcad * 65086 brlcad/trunk/include/rt/CMakeLists.txt: apply sf patch #371 (Changes in CMakeLists.txt for include/rt and include/rt/primitives) from Kalpit Thakkar that fixes header installation |
| 21:05.01 | vasc | man my english keeps getting worse and worse ever since i started reading scanlated japanese and korean manga |
| 21:06.53 | Notify | 03BRL-CAD:brlcad * 65087 brlcad/trunk/AUTHORS: credit kalpit with his code contribution that fixed header installation (sf patch 371), first from gsoc 2015 activity |
| 21:08.02 | vasc | about the sampling technique for the estimation of area or whatever its like brlcad said. you can always use the same RNG seed to make it predictable. |
| 21:08.51 | vasc | or cast the exact same rays of whatever |
| 21:09.12 | vasc | i think for the volume estimation there's another possibility though. |
| 21:09.36 | vasc | depending on how innacurate you accept the results to be |
| 21:10.01 | vasc | i think there's already a bounding box operator for all the primitives so you could just use that |
| 21:11.24 | vasc | you could even use it for area estimation as well |
| 21:11.36 | vasc | its probably really inaccurate but at least its fast |
| 21:14.35 | vasc | you would just computer the surface area of the bounding box and the volume of the bounding box as the estimate of the real thing |
| 21:14.39 | vasc | compute |
| 21:14.57 | Notify | 03BRL-CAD:brlcad * 65088 (brlcad/trunk/src/libsysv/memset.c brlcad/trunk/src/libsysv/strchr.c and 3 others): yo dawg, I heard you like to quell warnings on your warning quellage. compilers be gotten smart. |
| 21:15.20 | brlcad | example of a bad commit message ;) |
| 21:15.45 | dracarys983 | brlcad: Haha okay :P |
| 21:16.24 | dracarys983 | vasc: So we find the best bounding box and use it's estimate for volume and surface area. That's what you're saying? |
| 21:16.46 | brlcad | vasc: for that particular analysis (volume) I don't even think you'd need to match seed since it should be possible to track the convergence |
| 21:17.07 | brlcad | once we get N+M digits of confidence, we print the N digits back to the user |
| 21:17.59 | brlcad | but doesn't matter, daniel wants to go with the refactoring route, and that is definitely the lower-risk avenue from where we're at 9there's a LOT of validation in most of our analysis code) |
| 21:18.10 | vasc | its going to be a gross estimate. but at least it will be quick to compute. if you only use the area and volume operators for computing heuristics its probably good enough |
| 21:19.06 | vasc | the you know the volume of the bounding box is always larger or the same as the volume of the real thing |
| 21:19.12 | vasc | s/the/and |
| 21:19.21 | vasc | as for the area i dunno |
| 21:19.37 | brlcad | I believe someone actulaly implemented the BB estimate method you mention |
| 21:19.41 | brlcad | like 20 years ago :) |
| 21:19.46 | vasc | yes |
| 21:19.54 | vasc | so its like i said you can just use that |
| 21:20.01 | brlcad | it's not useful |
| 21:20.13 | vasc | what's the intended application scenario? |
| 21:20.30 | brlcad | a user wants to know what the volume of object X is for a report |
| 21:20.57 | vasc | oh i see. you could use it to know how much material you need to manufacture the thing or whatever |
| 21:21.15 | brlcad | how much mass it has for some simulation |
| 21:21.23 | vasc | and if its equal density you could compute mass yes |
| 21:21.43 | brlcad | this is a very common use case (why gqa and rtweight exist) |
| 21:22.23 | brlcad | hooking them into the analyze command is more of a convenience / usability objective |
| 21:22.57 | brlcad | instead of having to fire up this other command-line tool, specify view(s) and object(s) and fiddle with option knobs .. have it all happen automatically |
| 21:23.14 | vasc | so you basically want rtweight to be available on the fly and automatically. i see. |
| 21:23.34 | brlcad | actually view-independent gqa, but yes |
| 21:24.08 | brlcad | rtweight is a single view sample so it has really bad convergence properties if the model happens to align with the view being shot |
| 21:24.31 | vasc | you need at least to compute one for each major plane |
| 21:24.37 | brlcad | think shooting through a screen door .. goes from solid mass to complete miss depending on the grid alignment |
| 21:24.49 | brlcad | which is exactly what gqa does |
| 21:24.57 | vasc | yeah, which i why i said you need one for each major plane |
| 21:25.01 | brlcad | so users have almost abandonded rtweight in favor |
| 21:25.21 | vasc | oh |
| 21:25.26 | dracarys983 | brlcad: Yeah, even I like gqa |
| 21:25.39 | brlcad | users then said they want more than just the major planes since you can still end up with perfect alignment issues (along diagonals and grazing rays) |
| 21:25.56 | brlcad | they want 32 views |
| 21:26.05 | brlcad | (which is a standard analysis thing) |
| 21:27.04 | vasc | so gqa basically voxelizes the model and computes the volume that way? |
| 21:27.08 | brlcad | I look at that and know that really they want it view independent .. just give me the volume with some known error bars |
| 21:27.30 | brlcad | sort of -- it uses the actual hit depths but basically yes |
| 21:27.51 | brlcad | or maybe we just talked about it doing that in which case the answer is just yes ;) |
| 21:28.12 | brlcad | been a while since I worked on that code |
| 21:28.31 | brlcad | both commands have been rewritten a couple times because they're so frequently called |
| 21:29.13 | brlcad | gqa's main limitation is that you can't specify views and it's convergence is REALLY slow |
| 21:29.28 | brlcad | it globally increases density by doubling factors per view |
| 21:29.51 | vasc | i see |
| 21:30.17 | brlcad | by that, I mean a few minutes on big models |
| 21:30.29 | vasc | you could probably use something like adaptive supersampling in that case |
| 21:31.01 | brlcad | maybe, it's tricky since it doesn't actually know if there's some pattern being overlooked without increasing the global density |
| 21:31.03 | vasc | i.e. only if the adjacent values are different do you refine further |
| 21:31.18 | vasc | yeah adaptive supersampling sometimes doesn't catch fine details |
| 21:31.21 | brlcad | if you only sample "edge cases" you miss pathological geometry cases and have massive error |
| 21:31.38 | brlcad | which wouldn't be acceptable for this usage |
| 21:31.47 | vasc | but in this case you're mostly doing contours right? |
| 21:32.20 | vasc | i could see it being a problem in something with holes though |
| 21:32.40 | vasc | like a torus |
| 21:32.47 | brlcad | right, that's basically the problem we even see shooting the three primary axes |
| 21:33.38 | brlcad | that's why I really like the quasirandom spherical sampling approach |
| 21:34.08 | brlcad | it has convergence properties that are intrinsically view agnostic and error can be characterized as a function of increasing sampling density |
| 21:34.12 | vasc | even that will have problems if the surface isn't a manifold |
| 21:34.59 | brlcad | we're a solid modeling system, if it's not manifold it's invalid geometry (or at least meaningless to talk about volume) |
| 21:35.05 | vasc | ok |
| 21:35.41 | Notify | 03BRL-CAD:ejno * 65089 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: refactoring Section code (in progress); better management of grid IDs |
| 21:35.46 | vasc | even then something with holes will have issues |
| 21:35.54 | vasc | its just that its less dependent on positioning |
| 21:36.24 | brlcad | how are holes an issue? |
| 21:36.47 | vasc | like the torus |
| 21:37.08 | brlcad | not following |
| 21:37.11 | vasc | if i only look from the outside in a spherical projection i lose some data when looking that way |
| 21:37.38 | vasc | hm actually it should work pretty nice now that i think about it |
| 21:37.49 | brlcad | er, still not following :) |
| 21:37.57 | vasc | well |
| 21:38.04 | brlcad | we do full shotline samling, so I have ray segments through and through |
| 21:38.11 | brlcad | the hole will be a gap between segments |
| 21:38.31 | brlcad | sampled in any pattern, a torus will converge very quickly |
| 21:39.03 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 21:39.31 | brlcad | pathological cases are repetititve like blinds in a window, cheese graters, thin air intake slats on an engine block, etc |
| 21:39.40 | vasc | ok. i thought you only used the closest intersection value |
| 21:39.49 | brlcad | never! |
| 21:39.52 | brlcad | that's our specialty |
| 21:40.17 | brlcad | well not never .. we do only use first hit when making pretty pictures for performance |
| 21:40.31 | brlcad | but it's not our primary purpose |
| 21:41.10 | vasc | so basically your problem is getting the details because you're ray sampling and might miss something |
| 21:41.12 | brlcad | primary purpose is full shotline / multihit ray tracing for analytic (scientific) purposes |
| 21:41.17 | vasc | i guess you could use beam sampling :-) |
| 21:41.21 | vasc | j/k |
| 21:41.26 | brlcad | considered that |
| 21:41.30 | brlcad | beams, cones |
| 21:41.49 | brlcad | but reimplementing so many shot routines is probably highly impractical |
| 21:41.53 | vasc | exactly |
| 21:42.03 | brlcad | especially nurbs... |
| 21:42.17 | brlcad | and some higher-order surfaces |
| 21:42.20 | vasc | its basically the same issue you have with the volumes and area routines implementation except its much harder to compute beam intersections |
| 21:42.27 | brlcad | elliptical torus would actually be pretty hard I bet |
| 21:44.28 | vasc | oh talking about the spherical sampling reminded me of this paper by a guy i know |
| 21:45.54 | vasc | "Spherical Fibonacci Point Sets for Illumination Integrals" |
| 21:47.15 | vasc | it describes a way to generate meaningful points on a sphere for illumination integral computation. but its basically the same idea since you want to generate points on a sphere around the object to project the rays for the sphere sampling |
| 21:48.07 | vasc | i think people usually just use a halton or sobol sequence but i don't know what would be appropriate in your case |
| 21:48.54 | *** join/#brlcad andrei_ (bc1ac0b6@gateway/web/freenode/ip.188.26.192.182) | |
| 21:51.47 | brlcad | vasc: that's very much a related idea, quasi monte-carlo is exactly what this is too |
| 21:54.35 | brlcad | and exactly the same reasoning, faster / better convergence properties .. just not hemispherical for illumination |
| 21:54.55 | brlcad | but spherical for volumetric estimation |
| 21:55.18 | dracarys983 | brlcad: Should I read a paper and get an idea on quasirandom spherical sampling? Maybe we can talk to Daniel about this approach then? |
| 21:56.35 | brlcad | dracarys983: no, it's still scope creep on your objectives |
| 21:56.55 | brlcad | unnecessary unproven complexity (however promising and interesting it may be) |
| 21:56.57 | vasc | yeah |
| 21:56.58 | Stragus | You can often just precompute an uniform distribution on your sphere. Pick a random rotation matrix, sample X random points and every once in a while pick a new random rotation |
| 21:57.16 | vasc | when the intervals of the sampling distribution are non-constant its hard to compute the actual volume |
| 21:58.18 | vasc | maybe |
| 21:58.22 | brlcad | dracarys983: I think the first option is the better way to go -- and you could even go with gqa as-is without hardly any changes really |
| 21:58.58 | vasc | yeah that one seems like a good first approach |
| 21:59.01 | brlcad | leaving custom views for later/never :) |
| 21:59.44 | vasc | you could do the transform thing and sample things obliquely too i guess. |
| 22:00.11 | vasc | like Stragus said |
| 22:00.13 | brlcad | basically entails moving most of gqa's ray firing and book-keeping code into libanalyze, updating gqa and the analyze command to call libanalyze |
| 22:00.46 | dracarys983 | brlcad: Okay. That sounds good. |
| 22:00.57 | brlcad | gqa does a whole lot more than volume, so this may take you a while to sort through how to move the code |
| 22:01.22 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 22:01.29 | dracarys983 | No problem. |
| 22:01.56 | brlcad | just don't want to end up with a massive copy of gqa living in two places, so whatever you do should get refactored properly |
| 22:03.05 | dracarys983 | brlcad: Right. Will take care about that. |
| 22:03.43 | dracarys983 | brlcad: And oh, I'm done with the rt^3 changes to conform with recent changes in brlcad. |
| 22:03.58 | dracarys983 | Patch will be ready by tomorrow. :) |
| 22:04.02 | vasc | which reminds me i need to refactor some of the opencl stuff late on. i tried to not have external dependencies but too much code is duplicated right now. |
| 22:04.33 | vasc | maybe the opencl should be all in the same file for the intersection routines as well. |
| 22:04.48 | vasc | or i'll need some include |
| 22:04.56 | brlcad | dracarys983: great |
| 22:05.30 | andrei_ | hi, brlcad |
| 22:05.48 | brlcad | vasc: yeah, suggest using the tree hierarchy so you could put common code in src/librt/primitives for example |
| 22:06.28 | brlcad | want each primitive to remain independent / modular to the best we can |
| 22:06.34 | vasc | yeah i'll do a cleanup patch afterwards. i think we have enough of a variety of implementation cases to figure out how to refactor now. |
| 22:06.55 | vasc | well one of the issues with opencl is that you can't link it in the binary. at least not in opencl 1.2. |
| 22:07.13 | vasc | so you have to either read a file or parse an in-memory string and pass it to the gpu compiler |
| 22:07.31 | vasc | which is usually in the graphics driver |
| 22:07.58 | vasc | so you end up with lots of little .cl files in an installation directory somewhere |
| 22:08.46 | vasc | well |
| 22:08.50 | andrei_ | brlcad: I've been looking over andrei_il 's project, I don't have as much time as a mentor but, I'm trying to help him out. Let me know when you got a few minutes, please. |
| 22:08.55 | vasc | once these patches are in i'll do the refactoring |
| 22:09.09 | vasc | otherwise its gonna clash |
| 22:09.25 | vasc | during the merge |
| 22:09.52 | Notify | 03BRL-CAD Wiki:Andrei.ilinca24 * 8435 /wiki/User:Andrei.ilinca24/logs: /* Coding Period */ |
| 22:27.41 | Notify | 03BRL-CAD Wiki:Konrado DJ * 8436 /wiki/User:Konrado_DJ/GSoc2015/logs: /* 27 MAY 2015 */ |
| 22:27.58 | Notify | 03BRL-CAD Wiki:Konrado DJ * 8437 /wiki/User:Konrado_DJ/GSoc2015/logs: /* 27 MAY 2015 */ |
| 22:34.43 | brlcad | vasc: *nod* |
| 22:35.09 | brlcad | ending up with a dir of .cl files in the install tree will work just fine |
| 22:36.03 | brlcad | can be called during prep or we can create a set of per-object callbacks called once on init and shutdown |
| 22:37.14 | brlcad | can be sorted out later, those are non-priority issues compared to getting the pipeline to work at all ;) |
| 23:16.58 | vasc | sure. but i don't like code to be too dirty. i usually refactor when things get too messy. |
| 23:39.44 | Notify | 03BRL-CAD Wiki:Bhollister * 8438 /wiki/User:Bhollister/DevLogMay2015: /* Thursday, May 28, 2015 */ |