Jump to content

Cloaked.conf functionality in Gluon


Mitch
 Share

Recommended Posts

Hi, I was curious how one would replicate the functionality of a cloaked.conf file in Gluon. My specific use-case is that we have a repository for the artists on our project, and while I need access to some of the character Maya files for animation, I don't need all of the Zbrush/Substance/etc files. In PlasticSCM I would just add 'Zbrush' or '*.ztl' to the cloaked list and never have to worry about it. But with our directory structure, where each character folder has its own Zbrush folder, I have to manually exclude it for each character, and remember to do so any time a new character is added.

Ideally, I'd like to be able to just configure Gluon so it never downloads any folders named Zbrush/Substance/etc rather than manually excluding them.

Is this possible?

Link to comment
Share on other sites

Hi.

As you know Gluon by design has this functionality without the need of using a "cloaked.conf" file. You can configure your workspace to download the items you actually need.

But I'm afraid it cannot be preconfigured via configuration file. I'm guessing if you could share your ".plastic/plastic.wktree" with a coworker, this was you can have the same configure rules predefined. But this workaround needs to be tested ( I'm afraid it's not officially supported).

Regards,

Carlos.

Link to comment
Share on other sites

Sorry, I might have phrased my question a bit poorly. I'm not actually trying to share a workspace configuration with anyone else, I just want to be able to configure my workspace so that I can exclude particular file-types or folders of a certain name from ever being downloaded from the server, similar to putting them into the cloaked.conf with the regular Plastic client.

Link to comment
Share on other sites

  • 2 months later...

Hi! I'm evaluating PlasticSCM Gluon for our art-team, and we're in the same situation as @Mitch, except that we'd like to configure which file types are downloaded by default for the whole team. Reading through the docs, I thought cloaked.conf was supported by Gluon. As I now know, it is not.

We'd only use Gluon, since little to no code is involved. We're adding new asset folders on a daily basis. Each contain the big source files, like ZBrush & Substance Painter files, as well as the lightweight export format, e.g. GLB. Ideally, we don't want to separate working files from export files, to avoid maintaining parallel folder structures.

I expected the following behavior: Add file types to cloaked.conf, and when selecting a folder in the Gluon workspace configuration, it will not select (load) those file types, even though the parent folder was checked green. It would still show the file types to be able to select them manually, if needed.

On 10/14/2021 at 9:36 AM, calbzam said:

As you know Gluon by design has this functionality without the need of using a "cloaked.conf" file. You can configure your workspace to download the items you actually need.

With current behavior, when we'd update the asset library (consisting of lightweight formats), all (hundreds) folders would have to be configured in manual mode by all team members, several new folders a day... just to avoid the big files. This is not the same behavior as with a cloaked.conf.

The file search only allows for positive matches of a single file type. It can't exclude files from the search. Doing the search numerous times for all kinds of files that we do want to download (e.g. different image formats), just to avoid a few certain other files, is also not feasible.

Can this situation be made easier with Gluon? Right now, it's kind of a show-stopper for us. We wanted to switch to PlasticSCM/Gluon to make things simpler and more comfortable, not more complicated and cumbersome.

  • Like 1
Link to comment
Share on other sites

Good to hear it's not just me.

This is still a regular issue for me, to the point that I'm finding Gluon to be more cumbersome than just dealing with regular PlasticSCM client. Constantly having to manually manage which folders to include and exclude whenever new assets are added is a real problem.

Gluon is presented as a tool tailored for artists, but this is something teams of artists need to be able to do.

Would really appreciate a way to get similar functionality as the cloaked.conf file.

Link to comment
Share on other sites

Hi,

cloaked.conf is a configuration file only available for the Plastic GUI.

If I properly understand. you would like a similar feature so you can configure similar rules than the supported in Plastic GUI (file types...) but in Gluon?

Regards,

Carlos.

 

Link to comment
Share on other sites

22 minutes ago, calbzam said:

If I properly understand. you would like a similar feature so you can configure similar rules than the supported in Plastic GUI (file types...) but in Gluon?

Thanks for your answer. Yes, be able to have certain file types configured in Gluon to not be downloaded/updated by default, but have the option to manually download them. This would allow our artists to not be downloading several GB of data with each update (newly added folders to the library), but still get the smaller files they need from these new folders, without manually configuring many folders before each update.

