As mentioned in my previous post, in the past week or so I've been coding C# in Unity Engine. This is the major step in the path towards actually making playable games. That means it's time to do some research for the future. I learned some incredibly useful things from this article. One of these things was how to identify Unity errors using site searches. This is done by typing "site:unity3d.com" and the error message. This will search through all the Unity site's pages for information about the error. Another useful thing I learned was that garbage collection (GC) can cause stuttering frame rate. One of the pieces of advice the article gives is to create game objects early on to enable and disable as needed, rather than constantly using instantiate and destroy. Another way to do this is avoid concatenating strings with + when not needed. Multiple words can be used within a single string, so there's no point separating them using a + when they can be placed in the same pair of quotation marks. This will merely slow down the program. I also learned that when developing a game, there is likely to be duplicate code at some point. Instead of bogging yourself down with more code and more maintenance, create an interface. There's no point in coding the same thing twice if it's not necessary. The article recommends not to overdo it, though. I have not yet learned how to create interfaces, but I will keep this in mind for the future. So, to summarize:
0 Comments
I'm finally learning to write code! Using the program Unity, I've been coding C# for about a week, and already I'm thoroughly engaged. Here's what I've learned in my first week. One of the first things I learned is that syntax is very, VERY important. A single mistake can wreak havoc. Double check everything, as it will save you a lot of errors. I also learned that getting a second party to look over your work can be very useful. I once spent several minutes going over my code with no clue what was wrong, when a classmate glanced over it and pointed out a simple mistake in naming a file. This was also where I learned to look for the cause of errors in places you wouldn't necessarily expect. Another example of this is when I couldn't get the right number to print, despite it being in the code. The problem turned out to be that the previous default was still in the Inspector and had to be changed. I had assumed that changing the default in the code would change the value in the Inspector, so I didn't think modifying the value in the Inspector would change anything. I later learned this wasn't the case and also learned that making assumptions is a bad idea when coding. The computer simply does exactly what it's told, so it's important not to jump to conclusions. Test anything that might have an effect, or better yet, ask someone else like I said before. So, to summarize:
While working on an animation project about a week or so ago, I found out some incredibly useful things about 3ds Max lighting. Without further delay, here they are. One thing I discovered is how to light windows convincingly. The shape from which light emanates can be changed; in this case, it's probably best to use a rectangle. This shape can be modified in length and width, much like a 3D primitive. There is an option to make the shape from which the light emanates visible, so it will show up when rendered. This is useful for windows, since it allows the user to create a glowing rectangle. The light looks best lined up with the window and placed just in front of it, so the shape will be visible. Placing it behind the surface of the window (unless the surface is at least partially transparent) will result in a glow that is especially visible around the edges, but the shape itself will not be seen. The last time I tried to light windows was about a year ago, and I didn't know what I know now (and I was using the exact same model as I used this time). The result was a lot of small, weird-looking dots of light on the window, and the rectangles didn't fit the windows properly. I would also like to mention that this trick of showing the light itself is also useful when illuminating headlights, especially on simpler models. I also worked on lighting street lamps. I learned a few important things, one of which is that spotlights have two radii which can be modified. The first is the hotspot in the center, where the light is most direct, and the second is the falloff, where the light fades out towards the edges. I discovered that for street lamps, keeping the hotspot radius and falloff radius close together usually gives the most realistic effect. I also recommend making the shape of the light visible, because if any shots happen to catch the underside of a lamp, it will look strange without any a visible light there. The other interesting thing I discovered was temperature and filter color. Temperature can be set using a preset or by typing in a Kelvin value. Higher Kelvin values produce a pinkish tint, while lower values produce a bluish-white. Filter color is useful for unusually colored lights, but be careful, as it can have a drastic effect. I particularly like the Halogen presets for temperature. Using a few different temperatures in different windows of a building looks less monotonous, and is also more realistic; people buy different types of lightbulbs. So, to summarize:
While working on a big 3D animation project in class, I had several things not work, but I didn't know why. Naturally, it's time to do a little research. One of the requirements for the project was the use of a hair or cloth modifier. I tried using cloth, but nothing happened. The Autodesk website has my answer. I hadn't yet started the simulation, which is why the flag remained rigid. Another thing I noted was that I need to constrain the vertices at the top to the flagpole, or the whole thing is going to collapse to the ground. I also need to set the units for the modifier, since it does affect behavior. After finally figuring out how to make decent-looking smoke particles, I wanted to add the smoke material to them to make them more convincing. I did what seemed to me to be the sensible thing and applied it to the particle event in the material editor. Nothing happened. Once again, Autodesk has the answer: materials are applied to particles inside the particle flow tab. All I had to do was use the Material Static Operator, at least for what I'm planning. I also learned that it's possible to make particles change color using the Mapping operator or Material Dynamic Operator. So, to summarize:
|
AuthorI'm moving on to my 4th (and final) year as a Game Art & Design student at Durham School of the Arts. I'd like to call myself an artist, but I'm a programmer at heart. Archives
February 2020
Categories
All
|