3
$\begingroup$

I have several blend files with models in them. Each of these blend files use a common texture. Each of the blend files are linked into a Blend file with an environment in it.

When I render this environment - is the texture loaded into memory once, or several times?

If im using GPU rendering then the number of textures has to be efficient. If it loads the same texture multiple times I will have to append the objects into the environment rather than link them.

I'm using Cycles.

Thanks. Oliver

$\endgroup$
2
$\begingroup$

It should be fairly easy to test whether the objects are sharing the texture or not since you are using GPU rendering and the number of available textures that can be used is fairly low.

On this Blender Wiki page, http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/GPU_Rendering , it lists how many textures you can use before failure should occur.

Now do a simple test by Linking a number of objects that is higher than the number of allowed textures.
If everything renders fine then you can be satisfied that the textures are shared.

Also, if you look at the area that is circled in the next image you will see a number '2'. That indicates how many users of the texture there are.

I would not rely on software info to report this accurately for what you are doing.

Stress testing is really the only way to make sure the hardware can do what you expect from the software.

I tested both Link and Append using the following method. I added a 4096x4096 texture to two simple models and then added them to a group. I added a sphere with a hair particle system and added the 'crystal group'. The number of instances was set to 150.

Next the Particle system modifier was Applied and the scene saved.

enter image description here

Now I shut down Blender to make sure everything was cleared out and used Append to load in all the separate objects, (including the two originals)

By clicking on several of them individually, I checked the Materials texture node for the number of users and also to verify that there was not a tex.001, tex.002, tex.003, etc. There did not appear to be any redundant textures weirdness either in the nodes or the image editor drop-down. Only 2 users were reported for the texture node which looked the same for every model.

I now shut down Blender and restarted using a blank scene and this time used Link to load in a the models. The results were exactly the same, all the objects were sharing the texture and only 2 users were reported by the texture node. The second user is presumably due to the original crystal models that were also loaded in.

I also watched the OS's memory usage utility to see how much the system memory climbed for both tests. It was very reasonable so it's fairly certain that there were not 152 4096x4096 textures being loaded. I'm sure that would have shown as a dramatic climb in memory usage.

The shared .png file is about 8.3MB on disk(compressed) and the total RAM usage for Blender was reported to be about 230MB. When I started the Cycles Render it hovered around 400-500MB.
If the texture was being duplicated within Blender I'd expect the memory usage to be much higher.

I can't test using a CUDA enabled device since I don't own one but this looks promising for the use that you describe. I suppose next you could test to see what happens when the objects all have separate materials.

$\endgroup$
  • $\begingroup$ Fairly easy to link 100+ objects from different files? more details on limitations : blender.org/manual/render/cycles/gpu_rendering.html#limitations $\endgroup$ – Bithur Mar 8 '15 at 18:06
  • $\begingroup$ linking the same object 150 times isn't going to be difficult. $\endgroup$ – MarcClintDion Mar 8 '15 at 19:46
  • $\begingroup$ but the same object won't test anything but duplicates/linked duplicates $\endgroup$ – Bithur Mar 8 '15 at 19:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.