Published in


AR teams — Best practices for collaborating over Spark AR projects

You’re a Spark AR creator? Cool. But have you ever worked with a remote team on a Spark AR project?

The goal of this article is to make sure you’re gonna be A-Ok while starting to collaborate over projects and be enjoyable to work with while working over Spark AR projects.

It is an exciting moment in a career to start collaborating with other people because it will most probably help you step up your game both creatively and personally.

Now, when the outcome of collaborating doesn’t has to be proven, you might be willing to be sure collaborative work goes as smooth as it used to be when working on your own. And for that, as often, attitude is key.

Being caring with the ones working over your project and communicating well with them are the two things you should always have in mind. Don’t play games because of some ego trip or so.

While you always can talk to your teammates, sometimes, the workload on the team, the translation goofs, the different timezones or even egos of some people can be in the way.

Don’t be the one who doesn’t name anything in your project folders, saves 100 different versions and expects your team mates to figure which one you should start working on. Bollocks to that!

Now, you’re obviously caring and communicative so it’s only about following a few easy steps to make sure it will go as smooth as you are.

This article is all about making sure you’re revealing your inner smoothness over 5 simple points. From project versioning to individual asset naming, let the collaborative fun begin!

Part I : File storage

To the cloud and beyond!

The first thing you’ll want to do is make sure your team can properly access your files. The most common online storage options are :

  • Google Drive (or any equivalent drive system) — what we use for mostly all our company projects and documents. Proper hierarchy of information will make navigation easy and allow everyone to work from the same folders.
    The standard approach is navigating to “drive.google.com/drive/Name”, which involves manually uploading/downloading your files every time a change is made from an internet browser.
    A more modern approach, requiring a bit more setup, is called Drive FileStream. This will allow you to choose certain folders of the drive you want to be “streamed” aka available on your computer. This allows you to directly work from that folder and any changes on your computer will be synced directly on your team drive.
  • Github — an incredibly powerful tool for versioning. It has a small learning curve but is well worth getting into the habit of using.
Choose your weapon

Github is more suited to companies whose employees all share a common coding knowledge base, whereas Drive (Windows, Google, …) is the easy go-to solution that even your parents can use.

Part II : Proper naming conventions

Naming is sharing and sharing is caring.

Now we often agree on a 3 builds max with client but you know how it can go, don’t you?

You might end up completely overwhelmed with 22 different project versions and names that vary from : “PixelHalfHead1.0” to “sparkPixelHalfHeadv1.0.115.occlusionCorrectionTest02.arexport”.

Mum said that there are no problems, only solutions. So to remedy this problem, make sure you set the standard for your files’ naming conventions. One we’ve come to adopt goes as follow :

“Program used” — “Project Name” — “Project version” + “Program version”

Which will give us names like this : spark-PixelHalfHead-v1.0.115

From the name we can gather all the info we need. Additionally we can now easily sort by Name and get the chronological order in which the versions were made.

Part III : Removing Unused Assets

You and your teammates are now able to find the actual files you need to work on, what a time to be alive!

Opening the project though might paint a gruesome picture… That guy/girl isn’t known to clean up any unused assets in the project. And Spark AR has two main areas where this could be problematic :

Assets Panel

Contains all assets imported in the scene. Any unused asset found here will lead to additional file size.
To check if an asset is in use or not, highlight it and look for :

  • Any indication besides the asset’s name
Both the arrow and the “A” show us it’s not safe to delete
  • The “Used By” field in the Properties Panel
halfSphere was likely the first version used, and therefore not necessary anymore

Despite these two checks, you’ll find that some assets still cannot be deleted, else the scene breaks. A quick and dirty way to make sure you don’t make a mistake is to delete the asset but select “Keep”. This will keep the asset in the project folder so if the deletion has a negative impact, you can quickly Ctrl/Cmd+Z backwards. If deleting the asset didn’t change anything, roll back the change and delete for good, choosing “Delete” this time.

Choosing Delete will remove it from the project folder completely

An exception to this are Patch Assets. When deleted, all instances of the Patch Asset in the Patch Editor will be converted to Patch Groups, maintaining functionality.

Patch Editor

The Patch Editor is where most of your logic will live in Spark AR. It’s a visual coding interface that allows you to create “If/Else” statements and the likes to trigger different parts of your effect.

As such it often becomes the playground for all of the experimentation. This can lead to entire chains of patches being discarded in favour of an alternative or simply in virtue of not being needed anymore.

A few things to clean it up :

  • Remove any patch chain that doesn’t lead to an input, aka isn’t affecting our scene in any way
Blend — Shader Render Pass leads nowhere and can be deleted
  • Make use of the “Commenting Around” feature. It will allow you to create a customisable frame both in name and colour. Segmenting parts of your effect like this will make it easier to move things around.
Side benefits include being much more satisfying to look at
  • Get familiar with Senders & Receivers. Remember the days of dragging your input from one side of the patch editor aaaaaaaall the way to the other side? No more.
Sent on one end, Received on the other. Bellissimo
  • Make use of Patch Groups. As mentioned above, Patch Assets can be created as well as imported into a scene. A Patch Group is the step right before converting it to an actual Patch Asset. Generally, Patch Groups are best used to abstract parts of the project, whereas Patch Assets are best when something needs to be used more than once
Left : patches selected — Middle : patch group created, right-clicked + possibility to convert to Patch Asset — Right : Group properties expanded

Part IV : Proper naming conventions

didn’t we do this already??

Let’s recap what you and your teammates should have right now :

  1. A common place to find your project folders
  2. Proper names to each project file so everyone knows which one to open
  3. No unused assets in the opened project

The next step is to persevere with the naming! (Yay) Now that we have only assets that we know we’re using, we might as well make sure they’re all aptly named. This will help identifying which assets are related to one another and generally improve readability of your project tremendously.

As shared above, here is an asset naming convention we use in our projects :

“Asset Name” — “Asset Type”

Which, in the case of a face texture for example, will lead to :

  • a base texture to use : glowFace_tex
  • a material using that texture : glowFace_mat
  • a facemesh on which the material is applied : glowFace_fm
Set yourself up for success, not failure

Part V : Layers

Although not always necessary, some projects will require you to make use of Layers. Similar to how they work in classic 2D graphic software like Photoshop, layers will help Spark AR understand what item is meant to be in front or behind the others.

The most common use case in which layers become mandatory is occluders in 3D. You’ll want Spark to properly understand the 3D scene you’re giving it, and will likely have to make use of layers to achieve the result you want.

A good rule of thumb is to create different layers for different parts of your effect. The project below creates a pixelized effect on the face but also adds a 3D item and uses facial deformation. As such different layers were created for the troublesome features : the occlusion and the face deformation.

Create layers form the Layers Tab or directly from the Properties Panel


You and your team should have an easy to find project, uncluttered when opened and easily readable. This should make it much easier for people to inherit each other’s work and thus save valuable time over the duration of the project cycle.

Adhering to these steps will also ensure you are perceived as an absolute Chad of cooperation, instead of being that one guy/girl the entire office talks about behind their back 😜

DISCLAIMER: You’re not Captain Planet. The team is ❤

Author: Boris Josz
Contributors: Josh Beckwith, Laszlo Arnould



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store