toolchefs / atomsgaffer Goto Github PK
View Code? Open in Web Editor NEWAtoms Crowd extension for Gaffer
Home Page: https://atoms.toolchefs.com
Atoms Crowd extension for Gaffer
Home Page: https://atoms.toolchefs.com
It is currently functional but not very useful. It also needs unit tests.
We should add options on the AtomsCrowdGenerator to encapsulate the entire crowd, or encapsulate each agent individually.
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).
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 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 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.
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.
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.
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.
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.
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:
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?
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.
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.
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?
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.
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.
We don't necessarily want to load the ai attributes exported from mtoa, so this should be optional.
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.
We should run the tests for every PR / Release on Travis (or similar).
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)
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.
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.
Its more natural for Gaffer uses if an integer string field supports anything IECore.FrameList.parse()
can handle.
Until ACS-108 is addressed, we should forcibly ignore map1 in the VariationReader, because we know it is redundant data.
Once GafferHQ/gaffer#2917 is implemented, we may need to adapt the Generator node a bit to match.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.