Plugin won't load set material

[SpiderPig]

My plugin loads geometry fine but it doesn't seem to use the data I assign to the material.

Like the Quake Plugin example, I set a similar material to each mesh in the plugin code;

auto mtl = new GMFMaterial(file);
mtl->text = "{\"material\":{"
	"\"color\": [1,0,0,1]"
	"}}";
mtl->path = L"material0.mat";
mtl->data = (void*)mtl->text.c_str();
mtl->datasize = mtl->text.size();

mesh->SetMaterial(mtl);

When I load the model, m_material for all the meshes are no longer 'empty' but the color is not red.  It is still the default white.

1. Are there any extra steps I should take to make it work?
2. OR... Can I do something like this instead of creating a material in the plugin?  And have the engines LoadModel() function automatically load the file and use that?

mesh->SetMaterialPath("MyMaterialFile.mat")

I saw a variable in the mesh class for the material path.  Perhaps this should work?

mesh->materialfile = L"MyMaterial.mat";

 

[SpiderPig]

I've tried various things no matter the data for the material, it appears to be ignored when loading the model. 

[Josh]

Why are you using a plugin at all for this? What are you trying to do?

[SpiderPig]

I'm copying the quake plugin example but maybe I wrong in how I think it works.

I've exported an Ultra material file from blender along side my exported model format.  I want the correct material files applied to the mesh on that model upon loading in game.

[Josh]

Yeah, but why are you making a custom model format? It's impressive that you can do this, but what is the reason for it?

[SpiderPig]

Oh okay.  I'm going to write a blog about it once I finish the plugin.  But I'll explain here too.

While GLTF makes a lot a sense there are a few things about it I don't like and I find in-efficient (I know some things I've raised already will be fixed)

• I don't like folder clutter and GLTF has two files per object (GLTF + BIN) I know about GLB, I've not tested it in while and didn't try as I decided to go with a plugin approach.
• I also don't like the fact every time I save the GLTF it generates the PNG / JPG texture files, again purely the preference of not having unnecessary files in my workspace.  I know they can be removed from the final export.
• GLTF doesn't store LOD's.  This adds more files to manage.
• You also have to convert textures to DDS.
• Currently each GLTF file has it's own material which is painful to manage during development.  (I know this will change)
  • I have 12 pine tree variations, each with 4 LODS.  So that's 48 GLTF files that need changing if I want to adjust the diffuse or specular color, or any material setting.  I'm going to write a vertex sway for my foliage, I don't want to go through 100's of GLTF files to change the shader family of all my foliage.
• The export process from blender requires me to select and export each model / LOD at a time.  I'm going to want to adjust geometry in the future, I don't want to export each LOD stage of each piece of foliage over and over.
• I can export a PHYSICS mesh as GLTF and have the assets editor convert it to a collider.  But then I have to delete that GLTF / BIN file because it is no longer needed.  This is why I made the plugin for blender so this process now is as simple as selecting the physics mesh in blender and exporting it directly as a collider to the require folder.  Ultra will load it automatically it the model of the same name so that is awesome!

 

My Format:

• Exports one model file containing every LOD needed.
• Exports each material as a separate JSON file, and (will soon) export / covert textures as DDS.
• I only need to select the high resolution model in blender and nothing else.
  • Any model of the same name appended with _LOD# will be gathered and exported at the correct LOD stage.
  • E.g. Selected model is PineTree_001 and the following objects are auto exported
    • PineTree_001_LOD1
    • PineTree_001_LOD2
    • PineTree_001_LOD3
• Auto exports the collider mesh if an object exists of the same name appended with _PHY
  • E.g. PineTree_001_PHY
• The exported material files can be shared across all 48 models. (provided I can set a meshes material in the plugin SDK with a file path)

This drastically improves my workflow.  In fact, my game might not even need the editor as if I need to make a material change I'd do it blender so that my source files are all ready to be exported again.

I'm going to write another blender plugin that will (hopefully) export any material directly to an Ultra material without the need to export a model with it.

This way I can update a single material if needed.  The last thing I want to do is edit the material with Ultra and then re-export from blender one day and have it overwrite that material.  It's just better to manage it directly from blender I feel.  This way I know that my blender source matches what I have in game.

 

I dare say that most people are going to drag most of their models through an external editing software at some point (probably most with blender), and most models are going to need LODS.  Managing this with GLTF is just a bit tedious.

