Dynamic Model Generation At Runtime

1

Re worded this as a friend pointed out that is seemed I was being cranky, and that really was not my intention

In my engine, I have a base class to render my geometry, this is used for models from the pipeline as well as primitives I can create at runtime, this way I have a single place for rendering geometry and so the behavior is consistent throughout.

To render my primitives, cube, sphere, cylinder, quad, plane, capsule, I create a Model in code and fill it with Model Mesh and ModelMeshParts, so it then appears just like an imported Model from the content pipeline. Now, in 3.8 it appears that going forward, I may not be able to do that any longer as can be seen here:

image
image1166Ɨ162 11.2 KB

If this is indeed restricted in later versions, how else would I dynamically generate a Model at runtime?

I know I can create vertex and index buffers and render that way, but as I say, I donā€™t want to branch that functionality if I can help it. If I had access to the vertex buffer from the imported Model, then I may be able to do it the other way and put Model data into a vertex and index buffer and keep consistency that way, but, I think the last time I looked, this was not available (due to how XNA was structured).

So, with that in mind, do you have any suggestions on how I could keep rendering continuity and not have multiple methods of rendering geometry? If you could open up the vertex buffers that are in the ModelMeshPart so that I could get the type of the buffer it contains, that would help as I could then move away from using this. I think I even looked at writing a pipeline tool that would get me the Models buffer type, but again, that is not accessible (again due to XNAā€™s structure).

Anyway, your suggestions and advice are, as ever welcome.

Charles.

1 Like
2

Thoughts @Jjagg / @Tom / @harry-cpp

3

So this all comes from here i thinkā€¦

Where @Jjagg says:

Building a model at runtime is not supported. The ModelMeshPart constructor should not be public. Thereā€™s no way to add meshes to a model at runtime.

If I got this right, the exception occurs because ModelMeshPart assumes its parent is not null, which of course it is if you create one using the default constructor.

So yeah there could be a problem here if misused i guess?

The question is do we want to fix this API to support runtime creation or not?

Is the Model classes core to the framework and meant to be used in games or should people be writing their own model types?

1 Like
4

OK, well, I am using basic effect with it, I am not injecting the effect into the mesh part though, as I may want to switch and change effects during run time, so donā€™t want it set in stone.

My draw call looks something like this (not in the engine, I have a framework for materials in that but you get the idea)

image
image1165Ɨ665 35.4 KB

So this draw call gets used for an imported mesh or one I generate at runtime.

I guess, my question is, how do I create a unified render pipeline if this method becomes obsolete and you do not allow access to the VertexBuffer to gain access to the vertex type it is using?

Actually that is a daft question, the answer is I wonā€™t be able to.

For the recrord, this is how my Primitives base class generates the Model, the drived class (Cube, Quad etc.) just sets the vertext and index array.

image
image885Ɨ748 71.9 KB

I think the idea of baking effects and textures into the mesh are great if you are just getting into MG, but if you want any dynamic functionality, then I donā€™t think you want to be baking fixed properties like this, well, I can only speak for myself.

I think the Model class in itā€™s self and itā€™s integration with the pipeline is a great idea, it just needs to be opened up for more flexibility I think. Last time I looked, there is a lot in the pipeline I would like to have opned up :slight_smile:

5

Just so I am not confused what is being locked out here, but removing the possibility of creating models using MG code is locked out now?

I was planning to create my own model creation toolā€¦ Really hate Blender and cannot afford 3DSMax/Maya subscriptionsā€¦

6

Would it be possible to instead of generating and providing a MonoGame Model class to the renderer to have a custom Model class? That way you could extract all data from MonoGame Model classes to fill custom Models with data and also generate your own Models at runtime. You would then use the custom Model class in your renderer / in the render logic. Just an idea, donā€™t know if this makes sense in this context here :slight_smile:

7

No, under 3.8 you can still do this.

1 Like
8

I get you, but you canā€™t as I cant get at the vertext and index data in the buffers that are in the Model.ModelMesh[].ModelMeshParts[], no. If I could then this would not be an issue.

As I say, if you could open up the VertexBuffer and IndexBuffer classes so I could get at that data, then I would be all good, I could do as you say and have my own data model populated by the imported data, or by my runtime code. As the framework is as locked down as it is, thatā€™s just not possible, unless I am missing a trickā€¦

9

I do have a content processor actually where I can pull out the data, I guess I can use that, but it would be a shame, and a lot simpler if the framework classes were more accessible.

It is a design decision, I get that, and I am happy with what ever you guys decide.

10

@Tom, just re reading what @Jjagg put there, and I am, and do create models at runtime, as my code shows, so are you guys going to stop this going forward, or allow it to continue?

I have just written some code in my engine to try and work around this if you do stop it being able to be done, but it would make it a lot easier, and indeed model asset loading faster if I didnā€™t have to strip model data out of the model class to then use in my own Model class for rendering.

image
image800Ɨ508 19.3 KB

The box is dynamic, the rabbit is imported.

11

It the model mesh part constructor was already locked down (marked internal) and was locked down in xna.

It has instead been made public again and simply marked obsolete.

The problem is partially due to inadequacys n the content pipeline that arenā€™t matched to xna to match the manner they intended to get around this internal constructor.

The problem being they (xna) were afraid that it could be misused as is i guess, as if anyone already using it (building mesh parts) wouldnā€™t be smart enough to figure out the dangers.

Sort of silly.

Whats serious is i donā€™t even use the monogame model class cause its completely outdated and inadequate anymore.

12

Ok, so i guess concensus is to drop the model class.

Ill use my current work around untill I write an importer that gives me what I need without using the Model class.

Thanks all.