ColourRect use by RenderableImage, Frame, etc.

[Jeff_Leigh]

Hi CrazyEddie,

I am currently in the process of implementing my own window set, and tried to use setColous on both a RenderableImage and a RenderableFrame, but I'm not getting the effect I would expect.

Currently, draw_impl is simply passing the ColourRect to each call to d_image->draw... however, this is slightly less intuitive, I would have assumed it would generate a ColourRect for each draw, considering the x/y position of each coord within it's parent 'whole'. (So that the colours specified in RenderableImage::ColourRect are applied to the entire RenderableImage, regardless of tiling and alignment.)

Since I'm rather in need of this change, and it's fairly simple, I can just implement it myself and post the changes here if you are interested (I could also make it optional, so that the existing coloring method is still available).

[CrazyEddie]

Hi Jeff

I agree that the current implementation is probably not what many users will be expecting! This is one of those things that you are aware is not "right" but for some reason always gets put off to be fixed or added later.

It'd be great if you were to post the changes or submit a patch. I think the optional approach is best, as there may now be people who are using the system and want the current behaviour

As an aside, the text rendering also suffers a similar issue - the colours specified are applied to each glyph rather than the rendered text as a whole - which enables some interesting effects, but having the ability to specify a ColourRect for the entire text output is also a feature that I intend to put in at some stage.

[Jeff_Leigh]

Ok, I'm just now getting around to implementing this.

First thing I'm running into is that there is no real colour class for manipulating colours. I'm going to want to be able to add and subtract colours from one another, as well as multiply them against a factor.

I would imagine a ColourManipulator class could encase this functionality well enough... is there any particular approach you would like me to take on this?

[CrazyEddie]

A ColourManipulator class sounds like a good idea. Since this will basically be a utility class, I have no real preference as to how this be done. I'm not sure if you have something in mind that will need to hold state, but if not then an all static approach may be desirable since it allows access wherever it may be needed without the overhead of instantaiting an object - though I'll leave the final decision in your hands (anything is better than that I have now ).

Let me know if there's any problems or if there's anything you'll need me to do to accomodate any changes

Thanks.

[Jeff_Leigh]

Ok, I've implemented ColourManipulator and am pretty happy with it, and have made a few changes to RenderableImage to address the topic.

For the effect to look consistant, the ColourRect must be applied to individual rendered elements of the control correctly.

Therefore, it will have to be be the widget's responsibility to give each Renderable the correct ColourRect. In theory, this should be pretty easy, since I added a function ColourRect::getSubRectangle( left, right, top, bottom) which returns a clipped ColourRect from the specified region.

I'll work on this more monday and hopefully have a patch early next week.

[CrazyEddie]

Sounds great. I look forward to the patch

[Jeff_Leigh]

Ok, I think I'm done with my changes.



I haven't had time to build a patch out of this yet, but I can do it tonight if you really would prefer a patch. If you're anxious to get the changes in, I have a zip with the changed files here (I put my changes in large /**** ... Changes by Jeff ****/ brackets... there are only a few changes per file, except for RenderableFrame, in which case there is a change per frame image.)

I would recommend you apply this carefully, as I didn't have a chance to implement switching between this style mapping and the previous style... though I can't think of any cases where users would actually want the old style mapping. You may also be able to spot ways to improve the readability of the code, especially in the redundent ClourRect clipping in RenderableFrame.

The effected classes are ColourRect, RenderableFrame, and RenderableImage. There is also a new ColourManipulator class which should come in handy.

Note that if you make a framed window rather small, the blending becomes less than perfect (You'll notice the colour trianglulation where the border ends and the interior begins). This is, I believe is due to the colours being applied non-uniformly across the frame and interior, and I doubt there is much that can be done to improve this. Otherwise, if ColourRects are applied correctly, the transitions between border and interior are seamless (see illustration above... that panel has a border, as evident by it's rounded corners.)

Overall, though, I think this implements colour blending across renderables to look as expected. Hope this is useful!

[Jeff_Leigh]

Ok,

I've built a patch for you here.

[CrazyEddie]

I'll give it a good look over later today

[CrazyEddie]

Okay, I've had a chance to get this looked at I've added an option to keep the old way of doing things, though the system will now default to using the new method - since this is more likely what people are expecting.

Thanks a lot for submitting these changes Just got a couple of other things to do and I'll commit this to CVS.

[Jeff_Leigh]

After deploying this approach further, I found the results to still be less than perfect. Certain situations can come up when clipping controls which lead to the colours being mapped wrong.

I have a new approach in mind that I will try next week. Basically I'm going to add an optional Rect parameter to Imageset::draw that specifies the screen coordinates of the ColourRect if it were applied directly to the screen. The ColourRect for the individual image can thus be calculated after clipping and everything else... and should always be perfect. It will also save RenderableFrame and RenderableImage the trouble of managing the ColourRects themselves, and should (assuming you render text with Imageset... haven't looked at it, though) make applying colours to blocks of text a breeze.

I won't be able to start on this until next week, so feel free to ponder on things until then, and let me know if you have any thoughts.

[CrazyEddie]

I think adding the ability to specify an optional mapping area to ColourRect is definately the way to go. Not only does it allow the change to happen transparently to existing code, but it should also push the final ColourRect calculations into Imageset::draw, without requiring any interface changes; enabling the entire system to take advantage of the new functionality without needing to do anything too special (just set the area to use and enable the option). Great idea

[Jeff_Leigh]

Sorry,

I'm still planning on doing this. I've been away from my Ogre stuff for a while while I punch up my web projects for release, and forgot to finish this off.

I still plan on implementing this, though.

[CrazyEddie]

Hi Jeff,

I fully understand the need to work on other projects, and there's actually no rush for this

A few of the things within the system I've been looking at recently have made me want to re-work some other areas if the colour system anyway. Basically, I'm going to make the 'colour' typedef an actual class; there's too much repetetive code that is doing basic manipulation of colour values, or conversions, and what have you. All of this should be unified within the colour class itself (possible merging in the functionality from ColourManipulator), the end result will enable working with colours much easier IMO. I don't have an ETA for this, but it will be quite soon.

Having said this, your planned changes to ColourRect should not be affected, so don't feel you need to wait if you wanted to get on with that

CE.