EntityColor Color Range

Blitz help for EnityColor says 0-255 is the range for red,green and blue.
If so, why does the range 256-511 continue to increase the amount?

Here is the modified help example

; EntityColor Example
; -------------------

Graphics3D 640,480,24,2

SetBuffer BackBuffer()

camera=CreateCamera()

light=CreateLight()
RotateEntity light,90,0,0

cube=CreateCube()
PositionEntity cube,0,0,5

; Set initial entity color values
red#=255
green#=255
blue#=255

While Not KeyDown( 1 )

; Change red, green, blue values depending on key pressed
If KeyDown( 2 )=True And red#>0 Then red#=red#-1
If KeyDown( 3 )=True And red#<511 Then red#=red#+1       ; <changed 255 to 511
If KeyDown( 4 )=True And green#>0 Then green#=green#-1
If KeyDown( 5 )=True And green#<511 Then green#=green#+1 ; <changed 255 to 511
If KeyDown( 6 )=True And blue#>0 Then blue#=blue#-1
If KeyDown( 7 )=True And blue#<511 Then blue#=blue#+1    ; <changed 255 to 511

; Set entity color using red, green, blue values
EntityColor cube,red#,green#,blue#

TurnEntity cube,0.1,0.1,0.1

RenderWorld

Text 0,0,"Press keys 1-6 to change EntityColor red#,green#,blue# values"
Text 0,20,"Entity Red: "+red#
Text 0,40,"Entity Green: "+green#
Text 0,60,"Entity Blue: "+blue#

Flip

Wend

End

Could others check and see if their computers also show a 0-511 color range.

This is strange !

Blitz gives you a simplified view of 3D graphics.
Usually this is a good thing. But here it is confusing.

Screen pixels, like 2d images, have integer color values 0 to 255.

But 3d color values are floating point numbers.
0.0 means no color, 1.0 means full bright, 0.5 is half bright etc.

AmbientLight 0, 0, 255 actually sets internal values of 0.0, 0.0, 1.0

After a color value is calculated it is multiplied by 255.0 to get a screen pixel value.
This is rounded to the nearest integer, and limited to the range 0 to 255.

Consider this example. For simplicity it uses blue only.

Graphics3D 640,480,32,1

AmbientLight 0,0, 51     ; ambient blue level is really 51.0/255.0 = 0.2

camera=CreateCamera()

cube=CreateCube()  :  PositionEntity cube,0,0,5

blue# = 255 * 4  ; blue level is (255*4) / 255 = 4.0

While Not KeyDown( 1 )

	If KeyDown( 2 ) Then blue# = blue# - 1
	If KeyDown( 3 ) Then blue# = blue# + 1
	
	Delay 40
	
	EntityColor cube, 0,0,blue#
	
	RenderWorld
	
	Text 0,0, "Press keys 1,2 to change EntityColor blue# value."
	Text 50,50,"Entity blue: "+blue#

	Text 50, 100, "Calculated screen blue = " + ( (51.0/255.0) * blue )
	Text 50, 120, " Displayed screen blue = " + ( ReadPixel(320,240) And $FF )
	
	Flip

Wend

End

Note: Your example is misleading because there is also a default AmbientLight value of 128,128,128.

Thanks for the clarification of what is really happening with the colors.

Sorry if my example was misleading, as it was part of the misleading help/manual on EntityColor.

So rather than a range of 0 to 255 it is more correctly a forumla of ;
0 to (AmbientBlue/255.0) * 255.

Only when AmbientLight is set to 255,255,255 that the EntityColor range would be 0 to 255.

The Default AmbientLight is set to 128,128,128. So as you pointed out the range is different. This is when the range of 0 to 511 is true.

Or even more simply as AmbientLight decreases all EntityColor ranges become greater. With The extreme being with AmbientLight set to 1,1,1 and the EntityColor range being 0 - 65025.

That is the jist of what I got for you great example, thanks again. Please correct me if anything I said here is wrong. This is handy to now, and explains a few strange things in the past.

I guess this means the info in the help/manual is wrong or at best an over simplification.

Thank you again for you wisdom.

so if your program uses values from 0-255, Setting AmbientLight is in fact a limit AND a kind of scaling.

This really helps, because with low ambient light, it had been impossible to show a bright light. Now I know I then have to increase beyond 255 to 'beat' the ambient light limit!

Ambient light is ambient light. It's not a "limitation" and it doesn't affect the "range" of colors to which you can set an entity.

Imagine you have a pure red entity. If you set ambient light to 255,255,255, then you'lll see it as pure red.

However, if you set ambient light to 511, 511, 511, you'll see it as pure WHITE.

This is because the red color is getting overbrightened, just like when you crank up entityshininess and have a specular hotspot on your model. In fact, thanks to the face that you can set colors up to 511, you can simulate specular by adjusting the vertex colors if you don't want to use hardware lights.

As long as the sum of your objectcolor (or vertex color) and the ambient light and the lights in your scene stays below 255, you won't get that overbrightening effect.

It works like this:

(Ambientcolor/255 + (Lightcolor*Falloff)/255) * ObjectColor

So you can go up to 2.0 and perhaps beyond that on the left side of the equation and that will multiply your object color above and beyond what it would be if fullbright.

Thanks Shawn for the extra info.

Do people think the help/manual should be updated with this info from Floyd and Shawn?

I think knowing what a command is really doing is very important, not only having over simplification.

My equations aren't EXACTLY correct here I was just thinking because like I said, red will become white. There's something else going on internally, maybe a conversion to HSV, or maybe just white is gradually added to the color... I'm not sure.

So don't update the help file with the equations I gave cause they're wrong. :-)

The important thing is not knowing the equations. That won't give you the intuition to know what is going on.

Just know that you can specify rgb colors up to 511, and that any time a vertex color exceeds 255 either because you set the color to that, or because it's illuminated by a lot of ambient light and specular is enabled, you're gonna start seeing specular-like overbrightening effects.

I don't even know how lighting works in all possible situations.

My main point was that the values you specify in your code get divided by 255.
Then all the internal calculations, whatever they are, get done.
The resulting value gets multiplied by 255 to determine pixel color.

Here's another example to emphasize that there really is no restriction on light values.

Graphics3D 640,480,32,1

AmbientLight 0,0,0

camera=CreateCamera()

cube=CreateCube()  :  PositionEntity cube,0,0,5

blue1# =  300
blue2# = -200

light1 = CreateLight() : LightColor light1, 0, 0, blue1
light2 = CreateLight() : LightColor light2, 0, 0, blue2

While Not KeyDown( 1 )

	If KeyDown( 2 ) Then blue1 = blue1 - 1
	If KeyDown( 3 ) Then blue1 = blue1 + 1
	
	If KeyDown( 4 ) Then blue2 = blue2 - 1
	If KeyDown( 5 ) Then blue2 = blue2 + 1
	
	Delay 40
	
	LightColor light1, 0,0, blue1	
	LightColor light2, 0,0, blue2	
	
	RenderWorld
	
	Text 0,0, "1,2 changes light1.    3,4 changes light2."

	Text 50,50, "light1 blue: " + RSet(blue1, 7)
	Text 50,70, "light2 blue: " + RSet(blue2, 7)
	
	Text 50, 100, "blue1+blue2 = " + (blue1+blue2)
	Text 50, 120, "screen blue = " + ( ReadPixel(320,240) And $FF )
	
	Flip

Wend

End