I understand why GLTF is good, and if you only want one model from online and never want LODS for it or want to change it's geometry / animation in some way then it will be fine, the process is quick, simple and easy.  But as soon as you want to edit it, make LODS and mange everything efficiently I think GLTF falls apart.  Getting a GLTF file back into an external software sounds all well and good, but if your manage your project in a sensible and efficient manner (make backups etc.), is it really necessary that you can get it back in?

I'd much rather a format that I can export directly to Ultra and have every aspect of it work; LODS, materials, colliders.  I need to be able to modify the whole thing with minimal work because I will have 100's of different assets. 

Rant over.

 

[Josh]

Okay, do you need to go through the plugin system for that, or can you just make a LoadSPG() function you call in your program?

[SpiderPig]

I'm pretty sure I need to use the plugin system.  I'm getting the material path from within the model file like this inside the plugin:

auto str_len = 0;
reader.Read(&str_len);
auto material_path = reader.ReadString(str_len);

What I think will work would be something like this:

mesh->SetMaterial(material_path)

What I was hoping for was that my game would load the material file so that if I use a file watcher.  The material asset could be auto reloaded if I edited that file manually.

[Josh]

27 minutes ago, SpiderPig said:

• I don't like folder clutter and GLTF has two files per object (GLTF + BIN) I know about GLB, I've not tested it in while and didn't try as I decided to go with a plugin approach.
• I also don't like the fact every time I save the GLTF it generates the PNG / JPG texture files, again purely the preference of not having unnecessary files in my workspace.  I know they can be removed from the final export.
• GLTF doesn't store LOD's.  This adds more files to manage.
• You also have to convert textures to DDS.
• Currently each GLTF file has it's own material which is painful to manage during development.  (I know this will change)
  • I have 12 pine tree variations, each with 4 LODS.  So that's 48 GLTF files that need changing if I want to adjust the diffuse or specular color, or any material setting.  I'm going to write a vertex sway for my foliage, I don't want to go through 100's of GLTF files to change the shader family of all my foliage.
• The export process from blender requires me to select and export each model / LOD at a time.  I'm going to want to adjust geometry in the future, I don't want to export each LOD stage of each piece of foliage over and over.
• I can export a PHYSICS mesh as GLTF and have the assets editor convert it to a collider.  But then I have to delete that GLTF / BIN file because it is no longer needed.  This is why I made the plugin for blender so this process now is as simple as selecting the physics mesh in blender and exporting it directly as a collider to the require folder.  Ultra will load it automatically it the model of the same name so that is awesome!

• I recommend using .gltf instead of .glb.
• There is a glTF extension for LOD support but I have found having separate files is easiest.
• Yes, I wish 3D modeling programs would just export glTF files with DDS. The easiest way to convert these is with this tool.
• glTF embedded materials can have a name applied to them. Perhaps we should make the loader so it looks for a file by that name and loads that, if it exists.

I think you will end up running into a lot of limitations if you are going through the plugins system.

[SpiderPig]

2 minutes ago, Josh said:

I think you will end up running into a lot of limitations if you are going through the plugins system.

What sort of limitations?  Does it handle animations?

[SpiderPig]

I can see the vertex class supports bone weights and such.  Even if it didn't, I would still very much like to use the plugin system for this.  At the very least for static objects like foliage. 

[Josh]

It doesn't get used very often and it's difficult to debug.

[SpiderPig]

Oh okay.  That dosn't bother me.  I've been able to debug my plugin okay.

[SpiderPig]

Is my suggestion somthing you think you can add or are you reluctant to do so for that reason?

[Josh]

I don't know what your suggestion is. I don't know if you are talking about the plugin SDK side or the engine.

[SpiderPig]

I'll see if I can explain it better.

This is the code in the plugin the saves a materials information.

"path" will be set to "Materials\\MyMaterial.mat"

bool GMFMaterial::Save(MemWriter* writer, const int flags)
{
	uint64_t start = writer->Pos();
	writer->Seek(start + sizeof(uint64_t));

	writer->Write(path);
	writer->Write(&datasize);
	if (data != NULL)
	{
		writer->Write(data, datasize);
	}

	uint64_t end = writer->Pos();
	uint64_t sz = end - start;
	writer->Seek(start);
	writer->Write(&sz);
	writer->Seek(end);

	return true;
}

In the engine:

LoadModel("MyModel.myformat") should not only load the model, but look at that material path that was written to the stream for the mesh (writer->Write(path);) and then load that material and apply it to that mesh.

Does that make sense?

[Josh]

I am honestly reluctant to put effort into helping someone rewrite major parts of the engine, when it's just going to lead to more and more custom features requested that only split the user experience.

[SpiderPig]

