Modification to the SunLight entity

[Fireblade]

I would like to perform an alteration to either the SkyDome entity or the SunLight entity to have a dynamic sunlight effect.

How difficult would it be to add the functionality of the SunLight entity into the SkyDome entity and be able to use the skydome script files to control the SunLight portion (such as matching twilight coloring, and an overcast effect when the DisableSun flag is set, etc,). Also, using the SkyDome scripts would eliminate the need to tamper with the editors' entity definition file.

If that isn't possible, I have another approach;

Would it be possible to add a field to the SunLight entity (useSkyDomeAngle(flag)) that replaces the angle field with a the angle of the SkyDome entity's origin and sun position?

Personally, I prefer the second option.

How would I go about achieving either of these two effects (locations of the SkyDome and SunLight entities' source, recommendations, etc,)? I have taken classes in C++ and I'm not afraid of coding projects like this. I've also successfully compiled RF in the past.

If I can successfully get this done, I will submit the changes to the RF team for everyone to use; no point in keeping something so cool to myself

Any and all help would be greatly appreciated.

[Jay]

You know it's kind of funny, i posted the same thing on Feature Requests 3 or 4 years past.
gekido said a few things to me about the impossibility of this...in the end he was right - The original engine wasn't supposed to do this and so this would eat the performance.

I had an approach that would use kind of static shadows which are then computed by the sin/cos of a triangle and so forth...(work a bit like stencil shadows). However, i couldn't program it so the idea was dropped.

Doing it the way the engine normally handles kills every bit of performance we once had:

The main problem, like said above, would be speed - You cannot simply alter all lightmaps or vertex colors of a map at one time and think that it doesn't have any efect on the framerate.

Think of it like that: the SunLight-Entity is mainly precomputed lighting. Recomputing the lighting of the whole level every frame takes a whole lot of work...

But i have a different approach now. But warnings: It may be really slow.

You could do it that way (rendering of one single triangle):

First you have to get the 'angles' of the triangle.
Then you calculate the difference between the angles of the Sunlight and the triangle. These will be the angles for the light.
If one of these angles is smaller than 0, drop the triangle.
If one of these angles is greater than 180, drop the triangle.
These are speed optimizations and also prevent that the other sides of the triangles get darker afterwards then they were before.
You divide each of the angles by 180 and multiply the angles with each other(x*y*z) (alternate you can also multiply them first and then divide the value gotten by 5832000, which is the same, because 5832000=180*180*180; this is also faster)
Afterwards you multiply the now gotten value by 2Pi. This is because of math because 2Pi represents 360 degrees in when you take the sin(), cos() or tan() of something;
Then you take the sin() of this value to interpolate the value.
You multiply this value with a set value (aka the brightness of the SunLight) and add it to all three vertex colors in order to brighten the face.

Or you port the engine to DirectX9 and use directional lights.

Pseudo code: (This is ALL pseudo code, i don't have any clue how the engine does this. Some poeple understand things better if they are written in c/c++...)

Code: Select all

#define X 0
#define Y 1
#define Z 2
float triangle_angles* = GetTriangleAngles(&triangle);
float SunLight_angles* = GetSunLightAngles(&SunLight);
float angles[3];
float last_angle;
angles[X]=(*+X)triangle_angles-(*+X)SunLight_angles;
if(angles[X]<0 | angles[X]>180)
   return false;
angles[Y]=(*+Y)triangle_angles-(*+Y)SunLight_angles;
if(angles[Y]<0 | angles[Y]>180)
   return false;
angles[Z]=(*+Z)triangle_angles-(*+Z)SunLight_angles;
if(angles[Z]<0 | angles[Z]>180)
   return false;
//free memory
delete triangle_angles;
delete SunLight_angles;
last_angle=(angles[X]/180)*(angles[Y]/180)*(angles[Z]/180);
//This is when you want to interpolate the value geometrically, leave it 
//out if you don't need this. It is then interpolated linear.
last_angle=sin(last_angle*M_2PI);
triangle->vertices[0].color+=ARGB(0,SunLight->GetBrightness(),SunLight->GetBrightness(),SunLight->GetBrightness());
triangle->vertices[1].color+=ARGB(0,SunLight->GetBrightness(),SunLight->GetBrightness(),SunLight->GetBrightness());
triangle->vertices[2].color+=ARGB(0,SunLight->GetBrightness(),SunLight->GetBrightness(),SunLight->GetBrightness());
//do this for every triange in the whole viewort and you are fnished...

And then of course, this has to be added to the SkyDomeEntity also....

Uff i just hope you understood that that was really something to think for me....*headache*

[Fireblade]

Doing it the way the engine normally handles kills every bit of performance we once had:

The main problem, like said above, would be speed - You cannot simply alter all lightmaps or vertex colors of a map at one time and think that it doesn't have any efect on the framerate.

Think of it like that: the SunLight-Entity is mainly precomputed lighting. Recomputing the lighting of the whole level every frame takes a whole lot of work...

Since sun movement is hardly noticable to begin with, couldn't the lighting/shadow be redone every few seconds instead of every frame? I'd have it redone every 10 to 300 seconds, even using self.daytime as the timer for something like this:

Code: Select all

// sunlight.update is the rate in seconds at which lighting is redrawn
if self.daytime % sunlight.update = 0
{
     do update
}

Also, sunlight rendering can be manually set to disable at the darkest parts of night via the enhanced skydome script.

Any new possibilities here?

Note: % (modulo) is used to find remainders and returns an integer

Also, that pseudoscript looks prety nice

[GD1]

You know it's kind of funny, i posted the same thing on Feature Requests 3 or 4 years past.
gekido said a few things to me about the impossibility of this...in the end he was right - The original engine wasn't supposed to do this and so this would eat the performance.

I actually remember that topic.

I guess the main problem is that RF's lighting is static. In order to get smooth lighting, you have to break every piece of geometry down into individual polygons that are lit per-vertex. RF has to keep track of EACH of these polygons individually when we use Dynamic lighting, which more than doubles the slowdown caused by the polygons themselves. So without re-writing RF's dynamic lighting system, I'd say this idea is completely intangible, even if we could get the Sunlight entity to work dynamically.

[psYco]

w8 we have the ability to make things move in the editor on a timer rite? And we have a dynamic light entity now this is a shot into the blue, cause i actually dont know much about the way te engien works and even less about programming, but from a purely level desigher point of view cant we make like a model that would then based on a timer move across the sky like 'the sun'>>??? and then attach a Dlight to it? and mabey a dynamic fog light to make it look all cool? Pls tell me to shut up if im being stupid but this seems logical to me...

[Jay]

Yes it's possible but it wouldn't look like a SunLight Entity. It shows fairly good results though. I have done this once. The 'older' users may remember the picture with the 4 little pictures showing a village in morning, midday, evening and night which i posted almost at the same time when istarted the topic with the DynamicSunLight-Entity. Sad i have lost this picture


Maybe the more easier solution may be to make the 'Sun' and the 'Moon' of the Skydome EntityNames where Entities can be attached to. Then we could attach a Corona and a DynamicLight with nearly infinite range to it and see what happens

[QuestOfDreams]

Since dynamic lights in Genesis3D are updating the lightmaps a dynamic sunlight (which would have to update most of the lightmaps in a level) would be very very slow...