[Suggestion] Improve ColourValue

Hi,

I am just thinking about the colourvalue struct. It is working fine but very light weight. Converting from net. color to/from ogre colourvalue is not easy (for beginners, although there are snippets). It is a straight forward conversion form ogre (it is converterd, not wrapped, look in "mogre\Main\src\Custom\MogreColourValue.cpp" ). My sugeestion is to take a look at axiom's colourvalue and modify mogre's colourvalue to make more usefull (add a convert function from/to net color, add static fields for all known colors, more (usefull) constructures,...).

My knowledge in c++/cli is very limited (I know good converters ) but I think we should add it to our wish list.

you can always add your own extension methods

I know. I even have helper classes but in my opinion it is more "useful" to extend mogre than each user has to do the same again and again.

I am just thinking about the colourvalue struct. It is working fine but very light weight. Converting from net. color to/from ogre colourvalue is not easy (for beginners, although there are snippets). It is a straight forward conversion form ogre (it is converterd, not wrapped, look in "mogre\Main\src\Custom\MogreColourValue.cpp" ). My sugeestion is to take a look at axiom's colourvalue and modify mogre's colourvalue to make more usefull (add a convert function from/to net color, add static fields for all known colors, more (usefull) constructures,...).
It's not a good idea to extend Mogre this way. Mogre's purpose is to be a wrapper around Ogre and nothing more. Once you start adding extra stuff where do you stop?

For example, there are 3 Color classes in the .NET framework.

System.Drawing.Color - from early versions of .NET
and
System.Windows.Media.Color - introduced with WPF in later version of .NET I believe.
and
Microsoft.Xna.Framework.Graphics.Color - for people using the XNA framework.

Rather than extending Mogre.ColourValue to convert to the classes above, why not extend the classes above to convert to Mogre? Because you don't have access to the code, but more importantly because people who use System.Drawing or System.Windows.Media probably don't want to use Mogre and visa versa.

I know. I even have helper classes but in my opinion it is more "useful" to extend mogre than each user has to do the same again and again.
That said, if you wanted to start a MogreAddon that handles this kind of stuff I think it would be useful. People who are using Mogre to create editors would find this kind of thing particularly useful. All they would need to do is add a DLL to thier project specifically for this purpose.

Seems logically. It was only an suggestion

The idea of a converter class is interesting.
For my application I also wrote a colour converter.


My proposal:

* Don't add it to the Mogre core
* Don't create an add-on
* Just create a C# class, which contains the functionality and publish it in the wiki.

The same way Kojack published his EulerAngleClass.

So everybody can insert just one C# file to his project and can use it.
Additionally this way it's most easy to apply modifications if needed.

For VB users it's easy. Just put the code into an online converter and you get the result.

Currently I try out the MogreBuilder.
When I looked to the files, I saw that the ColourValue class is a "custom" (ported) class.

My knowledge in c++/cli is very limited
If you want to extend the class, you don't need CLI, because nothing is wrapped.

Perhaps somebody (Tubulii?) can port the code to C#. (It's not that much.)
And then extend the functionality. (Maybe just copy&past from Axiom?)

Advantage:
If somebody wants to modify the class, he doesn't need to re-compile Mogre.
As result the ported class can be used as replacement for class ColourValue if needed.


... after a while ...

In the internet I didn't find the related source file. Now I downloaded the whole Axiom source and got the file. By it's path I could figure out the URL of the online version.

C# code of Axioms colour class:
https://svn.axiom3d.net/svnroot/axiomengine/trunk/Projects/Axiom/Engine/Core/ColorEx.cs
(2700 lines, 50 KB)

Most parts of the code are static colour properties (Red, Green, etc.)

If you want to look to the current Mogre colour files - here are quick links:
https://bitbucket.org/mogre/mogre/src/bd76effd61ae/Main/include/Custom/MogreColourValue.h
https://bitbucket.org/mogre/mogre/src/bd76effd61ae/Main/src/Custom/MogreColourValue.cpp

Maybe it's useful for you.
I don't want to do more on this topic, because I don't need it and should concentrate on my diploma thesis.

You also can add more constructors:

MogreColour(System.Drawing.Color colour)
MogreColour(System.Windows.Media.Color colour)
MogreColour(Microsoft.Xna.Framework.Graphics.Color colour)


And methods to get/set specific colour types:


MogreColour.GetDrawingColor() .......... returns type System.Drawing.Color
MogreColour.GetMediaColor() .......... returns type System.Windows.Media.Color
MogreColour.GetXnaColor() .......... returns type Microsoft.Xna.Framework.Graphics.Color

Similar for setter methods like SetDrawingColour().

Alternatively you could use properties instead of Get/Set methods:

MogreColour.DrawingColor
MogreColour.MediaColor
MogreColour.XnaColor




Additionally you can add static converter methods:


MogreColour.ConvertToDrawingColor(MogreColour colour) .......... returns type System.Drawing.Color
MogreColour.ConvertToMediaColor(MogreColour colour) .......... returns type System.Windows.Media.Color
MogreColour.ConvertToXnaColor (MogreColour colour) .......... returns type Microsoft.Xna.Framework.Graphics.Color

MogreColour.ConvertFromDrawingColor(System.Drawing.Color colour) .......... returns type MogreColour
MogreColour.ConvertFromMediaColor(System.Windows.Media.Color colour) .......... returns type MogreColour
MogreColour.ConvertFromXnaColor (Microsoft.Xna.Framework.Graphics.Color colour) .......... returns type MogreColour



The static methods would be fine for plain conversions.
The non-static methods/properties/constructors are useful if somebody wants to keep and modify a colour instance.


To avoid code redundancies, the non-static methods can call the static methods internally.
Example:

GetDrawingColor()
{
return ConvertToDrawingColor( mColour );
}



Well, now I wrote a half hour for just this little post.
But perhaps it's useful.
(Maybe a half hour would had be enough for coding that stuff instead of writing a post.)

I already have such a converted class. I will extend it as you suggested and publish it.
And methods to get/set specific colour types:

MogreColour.GetDrawingColor() .......... returns type System.Drawing.Color
MogreColour.GetMediaColor() .......... returns type System.Windows.Media.Color
MogreColour.GetXnaColor() .......... returns type Microsoft.Xna.Framework.Graphics.Color


Similar for setter methods like SetDrawingColour().

Alternatively you could use properties instead of Get/Set methods:

MogreColour.DrawingColor
MogreColour.MediaColor
MogreColour.XnaColor
Another possibility would be to add custom CType operators (similar to the ones in the euler class). I will add them, too.

Edit: Done. (I excluded XnaColor and MediaColor (because I do not use them) but they can be added easily)

to add custom CType operators
Good idea!

I never used them, although I thought such a functionality would be fine for the colour class.
If you have defined a class or structure, you can define a type conversion operator between the type of your class or structure and another data type (such as Integer, Double, or String).

The static colour properties floods the colour class.
Perhaps it's more clear when you create 2 files for the same class. (For this use "public shared class".)
One file contains only the colour properties and the other one the rest.
Just as an idea (if you like to do it that way).

I think it is more intuitive when we keep the structure together, just like the .Net one.