symek Posted July 17, 2006 Share Posted July 17, 2006 You did it again! :shocking: :notworthy: <--- emotional slope Quote Link to comment Share on other sites More sharing options...
Jason Posted July 17, 2006 Share Posted July 17, 2006 That image tells nothing but truth! Great work, Mario! About the diffuse probability - i'd hazard a guess and only factor in any of this if the glass is dirty/dusty/low-clarity. And in the case of low-clarity, you'd have to store photons at different depths in the glass, I'd think - and the more opaque is became you'd probably have to start rolling in a subsurface scattering model, right? Now that you've added Diffuse to the surface shader, perhaps you should support storing diffuse photons just for completeness' sake? Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted July 17, 2006 Author Share Posted July 17, 2006 About the diffuse probability - i'd hazard a guess and only factor in any of this if the glass is dirty/dusty/low-clarity. And in the case of low-clarity, you'd have to store photons at different depths in the glass, I'd think - and the more opaque is became you'd probably have to start rolling in a subsurface scattering model, right?Now that you've added Diffuse to the surface shader, perhaps you should support storing diffuse photons just for completeness' sake? Yes. I think you're right. Now that there is a diffuse model, I guess I've allowed for a non-zero diffuse probability. Actually, now that I think about it a little more, there's also the case of the number of reflection bounces not being set high enough (by the user) to allow for internal reflections to escape the glass, which would leave them on the inside surface and *should* be taken into account as contributing to irradiance... hmmm. On the usability side, I should also add probability scales (for diffuse,reflect,transmit) in the UI. Right now it's all driven by the optics specs (which is valid for the base values, I think) but it would be good to have a back door for the user to control this (similar to adjusting intensity... but different). I need to do a lot more testing on all of this. Photons are pretty new to me, and balancing all the sources of irradiance (traced, local illum, and photons) so that the result is "intuitive", will take some care (and more experimentation than what I managed to cram in yesterday). But I'm definitely having fun with photons! Quote Link to comment Share on other sites More sharing options...
Andz Posted July 18, 2006 Share Posted July 18, 2006 That image looks really nice. I thought that only physical based renderers were able to do that light dispersion. Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted July 18, 2006 Author Share Posted July 18, 2006 That image looks really nice. I thought that only physical based renderers were able to do that light dispersion. Well, I'm not sure about that, but if the renderer lets you shoot photons, then I imagine it can do it. By the way; a few comments/updates: 1. I've received confirmation that there is indeed no way (in H<=8.1) to get at the evaluation depth in a photon shader. It's been submitted as a bug, but I'm told it's fixed for H9 (did I mention I want H9 *now*? ) 2. I was scanning the code last night and came across a few bugs. I'll fix them as soon as I can, but just wanted to remind people that this shader is *not* finished yet... it hasn't been properly debugged or optimized yet (I'm just setting down the main algorithms and doing the basic research right now). So please don't go using it on anything important, *please*. When I'm confident it's working properly, I'll post it as "version 1". It's just that at the average rate of a few of hours a week, it's taking a while to get there 3. Something that's been bugging me to no end since I started exploring dispersion: the current implementation (in both shaders) is only correct for first transmission -- all secondary transmissions (when dispersing) are wrong. Why? Because there's no way to tell the secondary instances of the shader which wavelength we're supposed to be tracing/shooting. As a result, the shader uses the mean eta for all secondary transmissions, even when dispersing. Ray labels would solve this problem, but they're not there in VEX... yet... (did I mention I want H9 *now*?). Soooo.... anyhooo... one solution may be to cache the ray info (indexed by the ray's start position I suppose -- "P" or "Eye", depending on who's looking) using a shadeop. But this means maintaining and distributing dso's. Not a problem for my own uses, but I just don't realistically see myself updating windows and linux dso's for every point release... it just won't happen. The other possibility is to release it just in code form (which I would do anyway), and let everyone be responsible for their own re-compiling (and all that that entails). On the other hand, once the shader becomes dependent on a custom shadeop, it just simply won't work unless that shadeop exists, is up to date, etc; making the shader less portable, and less likely to get used. So... for all these reasons, I'm hesitant to go that route, but I'd like to hear people's opinions on this. And of course, if anyone can think of a clever (non-shadeop) workaround, I'm all ears! Cheers! Quote Link to comment Share on other sites More sharing options...
rjpieke Posted July 19, 2006 Share Posted July 19, 2006 all secondary transmissions (when dispersing) are wrong. Why? Because there's no way to tell the secondary instances of the shader which wavelength we're supposed to be tracing/shooting. As a result, the shader uses the mean eta for all secondary transmissions, even when dispersing.Ray labels would solve this problem, but they're not there in VEX... yet... (did I mention I want H9 *now*?). And of course, if anyone can think of a clever (non-shadeop) workaround, I'm all ears! Cheers! Crazy-ugly solution, but here goes: use the ray's depth/level and crank up the max trace depth. For example, if your wavelengths can be encoded as integers between 0-100, set your max trace depth to 100*DESIRED_DEPTH and mark your ray levels as 100*ACTUAL_LEVEL+WAVELENGTH. Then in your surface shader you can split up the result of raylevel(). Of course, this assumes Mantra doesn't have a low upper limit on the max ray depth you can specify, and it will totally screw up any scenes you have that use raytracing with shaders other than your glass shader Cheers! 1 Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted July 19, 2006 Author Share Posted July 19, 2006 Crazy-ugly solution, but here goes: <...> Rob!! Are you out of your friggin' mind??!!?? Just kidding! That's a very clever idea. Very twisted. I love it! Like you say, it's too bad about what it will do to other ray-tracing shaders in the scene... it's a good hack for something internal to the shop, but it may be a little too much damage for a publicly shared shader like this one. Wolfwood here came up with another good one: hijacking the ray weight. It also has the potential of screwing up other shaders that depend on it being accurate, but by far the majority of shaders don't use it. I just need to make sure that Mantra *itself* doesn't use it for clipping rays or something. But if it's just an user-controlled metric then we should be good to go... and to hell with other shaders! Muuuaaaaahhhahahahahaha!!! (at least until ray labels show up) Gentlemen: kudos to you both! :notworthy: You're both sneaky, and devious, and obviously very, very eeeeeevil! Cheers! Quote Link to comment Share on other sites More sharing options...
Jason Posted July 20, 2006 Share Posted July 20, 2006 Houdini 8.1.668: The getraylevel() vex function will now operate correctly in the photon shading context. -no need to get ugly, gentlemen- Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted July 20, 2006 Author Share Posted July 20, 2006 -no need to get ugly, gentlemen- YAY for SESI! Yeah, I got that message yesterday, and I was thinking of posting. So that's one down and one to go -- everybody be on the lookout for ray labels in 8.1! As far as hacking our way around the second problem, I think Rob's solution gets the "Most Creative Evil Genius" award, but I think I'm going to go with Jim's, just because it's a little more transparent -- there might still be cases where users suddenly find their favourite volume shader mysteriously breaking when they have glass in the scene... at which point we'll all just :whistling: But that bit of uglyness may dissappear in H9, who knows? Let's keep our fingers crossed! Cheers! Quote Link to comment Share on other sites More sharing options...
rjpieke Posted July 20, 2006 Share Posted July 20, 2006 I think I'm going to go with Jim's, just because it's a little more transparent Be sure to report back as to whether mucking around with the ray weight has any adverse effects or not Cheers! Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted July 20, 2006 Author Share Posted July 20, 2006 Be sure to report back as to whether mucking around with the ray weight has any adverse effects or not Will do! Haven't tried it yet, but I suspect that anything that calls getrayweight(), *and* depends on a "reasonable" value for solving, *and* happens to have hit our glass, *and* assuming I can't encode what will essentially be a [0,1] float so that it's still "reasonable" in most contexts, then that shader will likely produce unexpected results... Speaking of encoding, Rob, any ideas on embedding some "ID" value within the float so I can distinguish rays that were spawned from my glass vs. other ray-tracing shaders? First though I had was to have all the glass-generated ray-weights be something like POSITIVE_INTEGER_ID*10+WAVELENGTH_0TO1. Where POSITIVE_INTEGER_ID would have to be something evil like 666, natch! -- but would fail the "reasonable" category (for a ray weight). But, what about some marker that can still live in the 0-1 range? Possible? (without the fixed-point bit-magic available in C++, I mean). Quote Link to comment Share on other sites More sharing options...
rjpieke Posted July 20, 2006 Share Posted July 20, 2006 Speaking of encoding, Rob, any ideas on embedding some "ID" value within the float so I can distinguish rays that were spawned from my glass vs. other ray-tracing shaders? How about rayweight = 0.9876 + WAVELENGTH_0TO1 * 0.0001 ? Given the unlikely (ie 1 in 10000) chance that a random ray weight will start with 0.9876, it should be pretty safe. And, as an added bonus, doing this ensures that all your rays will have approximately the same weight, independent of wavelength. So even if Mantra does care about ray weight, all your rays here will have high and roughly equal (~0.988) weights. Cheers! Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted July 20, 2006 Author Share Posted July 20, 2006 How about rayweight = 0.9876 + WAVELENGTH_0TO1 * 0.0001 ? Nice! Yes, I think that will work -- we should still have at least four digits of accuracy left down there, right? Oh wait, did you mean that to be 0.00001 (one extra zero) for a [0,1] instead of [0,1) range (and a 9876 ID), or am I misinterpretting? Thank you! (I think there may be another award going your way ) Cheers! Quote Link to comment Share on other sites More sharing options...
rjpieke Posted July 20, 2006 Share Posted July 20, 2006 Oh wait, did you mean that to be 0.00001 (one extra zero) for a [0,1] instead of [0,1) range (and a 9876 ID), or am I misinterpretting? I'm assuming [0,1) range, since a [0,1] range gives us essentially zero benefit and costs us an entire digit. So if WAVELENGTH_0TO1=0.9 then we want to end up with 0.98769 which is 0.9876 + 0.9*0.0001 But that detail's really not too important. To be honest I just hit 0 a bunch of times and didn't really check to make sure I'd actually counted correctly And if you want more "resolution" for your wavelength, you can always trade-off part of the ID tag (ie, 0.987 + 0.001 * WL), albeit reducing the effectiveness of the tag. Cheers! Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted July 20, 2006 Author Share Posted July 20, 2006 I'm assuming [0,1) range, since a [0,1] range gives us essentially zero benefit and costs us an entire digit. So if WAVELENGTH_0TO1=0.9 then we want to end up with 0.98769 which is 0.9876 + 0.9*0.0001 Right. Of course. I just reacted to the digit count without thinking. And if you want more "resolution" for your wavelength, you can always trade-off part of the ID tag (ie, 0.987 + 0.001 * WL), albeit reducing the effectiveness of the tag. Now that I think of it a little more carefully, I'm pretty sure I can keep your original 4-digit-ID safely enough with plenty of accuracy. The granularity usually being used out there for a "detailed" spectral sampling is 5nm intervals (which in a visible range of ~400nm-700nm is just 60 samples), so heck, it might even be better to tag on a two-digit [0,99] integer at the bottom anyway... and probably still have room to add one or more digits to the ID to increase its uniqueness. Yup, this should work just fine. Thanks again, Rob! Cheers! Quote Link to comment Share on other sites More sharing options...
MADjestic Posted November 23, 2006 Share Posted November 23, 2006 Doh! Quick guess at 4 bounces: four sides to go through double shell (default is 1). Reflections are all there now. Does 'Ray Tracing Level of Detail' parameter control the number of bounces, or there's something I miss? btw, Mario - is there any hope for an update of your uber shader? And have you already implemented ray ID tags? Good luck to you and looking forward to oncoming candies. bbb Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted November 23, 2006 Author Share Posted November 23, 2006 Does 'Ray Tracing Level of Detail' parameter control the number of bounces, or there's something I miss? The "Level of Detail" parameter controls the geometric accuracy for ray tracing. For controlling the number of reflection bounces allowed for any given object you have to adjust the "Reflect Bounce" parameter. And similarly with the "Refract Bounce" for adjusting the maximum number of allowed refraction bounces. btw, Mario - is there any hope for an update of your uber shader? And have you already implemented ray ID tags? It's been too long, I know... my bad -- but since my last update, we got stupid-busy and it hasn't let up (and won't for a while yet). The end result is that by the time I get home my brain is simply dead... I'll try to make an effort though, since The Guilt is now reaching religious levels And yes, just before I left this, I implemented Rob's suggestions for encoding an ID tag in the ray weight and it was working just fine. Cheers! P.S: I guess I better get on with updating this before H9 makes it all obsolete P.P.S: One thing I *should* mention is that Andrew (Mantra developer) kindly pointed out an error in the custom Fresnel function I posted in this thread: the transmitted intensity, kt, should simply be set to (1-kr) -- I accidentally put in an IOR weighing that shouldn't be there at all. Thanks Andrew! Quote Link to comment Share on other sites More sharing options...
MADjestic Posted November 23, 2006 Share Posted November 23, 2006 For controlling the number of reflection bounces allowed for any given object you have to adjust the "Reflect Bounce" parameter. And similarly with the "Refract Bounce" for adjusting the maximum number of allowed refraction bounces. Hmm... still don't get it. Where are these parametes? Also oldschool mentioned that the number of bounces can be controlled for VEX Glass as well - or am I wrong? Is it in mantra controls somewhere? I assume that Glass_part4 is the last build, right? Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted November 23, 2006 Author Share Posted November 23, 2006 Hmm... still don't get it. Where are these parametes? Oh, I see. These controls are in the Render tab of every object (not part of the shader). So if you have an object named 'model', then look for them in "model>Render>Reflect Bounce", for example. Quote Link to comment Share on other sites More sharing options...
MADjestic Posted November 24, 2006 Share Posted November 24, 2006 Oh, I see. These controls are in the Render tab of every object (not part of the shader).So if you have an object named 'model', then look for them in "model>Render>Reflect Bounce", for example. Thanks, Mario. The moment you replied 'reflect/refract bounce' has magically appeared in Houdini Help... 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.