Then I suggest the GLTF experience is drastically revamped.  It's okay for people who want to tinker, but for people like me who actually want to develop a commercial product.  It's a pathetically mind numbing experience that's taking huge amounts of time.  Hence why I'm forced to make my own plugin.

There's also this which is what the topic was about.  Now this IS already in the plugin SDK.  What about the fact that this doesn't work?

auto mtl = new GMFMaterial(file);
mtl->text = "{\"material\":{"
	"\"color\": [1,0,0,1]"
	"}}";
mtl->path = L"material0.mat";
mtl->data = (void*)mtl->text.c_str();
mtl->datasize = mtl->text.size();

mesh->SetMaterial(mtl);

The model is loaded in Ultra and the mesh has a material but "mtl->text" doesn't change anything.  Is this not its intended use?

[Josh]

26 minutes ago, SpiderPig said:

Then I suggest the GLTF experience is drastically revamped.  It's okay for people who want to tinker, but for people like me who actually want to develop a commercial product.  It's a pathetically mind numbing experience that's taking huge amounts of time.  Hence why I'm forced to make my own plugin.

There's also this which is what the topic was about.  Now this IS already in the plugin SDK.  What about the fact that this doesn't work?

auto mtl = new GMFMaterial(file);
mtl->text = "{\"material\":{"
	"\"color\": [1,0,0,1]"
	"}}";
mtl->path = L"material0.mat";
mtl->data = (void*)mtl->text.c_str();
mtl->datasize = mtl->text.size();

mesh->SetMaterial(mtl);

The model is loaded in Ultra and the mesh has a material but "mtl->text" doesn't change anything.  Is this not its intended use?

I don't know. I wrote this code a couple years ago and haven't used it much.

The plugins system is technically impressive, but I wonder if we might be better off just integrating things like the FreeImage load/save routines into the engine itself.

[SpiderPig]

Hmmm, I don't think you should get rid of the plugin system.  It'd be like getting rid of the editor extension system.  There are very good reasons to have both of them.

1. Being that you are a one-man developer, we have to wait considerable amounts of time for you to be able to implement features.  With plugins and extensions we don't have to wait.  We can do these things ourselves.
2. You said yourself Ultra is targeted for the more advanced users.  Plugins are advanced and should remain for that purpose.
3. I could wait for you to fix GLTF up a bit so it's workflow is improved.  But how long should I wait?
4. Should I release a commercial product only to have plugins removed half way through its development?

3 hours ago, Josh said:

The plugins system is technically impressive, but I wonder if we might be better off just integrating things like the FreeImage load/save routines into the engine itself.

If you do that, I think your only making yourself the bottleneck again because we would then have to beg and wait for things to be implemented.  You'd only be making more work for yourself.  How Ultra works at the moment feels really smooth to me and starting to remove things likes this concerns me that there might be something else my game relies on that might be removed in the future.  I really don't want to be in a position where this might happen.  This is what Leadwerks was like.  This is honestly why I put so much time and effort into doing things myself;  voxel terrain, foliage system, physics system, character system, and now model system, etc.  Because that way, I know they work, I have the source code and I can fix bugs / add features whenever I want.

 

I've given it some more thought.  I don't think adding what I suggested is catering only for me.  I also don't understand how it's a "major" part.  It seems pretty simple to me, but then again I haven't seen your code for LoadModel().  I mean, clearly LoadModel is already searching a plugin and creating a material for each mesh, so, is the following code really that difficult?

shared_ptr<Model> Ultra::LoadModel(shared_ptr<World> world, WString filepath) {
 ...
  
  auto mat = LoadMaterial(data->material_path)
  if(mat != nullptr){
  	mesh->SetMaterial(mat)
  }

The plugin SDK clearly supports the loading of custom / other known, model formats.  It clearly has an option to assign a material to mesh which isn't a custom feature.  I think that should be a material filepath as well as being able to construct the material dynamically.

4 hours ago, Josh said:

I am honestly reluctant to put effort into helping someone rewrite major parts of the engine, when it's just going to lead to more and more custom features requested that only split the user experience.

Like I said, it's not a custom feature.  I simply want to assign a material to a mesh within the plugin SDK and have Ultra::LoadModel() load that material and apply it.

The only reason I'm insisting on all this is because of the fact a material can be assigned to a mesh in the plugin SDK.  If your saying - that LoadModel() should not be loading and applying materials then I will have to find another way to do what I want.  But from what I've seen, LoadModel() does just that.  It loads models and applies the specified material.

 

EDIT : At the end of the day, if I truly can't convince you of this.  I will have to do away with LoadModel() and write my own importer to replace it.