matching BF with imap

[super gnu]

if i want a perfect per-pixel result with imap, i set the min and max to 0,0, but it takes waay longer than BF in this case.

i want the same "no fuss" setting, at a similar speed to BF, but with the advantages of caching and multiframe incremental for flythroughs.

what is the best way to disable all the interpolation and other features of the imap so it matches BF for speed and quality?

i guess, min max at 0, thresholds all at 0, delaunay triangulation(?) and interpolation samples all at 0?

i need to play more with this, but it could be a good compromise between bf and standard imap setup..

[super gnu]

hm well my proposed settings dont work at all!

with min and max at 0, thresholds at 0, interpolation at 1 sample, and delone triangulation, the imap calculates as expected, but the render is incredibly slow (i stopped it after a few buckets) very grainy and dark.

on a related note, i retested with imap at default apart from 0,0 min and max, and in this scene ( the rt gpu benchmark scene) its actually comparable in speed to a bf render, but there is low frequency noise in the result. id imagine since its doing a minimum rate of 0, all noise should be on the pixel scale..?

[Rens]

And if you set the preset to very high for calculation and when rendering lower the interpolation samples to around 5 or so? The interpolation samples make it 'blurry' as it interpolates for speed, but I'd image you need at least some.

[super gnu]

i dont know.. id have imagined if you set the min and max to 0, you are essentially telling vray to do per-pixel gi AKA BF. so in that case id imagine interpolation would be undesirable/unnecessary, as all the noise should be on the pixel scale, i.e. grain, controllable with the subdivs setting.

obviously im missing something.. im doing a few more tests.

[Neilg]

telling vray to do per-pixel gi AKA BF.

bf was built to work like that, ir map wasnt - there's no way you'll trick the IR map into scattering samples smaller than a pixel and have it be just as fast as BF. it's going to take 10x longer if you ever get it to send enough samples so they'll clear up.
You can do a prepass with the IR/LC on the settings it works best with, then load the map and have bf as the secondary (faster than bf, benefits of cache).
or use something like detail enhancement with a faster ir map, which is brute force, but only in the areas it thinks it needs (faster than pure bf, with cache)

[super gnu]

youre probably right... ive tried a few combinations of settings, and i always seem to get a noisier result with imap than bf for the same rendertime. in fact the only way ive been able to reduce the noise until its basically grain is to use a min and max of 1, rather than 0. To be honest im not sure whether a min and max of 0 or 1 is more like the BF calc.

wrt using imap/lc then swapping to bf for secondaries, i dont understand what this achieves? the secondaries are only needed for the calculation stage of the imap, unless you are using "lc for glossy rays" with the lc.

and speaking of detail enhancement ive never got on very well with it... i prefer a more detailed imap every time.

really, the only reason i was doing these little experiments was to see if its possible to get the imap to behave in a totally stable way, like BF, with no shimmering or blotchies for animated geometry, and just the subdivs to worry about, and with the added benefit of the cacheability of imap.