stelvis Posted July 15, 2008 Share Posted July 15, 2008 Hi there I'm trying to replicate some displacement shading on a poly object in SOPs (point cloud stuff) to do this I'm promoting the vertex uv attribute to the objects points so I can pass this to a colour map VOP which in turn feeds a displace along normal VOP - this all works however in doing so any discontinuous UV's (ie UV map boundaries) get dropped - ie where a vertex had discontinuous UV values theres is now a single UV value and my UV seams are mangled can't seam to get around this - have tried splitting the polys then fusing after the UV attr promote but it it does the same thing on the fuse SOP any bright ideas? cheers Stu Aitken axis Quote Link to comment Share on other sites More sharing options...
SpencerL Posted July 15, 2008 Share Posted July 15, 2008 Hi thereI'm trying to replicate some displacement shading on a poly object in SOPs (point cloud stuff) to do this I'm promoting the vertex uv attribute to the objects points so I can pass this to a colour map VOP which in turn feeds a displace along normal VOP - this all works however in doing so any discontinuous UV's (ie UV map boundaries) get dropped - ie where a vertex had discontinuous UV values theres is now a single UV value and my UV seams are mangled can't seam to get around this - have tried splitting the polys then fusing after the UV attr promote but it it does the same thing on the fuse SOP any bright ideas? cheers Stu Aitken axis Not sure if I understand correctly, but I am assuming your uv seam which is, say, a value of "1" in uv space is closest to another seam which is, say, a value of "0". A point cloud gets values based on the point postion in World space, not UV space. So if you had a seam with a value of 0 and 1 closest to each other, your point cloud will get a value of 0.5ish which would be a completely different position probably causing the mangled up effect. Basically you need to make sure the points you are feeding your point cloud are in UV space in order for it to read correctly. Quote Link to comment Share on other sites More sharing options...
stelvis Posted July 15, 2008 Author Share Posted July 15, 2008 Not sure if I understand correctly, but I am assuming your uv seam which is, say, a value of "1" in uv space is closest to another seam which is, say, a value of "0". A point cloud gets values based on the point postion in World space, not UV space. So if you had a seam with a value of 0 and 1 closest to each other, your point cloud will get a value of 0.5ish which would be a completely different position probably causing the mangled up effect. Basically you need to make sure the points you are feeding your point cloud are in UV space in order for it to read correctly. umm not quite - forgget the point cloud thing I;m trying basically to get a texture mapped displacement onto actual geom to then use that to geta point cloud - I'm not suing UV's to create the point cloud in anyway I guess a simple picture tells a thousand words - see attached this is after a simple attr promote SOP if I don't do an attr promote (which simply promotes UV values from the object verts to its points - NOT a point cloud) then I can't seem to access the UV's insode a VOP SOP which I need to do the displacement... Quote Link to comment Share on other sites More sharing options...
stelvis Posted July 15, 2008 Author Share Posted July 15, 2008 umm not quite - forgget the point cloud thing I;m trying basically to get a texture mapped displacement onto actual geom to then use that to geta point cloud - I'm not suing UV's to create the point cloud in anyway I guess a simple picture tells a thousand words - see attached this is after a simple attr promote SOP if I don't do an attr promote (which simply promotes UV values from the object verts to its points - NOT a point cloud) then I can't seem to access the UV's insode a VOP SOP which I need to do the displacement... having a deeper look - this is what i think is going on: it appears as if each poly has its own set of verts which would obviously mean each poly can have its own UV values at the UV seams initially (since the UV coords are attached to the verts) however the points the verts are 'based on for want of a better term are the more usual "one point shared between multiple polys" (ie like vertices are in most other apps) ie if I promote the UV's from the verts to the underlying points as attributes then only one vertex (out of a possible 4 in most cases) is actually promoting its UV value to each point now in most cases thats fine since the majority of verts that are coincident with a single point have the same values - however at UV seams (ie 'discontinuities') the verts sharing a single point DON'T have the same values and thus the discontinuity which is vital the UV mapping disappears once these differences are lost so the question is - can I somehow store multiple UV values (ie 'discontinuities') per single point...this sounds doable if a little elaborate if I Can how would I pass these sensibly to the colour map VOP.... or is there someway for the VOP SOP to access the vertex UV values directly? Quote Link to comment Share on other sites More sharing options...
stelvis Posted July 15, 2008 Author Share Posted July 15, 2008 having a deeper look - this is what i think is going on:it appears as if each poly has its own set of verts which would obviously mean each poly can have its own UV values at the UV seams initially (since the UV coords are attached to the verts) however the points the verts are 'based on for want of a better term are the more usual "one point shared between multiple polys" (ie like vertices are in most other apps) ie if I promote the UV's from the verts to the underlying points as attributes then only one vertex (out of a possible 4 in most cases) is actually promoting its UV value to each point now in most cases thats fine since the majority of verts that are coincident with a single point have the same values - however at UV seams (ie 'discontinuities') the verts sharing a single point DON'T have the same values and thus the discontinuity which is vital the UV mapping disappears once these differences are lost so the question is - can I somehow store multiple UV values (ie 'discontinuities') per single point...this sounds doable if a little elaborate if I Can how would I pass these sensibly to the colour map VOP.... or is there someway for the VOP SOP to access the vertex UV values directly? aha ok problem solved switched sub division to occur before UV attr promotion rather than after changed the attr promote method to first match and the points get a single UV value which is ok - it was averaging the verts by default Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted July 15, 2008 Share Posted July 15, 2008 Have you tried doing the UV mapping directly to the point cloud? I imagine that would retain all characteristics of the mapping, including discontinuities, but avoids the problems you're getting from the dual representation (vert/point). VEX Sops can only work with points and point attributes (not vertices and vertex attributes). Quote Link to comment Share on other sites More sharing options...
stelvis Posted July 16, 2008 Author Share Posted July 16, 2008 Have you tried doing the UV mapping directly to the point cloud?I imagine that would retain all characteristics of the mapping, including discontinuities, but avoids the problems you're getting from the dual representation (vert/point). VEX Sops can only work with points and point attributes (not vertices and vertex attributes). no - that was next on my list to try though - procedurally that would be better anyway since there would be less points to displace I finally realised though that the discontinuities only affect a surface "between" the discontinuous UV's and not the points themselves, as long as I sub-divide the poly cage first and not after the promote attribute stuff which can't handle them fairly new to houdini and all this vertex/point/attribute promotion stuff still confuses me the reason for doing this was to get a PC for your multi SSS VOP BTW serge's axis 'chanlum style' one is cool but doesn't do quite what i think sss should do on skin for this particular character I had a few thoughts on the multi sss VOP that I would love to run by you sometime if your not too busy thanks for the the reply anyhoo cheers Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted July 16, 2008 Share Posted July 16, 2008 I had a few thoughts on the multi sss VOP that I would love to run by you sometime if your not too busy shoot. Quote Link to comment Share on other sites More sharing options...
stelvis Posted July 18, 2008 Author Share Posted July 18, 2008 shoot. cool - will do I need to do some more experiments first to make sure I'm not just talking out my arse though having some basic issues just getting the point cloud itterate VOP to work right now (pc filter works fine) - I'll resurface eventually after I've worked out what the secret, undocumented voodoo I have to do is, this time any hints here are welcome.. I can't get the obvious thing of just passing the pc open handle to the pciterate VOP then passing its output into a simple while loop (as suggested in the docs) to work - it never evaluates the while loop (or it hangs) and I don't know why - tried using pcunshaded instead but I really don't get what its trying to do differently (well I get the gist, just not the detail) either I have done the camera to object space transform on P before feeding it to the pcopen VOP (though if you and others hadn't posted that on this forum I never would have guessed that either) and using pc filter on the returned points handle works fine so its definately something I don't grasp yet about how the pc iterration VOPs work see attached if anyones interested in helping me out here (this was snapped beforeI did the space conversion BTW - apart from that I don't see why this doesn't work) Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted July 18, 2008 Share Posted July 18, 2008 I don't use VOPs that much so I'm not speaking from experience here -- just guessing. But I do know that pciterate() and pcunshaded() are not looping constructs. They keep an internal counter that updates every time they're called, and return zero when they finish visiting all the elements (i.e: when they've been called as many times as there are elements to be visited). In VEX, their basic usage would go somewhat like this: // Initialize some accumulator vector acc = 0; // Open pc file int handle = pcopen(...); // iterate if handle is valid if(handle>=0) { while(pciterate(handle)) { // per-point code -- here, we just update the accumulator acc += 1; } } Notice pciterate() is the condition for a while loop. So.. that's the basic structure you need to see when you do a "View VEX Code..." on your VOP network. I just did a skeleton test, and the following wiring seems to produce the correct structure: I can't say for certain if this is the "correct way of doing it" though... YMMV Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted July 18, 2008 Share Posted July 18, 2008 I take it back. The above will always go at least once through the loop regardless of the initial return value from pciterate (assuming a valid handle). This is due to the way in which the while condition is translated into temporary variables. To fix that, you need to put down two pciterates: one outside the while loop and another one inside. Add to that the If VOP to test for a valid handle, and you're now having to traverse three levels of nested VOPs just to look at four lines of code... ugh... did I mention I don't use VOPs much? Quote Link to comment Share on other sites More sharing options...
stelvis Posted July 19, 2008 Author Share Posted July 19, 2008 thanks mario I think this is broken personally... the docs explicitly state that you should only pass the handle to one pciterate or pcunshaded iterator and that this can simply be passed to a while loop this seems to work in VEX (ie while(pciterate(handle)) and admitedly the only docs are in the vex function ref - there is no vop help at allf or these going through hoops like this in terms of VOPs just seems - well wrong I noticed in your first example your instinct was to put the pciterate inside the while loop rather than just piping it staright into the condition for the while subnet as I had done can I ask why? ie the pciterate in VEX doesnt go inside the while loop - its just the condition and that works - theres doesn't seem to be a need to explicitly update it, it does that itself apparently each time its evaluated by the while statement...but apparently doing the ame thing in VOPs doesn't work... this is the code produced by the VOP net for the pciterate and while loop if you just pipe it into the condition input: // Code produced by: pciterate1 success = pciterate(handle); // Code produced by: test bound_test = isbound("test"); // Code produced by: while1 int _condition = success; vector _test = test; while( _condition != 0 ) { // Code produced by: while1/constant1 constant = { 0, 0.45, 0.9 }; // Code produced by: while1/suboutput1 _test = constant; } now apart from all the variable passing going on this seems pretty much like the vex code to me except that: success = pciterate(handle); while(success) { } may not evaluate the same way as: while(pciterate(handle)){ } as it seems that the value of success is not being updated...I guess leading to your attempts to call pciterate multiple times but this seems like it won't work from the docs (ie the iteration mechanism can only deal with one pciterate call) I'll give it ago anyway thinking maybe I should just give up on this in VOPs, and accept I have to use Vex still - seems weird that there is a provided VOP node that is pretty much useless Quote Link to comment Share on other sites More sharing options...
stelvis Posted July 19, 2008 Author Share Posted July 19, 2008 ahh ok seemingly the following works - ie you do need to call pciterate again inside the while loop to update it properly not sure this agrees with Vex function reference docs though (ie only pass a handle to one pciterate call) and I guess I'll need to test that doing it twice doesn't cause any issues Quote Link to comment Share on other sites More sharing options...
edward Posted July 19, 2008 Share Posted July 19, 2008 I think they meant one call to pciterate per iteration? Quote Link to comment Share on other sites More sharing options...
stelvis Posted July 20, 2008 Author Share Posted July 20, 2008 I think they meant one call to pciterate per iteration? indeed and it looks like this is actually what happens here as the vop "variable passing" means that it doesn't get called again anyway wired into the while condition input Quote Link to comment Share on other sites More sharing options...
stelvis Posted July 20, 2008 Author Share Posted July 20, 2008 shoot. see SSS diary thread 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.