First, the new set pieces and props:
Pantry sink
The cornerstone (cue: "Cornerstone," which ran through my head the entire time). Yes, I used a font (instead of tracing by hand), but I had to do some research about the Urbana Masonic Lodge and Masons in general to confirm the date, and the name of Delmar Darrah, Grand Master.
I cleaned up some rooms, and added correctly-scaled trim. This means instead of stretching 3" of trim to fit the entire room, I created a new mesh in Blender scaled to fit correctly. This time-consuming process makes the wood texture look much better, so it is worth the effort. I also created a corner piece for the baseboards. These are the music room and art room, the latter of which also acquired a corrected skylight:
Street lamps
I started on props and furnishings for the library. There was an Unreal Marketplace sale during spring break, so I purchased a set of book models from user NOTLonely. There are single books, stacks of books, piles of books, sets of books to go directly on shelves, and all of them come in clean or dirty textures:
I then created bookcases:
A floor-standing globe:
Bookends
Various glassware to go with the books
And finally, a card catalog:
Here are various views of the library. I created the chairs and tables previously. The teacher desk is actually the same as the roll top desk I created in December, but with the roll top portion removed.
I added a few more props to the art room, based on a photo reference. I downloaded the models of Sapho and David from the internet.
Nurses' office ("emergency" on the plans)
Models for the brick windowsills
Coal bunker (underground, but it's there!), as well as softening the landscape throughout.
I decided that I might be ready to re-do the stonework on the main façade. The unsatisfactory model I did in August looked unattractive, so this is version 2:
During the Unreal Marketplace sale, I also purchased some inexpensive tree packages and a crops package (https://youtu.be/fPHz59riQNE), and placed them around the building to make it start to look like it is part of the neighborhood. In the distance, the fields are visible.
Finally, I spent the very end of March modeling a landmark of Carle Park, the pavilion.
Regretfully, I found out after I completed the model (actually, while Blender was rendering the above video at ~1.5 minutes per frame) that the pavilion was not added to the park until 1919, so if I include it in UHS: 1914, it will be inaccurate. I may keep it anyway, since it helps with the sense of place.
Now to the technical issues. I have been having frame rate issues since I started the project. A high frame-rate is desirable for the interactive functionality of the project, but does not matter as much for photo-realistic pre-rendered videos and screenshots. If I want to keep the interactive portion viable, I need the frame rate higher than the 10 frames per second (FPS) or so I have currently. I would prefer 60fps, but consoles like XBOX 360 and PS3 ran at 30fps for years, and no one was very upset, so 30fps is an acceptable goal. In short, a happy medium between photo-realistic lighting and frame rate is needed. I have seen evidence that UE4 can do both (see the infamous A Boy & His Kite real time demo)
The first thing I tried was to investigate the levels of detail in the models. I have been creating all the models in Blender using very high polygon counts, and assuming that they are downgraded automatically when I import them into Unreal Engine with it's built-in Level of Detail (LOD) generator. For complete technical information, refer to the Unreal LOD documentation. Basically, modern games have a system where a model becomes less detailed according the distance of the camera. Polygons are subtracted based on screen percentage for a particular object. It turned out that since I upgraded to UE4.18 from UE4.16 in January, none of my new models I imported had been given LOD because the default choice changed to "none." I manually added LOD settings for all new objects created since New Year's, which took several days, but will hopefully be worth it.
The second technical issue deals with lighting, specifically the choice between static, stationary, or dynamic (movable) lighting. Unreal can pre-calculate lighting, which is called static, or "baked" lighting (I love that baked is a technical term, like you're making cookies!). This means I do a "light build," which for small levels can be a few minutes, but my project can take up to a a few hours even when distributed among three computers in my house. A very good illustration of the three types of lights are in the Unreal Documentation, and also in this forum discussion. First, I tried making everything in the level static. This light bake took overnight, but the effect on the frame rate was spectacular -- I had almost twice the normal frame rate, which turned out to be a not-as-nauseating 30fps. However, the static lighting looked really bad. So bad, in fact, that I did not take any screen shots. Much of the level looked blotchy and colorless, and this was not acceptable.
After this attractive light build, I then had a discovery about a portion of my workflow that I didn't realize. Early on, I found out that when I built a model in Blender using multiple pieces, the imported static mesh in UE4 ended up having a corrupted lightmap UV. In response, I started importing all the pieces separately, and combining the pieces in UE4 using a blueprint. This resulted in acceptable lightmaps, but I found out that UE4 automatically makes all items in blueprints movable, or dynamically lit. I had upwards of 200 actors in my level that were unnecessarily being lit dynamically, and creating a potentially enormous performance hit. After numerous light builds, including one where the light from the digital sun "shone through" the walls ...
... I came up with a happy medium where I have everything set to be lit stationary. There was an additional problem when I upgraded to UE4.19 in which all metallic surfaces ended up rendering as pitch black, but I think that is solved by switching to 100% stationary. I also have started with the arduous task of turning all the walls made up of BSP brushes into static meshes. The BSP brushes may also be contributing to the low frame rate, but as seen in the above screenshots, they are what the light shines through, so it may solve some of the rendering problems by making the conversion.
In regards to lighting, I learned that Epic's Fortnight (a game by the creators of Unreal Engine) is entirely lit using dynamic lighting. That means the lighting for the entire game is rendered at run time. Given the frame rate issues for my own project, I was fascinated to watch a workshop describing their lighting techniques from this year's Game Developer's Conference. Though unrelated, a different video from the same conference about Unreal's Volumetric fog is truly beautiful and impressive. The engine has so many possibilities; I just have to learn them!
The third technical challenge of the month was a UE4 bug report. The explanation requires some exposition: I was having an issue where the level would load, then the textures would load after the level appeared on the screen, which created a bizarre pop-in effect, and was not what I wanted the user's first view to be. As a solution, I created a short animation that plays as the textures load, then gracefully fades out:
The animation was created using Unreal's built-in user interface system, UMG (Unreal Motion Graphics). I learned how to use this when I created the menus and floating mini-map system months ago. More information is in the Unreal Documentation. Basically, UMG has a Designer tab that is similar to graphic design software and a programming ("graph") tab that resembles the Blueprints elsewhere throughout UE4. The text and graphics are set up in the Designer tab, and the functionality is created in the Graph tab. I created the animation exactly as instructed in the documentation (see link earlier), and linked it to the game so that it would play as the level first started. It ran beautifully ... until I closed the UE4 editor, and opened it again later.
Here is what is supposed to happen: the animation in the Designer tab automatically creates a reference variable on the Graph tab so that I can call the animation when needed. In the screenshot below, you can see an Event construct with the first instruction being to Play an animation, and that animation is the blue "text_animation" variable. Then there is a delay, and the UMG widget is removed. (important note: this is not actually my animation, but the series of screenshots I used to illustrate the bug to Epic)
As soon as I closed and reopened the editor, the game would not Play in Editor ("PIE"). It gave a compile error, and asked if I wanted to skip the intro animation. Further investigation showed that in the UMG Graph tab, the animation variable disappeared. Granted, it was still visible on the graph, but it lost its connection to the actual animation:
The good news is that I can click the plus sign next to the Variables button I circled, and the animation variable will reappear in the list choices. However, I have to manually replace the reference in the widget blueprint for it to compile. Clicking compile without replacing it results in a crash to Windows. I will also have to repeat this every time I reopen the project. No good!
Since I have a free license for UE4, it is expected that I rely upon the Unreal community for most of my troubleshooting. This strategy has gotten me very far; in fact, I have learned much of what I know from others who have shared what they know either through YouTube or through Unreal forums. However, I could not find this problem anywhere else on the internet. Thus, I typed up a bug report, which involved creating step-by-step instructions on how to recreate the bug (including the screenshots), and to upload a project in which the only element is a UMG widget with the error. I have yet to find out if the bug report was accepted, but it was a lengthy process for someone with little technical background.
I ended the month feeling I know more now about Unreal Engine and its rendering, yet still with questions. My free UE4 license means I don't get the benefit of direct feedback for my bug report, and have to search for answers regarding all rendering issues. This is definitely a fun challenge, and one I find rewarding, especially when I experience successes!
