Remove ExternalTextureSource?

[scrawl]

Since we're currently removing unused / obsolete / deprecated stuff, what about ExternalTextureSource / ExternalTextureSourceManager ? Video playback can be done perfectly by creating a regular texture and updating its pixel buffer. I don't see any advantage to having this external texture source manager.

[dark_sylinc]

I don't even know what that is.

[Kojack]

I don't even know what that is.

http://www.ogre3d.org/docs/manual/manua ... re-Sources

The external texture source allows a material file to specify a plugin with parameters as a texture. You can make plugins for things like video, procedural textures, other non image formats (maybe html, etc) then give them parameters from material scripts instead of directly in code. From the link above, here's an example:

Code: Select all

material Example/MyVideoExample
{
	technique
	{
		pass
		{
			texture_unit
			{
				texture_source video
				{
					filename mymovie.mpeg
					play_mode play
					sound_mode on
				}
			}
		}
	}
}

filename, play_mode and sound_mode are all defined in the string interface of the "video" plugin.

It's probably not used much (if anybody even knows it exists), but it does still seem a potentially useful feature.

Video playback can be done perfectly by creating a regular texture and updating its pixel buffer.

True. But the advantage to external texture source is that the material script can provide the parameters, rather than doing it in code or via some other scripting system. You could even potentially change the video plugin without changing any code in the main program (just put a different plugin in plugins.cfg and change the parameters in the material script).

[scrawl]

Having to play X different videos on Y different materials (in which case a scripting interface would be useful) is really an edge case. Plus, the decoding does start to have a performance impact at some point, so animated textures are usually better.

If one really needs a scripting interface for this, then go ahead and make one yourself. It's not difficult: Reference a regular texture name in texture units (call it your "external texture id"), then parse some .video definition files to link them to a video. You'll know you need to start playing the video when tus->isLoaded() == true.

I don't even know what that is.

That kinda proves my point

[Klaim]

As someone who intend to use a lot of procedural textures (mostly noise patterns), well I'm not sure if it's a good or bad thing to remove this.

[Kojack]

That's where I see it as more useful, things other than video.
Video is very specific, it's probably better to do it explicitly like scrawl said.
But other image types (procedural, non image sources like html or svg, etc) would be better suited to it.
For example:

Code: Select all

material
{
   pass
   {
      texture_unit
      {
         texture_source noise
         {
            method perlin
            octave 5
            amplitude 2
         }
      }
   }
}

That could generate perlin turbulent textures. The advantage is that Ogre doesn't need to know about the noise plugin used there. Neither does your code. Even without the source code for the game/program you could give it the plugin (via the plugins.cfg) and change the material, the program now knows how to generate perlin.

It's the same basic thing as ogre's particle system. The emitters and affectors in the particle scripts don't exist in ogre. They all come from an optional plugin that registers it's contents as string interfaces. The external texture source system is a texture version of what particle systems also do.

[Zonder]

I have to agree with kojack it is a very powerful feature. Also makes me wonder if transporter knows about it as he did the work on procedural textures for procedural geometry.

[Klaim]

Indeed it looks very useful and would allow me to not have to have a separate configuration system for these procedural textures.
I didn't knew it existed but now I think I'll try it.

[dark_sylinc]

I've got to agree it does look very powerful indeed.
A library showing animated noise out of the box would be awesome (so does gpu noise though)