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

You can store them pretty much the same way as KineFX. The difference is that you pack them into the APEX Scene and you can use the kinefx::characterblendshapescore verb inside your APEX graph to apply them.

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

You could do this in the graph by essentially embedding transform nodes. Or you could embed some facial rig geometry in the character itself like how one would embed blendshapes.

ah i assume that APEX is multihreaded?

APEX is designed for multithreaded nodes evaluation but currently it only multithreads across evaluation of separate graphs, or the same graph across multiple frames. Within a single graph, multithreaded evaluation of nodes isn't expected to bring big wins for character rigs because the rigging nodes often operate on very small data like matrices and they're very dependent on each other. That's not to say that multithreading doesn't occur though because all the verbs (eg. skin deformation) will do multi-threading internally.

Are there established workflow scenarios for working with FBX exports intended for game engines? One might assume that conversion is straightforward, but I'm curious: have earlier challenges, like the intricate setup of blend shape animation curves not being integrated with the animation ROP, been addressed?

Drasko Ivezic
Are there established workflow scenarios for working with FBX exports intended for game engines? One might assume that conversion is straightforward, but I'm curious: have earlier challenges, like the intricate setup of blend shape animation curves not being integrated with the animation ROP, been addressed?

As an aside from the discussion on APEX taking place,

in H20 we've introduced a few more export options as well as a new Export Preset dropdown to the FBX Animation Output and FBX Character Output ROPs. Users will be able to select a "Maya" or "Unreal Engine" preset that sets these export options to the ideal values for exporting data to a particular DCC/game engine (e.g. by setting the correct axis system, computing smoothing groups etc).

Over time we hope to add more export options that address pain points for exporting to a particular app or game engine, making it easier to move data between them. If there's a bug logged for the blendshape animation workflow you mentioned I'd be happy to take a look.

rajatg@sidefx.com

Drasko Ivezic
Are there established workflow scenarios for working with FBX exports intended for game engines? One might assume that conversion is straightforward, but I'm curious: have earlier challenges, like the intricate setup of blend shape animation curves not being integrated with the animation ROP, been addressed?

As an aside from the discussion on APEX taking place,

in H20 we've introduced a few more export options as well as a new Export Preset dropdown to the FBX Animation Output and FBX Character Output ROPs. Users will be able to select a "Maya" or "Unreal Engine" preset that sets these export options to the ideal values for exporting data to a particular DCC/game engine (e.g. by setting the correct axis system, computing smoothing groups etc).

Over time we hope to add more export options that address pain points for exporting to a particular app or game engine, making it easier to move data between them. If there's a bug logged for the blendshape animation workflow you mentioned I'd be happy to take a look.

Last time I checked, Houdini 19.5 seems to have problem exporting blend shape normals:

https://www.sidefx.com/forum/topic/88155/?page=1#post-402912 [www.sidefx.com]

Is it a logged issue?

The reply I had for the logged issue for that thread's first post was:

As far as I can tell, the normals problem in the blendshape that you see in Houdini/Maya is directly from the blender exported hair.fbx file itself. So given that FBX file alone, it is impossible to recover the intended normals in those blendshapes. A quick google shows that Blender has issues with exporting blendshape normals in general to FBX (eg. https://developer.blender.org/T46019 [developer.blender.org] is still active), which doesn't give me good confidence in their exporter even if the issue isn't exactly the same. I'm sorry to say that this is not an issue that can be addressed in Houdini.

So that thread's file wasn't even an export issue as the artist noticed the bad normals prior to the export.

i still wondering why motion data is stored in APEX framework as geometry? Its really interesting out of the box idea and i feel that in future it will allow for something stunning not just animation performance speed up.

and more important how it is edited at the moment? is the motion data from APEX sucked and converted to standard motion paths (in graph editor with 3 bazier curves as channels: X, Y, Z)? isnt there any bottleneck? or mayby it is only temp sollution since totally new graph editor will show up? (i hope)

even more i wonder how those amazing new animation sliders work? do they operate on graph editor standard channels or mayby directly on stored motion path data in APEX?

Is it gonna be possible to import UE MetaHuman and store it entorly in APEX format, with all extra controllers for face, blendshapes (this is confirmed) and what else this MetaHuman have. I bet it will but question is more when?

iam really excited about that APEX. i was expecting some animation improvements but is is just another whole galaxy of possibiliteies added for animators!

i wonder if new Vulcan Vieport and new animation system could work together? by that i mean that actually viewport can display animation curves as 3D objects (with anialising and any thic u like), also keys and layers, non linear animation vlops etc.

i mean making UI/UX interface entirly inside Vulkan. so animation keys (dots, icons, sprites) will not be bitmaps based anymore but mayby 3D objects?, with raytraced shadows and sss just for fun xD

so animation spreadsheet, keys, curves all could live in actual 3D Vulcan viewport accellerated with hardware so milions of bazier curves wont be problem anymore. iam just dreaming anyway

Oh and talking about animation YT sugested me Blender roadmap for their improving in animations. Iam not Blender fan at all but they could have some cool ideas too, that could be adapted (borrowed xD) to Houdini fe. placement of pose library is in right place IMO (just above timeline) so that could be copied xd. i bet that SideFX team know what other do but ill attatch this YT anyway



Your text to link here... [youtu.be]

oldteapot7
more important how it is edited at the moment? is the motion data from APEX sucked and converted to standard motion paths (in graph editor with 3 bezier curves as channels: X, Y, Z)? isnt there any bottleneck?

That's correct. The channel geometry primitives was unpacked into regular channels for editing with the rest of Houdini while inside the Animate tool. I forget whether this was mentioned, but the graph rendering in animation editor was replaced with a GPU shader solution in H20 as well. But regardless, the rig evaluation isn't done from the regular channels. When the channels in the graph editor are modified, they're pushed back inside the Animate tool and evaluation is done internally.

even more i wonder how those amazing new animation sliders work? do they operate on graph editor standard channels

They operate on standard channels. So they're usable for animation anywhere in Houdini, including the old OBJ-based character tools.

Cheers!

"so animation spreadsheet, keys, curves all could live in actual 3D Vulcan viewport accellerated with hardware so milions of bazier curves wont be problem anymore. iam just dreaming anyway" - like this?

My guess is that all of this will be explained in the Houdini 20 HIVE videos, they say they will be released when H20 goes gold, I haven't seen a release date yet, can't wait for H20 to be released! 😜

i hope that same as with Vulcan viewport new feautures will be added to every new production build of Houdini?, Thats what SESI do anyway, right?

so animators dont have yo wait till 20.5 for some small but importantd upgrades in lates say HUD display animation targeted tools.

BTW please design look well, now its just same ugly slider as in main UI.
but it could be way cooler, way more ergonomic and good looking sliders and other stuff.
i belive that was shown was just quick placeholder that just works but not looks, but it all need redesign to fit well on screen.

and it should be fully customizambe. some animators might preffer heavy color thick sliders and other just tiny lines without any numbers. just something to easilly grab and more around on screen space.

also mayby its good idea to make tabs on vulcan screen? so each tab can contain diffetent animation palletes like selection sets. its like with multi desktop on windows that you can fast switch betwean differen workplaces.

ideal if there will be SDK or whatever its called to make ownt sliders, spinners, bone selectors, switchers, XY box areas where yo have sliders in X and Y directoons (fe. for eyes)

well basicy everything that is build from splines for animation controll could live just flat onscreen. it will be most handy sollution.fe, tabs could be good for organizing fe. lots of sliders for morph targets. i belive that for Animators UI/UX is most important becouse it their primary tool for endless tweaking poses and timing.

also some sort of painting/drawing on each frame on Vulcan wievport will be helpfull. So animators can draw all the arcs, poses etc. usually animators can draw preatty good and its faster for them to just draw poses and block animation.

please do not copy this ugly 15 yo panel sliders from main UI and instead make it super cool looking, super customizable and savable and sharable. so if somone will made in python or something beter UI for animators they could check and use it. fe. sliders for morphs wich is always pain to mix correct ones xD

Those HUD sliders must be able to store and save verys fast movement. so fe. when animator will hit autokey and press run he could be live capture of fast movement. lates call it real time motion capture with Wacom tablet.itll be nice if there will be possible to connect sliders to some mocap devices like gloves ets. so we could animate morph targets using our 10 fingers (its cool AF)

This on screen HUD should be next level state of art both functional and design wise thing not clone of that old ugly and messy Houdini UI

so animators dont have yo wait till 20.5 for some small but importantd upgrades in lates say HUD display animation targeted tools.

I have a strong feeling that you overestimate what the Vulkan viewport is going to be by a lot.

From what we know for now, it's supposed to a faster and hopefully more stable alternative to the existing GL viewport. It's not akeytsu or some UI overhaul for animators. (At least for H20)

Propabbly i didnt wrote it clear, soŕry for my english btw.
mentioning Vulkan i referred to one of the developers that said that new feautures from ToDo list will show in H production builds and they will not wait till 20.5 to release them. so thats about Vulkan. so the same could be with APEX new functions and NEW vieport HUDs?

now: HUDs (Head Up Display) AFAIK main idea is to give animators all they need on Vieport in form of quicly and easy to use tools such brand new "selection sets" and "value sliders" or whatever its called. This is GREAT IDEA!

So animators dont have to deal with rest of Houdini UI such as nodes and ugly parameter pannels.

All i suggest is to make those new pannes completly NEW from design point of view. fe. make them fully customizable, resizable, etc. so fe horizontal and vertical sliders are possible. etc. also make tabs for them to orginize. fe. each tab contains HUDs for each character.

Make them NEW from scratch not just clones from parameters menu.

like real HUDs friendly for animators.

i know its not related to Vulkan (but who knows mayby there
are speciall hardware accelerated function just for HUDs?)

i think its more connected with Qt 6.6 or whatever Houdini is using for UI.

i hope that iam more clear now?

Learning from Akeytsu doesn't sound like a bad idea. Akeytsu has fallen flop, but I think its design is good for animators. (I kinda feel it fell not because it's not good, but because there isn't a big market for animator-only tools)

raincole
Learning from Akeytsu doesn't sound like a bad idea. Akeytsu has fallen flop, but I think its design is good for animators. (I kinda feel it fell not because it's not good, but because there isn't a big market for animator-only tools)

Akeytsu does look good, as I recall it is Windows/Mac only, being a Linux users I never tried it, let's hope that other tools like Cascadeur, which I use, will fare better!

I've been running APEX examples in the documentation, feels like a decoupled sops to me, something close to geometry nodes in blender, datatypes are wide open, although electra crashes alot on me, it feels a bit rushed, but then again its good to get use to this early, I'm feeling the same trauma I had learning PDG.

mohammed
although electra crashes alot on me,

If you've got crashlogs, it would be good to send them in and also to try the daily H20 build which are out now.

My guess for APEX? All Purpose Execution so not still "all purpose"

Quite every node in houdini right know is multithreadead, so if we make a macro function using these nodes (sop 2.0) we can abstract those functions.

Now think about nodes that can be tokenized for Machine Learning... I am crazy or did somebody thought about this?