I am interested in hearing how everyone sets up their games so that objects can share materials without creating duplicates. Appended objects that use an already existing material tend to create duplicates of that material. What methods do you use to avoid that?
I tend to group objects by material use in to different blends then use libload.
It’s possible to write a bpy script that will tidy up all your duplicate textures and materials too if you have a disorganized project.
Have you found that libloading the same blend produces duplicates? I have not quite had the opportunity to test LibLoad extensively though my project will rely heavily on it. My project uses terrain chunks that share materials (trees, grass, etc.) and I will be using Libload for a streaming terrain mechanic. I have over 1100 blends, each with its own chunk of terrain, and I need a solution to avoid a massive memory leak.
Though I consider my project well organized, I would be interested in learning about that bpy script if you have it off hand.
I’m sure you can link materials the same way as you link meshes. Till now I did not need to do that as the objects had their own unique material.
When you link the group (containing the objects with meshes) you get the [linked] materials too. But I can’t tell if that material is a copy or not.
It turns out that linking (not appending) does not duplicate materials unless you make the object and its materials local, which is great. Although it seems like in this scenario, it would increase the rasterizer for me to load the same material from different blends. I don’t quite understand linking completely so this is very much an assumption.
Edit: So it doesn’t affect the rasterizer, but it adds 10% to my GPU latency compared to if the objects are appended.
Nice topic, I wonder if we could check for duplicated material with rayCast? I’ve never tested it but I assume if the poly return material names with name.001 etc, it might be one?
raycast only returns polyProxy on triangle meshes.
for mesh in object.meshes:
could be used, on load to test for materials
Names are a bad identifier. You can only guaranty the material is different when you get different name. There is no such conclusion when the name is the same.
What you can do is the check the Python id. But here is might be the other way around. Two different Python objects might refer to the exact same material (native code object).
I wonder why anyone things linking increases rasterizer workload. The rasterizer does not know about linking.
From what I know all data is loaded into memory at scene load. If there is a slightly overhead (e.g. on I/O operations) it is at the time when the scene loads/starts … once. But I do not know the implementation details.
I am interested in hearing how everyone sets up their games so that objects can share materials without creating duplicates. Appended objects that use an already existing material tend to create duplicates of that material. What methods do you use to avoid that?
I have no idea if I’m doing this right . . . But . . . If i append objects with the same material (textures) or whatever, I delete the duplicate material (texture) and re-assign the original material to the appended object. It’s time consuming tho.
So in UV image editor I select any texture with <name of texture.001> (hold Shift while clicking the “X” Then exit blender and restart. Texture will be gone.
I’ve been experimenting with libload, and that seems to be the way to go, but it’s far from perfect. And I have to use 2.71, cause it’s broken in 2.75.
I can say that, using a lot of materials didn’t seem to slow down my weak computers. My games have probably way too many textures, but all my games will run on a cheap $400.00 pc. It’s large textures that bogged my weak PCs down. As soon as that large texture was in the cameras frustrum, the FPS drops. Maybe it’s different for other PC’s, or a driver issue. IDK
I have over 1100 blends, each with its own chunk of terrain, and I need a solution to avoid a massive memory leak.
Why do you have so many blends with mesh?
I use one mesh (or 6 for LOD) for the terrain and I ‘bake’ specific heigtmaps into bit strings. Then I use libnew to add new terrain and the heighmaps to shape it. And place mesh for the nearest terrain (for physics). I have one material per terrain type, so on a specific area, I only need 1 set of planes. I’m not sure if LibNew duplicates the material though.
you can use 1 material for all land, and shift uv’s ?
use a terrain atlas?
This is more or less just a design choice. In order to really represent to terrain the way I have in mind, I needed quite a few terrain chunks. Each chunk resides in its own blend at the moment, but after I hit alpha release I will be optimizing quite a bit.