Immersive Visual Effects Project 2
IMMERSIVE VISUAL EFFECT
18/5/2026 - 14/6/2026| Week 05 - Week 08
LONG BOJIANG / 0375362 / Bachelor of Design (Honours) in Creative Media
Immersive Visual Effect / Taylor's University
Table of Contents:
Instructions
Lecture
Project
Lecture
week5
Reflection
This week focused on the technical systems behind immersive experiences. I learned that tracking, spatial input, and interaction are not separate parts, but a continuous process that connects the user's physical actions with the virtual world.
Tracking and Presence
Tracking is the foundation of VR interaction. Through 6 Degrees of Freedom (6DoF), the system can understand both the position and rotation of the user's head and hands. I realized that tracking is not only about recording movement, but also about maintaining a connection between what users see and what their body feels.
Even small delays or inaccurate tracking can break immersion and may cause discomfort. This connects with what we learned in Week 4 about cybersickness and proprioception. A successful VR experience needs to keep the user's senses working together.
Spatial Input
This week also introduced different coordinate systems, including head, controller, and world coordinates. I learned that choosing the correct input method affects how natural an interaction feels. For example, head movement can control attention, while controller movement is more suitable for precise actions.
This made me think about our previous Leap of Faith project. Different actions, such as looking down from a rooftop or controlling web-swinging, require different types of input to create a believable experience.
Interaction Design
We also learned four main types of spatial interaction: selection, manipulation, locomotion, and system control. Interaction is not only about making tasks possible, but also about helping users feel connected to the virtual environment.
When interactions feel natural, users become more comfortable and feel that they belong in the space. However, confusing controls can remind users that they are only using a VR device.
Conclusion
Overall, Week 5 helped me understand that immersive design depends on a continuous feedback loop between the user and the system. Presence is not created by visuals alone; it requires accurate tracking, suitable interaction, and smooth responses. The technical foundation behind VR is what allows users to feel truly connected to a virtual experience.
week6
Reflection
This week focused on how to develop a VR project effectively. I learned that creating an immersive experience is not a linear process, but an ongoing cycle of testing, improving, and refining.
Iterative Development
One important idea from this week was that VR projects need continuous testing in real headsets. A desktop preview can show whether the scene works, but it cannot show how the user feels inside the virtual environment. Scale, comfort, and movement issues can only be discovered through actual VR testing.
This changed my understanding of testing. In VR, testing is not only a final quality check; it is part of the design process.
Interaction and Comfort
We also learned that interaction and movement design are closely connected to user comfort. Features like grabbing objects, moving around, and camera movement need to consider how the user's body reacts.
An experience may look impressive, but if the movement feels uncomfortable, it can break immersion. This reminded me that presence depends not only on visuals but also on how natural the experience feels.
Optimization and Production Process
Another key point was that optimization should happen at the right stage. Instead of optimizing everything from the beginning, designers should first focus on the main experience, interaction, and comfort. Once the design becomes stable, performance improvements can be added more effectively.
Conclusion
Overall, Week 6 helped me understand that VR development is a continuous process rather than a simple path from idea to final product. The concepts from previous weeks, such as presence, interaction, and comfort, need to be tested and improved throughout the whole project. The goal is to create an experience that feels natural and seamless for users.
week7 No class
week8
Reflection
After learning about presence, perception, and interaction systems in the previous weeks, this week focused on how to build a VR environment that can support a believable experience. I learned that presence is not only created by advanced technology, but also by careful design decisions such as scale, layout, and usability.
Scale and Realism
One important topic this week was the importance of correct scale. I realized that scale is not just a modelling standard; it directly affects how users feel inside a VR environment. Objects that are too large or too small can make the space feel unnatural and reduce the user's sense of presence.
Correct scale also affects interactions, such as grabbing objects or moving through the environment. A consistent physical world helps users trust the virtual space.
Affordance and Interaction
We also learned about affordance, which means objects should communicate how they can be used through their appearance. For example, a handle suggests that a door can be opened, and an object that looks reachable encourages users to interact with it.
This connects with previous weeks about interaction design. Good design should make actions feel natural without requiring too many instructions.
Spatial Layout and Ergonomics
The layout of a VR environment is also important. The structure of the space, including pathways, entrances, and interactive areas, should guide users naturally. A clear layout helps users understand where to go and what to focus on.
We also discussed ergonomics, such as comfortable viewing angles and placing UI elements inside the environment. These details help reduce discomfort and maintain immersion.
Conclusion
Overall, Week 8 helped me understand that creating presence depends on many small design choices. Scale, interaction, layout, and comfort all contribute to whether users feel like they are truly inside a virtual world. Immersive design is not only about creating impressive visuals, but also about building a space that feels natural and believable.
Project
Adding a "Glitch Effect" to My Little Pony: A Debugging Log
Project Background
For this assignment, I worked on a 3D-scanned indoor scene and needed to add a "glitch" effect to one specific object in it — a plush My Little Pony toy. When triggered, the pony should shake slightly and its colors should distort, then smoothly return to normal when released. The rest of the scene (sofa, windows, etc.) had to stay completely unaffected.
It sounded simple enough, but almost every step ran into a problem, and the debugging process took much longer than expected. Here's a record of the whole thing.
First Attempt: Failed — the Object Just Disappeared
My initial idea was to "pull out" the pony and give it its own separate material, keeping it isolated from the rest of the scene so that changes to it wouldn't affect anything else.
After writing and running the code, the pony simply vanished from view. Only the scene remained, and naturally no effect showed up either.
Debugging Step One: Software Version Mismatch
My first guess was a version issue. Sure enough, checking the settings showed the editor had a newer version selected, but the app was actually still running an older one — meaning the version switch hadn't actually taken effect. A page refresh fixed the mismatch.
Lesson: after switching software versions, always confirm the change actually took effect — don't just trust what's shown in the settings.
Debugging Step Two: An Outdated Approach
With the versions aligned, testing again brought up a console warning saying that the old method of "pulling an object out to handle it separately" was deprecated and no longer recommended — the new default was to handle everything uniformly instead.
That was exactly the problem: the scene was already using the new "handle everything uniformly" approach, while I had forced the pony into the old "separate" approach. The two methods clashed, causing rendering order to break, and the pony ended up hidden when it should have been visible.
Debugging Step Three: The New Method Didn't Work Either
Since I needed to stay consistent with how the scene was rendered, I looked into the official "modify just one object without affecting the rest" method. After switching to it, the logs looked fine, but there was still no visible effect.
Further testing confirmed this newer method just wasn't reliable in the current software version, so I had to abandon it and fall back to an older, more established approach.
Debugging Step Four: The Program Crashed Completely
After looking at a classmate's code, I switched strategies to modifying a "scene-wide" setting — a mature and stable approach, but with the downside that it affects everything in the scene by default, not just the pony.
To make it target only the pony while leaving the scene untouched, I first tried identifying each object with an ID number. The syntax was wrong, though, and it crashed the whole program — and this crash was worse than before, turning the entire scene into a blank screen with nothing visible at all.It was the scariest moment of the whole process.
After giving up on the ID-based approach, I switched to something simpler:drawing a circular range around the pony's actual position in the scene, so only whatever fell inside that circle would get the effect, leaving everything outside untouched.
Debugging Step Five: The Most Hidden Problem of All
This version ran without any errors, but testing revealed yet another strange issue: no matter how I adjusted the settings — even cranking the effect to an exaggerated level that should have been impossible to miss — the screen still didn't budge.
I only found the cause through a brute-force approach: instead of "grabbing the asset once at the start and reusing that same copy," I changed it to "grab the latest copy fresh every single time it's needed." That fixed it.
The reason turned out to be this: both the scene and the pony use a format that streams in while loading. Early on, the program was probably handing me a temporary placeholder asset, and once the real data finished loading in the background, the program quietly swapped it out for a new one. What I had grabbed and stored at the start was that already-discarded placeholder — everything I modified afterward was effectively dead and useless, which is why nothing changed on screen. And this whole process never threw a single error, making it extremely hard to spot.
Final Solution
Putting together everything learned from the debugging process, the approach that finally worked reliably was:
1. Skip both the old "pull it out separately" method and the still-unreliable new method, and go with the most stable option: modifying the scene-wide setting;
2. Never cache the asset ahead of time — always fetch the latest copy right when it's needed, to avoid working with an asset that's already been swapped out;
3. Use the object's actual position in the scene plus a defined range to decide whether the effect should apply, rather than relying on ID-based identification — simpler and more stable;
4. The effect itself gradually fades out over the trigger duration — the pony's position and color shake and shift randomly, then ease back to normal. A safeguard was also added to prevent the effect from stacking up if the trigger key is held down continuously.
Takeaways
Looking back, the hardest parts of this process weren't the ones that came with error messages — several times when I got stuck (the object disappearing, the screen not responding at all), there were no errors whatsoever.The problems were hiding somewhere invisible inside the program. This taught me that no errors doesn't mean no problems — when something just isn't responding, it's more effective to patiently rule things out step by step (like deliberately testing with an exaggerated, unmissable effect just to confirm whether something is actually working) rather than continuing to guess based on assumptions.
I also came to appreciate that with newer technologies like this, the recommended methods and best practices change quickly. When running into problems, checking the latest official documentation is far more reliable than relying on past experience.
Reflection
Experience
Weeks 1–4 gave me a vocabulary for presence and immersion; Weeks 5–8 was where that vocabulary met the actual mechanics of building something. Week 5 introduced 6 Degrees of Freedom and the idea that tracking, spatial input, and interaction are really one continuous process. It made me realize how much of "presence" I had treated as a purely visual problem, when a lot of it comes down to tracking accuracy.
Week 6 shifted from a single moment to an entire project: VR has to be tested repeatedly inside a headset rather than judged from a desktop preview, and optimization comes later, not earlier — which went against my instinct to build once and polish in place. Week 7 had no class, giving me time to sit with that before Week 8 made things concrete: scale discipline, affordance, layout, ergonomics.
The clearest place I actually felt all of this was debugging a Gaussian Splatting glitch effect for a scanned object in a PlayCanvas scene — a small project running on the same underlying logic as the lectures. The goal was simple: make one object shake and distort on trigger without touching the rest of the scene. It took five rounds of debugging, and most of them turned out to be hands-on versions of things the lectures had only described in the abstract.
Observation
The clearest pattern is how closely Week 6's argument about iteration matched what actually happened. I could not tell whether an approach worked without launching the scene and testing it — several "fixes" only turned out wrong once I tested the next round. That's a literal version of "testing is part of the design process," just applied to whether an object rendered at all rather than to comfort.
A second observation: most failures were completely silent. The object would vanish, or the whole scene would stop updating, with no error at all — the real cause (a rendering-mode conflict, or a cached material reference that had quietly been replaced) stayed invisible. This mirrors Week 5's point that tracking problems are dangerous because they're easy to miss — a system can look fine while still doing the wrong thing.
A third observation: scale and range showed up as problems here the same way Week 8 described for layout. Once the shader logic finally worked, the effect still didn't show up — the jitter amount and the affected radius were just too small relative to the object. That's Week 8's scale-discipline argument in miniature: a value can be technically correct and still fail until it's tested in place.
Findings
The clearest finding is that "no errors" cannot be treated as evidence something is working. Several of the hardest problems produced a completely clean console until I forced a deliberately exaggerated test just to check whether the mechanism was connected to anything at all. That brute-force verification step is one I want to carry into VR testing, where a comfort or interaction issue that never throws an error seems just as likely to hide in plain sight.
A second finding is that iteration applies to the underlying system just as much as to comfort or layout. Every round of debugging shifted my assumption about which layer was responsible — a version mismatch, a rendering-mode conflict, an unstable API, a scale problem — and none of that surfaced from documentation alone; each only became visible through testing.
The broader finding tying Weeks 5–8 to this project is that presence and functionality both break quietly, at a scale too small to notice until tested in real context — Week 5 at the level of tracking, Week 8 at the level of individual assets, this project at the level of a single shader value. Going forward, the standard I want to hold myself to is treating every test as one pass through a loop I expect to repeat, not a decision I make once and move past.
Comments
Post a Comment