I’ve watched the keynote. the stuff that SideFX is able to put into ONE release is mind boggling! I honestly have never seen any company that is able to release so much after a year.

Either way, still struggling a bit with the APEX… So it’s not SOPs graph and it’s not VOPs… so what is it? What is it allowing one to do that was not possible to do before?

What application does it have beyond rigging?

Will it over time replace SOP context and VOPs? Why did we need another graph lol.

Thank you!

What i know it is SOP 2.0.
It abstracts the operator function from the parameter.
The node network is build dynamicly and gets compiled.

I currently don't know if the data has it's own stream. With this concept it looks like all data from: point, vertex, prims, detail, (parameters and the node network) will have the same data structure (json).

I hope there will be a unify API that is simplyfied for Python, VEX, OpenCL.

APEX is sort of a "mid level" graph in between SOPs and VOPs. From the TD perspective, it's like VOPs except that you can manipulate geometry as data that flows through the graph along side with small data types like vectors, floats, and matrices. Unlike VOPs though, the graph not run in a per-element fashion, making it more like SOPs in that respect.

The primary driver for APEX was KineFX rigging performance. Up until now, KineFX rigging was a mix of SOPs and VOPs. There were a few limitations with that:

• Adding new data types to VEX (which is what VOPs translate into) was daunting and KineFX really needs to manipulate geometry along side with matrices/vectors/floats.
  
• Single rigs were inefficient in VEX because of its per-element nature. Running VEX in detail mode wasted a lot of memory because it was designed to run the graph over many elements of the same type. Extra memory was allocated but never used when running in detail mode.
  
• Performance was lost in the switching between SOPs and VOPs. A way to assemble rigs in a modular fashion which can then be executed directly in the viewport without the need for heavy nodes was needed.
  

This opened up the opportunity for designing a graph engine that had some architectural benefits that are not really user facing: things like easy data and node type extensibility, decoupled compilation and execution, and enforced static dependencies by construction. By design, it's fairly generic so it can be used to solve other graph-like evaluation problems in the future.

I don't think it replaces SOPs and VOPs. Compiled SOPs is more efficient at working on single pieces of geometry, VOPs is more efficient when you need operate over many elements of the same type. To produce your rigs, SOPs is still the glue for everything else outside of the rig.

That makes sense. Thank you!

edward
APEX is sort of a "mid level" graph in between SOPs and VOPs. From the TD perspective, it's like VOPs except that you can manipulate geometry as data that flows through the graph along side with small data types like vectors, floats, and matrices. Unlike VOPs though, the graph not run in a per-element fashion, making it more like SOPs in that respect.

The primary driver for APEX was KineFX rigging performance. Up until now, KineFX rigging was a mix of SOPs and VOPs. There were a few limitations with that:

• Adding new data types to VEX (which is what VOPs translate into) was daunting and KineFX really needs to manipulate geometry along side with matrices/vectors/floats.
  
• Single rigs were inefficient in VEX because of its per-element nature. Running VEX in detail mode wasted a lot of memory because it was designed to run the graph over many elements of the same type. Extra memory was allocated but never used when running in detail mode.
  
• Performance was lost in the switching between SOPs and VOPs. A way to assemble rigs in a modular fashion which can then be executed directly in the viewport without the need for heavy nodes was needed.
  

This opened up the opportunity for designing a graph engine that had some architectural benefits that are not really user facing: things like easy data and node type extensibility, decoupled compilation and execution, and enforced static dependencies by construction. By design, it's fairly generic so it can be used to solve other graph-like evaluation problems in the future.

I don't think it replaces SOPs and VOPs. Compiled SOPs is more efficient at working on single pieces of geometry, VOPs is more efficient when you need operate over many elements of the same type. To produce your rigs, SOPs is still the glue for everything else outside of the rig.

Does APEX graph have most of the same operations / notes that VOPS have?

LukeP
Does APEX graph have most of the same operations / notes that VOPS have?

It's still very new so it does not, and possibly not ever because all SOP verbs are available. There was a CVEX prototype at one point that one could use to bridge into VOPs. For the first cut, the focus was on APEX nodes for the rigging and auto rigging.

edward
APEX is sort of a "mid level" graph in between SOPs and VOPs. From the TD perspective, it's like VOPs except that you can manipulate geometry as data that flows through the graph along side with small data types like vectors, floats, and matrices. Unlike VOPs though, the graph not run in a per-element fashion, making it more like SOPs in that respect.

The primary driver for APEX was KineFX rigging performance. Up until now, KineFX rigging was a mix of SOPs and VOPs. There were a few limitations with that:

• Adding new data types to VEX (which is what VOPs translate into) was daunting and KineFX really needs to manipulate geometry along side with matrices/vectors/floats.
  
• Single rigs were inefficient in VEX because of its per-element nature. Running VEX in detail mode wasted a lot of memory because it was designed to run the graph over many elements of the same type. Extra memory was allocated but never used when running in detail mode.
  
• Performance was lost in the switching between SOPs and VOPs. A way to assemble rigs in a modular fashion which can then be executed directly in the viewport without the need for heavy nodes was needed.
  

This opened up the opportunity for designing a graph engine that had some architectural benefits that are not really user facing: things like easy data and node type extensibility, decoupled compilation and execution, and enforced static dependencies by construction. By design, it's fairly generic so it can be used to solve other graph-like evaluation problems in the future.

I don't think it replaces SOPs and VOPs. Compiled SOPs is more efficient at working on single pieces of geometry, VOPs is more efficient when you need operate over many elements of the same type. To produce your rigs, SOPs is still the glue for everything else outside of the rig.

