thekenny Posted March 16, 2009 Share Posted March 16, 2009 XP64, and I still get that bug with dev1007 I was on my Mac... -k Quote Link to comment Share on other sites More sharing options...
edward Posted March 16, 2009 Share Posted March 16, 2009 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. Quote Link to comment Share on other sites More sharing options...
sibarrick Posted March 16, 2009 Author Share Posted March 16, 2009 (edited) Ah! Cheers Edward. I should have noticed that, as I did the same thing originally in the capture node. Doh! No idea why it works on my mac then, maybe a version thing, I wrote it in H9.5.197. Here's a hopefully working version. dev1008.zip Edited March 16, 2009 by sibarrick Quote Link to comment Share on other sites More sharing options...
jrgauthier Posted March 16, 2009 Share Posted March 16, 2009 Ah! Cheers Edward. I should have noticed that, as I did the same thing originally in the capture node. Doh! No idea why it works on my mac then, maybe a version thing, I wrote it in H9.5.197. Here's a hopefully working version. Works nicely now! Quote Link to comment Share on other sites More sharing options...
sibarrick Posted March 17, 2009 Author Share Posted March 17, 2009 (edited) Commercial version in an otl. [Edit] Re-uploaded with help included. PMVC.otl Edited March 17, 2009 by sibarrick Quote Link to comment Share on other sites More sharing options...
jrgauthier Posted March 18, 2009 Share Posted March 18, 2009 Commercial version in an otl.[Edit] Re-uploaded with help included. WOW! thanks very much Simon, i<ll give it a try as soon as I got 3 seconds! well done! Quote Link to comment Share on other sites More sharing options...
Jason Posted March 18, 2009 Share Posted March 18, 2009 Commercial version in an otl.[Edit] Re-uploaded with help included. Cool stuff! PS. It might be useful to be post a little hipfile that uses the otl too, perhaps? Quote Link to comment Share on other sites More sharing options...
sibarrick Posted March 18, 2009 Author Share Posted March 18, 2009 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. Quote Link to comment Share on other sites More sharing options...
sibarrick Posted March 22, 2009 Author Share Posted March 22, 2009 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 Quote Link to comment Share on other sites More sharing options...
sibarrick Posted March 22, 2009 Author Share Posted March 22, 2009 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. PMVCrelease.zip Quote Link to comment Share on other sites More sharing options...
Jason Posted March 22, 2009 Share Posted March 22, 2009 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. Quote Link to comment Share on other sites More sharing options...
sibarrick Posted March 22, 2009 Author Share Posted March 22, 2009 In my estimation I have absolutely no idea 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. Quote Link to comment Share on other sites More sharing options...
jrgauthier Posted March 24, 2009 Share Posted March 24, 2009 In my estimation I have absolutely no idea 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... Quote Link to comment Share on other sites More sharing options...
edward Posted March 24, 2009 Share Posted March 24, 2009 If you do end trying out the C++ version, it would be an interesting idea to use the functions in VM_Math.h. Quote Link to comment Share on other sites More sharing options...
sibarrick Posted March 28, 2009 Author Share Posted March 28, 2009 (edited) 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 March 28, 2009 by sibarrick Quote Link to comment Share on other sites More sharing options...
sibarrick Posted March 28, 2009 Author Share Posted March 28, 2009 Windows H9.5.379 32 bit vc8 version PMVC_winHDKtest.zip Quote Link to comment Share on other sites More sharing options...
sibarrick Posted March 28, 2009 Author Share Posted March 28, 2009 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 Quote Link to comment Share on other sites More sharing options...
Jason Posted March 28, 2009 Share Posted March 28, 2009 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. Quote Link to comment Share on other sites More sharing options...
edward Posted March 29, 2009 Share Posted March 29, 2009 @Jason: I suppose one could use CVEX these days too although I'm not sure how to use it. @Simon: VM_Math can be used for any of your regular math operations done in VEX. ie. array multiples mostly I guess. Quote Link to comment Share on other sites More sharing options...
sibarrick Posted March 29, 2009 Author Share Posted March 29, 2009 @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 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.