Classes for skinning animation in 3D models.
3 Likes
It would be nice, if possible, to be able to get the ātrueā line number of a warning/error in shaders.
Explanation: when using include(s) in an fx file, the line shown in the pipelinetool (and I suppose, by transitivity the line returned by mgfx) is offset by the number of lines in each of the inluded files.
If you have for example a warning for a truncation of a vector in your fx file at say, line 100, and an included file with 27 lines (these values are examples of course) then in fact the warning is at line 73, not 100 (which can be beyond the lines of the fx file)
Or is there an option to use with mgfx ? (āreturntruelinenumber ?)
1 Like
Here is a minor one. In spritebatch draw, add dual layer sort options. FrontToBack + Texture and BackToFront + Texture. So if a group of images (A,B,A,B,A,B) drawn on 0.5f layer. It will group all of them on 0.5f then secondary by texture so it can batch it more efficiently so (A,A,A,B,B,B) on layer 0.5f.
I make my vote, on OpenGL ES 3 support. For example if I set the game to HiDef profile, MG should support all features backed up by OpenGL ES 3.
HoloLens/Windows Mixed Reality support.
But a better solution of OpenGL shaders could be maybe even better because the difference between DirectX and OGL is big.
You mean in terms of whatās supported in MG? Because thatās not true.
Though we do need a solution for HLSL ā GLSL that works on all desktop platforms.
THIS, I was about to buy a headset and then realised, though I saw a project supporting it, somewhat [not seen actual imagery] and it was a hack job so not ideal at this stageā¦ but having this going forward, would be a neat step when the second generation of headsets arriveā¦
Biggest things Iād like:
- Swizzle functions on vectors.
- Vector2.YX(), Vector2.XXX() -> Vector3, Vector2.XYYX() -> Vector4, etc
- Broader math operator support across the Color/Vector families
I guess I could just make a PR for those though.
Swizzles were actually pretty easy when I sat down at it: Swizzle-builder + generated swizzles for Vector2, Vector3, and Vector4 including the combinations between them like Vector2.XXXX() -> Vector4.
2 Likes
One feature Iād really like to see is the ability to get an unmanaged pointer to the pixel data of a texture/render target.
This would allow us unsafe users to pass pointer types to unmanaged code (for example, Pango) and allow them to write pixel data DIRECTLY to a MonoGame texture, skipping the use of GetData<T> and SetData<T> which saves RAM and cuts out a pretty big performance hit.
1 Like
MonoGame does not keep a copy of texture data in RAM. Textures are usually only store in video memory (VRAM). So it has to be copied to RAM to be able to get an unsafe pointer which is exactly what GetData does.
We could consider exposing the texture id/handle, in case third party libs require a handle (this came up before with regards to VR support). But thatās not cross platform, so not sure if thatās something we should do.
Maybe the new Span<T> from C# 7.2 could help you ācherry-pickā some performance somewhere ?
I donāt want to be pushy, what you are doing is incredible and even more incredible is fact you are doing it for free. Now I realize, is there even donation button I am constantly missing? I just want to ask so I can plan accordingly, whatās current state of:
- Make the low level Shader API public.
- Add support for Geometry shaders.
2 Likes
Yes, there is 
thereās a āSupport MonoGameā link in the footer of every page except for on the forum (I guess thatās an oversight). It links here: http://www.monogame.net/donate/
This has been planned for a long time, but no one has gotten to it yet. Whatās your use case specifically?
EDIT: Hereās the relevant issue for it: Consider exposing low-level Shader / ConstantBuffer API Ā· Issue #3471 Ā· MonoGame/MonoGame Ā· GitHub
Also no work on this. The issue here is with cross platform shader compilation. MG uses MojoShader to translate HLSL bytecode to glsl and to get reflection data. MojoShader does not support geometry shaders. Last time I checked, none of the alternatives were ready to replace MojoShader.
1 Like
The forum is actually independent from the websiteā¦ but yes, it needs to be unashamedly more prominentā¦
1 Like
I, for one, wouldnāt mind having to write shaders twice in order to get them working in other platforms, specially if the benefits are great (as geomtry shaders are)
I already have lots of problems when porting shaders to android and Iāve been using GLFX to solve some of them. With mojoshader sometimes I find that I have to end up juggling code in order for him to make a correct GLSL translation. One wrong line and boom, you end up rendering nothing.
When those problems arise (which is often), I spend less time converting the shader to GLSL manually than trying to find a workaround for the Mojo bug
(no need to say Iād love GLFX support in the stable branch 
)
2 Likes
Iāve found this which may be of some help (or not)
It was used here: Simon's Tech Blog: Recent Update 2014
To write cross platform shaders, shaders are written in my own shading language which is similar to HLSL. Those shaders are then parsed by a shader parser generated by Flex and Bison[9] to obtain a syntax tree to output the actual HLSL and GLSL source code.
1 Like
The optimization stage deciding to kill things is the real problem with a parser. The parser sees that stuff is there but then when it comes to building the list of uniforms/parameters itās no longer there. Which as far as I could see, in my perusing, thatās the main reason for the way shaders are as they are. They need to get valid information out of the result, which makes it much worse than just translating as an AST must be built and checked.
Nevermind that hull/domain shaders are only mappable between HLSL and GLSL in trivial cases since they diverge.
Iāve been juggling around the notion of making my shader graph stuff work for Monogame. Though eto forms not having a sane way to paint custom controls cross-platform put a big wrench into doing that cross-platform.
As far as I could see when I looked at it the graph would take care of enough of a chunk of what the optimizer does that shader optimization shouldnāt hurt anything since it already detected this isnāt used and this tree of nodes is all constant situations.
Gotcha is that graphs are brittle to external changes. Although a simple snippet is easy to auto-build a node for (ie. a node for calculating new UVs for parallax occlusion mapping) itās not trivial to recognize or respond to āwell now everything is brokenā situations. I couldnāt find a case in the asset processor where there were consequential dependencies of that sort.
Still means some write for multiple platforms but itās at least confined to a node-by-node case.
I guess I could make it all work in WPF and then leave it to those braver than I to sort out how to cross-platform that sort of thing.
Maybe the way yo go for Monogame will be make one shader compiler for each platform, which i think would sign the end of monogame: there is already little spare time for contributors to improve the current version.
Maintaining many versions may lead to divergence, moreover when more contribute to the version they are interested in at the dispense of others.
But as technologies evolve, if monogame does not enter in the wagon it may stay a 2d framework. There is already dx12 and monogame does not yet provide all the stuff of dx11 (and dx10 as Geom. Shader were already available)
The only way to go i can see is to propose to install the technology we need: you wanna make some dx12 features with win10, monogame only install the framework (the common stuff from xna: vectors, matrices etc) and the dx12 part that is needed to compile your shaders.
You need to do something with linux, install monogame for linux with opengl related compilers.
Maybe the support of mobiles can stay in one package, as they share the same graphics card (not sure but it is opengl right?)
This way, breaking changes when a new opengl or directx arise only impact the concerned technology and not all of them, which can stay alive and running
Maybe iām not clear, tell me if anything is garbage, i just woke up with these ideas 
1 Like
For low level shader API: Some optimization. Geometry shader, now that would have many uses for me tho generally experimenting with what I can actually do.
1 Like