ranxerox Posted December 21, 2012 Share Posted December 21, 2012 if I don't wire N from globals to output in either a vop sop or a vop pop, N gets recalculated. is this a bug ? thanks -G Quote Link to comment Share on other sites More sharing options...
Fabiano Berlim Posted December 21, 2012 Share Posted December 21, 2012 I don't have the same behavior in here. Which version are you using? Quote Link to comment Share on other sites More sharing options...
ranxerox Posted December 21, 2012 Author Share Posted December 21, 2012 12.0.661 in a vop pop on particles which are inheriting N, just multiply P by something set output point position. N gets set to 0,0,0. -G I don't have the same behavior in here. Which version are you using? Quote Link to comment Share on other sites More sharing options...
gaurav Posted December 21, 2012 Share Posted December 21, 2012 if I don't wire N from globals to output in either a vop sop or a vop pop, N gets recalculated. is this a bug ? I dont think its a bug. By default behaviour is to recompute point normals after point transformation. Atleast thats what happens in transform sop. I wonder the reason behind it ? Quote Link to comment Share on other sites More sharing options...
tjeeds Posted December 21, 2012 Share Posted December 21, 2012 (edited) This is correct behavior, it's only really noticeable when you're working with disconnected points/particles. You can either wire N through or use a Compute Normal vop to stop it. Think about the reverse of this, if you had a mesh and you changed P and it didn't recompute N, that'd be weird, right? It only does it to N which is, after all, the surface normal. You can always store your vector under a different name if this behavior is bothersome. Without a surface there is no N, feel me? Edited December 21, 2012 by tjeeds Quote Link to comment Share on other sites More sharing options...
anim Posted December 21, 2012 Share Posted December 21, 2012 well, it is difficult to say if it's more logical that N changes automatically with P change or not, since in houdini you usually want the later since if you want automatical normals you don't have to have any N attribute present, N is usually used for customised normals which you may want to have control over by yourself and don't want them to be overwritten just like that anyway this behaviour is handled by Compute Normal VOP as it was mentioned and it defaults to Re-Compute N if P changes, so knowing that, it's not a bug, it's just how it's set to work as default Quote Link to comment Share on other sites More sharing options...
ranxerox Posted December 21, 2012 Author Share Posted December 21, 2012 good to know. I would prefer if it didn't do this because it adds a level of inconsistency to vops (vops is so low level I wouldn't expect anything to automatically be set for me if I didn't set it). easy to work around, just caught me off guard. -G well, it is difficult to say if it's more logical that N changes automatically with P change or not, since in houdini you usually want the later since if you want automatical normals you don't have to have any N attribute present, N is usually used for customised normals which you may want to have control over by yourself and don't want them to be overwritten just like that anyway this behaviour is handled by Compute Normal VOP as it was mentioned and it defaults to Re-Compute N if P changes, so knowing that, it's not a bug, it's just how it's set to work as default 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.