It looks like UV indices are supported in the Atoms format, and they are supported in Gaffer/Cortex as well, so we should keep them when loading the geometry.

In some cases the full path hierarchy exported from Maya might included more parent locations than we want in Gaffer (eg extra xforms from rigging that were not in the original model). Assuming we need those full paths exported into the variation .json, it would be nice to also have a "partial path" or "subpath" mode on the Variation Reader to prune those off.

This isn't needed after the generator. Note that this may require changes on the base class in Gaffer to allow modifying the top level location.

Is there a way to override the preview geometry (sphere) that pops-up in the viewer whenever a shading node is selected?
Currently I see no settings for switching to another option, or specifying an external file as the preferred lookdev "shader ball".

Taking it from the several geometry options available in Maya's Hypershade Material Viewer pane, I believe it would be beneficial to allow the user to specify a custom shader ball that is more appropriate for the particular shading element being tweaked.
(Users could provide their own geometries instead of Gaffer itself having to come with several ones included)

WIth #9, the internal EngineData is reporting the correct memory usage, but the overall consumption of the node still seems higher than what should be necessary for a point cloud.

I suspect we're still loading the full geometry for some reason. Possibly for bounds calculations?

Investigate and reduce memory usage if possible.

It is currently functional but not very useful. It also needs unit tests.

It would be good to move the joint* attributes to PrimitiveVariables on the meshes. Its not common to store such a large dataset as attributes in Gaffer, and its less flexible in terms of manipulation downstream.

