Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Making the Content Pipeline more extensible #6896

Open
NemoKradXNA opened this issue Oct 7, 2019 · 3 comments
Open

Making the Content Pipeline more extensible #6896

NemoKradXNA opened this issue Oct 7, 2019 · 3 comments
Labels
ContentPipeline Content processing issues Design Requires API decisions

Comments

@NemoKradXNA
Copy link

This is not an issue, but something I would like to look at doing with the content pipeline. Having had a look at the code for the content pipeline, I think it would be advantageous for it to be a little more open in how it is put together.

That is to say (and I know it's from the XNA base) there are a lot of private properties or fields in there, lost of methods that could be virtual, and so making writing your own content pipeline classes a lot easier.

So, sealed classes like ModelContent and the class NodeContent & OpenAssetImporter, making their private elements protected so we could derive from them and extend as we need. Making all their methods virtual and so we can override them too.

My line of thought comes from this community thread, and also my own experience of creating pipeline components in the past, originally with XNA, and now with MG.

Maybe there is good reason why it is how it is, and if so, then that's fine, ill just leave it alone, and work with it as is, but if you think it's a good idea, then I don't mind taking a fork and giving it a go :)

Forgive me if this is not the place to raise this sort of stuff, please delete/move as required :)

@Jjagg Jjagg added ContentPipeline Content processing issues Design Requires API decisions labels Oct 7, 2019
@Jjagg
Copy link
Contributor

Jjagg commented Oct 7, 2019

The content pipeline classes could definitely be opened up a little. If you or anyone else reading this has suggestions for what to make public, post it here and we can discuss on a case by case basis :)

@NemoKradXNA
Copy link
Author

Maybe start with OpenAssetImporter, be good if ImportNodes was not private, but protected and virtual. We could then derive from it, and in the case of the community post I mentioned in my OP, we could inject extra mesh data as required from there. Actually the more I dig there the more I want to open up, same with CreateGeometry :D

Pretty much, anything that is private should be protected, and all methods should be virtual :)

@willmotil
Copy link
Contributor

willmotil commented Oct 13, 2019

I actually just use the nuget open asset importer and put it into my game since i made my own loader and model class so i can have animations. Its kind of ironic that monogame already has it but its so locked up i need to download the nuget. At which point makes me wonder... why ?

Whats even more ironic is i tried to get the animated models to work in monogame and for the life of me couldn't figure out how to do it i couldn't even gain access to the needed stuff. Though in xna it seemed pretty easy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ContentPipeline Content processing issues Design Requires API decisions
Projects
None yet
Development

No branches or pull requests

3 participants