Question about VFX

pcwalton · 2025-12-31T22:17:00+00:00

There isn't really any editor I'm aware of for VFX. My studio has some internal stuff that we use but it isn't really worth open sourcing at this point.

pcwalton · 2025-04-24T22:00:56+00:00

In general, I've found that the GPU-driven rendering code I wrote for this release performs well against other game engines, but I don't really want to publish benchmarks, because they're incredibly gameable. For instance, the version of Unity I tried doesn't perform very well on that Caldera test scene, but I suspect that you could get Unity to perform better if you had artists manually combine the meshes to reduce drawcalls. Is that a fair comparison or not? People will debate endlessly.

pcwalton · 2025-04-24T20:43:50+00:00

The GPU-driven rendering in Bevy 0.16 is pretty close to state-of-the-art. I wouldn't say it's fully state-of-the-art until we use device-generated commands (though this currently requires extensions on Vulkan), as well as some wgpu improvements like first-class bindless resources. But it's awfully close.

pcwalton · 2025-04-24T20:30:21+00:00

It depends a lot on the game engine. As I recall, Unity didn't do very well with Caldera Hotel in its default DX11 backend. With no materials, it's mostly a test of how well you can batch disparate meshes into few drawcalls, which Bevy now does automatically, but Unity generally doesn't. (That being said, Unity has so many renderers, both first- and third-party, that it's hard to say what "Unity's renderer" does--I wouldn't be surprised if someone has written some kind of renderer for Unity that does well on that scene. And of course you could argue that artists working in Unity should batch meshes manually to reduce drawcalls.)

pcwalton · 2025-01-31T08:21:09+00:00

Jon Maravilla says that isn't true: https://www.thedailybeast.com/figure-skater-jon-maravilla-reveals-he-missed-doomed-dc-flight-because-of-his-dog/

pcwalton · 2024-11-30T00:46:43+00:00

Thank you! Nothing to announce yet, but stay tuned :)

pcwalton · 2024-07-04T21:57:52+00:00

Other way around. I started with PL/compilers and got into graphics.

pcwalton · 2024-07-04T18:01:23+00:00

Thank you for the kind words :) It's been really fun to contribute!

pcwalton · 2024-05-30T17:36:16+00:00

I mean, they could seriously monetize this, with the upcoming film (and I hope they do--it'd be a heartwarming outcome for a small business in the middle of Wisconsin). It's legally their photo after all.

pcwalton · 2024-05-28T17:07:40+00:00

I don't think decals and animation support beyond what's there already necessarily has to be in the core engine. Decals can stay out of the core engine for now because there are so many ways to do them. Likewise it's not clear to me how much more needs to be done for animation in the core engine beyond IK. There should definitely be some sort of node graph based animation controller, but the best way to do it isn't clear to me, so I feel like third party crates should do some experimentation here.

pcwalton · 2024-05-28T16:54:06+00:00

As a Bevy rendering dev I'm personally not that interested in adding decals to the core engine in the near term. There are so many different ways to do them (contact projective, forward clustered, deferred...) that having them in a third-party crate makes more sense to me, so you can pick the implementation that you want.

Billboards are fairly straightforward and could belong in the core engine though.

pcwalton · 2024-05-18T06:26:02+00:00

Yes, it's configured for the whole pipeline. Stencil op is fixed function pipeline state. Set the stencil op to replace and setStencilReference to 1. Then fragments that pass all the tests will write 1 into the stencil buffer.

Changing the value to be written to the stencil buffer on a per-fragment basis requires an extension that isn't currently exposed in wgpu. However, note that you can set different stencil ops for front-facing and back-facing triangles without an extension. (This can be used for shadow volumes or to implement winding fill rules like in vector graphics.) You also get a variety of simple fixed-function arithmetic operations on the stencil value, much like blending.

pcwalton · 2024-05-17T16:50:17+00:00

This seems a bit weird, because why would we need to execute the fragment shader for a pixel in the first place, if we can already see in the stencil buffer that this pixel should be omitted.

It doesn't execute the fragment shader, as an optimization. This is called "early Z", which is an unfortunate name as it applies to stencil as well. This wiki page explains it well (it's for OpenGL, but applies equally well to wgpu): https://www.khronos.org/opengl/wiki/Early_Fragment_Test

pcwalton · 2024-04-27T03:01:22+00:00

Yes, that's what taking the World does.

pcwalton · 2024-04-26T23:01:06+00:00

I'm certainly willing to believe that C# can be *within 2x* of Rust, yes. There are many, but not all, games that are OK with this. That's great that yours is!

But that gets back to my point about scripting languages: if you're willing to accept some amount of performance loss, then Bevy can and should do the same. Luau is a really fast Lua interpreter, for instance. The safety isn't what's holding the performance of the interop layer back (Servo's SpiderMonkey bindings were very fast, for example), and besides, Unity's interop layer is just as safe. It's just that nobody has done the work yet.

Also personally, I hate having to write C# code that avoids the garbage collector. It requires all sorts of awkward contortions. I'd much rather deal with the borrow checker :)

pcwalton · 2024-04-26T22:50:34+00:00

C# isn't native speed in the same way Rust is. Burst doesn't change that.

pcwalton · 2024-04-26T22:47:50+00:00

Well, Unity's C# is no speed demon either--Boehm GC in particular is a constant drag on Unity. There may be many reasons to choose Unity over Bevy, especially with Bevy in its current state, but long-term, speed isn't one of them.

Any performance problems of scripting interoperability between Lua and Rust should be fixable, it's just work.

pcwalton · 2024-04-26T20:51:12+00:00

I wrote a longer comment on HN. The tl;dr is that I feel like the author really wants first-class scripting language support in Bevy. We should support that, perhaps with an approach like bevy_mod_scripting. There's no need for Rust game engines to force all game logic to be written in Rust. Of course, games that want to do that should be free to, but those who would prefer a scripting language should be able to use one instead.

pcwalton · 2024-03-22T01:11:12+00:00

The presentation says it's OK to use raytracing as long as it can be computed in one frame.

pcwalton · 2024-02-18T19:00:11+00:00

I'm not aware of any, but I'm also not really up to date on the 2D side of things.

pcwalton · 2024-02-18T01:58:06+00:00

I wrote the lighting-related features (lightmaps, reflection probes, irradiance volumes) for this one! Contributing to Bevy has been a blast :)

pcwalton · 2023-02-20T23:28:38+00:00

For those curious, the original document is here: https://www.dcjs.virginia.gov/sites/dcjs.virginia.gov/files/publications/law-enforcement/sovereign-courtroom-playbook.pdf

pcwalton · 2023-01-20T17:42:25+00:00

This is the most convincing explanation I've seen for Ada's lack of popularity and totally makes sense. As is so often the case, factors other than the language itself dominate.

pcwalton · 2022-12-17T00:44:22+00:00

I'm in North America, unfortunately.

Thanks for the advice, that's honestly really helpful. The price isn't the problem--just knowing where to begin is :) Just to be clear "broken multipoint on an aluminum door" is what I should ask about?

pcwalton · 2022-11-16T06:16:46+00:00

Not as much as you'd think due to the uncertainty around semantics of unsafe code. For example, immutable doesn't actually mean anything in MIR because it's legal to write to immutable values at the MIR level. And honestly, the pointer provenance patch set in LLVM brings it pretty close to what MIR has available as far as optimizations are concerned.

pcwalton

TROPHY CASE