sun position with sunshader parameter

(Machine for to kill) #1

Is there a way to specify where the sun image is going to go when using sunshader. I though by default it would put it where the light source is supposed to be (from q3map_sunExt) but it didn’t. So how can I specify the location of the sun image in the sky.

(ZoSo) #2

Try here:
http://fps.brainerd.net/light4.htm

(Machine for to kill) #3

No you missunderstood my question. I’m not talking about a general sun light effect. There’s a shader parameter called ‘sunshader’ that displays an image for your light source. It can be a sun, a moon…anything. But I’m not sure how you go about positioning this image in your sky. If you’re not sure what I mean then look at the siwa sky and the big sun it has.

P.S.
i know that website, it’s pretty good but a little outdated. check the q3map2 forum for recent improvements to the lighting system.

(zig-zag) #4

Zoso is correct in pointing you to there. The position of the sun shader
is determined by the q3map_sun parameters:

from oasis
q3map_sun 1.0 0.85 0.6 180 220 70

r,g,b,intensity, degrees, elevation

degrees: is the angle relative to the directions on the map file. A setting of 0 degrees equals east. 90 is north, 180 is west and 270 is south.

elevation: is the distance, measured in degrees from the horizon (z value of zero in the map file). An elevation of 0 is sunrise/sunset. An elevation of 90 is noon

(Drakir) #5

This is Copied from the shader manual that comes with Radiant! (In other words RTFM) :smiley:

q3map_sun <red> <green> <blue> <intensity> <degrees> <elevation>

This keyword in a sky shader will create the illusion of light cast into a map by a single, infinitely distance light source (sun, moon, hellish fire, etc.). This is only processed during the lighting phase of q3map.

<red> <green> <blue> Color is described by three normalized rgbvalues. Color will be normalized to a 0.0 to 1.0 range, so it doesn’t matter what range you use.

<intensity> is the brightness of the generated light. A value of 100 is a fairly bright sun. The intensity of the light falls off with angle but not distance.

<degrees> is the angle relative to the directions on the map file. A setting of 0 degrees equals east. 90 isnorth, 180 is west and 270 is south.
<elevation> is the distance, measured in degrees from the horizon (z value of zero in the map file). An elevation of 0 is sunrise/sunset. An elevation of 90 is noon.

DESIGN NOTE: Sky shaders should probably still have aq3map_surfacelight value. The “sun” gives a strong directional light, but doesn’t necessarily give the fill light needed to soften and illuminate shadows. Skies with clouds should probably have a weaker q3map_sunvalue and a higher q3map_surfacelight value. Heavy clouds diffuse light and weaken shadows. The opposite is true of a cloudless or nearly cloudless sky. Insuch cases, the “sun” or “moon” will cast stronger, shadows that have a greater degree of contrast.

Design Trick: Not certain what color formula you want to use for the sun’s light? Try this. Create a light entity. Use the Q3Radiant editor’s color selection tools to pick a color. The light’s _color key’s value will be the normalized RGB formula. Copy it from the value line in the editor (CTRL+c) and paste it into your shader.

(MindLink) #6

Guys, you didn’t understand his question. He didn’t ask about the lighting stuff but about the sun-(moon- or whatever)SPRITE that is visible in the sky (implemented by the sunshader directive). That sprite/shader is NOT positioned via the q3map_sunlight stuff but by some other to me unknown means (the sun/moon appears on a fixed position in the sky, no matter where you place your q3map_sunlights). He wants to know how to set that position, not how to set the position of the actual lights.
Can’t help you there mate though sadly, don’t know it myself… :confused:

(Machine for to kill) #7

yep that’s exactly what I’m asking about.

It might’ve been a better idea to post this question on the q3map2 forum so ydnar can look at it. he probably knows what the deal with it is.

I’ve examined the siwa sky shader carefully and as far as I can tell it does not have any information about the position of the sun sprite on the sky. Yet somehow the sun image is displayed at the appropriate position depending on the q3map_sun data. So one would think that it would be properly placed by default. However when i try to use that parameter in my map it is displayed in a random position. I think the fact that I am using q3map_sunext instead of the old q3map_sun might have something do to with it. maybe the sunshader parameter does not recognize the new keyword. I’ll test with q3map_sun to see if it works right.

(Machine for to kill) #8

ok it does seem that sunshader does not recognize the new q3map_sunext keyword and that’s why it wasn’t working. I tried it with the old q3map_sun and it worked fine. I should point this out to ydnar so he can fix it.

