Pipi // The Visual Effects Pipeline


Hi guys,

We’re developing a new product for the commercial and film industries called Pipi that deals with the interaction of artists within a digital content creation production and we’d love to hear what you think of it.

For more information, visit our freshly published website and let us know what you think by commenting right here, or by just signing up at -

www.pipi.io

What do you think, is there a place for Pipi in our industry?

Looking forward to hearing your comments!

Best,
Marcus Ottosson
Founder
www.pipi.io
www.linkedin.com/in/marcusottosson

I’ve looked at your website and viewed the video but I am still none the wiser as to what it is pipi actually does.
When you publsh something, how do you specify what you want to publish?
Does it handle dependencies like model textures or other custom data?
Does it work with version control software like perforce?
Does it use plugins that will have to be recompiled for each new version of each dcc app you have, or does it use scripts where possible?
How much is it?

At the moment I dont think you are doing yourselves any favours, you dont explain much about the product. How about an FAQ.

Hope this is useful feedback

You’ve seen Shotgun, right?

nope, not really. Heard the name

As most of my time is spent working on Asset Management tools this certainly caught my attention but i’d echo both NeilG’s and cgjedi’s comments.

We need far more information, a short animation doesn’t give anywhere near enough detail to make any form of judgement, and as your primary competitor is Shotgun it would be great to get a side-by-side comparison of what Pipi has over it.

Shotgun has been, and pretty much still is aimed very much at the VFX industry, but it leaves a fair bit to be desired where games studios are concerned ( Perforce integrations etc ). Its interesting you have aimed your development at an audience that has a solution, but i’ll reserve judgement until we get more info!

At the risk of re-iterating Neil :

  • What is it written in, how much of the source is accessible?
  • How extendable is it, are there callbacks to add custom save/load/publishing code
  • What source control bindings are there
  • Does it run of an SQL back-end, what is the hosting criteria for that
  • What is the roadmap going forward, what applications do you have integrations for now, and what do you plan to integrate with in the future

Mike

Valid questions, I’ll return with more as I’m not currently at my computer but for now I’ll leave you with that I’ve worked with quite a few established pipelines in the past in both commercials, features and games, and I know exactly what you guys are missing from our cute and short animation. We chose to first target the broadest of audience with the most basic explanation as to how this could work (so as to be more illustrative to outside investors).

:edit:
Some of the technical goals; Python is the language of choice, Qt for user interfaces. We are looking at developing an event system that TD’s can hook into via an API and rather than storing metadata in a database, we are looking into using localised files, similar to how OSX does with .DS_Store.
:edit

Our first target is the newly established studios without an existing pipeline and we aim to slowly and steadily work our way towards larger and larger productions until Pipi is robust and flexible enough to fit a feature film environment.

Thanks so much for your questions guys, very much appreciated. I will return with more, feel free to provide more questions, we are very happy to hear what you find most important in your production environments at the moment and what you think would be important for any newcomers looking for a pipeline for their productions.

As you said, your animation is more targeted for persons that really isn’t involved with working with the actual pipeline and trying to sell your product to them. But I think that when that person goes to his technical director or equivalent, he will have the exact same questions as people already said here. And I do believe that TD will be hard to win over with the lack of information that you have around your product right now.

I have to clarify something! At the moment, that video represents the bulk of work that has been done so far. We have just moved from concept stage to asking artists and td’s about what they think and my hope is that this video together with some more technical mockups of interfaces that I will post here in a bit, will be a good starting point for others to get a glimpse of what the goal of Pipi is, so we can work together in making it as useful as possible.

I believe that you guys here at tech-artists is just what it needed at this stage prior to developing any code, because I’m sure my experience differ greatly from your individual experiences. My goal at the moment is making sure I’m not barking up the wrong tree and that the little you have seen so far actually makes sense and might be of use.

In regards to Shotgun, I’d like to think of Pipi as a complement to Shotgun, rather than a competitor. In fact, Shotgun is one of our early targets for integration, just because it deals so efficiently with task management and scheduling.

Well, I don’t see any difference between Shotgun and your video.

Tough crowd, here!

:slight_smile:

I believe we have all come across quite negative but i think its more that we’re all aware of how critical the details are in systems like this. The high level concept may be fine for an end user, but as the people that have the responsibility to integrate and maintain Asset Management tools its all about understanding how it works under the hood rather than on the surface.

Can you give us more details on how you envisage your system working? Maybe a flow graph representing workflow, file flow and levels of expected code exposure/customisation. Even if its just at the concept stage it would be great to see how you’re planning its development, that way we might be able to give some constructive feedback on how we all work and how we think we’d use a tool such as Pipi.

Mike

[QUOTE=patconnole;21917]Tough crowd, here!

:)[/QUOTE]

Haha, its ok, I don’t blame them. I should’ve made more of an effort to clarify how fresh the project was and what our goals were.

I just returned from a StartupWeekend event here in London (where we got an honorary mention!) and have been hard at work thinking about how to simplify the idea to anyone who asked us what it was about. Trying to explain a cg pipeline to someone outside of our industry is actually quite the challenge. Luckily that animated film proved quite useful. :slight_smile:

[QUOTE=MikeM;21918]I believe we have all come across quite negative but i think its more that we’re all aware of how critical the details are in systems like this. The high level concept may be fine for an end user, but as the people that have the responsibility to integrate and maintain Asset Management tools its all about understanding how it works under the hood rather than on the surface.

Can you give us more details on how you envisage your system working? Maybe a flow graph representing workflow, file flow and levels of expected code exposure/customisation. Even if its just at the concept stage it would be great to see how you’re planning its development, that way we might be able to give some constructive feedback on how we all work and how we think we’d use a tool such as Pipi.

Mike[/QUOTE]

Thanks, MikeM. I’m preparing this material for you guys as we speak and will share it with you within the week. I’ve got quite a few detailed plans for its upcoming development that I’d love your feedback on.

At a high level it looks pretty nice. I’m not too worried about the low-level details, as perusing your linkedin, it seems you’ve been around the block and probably have seen multiple pipelines and learned from that. I would agree that it’s not like shotgun, but here is the deal. shotguns new pricing model is that you get all the shotgun apps for 49 bucks. What you are making is essentially “tank” (shotguns publishing system) I would say, your only bet is this. Make a kick ass publishing system, and make it cheap. I think your right in having it developed for small studios and then work your way up.

IMO I actually like what your doing with the videos, it’s a much more agile approach. Instead of taking weeks to get it running, and then having to decide whether or not to throw it away progress, you draw it and get feedback, before the bulk of the work gets done.

Thoughts
1)it needs to be very customized (vfx versus animation versus game)
2)it needs to be cheap. ($50 per person/per month, I personally hate this pricing scheme, I don’t think it scales well, and it’s not worth it for small teams)
3)it needs to be very accessable api. Cause lets face it, like people have said above, the tech guy is going to make the final decision…

looking forward to this product…

That is great feedback, thank you! These are some of the things I hope to talk to you guys about, aside for the technicalities of course.

Yes, easy integration in external software was one of the first things that came to my mind …

Usability is another big thing for me. We are always trying to make the next big feature, but good UI design can make a bigger differences sometimes …

Thanks for your feedback, Nysuatro! I’m with you on that user experience is important. In fact, I think it’s as important as its featureset.

What is Pipi…
…to the technical artist?

Beating the bush

Ok, I think it’s safe to say that what we’re developing is already being developed in several places on this planet and is something that many of you may already familiar with. What we have done is recognize that not everyone has this luxury, especially the little guy. Our goal then is to make the most elegant and beautifully designed solution we possibly can and then make it available to all.

$$$

We love cg. We work with it every day. And whether Pipi is to be distributed for free, as open-source software or in some other way sold will depend greatly on the feedback given here. Our primary objective is for Pipi to grow to be as beautiful as possible so that it may be useful enough for one, ten, or thousands of users. If the way to get there is giving it away for free or selling it on a per-user basis, that’s what we’re here to figure out. The way we do get there is up to you, me, and all of us together. Starting now.

Our mantra is…

enable artists. This means building a foundation upon simple ideas. Simple enough so that when a tool fails, you know what to do. Too many times have I experience situations in which the tool, blindly trusted upon, fails - leaving the user helpless and in need of technical support. To truly enable, the user must be given a choice.

Our design is…

…beautiful. We believe frustration degrades productivity. And one of the ways frustration is born is through the way in which we interact with our tools. That is why user experience and its technical implementation bear equal importance to us. Suffice to say, we build from the user experience, not towards it.

Where we are

We would like to think of Pipi as Process Management, rather than Task Management. This is where Pipi fits in compared to existing Task Management Suites, such as Shotgun and FTrack.


Task Management vs. Process Management

Development

We love agile development methodologies and the lean startup method and recognize that no process is a linear as this. Thats one of the reasons why we’re here. Our initial goal is for Pipi to become useful to 1 studio, reasonably small yet know what they want and how to go about doing it manually. We are on the lookout for one that is interested and fits the role of the earlyvangelist.

From there, development will orbit around what is most urgent to them. We will then branch outwards into a closed-beta. A cycle which we’ll repeat for each of the main development areas - foundation, usability, tools - until we then move on to the next area of application - Pre-production, Animation, Post-production - covering aspects from Animation, VFX and Games as separate beasts.

I’ve tried to illustrate this process (click to enlarge)

Benefits, not features
We’ve broken down the most basic usage of a pipeline to a set of 6 set of tools. Those are Dashboard, Editor, Library, Publisher, Inspector and Manager.

Dashboard
This is what each user of Pipi will be most familiar with. It serves as an entry point for each artist at the start of each new day. It is where the user specifies what to work with and in what application. The Dashboard then sets up the environment and runs the application.

Editor
Authoring assets or shots, the Editor is where metadata is modified.

Library
For browsing available assets

Publisher
For creating an inactive (aka published) asset

Inspector
For exploring metadata and events

Manager
For loading and modifying instances of assets from within a DCC application, such as Maya.

From here, we will move on to more complex benefits, catering to extensibility and debugging followed by in-the-dirt tools used by artists in specific disciplines, such as utilities for the animator or setup artist.

Illustration here (click to enlarge)

[HR][/HR]

I’ll hold off showing you actual designs and prototypes until next time. TMI! TMI my friend! :slight_smile:

Let me know what you think!

Best,
Marcus

FAQ

Wait, who the hell are you?
My name is Marcus Ottosson. I’ve been making beautiful cg since 2008, time spent at over 10 vfx studios across Europe ranging from commercials to feature film to idents to triple-A game cinematics.

The video on your website doesn’t contain all of the information I need
It doesn’t. But we hope it provides you with enough of an introduction to understand our initial goals.

Isn’t this basically Shotgun?
No. Shotgun connects people. Pipi connects the software that people uses.

Python, python, python
Yes. We develop with Python and Qt.

I’m using software [X]. Will it be supported?
Where there’s a will there’s a way. We’ve been successfully prototyping with Maya and Nuke and aim to cover all of the packages that you use. Let us know what is important to you and we’ll move it higher on our checklist.

What about a database?
Yes, who needs 'em. Pipi runs under the Unix philosophy “Everything is a file”. That, coupled with a technique similar to the localised metadata storage used by OS X (.DS_Store), help keep the guts of Pipi simple and logical with very small learning curve.

How about version control?
I’ll have to rely on you to light the way in this regard as I have no experience with Perforce or other any off-the-shelf solution to binary media revision control, nor have I heard or seen of any DCC house (besides in games) that make use of it.

Will we have to reformat our folder structure to work with Pipi?
No. Our mantra is “Enable Artists”, rather than “Enforce Artists”. Pipi wraps any existing layout you might have (given it is logical) and provides a unified way of accessing content through code rather than static filepaths.

I need more information
Just ask.

It might be good to constantly reflect on both sides of artist and programmers.

How do you make artist feel good about using this product?

  • Do they have to learn something new or are you using things they already know?
  • Is there visual progress of their process?
  • How much visual transparency is there of what the tool can do and how do you bring these to the user?
  • How do you guide the user when doing something wrong?

How do you give access to the programmer so he has clear data to work with ?

  • How much control will you give and how much automation will there be?

  • What kind of support will there be when having problems with the API?

  • What about stability?

  • How does a programmer has to deal with updates and is there a way to avoid risky situations of corrupted data?

  • What are the constraints of this product?

I hope these questions can keep the discussions going :slight_smile: Very interesting topic!