It used to work fine with XNA (and it still does, i’m porting my code to Monogame… Well i try but no success with custommodelprocessor and effect assignement)
As discussed here
and maybe the solution
but it seems more of a hack than a clean solution to me and a lot of maintenance cost whenever changes to the code are needed.
So… when I build a model with an effect, it MUST BE an xnb… But when I debug the pipelinetool and mgcb, it calls again “BuildAsset()” method on an already xnb ! So why do i need to reference an ExternalReference to an xnb and rebuild an xnb from this xnb ?
Moreover, when building the model with my custommodelprocessor, no importer is defined (the string field is null), so in debugtime i put “EffectImporter” to see what happens, and then i get this famous Bad token CppNet.Token.
Does anyone have a clue to bake effects at build time in a custom processor ?
It’s a real pain to load all the stuff at starttime, as if i was doing my own contentpipeline…
Thx
After some further investigation in the debug process of the pipeline, i have found a clue i think important:
ExternalReference extref = new ExternalReference(effectfilepath, material.Identity);
where effetfilepath points to the fx file, ''Shaders/RenderBuffer.fx".
When building the model, all went ok but one thing: it tries to write the RenderBuffer.fx file first, and as
public void WriteExternalReference(ExternalReference reference)
tests if the filename ends with *.xnb, it throws an exception !
So first question: why is it trying to write the original fx file ? If I skip it manually during the debug session, it writes all the files for my model with my processor without errors nor warnings like it did with XNA 4 Next step is to load thses built files in my engine, to see if it works, but i don’t want to waste my time with the engine port to monogame if the pipeline is unable to do this (all my tools are ok with xna, i dont want to rewrite all from zero)
Second: How to see what’s in the xnb file after the build to check all is inside ?
I’ve been on this for a month.
So… As noone that has been working on this kind of problem does answer, and as i don’t want to waste another month on this problem instead of making my game, i’ll switch to unreal engine. Higher level conceptually, but it can do 3D things… and i won’t certainly be the only one strugglin on a so big problem. Goodbye monogame…
XNA was really fun. Monogame was irritating. Monogame is a great library, but not solid enough from my point of view and my use compared to XNA content pipeline. I spent 2 years on my engine on XNA, i dont want to do it again + debugging MG and never finish a single game. I’ll start a new adventure…
Next step is to load thses built files in my engine, to see if it works, but i don’t want to waste my time with the engine port to monogame if the pipeline is unable to do this (all my tools are ok with xna, i dont want to rewrite all from zero)