This week was very short for me since it only consisted of Monday and Tuesday. I did accomplish two things though. I mostly blocked out the upper floor of the main building! I still need to add stairs and doorways, but for the most part we have a template, which means Ryan can start coding the NPC walking patterns soon. I also learned that my "keyboard solution" involved 105 textures (what was I thinking last year when I made all of those textures???), which doesn't really help in terms of lag. I need to figure out how to avoid the "Screaming Keyboard" Problem (where each poly facing up is a different surface, but each is a tiny clone of the main one) and simply make a single texture surface that just has some gaps in it. This way I could at least UVW unwrap, because currently that only leads to the Screaming Keyboard problem again. Goals for this Week
0 Comments
I got that GAD Room DONE! Finally! (But knock on wood because I'm sure now that I've said this, there will be 5 new problems with it). Most of this week was still removing polys, fixing doorways, and adjusting object pivots, but I was able to move on to modeling some of the upstairs New Building by the end. Fixing doorways actually taught me about boolean objects, something I had somehow never looked into in my almost 4 years of 3Ds Max. Incredibly useful and I definitely should have looked into them earlier. I got the GAD room down to just 536 KB (536,000 bytes), much less than the original 233 MB (233,000,000 bytes), meaning by removing individual objects that can be made from prefabs in Unity, and by taking out all of those polys, the room is about 1/4 of the size it originally was in terms of data. From this whole process from the GAD room, we established that assembling whole rooms in 3Ds Max is a mistake. Instead, make the different assets, and set them around the room in Unity. This way, prefabs could be used, or at least colliders/other object settings can be copied really easily if nothing else. We did run into some issues with textures though, so it is my goal this weekend (today) to fix the keyboard's textures so that we can put that into the game. This keyboard has been the most complicated thing ever, and I'll be happy to have it working, even if it still is in a convoluted way with too many textures. Essentially, we initially had every key as its own object, and they were just all grouped together. That caused a ton of lag, so now a keyboard is just one complex object. However, this makes textures weird since the "box" has a ton of "top surfaces" that like to all be textured the same unless I explicitly go in and texture each of them individually. In the end, this will be worth it since I can just do this once -I already have done this in 3Ds Max but didn't know how to transfer textures to Unity at the time and have since lost the file - and then I can export it as an asset package, and hand it off to Ryan where he can easily copy it. Even though there will be 100 textures (not an exaggeration) it's the best way (currently) to avoid the issue pictured above, and each and every keyboard will reuse those same textures. I won't be surprised if I have to redo all of this again when we inevitably find a more efficient way, but for now, I'm doing what I can. Goals for Next Week
Most of this week was removing polys from a recycling bin. Yep. It's all going to be worth it in the end for a less laggy game, but it's very tedious work because even with Ignore Backfacing on, there were times where random parts of the object would be deleted and I would have to go back quite a bit. We're already through the first 1/8th of the school year (Technically 1/7th since the last 1/8th will be taken up by testing) and I don't feel like I've made any new progress towards this game, it's just been fixing stuff from last year, and the most basic preplanning possible. I am very close to having the whole room entirely simplified though. This is just the progress I made this week in terms of file size difference. The first number there was the file size for the original obj of the room. The second is from the obj of the room a week ago. I neglected to export an obj for the room I have now to compare, but what I'm saying is that there is notable progress in terms of reducing file size, which should help the game run much more smoothly.
I know these posts aren't the most exciting, but I think I'm getting close to being back on track, so thanks for bearing with me. Goals for Next Week:
This week was cut short due to hurricane Florence. As far as I know, not much damage was done around here, but school for Thursday and Friday was cancelled just to be safe. So, we only really had Monday through Wednesday, which is not a lot of time to get things done. I said in my last blog post that I hoped that "we are past any last year screw ups and can move on to this year's screw ups!" I should have followed this statement with "knock on wood," because I definitely jinxed it. The GAD Room model is RIDDLED with problems! Pivot points are miles across the screen! There are hundreds of unnecessary polys! There are doors without doorways in the wall! We sure didn't know what we were doing last year. So, that's what this week was. Working on fixing the GAD room, but I'm still not finished with it. It's gonna be a long week. [No picture included because the version of 3Ds Max we use at school is incompatible with the version I am able to get at home (I checked for updates, none available for my free student version) and since the week was cut short I did not get any pictures. Sorry.] Goals For Next Week:
As you can probably tell by the title, I didn't exactly meet my goals for last week, but I think I at least halfway met all of them, and still did make good progress this week. So what were last week's goals? Calender So I did get a very basic bare bones calendar set up in google docs, but, it was definitely too flexible and google docs is not an acceptable program to use for this purpose with our needs. Part of next week will be finding a suitable program and adjusting the calendar to have better defined deadlines, and then getting this out to everyone. Get Floor Plans We learned that we can get a paper map that must stay in Mr. B's room at all times due to security concerns. We were however, unable to get the map due to the owner of them being in a meeting when we swung by. Communication is important, I will email him immediately to figure out when would be a good time to get them. We are hoping and praying that they include measurements, because if not, it's time to measure a whole lot. Model Barebones 2nd Floor Between trying to figure out this map stuff and modelling other stuff that came up, I never got to this. As soon as we have the map and know how much information we still need, doing this will be the top thing on my list to do, but for now it has been moved to lower on my priorities list. "So, Abi, what did you actually do this week?" Well other than the map work describe above, I mostly was catching up with problems from last year. Problem 1: VR Controllers not showing up onscreen Normally in VR, when you're in the game, there's some sort of graphical version of where your hands are if you have controllers in them. If not, it can be very hard to tell what you're doing. For us, no hands or controllers were showing up for the first few days. So I set out to model a hand in 3Ds Max. Hands are hard to draw, but they're actually not too hard to 3D model (granted in a static and not very expressive position, and through a process that took me a couple days, but still.) However, halfway through making this hand, the controllers magically showed up in the interface. Of course. However, it is not a waste at all for two reasons: 1. Modeling experience, especially if I'm going to be working on The Hawk's model, which would most likely require hands (unless we go full bird route). 2. We were planning on having a mechanic where the player can look at their phone, and I can now take the phone model, which was created by the lovely Julia Serrano, and add it to the hand I made in order to make the model we will eventually need. I learned how to model the hand with this tutorial (and the other two in the series). It was very helpful. And Problems 2 + 3: Keyboard and Keyboards Last year when we made the GAD demo room, one of the objects I spent a ton of time on was a keyboard. At first when I made it, every key, and every letter on every key, were their own objects. This is obviously a problem because Unity can't possible load all of that and not be incredibly laggy. Somehow last year this problem was not so obvious to me. Eventually though, someone pointed it out, and I made a simplified version where symbols on keys were all textures, and the keyboard was one solid object. However, despite this there were still two problems, which I had to fix this week. 1. The "simplified keyboard" had some screw up when I merged all of those pieces and had a pivot about 1000 units away from the keyboard. This means that any rotation or scaling was completely screwed up. This was a quick fix of moving the pivot, and I'm glad I had this experience because now it's the simplest thing in the world to do if I every run into this problem again. 2. The original "Completed GAD Room" file that we had still included all of those lag-inducing keyboards. I just had to go through and delete all of them, which didn't take as long as I thought it would. So, I am hoping we are past any last year screw ups and can move on to this year's screw ups!
Goals for next week:
This week was mostly about getting back into the swing of things, getting organized, and setting up the overall group dynamic. This was fairly easy since our work from last year helped us build the team, but we then had to double check all of that work from last year still worked - so far, for the most part, it has. My main personal objective this week was to get the Trello set up in a way that works best for our group, and to figure out how much of the school we can realistically model. The Trello only took a day or two to set up, and I'm pretty happy with it now. It now shows what tasks are important for the immediate future, as well as what we are currently working on. There are colored labels for what each task pertains to (3D modelling, programming, etc.) so that most of them can exist in the same list so that they are easily visible, with the exception of categories where a separate list was requested in order to make it easier for that person (Sound Design in this case). Overall, I think it will lead to a better workflow where fewer things can be overlooked and where it's easier to see what needs to be done. As for the scheduling part, this is still something that I need to feel out, but we are hoping (and praying) that we can get the new building done by, or at least soon after, the end of this quarter. It took us about a quarter to design the GAD room last year, but we are hoping there will be a learning curve that will allow us to develop the map more quickly, even if we have to add details after this 9 week period.
Goals for next week:
This post is supposed to reflect on the process of design a game in VR. I don't have a lot to say about the actual designing of the game since most of the work I did was more about 3D modeling, so this will actually mostly reflect on that. Let's just say, this has been one of the most stressful projects of my life, I'm freaking out a little bit. Deadlines are very difficult to hit, and learning as you go only slows down the process. However, I feel like I have learned a lot and created decent work.
You can go to my selected works page, or even my VR DSA page in order to see what work I have actually done, but basically it was a lot of modeling of objects around the room. One of the main things I learned is every model needs to be as low-poly as possible. You'd be amazed at how many objects really are in a room, and how much lag it can cause. Moving into modelling the whole school, I definitely need to work on making lower-poly models, and learn a lot more about how textures and bump maps work. Though I have not seen the finished product yet, I am very proud of what we were able to accomplish in terms to making a VR model for the first time. I hope that the process will be a bit smoother next year because of all that we have learned as a group and with better scheduling and organization. VR is typically associated with VR games - at least for people in the game design field - so I want to look into what else it can be used for. I've heard people use it to see places in a more immersive way, and in psych we talked about using it to face fears that might be too dangerous or expensive to face in real life. However, I want to see even more of the uses - or possible future uses - for the technology.
The first one I found that really interested me - from this website - was VR being used for physical therapy. While this one involves game-like exercises, basically it gives patients a more entertaining way to do therapy to help with motor function. This site also mentions VR being used to train astronauts how to use specialized equipment. These kinds of programs could also be used to train pilots or ship captains. It also discusses companies using VR to make and see prototypes for things like cars in a more immersive way, as well as providing as a good educational tool as there can be virtual museums and lessons. Another source mentions three other uses that I think are really cool. The first being training surgeons, which is pretty self explanatory and similar to training astronauts. The second is space exploration. The site mentions that of course this would mean somehow getting good video footage of space or being able to accurately map it somehow, but then anyone could be immersed in space. The final use it mentioned was to allow people with disabilities or certain conditions to experience things they might not be able to otherwise. For instance someone who had health risks that would prevent them from leaving home for very long could virtually visit different countries, or someone who can't walk can still travel places in VR. Basically, it seems like VR can be used for almost anything. Of course it wouldn't really make sense to put a 2D cartoon in VR, or use VR to completely replace actual surgical training, but for most fields it can be a useful tool. Training seems like an especially useful functionality, especially for high stress jobs like being in space or removing someone's kidney. Exploration of not only places on earth but possibly space is really cool, and could save people money on travel, or at least help them decide where to go. I think we will continue to find new ways to use VR as it becomes more accessible and more advanced, but it's really cool that we already have all of these ideas for how to use this technology. Some uses for VR (other than gaming) are:
It's been a while since I made a post about, or have even thought about VR, but next year (and for the rest of this year) that is going to be our main focus. I wanted to review what I have learned so far about VR/ things to remember, while also looking into any other tips that I can find.
First I'm going to recap what I learned at ECGC last year, which I made a blog post about a while ago. That post focused a lot on the specific features Unreal Engine 4 had, and unfortunately, our computers at school are probably unable to use this engine. However, my interview with Hurley did give me some more general tips for VR. For starters, keeping your frame rate high so as not to cause nausea. This shouldn't be a huge problem for us, but is something to keep in mind. On the same track of not making your player feel sick, we need to be careful in how we do movement. Sudden, uncontrolled movements, especially with non-steady accelerations can really make a player nauseous. The last thing Hurley said is very different about working in VR is the fact that there are two, oddly shaped screens, and your design now has to accommodate that, usually by using special meshes or slightly different rendering. Now to the new stuff. This article talks about getting into VR by experiencing it and just playing around. It also mentions giving the player a horizon line to look at to keep them from feeling sick, making sure everything is scaled correctly so that your player doesn't feel lost or claustrophobic, and it goes on in detail about designing a UI. It emphasizes not having your player have to do crazy things (ie look down to an uncomfortable angle) just to do basic interactions. Most of the interactions should be easy to achieve without putting stress on the player's spine or neck. The Unity website has some other things to say about VR as well. Basically, it's simple to set up a VR project in Unity. You have to do some extra set up at the beginning, but then it's just a matter of changing the product settings to enable VR. While earlier I said we probably didn't need to worry about frame rate that much, the website pointed out that since it has to render everything for both eyes, frame rate will likely decrease. It also says that if you have a VR camera in the scene, you can't move it alone. It has to be the child of another game object, and then you move the parents and the VR camera will come with it. It also unfortunately will not set up different cameras for different eyes, so you have to do that part yourself., but the website does give an example of how to do so. It suggests not using visual effects since they are often unrealistic and costly to rendering time. Overall, I'm glad that there don't seem to be many differences between VR in Unity and VR anywhere else, but since I haven't done VR anywhere else, I'm sure it's still going to take a lot of learning. |
AuthorHi, I'm Abi, a DSA student who likes games, drawing, writing, and acting. Archives
February 2020
Categories
All
|