Attribute caching

[AWhetter]

This pull request implements attribute caching via the .arbGeomParams and .userAttributes fields of Alembic files.

During imports, all the attributes in the alembic are added to both the shape node and the reader node, and connections are made for these attributes from the reader node to the shape node. It also fills the new ExocortexAlembic_GeomParams and ExocortexAlembic_UserAttributes fields on reader nodes. These fields are required by the attachment progress. During attachments, the attachment process deletes all of the attributes on the reader node using ExocortexAlembic_GeomParams and ExocortexAlembic_UserAttributes, does the normal attaching, and then readds and connects the attributes on the reader node.

This is a requirement because of the way that Maya nodes work. Therefore although you can still change the path to the alembic file on ExocortexAlembicFile nodes, new attributes will not be added and old ones won't be removed.

Attributes can be cached using any of the following fields in export jobs:

attrprefixes=CacheThis_,ExamplePrefix,...
userattrs=Attr1,Attr2,...
userattrprefixes=CacheMe_,CacheMeAlso_,...

Attributes specified in attrs are cached into .arbGeomParams in the Alembic. Any attribute that has a name that begins with a prefix in attrprefixes is also cached into .arbGeomParams. (Similarly for userattrs and userattrprefixes with .userAttributes in the alembic).

Attributes should not begin with a '.' as these are use internally by Crate already for some node types (eg particles and curves). This breaks compatibility with Maya versions <= 2013. It also doesn't work well with Parallel evaluation with Maya 2016 (not that all of the default Maya nodes do...). Support for attributes on FaceSets is not implemented.

For now Crate no longer doesn't attach the reader and shape nodes together when the alembic schema for the shape node is constant. This is to cater for the case when transform and other standard attributes don't change, but the geom params and user attributes do. To fix this it needs a change in Shared/CommonUtils/CommonSceneGraph.cpp where isConstant is set.

I've also implemented super simple fields in the Export UI for specifying user attributes and user attribute prefixes. These are just simple line edits that pass whatever is in the box straight to the userattrs and userattrprefixes fields, so they expect a comma separated list of attribute names and prefixes. It might be nice to make the UI work more like the AbcExport UI for attributes eventually but I think we'd want to start using frameLayouts to keep things tidy, which would require translating the QT ui file to MEL.

[bhouston]

Very nice!

[martin-chatterjee]

Hey Ashley,

first of all thanks for your work on this, it's much appreciated.

I just checked out master and tried to build both Softimage 2015 and Maya 2016 on my side (Windows 7, Visual Studio 2012) and cmake fails on me.

Running _build/build-vs2012_x64.bat does not finish without errors - therefore ExocortexCrate_Windows7.sln is never created in the first place.

To make sure that my setup is not flawed I reverted back to 81f6fcd (prior to the merge in of #46).

There both build-vs2008_x64.bat (for Maya 2016) and build-vs2012_x64.bat (for Softimage 2015) work for me; also both solutions compile fine for me.

Could you please confirm for me that cmake is working on your side with a fresh checkout of the repo?

Thanks, Martin

[AWhetter]

You're right! I changed how setup_precompiled_headers worked in 4fd6f80 but forgot to update the other CMakeLists.txt files. I've implemented a fix in #49

Thanks for the heads up!

P.S. Maya builds with Visual Studio 2012 now (vs2010 for Maya 2014).

[martin-chatterjee]

Ashley,

thanks for looking into it. However I'm afraid this is not working yet on my side.

Running _build/build_vs2012_x64.bat does now finish without errors, so that's great.

However I get a few dozend errors when opening the .sln file and attempting to compile CommonUtils as Release.

I repro'ed this broken behaviour with a fresh repo clone on multiple machines. I also again temporarily reverted back to 81f6fcd (prior to the merge in of #46) and again everything builds as expected...

Therefore I am fairly certain that this is not a problem on my side. However what is puzzling me that apparently things are working on your side?

Could you maybe try a clean repo clone and a full rebuild on your side?

BTW, I am on Windows 7, Visual Studio Pro 2012 (11.0.61219.00 Update 5), CMake 3.4.1

Thanks, Martin

[martin-chatterjee]

Ashley,

just a quick heads up, I started to look into hunting down the build break issues, and I'm getting somewhere.

Basically I am using 81f6fcd as my base (as at that point everything still builds on my side) and then going forward through your changes commit by commit/file by file/hunk by hunk.

I've got some success - let me double check and verify my findings against a fresh repo clone & rebuild before I issue a pull request.

At that point It'd be lovely if you could then test my fix on your side with a full rebuild as well to make sure that things are still working for you as well.

(I still don't understand why things seem to work for you currently, therefore I still can't rule out completely that there might be some issue I don't yet understand fully on my side...)

Stay tuned,

Martin

[martin-chatterjee]

Ashley,

all right, I've just issued a pull request (#50) that works on my side.

Please read the details in the PR description.

Could you please pull from my (public) repo and check if this is working for you as well?

I'd like to get your feedback and confirmation on this before this potentially get's merged into master.

Cheers, Martin

[AWhetter]

I didn't compile originally because I'd never managed to compile Exocortex in full, even before I started making changes. I've managed to get it working though and I've put my changes (and documented some others) in a different pull request (#51). Alternatively you could change the includes reordering in yours to the includes additions in mine, and then we can use your pull request. I don't mind.

Sorry about all this though! But at least we've learnt some new things and now I know to test the entire build next time :wink:

[martin-chatterjee]

All right, cool.

I've just applied #51 as a patch to master on my side and successfully built Soft 2015 and Maya 2015 & 2016.

Therefore as far as I'm concerned it's all good and we can merge #51 into master. and forget about #50. :+1: