Smbat Voskanyan

Resume

Thu, 22 Feb 2024 00:00:00 +0000

/ [pdf]

Tiny Ray Tracer

Tue, 20 Feb 2024 00:00:00 +0000

I have a background in programming, including a keen interest in graphics and game engine development. Inspired by the “Raytracing in One Weekend” book series and Jacco Bikker’s insightful blog on ray tracing optimizations, I set out to build my own ray tracer. My goal was to create a feature-rich ray tracer with a focus on performance. The source code is avaible on ~~my github page~~. The rendered results are in the /renders folder.

Foundational Features

Scene Creation and Camera

To start, I implemented camera controls with “look-at” functionality. This allowed me to position the camera flexibly within a scene and adjust the image framing. I worked on defining basic materials: diffuse for matte surfaces, metal with adjustable fuzziness, and transparent glass. This enabled me to create scenes with a variety of visual effects.

Anti-aliasing was crucial for reducing jagged edges and creating smoother renders. I also tackled issues like shadow acne, where incorrect shadow calculations lead to visual artifacts.

A final render from this part of the journey, which took ~12 minutes to render. Enjoy!

The Power of Optimization

Early Multi-Threading Success

I began my performance work with multi-threading. Since ray tracing is inherently parallelizable (rays are independent calculations), this yielded immediate speedups.

With great models comes great amount of primitives

To make my scenes more interesting it was time to add support for triangles and models. For ray triangle intersection I implemented class Möller–Trumbore intersection algorithm, which is still pretty close to ‘as fast as possible’. Next, I hooked up Assimp for loading .obj wavefront files with their diffuse materials.

The Heart of Acceleration: Bounding Volume Hierarchies

Since I had the models it was time to optimize, so I focused on implementing BVHs Bounding volume hierarchy. The article series by Jacco Bikker were a great help for implementing fast BVHs. The performance gains here were even more drastic.

4882 Spheres Scene
*No BVH: 52936ms
*Simple BVH: 896.871ms
*Simple Jacco BVH: 1391.54ms
*SAH Jacco BVH: 1321.69ms
*SAH Jacco Iterative BVH: 725.51ms

11102 Triangles Dragon Model
*No BVH: 250936ms
*Simple BVH: 3904.27ms
*Simple Jacco BVH: 1522.3ms
*SAH Jacco BVH: 1298.32ms
*SAH Jacco Iterative BVH: 974.8ms

From numbers you can see around 70 times faster render time for spheres scene and mind-blowing 250 times faster rendering on dragon scene.

Lessons Learned

Performance is King

The BVH optimizations were a turning point, demonstrating the significant impact of efficient algorithms and data structures on rendering speed. There are other dirty optimizations, that I have on my to-do list, but I left them for later to keep the code readability simple for now.

Debugging Tales

Funny Visual Glitches

I encountered some annoying/amusing visual errors where models would render with parts inverted or cut off. Both issues stemmed from returning from intersection searches too early. Thorough testing with simplified models and debugging sessions resolved these.

The Missing Volume

A numerical bug caused triangle bounding boxes to become flat, preventing ray intersections. After much head-scratching, I solved it with minor padding, similar to a solution mentioned in Peter Shirley’s book.

Updates: Scaling Up and Optimizing Further

After implementing BVHs based on Jacco’s series, I successfully rendered a single robot. But who doesn’t love a robot army? Scaling up to 256 robots demanded an extra layer of optimization to manage this scene complexity.

Here’s what I added:

TLAS (Top-Level Acceleration Structure): TLASes act like a ‘manager’ over multiple BVHs. They use agglomerative clustering, a bottom-up approach that makes building the hierarchy faster. This is important when dealing with lots of individual models.

BVH Instances: These provide a flexible way to wrap my existing BVHs in a way that allows me to easily transform (translate, rotate, scale) the models. This let me position my robot army without having to rebuild the BVH for each robot.

As a result we have a significant speedup, allowing me to efficiently render a scene containing hundreds of complex models.

I present you 256 robots in rotation.

Putting it all Together: Lights, Camera, Render!

Since I had all the pieces of the puzzle, it was only natural to put them together. With the ability to render spheres, complex models, and multiples of them efficiently, it was time to build a compelling scene. However, a truly eye-catching scene requires well-placed lighting. Let’s dive into how I implemented emissive materials.

