Maya - missing geo

Coding
#1

This happens to a few artists here every once in a while, but we don’t know what causes it. You open a saved scene, and some geo is missing from the viewport, but the transforms and shapes are still in the outliner.

Fixes that usually make it reappear:

  • Delete All By Type --> History, then UNDO
  • Group the transform

Horrible step to make things worse:

  • Delete History on the transform. Now your geo is gone forever

On the offending geo, the transform has two shapes, one that you can see in the outliner, and one you can’t. I don’t think it happens when construction history is turned off. What causes this?! What’s the deal?!

#2

First of all, I wonder by the two geo’s if you are referring to the ShapeOrig node?

You can make this visible by turning off Object Display -> Intermediate Object.

This node is created when you have deformers in your chain. I’m not sure if you are running into a bug because I can’t reproduce it, but this might be a way for you to recover lost geometry at least.

#3

No deformers, just a lot of polysplit history. I don’t think it’s a shapeOrig node, or at least it wasn’t called that in this case. I’d love to know how it’s caused, but can’t repro intentionally.

#4

when you say “some geo” is missing, are you saying that the actual geometry is gone, or that it just doesn’t render anymore? (ie: can you still see its wireframe? From what you describe with your undo operation, I am guessing that’s your case)

typically, we’ve had to deal with issues like that randomly here as well.

When the geometry was actually gone, it was most generally caused by some #IND or #QNAN in the .ma file that was invalidating this particular object (float precision issues when serialized as text).
Quite simple to fix by replacing all occurences of #IND and #QNAN by zeros, save the .ma and it should fix the missing objects.

If you can still see the wireframe, but no shading, it’s mostly some retarded issue in how the graph networks of groupId and instObjGroups attributes update. You’re in to reassign the materials by hand eventually.
I had this issue tracked by a support ticket at Autodesk and given them a scene of ours and I am not really sure if that lead to any development/bug fix on their end. Hopefully in 2013?

if It’s neither of these, then disregard the above :wink:

Also, when you’re talking about multiple shapes under a transform, are only one of these not greyed out in the hypergraph? To our experience, these seems to be created somewhere during the life cycle and modeling operations on the object. They seem to be harmless and just some carried over cached data of some sort. I used to delete them by hand with no effect when finding them (after making sure they were not supposed to be there).
They seem also transparent to most python commands operating on mesh shapes except to some advanced API based scene parsing stuff.
So far, I haven’t found them to have any ill effects to our exported data. YMMV though.

#5

I found something similar while testing Maya 2012. If you open some scenes. In my case about 50% of scenes, some (not all) geometry would be invisible. Even the API would not know how many poly’s where in the shape. However the fix was to move the parent transform. This woke up the dependency graph and the API started to return the poly count. Also the invisible geometry shows up in the view port.

Not saying this is it. I’ve not seen it since early 2012 days so I assume it was fixed.

#6

If you can still see the wireframe, but no shading, it’s mostly some retarded issue in how the graph networks of groupId and instObjGroups attributes update. You’re in to reassign the materials by hand eventually.

I’ve also seen this happen when the materialInfo node connected to the material gets deleted. It is one of those wonderful auxiliary nodes that Maya hides from you, and isn’t visible by default. I’m not sure how they get deleted, but they do.

If an intermediate node has *Orig in the name, then that mesh is (very likely) being used by a deformer further up the graph. Assuming the deformer is still there, you certainly don’t want to delete the *Orig node, as the deformer uses it as a base to perform operations on.

The intermediate nodes created by modeling history are normally called polySurfaceShape* (at least with poly meshes). They act the same way as the *Orig nodes, in that they are a base for the poly modifier nodes to perform operations on. When you delete history on an object, Maya normally goes through and deletes these nodes for you. However, if there is a really long graph of poly modifier history, Maya can get really confused and miss some of these nodes. I’ve also seen it completely miss modifiers nodes. It’s not unusual for me to look at a scene and see a ton of polySplit nodes that aren’t connected to any mesh. It’s good practice to delete history regularly. It helps keep the scene nice and clean. Bottom line, if there’s no history on the mesh, these are safe to delete.

The left-over intermediate nodes are benign, but they can cause massive data bloat. One of our level files was over 200MB in size, and once I removed all the extra intermediate nodes, the file dropped down to ~50MB. Lets just say that the level artists were really happy after that from not having to wait minutes for Maya to load the level.

1 Like
#7

Used to happen with silly long names with massive numbers.
Maya would get to a point where it would just decide the increment in numbers everytime the object had been duplicated got so large it couldn’t read it in from the file any more, so would skip over it silently and just not load it, it was there in the file but not accessible. Of course having a ASCII meant you could manually rename then have them appear again.

Not seen this though since 7, I think…

#8

So ironically we have just seen this today,

#9

I think the most common way I’ve gotten something like this is just having two meshes, combining them and accidentally deleting the leftover transforms (which looks empty but they have hidden intermediate nodes as children), before deleting history on the combines mesh. First time I did this I though the viewport was broken as it was always wireframe… and restated Maya… bad idea as it removed the undo-history…

Got me thinking that there should be a check (at least an option for one or a warning popup) so you can’t delete nodes that are in construction history for another node…

#10

This is still causing problems! The behavior is different between standard 2012 and hotfix 4. Just had to ‘fix’ a scene (with delete all history, undo) for somebody on hotfix 4 (I don’t have the update yet). Can’t find any QNAN or IND’s in the files, either… :frowning:

#11

I found this, or at least a similar problem, the other day as well. I was lucky enough that between the artists local file and the previous revision checked in I was able to find a cause. Like the problem you hit, it was an object with a bunch of polySplit’s. What I tracked it down to was after the series of polySplits the artists were working with each split object individually, eventually getting them into the form they wanted. After that, they deleted all of the “empty” groups that polySplit leaves behind in order to clean up their scene. Those groups contain a lot of intermediate geometry shape objects which that chain of polySplits is relying on, and since they are flagged as intermediate they only show up in the hypergraph/shader, so as far as the artist knows they were just cleaning up their scene getting rid of unimportant transforms. However, Maya doesn’t seem to know how to resolve these objects going away and you end up with the Orig shape of the base mesh no longer correctly gets pushed through the graph to the rest of the shape nodes.

I don’t have a solid solution in fixing this issue yet, other than informing the artists that they should delete history after a polySplit before they go on to edit the split pieces. For that file the disappearing geometry was a piece that had not been edited so I was able to clean it up in the previous revision and merge it into the current scene.

edit: Pretty similar to what Wolfsong mentioned combine and split both leave these intermediate shapes in the scene. And I agree, it sure would be nice to have some kind of warning when deleting nodes that are in the construction history of other nodes.