Thanks for helping

…now where is that turkey.

(psychosanity) #9

Well, it doesnt work for me even with the old Q3map_sun. Not only that, but I cant change WHICH “sun” is displayed. I can change the sunshader in goldrush’s sky to textures/bite_me and there’s still a nice, full moon at same 'ol position. I can control the LIGHT but not the moon… :banghead:

(EB) #10

How are you attempting this ?
Post ur codes.

(psychosanity) #11

Well, I’ve just cut and pasted the goldrush sky into my shader, and put it in my shaderlist…unchanged right now except for the shadername, you really want me to post it? I’m just saying that I can change the angle and elevation of the Q3map_sun straight from goldrush and the light that is shining down will change, but the moon itself does not, and nothing happens when I change the name for the sunshader either.

(EB) #12

I understand what u are saying…post the code that you were trying to use.

(psychosanity) #13

Well, okay:

textures/skytest/goldrush
{
qer_editorimage textures/skies/sky_8.tga
q3map_skylight 65 3
q3map_sun 0.3 0.3 0.45 60 35 45
nocompress
skyparms - 200 -
sunshader textures/skies_sd/full_moon2
surfaceparm noimpact
surfaceparm nolightmap
surfaceparm sky

skyparms textures/skies_sd/wurzburg_env/sky 512 -


{	fog off
	map textures/skies_sd/goldrush_clouds.tga
	tcMod scale 5 5
	tcMod scroll 0.0015 -0.003
	rgbGen identityLighting
}


{	fog off
	map textures/skies/nightsky1.jpg
	tcMod scale 10 10
	blendfunc add
	rgbGen identityLighting
}

{
	fog off
	clampmap textures/skies_sd/goldrush_mask.tga
	blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
	tcMod scale 0.956 0.956
	tcMod transform 1 0 0 1 -1 -1
	// rgbGen identityLighting
	//rgbGen const ( 0.6 0.6 0.6 ) 
	rgbGen const ( 0.4 0.4 0.4 ) 
}

}

there ya go…right out of the pak0.

(EB) #14

READ THAT AGAIN ! ( aka, not the default code…the one where your adjustments were NOT working.)
Geez…
The code that u were using to try and replace the sun image.

Are u ok ?

{post the shader that u used to try to replace the sun image. The only code that can help me help u.}

P.S. the one u said was unchanged at that point of your 2nd previous post.
—>>>WELL, change it back and post it.

(FireFly) #15

You should always use Q3map_sunext instead of Q3map_sun to avoid the “stadium lights” artifact.

According to Ydnar it is possible to have a sunshader with Q3map_sunext : http://www.splashdamage.com/index.php?name=pnPHPbb2&file=viewtopic&t=9783&highlight=q3mapsunext

(psychosanity) #16

OMG. Problem solved…?!

I had a copy of my shader script (named: Copy of skytest.shader) in the scripts folder, figuring the different name kept it nice and ignored, but guess what? Evidently the game engine used THAT instead…

Without that copy there…the sun moves, changes properly. Am I crazy, or is that wierd?

P.S. Sorry for the misunderstanding EB but you didnt have to be snide. Seems silly to post the code we all have when I only changed two numbers and a shader name. I was pretty sure that wasn’t the problem. My humble apologies.

(EB) #17

My apology too…but please understand that I had no idea of what you tried(specifically) and I began to worry if you could comprehend that fact…that is why I became ‘snide’.
-I mean yeah…why would I need a default shader ? > I wanted the one in which you changed the shader’s syntax.
I am glad you figured it out…need anymore help on this ? I promise I won’t be snide if you promise not to post default shader files !!! hehehehehe :drink:

(psychosanity) #18

:drink: No, I suppose I’m good on this now…but it’s strange that the copy interfered. Any thoughts on why?

(EB) #19

Could be a number of things…
1 thing to watch: no spaces in file names…use Underscores ( “_” )
I would also suggest using lower caps in all file names as well…as a good practice.

but again…it could be a number of things…

(kamikazee) #20

Ain’t it so that ET reads all .shader files?
If so, since they both contained the same shaders, (textures/skytest/<shader>) they interfered with each other, probably the “Copy of …” got loaded earlier as it’s higher up the list when it’s sorted alphabetically. Seems ET ignores the second time it loads the same shader.

The same applies to .pk3’s, I once packed a .bsp, changed the map, recompiled it and then tried to run that level. I allways got the packaged one, untill I changed the .pk3’s extension so it wouldn’t get loaded.