On Oct 14, 2014, at 7:05 PM, Ștefan-Gabriel Mirea <mireastefangabr...@gmail.com> wrote:
>> #2 Eliminate rt_bot_mintie global altogether. Make rt_bot_prep() read the >> environment variable on-demand (which is called during rt_dirbuild()). Any >> user tools that expose a bot_mintie option (e.g., nirt, rt, and archer) will >> have to either have that removed (user must use env var) or they’ll have to >> get updated to putenv/setenv instead of setting a global. > > I'd like to try the second one, but I'm not sure if I fully understand > what you meant. Please correct me if I'm wrong: you propose two > options: Ștefan, you are correct! > 1) to completely remove any option regarding rt_bot_mintie from the > interface, such as File -> Preferences... -> rt_bot_mintie in Archer > or the -T flag and the bot_mintie command in nirt. Thereby this > parameter will only be available to advanced users through the > LIBRT_BOT_MINTIE environment variable. The merits of this approach are that it encourages a more simplified user interface but it’ll only be a good idea if we rarely want a user to manually turn TIE on or off (presumably we’d be debugging some problem and want to compare with non-TIE). It was mostly exposed as a user flag to simplify development so we could validate and perform comparisons against our traditional method, easily turning the new triangle engine on/off as needed. After validation and comparisons were completed (several years ago) the options remained because there is a limitation. Sometimes TIE prep is *much* slower than our traditional method. So slow that "old_prep+old_shot < tie_pre+tie_shot” … It turns out that tie_shot is very much superior to old_shot for most geometry, but tie_prep is nearly always even more slow than old_prep and that differential often dominates. The downside is that it’s more work and we may have to follow our deprecation policy to change user-visible options if they were documented somewhere. > 2) to let the interface as is and only get rid of the rt_bot_mintie > global variable and use LIBRT_BOT_MINTIE instead (setting it via > putenv/setenv). Basically, yes. Remove the global, but keep everything else intact. > In both cases, you suggest that any of those applications use the > fastest of the two methods (basically XGLUE(rt_bot_prep_, TRI_TYPE)() > versus bottie_prep_double()) by default. I don't really know how to > automatically check whick one would be faster :( Those applications are really just using the rt_bot_prep() interface and — in that function — a heuristic is calculated to estimate which one is better to use, TIE or traditional. An initial heuristic could be as simple as if #triangles >= MIN_TRIANGLES_FOR_TIE, run bottie_prep_double(), else rt_bot_prep_*(). A more involved one might entail creating a single triangle, running prep and running shot for TIE and traditional, and calculating an estimate for when one outperforms the other. Lots of possibilities. > Also, the variable significance is a little unclear to me: alongside > its declaration in librt/globals.c it is said to be the "minimum > number of bot for TIE". In nirt/nirt.c it is said that "0 means do not > use pieces, default is 4294967295". But, as far as I can see in > rt_bot_prep(), it looks to be the minimum number of faces that a BoT > should have in order to be precomputed with bottie_prep_double(). What > does it mean more exactly? Sounds like you might be mixing up two related but different variables. TIE attempts to spatially group triangles together, subdividing until each bin has that number of triangles or fewer. That is the rt_bot_mintie value. The traditional method uses a slightly different nomenclature, talking about “pieces” and referring to the minimum number of triangles required per simple subdivision. More clear? Clear as mud? Cheers! Sean ------------------------------------------------------------------------------ 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
