Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won


Serg last won the day on October 23 2015

Serg had the most liked content!

Community Reputation

29 Excellent

About Serg

  • Rank

Personal Information

  • Name
    Sergio Caires
  • Location
  1. Hey guys, too busy to reply with details now, but I will do later! Thanks S
  2. Irradiance caching

    Found Dennis Albus thread on ray switch labels (awesome! been trying to figure that out...) so I'll try and use that to improve the results when I get more time... I hope it allows the bsdf components to remain combined rather than editing all shaders and layer blending tools to handle separated bsdfs... and also hoping it might fix the noisy reflections. Ideally I want reflections to behave as the gilight does in reflections (and what my old gather based system did), in that reflections are reflecting diffuse tracing against the cache, whereas currently the irr cache completely replaces all diffuse in reflections of cached objects at all ray levels, which is the same result in reflections as when "point cloud mode" is On with the gilight. The difference between pcm and irr cache is that the irr cache is far cleaner so these reflections are far less objectionable (see post #3 renders). Cheers! S
  3. Irradiance caching

    Done. I rendered with sample lock On so we can clearly see how the caching methods differ. Its surprising how the photon cache strobe is not as visible in the beauty as the direct photon render would suggest. It looks like the photons that hit the wall directly stay stable, but of course the ones that hit the statue swim all over. Wonder if its still forgiving if the light moves... The irr cached render is rock solid though, and now at 1 minute per view dependant cache frame (with RHF filter) its starting to look really compelling. Solved the weird reflection on the right wall by setting min reflect ratio to 0.5, but its pretty clear that the hack confuses the path tracer, it looks as though the indirect rays are playing russian roulette with diffuse rays that aren't there, and this is still visible on the floor reflections. Mantra is same settings as photon cache render except for min refl ratio, but its still clear to see that the noise levels are lower because the irr cache is far more coherent than a photon cache. The funny thing with photons is that as the photon count increases blotching becomes less of a problem but variance gets worse, because they are getting smaller in radius and so harder to hit coherently ray after ray. I think there is a very good case for irr caching in Houdini... But like I said before, it needs sideFX to make it work proper and hassle free irrcacheVSphotons_001.mov irrcache_v008.hip
  4. Irradiance caching

    That will be an interesting comparison... I suspect any movement on the Buddha catching the light will move those photons around and cause low frequency strobe on contact points and dark areas they find hard to reach, lets see. Probably much less likely to happen with image based caches and sample lock On. I suppose I could try the ray histogram filter stuff on this... or even clean it up in post, NeatVideo does a wonderful job. Maybe we can even get away with rendering the view dependant cache at half FPS and re-time it in post! There might be some weirdness if I animate Buddha on the right to come into frame (global cache to view cache transition). Other things to try... distance threshold. I've got a bsdf occlusion node which is an indirect lighting vop hacked to gather occlusion attenuated by distance (normally used for my version of attenuation) that I could use to mix brute force PBR back in corners/contacts, rather than switch it off entirely for ray level > 0.
  5. Irradiance caching

    Cheers! One more test, with happy Buddha's yay! The only thing that got cached was the walls. Goes to show you don't have to cache everything... The Buddha's still get the benefit Indirect contribution from them shows up in the regular aov's while light from room ends up in emission. I also setup a hybrid of global GI cache + view dependant cache. The view dependant cache is just a half res render from camera where every object but the room is phantom and specular rays disabled. Fresnel is view dependant so there is less diffuse energy in the room than there should be (there is ways around it like a baking mode in the shader where Fresnel is Off)... Everything inside the frame that is not occluded from camera (a self shadow test) is using the view dependant cache, everything outside the frame or occluded is using the global cache. The view dependant cache has the potential to provide vast coverage with a cache detail level auto appropriate for the distance. The point of it is mainly to deal with animated stuff in frame efficiently with the option of a view dependant cache per frame, and a static frame for global. Gain and Gamma was adjusted until it roughly matches the brightness of Photon cache render. I turned up the settings until quality >= patience limit, pretty good for 8m14s + 4m for both caches (cache time could be much less if blurry reflections). This was 6x6 2min 9max 0.0025 noise level (var aa still struggles with dark transitions). Think pbr would still be chewing the first 16 buckets after this finished and no where near these noise levels. Something weird with the reflection on the right wall though. Photon cache does really well 5m53 with same mantra settings. 10million were fired, there were some odd glows/blotches with 1million but not that big a difference. Quality wise pretty similar for the time spent, I call it about even, irr cache took longer but its cleaner over big areas (less variance in irr cache). More photon caching glitches... think turning off prefilter photons then re-rendering photons breaks it (black) and seems to stay stuck black, after a while of trying to get it back (on/offs, different file paths, etc) it somehow comes back. irrcache_v006.hip
  6. Irradiance caching

    More craziness. This time I'm keeping the F components separate so I'm not terminating reflection rays (you'll see what I mean if you look at the hip). I also set the reflect limit to 10 (previously 1) and rough to zero (to see reflect bounces clearly), and I turned Adaptive sampling Off because it makes this scene more noisy rather than less. Interesting results... in that the beauty render time difference is bigger than before, at 6.4x faster than brute fore PBR and better noise quality than even Photon caching. Photons take a hell of a lot less time to cache than any way other way I can think of to bake lighting. ptex baking looks to not be viable at all for high polygon counts objects ... takes an age on something like the happy budha scan (640k poly)... pcwrite from an offset camera would be good but it's currently saying no to baking anything coming out of pbrlighting. Photon cache is a very practical solution but it looks much brighter. It would seems either PBR or Photon cache is wrong, but there's probably more to it... With Gi Light in point cloud mode the brightness is also too bright, the blotchy photons are clearly visible in reflections and light leaks at corners. photon caching is glitchy though, one minute its working, the next it doesnt, and then it works again... irrcache_v005.hip
  7. Irradiance caching

    btw one of the numerous gotchas, is that all indirect light comes out in the emission aov And yeah I think its probably a bug that emission is getting indirect bounces... this may not work for long
  8. I replied here with something that may or may not help you: http://forums.odforce.net/topic/24137-irradiance-caching/
  9. HACK ALERT!! In reply to comments on the BSDF bonanza thread. You can use a very very simple hack to trick the pathtracer to use an irradiance cache, of sorts... In the past I've done a lot of point cloud baking for this purpose, in combination with a lot of other `indirect light` vop hackery, in order to do stuff like the gi light distance threshold... which works, but by using the indirect light vop (deprecated stuff) hacks made rendering much slower when more than 1 bounce was needed and irr cache was not in use... and sometimes the pcwriting would randomly skip objects for reasons I never got to the bottom of. In this case I'm using ptex baking (H15), but I suppose it could be anything... Since the ggx thread post was made I had what currently seems to be a much better/simpler idea than how I did it before, without any real modification to the pathtracer. Basically the hack is, plug the ptex bake into Ce and zero F on indirect rays (not the pbrlighting input)... despite zero'ing indirect rays Ce is magically looked upon by erm, indirect rays... But of course there are lots of practical implications and associated further hackery... Need to wedge bake entire scene (though it could maybe be selective, like just the caching the walls) auto filling in the shaders cache file path Just discovered baking doesn't work on packed geo!! Don't want to be killing indirect reflection beyond the first bounce. This leads to needing pre multiplied separate F components until they arrive in compute lighting, which in turn means making your own shader struct and all the layer blending tools that go with that. OR (I really really hope someone knows how to do this and shares it here), make a is_diffuse/reflection/refraction/etc ray vop. I have a hunch that the best way to do irrcaching in general might be to voxelize the scene... not only because it would provide a cache for shading as we are doing here, but also because we (meaning sideFX or other brainy people) could then start looking at things like cone tracing (like nvidia is doing for realtime gi). But the best thing would be (really dreaming here) that it would remove geometry complexity from the problem of raytracing... Basically the voxels would become a geo LOD, so if the cone angle is big and the distance is bigger than say 2 or 3 voxels then it would do all that expensive ray intersection stuff against the level set instead... forests, displacements, bazzillion polys, reduced down to voxels. I think this might work because I've been doing this in essence for years, but limited to hair... by hiding hair from all ray scopes and using a volume representation to attenuate/shadow direct/indirect light reaching the hair (nice soft sss looking results). But! I hear some say it will be blurry etc, because the volume lacks definition, so there is also a simple illum loop to trace `near` shadows and so add some texture/definition back in... fast... even compared to today's much faster hair rendering in mantra, and arguably better looking (the sss/attenuation effect esp if the volume shader casts colour attenuated shadows), but there is the hassle of generating the volumes even if automated as much as it can without sesi intervention. 1m11s for cached, 2m26s for regular. This is using the principled shader. Btw a test on this simple scene looks like the GI light works (here!), but it is way way way brighter than brute force PBR, and yeah also had grief with the gilight, sometimes not writing the actual file... irrcache_v003.hip
  10. eetu's lab

    AWESOME stuff Eetu This is easily one of the best cg threads ever
  11. Not using Stylesheets here (have something else), but the point is that unless you set the property "Declare Materials" in Mantra/Rendering/Render tab to Save all Shops, then mantra cant see any packed prim materials.
  12. Actually 1 min ray in the above instance looks ok in shadows, as long as the pbr.h hack is in place. Saves another 2 min for 16m20s. Doing some more testing with the pbr.h hack. I think I'm convincing myself its always better than not, but more so when the scene has dark areas... Would be good to get a confirmation/second opinion. I also upped the lights intensity by 2 stops, to see if a simple overall brightness increase increases render times It does. Looking at the indirect samples map (without the hack) it is obvious that most of the image becomes clamped to max samples. Without the hack and 2 stops less bright like before, its the opposite, a lot of the image is clamped to min samples. So, at half res for speed and 2 stops up. With the hack (1min10max 0.0025 direct, 1m40max 0.005 indirect), it takes 5m11s. To get ~comparable quality without the hack it has to have the noise level halved (1min10max 0.00125 direct, 1m40max 0.0025 indirect). It takes 5m34s. Very interesting to look at the indirect_samples aov comparison. Some areas pop up in sample count that were previously dark, while large expanses that have less noise got less samples. In other words I'm getting more samples where its needed and less where it isnt. Variance aa out of the box looks more like a remapped luminance map whereas with the hack it looks more variance related.
  13. No variance AA. Decouple Indirect On 10 min rays on direct lighting 40 min rays on indirect lighting. Took 25m22s Shadows are much better, some areas are over/under sampled compared to var aa render. But imo I think I got more than the 4 minute difference back... + no time spent fiddling noise levels... Decouple Indirect is great. IMO the best balance of time/quality is to not rely too much on var aa, so: Var aa back On 5min10max direct, 20min40max indirect The result took 18m28s. and its less noisy than the first 21m21s render with 1min100max. I find more often than not that var aa is best for adding polish... 1 min rays at any meaningful noise level is hopeful... any time I try that I get chewed shadows, esp without the hack. 1 min is only the best approach if your perception of the noise matches what var aa is catching. Perhaps a easier general strategy is to set decoupled min/max rays to ~40 until quality good, then use min rays to reduce quality until unbearable...
  14. But yeah, just set 40min rays to get rid of the crunchy shadows altogether. It doesn't appear to be possible to get rid of it while using var aa efficiently. looks like odforce is re-compressing and scaling jpg's?... trying png...
  15. At 1080p, the hack + settings produced this result in 21m21s. On a i7 4930K @ 4.3Ghz