Good Morning,
I'd like to know if there are any improvements planned for WPF3D to make it more similar to a modern 3D engine.
Thanks in advance
@lindexi I think he's talking about the Visual3D class subtree, D3DImage is only useful for integrating external 3D engines, not for the builtin one.
@darcome I don't think anything is planned
Yes, I am referring about the internal one. @weltkante thank you for your answer!
Hi - we'll consider specific requests and proposals, perhaps you can expand on your ask? Thanks
Hi, I was thinking about the following, per example:
1) Make the engine use the latest version of DirectX instead of DX9.
2) Handle transparency automatically instead of having a user think what's the correct order to load objects in order for them to be transparent.
3) Give the possibility to write Vertex, Pixel and Geometry shaders.
These are just examples (I am not a 3D engine developer therefore I couldn't help).
Another possibility would be the following, even if probably is not feasable...
Would it be possible to sort of "port" BabylonJS to WPF so that the 3D Engine would be something modern as BabylonJS, but the simplicity to describe a 3D scene with XAML would remain? I know the BabylonJS team is a microsoft team, therefore maybe it would be possible to have the WPF3D team and the BabylonJS team cooperate?
I don't know... just my 2 cents...
@darcome the engine already has been updated to use a newer version of DirectX, there was a blog post at one point about that, but I don't have a link ready and don't remember the exact Desktop Framework version with which the update happened.
WPF still uses DirectX 9. :/
In .NET 4.7 I made a switch from D3DX to DirectXMath. This brought in a dependency upon d3dcompiler_47.dll - which is a DX11 component (it supplies D3DCompile Win32 function IIRC).
Besides this, WPF still uses DX9 in both .NET Framework and .NET core.
@darcome these are very good suggestions. I would suggest opening issues for each and let the community organically vote and help us prioritize each of these issues.
Give the possibility to write Vertex, Pixel and Geometry shaders.
It鈥檃 possible to incorporate your own shaders into a WPF application today. Have you had a chance to look into ShaderEffect yet?
WPF still uses DirectX 9
Huh, now I'm very confused, I'm 100% sure there was a blog post about updating the WPF rendering engine. I even had posted a question whether D3DImage interop would be updated as well (answer was no but they'd forward the request). Did that effort exist and got canceled? I don't remember if there ever was an announcment that it was done, I may just have assumed it was because D3D11 started to get loaded into the process after some framework update.
That said I'll definitely try updating it once it finally releases, I've done something similar once already and it wasn't too hard. I just hope the closed source part (line services etc.) doesn't depend on DX9, that would really be a showstopper for me.
It鈥檃 possible to incorporate your own shaders into a WPF application today. Have you had a chance to look into ShaderEffect yet?
I don't think that works on the 3D side of WPF, does it?
Hi, @weltkante @vatsan-madhavan Any news about the update to the rendering engine to support DirectX 11-12?
We currently have been trying to make Srgb work with D3DImage by looking into a few solutions like SlimDX, SharpDX, D3DImageEx but we believe that DirectX 9 does not support it. So now we need to copy the DirectX 11 surface to a memory buffer, pass it to WPF and use a WriteableBitmap to draw it. Which as you might think, has some performance issues especially on 4k monitors when our application runs fullscreen.
So we're wondering if we should hope for an official WPF update to support this or if we should investigate other solutions.
I had a prototype reimplementing the WPF native side in D3D11 for rendering and D2D for geometry. It maps pretty cleanly, but its a reimplementation and not a port, so I can't judge the compatibility issues this would cause (e.g. edge cases might behave differently if the semantics of D2D geometry should happen to differ from WPF's implementation). It was a crude prototype though, just proof of concept to check if its doable, and many of the fine details are not finished (in particular text). Having had a look at the current WPF source code I think porting it is not reasonable, but reimplementing the native library API on D3D11/D2D and keeping the managed side should be reasonably doable.
I'm currently not proceeding with any of my WPF plans, since its obvious the team/repo is moving too slow for what I'm doing, so most likely my changes won't be flowing back, and I'm not ready for a fork since that would mean I need to have my own designer as well.
Most helpful comment
Hi, I was thinking about the following, per example:
1) Make the engine use the latest version of DirectX instead of DX9.
2) Handle transparency automatically instead of having a user think what's the correct order to load objects in order for them to be transparent.
3) Give the possibility to write Vertex, Pixel and Geometry shaders.
These are just examples (I am not a 3D engine developer therefore I couldn't help).
Another possibility would be the following, even if probably is not feasable...
Would it be possible to sort of "port" BabylonJS to WPF so that the 3D Engine would be something modern as BabylonJS, but the simplicity to describe a 3D scene with XAML would remain? I know the BabylonJS team is a microsoft team, therefore maybe it would be possible to have the WPF3D team and the BabylonJS team cooperate?
I don't know... just my 2 cents...