awesome! not only did I learn about this custom primitive data i didn't know about before, I learned how to count drawcalls in the scene! thanks! I always thought instance materials saved on drawcalls I guess not~
Perhaps you were thinking of instanced static meshes, which do save draw calls. But no, dynamic material instances do not save draw calls... they just give you the ability to drive material parameters at run time, but at the cost of creating another material instance (which requires it's own draw call).
I've seen the instance static meshes, but never fully tried them, I assume that's how foliage works. can you make instance static meshes with different custom primitive data?
ahh good to know thanks! maybe the perinstancerandom or perinstancecustomdata node I saw could override individual mesh instance material settings without the extra draw calls?
@@YuuJer Oh wow, looks like you can do that. I haven't tried it myself but UInstancedStaticMeshComponent::SetCustomDataValue looks like it does allow you to specify per static mesh instance custom data. Interesting.
Hello mate I've shared materials with many meshes, so when I using one of these materials in a different meshes I don't want redundancy of draw calls in each mesh, so I want to be at same draw call of all meshes that using the same selected materials. For Example: I've 2 different meshes the first mesh using 23 materials and the second mesh using 35 materials, the draw calls will be 58 and I don't want this number I want 35 draw calls. is there any solution for this problem? can Custom Primitive Data helps me?
No, Custom Primitive Data will not help. Each specific material will have at least 1 draw call. That includes every material instance of a material. To go into it a bit more, consider the following examples. Case 1: Assume your 35 materials are all material instances of a single parent material, each with a float or vector parameter different for each instance. You may think "hey, I can combine these into a single material and feed the unique float/vector for each material using Custom Primitive Data." However, you cannot do this because the Custom Primitive Data is the same for all materials on that primitive (i.e., on that Static Mesh), so there will be no way to give each part of your material a custom data value. Case 2: Suppose the 35 materials are all completely different (not even instances of a parent material). In this case, each material is going to need it's own draw call. Custom Primitive Data only helps reduce draw calls when you want to provide a custom value PER PRIMITIVE (e.g., per Static Mesh Component). This allows you to reduce draw calls and provide some variation between Static Mesh Components sharing the same material, but that is the only case it helps in.
@@walidalhajyousef4865 Both HISM and ISM only help if you have several instances of a mesh. If your 2 different meshes are used many times in your scene, then ISM could help. If you used ISM, instead of having N * 35 draw calls (where N is the number of instances in your scene) you could just have 35 draw calls instead (assuming you have a single Instanced Static Mesh component for all instances in your scene).
You need to call Set Custom Primitive Data Vector 3 on each PrimitiveComponent. See 4:06 in the video for an example of this. UE4 documentation here: docs.unrealengine.com/en-US/BlueprintAPI/Rendering/Material/SetCustomPrimitiveDataVector3/index.html
When does this come in useful? Reducing draw calls is great for sure, but games use textures a majority of the time. Is there a similar method that doesn't use dynamic material instances like this, but for actual texture data?
For anyone coming here in the future, I believe the node that's needed for construction to working correctly is "Set DEFAULT Custom Primitive Data V3"
awesome! not only did I learn about this custom primitive data i didn't know about before, I learned how to count drawcalls in the scene! thanks!
I always thought instance materials saved on drawcalls I guess not~
Perhaps you were thinking of instanced static meshes, which do save draw calls. But no, dynamic material instances do not save draw calls... they just give you the ability to drive material parameters at run time, but at the cost of creating another material instance (which requires it's own draw call).
I've seen the instance static meshes, but never fully tried them, I assume that's how foliage works. can you make instance static meshes with different custom primitive data?
@@YuuJer You can put the custom primitive data on the entire instanced static mesh component, but not on each individual mesh instance.
ahh good to know thanks! maybe the perinstancerandom or perinstancecustomdata node I saw could override individual mesh instance material settings without the extra draw calls?
@@YuuJer Oh wow, looks like you can do that. I haven't tried it myself but UInstancedStaticMeshComponent::SetCustomDataValue looks like it does allow you to specify per static mesh instance custom data. Interesting.
Hey Doug, great video. Do you know if this can be used on mesh particles in Niagara ?
I don't know, though I would guess no. If you find out will you let me know?
any way to make this work with HLODs , mesh instancing, or packed level actors?
Very useful video, Thank you.
you're welcome!
Thanks!
how can i Get the value within a certain index of custom primitive data?
Hello mate I've shared materials with many meshes, so when I using one of these materials in a different meshes I don't want redundancy of draw calls in each mesh, so I want to be at same draw call of all meshes that using the same selected materials.
For Example: I've 2 different meshes the first mesh using 23 materials and the second mesh using 35 materials, the draw calls will be 58 and I don't want this number I want 35 draw calls. is there any solution for this problem? can Custom Primitive Data helps me?
No, Custom Primitive Data will not help. Each specific material will have at least 1 draw call. That includes every material instance of a material. To go into it a bit more, consider the following examples.
Case 1: Assume your 35 materials are all material instances of a single parent material, each with a float or vector parameter different for each instance. You may think "hey, I can combine these into a single material and feed the unique float/vector for each material using Custom Primitive Data." However, you cannot do this because the Custom Primitive Data is the same for all materials on that primitive (i.e., on that Static Mesh), so there will be no way to give each part of your material a custom data value.
Case 2: Suppose the 35 materials are all completely different (not even instances of a parent material). In this case, each material is going to need it's own draw call.
Custom Primitive Data only helps reduce draw calls when you want to provide a custom value PER PRIMITIVE (e.g., per Static Mesh Component). This allows you to reduce draw calls and provide some variation between Static Mesh Components sharing the same material, but that is the only case it helps in.
@@doug_richardson ohh okay thanks for helping
@@walidalhajyousef4865 Both HISM and ISM only help if you have several instances of a mesh. If your 2 different meshes are used many times in your scene, then ISM could help. If you used ISM, instead of having N * 35 draw calls (where N is the number of instances in your scene) you could just have 35 draw calls instead (assuming you have a single Instanced Static Mesh component for all instances in your scene).
How difficult to implement the custom data per instance?
You need to call Set Custom Primitive Data Vector 3 on each PrimitiveComponent. See 4:06 in the video for an example of this. UE4 documentation here: docs.unrealengine.com/en-US/BlueprintAPI/Rendering/Material/SetCustomPrimitiveDataVector3/index.html
thanks
you're welcome!
When does this come in useful? Reducing draw calls is great for sure, but games use textures a majority of the time. Is there a similar method that doesn't use dynamic material instances like this, but for actual texture data?
It's useful anytime you want a per-primitive value. Textures aren't per primitive.
@@doug_richardson Thanks for responding, suppose we'll just have to stick with dynamic material instances then