Light Intensity

Hi MK

Well, in my systems with up to 4 suns, I just copy the burn_color = of each sun into the light source’s color = for that sun, and it seems good to me, I have varied effects in different systems.

Did you ensure you have the following for each? :-

type = DIRECTIONAL
atten_curve = DYNAMIC_DIRECTION

I use range = 100000 for each and they do look cool, the light colour changes as I travel when I have different coloured suns.

Similar for me as well. I put a lightsource for each sun, alter the ambient and burn colours to match the colour i’m after, and vary the range setting as already mentioned. Higher the number, more of that colour appears as system lighting. Intensity is dependant on the system size, so bigger the system and more colour you want, higher the range number.

What exactly does this burn_color?

It is the colour of the sun as you look at it.

It has 3 numbers: Red, Green, Blue.

So for full red:
burn_color = 255, 0, 0

For full green:
burn_color = 0, 255, 0

For full blue:
burn_color = 0, 0, 255

For all the colours look in a paint program, such as PhotoShop or the GIMP or PAINT.NET.

iirc burn_color is color of the fx that surrounds your ship when getting too close to the sun. or when entering a planet atmosphere, thats why planets also have this property.

RimShot wrote:
iirc burn_color is color of the fx that surrounds your ship when getting too close to the sun. or when entering a planet atmosphere, thats why planets also have this property.

´Thats what I guessed it to be…never testet though.

Could be!

ive looked up in the 1.5 SDK files. most of the system files i picked randomly do not contain the burn_color line on their suns. the only ones i have seen had always the values “160, 222, 245”. sure, it is an RGB entry (btw its a light blue) but either the burn_color is not the flares coming from the ship’s front when youre in atmosphere, or there must be some kind of default value for this line. the line is optional however and as i remember, there are no differences in the color of the flares anywhere (theire beige, always). so, it should be for another purpose than the flares.

Well I think RimShot is right, the atmosphere_range is there too and it makes sense that this would be the colour of the sparks as your ship burns!

But in any case the LightSource’s color = parameters are indeed the color of the light from the source. So it does what we want. I had set my burn_color to be the same as the colour of the sun in any case, so setting the same values into the LightSource color = works for me.

As for the sun colours, I looked into it deeper and refreshed my memory…

The sun’s colours are set in stararch.ini where each sun is defined.

Each sun is defined n a [Star] section as follows, let’s take the med_blue_sun as an example:

[star]
nickname = med_blue_sun
star_glow = blue_starglow
star_center = blue_starcenter
lens_flare = circle_blue_lens_flare
lens_glow = default_lens_glow
spines = blue4_spines
intensity_fade_in = 0
intensity_fade_out = 0
zone_occlusion_fade_in = 1.0
zone_occlusion_fade_out = 1.0
radius = 3000.0

The colours are defined by the star_glow and star_center lines.

In fact both of those are in turn defined in [star_glow] sections, as follows:

here’s blue_starglow, in a [star_glow] section:
[star_glow]
nickname = blue_starglow
shape = glow2_ring
scale = 6
inner_color = 0.6, 0.6, 1
outer_color = 0, 0, 1

and here’s blue_starcenter, in another [star_glow] section:
[star_glow]
nickname = blue_starcenter
shape = LensGlowSpike
scale = 2
inner_color = 0.8, 0.8, 1
outer_color = 0.6, 0.7, 1

In both cases, the colours are R, G, B.

But, as in conformity with other cases of DA’s individualistic programmers, this particular guy or team who designed this part of the game decided to set the colour range from 0 to 1.0 for each value, instead of the range 0 to 255 for each value.

And as it happens it agrees with the method of floats used for Ec, Oc, with the RGBA (RGB & Alpha) values in the materials in cmp and mat files if you remember.

But it’s not hard to translate mentally, for those of us who have experienced such lovely variety previously! LOL

You can also design your own suns now, so go fill your boots.

By the way the plain FL sun definitions were incomplete, I did fix them a long time ago and released the fixed stararch.ini file, I attach a copy below.

I fixed them for JFLP, too, so it’ll be interesting to compare our approaches.

Yeah, that’ll be good!

But… - I don’t have the time, in between making all these posts to get to my target count of 1,000 before LS releases his sur generator! LOL

Maybe I should cut that post count down by the number of spam posts you’ve done, ST? ^^

Sorry for the gravedig on this but was wondering if anyone had messed with different coloured suns?

I was specifically looking for a red sun, a proper one and came up with this, based on the information above.

Required new entries in stararch to achieve the desired effect

StarTrader wrote:

But, as in conformity with other cases of DA’s individualistic programmers, this particular guy or team who designed this part of the game decided to set the colour range from 0 to 1.0 for each value, instead of the range 0 to 255 for each value.

And as it happens it agrees with the method of floats used for Ec, Oc, with the RGBA (RGB & Alpha) values in the materials in cmp and mat files if you remember.

Kodak colour…

A notation for colours developed by kodak, rgb in 3 floats, or rgb + intensity as 4 floats, range 0.0-1.0, commonly found in a range of 3d rendering apps

sometimes abreviated as kd (kodak diffuse colour), ka (kodak ambient colour, and ks (kodak specular colour), it’s a 3d CGI industry standard…

Do you EVER check post dates? Ever?

Sizer wrote:
Do you EVER check post dates? Ever?

Yes, every time…

and yet you continue to necro. fantastic.

Sizer wrote:
and yet you continue to necro. fantastic.

So you think that if a piece of information relevant to a topic isnt available within a fashionably short space of time, it should never be posted?

“Hey guys, does anyone know how to…”
“nope not yet…”
“Well thels forget this modding topic for all time then or Somebody will accuse us of being necro…”

Try and stay on topic huh…

So when you post something that isn’t just HEY LOOK WHAT I KNOW, and can be found out with a five second google search, lemme know. I’ll be there with cake.

EDIT: And just to note, considering the companies involved, and the state of standards at the time, its more likely that this is either an in house derivation of CIE 1931 or the vastly more common sRGB, not Kodak’s derivation (which happens to be rather inefficient)

Sizer wrote:
So when you post something that isn’t just HEY LOOK WHAT I KNOW, and can be found out with a five second google search, lemme know. I’ll be there with cake.

EDIT: And just to note, considering the companies involved, and the state of standards at the time, its more likely that this is either an in house derivation of CIE 1931 or the vastly more common sRGB, not Kodak’s derivation (which happens to be rather inefficient)

Ah… anything people dont know that YOU can find in a search engine is not a postable subject, thanks for clearing that up, so, should the whole modding community just sit and wait for your forthcoming book on everything, or can we participate in forum discussions amongst ourselves while we wait…