Anyone have experience doing VFX for open-world sandbox games? I’d imagine the pipeline would have to be accommodating to massive amounts of reuse and re-purposing, to allow for the deluge of content. Or maybe you just hire an army of VFX artists?
I was curious, because the makers of Ark: Survival Evolved just listed some featured job posts over on the board:
VFX Artist, Kirkland, WA
Senior VFX Artist, Kirkland, WA
Hey - speaking from my experience doing open-world games at Avalanche Studios and without getting too specific, I can definitely say that an army of VFX artists is not how we approach this task haha!
Like you said, VFX (and everything else in an open-world game) needs to be modularized. Any kind of set dressing work is difficult to do, since we rely almost exclusively on systematic solutions. Since there’s no concept of a “level”, budgeting performance is tricky and always something to be mindful of. Making sure that your effects hold up regardless of view angle/weather/time of day/enviroment is also a big one.
If anyone is curious about anything in regards to working on open-world games, I’d be happy to answer!
yeah lots of reuse and modularity.
Lots of building things systematically too - i used to do a quick line trace to the environment and spawn things like leaves in forest etc. dynamically, rather than placing things manually.
Also its a great idea to bake some extra lighting and rain parameters into the materials of your effects - anything that can give you a bit of extra control to make things bed into the world nicely.
I wonder how you make useful naming-conventions for the files. Since a generic dust-effect could be used for footsteps, dust behind a car-wheel or is impact-dust from a falling object you could just name it “dust_01” and re-use it everywhere (while modifiying size, partice-count etc per object) but then you may end up with dust_01 to dust_99 and no one has an idea how the effect looks like by just looking at the filename.
on the other side, naming it like “carWheel_break_dust_01” is so descriptive, that it might feel weird using it for an impact effect which has nothing to do with a car wheel 
do you understand what i mean? usually a filename shall be descriptive, but since you have to re-use everything everywhere, you can be too descriptive…or am i wrong?
“Naming Conventions…” rarely do two words bring such anxiety to my psyche so readily. lol.
What’s hard for me is accurately describing the shape of a thing. I’ve actually used the words “frito, chunk, and shard,” in an effort to bucket meshes into categories. Then when you consider the shape profile of a holistic particle system, generic descriptions become even more useless, especially if you make them color-agnostic, with LUTs tinting them (for instance, greyscale flames could also re-tinted to be dark magic, golden energy, or any number of things).
I think naming it “carWheel_break_dust_01” actually isn’t a bad idea, because at least you know where it originated and is working in-game, and over time the origin names become a part of the tribal knowledge within the team, so you can readily find stuff.
Stop generic naming! It’s a plague that needs to end. Dust_01 has no place in any project. What if you need to replace the texture and adjust some brightness values in it? Will you check the 4678 places it’s used in the opening area!? No! Replace the texture in FX_Env_Dust_Falling_AmbientIndoor and check both instances where it’s used.
I may or may not have written a naming convention document for everything fx related on my current project just a couple of weeks ago. Not saying I’m still obsessed but…
I don’t understand: Do you mean that re-using one texture in many many many areas is a bad thing (because when you change it you might have to check every of the 1000 effects where it was used if they still look good) or are you saying that the generic NAMING is a problem but not the re-use of assets?
Have you worked on a PBR lit game with indoor and outdoor uses of effects?
Reuse as much as you can, but make sure it’s the same usage. Indoor effects should only be used indoor. Backdrop effects should only be used in the backdrop. If I change dust_01 and colorboost it so it’s more visible in the desert during the day, I will create suipernovas in the caves at night. (Yes I am aware of workarounds, but poor naming is a major cause of the problems)
OK but let’s say you have 20 dust textures optimised for the use in the desert. Then your way would be to name them for their first usage like e.g. dust_01_impact_carWheel.tga, dust_02_chimney.tga, … even if later a totally different effect (e.g. some smoke from a pot over a fire) might use “dust_01_impact_carWheel.tga” too, which makes no sense from the naming but as long as the visuals are fine, that’s ok?
I’m not talking about textures. They should have descriptive names. I’m talking about particle effects/emitters.
This is a lot of text, so strap in! 
Star Citizen is very much an open world (open space?) sandbox game, so I am familiar with the conversation topics occurring in this thread. All of the below things push us towards a specific goal: consistency.
We use a “sanity checklist”, which in theory every “generic” effect (yes, we do use that word for effects that can occur anywhere in Star Citizen and Squadron 42) needs to be checked against when authoring:
Gravity - has the effect been tested both with and without gravity? (for example how does a ship explosion look when occurring in space versus on a planet with strong gravity).
Wind - similar to above.
Lighting - how does the effect hold up under all the possible time-of-day/lighting/exposure conditions? (our game is PBR and we have a pretty solid particle lighting setup, at least for our cpu particles).
Distance - does the effect look high quality when viewed up close (i.e. explosion occurring right in front of the player) as well as really far away (i.e. explosion way off in the distance) and is the effect suitably optimized to account for both extremes and everything in between?
These are just the most obvious examples. It’s a real challenge but we have a robust particle system that allows us to dynamically alter our affects using strength, life and distance curves (and we’re considering other curves to expand our arsenal).
re: naming conventions. This one is tricky (understatement, right?). Using our environmental effects as an example, we’ve settled on the following: we have a folder with an extensive library of “generic” effects, and “bespoke” folder which houses anything that is created purely for one purpose/location.
Our particle library file structured is like so:
Particles Root/Folder(s) > Particle Libraries > Particle Effects.
The effects library itself is essentially an xml file, however when viewed in the particle editor, it is structured hierarchically which makes everything easier to read.
So I could have a Particles/Environments/Generic folder. Inside that folder could be a particle library called “generic_steam”, and inside that library could be parent groups called "steam_linger" and “steam_jet”.
For the naming of the generic effects, we use the following convention:
effecttype_subtype_dimensions_loopingOrOnce_variantNumber
If that looks convoluted, in practice it isn’t:
steam_jet_4x8m_loop_1
steam_jet_4x8m_once_1
steam_linger_4m3_loop_1
etc.
Something important to bear in mind, once any of the above effects are placed in an environment, various attributes - including scale - can be overridden per instance. This could make a mockery of the “dimensions” part of the name, so we have guidelines on how much an instance can be overridden before the effect is not deemed appropriate for that particular usage. Restraint and common sense is required here, because it would be very easy to bloat the library with multiple variants of the same effect.
None of this is perfect - and as our game grows, we’re always looking at ways we can improve the process/setup - but it works for us at this stage in our project(s) and I wanted to share our experiences with you guys/gals
Thanks for taking the time writing all this down! Really interesting!
I wonder how you manage to name your textures since those can be heavily shared between effects.
Yup, naming conventions and modularity is where it’s at, at least until procedural fx entities become a thing (in 10 years maybe?)
There’s also other workflow pipelines if using PBR type assets that help this along when it comes to grading various parts of a material but really only useful for huge AAA games- I feel it’s a little more trouble than it’s worth if for a small/medium sized game.
love me my modularization; slow in the short term, but infinite long-term gains 
We’ve had heavy discussions as to naming conventions as well.
The whole generic / bespoke classification is very difficult because something that was originally created with a very specific case in mind can sometime be reused all over the place.
We are yet to find the perfect solution (probably because it doesn’t exist), but I guess that tags can also be a good helper (if your engine supports a tagging system…). You can’t put everything in the name, when you start adding _brighter_softer_2sided_larger_you-name-it… it gets too much.
From my past experience it often end up being “tribal knowledge” as @Keyserito said. I’ve seen it work with the __01 02 structure @Partikel loathes, and with the carWheel_break_dust_01 sort of structure. You just end up knowing them all in the end.
Still I wished we could nail the perfect naming convention, I’d love for everything to be perfectly sorted.
@Partikel In a year’s time or so, I’d love for you to reflect on the naming convention you’ve written. Everyone starts with the best intentions and then one day chaos happens. Very interested to see if yours manages to hold up.
Sure I can. I mean it’s based on previous conventions I’ve shipped games with.
As most of the topic was about filenames, I wonder if you guys want to go more into detail how the modularity is done on the logic side.
Let’s assume you have shallow water and in theory all kinds of things can penetrate the surface: cars drive through, big stones fall into it and feet can either do steps or maybe the character slides a bit after running on the ground of the shallow lake.
Do you consider all of this the same base-effect “something penetrates water” and then you try to build a generic system which only has a few inputs like: pentrate position, speed, duration and area?
Or do you generate different base effects (1x somethings drives in water, 1x foostep in water, 1x slide in water, …" and the generic system only scales these effect up/down depending on the size of the wheel/foot/stone/…
And how do you build the logic? At some point the script/code must check for example if below the foot is earth, water, dust, sand, etc pp. The same check must be done for “what’s below the wheel” and for “what’s the impact-surface a stone/debris falls onto”.
Do you build a little generic system which you can apply to any kind of asset which just does this separation and spawns object-based effects accordingly? Or would every object have a unique script and this surface-check-logic would be copied to each of the scripts?
p.s. Why is this in the jobs section?