This is amazing dear Edward.
I have a question about what you wrote.
If geometry is modified somewhere inside a compiled block, Doesn't this modification cause Houdini to cook everything from the beginning of the compiled block? Since we know in compiled blocks Houdini steals the geometry instead of copying it.
How does Houdini handle this scenario?
Thanks a lot.

one thing that got my attention is that APEX “All purpose execution”, right now is just working with kinefx, still not all purpose yet as was said during the keynote.
This statement it’s really important.
In my opinion this new framework will help Houdini user experience to close the gap with real-time programs like unreal introducing a new way to interact with tools seamlessly in the viewport.
I am a little bit scared that n the creation of these APEX graphs will be another context that is going to take lot of time to manage but who knows H20 is just around the corner

As always I am really impressed by the effort of sidefx for the innovation being involved in these new technologies

N-G
If geometry is modified somewhere inside a compiled block, Doesn't this modification cause Houdini to cook everything from the beginning of the compiled block? Since we know in compiled blocks Houdini steals the geometry instead of copying it.
How does Houdini handle this scenario?

APEX still needs to recook all the nodes that work on the geometry "in-place". The new thing in APEX is that inputs are marked explicitly whether they're "in-place" or not. So if the rigger knows that they need a checkpoint somewhere in a long chain of in-place nodes, they can insert a Value node that can serve as a checkpoint cache. Some more work needs to be done here on the network editor side right now to visually show these ATM though.

Majinpu
I am a little bit scared that n the creation of these APEX graphs will be another context that is going to take lot of time to manage but who knows H20 is just around the corner

While that's strictly true, you can still do non-procedural workflows with APEX as well. There's still the option of directly authoring your graph explicitly in the APEX Network Editor after putting down an APEX Edit Graph SOP, which is basically a glorified Stash SOP.

Perhaps it's just me, but I found it a bit worrying that SideFX decided to "reinvent" rigging twice in such a short period: 18.5 they introduced KineFX, and 20.0 they've introducing another completely different thing for rigging...? While KineFX was already a completely different thing from Obj rigging...?

Rigging isn't a very new concept. Are we supposed to re-learn and re-do riggings every few years? Is there going to be another completely different rigging mechanism in Houdini 22 and all APEX stuff is wasted?

While that is a valid criticism, APEX is here to stay and part of the long term plan to bring the full traditional scene/object-based character toolset into KineFX. Without it, the animation tools we wanted would not have been possible. And now that we're over this hump, it will be more straight forward to advance the toolset using this foundation.

APEX brings fast, procedural deferred evaluation to the table in a way that allows one to avoid traditional "rig build" scripting approaches. We hope that this brings a new level of productivity to the process.

Cheers,
-Edward

1. Recall that these new APEX tools are still in beta for H20.

kodra
Perhaps it's just me, but I found it a bit worrying that SideFX decided to "reinvent" rigging twice in such a short period: 18.5 they introduced KineFX, and 20.0 they've introducing another completely different thing for rigging...? While KineFX was already a completely different thing from Obj rigging...?

I think it was communicated well
When KineFX was introduced it was mostly hierarchy and skeleton concept brought to SOPs with some tools mostly useful for mocap and retargetting and with a few helper nodes for basic VOP constraints
I recall SESI clearly stated it's a foundation and they are working on animation and rigging tools and mostly UX to make the whole process of both tasks easier

H20 seems to start addressing these needs and it was said in keynote that KineFX and APEX are complementing each other not replacing

APEX based tools may obviously become a preferred choice in some workflows riggers and animators were struggling with and will be happy to move away from, like managing tons of rigpose nodes or dealing with channels on them or dealing with constant evaluation of the rig down the stream or not being able to manage more than 1 character at a time, etc..
Knowing Sidefx, you will still have previous tools at your disposal

> like managing tons of rigpose nodes or dealing with channels on them or dealing with constant evaluation of the rig down the stream or not being able to manage more than 1 character at a time, etc

The natural way to deal with these is to make a higher level abstract ion based on KineFX, but from what I saw APEX isn't such a thing. I might be wrong, but it seems even more low level than KineFX.

But I believe SideFX has some good reasons. Perhaps KineFX's performance issues are so fundamental that more levels up from it will only make things worse?

kodra
The natural way to deal with these is to make a higher level abstract ion based on KineFX,

natural for some, cumbersome and limiting for others with more of a workaround feel, but let's see what APEX brings to the table and if it feels more natural and flexible
for me personally I always evaluate new tech in terms of what it has to offer and try to use accordingly, I don't mind the evolution if it's a step forward
Rigging in Houdini has been one of those thigs that never resonated with me, ever since Object level and then CHOP constraints, then Kinefx VOP constraints, there was something off and cumbersome about it compared to what I was used to, so I'm definitely excited this area has now full focus from Sidefx and the presentation definitely looked promising

@tamte Do you know whether APEX has a skeleton building feature different from KineFX or is the latter supposed to still fill that role? I can't recall from the Keynote video and it's not like they went into lots of details, since it was just a presentation.

citizen
Do you know whether APEX has a skeleton building feature different from KineFX or is the latter supposed to still fill that role?

Skeleton building is still the same. You pack the skinned geometry and rest skeleton along with the rig (which can have more things like controller geometry, etc.) into an "APEX Scene" for animation.

Are SESI and SideFX one and the same?

LukeP
Are SESI and SideFX one and the same?

Yes, SESI is just "Side Effects Software Inc.".

If there is "skinned geometry" how about morph targets? are they also stored in APEX framework?

also is it possible to store bones for facial rig there?

i hope that in future APEX will use ML so animating and setting poses will be easy. somethink like in Cascadour whith autopose turned on.

ah i assume that APEX is multihreaded?