Creating / Editing particle systems and emitters in text files poll

Hey all!

I have a little question and it would be awesome if you could give me a quick answear! Thanks in advance! :slight_smile:
It would be very interesting to hear about how much text editors are still used for editing / creating effects.
The reason why I want to know is because I need to know what knowledge is relevant out there.

How often do you use a text editor to edit / create your particle system / emitter effects?

  • Very often
  • Sometimes
  • Rarely
  • Never
  • What?

0 voters

1 Like


Notepad++ with RegExp helps a lot to patch effects for PKFX-SDK, of course you need to have same code style to gain expected results.

1 Like

There’s a bunch of results in there and that’s great! Thanks so far for voting.
Believe it or not, I find this very interesting. I had no idea this many were still using text editors.

The downside is that this kind of ruins my argument that text editors are not being used anymore. :smiley:

Hey man,
If you’re trapped in 1992 editing particle systems, I totally feel your pain.

Here’s what I used to articulate a nested vfx system wherein systems further down in the directory structure would overwrite previously loaded definitions. You can use this to open multiple files at once and edit them all. It’s the ultimate search and replace tool that isn’t a programming environment.

This is what I used to find anything I was looking for…

Hey William!

Thank you for the links!

Thankfully I am not working in a text editor at the moment but I wanted to gather information about how much it was still used in the industry because we might be developing particle support for our inhouse engine. And I just wanted to make sure that there was going to be NO editing of text files. But I can see now that I will have a harder time to argue that it’s part of the 1990 and not 2000.
I am still going to push for a text file free environment but I know it will be a bit tough. :stuck_out_tongue:

So if I end up with text files again I will for sure have a look at those links!


From my experience it’s better to have text based rare files (YAML is human-friendly) and then built-in Patch scripts inside in-house engine. Those could have VFX scenarios like: changing UVs / textures, tweaking curves, make some filtering results, multiply some values, etc.

You should tell them the reason the entire industry moved towards artist friendly tools is that iteration is the key factor in determining quality. If they want to waste your time searching through text files instead of editing art, that’s fine. But the cost benefit of user friendly tools is well proven at this point. It’s not that great art can’t be made with crude tools. It’s that great art can be made faster with great tools.

Every time you have to switch contexts for creating art, it’s a disruption in your thought process. The greater the delay in feedback for a change, the less relevant and powerful any change is. There is such a thing as fatigue. If you get tired using a tool or feature, you’re less likely to rely on it.


You can always tell them that the cost of developing of fully fledged particle system is tremendously high. This is how much your programmer earns multiplied by amount of days he is going to spent on developing it and then amount of time you will need to spend on feedbacking, QA etc. Why not just buy PopcornFX? It can be integrated into almost any custom engine. You do it once and you get all the updates, bug fixes etc in a price of one product (around 200 bucks?).

1 Like

Good input guys. Really appreciate it!

Popcorn was a really good tip! I will actually see if I can talk to them about it.

We used an XML based particle system for Planetary Annihilation. Early on I pushed to try Popcorn FX, and later to move to YAML instead of XML but never got traction on either. I ended up find out near the end of the project the internal XML parser was a YAML parser from the beginning, but no one had noticed and there was enough random bits of code that assumed XML that it was non-trivial to change at that point.

I just wrote everything manually using Sublime Text or Visual Studio. I never found an XML editor that I liked. :confused:

These days I spend a lot of time writing shaders and doing custom bits of C# for modifying / appending Unity Shuriken. That kind of counts?

1 Like

I thought TA was unreal.

I’m not sure how to read that statement. Was that intended as:

  1. “I thought Total Annihilation was amazing.”
  2. “I thought Total Annihilation used the Unreal Engine.”
  3. Either of the above but with Total Annihilation replaced with Planetary Annihilation?
1 Like

I meant Planetary Annihilation…derp.

Planetary Annihilation was a fully custom engine written for the game. Some parts of the engine started with an engine written for Moon Breakers, a the first and last game made by Imba Entertainment which Uber Entertainment helped incubate and published.

Until basically after the game was released and we started adding mod tools, the game had no tools apart from one very simple tool for setting up shader definitions (which I didn’t use because it was slower and more error prone than straight text editing). Everything was done in text files, mostly giant hand edited XML files.

I wrote a particle editor, or more accurately a particle previewer, early on in the development so I could easily view effects playing (forced looping with a grid, size reference spheres, and optionally moving in some basic patterns like circle or figure eight) but it got broken really early on by major engine changes and I couldn’t figure out how to rewrite it to get it to work, and eventually someone on the programming team deleted it. I didn’t even have hot reloading for large parts of the project. Tweak fx and shaders, compile entire engine and game and run (or fix the compilation errors). Then hope it didn’t crash.

So much pain. Eventually got hot reloading (mostly) working and tested stuff by loading a tiny, empty moon test world and using the “ping” tool to spawn effects.


Oh wow. That really does not sound like fun… Especially where you did not get support for the work you put into your own previewer. A shame no one saw the benefits of having it. I really feel for you!

I never had to go through what you did while I was working with text files though, thankfully. At least I had a tool to start off with and a bit of programmer support. I just ended up editing the FX in text because it was faster and the only way to combine emitters into whole systems. We had the fun limitation of 256 characters / emitter string so if we enabled all the functionalities of an emitter some would be left out and set to default because the string couldn’t keep them all. :smiley:
After a while we did get hot reloading to work though and from there on it was so much less of a pain to preview the fx.
Oh, and this was between 2009-2012. So I’d say a shitload has happened since! But I really don’t want people to have to go through text files again. It is such a waste of time and prone for human errors (leaving a space, comma etc in the wrong place)

Funny thing is I sometimes used a text editor to work on Unreal Engine FX too. Not most of the time, but a text editor is easier for certain operations. Cascade got a ton better from when I first started using it, even just during the UE3 days, but editing and copying parts of arrays inside of those modules was a pain.


inFAMOUS Second Son + Ghost of Tsushima use what I refer to as a glorified text editor. Iteration time is a weird thing to measure in these types of comparisons because text gives you a quick read on many values at once and the ability to make really quick number entries to multiple parameters. Node based systems are much faster for many artists who are unfamiliar with the text editing environment but the downside is that often the data for your effect as a whole is buried in different nodes and sub-menus which can offset the iteration time gains. If I was writing an editor from scratch I’d have a composite between nodes and a text window that can show me (data from nodes/parameters/expressions) simultaneously.


@mattv so much this.
Honestly, there need to be better visualizations in node editors…basically a “print” node.