George Hulm
George_Hulm
About Me
Artist with a node addiction.
EXPERTISE
Freelancer
INDUSTRY
Education | Gamedev | VR
Houdini Skills
ADVANCED
Procedural Modeling | Environments | Digital Assets
INTERMEDIATE
VEX | Python
Availability
I am available for Contract Work
My Tutorials
My Talks
Recent Forum Posts
APEX for Foliage Generation July 29, 2024, 6:12 a.m.
We're very much over the hump with Apex. Thanks to the kind folks at Sidefx that steered us in the right direction. We're seeing some very exciting results now and the advantages of working Apex are becoming clearer by the day!
The Speed, control and flexibility are all very impressive and in our case there are some exciting benefits that we'll be sharing as we get closer to showing off more of our work.
In the meantime here's an early preview of our apex "solver" in action. It's still missing important features, but the core framework is nearly there.
The Speed, control and flexibility are all very impressive and in our case there are some exciting benefits that we'll be sharing as we get closer to showing off more of our work.
In the meantime here's an early preview of our apex "solver" in action. It's still missing important features, but the core framework is nearly there.
graph::invoke and other apex questions July 17, 2024, 11:48 a.m.
Some more context thanks to the kind devs at sidefx who helped us learn how to do things correctly:
graph::templates that get invoked only need to be "setup" once and these can get invoked at any point using graph::invoke in apex.
graph::templates that get invoked only need to be "setup" once and these can get invoked at any point using graph::invoke in apex.
graph::invoke and other apex questions July 17, 2024, 6:17 a.m.
Really informative discussion thank you. Thanks to this conversation and others I think I have a fuller picture now, which I'll post here for others as well:
The implications of this are as follows:
Large numbers of VEX nodes are "dangerous" for performance, but only in the graph building step, due to the time it takes to compile a large number of snippets. In theory this issue can be resolved by using precompiled vex. Which we have done, with some caveats.
The only way we found to run compiled vex from within apex was to invoke a sops level compiled graph. This *works*, but sacrifices some runtime performance in order to speed up the graph building step dramatically. Run Snippet and AttribVop can not run compiled vex from disk.
If Apex attribvop and runvex were updated to run compiled vex, this would be the ideal result for high-performance systems that require high numbers of vex snippets.
I've attached an example and will submit an RFE
- The main cost of VEX compared to native sop verbs is during graph rebuilding, where the vex gets compiled
- During evaluation, Vex has no "hidden cost" compared to using sop verbs. The cost is due to marshalling data into geometry
- If VEX runs over a small amount of elements(eg <1024), then vex runs in single-threaded mode, which means the vex is likely slower than the equivalent operations in native apex at these element counts.
- There is a relatively high cost to invoking compiled sop graphs in apex
The implications of this are as follows:
Large numbers of VEX nodes are "dangerous" for performance, but only in the graph building step, due to the time it takes to compile a large number of snippets. In theory this issue can be resolved by using precompiled vex. Which we have done, with some caveats.
The only way we found to run compiled vex from within apex was to invoke a sops level compiled graph. This *works*, but sacrifices some runtime performance in order to speed up the graph building step dramatically. Run Snippet and AttribVop can not run compiled vex from disk.
If Apex attribvop and runvex were updated to run compiled vex, this would be the ideal result for high-performance systems that require high numbers of vex snippets.
I've attached an example and will submit an RFE