Using Debug Log features, and material questions.

[Gluber]

Hi !

Some little questions:

Is there a way to register a new "LogListener" as far as i can see from LogManager and Log classes in Ogre its not possible ( There is always either file output or debugger output which is hardcoded )

It would be great if we could register a LogListener. I use the Debug log intensivly for diagnostics etc. ( especially during interactive scripting with our integrated IDE ) and would like to route all ogre debug output to our IDE ( which is rendered using CEGUI ) ..

My second question is on materials: Is there a feature planned to have a "material" template which exports some parameters and then on use you can instantiate this template and just set the parameters... e.g a OffSetBumpmap Material Template which just exports parameter like TextureName, BumpMapName etc.... this would make it much easier to let artists have a directory of programmer made materials and still be able to tweak them to their liking ( e.g using parameters like diffuse etc. )
It would also reduce a lot of code duplication ( it seems very wasteful to have copy of a material script just because you want a different texture )

I hope anyone can shed some light onto these issues.

[sinbad]

Importing log entries has been done in the past just by reading the output log back in. A patch to allow log listeners would be welcome though.

As for parameterised material templates, for artist tools most of the effort is going into supporting the native material tools in the modeller (see Octopus for 3DS, and I hope to do something with XSI soon) and separate material editors (nfz has a good one in progress).

[Gluber]

Again on the material ideas.

As of today non realtime rendering and realtime rendering differ radically. That said automatic export of any e.g SoftImage XSI Shader network into an ogre material is not really possible.

Seperate material editors are a very good idea..

However this does not solve the problem of code duplication right now !!

Suppose this situation:
You design a game based on Ogre which is an FPS. You design a material that is used for all walls performing paralax mapping etc and some magic of your own YOu want to apply that material to almost every surface in the game but with different textures, bump maps. etc... At the moment this results in extensive Material Code duplication since for every surface with different textures you would need a new material copy... Can you see my point ? Its a maintenance nightmare ( suppose you lateron want to fix some bugs in your material script or improve it .....) you would either need to write a material generator with some sort of text replacement scheme or hand edit your probably 100s of material copies...

