sibarrick Posted December 22, 2005 Share Posted December 22, 2005 Ok since Jason posted those stats about the new speed of occlusion in H8 I thought I'd give it a try. I slung together this quick test file, and bingo it doesn't work. It seems so simple and I can't see why it's broken. The occlusion returned is always 0,0,0 test.zip Second question, why doesn't the occlusion Vop not have any inputs for environment map and obj? Quote Link to comment Share on other sites More sharing options...
sibarrick Posted December 22, 2005 Author Share Posted December 22, 2005 Ok, the help lies, if you don't specify a distance it doesn't send rays to infinity it sends them nowhere... Second question still stands Quote Link to comment Share on other sites More sharing options...
sibarrick Posted December 22, 2005 Author Share Posted December 22, 2005 Ok, the help doesn't lie, I just set it up wrong, if you don't attach a parameter to dist then all is happy. Second question still stands Quote Link to comment Share on other sites More sharing options...
Jason Posted December 22, 2005 Share Posted December 22, 2005 Ok, the help doesn't lie, I just set it up wrong, if you don't attach a parameter to dist then all is happy.Second question still stands 23401[/snapback] The occlusion VOP is very incomplete actually - there are a number of (even undocumented!) variadic arguments it can accept along with "environment" and such that just aren't supported nicely. Sadly SESI haven't been terribly good about pumping up VOPs since they arrived... PS. I had tremendous success with the "Render From File (Bounded)" setup in conjunction with any of the raytracing tools. I realize that the raytracing acceleration scheme in Mantra is far faster than an simple bbox check but the whole thing just goes so smoothly and used less RAM for the longest time. Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted December 22, 2005 Share Posted December 22, 2005 Hi Simon, Yeah, what Jason said. Also, in case you're not aware of this, there are two different forms of the occlusion call: one gives you occluded irradiance, and the other one visibility plus bent normal. The only one exposed by the OcclusionVOP is the irradiance one -- which, incidentally, is the only one that uses the environment-related arguments. Given that the version available through VOPs *does* support environments (map, xform_object, filter:type:width, etc), you'd think that all these parameters should be available in the VOP.... and you would be right! Of course, the other great omission is that the other version of the function is not even available in VOP form... I added a quick inline to let you flip between the two versions (though I didn't add filter controls to the irradiance version... too lazy, sorry ) test1.zip Oh. I almost forgot. If you want "maxdist" to be "infinite" then you can set its value to -1 (or to a very large positive number, of course) . This would be familiar to RSL users, but I think it was a recent modification in Mantra -- I do that in the inline so you can see it. Quote Link to comment Share on other sites More sharing options...
Jason Posted December 22, 2005 Share Posted December 22, 2005 Thanks Mario, As usual, nothing but the highest quality info from you! The link to the "optional rendering parameters" on the Occlusion and Irradiance VEX and VOPs pages is not linked up right in the Houdini documentation, but here is a list of the available options. Houdini Docs, Optional Rendering In particular you might be interested in the "angle" option to specify a sampling cone. Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted December 22, 2005 Share Posted December 22, 2005 As usual, nothing but the highest quality info from you! 23418[/snapback] Thanks. Likewise Ah - forgot to include the angle option. Yup, that one can be useful for speeding up things in certain cases. BTW; an interesting exercise: Pick the visibility version of the function (the cheaper one) and render Simon's scene with "Polys As Subdiv Surfaces"... I think the new performance boost is mostly related to polys -- not very noticeable on other surface types, though I've yet to do H7-vs-H8 timings on SubD/NURBs... Quote Link to comment Share on other sites More sharing options...
Jason Posted December 22, 2005 Share Posted December 22, 2005 BTW; an interesting exercise: Pick the visibility version of the function (the cheaper one) and render Simon's scene with "Polys As Subdiv Surfaces"...I think the new performance boost is mostly related to polys -- not very noticeable on other surface types, though I've yet to do H7-vs-H8 timings on SubD/NURBs... 23419[/snapback] Me neither.. I can imagine its not quite so easy to divide up subd's into nice little BSP nodes as you can with Polys for larger scenes. On a scene of this size I suppose the speed of the intersection algorithm must be the most important factor, probably. VOP-wise, I think SESI kinda shot themselves in the foot by not implementing a good solid VOP for it. I'm sure they're loathe to change it now in fear of breaking compatibility. On another note, how did your R&D with the Nvidia Ambient Occlusion paper implementation end up? Did you get good results? Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted December 22, 2005 Share Posted December 22, 2005 VOP-wise, I think SESI kinda shot themselves in the foot by not implementing a good solid VOP for it. I'm sure they're loathe to change it now in fear of breaking compatibility. 23420[/snapback] Maybe... though I don't see how adding (as opposed to changing) inputs (plus a toggle that defaults to the old behaviour) would break compatibility. Ditto for the extra "Nbent" output... but maybe I'm missing something -- easy enough to test though. On another note, how did your R&D with the Nvidia Ambient Occlusion paper implementation end up? Did you get good results? 23420[/snapback] Haven't yet taken it much further than "proof-of-concept" (production has kept me from it), but we used it for one job even in that primitive state, and it performed very well (with deforming geometry). Good news is that the enhancements needed to turn it into a more robust production tool are quite clear -- it's just a matter of time... Right now, it works best on dense geometry because it uses incoming points as occluding elements -- much like your CAD car model (which incidentally, is exactly the type of geometry it was used on). Extending it to sparce geometry (and non-poly types) is doable, just needs some time -- the use of which is currently competing between this fast GI thing, wavelet noise, extending our shading library, and about a hundred other things I want/need to do Quote Link to comment Share on other sites More sharing options...
sibarrick Posted December 23, 2005 Author Share Posted December 23, 2005 Cheers for all the info guys! I'm definately going to try this out on a heavy scene and see how it handles. Sounds like converting to polys is a must for real speed, and the render from file with bounding is a good thing to know. Cheers! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.