Ogre Forums

peteb wrote:One issue is that some functions have been dropped from the Material class and it is not clear what replaces them (in fact this is a general pattern I have observed here).

That way, searching the source code for the missing function would reveal some pointers as to how to deal with its loss. When your main goal is just to get the application to compile before dealing with all the semantic/assertion/exception/visual breakages, this would have been extremely useful and saved me (and probably others) hours.

I think looking at the porting guide I need to use blend blocks to set up scene blending etc and other blocks for culling.

pass->setDepthCheck( ... );
pass->setDepthWrite( ... );
pass->setCullMode( ... );
//etc...

HlmsMacroblock macroblock = pass->getMacroblock(); //Retrieve existing settings and make a hard copy.
macroblock.mDepthCheck = ...;
macroblock.mDepthWrite = ...;
macroblock.mCullMode = ...;
pass->setMacroblock( macroblock );

But that is not initially easy to find if you do not have a fuller understanding of Hlms first. I take it that the old materials somehow actually use Hlms under the hood? Why do they only work in V1_LEGACY RenderQueue if they must use macroblocks etc for blending modes? Or is th eporting guide out of date in this area?

The other issue is existing materials that are not under my control. Existing users of the application have imported models (boats / ROVs / Wind Turbines etc) themselves that are persisted on disk and will have legacy style material scripts and mesh files. This results in Ogre throwing an exception when loading as the materials end up being FFP based.

I also see that cg support was dropped? All of my scripts use cg... It is kind of nice only having to write the shader once instead of separate GLSL and HLSL scripts.. But I do see that there is hlsl2glsl which may reduce the pain of this.

It would help if you describe which functionality you feel is not clear about what replaces it.

peteb wrote:Is it possible to do multi-pass materials in Hlms?

These materials have to be manually ported over to Hlms PBS materials. We discussed several ways of automating the process but it's nearly impossible. The old system was extremely flexible, too flexible, and thus there is no convention.
Is the 1st texture unit a diffuse map? the 2nd TU a normal map? a displacement map? Maybe normal maps are on the 5th texture unit? Which textures should apply gamma correction? which shouldn't? How do we map the shininess value from FFP which used gouraud shading to something meaningful in Cook Torrance or GGX?

peteb wrote: Why should gouroud shading be mapped to Cook-Torrance? You would want existing materials to look the same as they did before as far as possible and then upgrade as required.

peteb wrote: Not a single one of my materials work. I couldn't get the old material system to work whatsoever (objects just don't show up - but maybe I made some mistake). I started moving a couple of the more simple ones over to Hlms but still don't have a great mental model of the system - more examples would be great as searching documentation is not all that fruitful.

void GraphicsManager::createHlmsFromMaterial(const Ogre::String materialName)
{
	//load the material
	Ogre::MaterialPtr mat = Ogre::MaterialManager::getSingleton().getByName(materialName);

	//check datablock does not already exists
	Ogre::HlmsManager* hlmsManager = Ogre::Root::getSingleton().getHlmsManager();
	Ogre::HlmsDatablock* block = hlmsManager->getDatablockNoDefault(materialName);
	if (block == NULL)
	{
		if (mat.isNull() == false)
		{
			Ogre::HlmsPbs* hlmsPbs = dynamic_cast<Ogre::HlmsPbs*>(Ogre::Root::getSingleton().getHlmsManager()->getHlms(Ogre::HLMS_PBS));
			Ogre::HlmsPbsDatablock *datablock = static_cast<Ogre::HlmsPbsDatablock*>(
				hlmsPbs->createDatablock(materialName,
				materialName,
				Ogre::HlmsMacroblock(),
				Ogre::HlmsBlendblock(),
				Ogre::HlmsParamVec()));

			datablock->setSpecular(Ogre::Vector3(0.2));
			datablock->setRoughness(0.8);
			datablock->setFresnel(Ogre::Vector3(0.015), false);
			
			Ogre::Technique* matTech = mat->getBestTechnique();

			if (matTech == NULL)
			{
				//if best technique is not valid just grab the first one
				Ogre::Material::TechniqueIterator techItr = mat->getTechniqueIterator();
				if (techItr.hasMoreElements())
				{
					matTech = techItr.getNext();
				}
			}

			if (matTech)
			{
				Ogre::Technique::PassIterator passItr = matTech->getPassIterator();
				while (passItr.hasMoreElements())
				{
					//itterate through all defined textures in this pass. Currently assume they are all the diffuse texture
					Ogre::Pass::TextureUnitStateIterator texItr = passItr.getNext()->getTextureUnitStateIterator();
					while (texItr.hasMoreElements())
					{
						Ogre::TextureUnitState* tex = texItr.getNext();
						Ogre::HlmsTextureManager::TextureLocation texLoc = hlmsManager->getTextureManager()->createOrRetrieveTexture(tex->getFrameTextureName(0), Ogre::HlmsTextureManager::TEXTURE_TYPE_DIFFUSE);
						datablock->setTexture(Ogre::PBSM_DIFFUSE, texLoc.xIdx, texLoc.texture);
					}
				}
			}
		}
	}
}

peteb wrote: An extremely common use case will be using completely custom pixel shaders for special effects - i.e. not using the unlit or pbs scripts. As far as I can see this is going to require even more boilerplate code than the old materials system when using HLMS (you have to write a module like PBS or Unlit?).

With a couple of assumptions I converted many of my materials from 1.x to 2.1 on the fly with the following code.

Yes and this is why Ogre 1.x materials still exists in the form of Low_Level_Materials and have their own HLMS implementations.

peteb wrote:Ok - what I don't really get is why low level materials are only allowed in V1_LEGACY render queues (going by the porting guide)? Seems that using custom pixelshaders is hardly a legacy thing - PBS will not fit every requirement. Is this just because of the way that uniforms are dealt with?

peteb wrote:Seems that using custom pixelshaders is hardly a legacy thing - PBS will not fit every requirement. Is this just because of the way that uniforms are dealt with?

• If by custom pixel shaders you mean run a special shader for a particular artistic look (i.e. toon shading, other non-photorealistic rendering, debug view) then a custom Hlms implementation is the key to achieving both a shader that gets that look, can adapt to any object and runs fast. Creating a custom Hlms implementation is actually easy but like you said without a tutorial it looks intimidating and certainly having as reference complex implementations like PBS doesn't make it easier at all (I'd suggest taking a look at Unlit which is much simpler, but still it's not very tutorial friendly). The old material system was very good for quickly prototyping a shader that ran well in one mesh, but the system failed to make it easy to scale this shader widespread use with multiple meshes (what do you do if there's no normals? if there's more than 1 UV set? what about shadow casting? what do you do during depth only render passes? how do you deal with different setting permutations? what do you do if it's skeletally animated? etc)
• If by custom pixel shaders you mean run a customization on top of our implementations (ie. to add a particular feature, such as tree wind in the vertex shader), then we offer a C++ listener and template blocks for modular adding features to our Hlms implementations.
• If by custom pixel shaders you mean run a particular shader for a few objects then low level materials are still suited for that. Particularly for post-processing, but can also be used for rendering with other objects. That's why in the 2.1-pso we've improved support so you can use it with other modes. But note that trying to use these shaders with many Items or Entities will cripple performance. Flexibility to do anything you want in any moment to potentially any object without any sort of preparation, caching or precomputation comes at a price.

1. RTSS tried. And many of its bugs, high complexity & crashes are because the FFP restricts what the implementation should do and how it should work. By ditching the "FFP look", we were free to being the ones who impose the restrictions, instead of being the ones whose restrictions are imposed onto us.
2. It looks outdated. PBS achieves the same basic goal (show something on screen with textures and illumination) and looks much better.
3. Maintaining an FFP implementation consumes time and resources we don't have, and the benefits are marginal when nearly everyone will be using PBS.

Wathiant wrote: Wed Aug 21, 2019 10:30 am Just a simple example with a single "this is the 1.x material file" and "this is the equivalent 2.1 material definition" would be really helpful as I'm using fairly basic stuff.

{
	"samplers" :
   {
        "unique_name" :
        {
            "min" : "anisotropic",
            "mag" : "anisotropic",
            "mip" : "anisotropic",
            "u" : "wrap",
            "v" : "wrap",
            "w" : "wrap",
            "miplodbias" : 0,
            "max_anisotropic" : 8,
            "compare_function" : "disabled",
            "border" : [ 1, 1, 1, 1 ],
            "min_lod" : -3.40282347E+38,
            "max_lod" : 3.40282347E+38
        }
    },

    "macroblocks" :
    {
        "unique_name" :
        {
            "scissor_test" : false,
            "depth_check" : true,
            "depth_write" : false,
            "depth_function" : "less_equal",
            "depth_bias_constant" : 0,
            "depth_bias_slope_scale" : 0,
            "cull_mode" : "disabled",
            "polygon_mode" : "solid"
        }
    },

    "blendblocks" :
    {
        "add" :
        {
            "alpha_to_coverage" : false,
            "blendmask" : "rgba",
            "separate_blend" : false,
            "src_blend_factor" : "one",
            "dst_blend_factor" : "one",
            "src_alpha_blend_factor" : "one",
            "dst_alpha_blend_factor" : "one",
            "blend_operation" : "add",
            "blend_operation_alpha" : "add"
        }
    },
	
    "unlit" :
    {
        "myMaterialName" :
        {
	        "macroblock" : "unique_name",
			"blendblock" : "add",
			
			"diffuse" : [10, 10, 10],
			
			"diffuse_map0" :
            {
               	"sampler" : "unique_name",
				"texture" : "my_texture.dds"
            }
        }
	}
}