Emissive Materials: Letting Robots Shine

To give my robots a striking appearance. I introduced an emissive material type. It works by biasing how light rays scatter, making certain surfaces appear to emit light. The implementation was straightforward, but the results transformed the look of the scene.

This addition laid the foundation for creative lighting design. With everything in place, I’m eager to share the final scene in my next update!

Final Renders: When Visions Shift and Robots Party

The Epic (and Unexpectedly Funny) First Attempt

My first idea was to make this scene I had in mind for a couple of weeks. Sun surrounded with EVA-01 robots from the Evangelion series. There were many tiny spheres which surrounded the scene and looked like particles from the sun. In my mind, I though it was the most epic shit, however the results turned out rather funny.

One of my friends sent me this meme when he saw the render, which made it even funnier.

Pivoting to Awesome: The Robot Party is Born

No time to play! I still wanted to make a cool-looking render, so I reimagined the whole scene to look like a cool robot party with a bunch of emissive spheres and a light beacon in the middle. I think the results turned out super cool!

Lessons Learned

This whole experience taught me a couple of things:

The Unexpected is Part of the Fun: Sometimes, the best things come out of left field. A little humor and a not-so-perfect first render can make the process even more enjoyable.
Don’t be Afraid to Iterate: If something isn’t working, toss it and start again! There’s no shame in changing direction to find something truly awesome.
Visuals Matter (and Robots are Cool): A great final render is its own reward. Plus, ray tracing can make robots look absolutely epic (even when they’re partying).

I hope you enjoyed this peek into my ray tracer project – from epic fails to robot raves!

Thanks

First, I wanted to thank Peter @Peter_shirley Shirley and Jacco @j_bikker Bikker for putting such high-quality content out there for free, for people like me to be inspired and thrive to improve our skills in computer graphics.

Secondly, I want to thank my friends and brilliant game developers Andranik @andranik3949 Melikyan and Bagrat @dBagrat Dabaghyan for helping me out when I got stuck with stupid bugs and getting me out of burnout state!

Next Steps:

Lighting Expansion: Update: Completed! Implementing emissive lights will allow for more realistic and nuanced lighting effects.
Better Model Support: Add support for Normal Mapping, Metalness and Roughness maps. Although, for later other stuff should be refactored too. Advanced Sampling: I’ll explore monte carlo algorithms for smoother images and reduced visual artifacts and other probabilistic models for predicting properties of light scattering in scene.
GPU Acceleration: Re-implementing my path tracer in CUDA will allow for faster render times and the ability to tackle even more complex scenes.

Talos VFX

Sun, 23 Jul 2023 00:00:00 +0000

Introduction

Talos VFX is a powerful open-source visual effects editor designed for Java and LibGDX projects. Create stunning particles, shaders, and custom scripts, while seamlessly managing game assets – all from a single workspace. Its intuitive, node-based VFX editor and support for visual programming routines (similar to Unreal Engine’s blueprints) empower you to craft dynamic effects. Build 2D levels and scenes with brushes, and bring your creations to life with Spine2d skeletal animations, easily attaching VFX directly to animation bones. While primarily focused on 2D, Talos VFX also offers limited 3D support.

As a major contributor to Talos VFX, I’ve played a role in squashing critical bugs, implementing user-requested features, and refining the overall user experience. As of writing this post I authored around ~50% of Pull Requests on the project. Here’s the link to project. Note, that active development is carried on talos-3d branch and master branch is greatly behind.

Feature Development

Since a lot of features were missing initally and we needed many tools for our prototypes, I had a chance to contribute a lot in this area.

Fake BVB" (Bone Attachment Support)

Problem: Users were limited in how they could interact with skeletal animations, hindering dynamic effects and customization.
Solution: Implemented “Fake BVB” functionality, exposing animation bones as restricted game objects within Talos, enabling the attachment of other objects.
Result: Users can now create more complex and visually engaging effects by directly linking particles, objects, and more to skeletal animations. Examples include attaching characters to moving vehicles or syncing particle effects to bone movements.

NineSlices Support and Sprite Editor

