Ogre 2.1 mesh loading: Couldn't apply datablock to this renderable

[tct]

Ogre Version: 2.1
Operating System: Windows, Linux
Render System: OpenGL 3+
Blender Version: 2.8

I've created a simple textured cube in Blender 2.80 and created the corresponding *.mesh and *.material file(s) using the blender2ogre exported.
I use the following code to attempt loading my Blender exported model:

Code: Select all

Ogre::MeshManager& meshMgr = Ogre::MeshManager::getSingleton();
Ogre::MeshPtr mesh = meshMgr.create("cube.mesh", "General");//Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME);
Ogre::Item* item = sceneManager->createItem(mesh);

The corresponding *.mesh and *.material files are located in a resource directory that OGRE is aware of. I've attached them for your reference.

Running this I get:

Code: Select all

Mesh: Loading cube.mesh.
Corrupted chunk detected! Stream name: 'cube.mesh' Chunk id: 36864
OGRE EXCEPTION(3:RenderingAPIException): Fixed Function pipeline is no longer allowed nor supported. The material Materi
al must use shaders in HlmsLowLevel::calculateHashFor at C:\Users\joel\Documents\projects\ogre-next-2.1\OgreMain\src\Ogr
eHlmsLowLevel.cpp (line 154)
Compiler error: unknown error in Material.material(18): token "normalise_normals" is not recognized
Compiler error: unknown error in Material.material(23): token "transparent_sorting" is not recognized
Couldn't apply datablock '[Value 0x00000005]' to this renderable. Using default one. Check previous log messages to see
if there's more information.

I've manually removed the normalise_normals and transparent_sorting from the *.material file and retried:

Code: Select all

Mesh: Loading cube.mesh.
Corrupted chunk detected! Stream name: 'cube.mesh' Chunk id: 36864
OGRE EXCEPTION(3:RenderingAPIException): Fixed Function pipeline is no longer allowed nor supported. The material Materi
al must use shaders in HlmsLowLevel::calculateHashFor at C:\Users\joel\Documents\projects\ogre-next-2.1\OgreMain\src\Ogr
eHlmsLowLevel.cpp (line 154)
Couldn't apply datablock '[Value 0x00000005]' to this renderable. Using default one. Check previous log messages to see
if there's more information.

I'm not sure about how serious the corrupted chunk is. But what I know is that I am trying for days to load a simple model into Ogre 2.1 and it always end in this message:

Code: Select all

Couldn't apply datablock '[Value 0x00000005]' to this renderable. Using default one. Check previous log messages to see
if there's more information.

I tried to find information on this in the documentation, the forum as well as by looking at the source code. However, I couldn't manage to figure out what causes this issue and what I am doing wrong.

Could somebody please shine some light on this?

[Lax]

Hi tct,

you cannot use material files since Ogre 2.x anymore. You need to use hlms or *.json files. Take a look inside the media folder e.g.

"..\2.0\scripts\materials\PbsMaterials\PbsMaterials.material"

Code: Select all

hlms Rocks pbs
{
	roughness	0.4
	fresnel		1.33
	
	diffuse_map		Rocks_Diffuse.tga
	normal_map		Rocks_Normal.tga
	roughness_map	Rocks_Spec.tga
	specular_map	Rocks_Diffuse.tga
}

Or even better for more performance create a file: "yourMaterial.material.json":

Code: Select all

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

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

	"blendblocks" :
	{
		"Objects_Blendblock_0" :
		{
			"alpha_to_coverage" : false,
			"blendmask" : "rgba",
			"separate_blend" : false,
			"src_blend_factor" : "one",
			"dst_blend_factor" : "zero",
			"blend_operation" : "add"
		}
	},

	"pbs" : 
	{

		"Material/SOLID/TEX/Case3.png" :
		{
			"macroblock" : "Objects_Macroblock_0",
			"blendblock" : "Objects_Blendblock_0",
			"shadow_const_bias" : 0.01,
			"workflow" : "specular_ogre",
			"brdf" : "blinn_phong",
			"diffuse" :
			{
				"value" : [1, 1, 1],
				"background" : [1, 1, 1, 1],
				"texture" : "Case3D.png",
				"sampler" : "Objects_Sampler_5"
			},
			"specular" :
			{
				"value" : [1, 1, 1],
				"texture" : "case3S.png",
				"sampler" : "Objects_Sampler_5"
			},
			"fresnel" :
			{
				"value" : 0.1,
				"mode" : "coeff"
			},
			"normal" :
			{
				"value" : 0.5,
				"texture" : "Case3N.png",
				"sampler" : "Objects_Sampler_5"
			},
			"roughness" :
			{
				"value" : 0.22,
				"texture" : "Case3R.png",
				"sampler" : "Objects_Sampler_5"
			}
		},
		
		"Material/SOLID/TEX/plattform2.png" :
		{
			"macroblock" : "Objects_Macroblock_0",
			"blendblock" : "Objects_Blendblock_0",
			"shadow_const_bias" : 0.01,
			"workflow" : "specular_fresnel",
			"brdf" : "cook_torrance",
			"diffuse" :
			{
				"value" : [3.14, 3.14, 3.14],
				"background" : [1, 1, 1, 1],
				"texture" : "plattform2D.png",
				"sampler" : "Objects_Sampler_5"
			},
			"specular" :
			{
				"value" : [0.1, 0.1, 0.1]
			},
			"fresnel" :
			{
				"value" : 0.1,
				"mode" : "coeff"
			},
			"normal" :
			{
				"value" : 1,
				"texture" : "plattform2N.png",
				"sampler" : "Objects_Sampler_5"
			},
			"roughness" :
			{
				"value" : 0.09
			}
		}
	}
}

Note: You can collect many datablocks in one json file. "Objects_Sampler_5" is just an example and should be uniquely named in different json files.

See also: http://wiki.ogre3d.org/HLMS+Materials

Best Regards
Lax

[tct]

Thank you very much for your answer - it already clarifies a lot.

One question tho: When I create a JSON file for texturing my cube based on the JSON example you provide - how do I actually assign the material (?) to my loaded mesh? I assume I use setDatablock()? What parameter(s) do I pass to make use of the JSON?

Please excuse these beginner questions - I'm just having a hard time figuring out what the intended way of using Ogre 2.1 is. Documentation seems very scarce at this point - or at least simply insufficient for somebody with C++ but no previous Ogre experience.

[dark_sylinc]

One question tho: When I create a JSON file for texturing my cube based on the JSON example you provide - how do I actually assign the material (?) to my loaded mesh? I assume I use setDatablock()? What parameter(s) do I pass to make use of the JSON?

There's 3 ways:

1. The material name is embedded in the .mesh file. This gets assigned automatically on creation (unless the material couldn't be found, i.e. it doesn't exist; in which case we use a default grey one). The material name in the mesh file was written by the exporter. Usually exporters use the material name that was assigned in the original modelling tool (e.g. Blender)
2. Via C++, using Renderable::setDatablockOrMaterialName. e.g. you can call item->getSubItem( i )->setDatablockOrMaterialName( ... ); Alternatively you can also use setDatablock if you're certain the material is an Hlms datablock (you can think of datablocks as synonym for materials, but the class 'Material' refers to the 1.x interface aka low level materials in the documentation. Since it was already taken, we use 'datablock' instead to refer to the newer material system)
3. Via C++ using Item::setDatablockOrMaterialName. This is the same as calling item->getSubItem( i )->setDatablockOrMaterialName for all subitems with the same datablock/material name. It's just more convenient if you know all the subitems use the same material or if you know there is just only one subitem

Please excuse these beginner questions - I'm just having a hard time figuring out what the intended way of using Ogre 2.1 is. Documentation seems very scarce at this point - or at least simply insufficient for somebody with C++ but no previous Ogre experience.

No problem. It was recently brought to my attention that indeed our documentation assumes Ogre users come from a 1.x background. We spend a lot of time ensuring porting documentation was thorough that we overlooked new users.

In case you haven't seen it already, you may wanna also look:

• Manual
• Ogre 2.1 FAQ

Cheers

[tct]

Thank you very much for your answer.
Things are clearing up a lot!

The TL;DR of everything below: In my personal opinion, Ogre (2.1+) is a fantastic piece of software but the usability is heavily crippled by very low accessibility to new users (documentation, examples).

No problem. It was recently brought to my attention that indeed our documentation assumes Ogre users come from a 1.x background. We spend a lot of time ensuring porting documentation was thorough that we overlooked new users.

This is exactly the experience I'm having. As far as I can tell Ogre 2 is a fantastic piece of software engineering that is very rewarding to work with - once you get things up and running. There are features in there - such as the HLMS - that are simply impressive and were also the reason why we decided to work with Ogre in a small proof-of-concept prototype project. However, even just understanding what these different techniques do, how they relate, which are deprecated, which are outdated, which are recommended to use and really just getting an overall overview of how a developer would tackle building an application using Ogre has been a painful undertaking.

I'm an embedded C++ developer with a small background in reverse engineering - I have no idea how an average C++ developer is going to get Ogre (2.1) up and running to get something nice done. I think you guys have an excellent product that could be a star in the sky just as bright as Unreal & Unity - especially for the more software engineers driven endeavors - but the lack of documentation to just get things to work might repell a lot of potential users.

In my personal opinion the most crucial parts to cover by an upgraded documentation would be:

• Clarify versioning: The existing "What version to choose?" section on the homepage is step in the right direction. However, once past this there's a lot of confusion that arise as a new user startes to get things working. For example, the following things threw me off and it was hard for me to find any concrete, easy to verify, information:
  • What is the relationship between Ogre 1 and 2? Sure, the website gives the overall information but what's the state of support? According to the documentation Ogre 2.1 is considered stable - yet there's still Ogre 1 that appears to have independent development and the occasional backports.
  • What's the relationship between Ogre 2.1 and 2.2?
  • Should a new application - that based on the website decided to use Ogre 2 (aka ogre-next) use 2.1 or 2.2?
• Present an overall architecture of the system that shows all the core components to the developer and quickly explains what those do. Over at uGFX we did it like this: µGFX Architecture.
  From there, simply have links to the top-level documentation of each component. Important to note: A diagram is going to get a new user a long way! There's no need for an overly correct (and croweded) UML diagram - just something simple. Explain the basic concepts: What is a Compositor? What is a Workspace? What is a Node? What is Hlms? How do they interact together? This section should also give the user a fairly good overview of what's actually necessary to get something basic up & running and what is just nice to have fancy-ness for a second stage when there's actually a running application.
• A clear minimal example documentation: Create a section in the manual that explains how to setup a simple Ogre application to the point where the user gets a window with a black background and some cube rendered in the middle. This is an extremely rewarding experience for a new user. As of right now, there is no other way for a new user other than digging through the code samples which might not be very easy to understand for somebody with less software engineering background as they are not necessarily usable as "standalone minimum examples". Interestingly enough, the Ogre 1 manual has such a guide (and even a fairly good one!): https://ogrecave.github.io/ogre/api/lat ... scene.html This (and as a matter of fact the entire Tutorials section of the Ogre 1 manual needs to be ported to the Ogre 2 manual immediately.
• Clarify which parts of the software are actually deprecated: Again the same overall problem here: The software engineering part is very nicely done with the v1 namespace. Furthermore, there's a very good migration/porting guide for people coming from Ogre 1. The documentation shows how to achieve things both with the old v1 API as well as the new one. Problems start showing up once working with external tools such as blender2ogre and others which start providing misleading & confusing information as to what the expected workflow is. Together with a dozen forum posts there was a big cloud of uncertainty on whether using the v1 API is actually preferred for a new application as well or whether that is really just for easier porting. A lot of forum posts, blog posts, 3rd party tool readmes etc. imply somewhat contradicting information on this. There's no surprise: After all you're researching something using a web search engine. The real problem is that in my opinion there's no official documentation that would clarify this.
• Keep documentation up to date: This might sound trivial but of course it's not. The manual itself seems to do a good enough job here but the wiki... There are articles clearly marked as outdated with a link to another source - which by now is outdated as well and has been superseeded by new things that are nowhere mentioned other than deep in the manual without the necessary background information to understand that this is even what the user is looking for. I'm very aware of how much efforts it is to keep a community wiki maintained but if you don't put that work into it you end up in exactly this situation: An excellent product that simply put nobody uses. One of the easiest improvements: Force fields for information such as which Ogre version the article concerns and extend those fields for articles talking about plugins etc. This way it's at least clear to somebody coming across an article that this works with the specific version combination even though the underlying software is outdated.
  A good example of this: It seems that developers go through quite a bit of effort to back-port features to Ogre 1. Based on the information I find it seems that the HLMS together with PBS capabilities have been back-ported to Ogre 1. Yet the website would suggest that PBS is only available in Ogre 2.
• Demonstrate asset handling workflows: I lost a substantial amount of time finding an asset workflow that actually work. I know - everybody is gonna have his/her own requirements, different tools & environments to work with and so on. Also, content creators tend to use different tools and for a software engineer it's not always easy to support & document everything but here's my point: The first day I looked at Ogre when considering it for one of our products it seemed very good on the surface:
  • Exporter for Blender
  • Exporter for Maya
  • Exporter for 3DS
  • Various custom tools (eg. "Ogre mesh viewers")
  • Mentioning of lots of separate auxiliary tools - and even some CLI action
  • Corresponding wiki articles have relatively young edit dates
  Here's how reality looked for me after several days of installing different tools, plugins, add-ons etc: Almost everything is outdated and/or partially not even working due to incompatibilities on multiples levels.
  So for the love of god: The official manual should have a section where one or more workflows with common tools are shown in a step-by-step manner. Nobody will blame you for not having a detailed guide on how to do things with Maya, 3DS or other tools but fact is: This is an open source project and so is Blender. Show instructions that clearly list at the beginning which versions of which softwares (tools & add-ons/plugins) were used and simply show how to get a simple textured 3D model exported & rendered into an OGRE application.
  My conclusion after several days of extreme ****: It seems to me that there's no working workflow to work with a tool that is common for artists/content creators (Blender, Maya, 3DS, ...) and simply export from there to a format that can be used in an Ogre 2.1 application without having an intermediate stage and/or converting between v1 and v2 versions - depending on which way you need to go.
  Overall the asset handling/workflows is a very big and important point for any serious application based on Ogre. Even if it doesn't seem like it from the Ogre's developer's perspective this is a make or break situation: Either you have a workflow that allows your content creators/artists to get their assets into the Ogre scene or there's no point in using Ogre at all. In my opinion you absolutely must put time into getting a good overview of what actually works yourself, update the official documentation accordingly and then decide whether more is needed to get more users on this train.
  
  All of this is my own personal two cents. I don't mean to offend anybody here. This is an attempt to provide the perspective of new user to the project maintainers and nothing more. I enjoy the software engineering part of Ogre a lot and it would just be a very sad & shameful event if Ogre would go down simply because lack of documentation.
  I'm the original author & maintainer of the µGFX library which is essentially OGRE but for 2D graphical user interfaces on very resource limited embedded systems. If I look at the examples of Ogre I can fully see that most of the efforts went into making examples for the very fancy advanced features. I fully understand that this is both more interesting and necessary for the developers as they also need some kind of samples / testbenches for a new feature that is being implemented. However: A new user starts at literally zero. There absolutely need to be easy to understand & reproduce examples of how to just render a cube, how to load a texture and so on. Work you way up - but don't skip any steps. There's no point for a new user to look at a fairly well crafted MSAA demo if there's not even a black window on his/her own screen yet.
  Of course it's also very likely that a lot of my personal opinion above is incorrect and that I missed or simply misunderstood pieces of existing documentation.
  This post has been cobbled together over various sessions so please excuse any continuity inconveniences.

[paroj]

Here's how reality looked for me after several days of installing different tools, plugins, add-ons etc: Almost everything is outdated and/or partially not even working due to incompatibilities on multiples levels.

keep in mind that only working with Ogre1 should not be considered outdated. In fact the first bullet point at "What version to choose?" says that you should be prepared that the infrastructure will fail you, if you go with Ogre2.

But now that you brought that up, I tried to reword that page to make it more clear (likely readers dont know what CEGUI is, but can imagine what a GUI solutions is).

[dark_sylinc]

I'm bookmarking this. It's gold.

Btw many of these issues are historical (Ogre is a 20-year old Software after all...) for example on 1.x vs 2.x; originally Ogre 1.x stopped being worked on and 2.x branch was the next generation.

But then some users didn't want to port (1.x was fine for them. Different goals, costs, etc) and started asking or funding more 1.x development. Paroj stepped in and was already doing more 1.x development.

Thus as of today; neither branch can be considered old or deprecated. It's a similar situation to what happened with Python2 and 3. Python3 was supposed to supersede Python2, yet 2.x versions continued being developed further for more than a decade (and it was only EOL'ed this year).

There's no signs of Ogre 1.x or 2.x being EOL'ed any time soon.