This week we continued to make really good progress both on 3d models and the coding side of our project. we were finally able to finish simplifying models for our demo GAD room. This means that's when you load the GAD room you get significantly less lag. The file was reduced in size from 233 MB to 536 KB.
We also got a lot of things working in VR this week. After a frustrating couple of weeks struggling to get VR items to work, it was a breath of fresh air for things to function well on the first pass at making them. We imported doors into the GAD room scene and were able to make a working, intractable door prefab. We could then clone this prefab around the scene and have multiple working door. By the end of the week you could walk around the GAD room and interact with many objects. You can now open doors and pick up items such as keyboards and recycling bins. For my share of the work this week I finished making the grasping animation for the hands. After that, with the Unity side of things going for smoothly I decided to start making a couple of promotional pieces of artwork while I wait for the chicken model to be complete. The first piece I made was a simple logo-like chicken head. It turned out well enough that I decided it would be a good header for my Blog page. Now that I'm warmed up in photoshop I should be able to make several more of these logos to be used as promotional items or possibly in the game's minimap to show you item locations. Next week I plan to: -Create logos for more key items and enemies within the game -Start working on animations for the chicken monster as soon as it's model has been completed
0 Comments
Recently I have been doing a lot of animation in 3ds Max for my Advanced Studies team. I have been creating all the simple hand model animations we will need to create our game. Doing this has given me a good sense of the ins and outs of animating thing in 3ds Max.
The Good: There are actually many things I like about animating in 3ds Max. The first is that is uses tweens. This means that all you need to do is set keyframes and 3ds Max fills in all the frames you might need in between. This means you save A LOT of time. Since you don't need to fine tune every single frame you can get very high fps animations without wearing yourself out. The Bad: It still takes a long to bone models and fine tune your envelopes. When you link a bone to a model you need to adjust the bone's area of effect or its envelope. To do this you go bone by bone adjusting a weird gizmo that changes the area of effect. Doing this initially is hard but even after you start animating you can expect to have to go back into the bone structure many times to fine tune envelopes. The Why?: Sometimes 3ds Max just does weird things with your animation. One example of this is every once in a while you will delete a frame that seemingly doesn't affect you model at all. All of a sudden 3ds Max twists your model and you must completely remake it if you want to get rid of the key. -my experience -the good -the bad -the weird This week everyone continued to work on their 3d modeling tasks. We also made some decisions concerning the "monster" of our horror game and broke out the 3d camera to take some pictures of the atrium.
Our excursion to the atrium was very successful. We not only were able to get the 3d camera to work but got a lot of the pictures we needed to continue modeling. While we were in the atrium, we also came up with a new idea for the game's "monster". Originally we were planning on using our principal as the enemy character. While this would be extremely funny, we have quickly realized that unfortunately this would not actually be scary. No one really has a fear of being chased around by a relatively nice looking man in a dress shirt and a tie. Instead we decided it would be far scarier to be chased around by some of the 3d media art pieces on display in the atrium. There are two pieces in particular that have been sitting out in the open for pretty much as long as any of the students here can remember. A large chicken and a large pig that are larger than the size of a normal human and made out of pieces of re-purposed trash would be perfect monsters. With the right lighting effects and sound they could be quite terrifying and make anyone give them a wider berth in the atrium after they play our game. Next week we will: -Continue making atrium models -Continue animating hands -Attempt a first draft monster model As many seniors are this year, I am starting to apply for colleges. One thing I've found that has really helped me through this process is my game design portfolio. Not only has this portfolio provided valuable resources of examples of my work, but through these blog posts I've learned a lot about how to write well off the top of my head.
When many people think of college applications and writing they focus on the essay. While this is definitely a large part of your application, there's many short answer questions you will have to answer as well. When it comes to these it pays to used used to getting your ideas out quickly and in an efficient manner. For example Elon University has a whole section of their application devoted to short responses. They simply want you to write down the first thing that comes to your mind with minimal editing. After doing blog posts for the last three years I felt completely ready for this. It was one of the only times I actually had fun while filling out my applications. This website has also helped me show off my work. I love being able to just send people A link to my portfolio website for them to browse at ease instead of needing to send a bunch of individual pieces of work. Even where I can't send a link having all my work in one place allows me to quickly select good pieces. All in all I definitely recommend making a portfolio page if you have work that you might want to show off sometime in the future. It doesn't have to be fancy be trust me; it will save you a bunch of time later on down the road. -college application process -how having a portfolio helps -how having a blog helps This week in VR our group has focused more on two things. Most of the group is working on removing polys from our GAD Demo room to reduce lag. As it is right now, it's hard to move around the room because there's too many polys. We've learned from this mistake and when we make future rooms in our game we'll work on getting rid of these extra shapes. But for now, we're simply focused on removing as many polys as we can from the current scene we have.
While that's been going on I've been looking toward the animation aspect of things. I was given some hand models created by one of our modelers and have been working on boning and creating basic animations in 3ds Max. Next week: -continue anitmating hands -add phone to hand animations This week we finally solved our first big problem we've had to deal with on the coding side of our VR project: getting the controllers to work. This is a problem we've been having since last year with the computer at school. For some reason the code we were using to track the controllers and keep them active in the scene simply didn't work. We tried many fixes trying to both debug it ourselves as well as scanning the internet for possible problems with our code. The code we use is from VRTK, Unity's basic VR codes asset package.
This problem get weirder over the summer. One of our team members got a Vive and started working on the code at his house. A couple weeks from the end of summer he was able to get the controllers to work. As soon as we got back to school, we put his method to the test. He found that the VRTK script had worked perfectly well on his computer and so we looked to see if the asset store had simply updated the VRTK package over the summer. This failed. There was no new updates in the asset store and when we re-downloaded the package nothing changed. Confused we decided the quickest way to figure out if this was a computer problem would be to directly copy it from our team member's personal computer and send it to the one we have at school. After finagling trough our school's system, we were able to get the code into the school computer. It still didn't work. Finally we found the answer on a random forum that told us to download it off of gethub because the asset store didn't have the right version. When we did this the controllers were tracking and working at last. Thus we ended our long struggle and showed that even seemingly impossible problems can always get figured out with enough persistence. Next Week: -Import codes into gad demo scene -Import audio into Gad Demo scene |
AuthorSamuel Henry is a Senior at DSA in NC. He has 3 years of prior experience in the game design pathway and he's looking forward to becoming a great game designer. The views and opinions expressed in this blog are solely those of the author and do not represent those of Durham School of the Arts or Durham Public Schools Categories
All
Archives
May 2019
|