Home Website Youtube GitHub

P4 (Perforce) Pre/Post build script sharing

Support
#1

Hey all!

Wanted to find out what people are doing in studios that are using P4 for version control and sharing their scripts with other users and having to deal with file paths changing between users?

Look forward to hearing all about it :slight_smile:

All the best,
Jascha

2 Likes
#2

Back in the day, in Lionhead, we used to have a virtual drive Z: mapped to p4 depot. This way everybody was always having the same path for everything, importing assets, deploying tools etc.

1 Like
#3

Hey @Milio,

Thanks so much for your response on this one man! Funny as you have shared this wisdom, this is something that we are currently doing on the larger scale of things as well. Seems to be the only way with P4 related aspects.

Thank you so much! Much appreciated!

#4

Nice!! It does make a lot of sense to me!! Wuite surprised when studios, either big or small don’t seem to embrace it. in here, in this project I am on at the moment is not like that… all pipeline, P4, etc relies on the assumption you having a F: drive in you computer to work properly… :pensive:

1 Like
#5

we also have everyones workspace root point to the same place for a project, also a mapped to a virtual z drive. this is fine for a single project but not ideal sharing across different projects with different roots.
also.

2 Likes
#6

@Milio It is such a simple solution actually. Initially, there was some push back and a bit of concern about it. Once explained out the problem set as to why we needed, it was a bit more accepted and also in the way it will be handled. P4 does complicate having an easy way to set projects without some sort of user intervention, which makes tooling a bit more of a headache versus being on a central server where everyone has the same mappings.

@JimBo_Drew we are doing some research into multiple projects problem at the moment. Our pipeline will create and destroy on the fact that users are changing between workspaces and projects. It is a headache and I do not envy our pipeline TD at the moment with this :rofl:

I am crossing fingers that this will be the solution for easy sharing of pre-post build scripts.

If there is more information that you guys have on this, I would welcome it with open arms. Appreciate all the knowledge shared! :kissing_heart:

#7

I don’t have any P4 tips specifically. But this is everything I do to keep things relative.

Some of this might be obvious or wrong. I hope I’m not missing the point of your question. Maybe there are some P4V challenges I’m unaware of. I’m just listing everything I can think of, hoping some of it helps someone. Please let me know if you disagree with any points! I’ve never set up mGear in a large studio, so I am not extremely familiar with complex environment setups.

  1. No mGear files in Maya prefs. We keep mGear in a production drive, and install it with MAYA_MODULE_PATH in Maya.env. (That also makes it easy to quickly swap out versions for different projects.)
  2. All custom modules are also put in a production location: MGEAR_SHIFTER_COMPONENT_PATH = /production/mGear/tools/mgearCustomModules
  3. Set a production build directory, so all Python PRE and POST scripts will run relatively from here: MGEAR_SHIFTER_CUSTOMSTEP_PATH = /production/mGear/build
  4. Also keep all character data (skinning, lips, eyes config files, etc.) in /production/mGear/data
  5. Each character gets a new [CharacterName] folder under “build” and “data” directories. I second-guess decision this often. I sometimes wonder if it would be better to keep everything relative to each character…
  6. There is also a “common” directory, where scripts are stored that are the same for all characters. And of course a separate place for imported modules in the PYTHONPATH.
  7. Since all scripts are relative to MGEAR_SHIFTER_CUSTOMSTEP_PATH, you can find relative paths like this in Python, to find the data folder for skinning:
    postpath = os.path.abspath(os.path.dirname(__file__))
    basepath = os.path.abspath(os.path.join(postpath, '../../..'))
    character = "YOUR CHARACTER NAME"
    configFile = 'leftEye.eyes'
    eyesConfigPath = os.path.abspath(os.path.join(basepath, 'data', 'characters', character, 'configs', configFile))
  8. In the point above, my left eye config file is called “leftEye.eyes”. I name all config file exactly the same for every single character. All skin pack files are always called “skin.jSkinPack”. The only variable is the character folder which matches the rig name.
  9. Instead of os.path('../../../') it would likely be smarter just to define an environment variable as well. But I personally wouldn’t suggest keeping data (skinning) and scripts together, just to keep cleaner version control. I want to keep my build scripts separate from my skinning data. But… I wish I had kept config files together with build scripts. Skinning (including ngSkin json files) is the only thing I really want to keep separate.
  10. In my post Python scripts I like to use collections.defaultdict as a way to set default values for variables, that can be overridden by the character rig name, if it exists. If it doesn’t exist, it uses the default value.
  11. I think it would be a very nice feature request for mGear to handle additional arbitrary metadata. Just like character names, it would be nice if you could include project names, character type, or any other data you choose.

So as far as I can imagine, the only difference between users should be where they define MGEAR_SHIFTER_CUSTOMSTEP_PATH and install the mGear module differently, if they are on a different OS, or the production drive is mounted differently. We weren’t using Perforce, but we were building rigs on both MacOS and Windows.

2 Likes
#8

Hello!

Thanks for sharing knowledge!

I wonder how do you handle core character and its variations with Custom Steps? I have a problem that versions of the main charcter are changing every now and then. Each time, I had to manually rebuild a variation after a main character got an update. Could you enlight me how to tackle this problem, please? I have been thinking about starting using GitHub so every rigger has access to scripts. What do you think about it?

All the best,
Pit