Heya folks.

It was lovely to see a bunch of you on the bimonthly banter last week. Since then I’ve been keeping busy.

Monday was spent on research. I had a terrifying number of tabs queued up, and it was time to work through them! The reading was not focused on a specific feature, but instead is about giving me new tools to apply when challenges appear. I won’t link everything I was working through, but here are three I enjoyed:

• Ray Tracing of Signed Distance Function Grids It was really neat to see how to use trilinear interpolation to get the exact ray intersection.

• H-PLOC: Hierarchical Parallel Locally-Ordered Clustering for Bounding Volume Hierarchy Construction We have a lot of things to draw so techniques for quickly building volume hierarchies are always of interest. Also I’m not as familiar with more complex compute strategies so this exposed me to a little of that.

• Filtering, Convolutions, and Quaternions This is such a gem. Incredibly well written, and a goldmine of information. Unlike many of my friends, I don’t have an audio background, and so didn’t get exposure to signal processing until much more recently. This article was just what I needed to start a whole bunch of puzzle pieces falling into place in my head.

So a very fruitful day, all in.

Today I’m back on physics. I’m slowly updating our frontend to the engine, trying not to break anything in the process :) If all goes well this will give a good performance boost to the physics code.

That’s all from me today. See you in the next one.

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team

Heya folks,

Wait.. I already did this today. I wrote a dev-log, and then told myself, “Alright, I’ll just code this one thing and then post it”… and now it’s midnight. So, just before my original dev-log here is the one from today:

I worked on exactly the kind of polish I mention below, with lots of focus on how the system communicates errors to the user.

I’ll leave it at that as there’s already a whole post to read.

Bye!

Heya folks,

Work continues well on the VFX-System[0]. Over Friday and Monday, I got the effects running in Unity’s edit-mode instead of just play-mode. This makes it way easier to iterate without having to start the game every time. It took a little extra prodding to get it behaving well in prefab-scenes too, but that also works as expected.

Along with the usual bug fixes, I also got to work on little details that make the experience nicer for the artist. Nicer defaults in new assets, right-click menu options for easily adding effects to scenes, pre-configured effects so things are immediately visible when you create them. And so on.

Today I’m going to continue working on polish, and then I’ll dive back into effects that procedurally generate geometry, instead of just drawing meshes or billboards. We had that working in an earlier build, so I don’t foresee that being difficult.

After that, it’s all about fleshing things out! I’m hoping to hand this over to Ree later this month. Then, as they explore what Alex and I built, I’ll get stuck into the next project (the system architecture improvements I mentioned in a previous log).

Today is one of those wonderful days where the road, while long, seems clear. TaleSpire is a lovely project to work on, and it’s going to get so much better.

I hope inspiration finds you today too.

Peace.

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team

[0] I’ve been calling it a particle system, as the name was more familiar. However, in our current terminology, the top-level concept is an ‘Effect’. An effect is a container for multiple ‘Particle Systems’. Each particle-system updates separately, but each particle can add new particles to any of the other systems (amongst other things).

Today I continue plugging away at our effect system.

I’ve been steadily writing code to handle the various ways an artist may reconfigure the effect while it runs.

It’s a lot of work, but I’m seeing the light at the end of the tunnel. Tomorrow I hope to finish the code around particles that spawn other particles, and to take a good crack at the code that uploads uniforms to the compute-shaders. There are improvements to both that have been on my wishlist.

That’s all from me,

Goodnight from Norway.

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team

Allo folks,

This dev-log is for the last two days

I’m working on the code that runs an “effect” as defined in our particle system. This code is currently called the “effect-driver” which may change, but will do for this log.

The effect-driver is a MonoBehaviour (a component that lives on Unity’s GameObjects and gives them behaviour) that holds a reference to an effect made in our system. It then does three main things:

1. Dispatches the various compute-shaders that updates the particles, and then the code that draws them

2. Notices any changes to the definition of the effect and updates or recreates the buffers used for the effect

3. Provides a Unity-friendly UX to the folks configuring the effects. This means both that it’s associated with a GameObject and that it provides UI in the inspector to configure the values used by the effect.

This is already a bunch of work, but there are also other concerns. Unlike normal game code, we need the effect to run in edit-mode rather than just play-mode. This is the norm for tools like these, it would suck to have to run the game every time you wanted to tweak how a particle effect would behave.

There is a tool for this, ExecuteAlways. I’m getting used to how this works. Along with disabling domain-reload (which I mentioned in the last log), this does make fairly major changes to the normal flow of a MonoBehaviour’s lifecycle, so I’m having to read a lot to make sure I have actually understood what it’s doing.

Progress is steady though. I am currently working on the code that works out what parts of an effect have changes and reconfigures the driver.

Until next time.

Peace.

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team

Heya folks,

Today I worked on updating a bunch of our libraries to support a feature in Unity: Disabled domain reload

You can find out the official details here. It does a good job at explaining it actually, so I’ll quote it here:

Domain Reloading resets your scripting state, and is enabled by default. It provides you with a completely fresh scripting state, and resets all static fields and registered handlers each time you enter Play Mode. This means each time you enter Play Mode in the Unity Editor, your Project begins playing in a very similar way to when it first starts up in a build.

Domain Reloading takes time, and this time increases with the number and complexity of the scripts in your Project. When it takes a long time to enter Play Mode, it becomes harder to rapidly iterate on your Project. This is the reason Unity provides the option to turn off Domain Reloading.

It doesn’t affect you folks directly, as it’s purely a Unity Editor thing, BUT being able to iterate faster will be huge for us, so it’s worth the investment.

It took all day, but in the project where I am developing the particle system, the time to enter play-mode went from over six seconds to under one! I’ll take it.

Learning this has been very useful so now I can dive into writing code to run the effects in edit-mode with more certainty.

Until tomorrow,

Peace.

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team

Friday went well enough. I was preparing to rewrite the editor code that runs the effects, as I need to make it work outside of play-mode.

This was a good time to restructure the project, so I was doing that and experimenting with what Unity allows it terms of spreading the definitions of scriptable objects over multiple assemblies. The answer is, in short, it doesn’t. The C# compiler is happy enough with it, but Unity’s runtime is not. It’s fine though, it was simply an effort to keep the codebase cleaner by separating the code that is needed at runtime from the parts that are not.

Tomorrow I’ll be getting stuck into getting particles back on screen, and exploring ExecuteAlways, which is something I’ve only used for very simple systems before now.

Seeya in the next dev-log

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team

Hey all,

Decent progress yesterday .

• Fixed cases where curves connecting nodes were laid out incorrectly during certain inputs
• Dedicated types for various internal IDs
• Added the ability to drag/drop resources from the Unity project directly into the canvas.
• Improved debugger integration
• Users can now replace connections without removing the old ones first.
• Added a way to specify default values for connectors
• Got user-defined functions to compile correctly when used in other effects.

The drag/drop one is simple but it’s nice to be able to drop a texture into the graph and get a texture node immediately. The same is true when dropping in a user-defined function asset.

The connection replacement, too, is a nice quality-of-life improvement. Previously, connectors could be turned into value slots with a right-click action. However, based on feedback, we’ve moved to showing the value slot whenever a connection is not made. It doesn’t always make sense to have a slot though, for instance, you wouldn’t want to type a texture!

Today I’m going to focus on improving resource handling. In the graph, resource-nodes are nodes where the value comes from the CPU, rather than being computed on the GPU.

Seeya you then.

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team

Heya folks,

As promised, the minimally viable dev log!

I’ve continued work on the fixes post my major refactor of the particle tooling. Today has involved

• A bug in node deletion
• Fixing deserialize as it wasn’t preserving node-inputs with fixed values (as opposed to a connection to another node)
• Improvements to the user api
• And assorted small fixes and improvements

Next up, I’m making it so removing a connection from an input automatically turns it into a value input (I’ll show a gif tomorrow).

Then hopefully I’ll probably be back to the runtime code.

Seeya tomorrow.

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team

Howdy all,

Today, I’ve been back working on our GPU particle system, which will eventually be used for our weather effects.

Our artists will need to be able to script the particles’ behavior, so we’ve gone down the very tried-and-true route of having them make these scripts via a node graph.

WIP version of the node graph. Not final

A while back I wrote a good chunk of the compiler and, although I’ve got more to add, it’s already producing decent compute shaders. Since then we’ve been working on making the user exerience for the artists nicer.

The current task I have for this is adding support for allowing the artists to make their own nodes (essentially functions), which themselves are defined as node graphs.

Hopefully, this’ll only take a few days. After that, I think I’ll be back on dice. We’ll see how it goes.

Until next time folks.

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team

A quick one today.

I put in some basic code for handling language in fuzzy name search. I’m 80% sure I’m going to have to tweak how it works when we work out the UX, so I’m not stressing about it being perfect right now.

After that, I did a little work on the Discord and got set up to work on particles again. Next up, I want to add support for user-defined functions.

Back soon with another dev-log.

Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team