Publish - An open source pipeline tool

The normal way to perform these checks is a tool plugin, e.g. hooked to asset export. Such scripts are going to be very specific to certain asset categories, limited to one project (but possibly easy to recycle and adapt), continually evolving, and integrated with databases and asset pipelines on their own terms: only basic building blocks (e.g. verifying that an alleged manifold mesh has consistent normals) and reporting infrastructure are plausibly useful products.

Hey Lorenzo, thanks for your comment.

Yes, that sounds like the general idea here as well. Publish would be launched from within a creation tool and then validate content prior to exporting it onto disk. The focus of Publish here lies in the validation process.

The reporting to infrastructure is meant to be handled separately, either by listening on events triggered by Publish, or via callback on the actual publishing mechanism. The same goes for actually organising the output; Publish will make no attempt at storing it consistently together with content throughout an organisation, but rather store it relative the current working directory. The signal/callback would then provide the path to where the files have been published, so that other processes could manage notifications and organisation.

Pluggability is key here, Publish is meant to facilitate being plugged into any existing habits or conventions, without providing an exhaustive list of features that are unlikely to hit all targets anyway. Quality assurance for content is what we're going for thus far, and I think this could safely be handled separately.

I take it this sort of tool isn't particularly common/useful for those visiting this particular forum. Does anyone know of a more appropriate forum I should be posting on? Thanks in advance.

I take it this sort of tool isn't particularly common/useful for those visiting this particular forum.

I tried to explain that those who want this sort of tool tend to write their own, and your project, being too new, doesn't offer anything of value for that purpose yet, nor an alternative to custom development; and it isn't even promising vaporware, because you don't describe any novel and compelling vision.

Your announcement is simply premature: it's about you beginning to work on asset validation, not about actually existing asset validation software that people can try and get excited about.

A background question: why are you specifically interested in asset validation? The same technology could be applied to make other more interesting and presumably more valuable product types.

I tried to explain that those who want this sort of tool tend to write their own, and your project, being too new, doesn't offer anything of value for that purpose yet, nor an alternative to custom development; and it isn't even promising vaporware, because you don't describe any novel and compelling vision.

Your announcement is simply premature: it's about you beginning to work on asset validation, not about actually existing asset validation software that people can try and get excited about.

Hi Lorenzo, thanks for your reply and for being so honest.

I can understand your doubts about the project, but as we just got started, I wouldn't define it as vaporware just yet. Most projects are announced once built, but I believe that the goals of this particular project are very hard to reach in a way that pleases the potentially large userbase and that the only real way of getting there is by doing it together with the userbase itself.

This is of course how many if not most vaporware projects start, so again, I can see where you're coming from, but, as an example of its benefit, licensing is a current topic of debate in which one user, representing his organisation, mentioned that one particular license is more suited than the one we had originally planned. Now, imagine if we were to instead build the product and only present it once its in a workable state; we would then most likely be unable to alter the license and thus eliminate a potential portion of the userbase.

But perhaps most importantly; I don't have all the answers myself and it is my hope that we, as a community, build something that will eventually be described as novel and compelling so as to attract users such as yourself. You may not be the target audience for this announcement and if you can think of a better suited place I would very much like to hear about it!

Thanks again for your input.

Best,

Marcus

I'm interested in hearing your view on how this type of tool could be useful to you; as neither of us currently have much experience in Games, your views would be a real ice-breaker. In film, the process is typically this:

1. Artist works on content
2. Artist publishes content
3. Another artist picks up published content

Some studios work this way, while others are much more casual/freeform in their workflows.
The smaller a developer gets, the more free-form their interactions will be :/

I've only heard of one studio that used a software solution like you mention -- artists would complete tasks and click a button on the intranet to indicate a task was complete. This would notify their lead, who would review the work and either enter feedback into the form, or click a button to pass it on to the art directior, who would do the same thing. Only after passing through all these gates would the task actually be complete.

