Jump to content

UV discontinuities from verts to points


stelvis

Recommended Posts

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

Link to comment
Share on other sites

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

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.

Link to comment
Share on other sites

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...

post-3889-1216139351_thumb.jpg

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

:)

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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)

post-3889-1216384099_thumb.jpg

Link to comment
Share on other sites

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:

post-148-1216402954_thumb.png

I can't say for certain if this is the "correct way of doing it" though... YMMV ;)

Link to comment
Share on other sites

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?

post-148-1216405739_thumb.png

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

post-3889-1216483956_thumb.jpg

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...