Giter Site home page Giter Site logo

Comments (12)

mottosso avatar mottosso commented on August 11, 2024

I've given some thought to this, let me know what you think of this workflow.

  1. A shot is entered via mb.bat, such as sh010
  2. An environment is created, via loading assets
  3. Static models are re-published as a new combined asset, as a model
  4. Rigs are also re-published as a combined asset, as a layout

In the Pyblish GUI, you would see both instances.

Once complete, in the Loader, there would be two new assets.

sh010
  environmentDefault
  layoutDefault

The artist interested in animating the rigs from the environment would then load layoutDefault, and optionally environmentDefault if needed.

The one problem I foresee is that if we use Layout for the placement of characters, and if we don't do this in the environment scene along with other assets, then we would be publishing a second Layout for characters.

sh010
  layoutEnvironment
  layoutCharacters
  environmentDefault

But perhaps that is ok?

from core.

CalleHalldin avatar CalleHalldin commented on August 11, 2024

I like the idea, i think it could work.
What happends if we update the rigs? Is the (reference) connection to the original asset still there after the "re-publish" or do we have to go in to each layout scene, update the rig and publish the layout again?

from core.

mottosso avatar mottosso commented on August 11, 2024

If we go with a layout family, then I'd imagine versions of the rigs not to be included in the published assets. Instead, the latest version is chosen whenever the layout is loaded.

So a layout asset would merely contain this.

  1. For each contained asset:
  2. Name, e.g. Greta
  3. Subset, e.g. rigDefault
  4. Default values on the controllers

Practically, I'd imagine the layout only being used once and never needing an update. The Animator will have started working on it, and would update the asset in his scene.

But I may be wrong here, in what scenario do you see someone updating a layout?

from core.

CalleHalldin avatar CalleHalldin commented on August 11, 2024

Maybe i misunderstood your original post but this would all happen inside the setdress scene where they would create the camera and environment for animation and render team correct? If that would be the case the layoutEnviroment along side with environmentDefault would be updated many times parallel with animation. Usually the rigs we are speaking of, like a tree will usually have a simple cycle and not be touched by the animator. If the animator will use it as a part of the preformence then its the animator who will continue to tweak the place the tree. Maybe its our workflow on how we handle ambient/cycled animation on environment assets that needs to be re-worked. We usually use rigged eviroment close to camera and tweak the cycles so incase you can't see the motion clearly enough we scale the curves up or if its too much we scale them down. I'm open to suggestion on different workflows. I will have to ask the layout artist tomorrow if there is any other usage for a rigged eviroment asset besides for cycles unless the animator is suppose to use it.

from core.

CalleHalldin avatar CalleHalldin commented on August 11, 2024

Seems like there would be no real reason to have rig besides having a animation cycle (like wind blowing in the leafs of a tree) on it, one small reason would because it easier to move around and to pose but usually the ones with rigs have a cycled animation on it anyway. Perhaps we should look into replacing rigs with animation with cache model of some kind like Roy from colorbleed suggested?

from core.

mottosso avatar mottosso commented on August 11, 2024

Usually the rigs we are speaking of, like a tree will usually have a simple cycle and not be touched by the animator.

Ok, this is good. We haven't talked about pre-made cycles before, that's a new requirement we'll need to take into account for this design.

Could an animator bring in a tree rig and either animate or apply a cycle to it and publish?

That way, we'd stick with the normal workflow for animation, and control could still reside within the hands of whomever publishes the cycles.

Seems like there would be no real reason to have rig besides having a animation cycle

Ok, that simplifies things. Let me know what you think of the suggestion above.

from core.

CalleHalldin avatar CalleHalldin commented on August 11, 2024

The animation of the tree could perhaps be done by the animator. It very much depends on the project. Recent King project for example have mainly been a forest environment, doing Setdressing and applying the animation cycles, exaggerating the motion or reduce it, offsetting the animation on trees and plants along side of placing static assets has allmost been a fulltime job since its a rather busy eviroment with alot of assets. To keep the production as effective as possible (and less expensive) I'd rather have animators doing the hero animation. The reason why it's allmost a fulltime isn't becase it's hard it's because it's just alot of stuff. I'd rather have this to be able to be a separate department for when is needed.
How about Setdressing publishing alembics instead of rigged assets then? And like I said before when a rig that is needed for the hero preformence it's the animators responsibility for all its motion. No real need to have have a rigged assets with a animation cycles in the animation scene if the animator never touches it. That should work right?

from core.

mottosso avatar mottosso commented on August 11, 2024

How about Setdressing publishing alembics instead of rigged assets then?

Yes, that's entirely possible. Try that and let me know what you find.

from core.

mottosso avatar mottosso commented on August 11, 2024

Hi @CalleHalldin, did you try this workflow, how did it go? Anything you need implemented or should I close this issue?

from core.

CalleHalldin avatar CalleHalldin commented on August 11, 2024

Not in a sharp production. This could work as an output to animators, the problem is that you don't get shaders and would have to load some sort of animLookDev for each asset. Also there is no way for the animator to do tweaks to the layout if needed.
I've been giving this some thought and also discussed it with Bruno. This might be a separate issue but I'll let you be the judge of that.
This is how I picture it working:
In the picture of colorbleed launcher they had layout (or setDressing as we are referring it to) in the shot tab. We need this aswell I think.
Like I was saying before we usually do a big environment from alot of separate assets and create a "master scene" based from what was created in the sandbox stage, then we use that master scene as a starting point for the "per shot" tweak and refinement. I would like to keep this workflow intact but instead of using unstable nested references I would like to just like to tell the pipeline what assets that has been used and its position/animation. I would also like to have a script that creates a "placer" rig which is simply just a main control and joint with the right group structure to speed the process of making simple placer rigs. After loading in and placing these placement rigs in the right position we make a "master scene". You will load that for each shot and make the tweaks and refinement and again only export the info to the pipeline which assets was used and what position/animation. If sh030 is very close to sh020 you can also simple load the setDress for sh020 for creating the setDress for sh030.
The animator will load shXX_setDress from the loader and the pipeline will load each assets and also it's position/animation. Rigs will contain textures so that problem is solved and we can also continue refining the rigs if we need to add cycles for some assets in the environment in setDress or if the animator needs a more advance rig.
As a default a placer rig is set to "static" which means that only 1 frame will get exported once exported as an alembic by the animator but the SetDress artist or animator can decide at any point if a rig is "deforming".
What do you think? It kinda goes back to my original though but this would make it possible to work on the Layout/setDressing parallel to animation, adding ambient animation cycles to tres or what not or just simply tweaking image composition it to final.

from core.

BigRoy avatar BigRoy commented on August 11, 2024

@tokejepsen You seemed to have pushed a commit about 5 days ago that referenced this issue? I think it might be unrelated. Is that correct?

from core.

tokejepsen avatar tokejepsen commented on August 11, 2024

Yeah, unrelated. Dunno why that happened.

from core.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.