Vacation

The last 2 weeks the artists worked on a poster and trailer of the application. While the rest of the team worked hard on patching up all bugs and writing the report. You can find the poster and the trailer below.

The project as a whole has been an educative experience. We have learned to work in a big team and to work together with a client. At the start of the project it became apparent that before we could programming we first needed to learn the required domain of veterinary medicine. So everyone in the team now knows a lot more about veterinary medicine which can always come in handy when your pet gets sick. The atmosphere in the group has always been good, in some instances it might have been too good. But luckily the big scope of the product constantly reminded us there was still a lot to be done. And after a lot of of cooperation, consultation and hard work the application has finally been finished, the customer is happy and we should enjoy our well earned vacation.


First steps into a new direction (soft-surface modelling)

At first when decided with the other artist (Bas). That I was going to be modeling the animals, it was a bit scary and exciting at first. Because I focus more on hard-surface modeling than soft-surface modeling, so soft-surface was still pretty new to me. But I also wanted to improve myself in terms of soft-surface modeling, so I saw this as an excellent oppertunity.

Because soft-surface modeling has a different workflow than hard-surface modeling. I started to look up some tutorials on Youtube and started to study other people’s work. This gave me a clear view on how to get started.

First I looked up the anatomy of the model I had to make (dog, cat etc.). After doing that, I started to create a simple rough mesh that represented the animal.

Ferret (rough shape):

foto1

The next step was to improve the anatomy, add some more details and fixing the meshflow of the model.

Ferret (Anatomy + fixes):

foto2

The final steps were to smooth the model, unwrap it and put it into Mudbox. So it could be textured.

Ferret (final mesh + texture):

foto3

 

This was my very first time of using Mudbox for texturing. Mudbox offers a very pleasant way of texturing simple 3D models. You don’t have to waste time by perfectly unwrapping a model and then texturing it in 2D photoshop. In Mudbox you can import your model and paint DIRECTLY ONTO IT! This saved a lot of time.

I continued this workflow with every other soft-surface model, luckily I didn’t encounter any problems during this process.

As a 3D artist it was a very learning experience because it was almost completely new to me. And I had very little experience when it came to soft-surface modeling.

When I presented the models to the client/s they seemed to be very happy with the results. And that is always nice to know that someone is happy with your work.

Jerremia Egels.

 

 


Current status of Furo

You’ve seen blog posts about Git-fu,  CI, unwrapping and of course the 20 facts about ferrets, but what about our project?

With less than 6 weeks till the end of the project, still some things need to be done. But, to give you an overall impression:

Screen Shot 2016-05-27 at 14.54.15 Screen Shot 2016-05-27 at 14.54.38

These are screenshots of the ‘Lichamelijk onderzoek’ and creating of the ‘DDx’ for the students of Diergeneeskunde. Our artists are working hard to replace the colours in the application to the colours of Diergeneeskunde. Screens will look like this in a couple of weeks:

Screen Shot 2016-05-27 at 14.57.07

This page with a lot of purple (colours of Diergeneeskunde) is a page where professors can add new cases. How this works, we will show this in another blog post.


Git-fu

Say you and your ferret loving friend want to create a website about ferrets. You know how important version control is, but neither of you have any experience with git. These are some of the most important git commands you need to know to bring your project to a good ending, and share your knowledge of ferrets with the rest of the world.

We will start off with a folder, containing only one file: ferrets.txt.


 

To initialize a git repository in this folder, simply use the command $ git init

image04

To check the status of your current branch, you use $ git status

image08

As we can see, we are on the master branch, and this is our initial commit. Also, git notifies us that we have untracked files. To add a file use $ git add <file>

image02

We can now store the changes in a commit and add a message, using $ git commit -m “our message”

image05

When making changes to your project it is good use to do this in a separate branch and leave the master branch alone. To create and go to a new branch use $ git checkout -b Branch-Name

image06

The -b flag tells Git it needs to create a new branch. You do not use this flag to checkout to an existing branch.  Now let’s add a picture of a ferret and check the status.

image07

We can add the picture using $ git add ferret.jpg, but when we have hundreds of pictures of ferrets, we do not want to add them all by hand. To add all untracked files, use:

image09

Be aware that this may also include unwanted files. If there’s any files we do not want to include in our commit, we can remove them with $ git commit — <file> 

Now create a commit and add a descriptive message. You can now checkout to master, and apply your changes. Now that we do not need our Ferret-Picture branch anymore, we can safely delete it using $ git branch Branch-Name -D

image10

Now let’s add some ferret facts to our text file. We checkout to a new branch, add some ferret facts to ferrets.txt, add the file, and finally create a commit. Oh noes, we forgot to add one of the ferret facts! What we can do is create a new commit. But that will leave us with an extra commit with only one change. A clean way to resolve this is to amend your last commit: $ git commit –amend

image01

By using –no-edit we do not need to write a new commit message, and Git will use the last commit message. To check the changes between files on different branches, use $ git diff Branch1 Branch2 or ad –name-status to only display the file names:

image12

To clean untracked and unstaged files and remove empty directories, use $ git clean -fd

image11

Now, let’s assume your friend has set up a remote repository. You can locally access repository by cloning it, using $ git clone git@gitserver:some/path/ferrets.git

You can pull all changes to a branch to keep it up to date by using $ git pull

image00

As we can see, the file ferrets.txt was edited, and a new file pull.txt was added. To view the commit history of a branch, checkout the the branch and use $ git log

image03

After a pull, we also have local access to remote branches. We can check out to a branch, commit changes, and then push the commit using $ git push 

If we create a local branch, and we want to add it to the remote repository, use $ git push –set-upstream origin Branch-Name

 


GitLab CI with Unity3D in Docker

Tests should be an integral part of every software development project and tests mean a lot to us. For our version control we use GitLab, which has great support for CI. For our front-end we use Unity3D, which now has built-in support for unit tests. We wanted to run our Unity3D unit tests on the GitLab CI runners, which proved a bit more difficult than we thought. In the end we got it working using Docker, this blogpost is about how we set it up.

Docker is a great tool that allows you to create containers for software, so that you don’t have to worry about the environment that it is being installed on. To learn more about Docker, check out this link. Our docker image is based on an Ubuntu docker image. The Dockerfile used to create this image is the following. It installs a bunch of dependencies necessary for Unity3D.


FROM ubuntu
ADD unity-editor-5.3.3f1+20160223_amd64.deb .
RUN apt-get update -qq
RUN apt-get install -qq -y gconf-service lib32gcc1 lib32stdc++6 libasound2 libc6 libc6-i386 libcairo2 libcap2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libfreetype6 libgcc1 libgconf-2-4 libgdk-pixbuf2.0-0 libgl1-mesa-glx libglib2.0-0 libglu1-mesa libgtk2.0-0 libnspr4 libnss3 libpango1.0-0 libstdc++6 libx11-6 libxcomposite1 libxcursor1 libxdamage1 libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxtst6 zlib1g debconf npm xdg-utils lsb-release libpq5 xvfb
RUN dpkg -i unity-editor-5.3.3f1+20160223_amd64.deb

We use Unity 5.3.3, you can easily change the version by placing the Linux package downloaded from here in the same folder as the Dockerfile and changing the following line

ADD unity-editor-5.3.3f1+20160223_amd64.deb .

and then building the Docker image again.

As for our .gitlab-ci.yml file, that looks like this:

unity:
image: "aran/unity:latest"
script:
- mkdir -p /root/.cache/unity3d # A folder necessary for building your project
- cd FrontEnd/FuroUnity # Cd into your Unity project dir
- xvfb-run --server-args="-screen 0 1024x768x24" /opt/Unity/Editor/Unity -projectPath $(pwd) -batchmode -runEditorTests -force-opengl -logFile

Most of this was found out by trial and error, as there was no definite guide on how to run Unity3D on servers without GUI, so hopefully this will help you set it up.