As for the diagram - I've seen this implemented for code before (as it's very easy to test) but not for art yet. The solution that I worked with was a series of plugins/extensions/scripts for the Git version control system.

At another job, we had something similar, but the 'test' part came on the right hand side of the central asset store -- after bad data had been pushed into the central repository, an automated system would send out an email complaining about the broken files.


I think for a new reusable solution to become popular, it would have to act in a similar way -- easily integrating itself with a variety of version control systems. In my experience, the most popular ones in games are Perforce, Subversion and Git.
Alternatively, instead of integrating into the asset management systems, it would instead have to integrate into every tool that is used by game artists -- 3DSMax, Maya, Softimage, Blender, Photoshop, ZBrush, Mudbox, Substance, Marvellous, Mari, World machine etc, etc... as well as having a well designed public API so that studios can easily develop plugins for their own custom-built tools! Also, the plugins for Max/Maya/Photoshop/etc would themselves have to be highly customizable, because the rules for what constitue valid content vary massively from game-to-game and studio-to-studio.
If such a framework did exist for easily making these kinds of plugins though, I guess that might be a useful tool!

I take it this sort of tool isn't particularly common/useful for those visiting this particular forum. Does anyone know of a more appropriate forum I should be posting on? Thanks in advance.

Most of the people on this forum are in the indie/hobbyist category, and thus don't require such strong/rigid QA guidelines. There aren't that many big forums for game development though... Maybe you could write up a detailed article about these kinds of processes (and the need for new software) and publish it on altdevblogaday, gamasutra, develop or the like?
There's some really experienced coders on this forum, but not that many veteran game artists. Maybe the typical boards like cgsociety.org/etc would be easier to get in touch with experienced game artists?


P.S. just so you know: what film people call "technical directors", games people call "technical artists".
In games, the "technical director" is generally the most senior programmer in the company (e.g. CTO / director of technology).

Hi Hodgman, thanks for your reply.

The smaller a developer gets, the more free-form their interactions will be :/

This is much the same in commercial work and we're including this in our target audience. I'm confident that even smaller team would benefit from the concept of publishing as it facilitates for much more powerful things down the line; such as automation but, perhaps most importantly, an understanding of a greater amount of information.

I've only heard of one studio that used a software solution like you mention -- artists would complete tasks and click a button on the intranet to indicate a task was complete. This would notify their lead, who would review the work and either enter feedback into the form, or click a button to pass it on to the art directior, who would do the same thing. Only after passing through all these gates would the task actually be complete.

Thanks for sharing that, it sounds quite a bit more tedious than the ones I've been exposed to and strengthens my motivation for providing something to resolve that. I've collected some images of the existing solutions we've found here to illustrate how it may look:

https://github.com/abstractfactory/publish/wiki/ui-ux#references

Alternatively, instead of integrating into the asset management systems,

Yes, there seems to be two ways of going at the problem; either pre- or post-export from content creation software. Post-validations could potentially only perform shallow tests if the files tested are binary, as is often the case. What typically happens is pre-validations in which the software used in creating the content is used in each test; from there, more explicit tests can be made, such as testing for uniquely named objects or dimensions of various pieces of geometry.

I'd like to support both. I think they both have great potential and that the main reason we're stuck with black-box testing within each DCC is due to a limited set of options we've got when it comes to publishing. This is what we'd like to change.

Maybe you could write up a detailed article about these kinds of processes (and the need for new software) and publish it on altdevblogaday, gamasutra, develop or the like?

Thanks, I haven't considered that, but I can see why you would suggest it. Perhaps further down the line when the benefits of publishing are clearer to me; at the moment, its a bit too taken for granted and my vision is set further ahead with what you can actually do when publishing is done.

P.S. just so you know: what film people call "technical directors", games people call "technical artists".
In games, the "technical director" is generally the most senior programmer in the company (e.g. CTO / director of technology).

Thanks for mentioning that, I'll keep that in mind!

Thanks again for a great reply!