Jason

They're on the same page, I think -- did you see this:

Hi, Try a very new build -- there were some updates to Windows which caused some issues with TBB and such. I saw this come and go on the SideFX forum. Try the Daily Build.

Also, when you printf() in VEX, you're forcing output to happen. VEX is usually very good at detecting uniform vs varying variables and executing thing the minimum number of times. However, there are some specific optimizations you can use -- check out texprintf().

Congratulations, SideFX -- and a priceless still frame! Best of luck for the future and keep innovating!

Oh you want to do this directly in the viewport? I was hoping Render COP pointing to a OpenGL ROP would let you grab the viewport, or failing that some kind of python function to yank the GeometryViewport and then do your thresholding and use that to scatter colored points on the viewing plane - your sprites. Sadly the very first step doesn't support opengl rendering directly into COPs, and I can't find an appropriate python function. What speeds are you looking at wanting? Realtime? If so you might be in HDK Viewport Render Hook territory.

Isn't that cool?!!

Looks interesting; I'll give it a try. Thanks for sharing, Jason

hou.hda.installFile() http://www.sidefx.com/docs/houdini/hom/hou/hda.html

Or get to know the Point Replicate SOP!

That's a new one on me

Hi, Good luck with your toolset! I've written a RAT converters a few times over the years, and I'll make just one suggestion -- using the multiprocessing module and perform 5-10 conversions simultaneously in a multiprocessing pool. Super easy to add and improves the turnaround time immensely.

I would imagine this is not very applicable to VEX, really because it's executed in SIMD fashion -- ie. Single Instruction Multiple Data -- which basically means that data isn't laid out in single data units as it appears in the code, but instead are each large uniform arrays in memory, loaded with data from the entities it's processing (eg. points, prims, etc). These arrays are dense and chewed through in a processor-pipeline-friendly fashion. If you look at the runVex() HOM command you can see how you need to provide arrays of data.

This is definitely a masterful release - bringing lots of great new functionality. Thanks, SideFX!

Interesting, I didn't know that. Perhaps SideFX would have some insight if you wanted to solve this puzzle. FWIW, we have implemented our own URI handlers pointed at our asset system using that class. It can be very intuitive if done right.

It looks really good -- does it exist on Orbolt, and for H16?