Maya HUD!

So this is a simple question, I’m wrapping the Maya HUD setups into a simple metaNode so you can really easily add and monitor attrs in the Hud without having to do any messing around. The question is this, why give us 10 sections in the HUD grid when most of them are reserved for Maya’s own hud elements, even if those elements aren’t being draw? EG, I want to be able to draw all debug info on our facial rig in the HUD in section 0, but I can’t as it already contains hud elements, presumably all the standard polyCounts etc, even though I’ve not activated those in the Maya session?

Anybody got any pointers?

Mark

I ran into the same limitation, but didn’t try very hard to get around it. I just moved my HUDs to open slots. There is probably a .MEL script in the Maya folder where the HUDs are created - could probably hack into that file to free up those sections.

I remember I tried to find where they were being declared though this was probably like 2 years ago. Was trying to put grid divisions in there but just ended up using the nextfreeblock command.

Yeah I by-passed it but it just feels way too limiting. If the HUD hasn’t been draw then why reserve the slot, why not just make it when it’s required and kill it afterwards? I’ve been playing round with the metaHUD stuff in Red9 and decided I’d wrap it into the ChannelBox so that I now have an ‘addTo’, ‘removeFrom’ and ‘delete’ Hud items. It’s really useful, you just select any channels in the CB and add them, anything added is thrown to the Red9Hud and drawn/monitored which is great for debugging systems. To be honest it’s the kind of functionality that just should be there in the first place!

Mark

is it not possible to put the hud commands in edit mode, and remove elemeants by name?

it is, but the hud’s in question are the native Maya ui huds and my beef is that if they give you access to drawing in the sections, why reserve those sections when the native hud’s haven’t even been initialized? I guess they reserve the slots, but it just seems kind of wrong

You could try and make your own HUD using the headsUpDisplay command.
http://download.autodesk.com/global/docs/maya2013/en_us/CommandsPython/index.html

that’s exactly what I’m using, but most of the sections are actually reserved for Maya’s own HUD items. No worries, I’ll live with it for now. This is in testing for the new build of the StudioPack, the ChannelBox now has an ‘Add to HUD’, ‘remove from HUD’ and ‘delete HUD’, means you can simply select attrs in the channels box and add them directly to the HUD so you can monitor them, been an absolute gem for me at the moment designing facial setups and wanting to monitor lots of attr changes.

Ah! Sorry, didn’t realize it was reserved.

For montoring, there’s another node that displays a number in the viewport although I can’t remember its name… It was less useful for accurate things though as it was based on the current scene fps (steps inbetween values based on 1/fps to a predetermined amount of decimals) but I’ve had good use of it as it can be embedded in the DAG with the rig letting you make visibility toggles etc. for dailies and general info to artists.

I’ll try and hunt down the name of that node, it’s quite unrelated to monitoring I remember. Unless someone else knows of which node I am referring.

The idea of this one is that you can stack up to 34 attrs live in the HUD / viewport, these are linked to the refresh call so show in playblasts etc. I needed something that I could monitor changing internal attrs on our facial rig easily so decided to expose the metaHud nodes stuff I’ve been doing directly in the CB for people to use.

Yep, thats what I was thinking too!

I found the name of the mystery-node.
cmd.createNode(‘positionMarker’)

It’ll update to attribute changes (numeric only) and appear above everything else, like the hud, while sitting in 3d space, like on the face or on a finger.

The “aha” being that it clamps output values based on which fps you’ve got set in your scene… Can be quite a bummer for detailed feedback, or very low values. For that, you could multiply values before inputting them, so as to avoid small-value-clamping.

Hey Mark! Did you find any use for the positionMarker? I’m curious to see how you incorporate it, if at all.

I had a look at it but it’s not really what I was looking for. Stuck with wrapping the headsUp calls into a metaNode so the attrs and connections can be monitored and managed. Seems to work really nicely, pushed it out in v1.30 of the Red9 pack last week, all integrated into the channelBox RMB menu’s :wink: