Light Intensity

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…

well, what you COULD have done (and probably should have) instead of simply demonstrating how knowledgeable on the subject of color spaces you are, ya could have, ya know, demonstrated how to actually convert between standard 8-bit RGB and any of the decimal CIE1931 RGB gamuts this could be.

(WHICH, btw - General trick is to multiply your 0-1 value by 255, most color spaces function under that rule).

Easy, fellas. No need to get all riled up…

Anyways, I’m glad this thread was bumped. I’d like to know if multiple light sources count as dynamic lights, because if so, that kind of destroys an idea I had for Broken Bonds.

Sizer wrote:
well, what you COULD have done (and probably should have) instead of simply demonstrating how knowledgeable on the subject of color spaces you are, ya could have, ya know, demonstrated how to actually convert between standard 8-bit RGB and any of the decimal CIE1931 RGB gamuts this could be.

(WHICH, btw - General trick is to multiply your 0-1 value by 255, most color spaces function under that rule).

Hmm, elemetary grade maths, available in any school…

I didn’t bring cake…

Kazinsal wrote:
Easy, fellas. No need to get all riled up…

Anyways, I’m glad this thread was bumped. I’d like to know if multiple light sources count as dynamic lights, because if so, that kind of destroys an idea I had for Broken Bonds.

Probably, the limit for graphcs cards, and the directx/opengl software using them is for number of lights displayed, not on what they are used for.

The dynamic bit is just to describe the use for effects.

Hmmm….

So what is it you want to know that we can try to help with?