logo80lv
Articlesclick_arrow
Professional Services
Research
Talentsclick_arrow
Events
Workshops
Aboutclick_arrow
Order outsourcing
Advertiseplayer
profile_loginLogIn

VFX Technical Artist on Creating Non-Photorealistic Visual Effects in Godot

Matt Ostertag has told us about getting into VFX art, shared some personal projects, and walked us through the process of setting up the latest artwork in Godot.

In case you missed it

You may find this article interesting

Introduction

Hey, I'm Matt, a VFX Technical Artist and Technical Director at Tuatara. While my background is in programming, I also had a brief stint in law school, although I didn't make it past the first year... twice. It was definitely a failure. However, my true passion has always been in 3D, art, rendering, and games. As a child, I spent a lot of time creating Maps in Warcraft II and later in Warcraft III. I was even part of a modding team for Crysis, which was incredibly cool.

After that law school experience, I pursued a 3-year IT program. I got an internship and my first job as a Unity developer in a service company. I've been mainly working on a house design and decoration tool. As a first professional experience, I learned a lot with great people. However, I still yearned to be a part of the game industry and work on more artistic and visually-driven projects. So, I started learning shaders, tech art, and VFX in my spare time, mostly during evenings and weekends. I think that the very starting point of my VFX career was when I decided to sell my snow package on the Unity Asset Store, maybe 10 years ago. Thanks to that, I started to receive emails from people who wanted to work with me.

Then, I started doing freelance work in my spare time. However, as I began receiving more contracts, I made the decision to become a part-time freelancer. I didn't stop doing personal projects. I continued to challenge myself to grow my skills and fulfill my passion. One day, a guy named Klemen Lozar reached out to me. Thus, began the Tuatara adventure, where I was surrounded by amazingly talented and kind people.

Inspiration

Overall, I'm mostly inspired by everyone out there. What I see on social media, games, blogs, breakdowns, etc. It's like: "Wow that's so cool, I wanna be able to do that too !" and then I jump in. In the process, I think about how I would approach it and how others are approaching it or at least something similar. I then combine those ideas, try them out, fail, and restart from scratch. I continue this cycle until I achieve what I had in mind.

During the creation and learning process, it's like filling my toolbox with new tools. I discover techniques and learn how to use them. As my toolbox grows, I can use, combine, and improve those tools to achieve my vision. Sometimes I even combine them in unusual ways, but hey, it works!

Projects

The personal project I'm most proud of is an environment fan art of Klaus created with Unity, using custom shaders. I used to share many of my experiments on Twitter.

As a freelancer, I have worked on various mobile projects with Battery Acid Games, VR experiences with Estudio Future, fighting games like Icons: Combat Arena, made some Unity tools with Infinite-Realities, and also worked on an emotional puzzle game called Where Cards Fall.

If you want to see some of my old work click here. More recently, at Tuatara, I have been contributing to internal projects such as Bare Butt Boxing, as well as external projects like Somerville, Project L, Unity Demo team shorts, and Battle Shapers for example. To know more about those – it's this way.

Speaking about Switching to Godot

In our industry, things are moving fast, and it's always important to stay up-to-date with new technologies, tools, engines, and so on. I've been using Unreal Engine and mainly Unity during my career. We all know about what happened recently with Unity, this has been debated a lot on social media. I believe that what happened has triggered me to explore new horizons, and Godot seemed to be the next logical step due to its supportive community and potential.

Although Godot is not as mature as Unity or Unreal Engine, I was pleasantly surprised by how accessible it is. As someone coming from Unity, using Godot felt quite natural and straightforward. Additionally, there are already numerous tutorials available, and the community is quite active. I also enjoy Godot because it reminds me of the early days of Unity, maybe I'm just being nostalgic.

As for the future, Unity and Unreal Engine are robust and powerful engines and I'll continue using those because I love them but I'll surely keep experimenting with Godot too.

The Story Behind the Most Recent Fire VFX Project

As I mentioned earlier, I find inspiration in the incredible work I see around me and strive to learn from it by doing similar projects myself. For this particular project, I've been inspired by the work of 千葉章人.

For the Unity version, I wanted to approach it in my own way, with more details. As for the Godot version, it served as more of a pretext to dive into something completely new but within a familiar context. Overall, I simply wanted to learn, have fun, and create something that looks good.

Setting Up the Project in Godot

The setup is basic as the project scope is very limited. I have a Camera and a World Environment to be able to set background colors or post-process like bloom which is useful for this effect.

The first important element to consider is the burning sphere. I'm using a MeshInstance3D with a custom shader made with the Shader Editor. This shader is assigned in the Geometry Material Override. It's almost the same as the one made in Unity, with erosion, vertex offset, distance fields, alpha cutout, emission, etc.

The burning zone is handled in the shader using a sphere distance field driven by a Node 3D with a script. The purpose of the script is to send the position and size information to the material.

I'm getting scale and position from the Node 3D on which the script is set and referencing the Geometry Instance 3D to be able to set related shader parameters.

To optimize my workflow, I added @tool in my script so it is executed in the editor and I don't have to jump in play mode to send Node 3D values. Because of this and how instant the compilation is, iteration time is perfect.

The other important components are the particles. I'm using two GPU Particles Systems and a GPU Particles Collision to generate embers on the intersecting zone between the collider and the sphere. I'll give more details in the next part.

The main challenge here was to discover the engine and understand the concepts but overall it's pretty similar to what I've been using in Unity or Unreal Engine.

Some Words on a GPU Particle System

I wanted to detect where the collider intersects with the mesh and spawn particles on that intersecting zone. So I went to the fastest way possible and ended up using something similar to what I used on Unity.

Here's the setup:

  1. GPU Particle System that scatters particles on the sphere. As you can see those are not evenly distributed but that's okay for that experiment. When colliding with the GPU Particle Collision, they will emit sub-particles. To achieve this, I set the Sub Emitter Mode to "At Collision" and the Collision Mode to "Hide On Contact." I'm also hiding all other particles in the Draw Passes with an alpha clipping using the Alpha Scissor Threshold property.
  2. GPU Particle System that generates ember. It is used as a Sub Emitter in the previous system. The setup is classic using built-in motion, time, and rendering behaviors. Collision is Disabled.
  3. GPU Particles Collision is used to detect collision with the first system.

While this worked well, I see this setup more as a hack, but why?

  • The purpose was not to achieve something production-ready, it was an experiment using simple and built-in features to have something quick and nice.
  • Ember is not spawned only on the intersection zone like in Unity, if the whole mesh is embedded with the collider, it will disappear but continue emitting particles.
  • My knowledge is limited on Godot, maybe it's possible to have custom GPU Particles shaders. This would open a whole new range of customization and could solve the previous point.
  • Having a defined number of evenly distributed points using a point cloud would be better. Maybe using vertices or quads and some scripting to detect collisions and spawn embers? Maybe using some render targets or compute shaders to detect collisions?

If you have other ideas on how to approach this, I would be curious to hear from you. The full breakdown of the effect on Unity is available here.

Final Words and Pieces of Advice

My main tip would be to stay curious and continue to be inspired by our amazing community, regardless of the engine you use: Blender, Unity, Unreal Engine, Godot, etc. Visual effects systems and concepts are universal just like shaders.

Here are some general advice :

  • Have a clear goal, start small then iterate. If you’re aiming for something big, break it down and progress step by step.
  • Don't be afraid of failing and don't be surprised if you struggle when doing things. We all do.
  • Share your work and be proud of what you’ve done. But also be open to feedback and improvement.

On the visual effects side of things, I think that there are three important pillars:

  • Motion: How things are moving and animated. It sets the rhythm, and speed and impacts emotions.
  • Visual: How things are looking. It has a significant impact on emotions and mood through the use of colors and lighting.
  • Technical: How the effect is built within the engine or using tools. It has an impact on the performances and the visual features that are needed to bring your vision to life.

Here's a talk that every visual effects artist should watch:

At Tuatara, we are sharing tips we use all the time when crafting visual effects: click here. We've been also sharing two breakdowns and I made a series of shorts explaining classic tools that should be in your visual effect toolbox. Might be worth taking a look.

  • Unity Enemies – VFX Breakdown
  • Jumpship Somerville – VFX Breakdown
  • Tech Art Toolbox 1 – Erosion
  • Tech Art Toolbox 2 – Remapping

The game developer community is highly present on social networks, even if more scattered than before, take a look at Twitter or X now, Bluesky, or Mastodon. Everyone is always happy to help and share.

Here are also a few Discord servers and websites:

Don't forget about your toolbox. Continuously add tools to it, as that's how your experience will grow.

Matt Ostertag, VFX Technical Artist

Interview conducted by Theodore McKenzie

Join discussion

Comments 0

    You might also like

    We need your consent

    We use cookies on this website to make your browsing experience better. By using the site you agree to our use of cookies.Learn more