Jump to content

PMVC - positive mean value coordinates


sibarrick

Recommended Posts

  • Replies 44
  • Created
  • Last Reply

Top Posters In This Topic

Well just duplicated this myself on windows, I'm going to have to defer to Sesi on this one unless someone else can spot what is wrong.

I'm not sure why you would need to go to Windows to duplicate this since it's just a python bug in the code that should be cross platform. When you call addAttrib(), it determines the type of the attribute from the type of the default parameter you give it (ie. newAttDefault). In Python, the literal "0" is an integer, so newAttDefault is a list of integers, creating a integer attribute sparseAtt when you intended for it to be a float attribute. Changing it to newAttDefault.append(0.0) instead of newAttDefault.append(0) fixes the errors for me.

Link to comment
Share on other sites

For sure. I'll set something up.

I think next I'm going to try an HDK version of the deformer stage so I can compare performance. It gets a bit sluggish when the point numbers go up.

If I could get access to the weight attribute in vex it might be perfect for some multi-threading speed up.

Link to comment
Share on other sites

Here's a commercial example file. Its very simple but it shows a typical capture and deform setup. I'm still not 100% happy with the speed of the deform sop as a python sop, I definitely need to test an hdk version. Anyway this demonstrates the technique nicely. I guess if you did want to use this method you might consider animating a low res proxy version and only run the full res version through at render time. Its often the payoff, quick setup time = long cook times.

Be aware I made this in a beta of H10 so if you load it in H9.5 you might get a fair few warning messages, hopefully it will still work though.

PMVCexample1.hip.zip

Link to comment
Share on other sites

Added a threshold value, this can reduce the number of stored values at a cost of accuracy. In the attached I've tuned the previous file to a point where the accuracy cost is starting to show, however the number of stored weights is reduced enough to give a decent speed increase.

Neat idea, Simon.

In your estimation, how much of a speed increase do you reckon HDKing it'd give? Just looking at the marvellous simplicity of the python code, it makes me wonder.

Link to comment
Share on other sites

In my estimation I have absolutely no idea :lol: but that's why i'm interested, if it turns out that python runs at the same speed that would be both good and bad. Good cos it means where ever possible I would switch to python in the future and bad cos it means this method is probably too slow for practical uses outside of fairly low res stuff.

If I get around to it I can also compare it to a vex solution that would then give a neat 3 way comparison of all the possible methods.

Link to comment
Share on other sites

In my estimation I have absolutely no idea :lol: but that's why i'm interested, if it turns out that python runs at the same speed that would be both good and bad. Good cos it means where ever possible I would switch to python in the future and bad cos it means this method is probably too slow for practical uses outside of fairly low res stuff.

If I get around to it I can also compare it to a vex solution that would then give a neat 3 way comparison of all the possible methods.

Yeah, I'm wondering if I could use it on a midres or highres character...Feels a bit slow like you said.

I'll have the occasion to try it in a near future, I'll post my tests when I have some...

Link to comment
Share on other sites

Ok, so I finally tried this with the HDK and it totally blows away the python version

@Edward - I haven't tried the VM_Math stuff yet, I'm not sure it will work in this case as all I need is to sum a bunch of multiplies, I might come back to it though.

So the comparison is this

Python deformer node - cook time in the hip file attached to the last post - 301.77 ms

HDK deformer node - as above - 0.97 ms

I'd say HDK won that one hands down!

I've attached the source and a Mac (yes I'm developing on the mac now :) ) compiled version. PC version to follow at some point. Probably post it on Houdini Tools

Haven't tried VEX yet but I'm now very interested in how it compares to Python.

The math is pretty simple though, HDK in this case is approx. 300 times faster.

[edit] should have said the mac compile is H10.0.228

PMVCdeformerSource.zip

Edited by sibarrick
Link to comment
Share on other sites

Ok, this is getting very interesting now.

I've made a VEX version of the deformer and upped the point count in the captured geometry to ~10K points.

Here's the comparison

In reverse order....

Python node = 6 seconds

VEX node = 24.15 ms

and the winner is....

HDK node = 18.05 ms

So the VEX node is pretty damn close, and who knows with more cores it could end up winning. Couple that with the fact you don't need to compile it for new versions of Houdini and I'd have to say VEX is looking pretty good here.

The attached file is the one I used for testing (otl included) it has the HDK node in it too so ignore any errors produced by that node if you don't have it installed.

PMVCrelease2.zip

Link to comment
Share on other sites

Amazing results; and everyone loves VEX. It's not so build-sensitive, and VEX is editable:)

However, I'm a little disappointed in Pythons performance (assuming the slowdown is all python, not the PythonSOP connection)... but, as you say, great for rapid development.

Link to comment
Share on other sites

@Simon: VM_Math can be used for any of your regular math operations done in VEX. ie. array multiples mostly I guess.

I took a look at it but I thought I'd just be breaking the SIMD nature of it every loop as I have to traverse through the attributes using standard code so it wouldn't get much chance to do anything

	   FOR_ALL_GPOINTS(gdp, ppt)
	  {
		swCaptHandle.setElement(ppt);
		new_pos = UT_Vector3(0,0,0);
		for ( i = 0; i < swCaptHandle.entries(); i++ )
		{
			float weightPtn = swCaptHandle.getF(i);
			int ptn = SYSfloor(weightPtn);
			weight = weightPtn - ptn;
			if (weight)
			{
				pt = deform->points()( ptn );
				pos = pt->getPos();
				new_pos += pos*weight;
			}
		}

The only place I could see using it was

new_pos += pos*weight;

, or am I thinking about this all wrong.

I should have said I'm testing on a dual core proc, both hit around 80-90% when this is using the VEX version, when I get to work I can test on a quad core and I'm really hoping the VEX node can whip the HDK one.

Anyway here's another small update I've tweaked the capture process so it runs a bit quicker, its still not great. I realised there were 2 bottle necks.

1. The python node that processes the output from the ray sop.

2. The copy loop using an add sop to extract a point from the source geometry.

I've improved bottleneck 2 by using a vex sop to just move a single point to where I need it. But bottleneck 1 can only be resolved with an HDK sop so I'll try that and then probably end up publishing 2 versions, one HDK based and one VEX/Python based.

Does anyone know if the python nodes run compiled code or is it always interpreted?

PMVCrelease3.zip

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