So i think having a material template and parameters is the way to go ( like DX and CGFX have it... Also getting a stock art tool to create you special material scripts ( since i doubtt hat everybody is going to use the same materials ) would next to impossible except with a text replacmenet scheme as outlined above.
The only code that can be shared right now is the actual verex/pixel shader code.. but my materials themselves tend to get pretty long already ( we are doing architectural visualization with materials that often contain 10 passes or more even on PS2.0 hardware )

[haffax]

Yes, some way to effectivly manage huge amounts of similiar materials would be very welcome. Maybe in Ogre 1.x.

A similiar feature request has recently been issued here.

[nfz]

Back in Aug 2004, when I started working on a material/resource editor, I realized that material script files get rather huge when you can easily generate materials on the fly in real time. As many people have noted, most materials are just slight variations of another material and its a waste in a script to have so much the same and have only slight variations. Being able to generate and tinker with materials in realtime just by using a mouse takes out the drudgery of copy and paste in script files but when the editor has to serialize the materials to a script there is a lot of duplication in text output. Then of course later on when you decide to load the script into your engine, the long script takes time to load.

So I came up with a method to keep the script size down. I added the following feature to the material system: copy history. I won't go into all the nitty gritty details of how it works but the end result is this: any material can be a template for another material.

Here is a simple example of what the material script looks like that is generated by the material editor:

Code: Select all

// ORE generated material script
// 08 Jan 2005
material BaseWhite
{
  receive_shadows on
  technique
  {
    pass
    {
      specular 0.190841 0 0 1 21.3743
      emissive 0 0 0 0.864821
      scene_blend dest_colour zero
    }
  }
}


material test 
{
  copy BaseWhite
  technique
  {
    pass
    {
      specular 0.9136 0.9996 0 1 26.3743
    }
  }
}

Note the "copy" command that the editor put in the script for "test". When the material serializer is loading the script and encounters the copy command, it copies the named material which must be previously defined and then any script commands after just modify or add to the material definition for "test".

Here is a more complex example but shows how easy it is to set up a slightly different material based on another one.

Code: Select all

// ORE generated material script
// 08 Jan 2005

vertex_program GLSLDemo/OffsetMappingVS glsl 
{ 
	source offsetmapping.vert 
} 

fragment_program GLSLDemo/OffsetMappingFS glsl 
{ 
	source offsetmapping.frag 
} 

material GLSL/OffsetBMRockWall
{ 
  technique 
  { 
    pass 
    { 
      ambient 0.7 0.7 0.6
      diffuse 1.0 1.0 0.9
      specular 1.0 1.0 1.0 64
			
      vertex_program_ref GLSLDemo/OffsetMappingVS
      {
        param_named_auto lightPosition light_position_object_space 0
        param_named_auto eyePosition camera_position_object_space
        param_named textureScale float 1.0
      }

      fragment_program_ref GLSLDemo/OffsetMappingFS 
      { 
        param_named Ka float 0.2
        param_named Kd float 0.7
        param_named Ks float 0.22
        param_named scale float 0.04
        param_named bias float -0.02
        param_named normalHeightMap int 0
        param_named diffuseMap int 1
				
      } 

      texture_unit
      {
        texture rockwall_heightNH.png
        tex_coord_set 0
        filtering trilinear
      }

      texture_unit
      {
        texture rockwall.png
        filtering trilinear
        tex_coord_set 1
      }

    } 

  } 

} 

material GLSL/OffsetBMStone
{ 
  copy GLSL/OffsetBMRockWall
  technique 
  { 
    pass 
    { 
      diffuse 1.0 0.49999 1.0

      fragment_program_ref
      { 
        param_named Kd float 0.862
      } 

      texture_unit
      {
        texture BeachStonesNH.png
      }

      texture_unit
      {
        texture BeachStones.jpg
      }

    } 

  } 

}

GLSL/OffsetBMStone is basically the same material as GLSL/OffsetBMRockWall but with a different diffuse setting and different textures to use for the offset mapping. Oh and fragment_program_ref has a different param_named value for Kd.

I will be submitting a patch for Ogre 1.0 but it will not happen until after I get the Alpha version of the material editor working with Ogre 1.0. I was going to submit it back in November but decided to wait and see what mods Sinbad and crew were going to make to the script system and I am glad I waited.

[stodge]

Or for programmers, how about this?

Code: Select all

material test: BaseWhite
{
  technique
  {
    pass
    {
      specular 0.9136 0.9996 0 1 26.3743
    }
  }
}

[nfz]

I had toyed with that method but at the time it was easier to modify the parser to accecpt a seperate line that had the copy command. But I agree that format is nicer / easier to read. Hmm. I could modify the material command to accept up to 3 parameters:

Code: Select all

material test : BaseWhite 
{ 
  technique 
  { 
    pass 
    { 
      specular 0.9136 0.9996 0 1 26.3743 
    } 
  } 
} 

A space is needed around the colon so that the parser picks it up. The ogre parser just breaks up the line based on white space. If other people think that is a better form then I can change the serializer/parser. Of course this all depends on if the Ogre team likes the patch.

[leedgitar]

The only issue I can think of that would arise would be ensuring the material you are "inheriting" from has already been loaded. I do like stodge's suggestion better though, maybe because I'm a programmer . And really, the implemention wouldn't even be that hard, since "child" materials could just clone the parent, and overwrite the settings where appropriate.

And while I'm at it, since 1.0 is coming and there may already be some planned material changes, I'll try one more time to suggest allowing techniques (and maybe even passes) to be optionally named like you can in .fx files . Retrieving said objects by name wouldn't be necessary, it would serve as nothing more than a meaningful name. It would be helpful when debugging, error logging, etc I believe.

Code: Select all

material Foo
{
     technique WhizBang
     {
     }

     technique Fallback
     {
     }
}

[sinbad]

nfz: yes, I like this idea and a patch would be welcome. I think requiring a space around the ':' would make it error prone, and I don't think you need it. The parser splits on the first whitespace character only to begin with (see invokeParser), the rest of the line just gets passed to the parse function as a string to allow it to decide how to split the rest. So parseMaterial currently doesn't split at all, but you could make it split on ':' to do what you need.

Oh, and a patch to manual.texi at the same time would be most welcome

@leedgitar: I don't think loading matters since you're only copying a definition. None of the materials are loaded during parsing but you can still fully define them and read out those definitions. I definitely would be opposed to any patch which forced the loading of a material during parsing.

As for names on techniques / passes, I've no particular preference - I've never felt the need to use them but so long as they're optional I don't mind if someone submits a patch to allow them.

[nfz]

Sinbad: ya, was being lazy about parsing. I'll set it up to scan for : as a delimiter between names to see if the material must copy from another material first. I'll do up the changes to manual.texi too.

Leedgitar: I have been thinking about adding the option for names to technigues, passes. In the material editor when you drag and drop a technigue, pass, or texture unit to move/copy, its hard to tell if the order actually changed if the items aren't expanded in the tree since the numbers for technique/pass stay the same. Its not that hard to add name support for technique, pass in the parser so if I get some time I will implement this. I agree that naming should be optional in the script.

[leedgitar]

@leedgitar: I don't think loading matters since you're only copying a definition. None of the materials are loaded during parsing but you can still fully define them and read out those definitions. I definitely would be opposed to any patch which forced the loading of a material during parsing.

As for names on techniques / passes, I've no particular preference - I've never felt the need to use them but so long as they're optional I don't mind if someone submits a patch to allow them.

Oops, I meant parsed rather than loaded. If it were known that the parent would always be parsed before the child, it would be simpler to init from parent definition first, then parse the child params so they only overwrite with the values that are actually defined in the child material. However, that would only be possible if the parent were already parsed (which isn't guaranteed), so this process would likely have to be deferred until load time. In that case, you can grab the parent material and copy to the child, but at load time you don't know which material settings in the child material were initially set by the script. In most cases, that would mean the current value is not the default value. So, you could have a specialized version of copyDetailsTo or whatnot for this purpose, that only overwrites values that aren't the default. I.e. Parent defines diffuse as red for the first pass, and child defines it as blue. When parent gets copied to child, it sees the diffuse value for the childs first pass is not the default of white, and does not overwrite it. If the child's diffuse value were White (which is the logical default), then it would overwrite it since the child's value has no reason to be preserved.

I didn't get much sleep last night so I hope that makes some type of sense.

[DWORD]

I really like the idea of material inheritance. I think it would be best to just require the parent material to be defined before its descendants, though, because I could think of situations where you would want to override 'back' to the default value.

[Gluber]

Hi again

On the material system issues. Since we all seem to be clear that some sort of material "templating" is required i have to add another thought. I am starting to use Ogre in full production mode soon ( with 4 artists ). Material inheritance is cool , but e.g if we programmers create some fancy materials, and the artist can override parameters for it, this can lead to some problems. At least our artists are NOT technically versed, they have no clue about realtime 3D graphics whatsoever. So letting them "choose a base material" and override where you need" is not a good idea as it would lead to many problems and long turnaround times ( they just don't get the concept of a texture_unit or something ) I think it would be much better to define some "parameters" as external with some description ..e.g i came up with something like this..

texture_unit
{
texture [ColorTexture:Filename]
}


so the artist would just see those parameters and in the above case have a ColorTexture parameter he can assign an image file to..
This would allow us to write easy to use material editors where the artist can't wreak havok with carefully crafted material code.....
Of course as i said before this could be implemented in a tool entirely, but i think it would e much better if Ogre hat support for this by itself since its useful in many situations. Remember if you really want to make a product with ogre its not about programmers anymore but the whole team that has to work with it.