Graphics engineer, not a cat
Joined August 2009
- Tweets1.2K
- Following46
- Followers2.7K
- Likes1.3K
I agree that there's a tragedy in there, but I don't think the "prioritization" of human work is anything but a pipe dream.
You probably have 100 bucks, are you going to give it to an artist to make something? Probably not
Not because you're a bad person, but because to make a game you'd need 100 times more than that, at the very least.
On the other hand, you could spend 100 bucks on AI and get a game prototype. The choice of "prioritizing" human artists for you would boil down to not making a game.
Again, I don't mean to pick on your specifically.
Take a studio with 500k in funding, they can pay an artist to draw 1000 icons for their game by hand, each icon will take about 10 hours, at say 20$ per hour, that's 200 bucks per icon and a cool 200k for all icons.
That's 40% of your budget gone on what should have been a small fraction of your game.
And that's before you start thinking about things like communication, admin and legal. And you assume that the artist is actually good.
Frame generation is technology of generating "fake" images that were never rendered by the graphics engine to create a smoother frame rate for the user.
The approach that has worked so far is holding an extra frame instead of presenting it to the user immediately and interpolating between that held frame and the previous one
@nvidia has it as "DLSS Frame Generation" / "DLSS Multi-Frame Generation"
@AMD has it as "FSR Frame Generation" / "Fluid Motion Frames"
@intel has it as "XeSS Frame Generation"
@Apple has it as "MetalFX Frame Interpolation"
etc.
Apperently @Sony is working on Frame Generation with extrapolation.
Problem is - extrapolation doesn't work.
The reason it doesn't work is because velocities of pixels are not continuous, worse yet, the acceleration is not continuous and not even linear.
This has been tried many times, but math is not on your side. You have 3 situations for a pixel:
1. velocity is constant - everything works
2. velocity is very high then low - moving things way too far. Think fighting games where punch has ridiculous acceleration. Pixel appears half-way across the screen, falsely
3. velocity is very low then high - you barely move a thing, and it snaps the following frame creating a visible pop
The problem is that you're landing on 2 failure modes most of the time in real scenarios.
Well, you could say "Since we know about these potential failures, we can fix it, no?"
- No.
To fix these issues you need to know what the future holds, and that would be interpolation.
The best you can do is to clamp high impulse frame (velocity high -> velocity low), but this will not fix the issue, it will only mitigate it.
And that mitigation will introduce errors into the case where the prediction was correct.
Big thanks to @mrdoob for teaching me how to use twitter (formerly known as twitter)
Fluid simulation on WebGPU
live version: meep.company-named.com/examp…
The fluid sim is cascaded with a global fallback running on the GPU with dynamic obstacles. There are 4 obstacles here including the "ground" box.
The particles are GPU driven, they just sample the fluid volume
Real-time cloth simulation - WebGPU
live link: meep.company-named.com/examp…
Fire in WebGPU
live link: meep.company-named.com/examp…
* Fluid simulation
* Volumetric lighting (particles receive all light contribution)
* Order Independent Transparency
* GPU-driven particle simulation
Tree generator - WebGPU
* reworked skinning to be more physically accurate
* added stubs and knots
* added roots
* minor improvements to branch and leaf placement - better adherence to tree biomechanics
And yes, the tree is rigged and skinned and the animation is 100% procedural from the real-time fluid sim
When you play a game, at some point you stop being aware of the controller in your hands, or the mouse and the keyboard.
The screen's pixels and subtle reflections stop existing. You are the character, and your brain is controlling that character directly.
There are many terms for this phenomenon:
* Kinesthetic Projection
* Action-Awareness Merging
* Body Schema Extension
To me AI is like that too. If I want to make a piece of software or a game, the tools are in the way, and when I'm at my most productive, they disappear from my conscience, they become a part of the "me", as weird as it is to say.
It's never been about the tools, it was always about the goal. Sometimes the journey to the goal is meaningful too, but most of it is just you dealing with a your tool's limitations.
Given a choice, would you use a worse PC to develop? A tiny display? A worse editor, with no language support?
- I wouldn't, and I don't.
AI in video games are a confusing topic to me.
@TimSweeneyEpic recently got a lot of flak for pushing AI in game development.
There are opinion pieces left and right condemning AI use in game development.
Here I am, having worked for ~6 months on a game I released on Steam last week. And my sin, apparently, was using AI and disclosing it.
The comment section was pretty clear on that.
It's confusing to me. AI is a tool. IDE is a tool. A programming language is a tool. A graphics API is a tool. We're just using tools.
I've been writing software for about 3 decades now, I'd like to think that I know what I'm doing and am pretty good at it. I see AI as an incredible productivity booster.
It does some things that I pride myself on being good at, such as teasing out a math formula or optimizing an algorithm better than me most of the time (with a lot of handholding, granted), but for the most part it makes things I find tedious - fast.
As I software engineer, and a game maker, I take relatively little pride in knowing a programming language, or remembering 100 shortcuts in an IDE, or knowing a programming language spec by heart.
I remember the first time I needed to make an animated 3d model, almost 15 years ago now, and it took me about a week of full-time effort to get anywhere. I didn't feel particularly proud, I felt frustrated, I had a clear idea, but the tool and its complexity were getting in the way. Well, the tools are better now. Blender is better, animation tools are better, and there are AI models that keep improving at an incredible pace.
Ultimately, when I write a piece of software, or work on a game - I rarely think about the tools, they are a means to an end, not the point in itself.
did more work on the tree generator for WebGPU
* more biomechanically accurate branching, fewer very long thin branches
* branch growth takes gravity and material into account now
* branches use full collision resolution, previously it was statistically improbable, now it's impossible
* Added senescence parameter to leaves, so we can cover different phases of growth, especially useful for autumn and for young leaves (spring)
* leaf cards are now generated with variants, so leaves don't all look the same
* placement optimization, much fewer cards and branches required for the same overall coverage/volume, ~50% fewer triangles overall
I don't think realism is something I will chase relentlessly on this, as this is intended for real-time applications, to generate foliage for games and interactive experience, not so much for botanical simulations. But having a principled generator costs nothing at runtime, so I'm going as far as it makes sense to.
Right now a tree takes anywhere from 50ms to about 1s to generate, depending on the size and other configuration parameters, which is entirely reasonable for my goals.
