I also changed the algorithm to use as many images as one cares to use and automatically subdivide based on modeling and animation requirements, based on DASD feedback.
I changed the algorithm today based upon feedback and requirements asked for by DASD. First rule in my asymmetric thinking play book: why build one when you can have two (VEX, Python, Mathematica)? For example: Did you know Houdini can now do facial recognition dynamic scanning edge detection that runs off GPUs and then turn that into geometry? Here is an example of what Houdini can do now in the attached image that was originally drawn by hand, imported into Houdini and scanned using a new mathematica Houdini node. Houdini is excellent technology, I am making it better.
#VEGA GPU AND HOUDINI SIDEFX FULL#
Ndickson In a nutshell, getting *every*thing on the GPU would take an effort comparable to re-writing all of VEX … I completely agree, which is why we must take an asymmetric approach with Mathematica Kernels connected to Houdini to greatly increase Houdini's functionality toward the path of full automation and greatly increased performance and efficiency. I wouldn't predict that it's never going to happen, but it'd almost certainly have to be a very strict subset of current VEX functionality, which may be perfectly acceptable for some things.
#VEGA GPU AND HOUDINI SIDEFX CODE#
In a nutshell, getting *every*thing on the GPU would take an effort comparable to re-writing all of VEX and all of the code that it relies on, and the overhead due to sending all of the data needed may mean that it'd be worse off before it even began any real computation on the GPU. VEX has functions that queue up geometry modification operations to be done after the VEX part is done, so there'd be no possible benefit for those operations. VEX has functions that can find the closest point on a detail or send a ray into a detail, supporting most of Houdini's primitives, including NURBS surfaces, curves, metaballs, etc, meaning that all of that would need to be ported to the GPU. VEX has regular expression parsing functions, so you either need to ban them or port all of those to the GPU. As an example of a complication, in VEX, you can request parameter values from any node, or topology data from any SOP's geometry, meaning that if you want VEX on the GPU, either you need to ban those operations or send all of that data to the GPU, which would mean that it could be significantly slower than doing it on the CPU unless you're doing a ton of computation. Not to burst too many bubbles, but this seems a bit like “Toronto is a city, and Las Vegas is a city, so why not have a CN Tower in Las Vegas?” In concept, it may be possible, but it'd be a gigantic amount of work, probably way more work than the original, it'd have to be done from scratch, and it probably won't be worth it to go to Las Vegas just to see a copy of the CN Tower there you'd need to be able to do other stuff while you're there, else it'd be a huge disappointment.
0 kommentar(er)
