Venturing into the world of PyQt and Model-View design

This semester I'm taking a course called "Communication and UIs" (alongside multivariable calculus and "Design"). I've taken this opportunity to venture into the world of Python, PyQt and Model-View design by making a little asset viewer/mini-manager for Maya.

Huge thanks to Yasin Uludag for making the PyQt4 Model View tutorial series (available on his youtube channel).

Asset Viewer

• Reads/writes to an XML file to store the asset metadata
• Asset status
• Asset preview image (with viewport snap option)
• Filter (semi-broken atm)

The reasoning for making this little tool was to demonstrate the benefits of having the tools that permits the user to deal with the important stuff and not manual file labor, because everyone knows how messy that can get even if it's just a little personal project. I bet if I take a look around some old stuff I've worked on I will find wonderful examples like "robot_v212_final_reallyFinal_shitisbroken.ma".
A simple structure from the beginning goes a long way, especially when it comes to eventually move to a more complex and feature filled management.


There is still some things that needs working on, but since the focus of the course is really just UI design I won't be adding any more features that takes it beyond a "concept of asset management". I'll upload the full source etc when it's "done".

PS. Any comments concerning the UI design is greatly appreciated! I will eventually be graded on this, and my professor will not be taking all that beautiful Model-View design into consideration. Thanks!

”I can do it myself!”

avoiding copy/paste programming tutorials.

I Just recently started working on creating my platform for a 3D engine using DirectX to use during my education as a base for trying to implement techniques and ideas that are relevant and new within the game industry. I quickly found a website with a lot of information and code about the subject. I started using this website and the code that it had on the subject, but I quickly realized that I was more just copy/pasting code than really understanding the concepts and how DirectX actually work and in the end, I couldn't really explain the code to my debugging friend (a horse with rainbow mane and a disco ball around his neck, check pic below). This made me realize, that in the end I wouldn't really learn anything from this and instead went for a new source of information: Frank D. Luna's books about DirectX(Link to book). It has been a great source and I highly recommend it if you want to get your hands dirty with DirectX. Not only does it talk about the fundamental logic behind it, but also explains the code and function calls very thoroughly and my understanding of the code I write and DirectX is much improved. 

(My rubber ducking friend, Tony Mane-ro)

I've always tried to avoid doing copy/paste from websites to solve problems that I meet, mostly to make sure that I understand the logic to the solution and also to avoid diving into a subject just to find the solution and then swim back out without really looking around and seeing a bigger picture within the subject. And therefore I thought I would write some ideas and tips to share to help you avoid this, and also, when you write blog posts or reply on threads regarding a problem to help your reader not to do these kind of dives.

When reading about solutions to certain problems that might occur when programming, you can find times where you see a small text with no explanation or very little explanation of the code and huge block of code. In the heat of the moment you can often say “great that chunk of code solves my problem!” (Perhaps with some modification) and you end up just copy and pasting the code right in to your code and continue on. Sometimes this is acceptable if it's a trivial problem you just forgot the name of a function and not really something you have to spend much time thinking of how the solution will really work. But even then, instead of just copy/paste, write the code yourself! Muscle memory can perhaps help you remember that function next time you need it! I would say that you should always retype code instead of just copy/pasting to avoid missing to rename a variable or any other mistakes that could be easily avoided. This also helps you see the actual flow of the code that solves your problem and you might find new ways to write code that treats something within the problem that you haven't seen before, you find better solutions to situations that you perhaps never saw as a problem. This is perhaps something you should also think about when starting a new project where you want to reuse some of your old code. Take a look at that code and evaluate it, is it possible to re-write it so it's faster/smarter/less error prone? Then do that before you copy/paste it or reference it into your next project.
   I believe this is very important when working with production code, it could be something you'll perhaps will need to give to someone else at a later stage of production. If you can't fully understand it, how should your co-worker relate to this? I had an experience like this once when one of my co-workers was working on RnD stuff and was coding towards an SDK he'd never worked with before. I was asked to take a look and see if a could see anything that could solve his issue he had at the time and so he handed me the code he had “Written”. I quickly realized that a lot of this code was just copied and pasted from some website since some of the comments and variable were in spanish... And in the end to solution to his original problem was incredibly simple and he would have stumble upon it if he would have taken the time and read 4-5 pages in the SDK documentation.

   What actually happened was that I re-wrote everything because of the design of the copied code was very strict and I knew that it wouldn't work later when we later woul have to expand the system. So not only did he copy/pasting take more time because of the refactoring, he would have also spotted his problem and solved it with some reading and gained a greater understanding of what he was actually doing.

   Some might see that re-writing code that someone else has posted is re-inventing the wheel, but if you later have to either change the wheel or perhaps remodel the wheel, it could be good to know why it looks like it does when you start.

What can you do to help others avoid the pitfall of copy/pasting code? It depends on what the person is asking for or who is your intended audience.

   If someone on a forum asks for a function within Maya or any other DCC, instead of typing it, point them in a direction where they can find more information about it(like the Maya documentation). This might help them find the solution to another one of their problems in the future. It's like when your trying to solve a puzzle and ask for a hint, you don't want them to give the solution, just a way to find the solution for yourself.

And if you're writing a blog post where you want explain how you solved a certain issue, I would recommend you to talk more about your approach in text than in code. Post the code in segments rather than in a big chunk and talk about those segments individually. Many of the articles you find at  www.Codeproject.com , I believe, does this very well!

So start copying code from the internet,
but do it a letter at a time.

Introductions

I would guess It's best to start off with some introductions of who we are and what we do. Basically, were two guys that love super weird music, food of any kind, alcohol of any kind and anything 3d related (both technology and art).

We are both students studying M. Sc. in Media Technology & Engineering at Linköping University, Sweden and we've also worked within the game and film industry.

I (Erik) worked within the games industry for 2½ years as a technical artist at Imagination Studios in Uppsala. An animation studio with a motion capture system and other great resources. I worked with creating new tools for our animators as well as tools to make the work tasks for our Motion Capture technicians easier to handle. During my time at Imagination Studios, we worked as developing partners for games such as Battlefield 3, Syndicate, Bloodforge and other projects, some unannounced and some that cancelled.

During Fredrik's internship time from our previous education SOFE (School of Future Entertainment) he was an intern at Copenhagen Bombay in Copenhagen and  was, at first, brought in to work as a Compositor, lighting artist and matte painter. However, due to circumstances his role at the company gradually changed into working more with the technical side of their current movie "The Great Bear" and working with optimizing the scenes before render. At the end of his internship he was given the opportunity to relocate to Trollhättan, Sweden, where he was in charge of a lot the rendering work that had to be done for the movie.

What made us go back to school?

Well, in Fredrik's case it was the slow transition from being a classical trained artist to being more of a role working with the technical parts of production that happened during his time at Cophenhagen Bombay.
    For me, it has been a gradual change of interest from being a Technical Artist  and working with tool development to a desire to work with game development and specially working with developing realtime graphics for tomorrow.
    We're both back in the benches in school to build up our knowledge when it comes to math and science, but from a perspective very (if any) few of our classmates have: The knowledge and experience from the industry and a direct idea of when to apply any math or science we learn because of our time within the industry.

So, what could you expect from here? I dunno, 3D stuff :) ? We will talk about things we see and face in our education that we can reflect over from our perspective and the things we believe the school is missing in it's teachings.


(Also, if you're wondering what Ballmers peak is : http://xkcd.com/323/ )