That said, we’re just talking about the front end, we could make a web front end, I am more interested in the process and the things mentioned before than the way you interface the system.
Some key things for me are like auto creation of directories in the asset db, be it p4 or whatever else. I would like artists to never need to open up p4win.
Big software projects like this are precisely not what a good open source project is- it is like creating a game engine rather than an engine component. Look at how numerous popular single engine components are (graphics, audio, physics), whereas you’d be hard pressed to find any complete project using any more than a few open source or commercially available engines. Team’s needs are too specific, too fluid and too custom, to have anything moderately successful. What you mean by any single term may not be what I mean- and I can guarantee you your implementation of the notion behind that arguable term is different than everyone else’s. If people really want to collaborate on something it needs to be standalone, pretty core (from libraries to deploy systems like NuGet), or pretty high level (a separate module or tool that fulfills a certain purpose people can hook into their own custom setups).
There are also some other concepts here I fundamentally disagree with (artists never having to open P4Win/P4V), but that’s another issue entirely- this is just about practicality.
If a regular GUI app client is what you’re thinking instead of a web interface, then some likely options are wxPython, pyQT or pyGTK. I have a lot of experience with wx, but it’s probably more important the people contributing to the UI be comfortable with the chosen framework.
I’ve done a lot of database work with Python, using SQLite, MySQL, MSSQL and a little Postgres. We use SQLAlchemy with MSSQL a lot at Volition, and given the choice I’d definitely do the same on a new side project.
I’ve used that combo for everything from “dumb data stores” for simple process timing info, to larger sets of relational tables storing everything from game coordinates to binary image data. Once you get a table design established it’s easy to read/write the data in a simple Pythonic manner.
Anyway. It might make sense to assign leads to different areas?
I’d suggest going with PyQT and sqlalchemy for your needs. I’m starting to realize that the project I’m thinking of is something a bit different =)
If you just need a quick and simple asset management solution you should be able to bang one out pretty fast to fit your needs specifically. What I was thinking/hoping for is more of a portal/glue/centralized tool that all of the other modules would dock into and exchange information. Basically something to connect the assets with the tasks and approvals.
Currently I have something that keeps track of the assets and of the gameplay and how the two connect to each other, but I’m missing the project management, metrics and other bits that currently exist but don’t talk to each other. I’m a fan of one stop shops when it comes to workflows, having to do the same thing in 3 different places or have 4 different tools to get the information I need drives me nuts =)
Let me know if I can help at all, I’ll probably move on on my own on what I was thinking of but I’ll gladly help you with whatever you guys have in mind.
This is such a complicated issue and if any tool you write is to be of any use at all it is not going to be “simple” by any means! All you get with simple is another window on your desktop you need to have open to do something you use to be able to do in perforce, linux shell or some other more familiar thing…
Right now we’re using Tactic|Shotgun|SVN to solve our asset management and production tracking needs and even with all these feature rich and production tested tools the amount of our own wrapper code needed to fit that into our pipeline is mind-boggling and we still can’t do what we need and how we need it! So much so we still have to go and manually do some of the work at a very low level all the time!
There are just so many variables in a production that to wrap it all into a nice simple gui is just impossible.
Now it’s not to say it shouldn’t be attempted but I highly recommend you do a lot of planning and scoping before you start. Keep your system very open and very granular to be able to adapt easier.
well if you just need a tool that creates assets and tracks them in a database, you can do one relatively easy. If all you’re doing is making a new asset from a template and adding it to P4 and logging that into the db.
If you want to get into project management and workflows that’s where it gets interesting.
Just curious, Tactic and Shotgun seem really familiar, why do you guys use both? Different departments have their own?
Maybe it is a good idea to first write down all the things you would like to see in the project that are not present in perforce, shotgun, …
Then this way you can see for a software structure that is flexible enough to fit those requirements.
I am quite the noob with making software. But how do you guys begin when starting a project like this? I guess there has to be a really good base structure because lot of people want to work on it?
I would like to help, but I don’t have enough experience with Python (like almost zero). So I guess I would not be a really valuable project member. If there is anything I could help with, you may always let me know.
But I don’t want to make a be all end all.
I would just start as a simple asset database where each asset has associated tasks and attributes (like a journal of comments and review feedback).
I would try to set interfaces, then myself only support the tools we use in my studio (p4, etc…). If someone wanted to use something else, they would just write a module to connect it.
CE
[QUOTE=Chris.Evans;8440]But I don’t want to make a be all end all.
I would just start as a simple asset database where each asset has associated tasks and attributes (like a journal of comments and review feedback).
CE[/QUOTE]
That definitely seems like a good starting point, separate from versioning, UI, any of that madness. You could probably even boil it down to just something like building a data model first and going from there.
Yeah but, not having done this before, and not seeing any examples online, i thought it would be a good thing to do:
seems like a good time to learn…
Yes. What you really need is to spec-out what you want/need, even before picking the tools & methods (“I need it to be in python because our coders and artists already know some python” can be part of the spec, but it’s a line item among line items)
This is, of course, almost never how production software gets actually made – it tends to evolve according to changes in the environment. But as an ideal, it’s a good ideal.
I am starting to get a bit lost here… 
So what’s the goal?
-Do we want to create a core with lots of interfaces so people can create their own UI and their own glue to external software (P4, Hansoft, etc…)?
What would be the functionality of the tool? Will it take care of creating a data model with the raw data, binary data, meta data and insert it into a DB? Then provide interfaces to manage this data?
In my opinion that would be the best option, small solid data management core wich can be glued to any version control software and any UI.
[QUOTE=lkruel;8437]
Just curious, Tactic and Shotgun seem really familiar, why do you guys use both? Different departments have their own?[/QUOTE]
Tactic is an asset management software, Shotgun is production schedule and task tracking software. To do both things effectively the two systems need to interact.
It’s not about making the tool to “be all end all”. The problem is that the nature of the problem at hand requires it to be a lot more than what you would expect if it is to be used successful in a production and not be a burden for artists or a complete hindrance.
I mean starting with a data base, the first thing you absolutely will run into is a complain that it is SLOW. It happened every time, your artist and tds will say (and they will be right) that querying the db for assets is slower than running a os.listdir on a directory with assets. So there are countless man hours then go into making it fast, creating cashes and etc. And that’s just the database query part.
Like I said this issue is like an iceberg, it’s deceivingly simple from above water!
Try and scope out a definition of an asset and make sure it takes care of every piece of data various departments can produce… it’s nightmare! This is partly why Alienbrain fails miserably and tactic still has trouble with all sorts of complicated assets and forces a lot of workarounds…
If you want “simple asset database where each asset has associated tasks and attributes” I would start with two existing techs that do that, ex. P4 and Bugzilla and make them talk to each other and maybe obfuscate it all in a simpler gui…
Wow. I’d venture to say you haven’t worked with databases that were well designed for the task at hand. Your table design certainly needs to match the needs of the tool/queries. However, if you get that done (even semi-correctly) you can retrieve a variety of data that’s simply not there using just the file system and os.listdir. And do it quickly. But I digress.
See! This is why I came here… So are there any good pages or books you have come across on this? Or just experience from doing it?
Yeah those guys at Tactic really don’t know what they are doing, who would imagine they’d design their database architecture for the task at hand … but I digress!
The point is it’s not simple which is what I’ve been trying to say. Every place where I’ve worked that had a system that did a data base query had the speed problem. And to assume that engineers I worked with, including those working on commercial tools such as Tactic and Shotgun just aren’t smart enough to know about appropriate data base design is a huge assumption to make to refute a valid point of concern!
I’d like to advocate the idea of a node based UI for asset manager. Given the complexity of the data in a pipeline i think an alternative approach, i.e. non dialog hell based ui, is needed. I must admit i have a crush of node based workflows so bare with me.
Example Workflow:
select project, zoom into a task node, select a bunch of nodes(assets) and drag and drop them to the dcc app of your choosing or launch a workfile by doublclicking. Select nodes in the dcc and drag and drop them back onto the task to add them to the database.
For the asset manager they’re all just BLOBs with attached attributes on them. Some(task/asset) attributes would be hardcoded(task: user,date,type, changed, dependencies, priority,etc.) and others custom(assets: think customvalidation.py)
Viewing the assets as vertices in a mesh makes color coded dependencies a breeze. So what if it generates a complex spider web of data, if it does so consistently you’ll quickly learn to navigate it. It is also a representation of the true nature of all things production and hopefully would make people appreciate why they should do things properly. Btw You could do pelt unwrapping of asset meshes based on the dependecies/priorities! 
I’d probably go with an object database instead of a relational one.
2 modes: Game & Film. First objects to figure out: Project, User, Task, Asset.
Hope this helps to get the spec discussion going!
Mainly past experience, and what stuck with me from database design courses in college. I’m also fortunate to work with some guys that are wicked smart with relational data, I’ve learned a lot from them.
I would be glad to help with this stuff, including helping write the database layer. The two main things to consider are 1) what data do you want to track for the assets, and 2) how will the tool(s) use that data?
Even before table design, that’s a good place to start for this kind of system. It can potentially rule in/out several options. For instance, a few questions that could point towards certain approaches:
[QUOTE=bjorke;8450]Yes. What you really need is to spec-out what you want/need, even before picking the tools & methods (“I need it to be in python because our coders and artists already know some python” can be part of the spec, but it’s a line item among line items)
This is, of course, almost never how production software gets actually made – it tends to evolve according to changes in the environment. But as an ideal, it’s a good ideal.[/QUOTE]
BAM! I strongly agree with you.
I’m no expert myself, as I just graduated from school, but heres what I’ve been thinking.
At this point, I think we are starting to agree on what we are trying to acomplish. From what I’ve gathered so far, it’s seems like most people want to “Build a UI for a small asset management program. This will include things such as creating new assets with the ability to assign them to a user, tags and keywords for sorting/querying, due dates, links to other assets, (concepts of the 3d models to be built) a commenting system, and leave hooks to link DCC programs as well as Version control.”
If we can first agree on what the program is going to do, it will be easy to create a Data Model that further defines what the program can do/can’t do.
Also, at this point I don’t think we need to worry about whether it’s web based or a stand alone program. I understand that will be a major discussion down the road, but either way I believe deciding now is getting ahead of ourselves. Getting the initial design done correctly, would easily allow both to be created. If you haven’t heard of Model/View/Controller, check that page out.
Also, maybe having a group chat or conference would be a good idea. I believe Skype has a nice group conference feature.