Problem: Users lacked advanced scaling options for UI and graphic elements, limiting design flexibility. Limited or inefficient tools for sprite editing and managing NineSlice metadata within Talos VFX.
Solution: Implemented NineSlice rendering functionality, providing a system similar to Unity’s NineSlices. This allows specific sections of images to be repeated horizontally, vertically, or in both directions.
Result: Improved control over how UI elements and graphics scale, enhancing the ability to create visually polished and responsive interfaces within Talos VFX.

I have fixed more bugs than I could remember, however to recall some off the top of my head, then these would be the ones.

Project Explorer Stability and User Experience

Problem: File management was unreliable, with crashes and unexpected behaviors. Crashes when moving or renaming files. Bad user experience. Poor file search performance.
Solution: Revamped project explorer logic, preventing errors and ensuring a smoother file management experience. Refreshed the UI for more costumization and assets previews. Fast asset lookup.
Result: Increased stability and reliability within Talos VFX, protecting user work. Happy users.

Routine Workflow

Problem: Editing curves within the Routine App was buggy, hindering intuitive workflow.
Solution: Fixed curve gizmo display and interaction points, including inserting new points and using the ESC key.
Result: Restored smooth and predictable curve editing, streamlining the creation of dynamic effects within routines.

Concusion

Through this project, I’ve learned many new topics and significantly improved my knowledge in Java, libGDX, and 2D engine development tools. It was both challenging and rewarding to work with a community of people directly affected by my contributions. Seeing others use Talos VFX to create amazing games is a deeply satisfying experience.

Tiny World

Thu, 05 Jan 2023 00:00:00 +0000

I’ve created a game engine from scratch featuring a tiny world. This project aimed to demonstrate my understanding of 3D graphics programming and the principles of perspective, lighting, and texturing. I had a lot of fun implementing the water. It features Fresnel Effect, samples skybox and terrain for realistic reflections and uses depth buffer information to achieve soft edges. I wrote the project purely in Java and OpenGL, and the source code is available on git.

Furthermore, this is a personal live project meaning it will be constantly updated with new stuff as I keep learning new techniques and would want to practically apply them somewhere. Specifics and more details about the project, and how to run it on your local machine are uploaded to the webpage provided in the link. Enjoy!

Source code for curious ones.

AI Algorithms Practice

Thu, 22 Dec 2022 00:00:00 +0000

I took a bonus assignment for my Artificial Intelligence course. The work demonstrates the implementation of various algorithms for solving the n-puzzle problem, along with useful statistics for analysis. Due to the professor’s request, I have made the repository private, so students of upcoming years will not copy it, but you can access the code with this link.

Statistics

Part 1

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


Executed Breadth First Tree Search
Nodes Generated 2298274; Max Nodes in frontier 1473871

Executed Breadth First Tree Search with Early Goal test
Nodes Generated 824404; Max Nodes in frontier 537119

Executed Breadth First Graph Search
Nodes Generated 5019; Max Nodes in frontier 1926

Executed Breadth First Graph Search with Early Goal test
Nodes Generated 4644; Max Nodes in frontier 1075

Skipped the execution of Depth First Tree Search
Algorithm gets into an infinite cycle of Right <-> Left actions

Executed Depth First Graph Search
Nodes Generated 68217; Max Nodes in frontier 29633

Executed Iterative Deepening Tree Search
Nodes Generated 34232; Max Nodes in frontier 43

Both Breadth First Tree and Graph Searches found the optimal solution. Clearly huge improvements are observed with graph search version and the early goal test gives the extra bonus of cutting off extra nodes, that would be generated otherwise.
Although, Depth First Tree Search is known to consume very little memory space it is not effective in this case as it gets into an infinite loop.
Depth First Graph Search does a better job, than its Tree Search version xD. However, it generates many more nodes, than Breadth First Graph search and has a bigger frontier stretch. Iterative Deepening Tree Search did a good job to find a solution, and it also spent very little memory. However, it is also worth to mention, that IDTS did not find the optimal solution. Also still, 4644 + 1075 < 34232 + 43 it still consumes more memory. You may argue, that compared to BFGS, IDTS does not use an extra set to keep track of reached states, however reached states is not really making new states, but rather keeps references, which is still much less, than what we get with IDTS.
Overall, Breadth First Graph Search with the early goal test comes out as a winner in uninformed search category, reason being, that it just works better for this problem.
As it says in the book

