(about doing water in a game) …the simplest example is foam level is stored in vertex color. Either you paint those in manually, or procedurally, it does not matter.
A lot of modern inexperienced tech artists fall into a trap of developing an amazing runtime solutions for this kind of thing (DFAO shader implementation), but they only have one thing in common; they’re slow. Them reducing production time is not implied. Improving visuals is not implied. Reducing package size is not implied. But being slow is almost guaranteed.
| occurrences (high) | (low) | |
|---|---|---|
| task complexity (high) | #1 | #2 |
| (low) | #3 | #4 |
We can generally place any technical art problem in the above schema and go from there accordingly.
Environment art or foliage or lighting is a #1. It happens a lot in games and is also fairly complex. So it required people to work on pipelines, tools, documentation.
A boss monster is a #2. It is very complex but only happens once. So what you need is a small team of specialists who make it work. No need for teams and documentation and pipelines.
Exporting and importing assets is a #3. It’s something you want to automate as soon as possible, so no more manual time is spent on it.
Anything that’s a number #4 you just ignore. People will figure it out by themselves. These are mostly in-the-minute requests for trivial stuff.
Step 1: Solve the problem by any means necessary.
Step 2: Do it again, now you can be better and more efficient.
Step 3: See if you can speed up the process by tooling, scripts, etc.
Step 4: See if you can isolate parts of the process so you don’t have to run through the entire thing.
You can stop at any of the above steps depending on the situation.