exposing per channel colour_write in the material

What it says on the tin: a place to discuss proposed new features.
Post Reply
nbeato
Gnome
Posts: 372
Joined: Thu Dec 20, 2007 1:00 am
Location: Florida
Contact:

exposing per channel colour_write in the material

Post by nbeato » Fri Oct 30, 2009 10:24 pm

So, right now, I have written a few shaders for alpha channels and rgb specifically. These shaders can be "combined" easily if colour_write exposes per channel functionality. For example, an rgb gaussian blur and alpha gaussian blur only need different pass settings (colour_write rgb vs colour_write alpha) using a shader that blurs all 4 channels. So knowing that OpenGL allows per channel settings, I looked into how it works in OGRE. After investigation, this limitation is on the material compiler and the pass, not the render system. This can be seen in SceneManager::setPass...

Code: Select all

		// Set colour write mode
		// Right now we only use on/off, not per-channel
		bool colWrite = pass->getColourWriteEnabled();
		mDestRenderSystem->_setColourBufferWriteEnabled(colWrite, colWrite, colWrite, colWrite);
So my proposition is to change the bool state representation to 4 bit masks in Ogre::Technique, Ogre::Material, and Ogre::Pass, ie:

Code: Select all

bool getColourWriteEnabled() const
becomes...

Code: Select all

ColourWriteChannelMask getColourWriteChannelMask() const
In the Material/Pass/Technique API, the existing API can still set all channels to true or false, but adding setColourWriteChannelMask(ColourWriteChannelMask mask) can allow explicit control. There's really not too much to change in the source, but I wonder how much this is used elsewhere? So maybe the current API can still exist as a deprecated shortcut?

In the material files, the only modification would be extra parsing capabilities... ie

Code: Select all

colour_write := (on | off) [(on | off) (on | off) (on | off)]
In other words, set all channels with one "on" or "off", or explicitly set all 4 channels (in RGBA order).

I'm willing to try to do this and send a patch. I am curious if the dev team agrees with these changes?

Assuming yes, if the old interface is left, I think might be confusing is explicitly setting a mask in the API might imply that the on/off on colour_write just enables that mask. So maybe the alternative would be to just introduce a colour_write_mask field to the pass, but leave the colour_write as is. This would be with the understanding that turning colour_write to on enables the mask, not all 4 channels. That seems like the more complex approach though.
0 x

Post Reply