IRC log for #brlcad on 20161123

00:13.12 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
00:21.19 *** join/#brlcad ries (~ries@D979C7EF.cm-3-2d.dynamic.ziggo.nl)
00:41.34 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
00:51.34 *** join/#brlcad teepee (~teepee@unaffiliated/teepee)
00:55.08 *** join/#brlcad ries (~ries@D979C7EF.cm-3-2d.dynamic.ziggo.nl)
01:33.18 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
01:43.18 *** join/#brlcad usybtveujxrllreu (~armin@dslb-088-065-186-000.088.065.pools.vodafone-ip.de)
05:43.18 *** join/#brlcad devi_ (73f8f961@gateway/web/freenode/ip.115.248.249.97)
05:43.50 starseeker brlcad: I had first implemented the sph sampling with our exiting random number generator - that worked, but it looked as if there was some "clumping" so I investigated methods for making things a bit more evenly spread out
05:44.14 brlcad starseeker: which one?
05:44.15 starseeker that led to the sobol, but once I got that hooked up I could see the pattern in the generated points on the sphere
05:44.38 starseeker randmt
05:45.51 starseeker so looking for ways to fix that led to the Florida State report, but I don't have a license compatible implementation of that in C ready to hand
05:46.10 starseeker so sobol in its current form is fairly useless
05:46.42 starseeker but as you say, the randmt method should be "good enough" and is readily available
05:47.32 starseeker the next step is to try hooking it up to the raytracer rather than fiddling with improving sph point generation...
05:47.53 starseeker unfortunately I got interested ;-)
05:49.26 brlcad I think it "can" be good enough for a first step, it'll probably just take 10x longer to converge a confidence interval below some tolerance
05:51.18 brlcad so cool, that's awesome progress
05:51.34 brlcad was it just the pattern that made sobol useless??
05:51.39 starseeker nods
05:51.55 brlcad did it support seeding?
05:51.56 starseeker it looks like its some sort of projection
05:52.12 starseeker yes, but it was the way the points were generated that was the problem not the specific values
05:52.26 starseeker visually it looked like a grid wrapped around a sphere
05:52.35 starseeker not precisely, but something along those lines
05:52.43 brlcad maybe in polor coordinates?
05:52.50 starseeker possibly
05:53.30 starseeker there was one point where a lot of points were clumping, like the parametric edge collapsed to a near-point there
05:54.12 starseeker it's possible I did something wrong - I know there are a lot of subtle points to this
05:54.33 brlcad sounds like something wrong
05:54.47 brlcad here's something you might have better luck with that saucier wrote
05:54.50 brlcad http://ftp.arl.mil/random/random.pdf
05:55.50 brlcad it's a c++ class that should be easily wrapped
06:03.12 *** join/#brlcad caen23 (~caen23@79.112.95.83)
06:10.40 starseeker brlcad: what I've got so far is in libbn/randsph.c and libbn/tests/randsph.c if you want to see - the sobol bit wouldn't be hard to turn back on, but at the moment it's all commented out
06:11.06 starseeker I need a better test viewer - right now I'm dumping in commands for spheres, which doesn't scale well
06:11.28 starseeker 50,000 in cmds for spheres makes MGED sad, apparently...
06:13.06 starseeker calls it a night
06:17.43 brlcad starseeker: nifty snippet I had stashed: http://brlcad.org/~sean/tmp/randompoints.html
06:18.08 brlcad basic quasirandom in like 10 lines of code
06:24.37 brlcad and the way the avoidance works, it will work incrementally (it'll just get slower/harder to get more points as the density increases)
06:26.32 brlcad for testing, should use the pnts primitive... perfect for this
06:34.57 brlcad hm... documenting the points primitive will make for a good gci task... :)
06:40.08 *** join/#brlcad amarjeet (~amarjeet@202.164.53.117)
06:42.42 *** join/#brlcad Lord_of_Codes (~Lord_of_C@122.163.244.145)
06:55.05 *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee)
07:54.52 *** join/#brlcad caen23 (~caen23@79.112.95.83)
10:02.40 *** join/#brlcad teepee] (bc5c2133@gateway/web/freenode/ip.188.92.33.51)
11:31.19 *** join/#brlcad Lord_of_Codes (~Lord_of_C@122.163.244.145)
11:33.08 *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar)
12:15.43 *** join/#brlcad yorik (~yorik@2804:431:f721:47e1:290:f5ff:fedc:3bb2)
12:34.52 *** join/#brlcad MikeH (~Mike@188.175.158.32)
12:40.03 *** join/#brlcad Lord_of_Codes (~Lord_of_C@122.163.244.145)
13:22.33 *** join/#brlcad Lord_of_Codes (~Lord_of_C@122.163.244.145)
13:25.51 starseeker brlcad: the bit about getting slower with more points added was one of the things I was trying to avoid - my intuitive expectation is that these methods may require a *lot* of points to converge...
13:26.43 starseeker pnts primitive would work execept IIRC it doesn't have an in cmd implementation... maybe I'm misremembering
14:42.00 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
14:57.49 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
15:16.41 Notify 03BRL-CAD:starseeker * 69215 brlcad/trunk/include/bn/rand.h: start working on a design for a generic API that can subsume the various possibilities for number sequence generation.
15:17.53 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
15:21.09 starseeker brlcad: comments appreciated on r69215 - those are my initial thoughts after the initial quasi-random sph pnt work on the "desired" API for libbn
15:26.30 Notify 03BRL-CAD:starseeker * 69216 brlcad/trunk/include/bn/rand.h: Make some rework/TODO notes for this function
16:24.50 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
16:55.45 *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar)
17:47.31 *** join/#brlcad Lord_of_Codes (~Lord_of_C@122.163.244.145)
21:09.42 Notify 03BRL-CAD:starseeker * 69217 (brlcad/trunk/include/bg/CMakeLists.txt brlcad/trunk/include/bn/CMakeLists.txt and 3 others): start stubbing in bits of a proposed generic pseudo/quasi random number sequence API.
22:21.18 *** join/#brlcad teepee (~teepee@unaffiliated/teepee)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.