4 ms·

Perhaps somebody knows better than I do, but I'm pretty sure Unity only make the tools, which is a very different proposition! They will have the large files, b

by to3m 11y ago

Perhaps somebody knows better than I do, but I'm pretty sure Unity only make the tools, which is a very different proposition! They will have the large files, but not the iteration. Storing large files somewhere outside the working copy is only part of the solution. Working with artists is going to be a bit painful unless you have centralized file locking, or some other self-managing means of preventing two people modifying the same file by accident. In theory, you could use merge tools for the binary files that artists manipulate, but in practice, these tools don't seem to exist. (I can't speak for hg - but an issue with git is that you really have to have a good mental model of how it works to use it effectively. This is something programmers like - or, failing that, are at least practised at doing. But it's really not the sort of thing artists seem to generally enjoy. Certainly very few of those I've worked with...)

jordigh 11y ago
> Working with artists is going to be a bit painful unless you have centralized file locking, or some other self-managing means of preventing two people modifying the same file by accident. I am convinced that file locking is not the ultimate solution, even for artwork. Someone could decide to change the colours of some character while someone else could decide to redraw her arms. Both changes make sense together. What we need is specialised diff and merge tools for artwork, which nearly any VCS already allows you to plug in. Even github has a WUI for diffing images. File locking is a workaround with other well-known problems. Merging divergent work is not any more annoying for artwork than it is for code. Pixelapse seems to be presenting a compelling case on what VCS for design could look like: https://www.pixelapse.com/ https://www.pixelapse.com/ > I can't speak for hg - but an issue with git is that you really have to have a good mental model of how it works to use it effectively. This is widely touted as a huge difference between hg and git. You don't have to understand hg's revlog format to use hg, but you need to have a solid understanding of blobs, trees, commits, refs, and hashes to understand git. What you do need to understand for both is that someone can have modified the same file that you're working on while you're working on it, and it is OK that they modified your file at the same time...
- vvanders 11y ago
  Nope, nope nope nope. This keeps coming up again with "we just need the right tools". The thing is there's a good chance the people you're working with aren't very technically inclined(which is why they're such awesome artists, they have other focuses). Anything more than the simplest scheme is going to fall over at production scale. It's been tried many times, the tools that you are talking about(Maya, Photoshop, ZBrush, etc) don't even consider merging with their large binary workflows. The closest you get to this is referenced scenes in Maya and that requires a good technical artist to set everything up and police things so that people don't touch things they don't understand.
  - jordigh 11y ago
    > Anything more than the simplest scheme is going to fall over at production scale. Then we need a simpler scheme that still allows people to understand that two can work at the same time. Everyone hates merging regardless of their technical ability, even software developers, but I refuse to believe that it's a hopeless task to build a tool for merging artwork.
    - vvanders 11y ago
      That's because merging two things is inherently complex. You need a complete understanding of both how they work and all the things they interact with. That's why everyone hates merging. You're welcome to take a crack at it, however you're looking at hundreds of hours of work to reverse-engineer all the formats that Adobe and Autodesk use plus whatever new tools are on the horizon that you don't know about yet. AFAIK there isn't a single tool out there that can render a PSD to PNG reliably(aside from scripted photoshop) so thinking we would be able to cover the entire suite of tools is a bit naive.

by to3m 11y ago

jordigh 11y ago

> Working with artists is going to be a bit painful unless you have centralized file locking, or some other self-managing means of preventing two people modifying the same file by accident. I am convinced that file locking is not the ultimate solution, even for artwork. Someone could decide to change the colours of some character while someone else could decide to redraw her arms. Both changes make sense together. What we need is specialised diff and merge tools for artwork, which nearly any VCS already allows you to plug in. Even github has a WUI for diffing images. File locking is a workaround with other well-known problems. Merging divergent work is not any more annoying for artwork than it is for code. Pixelapse seems to be presenting a compelling case on what VCS for design could look like: https://www.pixelapse.com/ https://www.pixelapse.com/ > I can't speak for hg - but an issue with git is that you really have to have a good mental model of how it works to use it effectively. This is widely touted as a huge difference between hg and git. You don't have to understand hg's revlog format to use hg, but you need to have a solid understanding of blobs, trees, commits, refs, and hashes to understand git. What you do need to understand for both is that someone can have modified the same file that you're working on while you're working on it, and it is OK that they modified your file at the same time...

vvanders 11y ago
Nope, nope nope nope. This keeps coming up again with "we just need the right tools". The thing is there's a good chance the people you're working with aren't very technically inclined(which is why they're such awesome artists, they have other focuses). Anything more than the simplest scheme is going to fall over at production scale. It's been tried many times, the tools that you are talking about(Maya, Photoshop, ZBrush, etc) don't even consider merging with their large binary workflows. The closest you get to this is referenced scenes in Maya and that requires a good technical artist to set everything up and police things so that people don't touch things they don't understand.
- jordigh 11y ago
  > Anything more than the simplest scheme is going to fall over at production scale. Then we need a simpler scheme that still allows people to understand that two can work at the same time. Everyone hates merging regardless of their technical ability, even software developers, but I refuse to believe that it's a hopeless task to build a tool for merging artwork.
  - vvanders 11y ago
    That's because merging two things is inherently complex. You need a complete understanding of both how they work and all the things they interact with. That's why everyone hates merging. You're welcome to take a crack at it, however you're looking at hundreds of hours of work to reverse-engineer all the formats that Adobe and Autodesk use plus whatever new tools are on the horizon that you don't know about yet. AFAIK there isn't a single tool out there that can render a PSD to PNG reliably(aside from scripted photoshop) so thinking we would be able to cover the entire suite of tools is a bit naive.