On Thu, Oct 16, 2014 at 3:01 AM, Erik Greenwald <e...@elfga.com> wrote: > > Could you make the data/results public? (could even be a nifty blog post or > article)
Sure. Feel free to download and use them, but you may have to improve them as they still don't get too relevant. > There were also very slight differences in hit depth/distance and normal, > check out an old pixdiff of a facetized m35 > athttp://elfga.com/~erik/bot20101229.png to see :) the 'rainbow waves' are > the location/normal discrepancy in action. We never tested these to see if > either were within a certain tolerance or if either was close to the zomfg > infinite precision mathematical result. I also achieved a similar aliasing with my spheres[1]. There are some visible differences[2][3] caused by a misinterpretation of the face margins (this is the case with the most different pixel - (241, 180)), so I'd say that the ray direction is also a bit affected. Furthermore, I don't think that this is principally due to precision loss, because I changed TIE_PRECISION to TIE_SINGLE_PRECISION and the total number of different bytes only increased from 79135 to 79399. There is some nedeterminism in the raytracing process. This pixdiff[4] was obtained from two successive raytracings, both with LIBRT_BOT_MINTIE unset and the original .pix files differ in 66218 bytes. On Thu, Oct 16, 2014 at 7:41 AM, Christopher Sean Morrison <brl...@mac.com> wrote: > > Very interesting and great data to see! The conclusion is a little > premature, though… Thanks for feedback, I took into account your advices[5], yet the results don't reveal anything clear[6][7]. > their are several discrepancies in the data that raise questions and (more > importantly) they don’t reflect observed performance behavior, but I think > it’s mostly because of the limited range of testing. Try powers of 2 instead > of incrementing by 2, take it up to at least 20M triangles (so 25+ runs). I modified the script to exponentially increase the complexity, but can't reach 20M as it runs too slowly. > You’re looking for an expensive prep overhead, which is going to be tricky > with your sphere model because that’s essentially a best case for TIE’s > spatial partitioning method. TIE’s prep will, however, still get > exponentially slower whereas without-tie’s prep should get slower linearly. > TIE may still always win that case because, like I said, it’s a best case. If TIE's prep runs exponentially with the number of triangles, does that mean that TIE will surpass non-TIE at some point (I didn't actually check if TIE's shot / non-TIE's prep / non-TIE's shot run in polynomial time)? If this is the case, the heuristics should be reversed, that is: if #triangles >= RT_DEFAULT_MAXTIE, run rt_bot_prep_*(), else bottie_prep_double(). > Another useful test model is to just create random triangles that span the > sphere’s interior (i.e., pick any three distinct points, make it a triangle, > repeat). That should be essentially a worst case for both with-tie (and > without-tie) and have a fairly different performance profile. Done, the number of inner triangles can be given as an optional argument and the -u option will make them distinct (but will also use much more memory). > Another issue is that you create the .g file and then run the without-tie > test and then the with-tie test every time. This will cause without-tie to > always pay a disk read overhead and with-tie will might potentially be > gaining a slight advantage from the filesystem cache. Maybe run without-tie > twice, and only look at the second run time. That might be what’s causing > the spiking of without-tie’s performance (sometimes the .g got loaded to > cache by the time rt ran, sometimes it didn’t). Very good point. I modified the calling order, now I firstly run all the non-TIE tests and then all those for TIE. > Yet another factor is the number of rays being fired. You just run rt, so > that’s running prep once and shooting rays 262144 times. I don’t think > that’s unfair, but you’ll see without-tie fare much better as the number of > rays decreases (e.g., if you shot only a single ray). I don’t think you need > to actually test this unless you’re curious, but being aware of this bias (in > TIE’s favor) is important for interpreting the results. Now I measure the two routines separately (shot time is still measured for all those 262144 rays together as it would have been too small for one single ray). If I had the results for a huge number of triangles, then for any given number of rays that are going to hit the object surface I could find the intersection of prep + rays_no * shot for the two methods. Of course, the problem is that when I take the decision of using TIE or non-TIE (which happens in rt_bot_prep()) for a specific mesh, I don't know how many rays are going to be shot, because every application that uses raytracing handles it differently. But, if TIE's prep really grows exponentially, then the so-called RT_DEFAULT_MAXTIE wouldn't depend too much on the number of rays as there would be a pretty tiny interval in which TIE's prep + rays_no * TIE's shot would overcome non-TIE's prep + rays_no * non-TIE's shot for the traditional orders of magnitude of rays_no, so the desired range of RT_DEFAULT_MAXTIE might be compressed to a single number. I don't know if this really leads to something since meaningful results look kind of hard to obtain. > Lastly, I can’t say for certain whether without-tie and with-tie prep > overhead is linear with the number of objects. That is to say, what happens > as the number of objects increases? If I have 1 sphere vs 1024 spheres does > it get linearly slower? It almost certainly won’t even if you tried to > compensate for the same number of pixels hitting triangles. I don’t think > you need to actually test this aspect too, but it’s also worth noting as > real-world models are rarely ever single meshes but collections of thousands > or tens of thousands. Probably, but there would be necessary high computational resources to run the experiment is this case and the way the model complexity differs between the objects relative to one another could be an important factor too. On Thu, Oct 16, 2014 at 4:57 PM, Erik Greenwald <e...@elfga.com> wrote: > > Very interesting graph, the non-tie line particularly. In fact, the non-TIE graph was drastically influenced by reading overhead, as Sean pointed out. > This was just one rt sample at each tri count? Yes, there was a single execution of rt for a single mesh each time. Cheers! Stefan [1] http://s11.postimg.org/haafx3eqr/spheretie1_vs_spherenontie1.png [2] http://s9.postimg.org/dxw78kfen/spheretie1.png [3] http://s30.postimg.org/n5t61o381/spherenontie1.png [4] http://s29.postimg.org/bttdystfr/spherenontie1_vs_spherenontie2.png [5] https://docs.google.com/file/d/0BzUvtJl1x3QBYndRZU1mbWJRMjQ/edit [6] http://s23.postimg.org/uijbwla1n/prep.png [7] http://s24.postimg.org/4zjmx6f2t/shot.png ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
