search

vpenades / MonoScene

Example of using Monogame and SharpGLTF to load animated glTF models at runtime.
MIT License
39 stars 13 forks source link

Tentative Roadmap. #3

Open vpenades opened 4 years ago

vpenades commented 4 years ago

This repository served originally as a showcase of how to use SharpGLTF to load a 3D model into a game engine, in this case, MonoGame.

Since then, it's been evolving, and given that MonoGame is severely lacking a decent 3D API, we're trying to provide an alternative for the in-built monogame 3D model features.

Short term development:

Roadmap / Wishlist

( in no particular order, and items with question marks need to be discussed whether include or drop )

Effects variants

Content Pipeline processing. (Help Needed)

The two reasons why this library loads glTF models at runtime instead of going through the content pipeline are:

Right now, improving the content pipeline is a dauntling tasks that nobody seems to be willing to tackle, and it would probably cause lots of backwards compatibility issues with existing importers (Assimp). Also, 3D models format technology is continuosly evolving, so there's no point in doing a lot of work, just to become outdated after a few years.

So my proposal is to take away 3d model processing from the main pipeline and make it a separated tool. Pretty much like the effects compiler tool. It could be made so it can be called by MGCB seamlessly, but it would no longer be integrated within the main library.

In order to do this stand alone 3D model converter tool, there's a prerequirement: the whole XNB serialization API needs to be exposed, so third party tools could write XNB's on their own.

Also, given that it is very useful to be able to consume glTFs at runtime and from the content pipeline indistinctly, and to avoid duplicating efforts, it would be desirable to use the same glTF importing codebase for runtime and pipeline contexts. This feature essentially excludes the possibility of using the current content pipeline.

Shadows (Help Needed)

There's a multitude of shadowing technologies, and it's simply not feasible that a single effect supports all of them. Furthermore, having in-built shadows in the base effect might coerce the way in which derived effects implement their own shadow technology.

So, from an architectural design, effects with shadows must derive from the base effect.

Notice that shadows implementations might derive from more than one effect class, so maybe some sort of composition architecture might be required.

Additionally, I believe the most complex light/shadow scenarios are designed with deferred shading... so maybe it's worth to explore.

Future works & beyond glTF (Help Needed)

Until MonoGame updates it's rendering API, it is simply not possible to implement some glTF related features:

Also, there's features currently not supported by glTF, but might be supported in the future, or by other formats.

NicusorN5 commented 3 years ago

Providing some arguments to the features that have a question mark:

1.) I'm my opinion, shadow mapping should be implemented by the user itself, since BasicEffect Model instances may be used for really basic objects like props, map elements, etc. (Since shadow mapping requires redrawing the scene, playing with the stencil buffer, and some more stuff). 2.) For the model picking - I have a Model-Ray intersection algorithm written in C# Monogame (Moller-Trumbore to be exact) written on an older push in my game engine's code. Check that out here: https://github.com/3DRadSpace/3D_Rad_Space/blob/7feb0daa41190d244bfab2d109fd62f97dadba19/3DRadSpace/3DRadSpace/Editor.cs#L348 Feel free to adapt it to your own code. 3.) MipMap generation and texture compression: both sound good. Why not?

vpenades commented 3 years ago

@NicusorN5 Ideally, the ultimate objective is to have a framework than can be used, out of the box to achieve similar quality results compared to the basic implementation of Unity.

There's a good number of developers that don't really wish to have to develop their own shaders on every project they start, and need stuff that just works. This is what I think monogame needs to keep being competitive.

This doesn't mean I am going to do all the stuff listed in the roadmap... it's mostly a wishlist of what I would like this project to solve... and I would like people to contribute solutions for some of these issues.

1.) shadow mapping...

This is a wish of mine, and I don't hope to be able to do it myself... it's in the category of things I would like to have in monogame out of the box.

2.) For the model picking

I was already thinking on solutions for picking, since it's something I've already done in the past... but I will certainly look at your solution, thanks!

3.) MipMap generation

This is a very much needed feature required by glTF to look good on monoGame... but it's also a feature that needs to be implemented within monogame itself. This includes not only supporting mipmap generation, but also supporting newer texture formats like WEBP and KTX2, which are supported by glTF.

NicusorN5 commented 3 years ago

Coming back, I've found some articles regarding implementing shadow mapping in XNA. They are actually published again, in a GitHub Wiki for a while, and I've found out that there's a very small number of lines to change (change the shader version).

https://github.com/SimonDarksideJ/XNAGameStudio/wiki/Riemers3DXNA3hlsl12shadowmap

You might have seen this, but I think this might be helpful, anyways.

vpenades commented 3 years ago

You might have seen this, but I think this might be helpful, anyways.

No, I didn't... and the shader code provided by the link is short enough to give it a try at some point.

thanks for the contribution!