kingsoz Posted April 4, 2006 Share Posted April 4, 2006 hey there! i've just finished modelling an old LEGO model i have in Houdini, and now i've come to light the scene i've noticed some problems. Strange black patches appear on parts of my model, as you can see from the attachment. I am using clay shader on the model, but it appears with no shader at all. I am using 1 light with no shadows and the ambient occlusion shader assigned to it. is this because there is not enough detail in the model? i started a new scene with a box, ground plane, and ambient occlusion and the box has the same problem. to fix it i resampled the box so that it was much higher detail, and this fixed the problem, but there must be another way around this? any ideas? King Soz Quote Link to comment Share on other sites More sharing options...
stu Posted April 4, 2006 Share Posted April 4, 2006 I thnk that you're getting smooth shading where you want the edges to be hard. Try a facet SOP and either making the points unique or cusping the edges so that only the extreme angles of the geometry are shaded as sharp. Quote Link to comment Share on other sites More sharing options...
Jason Posted April 4, 2006 Share Posted April 4, 2006 Stu is totally right... and one more thing. The way the Mantra Clay shader is implemented has a bug in it, I think : it really can't handle surfaces where the surface faces away from the viewer - where you'd be thinking now "Duh, so what, Jason.. who cares about surfaces facing away from us??" - but in the case where you have a low-resolution surface with interpolated normals this happened A LOT. Try the lowest poly setting sphere, and render it. You'll see black artifacts on the polys on the horizon. Now turn up the poly resolution on the sphere and re-render and you'll see you've pushed the black wave back. The PrMan Oren-Nayar implementation (in the Advanced Renderman book) does not have this bug. It's very easy to implement in Mantra if you need it and you're OK with writing VEX. Or switch to Lambert. PS. Fun looking model - can't wait to see it rendered! Just Facet and Bevel away and you'll get better results. Quote Link to comment Share on other sites More sharing options...
kingsoz Posted April 4, 2006 Author Share Posted April 4, 2006 oooooooooo so coool!! thanks the facet thing really worked! ok, now i can spend a little time bevelling bits and pieces, i'll post more renders once i make them thanks again guys! King Soz Quote Link to comment Share on other sites More sharing options...
jjstanley Posted April 4, 2006 Share Posted April 4, 2006 The other thing I have found is to increase the Displace Bounds under the Render tab at the OBJ level. This does increase render times but fixes a lot of problems like that especially when using the VEX Super Material that has transparency. In this case I'm sure the Faceting was all you needed but keep the Displace Bounds in mind as you add more shaders later. Quote Link to comment Share on other sites More sharing options...
stevenong Posted April 5, 2006 Share Posted April 5, 2006 Displace Bounds is only necessary if the object has displacement shaders applied to it. A small value will not add a lot more to the render time but if you have 1000 frames to render or have a deadline to meet, that small value might add up more than you think. What kind of problems do you have when using the VEX Super Material with transparency? Please post a new thread as I don't want to hijack this. Cheers! steven Quote Link to comment Share on other sites More sharing options...
sibarrick Posted April 6, 2006 Share Posted April 6, 2006 Stu is totally right... and one more thing. The way the Mantra Clay shader is implemented has a bug in it, I think : it really can't handle surfaces where the surface faces away from the viewer - where you'd be thinking now "Duh, so what, Jason.. who cares about surfaces facing away from us??" - but in the case where you have a low-resolution surface with interpolated normals this happened A LOT. 26283[/snapback] have you ever come across this problem with VEX Specular too? I've just now hit it and switching to Blinn works fine but VEX Specular generates NANs all over the place. Its fine without a bump on it but even the tiniest displacement amount used to override nN in the Lighting model vop instantly causes all sorts of nasty black and white NANs (at least that's what they look like. VEX Specular Blinn Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted April 6, 2006 Share Posted April 6, 2006 have you ever come across this problem with VEX Specular too?I've just now hit it and switching to Blinn works fine but VEX Specular generates NANs all over the place. 26327[/snapback] Can't say I've seen that problem before -- I'll check it out when I get a chance. Judging by the way it looks, I'd guess that VEX's specular may use a shadowing/masking term, which could cause problems -- I'd find it hard to believe that it was coming from the distribution itself... will test... (have you checked for zero-length vectors/normals and such?) Oh, and BTW: Yes, the issue with VEX's Oren-Nayar has been around for some time. I think they probably don't want to change it at this point so as to not break old shaders... just guessing though. Quote Link to comment Share on other sites More sharing options...
sibarrick Posted April 6, 2006 Share Posted April 6, 2006 Can't say I've seen that problem before -- I'll check it out when I get a chance. Judging by the way it looks, I'd guess that VEX's specular may use a shadowing/masking term, which could cause problems -- I'd find it hard to believe that it was coming from the distribution itself... will test... (have you checked for zero-length vectors/normals and such?) 26338[/snapback] I've done all the checks I can think of, even added clamping (0,1) in the vex code before feeding it into the lighting model. It's a triangulated surface. There are no other attributes on the surface. if I set the bump to 0 it's ok. I'm using a hilow noise vop fed into a displace along normal vop and that feeds the lighting model with the perturb normal, nothin complicated. What really got me was changing to Blinn which is pretty similar in look and that fixed it right up. I also tried upping the shading quality and the displace bounds. On a slightly different but related note do the displace bounds get used when you are doing a bump using a displacement method to disturb the normal? As I understand it the point is temporarily displaced to calculate the true normal so in theory it might require increased bounds, though usually anything with such a big displacement won't look good as a bump anyway. Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted April 6, 2006 Share Posted April 6, 2006 Hmmm... I haven't been able to reproduce. Here's the test file I'm using: testSpec_1.zip the ROP 'mantra1' is set to run with the profiler turned on, and I don't see any NaN's showing up... On a slightly different but related note do the displace bounds get used when you are doing a bump using a displacement method to disturb the normal? 26340[/snapback] You shouldn't need to worry about displacement bounds if all you're doing is bumping. They only come into play when doing true displacements. ...I'll test it some more tomorrow... Quote Link to comment Share on other sites More sharing options...
Jason Posted April 6, 2006 Share Posted April 6, 2006 Oh, and BTW: Yes, the issue with VEX's Oren-Nayar has been around for some time. I think they probably don't want to change it at this point so as to not break old shaders... just guessing though. 26338[/snapback] .. dont want to FIX old shaders? Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted April 7, 2006 Share Posted April 7, 2006 .. dont want to FIX old shaders? 26342[/snapback] Heh... yes, well... that's another possible outcome Hey Simon: do you have a simple hipfile that shows the problem? (I can't seem to get specular to break). Quote Link to comment Share on other sites More sharing options...
sibarrick Posted April 8, 2006 Share Posted April 8, 2006 I'll see if I can put something together. I've now discovered that even with blinn I can get the occassional NaN so there must be something else at fault. It's no where near as bad and only happens on the edges, setting the bump amount to 0 fixes the problem in these cases. It's all very weird, I've done tons of similar stuff and this is the first time I've had this problem. I suspect the problem lies in the actual geometry and I need to test it on a sphere or something to see if I can reproduce it. If that still fails I post something up. You shouldn't need to worry about displacement bounds if all you're doing is bumping. They only come into play when doing true displacements. So how does the normal get calculated when you are doing this in the shader context? I thought I'd read in the Advanced Renderman book that the micropolygons are displaced and the normal calculated from the displaced geometry, because it's not a displcement shader the micropolygons are not actually moved in the final output but they are in order to find out the direction of the normal. If that is the case isn't it possible for the displacement to go out of bounds. If not how do they calculate the direction of the bumped normal? Quote Link to comment Share on other sites More sharing options...
sibarrick Posted April 10, 2006 Share Posted April 10, 2006 Well I've tracked down the problem, but it's left me even more confused. Basically I have two highlights on the surface, a tight one and a larger softer one. I then have an attribute on the surface that controls the amounts. When I turn off the tight one in the shader and delete the attribute all is fine, if I set the attribute to zero (which should be effectively the same thing) i still get NaNs. So currently I have just turned it off and deleted the attribute. Never seen anything like this before. The only thing I can think of is that somehow the interpolation of the attributes between points is screwing up and causing out of range values. But how that can happen when every point is set to 0 I have no idea. Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted April 10, 2006 Share Posted April 10, 2006 Well I've tracked down the problem, but it's left me even more confused.Basically I have two highlights on the surface, a tight one and a larger softer one. I then have an attribute on the surface that controls the amounts. 26404[/snapback] Interesting... I take it this attribute you're talking about is the specular "roughness"? I wonder what happens when some of these brdf parameters take on illegal values... e.g: roughness going negative... Quote Link to comment Share on other sites More sharing options...
sibarrick Posted April 10, 2006 Share Posted April 10, 2006 No not quite it's just a multipler that turns the effect on and off, I keep it zero or one then it's multiplied by the roughness in the shader. It just means that I don't have to keep tweaking attributes on the geometry i do that in the shader, all it does is just determines which bits of the model have the effect. It amounts to the same thing though. I just can't see how it can go negative when every single point is set to zero. Thats why I'm stratching my head. If I delete the attribute and set it on the shader to zero then it's fine.. very weird. Quote Link to comment Share on other sites More sharing options...
sibarrick Posted April 11, 2006 Share Posted April 11, 2006 Well I found a way to fix it, convert the whole thing to triangles. Still don't know what is going on though. I made a shader that just reads the offending attribute and it behaves itself perfectly, nothing going out of range as far as I can see, so it's a mystery but at least I have a solution. It's not ideal because the shading slightly changes when it's turned into trianges but it's ok. Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted April 11, 2006 Share Posted April 11, 2006 Well I found a way to fix it, convert the whole thing to triangles. 26442[/snapback] I'm glad to hear you got it fixed. I get the feeling that maybe the specular wasn't the culprit after all -- if you still have the broken version around, maybe try a different noise than the hi-lo one(?) -- you *know* all noises are eeeevil, right?. I come up against this type of problem quite a bit: something feels/is buggy, but you're time is running out and you gotta deliver, so you find a workaround and move on and leave the bug tracking for later -- or, more usually in my case, jump on the next job and don't report the bug at all... <sigh>... my bad. Just had a thought: if triangles fixes it, then maybe the bug is related to (shows up with) interpolated normals across quad patches (spread >= 180 deg across the patch)? 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.