Dev/terrain material editing

[Wc4ever]

Here is my take on terrain materials editing. I tried to adopt MeshComponent approach.

It works fine at first glance. But I can't figure out how to do serialization backward compatibility. Seems like materials library serialization is done at this point so I cant some how inject new components data into it. Also it's seems like I can't simply create new components in scene since I don't have access to scene.

Any suggestions?

[turanszkij]

Is it not enough to just copy material structure into the terrain.material_Base, material_Slope, etc instead of using entity handles? So when you select a material for base/slope/low/high in the editor, the terrain doesn't remember entity handles, but copies the selected material into itself? This way the terrain is not dependent on what's in the scene, but it contains its own data as it currently does, and doesn't need serialization changes.

[Wc4ever]

In this case you need to reselect materials after every little adjustment, combined with huge list of materials in combo box it could be painful and slows down tech artists iterations.

Also can't see what's wrong with terrain components depending on other components seems it's common, maybe even "best practices", for current engine architecture. Components encapsulates only necessary data for its purpose.

[turanszkij]

About your previous questions, if you want separate entities for the terrain materials, then you insert them into the scene's materials and then you don't need to serialize material components from the terrain serialization. And for back-compatible versioning, the way it is done is by increasing the version number of the terrain component where it's registered, that would be in wiScene.h, at this line:

wi::ecs::ComponentManager<wi::terrain::Terrain>& terrains = componentLibrary.Register<wi::terrain::Terrain>("wi::scene::Scene::terrains", 3); // version = 3

Then in the terrain's Serialize function you can decide what data to read from the archive based on the current version. Usually it is done like this:

if(seri.GetVersion() >= 4)
{
  archive >> newDataThatwasintroducedAtVersion4;
}

Although I don't really like that this changes how the scene will now rely on there being separate material entities in the scene. I feel like it would be better to have some editor-only functionality to just directly edit those 4 terrain materials.

[Wc4ever]

Ok, thanks for the answer.

If you don't mind let's talk about general approach because I feel like I don't fully understand. At this point terrain already depends on different entities for props meshes, also mesh component depends on entity for material, do you consider these solutions as "not the best" and it would be better for mesh component to contain material as inner structure with inner editing window?

Also what about grass particles, I was thinking about excluding them from terrain also, and implement ability to link more than one grass particle into terrain. Is it also not good idea?

[turanszkij]

Well, we can move ahead with this solution too, it's not a big deal, I just thought it would be better to not modify the existing terrain system for the Editor's sake, this could break other users' code too.

But I like how it works with your method too, my little complaint is that I think the terrain materials should be also children of the terrain object in this case, that would be cleaner. Also the serialization backwards compatibility needs to be handled (see my previous comment), currently I can't load an existing scene that contains a terrain.

[Wc4ever]

Don't get me wrong I am not complaining or something I just want to find better solution to make terrain more flexible and able to build good looking modern terrain.

Also, these changes not only for editor's sake. I wanted to make it agnostic to base/slope/altitude paradigm, so it going to be easier to add more materials in future. I think it is necessary to allow more masks and materials in terrain system.

Agree about parenting, you mean it should be invalidated like only children materials allowed to link?

[Wc4ever]

Eventialy I discovered it is unsafe to create components in another components manager during deserialization. So it seems at this point I can't convert materials contained in terrain into entites to provide backward compatiblility.

[turanszkij]

I'll run a round with this too, it must be possible somehow.

[turanszkij]

Ok, I noticed some issues with the serialization that are fixable to be able to do what we want and create entities in the scene from inside serialization. I will make some other changes of how the material entities are handled, but it seems that we can go through with your solution.

[turanszkij]

I opened pull request into your branch with my changes: Wc4ever#1
If you merge that into your branch, this pull request will be updated to contain those changes.

[Wc4ever]

Thanks for your help.

I tried similar approach but it never works because deserialization clears everything.

Also then I was debugging deserialization I run in to bug, then that block is out wi::ecs::EntitySerializer.componentlibrary pointer is stale because tmp_scene rewrites it.

[turanszkij]

Yes, what you found was a real issue, I had to fix it. There was not really a reason that deserialization should clear the components, or I don't remember. The other thing that seri is rewritten was annoying to find too, that's why now library pointer is saved now at the beginning.

[turanszkij]

Thanks for your work!