# Future 3D API...

**URL:** <https://discourse.libsdl.org/t/future-3d-api/33485>\
**Category:** SDL Development\
**Created:** [November 13, 2021, 5:19pm UTC](https://discourse.libsdl.org/t/future-3d-api/33485 "2021-11-13T17:19:35Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![Mason\_Wheeler](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/m/b9bd4f/32.png) [@Mason\_Wheeler](https://discourse.libsdl.org/u/Mason_Wheeler)\
**Post date:** [November 16, 2021, 11:36pm UTC](https://discourse.libsdl.org/t/future-3d-api/33485/21 "2021-11-16T23:36:45Z")

</div>

> [@icculus](#):
>
> This isn’t true, at least in terms of rendering.

OK, so I won’t go into object loaders or how you didn’t even mention FBX and Blender format, probably the two most relevant object file formats in all of gamedev. Let’s just talk about rendering.

You mentioned custom shaders. If you want to render 3D geometry with shaders, people are going to want a way to use the same basic shader for multiple models, but with different parameters. So you need a concept of Materials.

Once people start rendering scenes composed of more than one 3D model, lighting becomes crucial. So now you need an API for Lights. Then you need ways to determine how to deal with multiple Lights shining on the same texel. So you need a Forward or a Deferred rendering algorithm, or preferably both and an API to choose between them.

Once people start lighting scenes, they’re going to discover that rendering even halfway decent lighting is very computationally expensive, and the bulk of that computation is redundant because it doesn’t change from frame to frame. So you need a concept of baking and applying lighting maps.

Once people have scenes, they’re going to want to not just place things in the scene but also move them around. They don’t want solid objects clipping through each other, so you need a concept of a 3D collision geometry simulator. (Even without a full physics engine, which I agree is beyond the scope of SDL, you _will_ need a collision system.)

Once people start moving things around, they’re going to want them to move in a lifelike manner. So you need a concept of Animations, and a way to transition smoothly between Animations.

Once people move objects around, they’ll want to connect objects so they will move together, such as a person picking up a weapon and holding it in their hand so that it will move together with the hand in a visually correct way. So you need a hierarchical Scene Graph API.

And so on. If you do not have APIs for these basic things, no one will want to use SDL for even simple 3D rendering when engines such as Unity and Unreal provide them all, for free, out of the box. As I said above, this is table stakes for 3D. Like giving a mouse a cookie or boiling up a pot of stone soup, once you take the first step there are tons of other things that will inevitably be pulled into even the Minimum Viable Product, and any product that doesn’t end up containing them _will not be viable._

---

<div class="post-metadata">

**Author:** ![icculus](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/icculus/32/81_2.png) [@icculus](https://discourse.libsdl.org/u/icculus)\
**Post date:** [November 17, 2021, 1:27am UTC](https://discourse.libsdl.org/t/future-3d-api/33485/22 "2021-11-17T01:27:37Z")

</div>

You’re describing a game engine, not a rendering API.

---

<div class="post-metadata">

**Author:** ![arkedrem](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/arkedrem/32/4371_2.png) [@arkedrem](https://discourse.libsdl.org/u/arkedrem)\
**Post date:** [November 17, 2021, 12:36pm UTC](https://discourse.libsdl.org/t/future-3d-api/33485/23 "2021-11-17T12:36:25Z")

</div>

> [@AntTheAlchemist](#):
>
> I vote in favour of keeping the bloat down. This ethos is what makes SDL so great and sets it apart from other libraries / engines.

Hello, I’m a newbie testing out SDL2.

May I request for a Youtube video of the future of SDL2?

It’s easier to watch a video of what you’re planning to do.

---

<div class="post-metadata">

**Author:** ![Mason\_Wheeler](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/m/b9bd4f/32.png) [@Mason\_Wheeler](https://discourse.libsdl.org/u/Mason_Wheeler)\
**Post date:** [November 17, 2021, 3:53pm UTC](https://discourse.libsdl.org/t/future-3d-api/33485/24 "2021-11-17T15:53:04Z")

</div>

Well yeah. The biggest use case for SDL, _by far,_ is to build games. If people want to build a 3D game, and they see a “rendering engine” that doesn’t have these features, what are they more likely to do?

1. Build out all those features themselves.
2. Pass it by and use a different framework that does provide them.

People may claim they don’t like “bloat,” but they always want more features. “Bloat” just means “features I personally don’t need,” but the table stakes stuff is features everyone will need.

The simple fact of the matter is, in the world of programming, Zawinski’s Law reigns supreme: software which can’t provide the features people want is replaced with software that can.

---

<div class="post-metadata">

**Author:** ![icculus](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/icculus/32/81_2.png) [@icculus](https://discourse.libsdl.org/u/icculus)\
**Post date:** [November 17, 2021, 3:56pm UTC](https://discourse.libsdl.org/t/future-3d-api/33485/25 "2021-11-17T15:56:26Z")

</div>

This is either a bad-faith argument or a wild misunderstanding of SDL’s role in the software stack, and I’m not interested in having either conversation with you in this thread.

---

<div class="post-metadata">

**Author:** ![Edward\_Rudd](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/edward_rudd/32/180_2.png) [@Edward\_Rudd](https://discourse.libsdl.org/u/Edward_Rudd)\
**Post date:** [November 17, 2021, 8:01pm UTC](https://discourse.libsdl.org/t/future-3d-api/33485/26 "2021-11-17T20:01:13Z")

</div>

@icculus you should look at what dawn and webgpu-rs are doing  
( [dawn - Git at Google](https://dawn.googlesource.com/dawn) ) ( [GitHub - gfx-rs/wgpu: Safe and portable GPU abstraction in Rust, implementing WebGPU API.](https://github.com/gfx-rs/wgpu) )

Basically they are providing a “webGPU” interface and having backend (native and web) behind the scenes. Thus in the end you only have to target one “render API” and it’ll use DX12, meta, vulkan, GL, webGPU,etc… on the backend. But yes, as the standard is no where near finalized, not quite as useful. But something to watch.

---

<div class="post-metadata">

**Author:** ![rtrussell](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/rtrussell/32/4768_2.png) [@rtrussell](https://discourse.libsdl.org/u/rtrussell)\
**Post date:** [November 17, 2021, 11:11pm UTC](https://discourse.libsdl.org/t/future-3d-api/33485/27 "2021-11-17T23:11:46Z")

</div>

> [@Mason\_Wheeler](#):
>
> the table stakes stuff is features everyone will need

Not me! I’d like to see some 3D capabilities added to SDL; currently I use direct calls to OpenGL for this, which works but it would be easier and potentially more portable to do it all through the SDL API. Ryan’s current proposals are pretty much exactly what I want.

---

<div class="post-metadata">

**Author:** ![brada](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/b/9dc877/32.png) [@brada](https://discourse.libsdl.org/u/brada)\
**Post date:** [November 17, 2021, 11:58pm UTC](https://discourse.libsdl.org/t/future-3d-api/33485/28 "2021-11-17T23:58:12Z")

</div>

Same, the addition of shaders alone opens so many doors for 2D games. I’ll finally be able to do palette swapping on the cheap! Doing things like greyscale or dithering become trivial too.

Even if we needed/wanted those other things. gotta start somewhere and this is it.

---

<div class="post-metadata">

**Author:** ![paulr](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/p/c4cdca/32.png) [@paulr](https://discourse.libsdl.org/u/paulr)\
**Post date:** [November 22, 2021, 9:03pm UTC](https://discourse.libsdl.org/t/future-3d-api/33485/29 "2021-11-22T21:03:21Z")

</div>

Agree this is pretty an exciting development in SDL.

I suppose my question is would you expect this to be available in 2022 or are we talking further out? It feels like quite an undertaking particularly distilling it down to the minimum.

---

<div class="post-metadata">

**Author:** ![pandrafan](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/p/a88e57/32.png) [@pandrafan](https://discourse.libsdl.org/u/pandrafan)\
**Post date:** [November 24, 2021, 9:55pm UTC](https://discourse.libsdl.org/t/future-3d-api/33485/30 "2021-11-24T21:55:20Z")

</div>

That’s great news, but also a big undertaking.

Meanwhile, I am glad that the 2D API remains and wondering if it is still subject to receive few minor feature updates. I am interested in **“signed” Texture blending** support in particular. I am asking because it is vastly underestimated which real-time visual effects can be achieved just by a smart use of blending. And I like to push those limits while the code remains cross-platform.

For example, signed-valued textures would enable me to implement **normal-map lighting** much more efficiently (since I don’t have to separate negative and positive vector-components in seprate textures to handle them differently).

Would be nice to hear an answer on that. Thanks! 🙂

---

<div class="post-metadata">

**Author:** ![icculus](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/icculus/32/81_2.png) [@icculus](https://discourse.libsdl.org/u/icculus)\
**Post date:** [November 25, 2021, 5:47pm UTC](https://discourse.libsdl.org/t/future-3d-api/33485/31 "2021-11-25T17:47:24Z")

</div>

> [@paulr](#):
>
> I suppose my question is would you expect this to be available in 2022 or are we talking further out? It feels like quite an undertaking particularly distilling it down to the minimum.

My expectation is this will be a few months of serious work to get to something presentable, so _sometime_ in 2022?

The megagrant paperwork is still being processed, so beyond sketching out basic API design, this hasn’t started yet…but hopefully soon!

---

<div class="post-metadata">

**Author:** ![icculus](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/icculus/32/81_2.png) [@icculus](https://discourse.libsdl.org/u/icculus)\
**Post date:** [November 25, 2021, 5:51pm UTC](https://discourse.libsdl.org/t/future-3d-api/33485/32 "2021-11-25T17:51:48Z")

</div>

> [@pandrafan](#):
>
> I am interested in **“signed” Texture blending** support in particular.

I haven’t thought about this at all, and what it would take to add it to various backends, so I can’t say about this feature specifically at the moment.

But while the 2D API won’t go away, I don’t expect to add more major features to it. But simple additions are 100% still possible!

---

<div class="post-metadata">

**Author:** ![pandrafan](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/p/a88e57/32.png) [@pandrafan](https://discourse.libsdl.org/u/pandrafan)\
**Post date:** [November 25, 2021, 6:36pm UTC](https://discourse.libsdl.org/t/future-3d-api/33485/33 "2021-11-25T18:36:52Z")

</div>

Thanks for considering! Just the small addition of signed texture blending would empower the possibilities of the 2D renderer dramatically. It would be possible to make a 2D game look advanced/modern without the use of shaders (since many neat effects can be simulated with blending and some precomputed stuff), and all that running on an integrated gpu.

Btw. signed texture blending just for SDL\_BLENDMODE\_MOD and SDL\_BLENDMODE\_ADD would totally suffice.

---

<div class="post-metadata">

**Author:** ![pandrafan](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/p/a88e57/32.png) [@pandrafan](https://discourse.libsdl.org/u/pandrafan)\
**Post date:** [November 25, 2021, 10:45pm UTC](https://discourse.libsdl.org/t/future-3d-api/33485/34 "2021-11-25T22:45:33Z")

</div>

Just one last thing while I’m at it. There is one thing possibly even more valuable than signed texture blending. That is “swizzled” texture blending. Just like with SDL\_SetTextureColorMod() we could have “SDL\_SetTextureSwizzleMod()” where you can swap the channel order before blending (like rgb,brg,gbr). That would make it possible to compute the sum (r + g + b) of a texel without cumbersome workarounds (simply blend the texture three times with different swizzle modes). And we are a good step closer to general purpose computation with blending. Want to multiply a texture by a 3x3 matrix? No problem. Want to do normal-map lighting? No problem.😉

The current workaround for all that is to actually store a texture in 3 “formats” (rgb,brg,gbr) and do the same computations on them 3 times (instead of just one). And then adding the three results together.

Now I don’t know if you are already using shaders behind the scenes to do some of the blending. In that case adding swizzled texture blending should be straight forward. Otherwise, if the blending stage is done by the API on all ends, then I can see how it could complicate things as you would need to fire up a shader just to do that swizzling thing.

---

<div class="post-metadata">

**Author:** ![DEV](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/d/e8c25b/32.png) [@DEV](https://discourse.libsdl.org/u/DEV)\
**Post date:** [November 26, 2021, 6:58am UTC](https://discourse.libsdl.org/t/future-3d-api/33485/35 "2021-11-26T06:58:31Z")

</div>

There will be more graphical functions similar to SFML (VAO, VBO, drawing primitives, camera…) or still all the backend will be up to the user?

---

<div class="post-metadata">

**Author:** ![fizz](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/f/b77776/32.png) [@fizz](https://discourse.libsdl.org/u/fizz)\
**Post date:** [December 11, 2021, 8:43pm UTC](https://discourse.libsdl.org/t/future-3d-api/33485/36 "2021-12-11T20:43:32Z")

</div>

Please please please fight to keep it simple. There will be tools that are more efficient, prettier, more accepted, but nothing will be simpler than SDL if this is done right. icculus once said that SDL is a hyped up super nintendo, which actually how I’ve explained it to people before because everything is so rectangular. I love what it is and I don’t want to see it go.

I’m actually building a 3d game with SDL now hehe. I would like to see what happens with this 3d API stuff.

---

<div class="post-metadata">

**Author:** ![VitusVeit](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/vitusveit/32/4823_2.png) [@VitusVeit](https://discourse.libsdl.org/u/VitusVeit)\
**Post date:** [October 2, 2022, 6:51pm UTC](https://discourse.libsdl.org/t/future-3d-api/33485/37 "2022-10-02T18:51:41Z")

</div>

I’m excited about this new API, just having multi-platform support for shaders is an incredible thing! I’d like to know if you already have an idea of a possible release, maybe at the start/middle of 2023? I noticed that there is still work in the shaders tool and I know that [these things take time](https://youtu.be/0d6yBHDvKUw?t=6) so maybe not that soon? Anyway, thanks so much for your work!

---

<div class="post-metadata">

**Author:** ![ROSY](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/r/8797f3/32.png) [@ROSY](https://discourse.libsdl.org/u/ROSY)\
**Post date:** [October 3, 2022, 6:44pm UTC](https://discourse.libsdl.org/t/future-3d-api/33485/38 "2022-10-03T18:44:29Z")

</div>

I would prefer some code example showing how the new functions would work …

---

<div class="post-metadata">

**Author:** ![icculus](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/icculus/32/81_2.png) [@icculus](https://discourse.libsdl.org/u/icculus)\
**Post date:** [October 12, 2022, 2:41am UTC](https://discourse.libsdl.org/t/future-3d-api/33485/39 "2022-10-12T02:41:22Z")

</div>

I put together a really quick FAQ and link dump document over here, which has a code example or two mentioned:

> <https://github.com/icculus/SDL_shader_tools/blob/main/docs/README-SDL_gpu.md>

---

<div class="post-metadata">

**Author:** ![icculus](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/icculus/32/81_2.png) [@icculus](https://discourse.libsdl.org/u/icculus)\
**Post date:** [October 12, 2022, 3:09am UTC](https://discourse.libsdl.org/t/future-3d-api/33485/40 "2022-10-12T03:09:44Z")

</div>

I’m currently building out the Intermediate Representation portion of the shader compiler (which, since this is more or less flattens down into the bytecode format, can be the last stage of the compiler for now), and then I have to implement shader loading into the GPU API, which is me downplaying a lot of work still to be done, but we’re still getting surprisingly close to a first-cut proof-of-concept.

Once that’s done, the next big step is implementing the other backends (currently I’ve only implemented Metal for the proof of concept), filling in gaps we know we skipped over, like missing texture formats, etc, and adding a basic optimization pass to the compiler (nothing super-serious, but there are some basic-but-very-good optimizations that can be implemented very easily without writing LLVM from scratch, like constant folding and deadcode elimination, so it’s silly not to implement them).

Right now this is getting implemented in my spare time, which isn’t a lot of time right now, and as compiler development goes, some days I look at the next thing I need to write and take a nap instead, you know how it goes. 🙂

But I _am_ making forward progress, and the finish line for _something_ usable is coming up. It might be before 2023!

[Previous page](https://discourse.libsdl.org/t/future-3d-api/33485.md?page=1)

[Next page](https://discourse.libsdl.org/t/future-3d-api/33485.md?page=3)