<aside> <img src="/icons/stars_blue.svg" alt="/icons/stars_blue.svg" width="40px" /> Portfolio
</aside>
<aside>
<aside>
Hello! I am Stephanie. In this devlog, I will walk you through my process of development in the 3D department of the "Weaving Factory Experience" project.
The client, Museumfabriek in Enschede, specializes in Dutch history and natural exhibits. Housed in a former textile factory, the museum envisions an immersive VR experience in Unreal Engine 5 that transports visitors to a 1930s weaving factory in Enschede. In this environment, visitors will experience the sights and sounds of a bustling, dusty factory floor filled with hard-working individuals.
My role in this project is to create 3D assets and bring this world to life in Unreal Engine 5. I will also be expanding my skills as I work toward a functioning prototype for testing in the museum.
For this project, we are using the Design Thinking Method. Since we are all familiar with it and do not have a specific reason to explore other design approaches, it felt like the most straightforward choice.
For this project, I decided on 3 learning goals that will help my future skills, but would also benefit and fit the project.
Documents related to research I have performed or created. (references, videos, articles I created, etc.)
On the first day of the project, the team met with the client, Rob Maas, who outlined his vision and expectations for a historically accurate, immersive VR experience of the factory interior. He emphasized realism, including the warm, loud, and dusty atmosphere workers endured. Although initial files we received included an exterior neighborhood, we decided to focus only on the factory's interior.
We quickly began research, compiling a document to outline our target audience, main objectives, mechanics, and key historical details of the time. To deepen our understanding of weaving factories and their workings, we also toured Museumfabriek with Edwin Plokker. He is the conservator of the Museumfabriek, who guided us through the machines exhibit, explaining their function and the working conditions of the time.
Once we had established the target audience based on typical museum visitor demographics, we created an empathy map. We identified the average Museumfabriek visitor as a 15-year-old, often visiting with parents or on school trips. This mapping process was a collaborative effort, where we held an open discussion as a team to gain insights and better understand our audience's perspective.
Empathy map made by Nataliia and Carolina
During the first four weeks, our team focused on both historical research and familiarizing ourselves with the software for the project. Our engineer, Jelle, initially set up the project in Git, but switched to Perforce. This was for his personal learning goals, but also because it is an industry standard. Other team members (Senne and Faried) explored tools like Marvelous Designer for the clothing and Wwise (Wouter) for sound design.
I got fitted in the Xsens suit for motion capture, refreshed my skills in Unreal Engine by making particle systems using tutorials, and analyzed the older project files. Since I have experience with Unreal and will be integrating assets alongside Faried, I am one of the few team members with access to the Perforce project files, given the five-user free limit. It took me a while to get used to Perforce, but I was gradually adapting to its workflow.
My initial worries in this project were about over scoping by incorporating the surrounding environment, which was something the client had hoped for. If our team had already been proficient with procedural building placement, it might have been feasible. However, after discussing the matter with the team, we all agreed to focus on refining the interior of the factory instead and improving the environment that had already been created. This approach benefits the client by allowing us to focus on perfecting one key aspect of the project, rather than rushing to meet all demands within the limited timeframe.
Another concern of mine early on in the project was the VR aspect. The team wanted to implement interactions using VR controllers, but based on my experience with VR and Unreal Engine, I knew that could quickly become too complex. Since none of us had substantial VR experience either and we did not have a clear goal to implement VR interactivity through coding, I suggested we keep it simple—perhaps even remove the controllers altogether. This would not only make things easier for us, but it would also benefit the museum. The client had mentioned that the controllers had occasionally gone missing, and removing them would streamline the experience for visitors, reducing wait times.
[Concept for a POI teleportation movement made using Blender by Jelle (Technicjelle, 2024)](https://prod-files-secure.s3.us-west-2.amazonaws.com/81b11ed9-acc1-495c-a2fe-8432b2c84dfa/db22cddd-48f4-48bb-b634-b425ac4fd393/MovementConcept0001-0250.mp4)
Concept for a POI teleportation movement made using Blender by Jelle (Technicjelle, 2024)
Jelle, our engineer, came up with a clever solution: a teleportation system where you simply look at a point of interest (POI), and the system teleports you to a location where a micro-story unfolds. This eliminates the need for learning controls and allows users to jump straight into the experience with minimal effort.
Finally, the team faced the challenge of deciphering the old project. There were two options: either rework the assets in the old project or move them into a new project and reorganize them there. I mentioned that while both options would take time, moving the assets to a new project would provide us with a clearer folder structure. This would make the project easier to understand and manage, rather than wasting time trying to navigate the old structure and replacing or recreating assets anyway.
With the project’s half point approaching, the designers, Nataliia Sviridenko and Carolina Bertoncello Machado, began working on the cost calculations to get an idea of how much it would cost overall. These calculations contained factors such as worker wages, rent and utilities, item depreciation, licenses, and necessary insurance.
Cost calculations for item depreciation by Carolina
Cost calculations for licenses by Carolina
The insurance types used for the calculations include:
Upon discussion with teachers and research into insurance needs, we realized that Inventory, Cyber, and Legal Assistance insurances were unnecessary for this project, therefore the insurance list became the following:
By using proceduralism effectively, not only can we streamline workflows and reduce production time, but we can also significantly lower costs. This efficiency is appealing not only to clients and investors but also to potential employers, as it demonstrates a forward-thinking and resource-conscious approach. Also, addressing technical feasibility—such as enabling functionality using only a headset instead of controllers and ensuring compatibility with an Android build rather than relying on a dedicated gaming setup—further reduces expenses for the client. These considerations make the project more accessible and cost-effective while maintaining quality results.
The final cost of the project, with all variables included — wages, rent, utilities, items, licenses, and insurances — came down to a total of €234,080.
I created the following problem statement out of this research:
<aside> 💡
The appearance of the weaving factory in the VR experience need to convey the bad environment the employees worked in: a dusty, warm and loud factory, while maintaining optimization for the game engine, and ease of use fitted for the museum and its users.
</aside>
We gathered as a team to brainstorm and generate 1-3 concepts each for how the narrative aspect of the project could unfold. We discussed potential interactions (if any) and how the user would engage with the experience. After considering about 10 options, we narrowed it down to three strong contenders.
Concept 1 - Tour
This concept would feature a narrative-driven experience where the user is guided through the factory by a historical figure—such as a museum guide, but styled as a factory worker from the 1930s. The guide would provide insight into the machinery, the workers' roles, and most importantly, the working conditions.
The narrative would be accompanied by sound design that gradually lowers the background noise when the guide speaks. This would make the guide's voice more intimate, almost as if it were in the user's head, and avoid the need for facial capture.
[Concept sketch made by Julia ](https://lh7-rt.googleusercontent.com/docsz/AD_4nXf3wTTA76rGxY9GKJVZGtC8B8VNACBfIXFQVv8RL9fZ6V9o_qNvbpu74Jz681FMxV7_t0JO7v9WZY42J6vj-IpPlLAHtiK8IgX8M1eyGWBxHwNPQ5kCO8W2qX659IwCJMMQ5OU-kMOGN_K4Q56lND6B2OSvhE_hQ3iv0BjYsjDjWu5o4tpwFw?key=nS-26uEE0iNH2rUQVFCb-g)
Concept sketch made by Julia
Concept 2 - POI
Users would be able to explore pre-determined points of interest within the factory. These points would be manually placed during the design process, and the user could teleport between them at will, simply by pointing and clicking.
Once the user teleports to a POI, they receive an exposition about it, possibly from a worker who was stationed there. An additional feature could allow users to teleport via a menu, providing an alternative to the pointing mechanic.
[Concept sketch made by Julia](https://lh7-rt.googleusercontent.com/docsz/AD_4nXc-j-kfqoHOirpp4CqC_loprhHkDvQKmfJDuIeKa7AVD73Tk_E43sNY5ZkJEfoDV-mZsLwl7_bw7U9Wo-PYvRQq8n68epdLY-g3ms1nuXEchMOka5dEY_5dUmrR7VlvI0HTSjokvx-hmTo7NXetF3-4Uc__n1G8Ls_eV40jsewV4wv3KMTu_Tk?key=nS-26uEE0iNH2rUQVFCb-g)
Concept sketch made by Julia
Concept 3 - Live
This concept would immerse the user in the factory as an outside observer—like a ghost who can walk through the factory, observing the workers without being able to interact with the machines. The emphasis here would be on experiencing the environment and the grueling nature of factory life.
The key to this experience would be the workers' actions and behavior, showcasing how difficult, dangerous, and overwhelming their jobs must have been.
To help guide our decision-making, the design team, along with Faried, created a pro and con list for each of the three concepts. After presenting these ideas to the client, we managed to come to a final decision together.
Pro-con analysis made by Faried, Nataliia and Carolina
The final decision was to go with the POI concept. In this VR experience, users would step into the shoes of a 1930s weaving factory worker and encounter micro-stories triggered by specific points of interest as they explore the factory. These stories would depict moments like a worker fixing a machine, a child struggling to keep up with the work, or a supervisor checking in on the team.
The experience would be driven by motion-capture animations, Dutch voice acting, and attention to historical accuracy in both the movements and working conditions of the time. The experience would last 3-5 minutes, emphasizing immersion and visual storytelling, while keeping interactive gameplay to a minimum to maintain a realistic, non-game-like feel. Users would explore at their own pace, with the environment responding to their presence.
Nearing the 3/4th mark of the project, we realized that we needed to downscale our ambitions further in terms of the final concept. While this did not impact my work as much, I am mentioning it here early on in this devlog. As a result, we had to remove the micro-stories and voice acting entirely. The current version of the project is now a VR experience where users can look around, teleport between points, and observe the workers at their stations, but without additional information or unique animations playing when teleporting to different areas. This is unfortunate, but we were short on time and decided on focusing on recreating the atmosphere to the best of our ability.
The Weaving factory project is an ongoing project, which means we inherited the previous asset files. Faried and I reviewed the project together. Visually, it looked good, but when we examined the folder structure, we noticed a significant problem: it was almost non-existent. This is a common issue I have encountered in past projects—trying to work quickly and creating too many assets, which often leads to disorganized folders. For example, having separate folders for models, materials, blueprints, etc., can quickly become chaotic and hard to maintain.
Recognizing this as a potential challenge, I saw an opportunity to streamline our asset management and ensure we did not face problems down the line, such as breaking the project or having to reorganize everything later.
I did some online research and found a helpful guide that addressed this exact issue. Someone had shared their experience organizing Unreal Engine projects, and they had put together a comprehensive structure that could help us avoid chaos.
GitHub - Allar/ue5-style-guide: An attempt to make Unreal Engine 4 projects more consistent
I analyzed the guide and created a condensed version of it for myself and the team. The aim was to keep things clear and simple while following the rules of proper folder structure. I also kept a list of naming conventions, which I could refer back to in case we needed to double-check our naming for consistency.
My condensed folder structure guide Since we decided to start fresh with a new project rather than reworking the old one, I implemented this new structure in the Weaving Factory project. I followed Allar’s guide as well as my own version of it to create a folder hierarchy that would help us stay organized and efficient.
I kept all the VR template assets outside the main Weavery Experience folder because we do not need to modify them regularly. This prevents accidental changes that could break the VR functionality.
Folder breakdown:
There are additional subfolders within these categories, but I intentionally avoided creating redundant folders like "Meshes" or "Materials"—these are typically unnecessary. As noted in Allar’s guide, Unreal Engine allows you to filter by asset type, so there’s no need to create separate folders for each mesh or texture (Allar, n.d.).
Near the end of the project, I asked Jelle, Faried, Carolina and Wouter to sum up how they felt the new folder structure worked for them, since they had access to the perforce, and then of course the project itself. The feedback was positive: the folder structure was laid out sensibly, making it easy for them to quickly locate what they needed by following the sorting system. However, at times, some items were nested too deeply in folders. Overall, the new structure improved the project's workflow and will also benefit the client in the future by making it easier for others to take over the project.
Fabric material
During our visit to the Museumfabriek, I noticed that the fabrics coming out of the weaving machines were not the basic white fabric we had in the old project files. Instead, the museum showcased a variety of fabrics in red, blue, and white, featuring different checker patterns. To ensure historical accuracy in the project, I wanted to replicate these fabric patterns in our project.
Old project file of fabric
Red fabric reference
To achieve this level of detail and accuracy, I decided to experiment with Adobe Substance Designer. I wanted to improve my skills with procedural textures, and this software is ideal for creating this type of work, especially with its powerful tile generation and node-based approach.