When all step costs are equal, breadth-first search is optimal because it always expands the shallowest unexpanded node.

Part 2

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


Executed Uniform Cost Tree Search
Nodes Generated 2587508; Max Nodes in frontier 1653452

Executed Uniform Cost Graph Search
Nodes Generated 7549; Max Nodes in frontier 1656

Skipped the execution of Greedy Tree Search with h1 number of misplaced tiles
Algorithm gets into an infinite cycle.

Skipped the execution of Greedy Tree Search with h2 manhattan distance
Algorithm gets into an infinite cycle.

Executed Greedy Graph Search with h1 number of misplaced tiles
Nodes Generated 233; Max Nodes in frontier 68

Executed Greedy Graph Search with h2 manhattan distance
Nodes Generated 1051; Max Nodes in frontier 267

Executed A* Tree Search with h1, number of misplaced tiles Tree Search
Nodes Generated 964; Max Nodes in frontier 613

Executed A* Tree Search with h2 manhattan distance Tree Search
Nodes Generated 120; Max Nodes in frontier 74

Executed A* Graph Search with h1 number of misplaced tiles
Nodes Generated 360; Max Nodes in frontier 91

Executed A* Graph Search with h2 manhattan distance
Nodes Generated 106; Max Nodes in frontier 29

Before we continue any further, I would like to right away give the trophy to A* Graph Search with Manhattan Distance heuristic.
Let’s jump into it! Right away we can see that Uniform Cost Tree Search gave similar results to Breadth First Tree Search. Reason is that action cost is 1, and path costs gets incrementally bigger with each level forcing UCS to iterate in Breadth first manner. Reason why numbers are not same is connected to the fact how JDK implemented the PriorityQueue, which means it is not guaranteed to return the leftmost node in the same level.
Same goes for Uniform Cost Graph Search and Breadth First Graph Search.
Neither Number of Misplaced Tiles heuristic, nor Manhattan Distance heuristic are good enough on their own to run Tree Search, therefore Greedy Tree search gets into a cycle. Again quoting the book:

Algorithms that don’t remember the past are doomed to repeat the history.

Regarding A* Search we see power of good heuristic, because A* Tree Search with Manhattan distance performs better than A* Graph Search with Number of Misplaced Tiles heuristic. It is proved in the book that h2 dominates h1.
It also has lower Effective Branching Factor.

d	BFS	A*(h1)	A*(h2)
6	2.01	1.42	1.34
8	1.91	1.40	1.30
10	1.85	1.43	1.27
12	1.80	1.45	1.28
14	1.77	1.47	1.31
16	1.74	1.48	1.32
18	1.72	1.49	1.34
20	1.69	1.50	1.34
22	1.66	1.50	1.34
24	1.62	1.50	1.36

Overall, obviously and for the reasons mentioned before, A* Graph Search with Manhattan Distance heuristic comes top as a winner.

Solution

Following is a demonstration of A* Graph Search on 8-puzzle with Manhattan Distance heuristics.

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139


0: start

-------------
| 7 | 4 | 2 |
-------------
| 8 | 1 | 3 |
-------------
| 5 | | 6 |
-------------

1: move LEFT

-------------
| 7 | 4 | 2 |
-------------
| 8 | 1 | 3 |
-------------
| | 5 | 6 |
-------------

2: move UP

-------------
| 7 | 4 | 2 |
-------------
| | 1 | 3 |
-------------
| 8 | 5 | 6 |
-------------

3: move UP

-------------
| | 4 | 2 |
-------------
| 7 | 1 | 3 |
-------------
| 8 | 5 | 6 |
-------------

4: move RIGHT

-------------
| 4 | | 2 |
-------------
| 7 | 1 | 3 |
-------------
| 8 | 5 | 6 |
-------------

5: move DOWN

-------------
| 4 | 1 | 2 |
-------------
| 7 | | 3 |
-------------
| 8 | 5 | 6 |
-------------

6: move DOWN

-------------
| 4 | 1 | 2 |
-------------
| 7 | 5 | 3 |
-------------
| 8 | | 6 |
-------------

7: move LEFT

