pipeline with alembic

84 views
Skip to first unread message

illunara

unread,
Apr 2, 2015, 11:14:11 PM4/2/15
to python_in...@googlegroups.com
Hi everybody
I have a question with maya's alembic. While the render processing, if i override an alembic file, which got imported into scene, it behavior really strange. Maya didn't actually import the alembic file, but just reference it, and keep reading it every frame, if i not mistake.

What should i do in this situation? Thanks

Justin Israel

unread,
Apr 3, 2015, 5:11:20 PM4/3/15
to python_in...@googlegroups.com

Don't overwrite files that are being actively rendered?


--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/bf049fe4-f109-4acf-a417-03a0d7b29ef4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Tuan Nguyen

unread,
Apr 4, 2015, 5:35:00 AM4/4/15
to python_in...@googlegroups.com
Hi Justin
Currently, we keep as much version-up file as possible, but only one final file (maya or alembic) for reference. While rendering process, we got a feedback from customer, and accident override the old data, and you know what happen later.

Can we know which files being used, or should we find another way to deal with it? We still going on our pipeline. Thanks

Justin Israel

unread,
Apr 4, 2015, 6:38:04 AM4/4/15
to python_in...@googlegroups.com

I don't have much experience with alembic specifically, but from a general perspective it might be a good idea to revisit your queue submission process in combination with your versioning and publishing system. If new versions published can overwrite data associated with previous publishes, that seems bad. I would say,  sure, you could go about checking access times on files, but that seems like it should be unnesseccary. Is there a specific reason you can't keep isolated to each version and just stick to a disk management policy of N recent versions? Or maybe I don't understand the problem correctly.


--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

Tuan Nguyen

unread,
Apr 4, 2015, 7:34:56 AM4/4/15
to python_in...@googlegroups.com
Yes, we already kept version isolated to each other, however, to avoid that we will have to change the reference path everytime new version get published, we make a final version which actually the lastest published version, so it get update automatic.

In our company, since artists used various 3d program for different tasks (like maya, max houdini...) we using alembic for data exchanging.It light,easy to used, supported by many software. But the real problem here is not about alembic, but the pipeline we working on, i guess ;)

Marcus Ottosson

unread,
Apr 4, 2015, 7:58:44 AM4/4/15
to python_in...@googlegroups.com

Though I’d agree that overwriting caches to avoid updating is risky, and that a better approach is to try and handle that more efficiently so that it wouldn’t be so tedious (i.e. a version manager of sorts), there might be something else you can do to work yourself out of this corner; at least temporarily.

How about this; when sending anything to be rendered, it makes a copy of the alembic and renders that. Once finished, it can remove the copy and the next render would do the same.

To keep copies from adding up, you could cache the copy at a global directory in which each file is unique and perhaps dated. Then, when a rendering machine is about to make a copy of the file it’s about to render, it could first look in the cache it is has already been copied.

/server/scene1/character1/final.abc
/server/cache/final.20150404-125612.abc # With creation date of original

On 4 April 2015 at 12:34, Tuan Nguyen <cb.il...@gmail.com> wrote:
Yes, we already kept version isolated to each other, however, to avoid that we will have to change the reference path everytime new version get published, we make a final version which actually the lastest published version, so it get update automatic.

In our company, since artists used various 3d program for different tasks (like maya, max houdini...) we using alembic for data exchanging.It light,easy to used, supported by many software. But the real problem here is not about alembic, but the pipeline we working on, i guess ;)

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

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



--
Marcus Ottosson
konstr...@gmail.com

Tuan Nguyen

unread,
Apr 4, 2015, 9:00:00 AM4/4/15
to python_in...@googlegroups.com
Thank Marcus
That's a good way. However,  i want to keep data as optimize as possible, for a large-size project, duplicated data will be a pain to handler later.
I wonder how big company manager their data :D

Marcus Ottosson

unread,
Apr 4, 2015, 10:57:53 AM4/4/15
to python_in...@googlegroups.com
Well, even amongst big studios there is no consensus on how to manage files; it varies. If you want consistency, it's possible that you might have to trade it in for some extra work on behalf of your artists, such as having them make sure their versions are up to date before submitting anything, instead of relying on overwriting files.

Once that's done, you could instead work towards making it less painful for them, such as introducing a nice visual interface in which they can see whether there are any new versions, perhaps a notification of sorts to let them know, or a publishing mechanism* to check whether the latest version is the one about to be submitted for render.

*I'm one of the developers.

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

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



--
Marcus Ottosson
konstr...@gmail.com

Tuan Nguyen

unread,
Apr 4, 2015, 2:01:40 PM4/4/15
to python_in...@googlegroups.com
Oh wow. That's look great, thank for sharing :D
I think i will join your conversation too

Justin Israel

unread,
Apr 4, 2015, 4:14:29 PM4/4/15
to python_in...@googlegroups.com

I was also thinking of the approach of copying your data to a temporary area at render time, prefixed with the render job id. But I wasn't sure how big the data was. It would be a bit cumbersome if the data is huge. But it could be cleaned up either at the end of renders or periodically by access time.
ideally though, it does come down to your version and publishing system, and how you reference your files.


On Sun, 5 Apr 2015 6:01 AM Tuan Nguyen <cb.il...@gmail.com> wrote:
Oh wow. That's look great, thank for sharing :D
I think i will join your conversation too

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

Tuan Nguyen

unread,
Apr 4, 2015, 11:02:35 PM4/4/15
to python_in...@googlegroups.com

Thank Justin
I will take a deeper dive into it then :)

You received this message because you are subscribed to a topic in the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/python_inside_maya/Lvv9ZglXSLQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0qcTKd6tQRXuixwBuOvqQXdVGLbcdS4tiphc8EuuJ6nQ%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages