Porting to Ogre 2.1 - materials

Discussion area about developing with Ogre2 branches (2.1, 2.2 and beyond)
Post Reply
peteb
Gnoblar
Posts: 17
Joined: Thu Feb 26, 2009 9:05 pm

Porting to Ogre 2.1 - materials

Post by peteb » Tue Nov 01, 2016 2:56 pm

Hi

I'm porting a couple of applications to Ogre 2.1. They are not games.

I've finally got the simpler one of the two compiling and initializing but having / had major issues with materials.

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).

It would be great if the legacy function prototypes could be left in commented out - either in the header files or maybe the cpp files to reduce header bloat. Along with a comment about why it was removed and if there is any replacement...

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.

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.

Subsequently it will crash due to Is there any way to get these to either automatically use the new Hlms material system? Looking around I see there is RTSS which I have not used yet. But it is not clear if this can act automatically?

Really not sure how to deal with that.


Is there any reason that old style materials can't be converted to Hlms?

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.

Would be lovely if there were an example of how to move a material from old to new.
I also can't find any docs on the syntax of hlms material scripts? Is it possible just to generate them in code?
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4066
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 228
Contact:

Re: Porting to Ogre 2.1 - materials

Post by dark_sylinc » Tue Nov 01, 2016 5:18 pm

Hi,
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).
It would help if you describe which functionality you feel is not clear about what replaces it.
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.
That's why we recommend first porting to Ogre 2.0, then to 2.1. You don't have to deal with broken materials in 2.0
Once your program runs ok in 2.0; you can port to 2.1
I think looking at the porting guide I need to use blend blocks to set up scene blending etc and other blocks for culling.
Yes. A lot of state data was moved to Macroblocks and blendblocks to match modern APIs. Leaving functions such as Pass::setDepthCheck & co. was bad because they would have to modify the macroblock, which means retrieving an existing or generating a new macroblock that matches the requested settings.
If you would call:

Code: Select all

pass->setDepthCheck( ... );
pass->setDepthWrite( ... );
pass->setCullMode( ... );
//etc...
In succession, you would end up with O(N^2) behavior.

To solve that you would have to setup the macroblock as can be seen in many of our samples:

Code: Select all

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 old materials are implemented as an Hlms that acts as a proxy/delegate to the old system, hence all the limitations.
In the 2.1-pso branch many of these limitations have been lifted (IIRC you can even use them with Items), but still old materials are only good for a few select use cases, but not for use as a general case.
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.
FFP & RTSS are no longer supported in Ogre 2.1.

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?

If the original developer designed its material system around certain convention of his own making, it should be possible to create a tool to automate the conversion process. But it would only work for his material convention.

The best advice I can give is unfortunately to do the conversion by hand, or write a tool to fit your conventions. But likely a tool will do half of the job as the settings will have to be calibrated, otherwise it likely won't look good.
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.
NVIDIA killed Cg. It stopped working with the more advanced features we started using in Ogre 2.1

Fortunately Cg and HLSL syntax is very similar, sometimes Cg shaders would just compile as HLSL (specially true for Shader Model 3.0; needs a few tweaks for SM 4.0).
You can try hlsl2glsl, or HLSLParser (or try zeux's fork).

Right now we're literally duplicating code. We have some plans for using the Hlms to allow some code sharing, but for the time being options suck.

Regarding how to write your own Hlms shaders: yes, we're lacking a simple tutorial (writing an Hlms implementation is actually very easy, but since all the implementations are complex, it looks hard).
0 x

peteb
Gnoblar
Posts: 17
Joined: Thu Feb 26, 2009 9:05 pm

Re: Porting to Ogre 2.1 - materials

Post by peteb » Tue Nov 01, 2016 7:20 pm

Thank you for the detailed reply!
It would help if you describe which functionality you feel is not clear about what replaces it.
I mean the functions like setCullingMode, setDepthCheck etc. It took me ages to find the one sentence about it in the porting guide! The first time I read through I did not realize the significance as taking in a lot of new stuff.

Is it possible to do multi-pass materials in Hlms?
0 x

hyyou
Gremlin
Posts: 164
Joined: Wed Feb 03, 2016 2:24 am
x 5
Contact:

Re: Porting to Ogre 2.1 - materials

Post by hyyou » Wed Nov 02, 2016 9:02 am

peteb wrote:Is it possible to do multi-pass materials in Hlms?
Unfortunately, no.
You are forced to squeeze every thing into 1 pass (thus better performance), and HLMS provide a very convenient way to do that.

However, no every set of old passes can be squeezed that way.
(except using 2 items to mimic 2 passes which is far more expensive, I guess)
I sometimes also want multi-pass. (sad face)
0 x

peteb
Gnoblar
Posts: 17
Joined: Thu Feb 26, 2009 9:05 pm

Re: Porting to Ogre 2.1 - materials

Post by peteb » Wed Nov 02, 2016 10:36 am

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?
Flexibility was one of the reasons I chose Ogre in the first place!

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.

The objective here is to be able to port an application that uses Ogre 1.9 or 2.0 to Ogre 2.1. It would be good if this process was not going to take weeks to do. I have had to abort my current porting stint as it is taking far too much time.

Since RTSS technology exists already to emulate FFP why not use it for legacy material scripts? Its not like its going to need updating in the future but will help a lot of people out who just want their application to work so they can then gradually move over to Hlms.

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.

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?).
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1200
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 76

Re: Porting to Ogre 2.1 - materials

Post by al2950 » Wed Nov 02, 2016 12:25 pm

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.
Good point, however we have finite time and LOADS of things that are wanted and implementing 'old school' FFP shading will be quite far down the list. However it would be very easy swap out the PBR shading with gouroud shading without having to make your own HLMS.
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.
With a couple of assumptions I converted many of my materials from 1.x to 2.1 on the fly with the following code. (It Basically assumes any texture is the diffuse texture, and sets some sensible defaults for specular and roughness.)

Code: Select all

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);
					}
				}
			}
		}
	}
}
Please note this was only used as a temporary measure, and I have since converted by hand all my materials. Also note this code can be called on all materials HLMS and old ones as it does a check at the top.
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?).
Yes and this is why Ogre 1.x materials still exists in the form of Low_Level_Materials and have their own HLMS implementations. The main difference though is that these materials no longer support FFP and so are only used for custom vertex, geom, pixel, shaders.
0 x

peteb
Gnoblar
Posts: 17
Joined: Thu Feb 26, 2009 9:05 pm

Re: Porting to Ogre 2.1 - materials

Post by peteb » Wed Nov 02, 2016 2:13 pm

With a couple of assumptions I converted many of my materials from 1.x to 2.1 on the fly with the following code.
Thank you for that - looks like it will be useful.

The materials I'm converting are probably pretty simple diffuse textured ones. But since customers can generate things themselves it could be quite open ended.
Yes and this is why Ogre 1.x materials still exists in the form of Low_Level_Materials and have their own HLMS implementations.
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?
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4066
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 228
Contact:

Re: Porting to Ogre 2.1 - materials

Post by dark_sylinc » Thu Nov 03, 2016 5:04 pm

Regarding multipass: I had an argument with another team member regarding this :lol:

While there are certain legit cases for using multipass materials, a lot of multipass techniques can be implemented in a single pass shader (or with different approaches i.e. multipass lighting can be implemented instead via Forward3D, Forward+ or Deferred Shading). Many other multipass techniques can also be implemented as multiple render_scene passes.

