top of page

3/30/2026 - Week 1 Milestone

  • Mar 29
  • 3 min read

Updated: Mar 30


This week, we explored multiple options for our project. Some alternative ideas that we didn’t pick were a galaxy simulation or a visualization of how everyday choices impact the environment. In the end, we settled on a VR simulation of kitchen safety to promote safe practices for children and people who may have never been exposed to a kitchen. We chose this option because it balances both engaging elements and social impact, and developing it in a VR space is necessary. Using knives and open flames in a real kitchen can lead to physical injury or property damage, whereas VR provides a completely safe environment to explore these risks. This approach is both novel and non-trivial, as it enables hands-on interaction with kitchen hazards in ways that traditional 2D applications cannot replicate, allowing users to physically engage with objects and experience real-time consequences. Furthermore, it possesses excellent scalability: as players engage more with cooking, they can not only learn to prepare a variety of dishes but also acquire additional kitchen safety knowledge beyond everyday home cooking. Finally, the software has clear financial sustainability, as potential customers—such as kindergartens, elementary schools, and beginner cooking programs—would be willing to pay for an interactive VR tool that safely teaches kitchen safety and basic culinary skills.


In terms of development, we focused on setting up the environment and implementing basic interactions for the VR application. For the environment, we downloaded many prebuilt models from Sketchfab and Fab and used Blender to edit and separate them into individual components to enable future interactions. For example, the microwave, stove and its knobs, faucet and its handles, as well as the refrigerator and its door have all been separated so they can later be used for interaction implementation.


We also focused on some interactions that would be necessary for the game. We set up an affordance-based class to base our interactions on. Two of the most dangerous parts of working in a kitchen are handling sharp objects and the use of heat. So we decided to work on a chopping simulation and a frying/pot simulation.


The pot is a SketchFab model for which the materials have been manually re-created (as it wouldn’t download properly). Attached to it is a HotToTouch blueprint (created as an external component for future modularity), which contains a temperature variable. When the temperature of the object is too high, touching it without oven mitts will “burn” the user. This is implemented as a function call which, for now, simply plays an “Ow” sound, but which can be straightforwardly edited in the future to perform more complex tasks, and is triggered based upon collisions with the player's hands (by binding overlap components, which was a new functionality and took a while to figure out how to implement properly). The oven mitts themselves can be put on by pointing and clicking on them, at which point the models take the place of the user’s hands (via some toggling of visibility settings).


Regarding the cutting mechanic: users can now correctly grasp a knife by approaching the knife block and pressing either the left or right-hand trigger. To put the knife back, simply approach the knife block again and press the trigger using the hand currently holding the knife. For both aesthetic and practical purposes, the knife and mitts cannot simultaneously exist. At present, however, the mittens still register visually as being interactable when the knife is held (i.e., the line trace changes colors) - though they cannot actually be put on, an aim for the next part of the project is to rectify this.


In the future, these base actions will be used to trigger consequences for the user to demonstrate the potential dangers of the kitchen. For example, if the pot is left on the stove for too long, then the room will get smoky, and eventually the fire alarm will go off. The user will then be tasked with dealing with these consequences. We believe that such interaction demonstrates both technical sophistication and novelty.


One issue we encountered this week was with the navigation system - we’ve been able to mostly rectify this by using NavModifier components (so that the user cannot, say, stand on top of the pot) and modifying the vertical offset used when teleporting, but it still requires some further fine-tuning.



 
 
bottom of page