There are known limitations preventing this currently (eg we'd need a fixed numbers of influences), but there are naming schemes that can accomodate these issues as well.

the generator can receive per agent primvars from both the agent pointcloud as well as the variation reader geo, have control options as to what does end up on the generated geo and where (ie, as a primvar or an attrib) - the copy sop in houdini is a good example

We can add a Help->Atoms menu that links to external Atoms docs and loads each example script.

We have a crowd with instancing enabled and a huge amount of duplication (1200 agents duplicated several times to make 20500 agents). Based on stats from an Arnold render, the instancing is working as expected, but there is a unexpectedly high amount of "unaccounted" memory reported. It could be related to #15 or could indicate another memory issue in AtomsGaffer, or in Gaffer itself.

Since we know the 10 primvars we're exposing on the points coming out of the CrowdReader, we should pre-populate the AtomsMetadata UI with those options as optional member plugs of a compound (eg the same AtomsAttributes is doing).

We might not want to load all variations, so we can add a StringPlug to filter them using StringAlgo::multiMatch. It can default to "*" so we get all variations.

We should be able to store in the variation file a mesh interpolation (linear vs catmulClark) and the variation reader should respect that. We can either add the Cortex convention (ieMeshInterpolation) or re-use the arnold subdiv settings if they exist in the cache. Note that meshes set as subd should not bother loading normals into Gaffer.

We don't necessarily want to load the ai attributes exported from mtoa, so this should be optional.

Once GafferHQ/gaffer#2917 is implemented, we may need to adapt the Generator node a bit to match.

We should add options on the AtomsCrowdGenerator to encapsulate the entire crowd, or encapsulate each agent individually.

I just experienced a hashing bug of some kind. I was using the AtomsMetadata node to override the atoms:variation and it seemed to work, but then disabling the node did not result in an update to the final crowd, either in the Hierarchy View or Viewer. Once I clicked away and back onto the generator, the Hierarchy View did update as expected, but the geos drawn in the Viewer were in an even worse state, with some of them being unexandable bounding boxes.

Is there a good reason to have the AtomsCrowdClothReader as a standalone node? It seems to just add extra data onto the points coming out of the AtomsCrowdReader before piping them into the generator. Can we move this functionality to the AtomsCrowdReader instead?

currently the weights/indices for deformation are stored as custom attributes, instead store them as primvars that will be exposed via the VariationReader and need to be read from the
primvars in the CrowdGenerator, this will make it easier to inspect / modifiy them as well as benefit of compression etc.

A drawback of putting this stuff into primvars is that there currently no really elegant way to support varying influence lengths (ie, one point driven by 2 influences, the next one by 8).
What we'd eventually like to do is support varying array data for indices and weights per point, but we currently don't because we haven't come up with a good way to interpolate those.

Anyhow, we ended up with a convention that looks like this:

• split up the the weights into individual primvars of size 1
• the max amount of those individual primvars would be determined by the maximum influence we have across the topology
• use a naming/number convention to identify which weight belongs to which influence
• expose those names as parameters on the nodes (with sensible defaults)
• convention looks like so: [nameOfInfluence]# [nameOfWeight]#
• so in a situation where you have a max of 3 influences, you'd have something that would look like:
  influenceJointId_0 (int), influenceJointId_1 (int), influenceJointId_2 (int), influenceWeight_0 (flt), influenceWeight_1 (flt), influenceWeight_2 (flt)
• if an a point is driven by less influence than the max number, we assume the influence id to be -1
• we assume all influence to be ordered by weight, and as soon as we encounter an influence id of -1 (or weight of 0), we stop
• typically we don't build an internal lookup from the primvar data, but use the data directly to prevent redundancy of weighting information
• while on paper this seems like a waste of space on the primvar side (especially when the amount of influences is differing greatly) we found that due to primvar compression etc this has not turned out to be an actual problem
• a nice plus of storing data this way is that the interchange of weight information with other applications (maya, houdini etc) via any of the supported file formats becomes quite easy

Once GafferHQ/gaffer#3394 is merged and released, we'll want to update the AtomsCrowdGenerator to make use of it, the same way GafferScene::Instancer is doing.

jointIndices, jointIndexCount, and jointWeights should all have atoms: prefixes to avoid clashes with other plugins/tools.

Add an option to the AtomsCrowdGenerator to output a PointsPrimitive representing the animated agent skeletons rather than the final geometry.

Its more natural for Gaffer uses if an integer string field supports anything IECore.FrameList.parse() can handle.

AtomsCore::MetadataImpl<Imath_2_3::Box<Imath_2_3::Vec3 > >::toString(std::basic_stringstream<char, std::char_traits, std::allocator >&) const

AtomsGaffer is built against 3.0.1 and gaffer 0.54.1.0 with USE_GAFFER_DEPENDENCIES=ON

Building against 2.8.2 throws different undefined

2.8.2/0.54/lib/libAtomsGaffer.so: undefined symbol: _ZNK9AtomsCore18TypedArrayMetadataIN9Imath_2_34Vec3IdEEE7memSizeEv

AtomsCore::TypedArrayMetadata<Imath_2_3::Vec3 >::memSize() const

Both of these are thrown on "import AtomsGaffer"

Any ideas what might be going on?

We should run the tests for every PR / Release on Travis (or similar).

We have 2 agents with the same costume (eg man/winter & woman/winter), but the generator seems to be ignoring the agentType of the incoming points and just using the costume name.

@iaiotom is investigating a memory issue reported, todo with the EngineData potentially.

If I transform the points between the CrowdReader and the CrowdGenerator, I expect that to move the agents origins, but it is not currently happening.

Until ACS-108 is addressed, we should forcibly ignore map1 in the VariationReader, because we know it is redundant data.

Until now, if more than one thread in Gaffer wanted the result of the same computation, and that result wasn't in the cache yet, both threads would perform the compute. This can be particularly bad for big computes that do IO, which I believe is a good description of the AtomsCrowdReader.__engine plug.

Gaffer 0.54 provides the option of blocking in this case, so that the computation is only performed on a single thread. Relevant documentation here :

https://github.com/GafferHQ/gaffer/blob/master/include/Gaffer/ComputeNode.h#L81-L86
https://github.com/GafferHQ/gaffer/blob/master/include/Gaffer/ValuePlug.h#L105-L129

And an example is here :

https://github.com/GafferHQ/gaffer/blob/master/src/GafferImage/OpenImageIOReader.cpp#L756-L771

Feel free to give me a shout if you have any questions.