And then there's a small portion of multipass techniques that are best implemented as per-draw multipass like Ogre 1.x did. The thing is, supporting that kind of multipass created additional complexities in the renderer and hindered certain important performance optimizations. Because there was little to gain and a lot to lose, a compromise was made and multipass support was cut. As noted by another user, this multipass approach can still be achieved by using multiple Items with the same transform but different materials.
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?
Yes, the devil is in the details. Technical details such as how uniforms are being dealt got in the way. The old materials like to mess up with all sort of API render state unnecessarily.
In the 2.1-pso branch workarounds were made and now low level materials seem to be working on all RenderQueue modes (I can't guarantee every functionality is working though, i.e. auto params). Please note that 2.1-pso is very stable and planned to soon be merged with 2.1; you can give it a shot.

Long term plan is to implement an Hlms implementation that works similar to how the HlmsCompute implementation works (which is used for compute shaders) which would allow for flexible materials with custom shaders and a speed close to an actual Hlms implementation. The script syntax would only work using JSON though.
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?
Depends on how we define "custom pixelshaders":
  • 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.
As for old materials using FFP (fixed function pipeline), when we implemented the Hlms we decided to not emulate its look for several reasons:
  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.
0 x

peteb
Gnoblar
Posts: 17
Joined: Thu Feb 26, 2009 9:05 pm

Re: Porting to Ogre 2.1 - materials

Post by peteb » Mon Nov 07, 2016 2:13 pm

Thanks for the reply!

I guess I will need to be looking at a custom Hlms implementation then for some of my stuff (Ocean surface).

And as for porting existing customer specified materials, I'm expecting that they will indeed be simple diffuse textures / fixed colours. I guess I can 'preload' materials in the resource path created for the asset, parse the legacy material scripts and generate Hlms materials for those with PBS that just use the diffuse texture / colour. I guess they will look better with Cook-Torrance in this case! Hopefully loading the mesh will then use the generated Hlms materials in preference if they use the same name.
0 x

Wathiant
Gnoblar
Posts: 6
Joined: Wed Aug 21, 2019 9:35 am

Re: Porting to Ogre 2.1 - materials

Post by Wathiant » Wed Aug 21, 2019 10:30 am

Hi, I'm trying something along the same lines and could also use some help.

I am also porting from 1.9 to 2.1. I have everything set up so I get my scene displayed (with debug level 3 I don't get any asserts).
However, my scene is just in shades of grey, which I strongly suspect to be caused by the materials not being available for the HLMS stuff.

This is where I'm stuck. I only have a handful of materials and I don't have any user-defined objects so I don't mind converting the material scripts by hand, but I could not find a reference or example on how to do this. 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.

A commonly used material by my application is this one:
material XSens/DiffuseNoLight
{
receive_shadows off

technique
{
pass
{
lighting off

texture_unit
{
colour_op_ex source1 src_diffuse src_current
}
}
}
}

One thing I noticed is that the parser complains about the 'lighting off' line, so I got rid of it for now, but I guess this is one of those cases mentioned by Peteb where I could not find anything online about the lighting keyword no longer being supported nor about what should have replaced it. (not angry here, I understand you have lots of stuff to fix, just hoping for some insights :) )
It also complains about iteration_depth_bias -0.025 which is used in another material (but I think I can work around that one)

Any pointers on how to get my scene to get some colour and textures again would be helpful!
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4066
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 228
Contact:

Re: Porting to Ogre 2.1 - materials

Post by dark_sylinc » Wed Aug 21, 2019 3:35 pm

Hi!

Porting most materials is a little 'complicated' in the sense that there is no 1:1 transform. Except no lighting materials, such as the case you posted.

You need to use an unlit material:

Code: Select all

hlms XSens/DiffuseNoLight unlit
{
    diffuse_map name_of_texture.png <blend_mode>
    diffuse_map1 name_of_texture_on_next_texture_unit.png <blend_mode>
    //... up to diffuse_map15 supported
}
Blend mode is optional and can be any of the following (no quotes):

Code: Select all

"NormalNonPremul", "NormalPremul", "Add", "Subtract", "Multiply",
"Multiply2x", "Screen", "Overlay", "Lighten", "Darken", "GrainExtract",
"GrainMerge", "Difference"
Many settings such as depth_check, depth_write, cull_mode, scene_blend, etc still work. But any of the 'iteration*' settings are no longer supported.

Lighting on/off no longer makes sense, as if you want Lighting off you should use unlit materials, if you want it on, you should use pbs materials (we have several samples of pbs materials under Samples/Media/2.0/scripts/materials.

Btw some more advanced settings you'll find can only be tweaked via JSON materials (see Docs/2.0/JSON for examples)

Cheers
Matias

Update: al2950's answer is more complete!
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1200
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 76

Re: Porting to Ogre 2.1 - materials

Post by al2950 » Wed Aug 21, 2019 3:36 pm

Hi
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.
I think this is a very valid point!

Firstly there are 2 material formats in Ogre 2.x, *.material and *.material.json. However you should only really use *.material.json as thats the 'new' version. BUT all the current samples use the older format which may add to the confusion!

If you have made yourself familiar with the changes overview here then have a look at this folder, this shows you the settings for PBS and Compute material files, sadly its missing Unlit, which is what it looks like you are after. Its also missing documentation of what everything is. Most is obvious, but the source code, especially the *datablock* files are well documented and should give you everything you need.

In the meantime, below is a example unlit material file for a additive transparent object. (watch out for bad json syntax, if you dont know it learn it!)

**EDIT** Please note the material below is not tested, and might have some mistakes as its copy and pasted from various places. Also you do not need to define eveything in that file, infact a lot of its is pointless as its default settings

Code: Select all

{
	"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"
            }
        }
	}
}
Last edited by al2950 on Wed Aug 21, 2019 3:45 pm, edited 5 times in total.
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1200
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 76

Re: Porting to Ogre 2.1 - materials

Post by al2950 » Wed Aug 21, 2019 3:39 pm

Dark_sylinc posted about 2 seconds before I did! FYI he is using what I would call the 'old material' format.
0 x

Wathiant
Gnoblar
Posts: 6
Joined: Wed Aug 21, 2019 9:35 am

Re: Porting to Ogre 2.1 - materials

Post by Wathiant » Wed Aug 21, 2019 3:39 pm

Thanks! What if I don't want to use a texture? I have some primary color primitives (essentially spheres on sticks) using this
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4066
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 228
Contact:

Re: Porting to Ogre 2.1 - materials

Post by dark_sylinc » Wed Aug 21, 2019 6:56 pm

Then use diffuse colours e.g. "diffuse 1 0 1 1" and set scene_blend for alpha blending if required (parameters are same as in 1.9)
0 x

Wathiant
Gnoblar
Posts: 6
Joined: Wed Aug 21, 2019 9:35 am

Re: Porting to Ogre 2.1 - materials

Post by Wathiant » Thu Aug 22, 2019 7:43 am

Thanks! I 'll go and experiment with this new information today, hopefully with some success :)
My posts need to go through a moderator so any follow up questions/remarks will be slow. If someone could mail me it would really help: job DOT mulder THINGY xsens DOT com.

One question, the HLMS system as shown in the samples seems to load its files from a different location than the other resources. In particular there is a bit that seems to filter out sections names Hlms. Is this correct? And if so, where should I put these newly defined materials? I've been putting them in multiple locations, but it's easier to fix things when I can use a single file :)

Thanks for all the support! Despite it not working yet for me, you guys are really helpful :D
0 x

Post Reply