I know a lot of people use brute force these days.. But I’m still a massive fan of the irradiance map. With the right settings you can get a relatively crisp result, and no matter how fast cpus/gpus/bf gets, Imap is wonderfully efficient, especially when you do a lot of flythrough/static geometry animation stuff like I do.
Having seen the speedup in rt gpu when using the Lc for secondaries, I can only imagine how fast it would be with a precomputed imap too.
It seems totally feasible to render an entire flythrough animation on a couple of gpus in this case, especially when used in conjunction with the “store with imap” light setting.
I know vlado said it’s possible. I recon it would be an awesome upgrade.
The amount of posts asking to make feature X of V-Ray available in Vray-RT is amazing. If we take all of these and compile them, it is evident that what everyone one wants in the end is simple : ONE render engine, with similar features and seameless transition from CPU to GPU :
Well, I also want to wave a magic wand and make it happen, but it doesn’t work like that… so it has to go the slow and painful way where we do stuff bit by bit, and where we need to work on both render engines at the same time.
But, looking on the bright side, the GPU renderer has more features than V-Ray 1.0 had
Of course each feature of vray is important to somebody, and I’m sure the big brains at chaos will get closer and closer to feature parity.
However, I’d make the case that the irradiance map isn’t just “another feature” to be lumped in with requests for shaders and maps etc. The Imap is one of the defining features of vray, and if we are mentioning vray 1, one of the main reasons it ate Brazil, final render and mentalray for breakfast (and therefore why it is in its current leading position)
Now, despite the rise of computing power meaning brute force is finally practical for a lot of cases, I map still wipes the floor with it speedwise, especially when you consider multiframe incremental.
It’s addition to rt gpu would mean that for scenes with static geometry, rt gpu would have the same advantages over its current gpu competitors, that it did all those years ago when we first discovered we could use gi in animations when even pixar didn’t consider it practical.
Maybe a bit of an overblown response but Imap is great, and could speed up rt gpu hugely in suitable scenes.
Judging by the recent addition of light cache, I suspect it might be somewhere on “the list”.. I just hope it gets the recognition it deserves. It’s not just" a feature".
I agree,
If you force RT GPU using both LC for first and second bounce, you basically ditch the BF and my god, it’s blazing fast, nearly as fast as the view-port.
No seriously, it’s nothing comparable to the speed of BF, so if IR could make it at some point, fly-through will just be a coffee away…
ive got a lowly gtx 670 4gb.. and using the GPU benchmark scene, i got a time of 4m 20 seconds.
the titan z did the same scene in 1m 03 seconds, so 4.1x faster.
the same scene on my gpu, using a precomputed lc for both primary and secondary completed the 512 paths per pixel of the benchmark scene in 48 seconds.
using the multiplier of 4.1x
a titan z could render that benchmark scene in **11 seconds** using precomputed GI.
obviously there might be differences in overhead/ time using a precalculated imap for primaries instead of a crappy lightcache, but the argument still stands. RT GPU is *really* fast when it doesnt have to do BF gi.
i know you have to factor in the Imap calculation time here, but when doing a flythrough, with every 20th frame calculated, the imap calc is a very small part of the overall rendertime.
Oh yesss!
To win time (and efforts), even if it needs to be done through the normal production render and assigned in RT through MXS, that would be great!
quick update on my testing.. i used the rt gpu benchmark scene, and calculated a flythrough lightcache, on relatively (for a lightcache) high quality settings.. took 15 mins.
i then rendered out 100 frames at 720p, with a noise theshold of 0.003 and a passes per pixel of 1100. its still a bit noisy, particularly the wicker lamp in the foreground, BUT
it rendered in more or less 4 mins a frame ( ignore timestamp)
this means 100 frames rendered in under 7 hours.
that is damn fast for a single gtx 670.
expect under 1.5 hrs for 100 frames on a single titan Z (anyone wanna test it? i can upload the scene and lightcache)
obviously being lightcache, the GI looks crap. but should be a good indicator of the speed with a nice imap too.
single frame here:
100 frame test here (with youtube compression of course)
i did let it run to see how long it took to get completely clean, but it seems hard to shift the last bits of grain. im not sure if there are some adjustments i can make, ive barely used rt gpu before. i got to lets say 90% clean in about 15 mins. but the difference in noise between 10 and 20 mins seems negligible.
Just wondering if this is likely to happen any time soon? I’m costing up some rendering capacity and need to decide whether to lean towards cpu or gpu in my limited budget. Since I now have a 12gb gpu option, literally the only thing stopping me diving into gpu rendering in a big way is lack of precomputed gi options.. I very rarely need or want BF in my animations. It’s too slow, even with vray 3 and rt gpu. I can get faster rendertimes on a midrange workstation with imap .
I’m guessing it will be at least a couple of months - one of the developers is just starting to look into it. While it’s not terribly difficult to implement this, it will still take some time to code and debug.
Hi Vlado,
I know it’s been only 3 weeks but I just wanted to know if this has progressed of not.
Do you think we would have a chance to see any alpha stage into the nightly soon?
I’m just guessing it will not make it for the SP? :roll:
There is nothing that you can use yet, unfortunately. It’s too late for the next SP anyways, which has its fair share of GPU-related stuff that I’m hoping you’ll like.