14 hours ago, Olaf said:

when selecting a folder in the Gluon workspace configuration, it will not select (load) those file types, even though the parent folder was checked green. It would still show the file types to be able to select them manually, if needed.

 

Link to comment
Share on other sites

As an example, this is what I have been having to manually configure every time a new asset is added to the repository. I am only interested in syncing the "Maya" folder under each asset, but the character artists need the Zbrush (*.ztl) and Substance Painter (*.spp) files. Those assets are gigabytes in size and so anyone who doesn't need them shouldn't be syncing them. Currently, the character artists need to say "hey, there are new folders you need to add to your config" whenever a new asset is created.

This could be solved if I were able to specify file types or folder names to exclude.

image.png.e19bd199b7bf0dff175f3f5c7f761a7f.png

  • Like 1
Link to comment
Share on other sites

A curious thing just happened: Gluon seems to care about the cloaked.conf when you try to delete a cloaked file. Tried to delete a file in Gluon which type is listed in the cloaked.conf and got an error message that the file cannot be deleted, because it is cloaked.

Link to comment
Share on other sites

  • 1 month later...
  • 2 months later...

Hi @Mitch,

Can you clarify what is your current problem?

If you have a Gluon workspace that is not fully checked but you just have configured a few folders in your workspace, only the changes that happen in these folders will be automatically updated to your workspace.

Regards,

Carlos.

Link to comment
Share on other sites

Our situation is that we have a repository for the source art in our game project. It contains source files for our characters (e.g. Zbrush, Maya, Substance, Houdini), animations (Maya), environment (Blender, Houdini), and more.

The animation team (my dept) need access to some of the character assets for rigging and animation, but not all of the gigabytes worth of Zbrush sculpts and the like.

The folders are structured so each character has its own subfolders for different types of assets. I only want to sync the Maya folder for each character.

I want to just say "Sync the characters folder, excluding these file types" which is trivial to do with the regular client. With Gluon, I have to configure the workspace, and only include the specific 'Maya' folder for each character. Then, when a new character/outfit/prop/etc is added, I need to go back into the workspace configuration and manually include its respective Maya folder.

Same goes for any other type of file stored under the 'Characters' folder which I want sync. It needs to be manually added to the workspace, because I can't just tell Gluon to keep the whole folder up to date. The cloaked.conf (or something like it) would make this incredibly simple, because I could just tell it to skip .ztl or .spp files, and wouldn't need to continually reconfigure my workspace.

Link to comment
Share on other sites

On 5/20/2022 at 1:45 PM, calbzam said:

Hi @Mitch,

Can you clarify what is your current problem?

If you have a Gluon workspace that is not fully checked but you just have configured a few folders in your workspace, only the changes that happen in these folders will be automatically updated to your workspace.

Regards,

Carlos.

Hey @calbzam. I thought the problem was quite clearly explained. Having the same issue as Mitch in our team, I can also just repeat what had been said before, and why your suggestions with the current functionality aren't a solution.

Example of current problem:

Create a new repository. Artist 1 starts working on an asset in folder asset1/, and adds zbrush, substance, Blender files, and texture maps. Another artist 2 ( eg. rigger or tech-artist) only needs the blender files and textures (put otherwise: everything except certain folders or file types), so they configure their workspace to only include those files in asset1/. Meanwhile, artist 1 checks in a missing texture map. Artist 2 doesn't get the update, because they had to manually load the files. Furthermore, artists 3, 4, and 5 added folders for asset2, asset3, and asset4. Artist 2 has to repeat the same step for each of them, as with asset1/. Every once in a while, artist 2 may need to check a substance or zbrush file.

Now scale that up to more artists and assets.

It's missing a functionality where you can simply define files/folders to not be loaded by default, while keeping in sync with the rest of the repo (load root) when new folders and files are added that you do need to have, without micromanaging them each time.

  • Like 1
Link to comment
Share on other sites

  • 4 months later...

Hi @calbzam

So it's coming up to a year since I posted this question, just wondering if there's been any discussion about the issue internally? It's still routinely an issue that we come up against in our production workflow.

Link to comment
Share on other sites

  • 1 month later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...