instance support with abcexport

[99a...@gmail.com]

Hello,

is anyone interested in supporting instancing with abcexport?

If so, I like to discuss the distinction in the code between "static" and "animated" objects. Both export and import treat them differently. For example on import, a single frame does not have the alembic node created, only when animated. In my opinion there should not be a distinction, only a difference of numbers of samples. Here is why:

- in the studio, we want static geometry exported to abc and import it with the alembicnode connection, and not store it in the maya ascii file, too, creating duplicate data
- if someone still wants a static import without the connection, just delete history
(getting to the point of the topic)
- on export, the pointers to "rootinstance" OObjects with static geo remain local, so they are not available later on, which makes the implementation of instances impossible since, OObject::makeChildInstance() requires that pointer

I implemented the existing abc core instancing support into abcexport. But in order to do that, I had to get rid of the conditionals for static/animated in abcexport. Happy to send a patch.

For abcimport, I am further suggesting the implementation of two flags:
- a flag making static geo still linked to the abc
- a flag to reconstruct maya instancing
(Happy to send a patch once done)

None of this should cause incompatibilities with existing abcs, or older versions of abcexport/import.

Thanks
Alf

[Diego Garces]

Hello Alf,

We have also implemented support for instances in maya.

However we did not find practical to import them and are just sending directly to render. How do you plan on importing them back to maya? Using plain maya instances? Using a particle instancer?

Cheers,

Diego

--
You received this message because you are subscribed to the Google Groups "alembic-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brad Falk]

I think supporting instancing is a great idea. I'm currently using Cortex to deal with this and there is really too much to support. Alembic would be great.

And as far as using the in maya, we don't actually import, we use only representative geometry like points, bbox and "gpu" for instances. 

I'd live to hear more about instancing support in abc.

Brad

Sent from my iPhone

[99a...@gmail.com]

Hi Diego,

to answer your question, it will be maya instances. Particle instancer could also be implemented but that would be a different topic. It can be done, you would also have to add animated particle support and per-particle attributes, and you could also add the particle instancer itself. Then you can take Houdini particles for instance and use them with mayas particle instancer...

For rendering, the Arnold procedural already has support for instances (makeinstance flag). It does it through identical hashes so it catches instances and duplicates even, I see no reason to change that. Not sure I remember the prman procedural does something like that, but I am talking about the stock procedural not any of the hundreds of studio-specific ones, but it will be a piece of cake to implement that once the information is contained in the abcs.

Cheers
Alf

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discussion+unsub...@googlegroups.com.

[Diego Garces]

When there's a big number of instances we tend to model them using particle instancers, so reimporting them back as maya instances is not really practical for us at the moment. However, turns out that creating a particle instancer from external data doesn't seem to be as easy as I thought. The only way I have found is to create a .mc cache and use it as input of the particle instancer or create a complicated network of nodes, including meshes and emitters using the mesh as goal.

It would be great to have an official implementation of the export process of instances in AbcExport. We'd be happy to pull a merge request of our code if people are interested.

Cheers,

Diego

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "alembic-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.

[Lucas Miller]

> It would be great to have an official implementation of the export process
> of instances in AbcExport. We'd be happy to pull a merge request of our code
> if people are interested.

Go ahead and submit a PR for what you have, at the very least it'll
further the conversation.

Lucas

[99a...@gmail.com]

Hello,

I finished my research and got it working on a rather heavy production asset. This is just basic maya instancing. I do not think the particle instancer should be mixed with that. Supporting the particle instancer could be done as well but that would be a different (if interesting) topic:

- first of all, support for animated particles needs to be implemented - that is kind of due anyway :)
- then create a separate particleinstancer class for export/import and the procedural.

It would basically recreate the particle instancer as a particle instancer on import, connected with the instances and the particles.
This way you will get what was exported Instances->Instances, ParticleInstancer->ParticleInstancer. Like I said I would not mix the two as this could be confusing.

You could do really cool stuff like using animated particles from Houdini with the maya instancer...

I could merge the instancing support to the the latest alembic source and submit a PR for that.

Cheers
Alf

[Lucas Miller]

> - first of all, support for animated particles needs to be implemented -
> that is kind of due anyway :)

If anyone has added support for this in AbcImport, a pull request
would be greatly appreciated.

> - then create a separate particleinstancer class for export/import and the
> procedural.

The need for a point instancing schema was brought up during
yesterdays SIGGRAPH BOF.
This schema would contain a small number of properties to represent
the xform for all of the instances (not an xform stack), and a list of
Abc::OObjects would be given representing the unique instanced
hierarchy within your archive.

> I could merge the instancing support to the the latest alembic source and
> submit a PR for that.

Yes please.

Lucas

[Eoin Murphy]

Hi Alf,
reading this post a bit late - I was at the Siggraph BOF and talked to a few people about Maya instancing support. I've also added instancing support for AbcImport and Export, but I never submitted it back due to the confusion about who was maintaining the Maya Plugin. In the end, getting basic support in wasnt that hard, but one thing i wanted to ask you is if your system supports nested instancing?
We've also modified the maya importer to remove the distinction between static and animated geo, and always maintain a connection to the Alembic MpxNode. We did this as our renderer translator needs to know that geo it seees can be represented as an alembic procedural in our render scene description, and is not maya geo.
Thanks,
Eoin

[alf...@grid-vfx.com]

Hi Eoin,

yes the alembic node connection for static geo is another thing we should probably discuss. I solved it with a flag that connects when the flag is set. Not only for the procedural checking, but it also creates twice the data when not connected.  I do not see why it should ever be disconnected in the first place (just delete history if you want that).

I am not sure if it works with nested instancing, would you have a sample scene? I am just using addChildInstance with transforms, so it probably does.

I created a fork of 1.6.1 and added the changes. I am not too happy with the way I solve multiple imports in the same scene, so I have to postpone the PR, but you can check it out here"
https://github.com/alfkr/alembic. Instances cannot be in the maya root at the moment, must be grouped etc. Needs to be fixed as well. If you are doing anything more clever, just let me know.

Cheers
Alf

Alf Kraus

Software Engineer

Grid BVBA

Dulle Grietlaan, 1

B-9050 Gentbrugge
http://www.grid-vfx.com

[alf...@grid-vfx.com]

Hi,

I removed all restrictions, and instancing should now work in full. I also changed the behaviour of the alembicNode with static geometry that is linked to it. If there is only one sample in the abc file, there will be no forced dg update for timeline changes anymore, so it can be scrubbed as usual.

Pull request is out.

Cheers
Alf

Alf Kraus

Software Engineer

Grid BVBA

Dulle Grietlaan, 1

B-9050 Gentbrugge
http://www.grid-vfx.com

[Eoin Murphy]

Hi Alf,

apologies for late reply... i was on the road for the last 10 days...

Had a look at your PR, looks promising - I definitely think that the instancing section of the code that you've added could do with some unit testing, as round-tripping of this data will inevitably throw up some problems.

When I mentioned nested instancing, I was referring to making a set of instances in maya, then instancing the whole lot again, fairly common in environment workflows etc. I can send you an example or two when I'm in front of maya.

Another thing worth testing is the mismatch between the 2 instancing models - as you know, maya uses a multiple-parents one-child instancing model, whereas alembic uses a more standard referencing based model​..and there are a few edge cases where one approach can express an instancing relationship the other can't.

Thanks for your hard work,

Eoin