Enabled / Disable auxiliary state performance.

[sebastian.vesenmayer]

Hello,

we did observe that when we are changing the material of an ObjectMeshStatic, it will lose its auxiliary state information during runtime.

We are using the aux buffer for outlining objects, but changing the material will disable the outlining.

We did a workarround for this and did restoring the auxiliary state when the material changes.

We did a profile run and did observe: restoring the auxiliary state takes always a lot of time until the function will return. So every time a material changes on an object the application halts for a noticeable time.

Do you have a simple solution for that, that does not cost any extra ressources and time on CPU/GPU side? We are on 2.8 Unigine version using opengl.

Thanks a lot.

Edited January 27, 2020 by sebastian.vesenmayer

[morbid]

Hello Sebastian,

Changing material state in the runtime is an expensive operation that causes shader cache recompilation, it can't be optimized.

Do you mean that originally you had two materials, one with Aux State enabled and the other without? And setting the aux material to a mesh it did not cause auxiliary buffer update?

Thanks.

[sebastian.vesenmayer]

Hi morbid,

I did only implement this feature like in the example from Unigine SDK, is it possible to set auxiliary state directly on the material and not the mesh? I cannot find any documentation on this.

So setMaterialState will inherit the material which is set , sets the states and recompiles the shader?

Because when I switch back to the material where auxiliary state was set over the ObjectMesh at the beginning the auxiliary state information is lost then.

When I set the auxiliary state again it will write to the auxiliary buffer again, but well this takes time.

So what you mean is that I need an extra auxiliary material to get this working smooth?

Thank you.

[morbid]

36 minutes ago, sebastian.vesenmayer said:

I did only implement this feature like in the example from Unigine SDK, is it possible to set auxiliary state directly on the material and not the mesh? I cannot find any documentation on this.

Sorry, could you please clarify which example you're referring to?

35 minutes ago, sebastian.vesenmayer said:

So what you mean is that I need an extra auxiliary material to get this working smooth?

Yes, if you need a faster state switch prepare two materials and change them in runtime.

[sebastian.vesenmayer]

6 minutes ago, morbid said:

Sorry, could you please clarify which example you're referring to?

UnigineScript/Shaders/post_selection_00.cpp

[silent]

Sebastian,

In this sample setMaterialState is called just for a demonstration. I think that's highly unlikely that in real-world application you will need the random objects glowing. We will think how to re-write it to be more production-use ready.

However, I can't see any issues in that particular sample that will cause application freeze for a seconds. My guess that you have shader recompile each time you change state (you can get more detailed picture in microprofile), so in theory if you can pre-compile all the shaders before running application switching states should be much faster.

I also can't understand the following statement completely:

Quote

We are using the aux buffer for outlining objects, but changing the material will disable the outlining.

By default in mesh_base material most of the states are disabled, so you need to inherit from mesh_base and enable aux state in the inherited material (to invoke shader recompile) on application startup or even in Editor. After that when you will inherit from a new material it will have aux state enabled by default, so you don't need to wait or write some additional code to handle this case.

Thanks!

[sebastian.vesenmayer]

Hi silent,

4 hours ago, silent said:

In this sample setMaterialState is called just for a demonstration. I think that's highly unlikely that in real-world application you will need the random objects glowing. We will think how to re-write it to be more production-use ready.

Yes I build it like this because it was demonstrated like that. :) It would be less confusing when material states won't be set on objectMesh and instead on the material. The user cannot know what is happening there or if the state is part of the material or the objectMesh.

4 hours ago, silent said:

However, I can't see any issues in that particular sample that will cause application freeze for a seconds. My guess that you have shader recompile each time you change state (you can get more detailed picture in microprofile), so in theory if you can pre-compile all the shaders before running application switching states should be much faster.

You can try this in your selection example and you will get a noticeable lag with opengl.

int update() {
    interval -=1;

	if(interval<=0)
	interval += 60;

	if(interval==60)
	{
		for(int i=0;i<meshes.size();i++)
		{
			meshes[i].setMaterialState("auxiliary",0,0);
			meshes[i].setMaterialParameter("auxiliary_color",vec4_one,0);
		}
	}
	if(interval==30)
	{
		for(int i=0;i<meshes.size();i++)
		{
			meshes[i].setMaterialState("auxiliary",1,0);
			meshes[i].setMaterialParameter("auxiliary_color",engine.game.getRandom(vec4(0.0f),vec4(1.0f,1.0f,1.0f,0.0f)),0);
		}
	}
	return 1;
}

 

4 hours ago, silent said:

By default in mesh_base material most of the states are disabled, so you need to inherit from mesh_base and enable aux state in the inherited material (to invoke shader recompile) on application startup or even in Editor. After that when you will inherit from a new material it will have aux state enabled by default, so you don't need to wait or write some additional code to handle this case.

Yes I understand that, but I don't want many materials drawing into the auxiliary buffer, because it costs gpu time and is not for free.

I will let you know when i get this fixed.

Thanks

 

[silent]

2 hours ago, sebastian.vesenmayer said:

You can try this in your selection example and you will get a noticeable lag with opengl.

That's actually our old friend (buffer creation spike with OpenGL), not a shader generation.

We improved buffer allocation times in 2.10 SDK update with OpenGL:

Unfortunately, we can't get rid of this kind of spikes completely due to API limitations.