-------------
| 4 | 1 | 2 |
-------------
| 7 | 5 | 3 |
-------------
| | 8 | 6 |
-------------

8: move UP

-------------
| 4 | 1 | 2 |
-------------
| | 5 | 3 |
-------------
| 7 | 8 | 6 |
-------------

9: move UP

-------------
| | 1 | 2 |
-------------
| 4 | 5 | 3 |
-------------
| 7 | 8 | 6 |
-------------

10: move RIGHT

-------------
| 1 | | 2 |
-------------
| 4 | 5 | 3 |
-------------
| 7 | 8 | 6 |
-------------

11: move RIGHT

-------------
| 1 | 2 | |
-------------
| 4 | 5 | 3 |
-------------
| 7 | 8 | 6 |
-------------

12: move DOWN

-------------
| 1 | 2 | 3 |
-------------
| 4 | 5 | |
-------------
| 7 | 8 | 6 |
-------------

13: move DOWN

-------------
| 1 | 2 | 3 |
-------------
| 4 | 5 | 6 |
-------------
| 7 | 8 | |
-------------

Battle Cards: Real-time PVP

Fri, 25 Feb 2022 00:00:00 +0000

Check out Battle Cards! It was an incredible journey that began at the Playcrafting NYC Game Jam 2021. Our team managed to create a compelling multiplayer prototype in just two days, earning recognition from the judges. Built with Java, LibGDX, and a Node.js backend, we had a solid foundation for a full release. Seeing the positive response, we decided to take “Battle Cards” to the next level. After a year of dedicated development, we launched a polished version that players genuinely enjoyed.

My contributions centered on the UI, ensuring new features, code refactoring, and optimizations all worked toward a seamless player experience. However, being part of a small team meant I got to wear many hats! I contributed to gameplay programming, designed some eye-catching VFX, and tweaked the backend for better performance. For our marketing efforts, I created a compact 2MB playable ad to showcase the heart of the game.

Additionally, I collaborated closely with our analytics team to improve dashboards, graphs, filters, and other tools. Our goal was to make analyzing user experience more accessible, enabling us to make informed game design changes. Ultimately, my focus was on making sure “Battle Cards” didn’t just look good – it had to play well too. It was a challenging, yet incredibly rewarding project.

Sandship: Crafting Factory

Mon, 15 Feb 2021 00:00:00 +0000

Explore the world of Sandship blends the vastness of a Dune-like world with the addictive mechanics of Factorio. It was one of my first projects at Rockbite Games and offered an array of exciting technical challenges. I played a crucial role in crafting the game’s UI, implementing new elements, extensively refactoring for efficiency, and squashing bugs. Java and LibGDX were my tools of choice.

My work wasn’t limited to just the UI. As part of a small team, I contributed in many areas from backend development to gameplay programming. One standout feature for me was the “News” system. To keep players connected, I built a Node.js microservice allowing our Community Management team to post website updates that seamlessly appeared in-game.

Ultimately, I made sure “Sandship” delivered a visually engaging and smooth player experience. Tackling these challenges was as rewarding as seeing players immersed in the world we built.

Search

Mon, 01 Jan 0001 00:00:00 +0000

Smbat Voskanyan

Resume

Tiny Ray Tracer

Foundational Features

Scene Creation and Camera

Image Refinement

The Power of Optimization

Early Multi-Threading Success

With great models comes great amount of primitives

The Heart of Acceleration: Bounding Volume Hierarchies

Lessons Learned

Performance is King

Debugging Tales

Funny Visual Glitches

The Missing Volume

Updates: Scaling Up and Optimizing Further

Putting it all Together: Lights, Camera, Render!

Emissive Materials: Letting Robots Shine

Final Renders: When Visions Shift and Robots Party

The Epic (and Unexpectedly Funny) First Attempt

Pivoting to Awesome: The Robot Party is Born

Lessons Learned

Thanks

Next Steps:

Talos VFX

Introduction

Feature Development

Fake BVB" (Bone Attachment Support)

NineSlices Support and Sprite Editor

Bug Fixes and Refinements

Project Explorer Stability and User Experience

Routine Workflow

Concusion

Tiny World

AI Algorithms Practice

Statistics

Solution

Battle Cards: Real-time PVP

Sandship: Crafting Factory

Search