# Tag Info

31

Real-life soft shadows have a shape that depends on the shape of the light source as it appears from the point of view of the shadowed surface. This is because penumbras occur due to partial occlusion of the light source from the shadowed surface's point of view. The shape of the shadow is therefore something like the shape of the occluder convolved with ...

23

This is simply a kind of optimization given that invSqrRadius = 1/SqrRadius, instead of calculating the inverse squared radius for each light every time they simply cache it, the reason is that division is usually a "slow" operation at least when compared to multiplication. This optimization is relevant especially: when the operation is done a huge amount ...

7

You can also do it without code. Attach the point light to your Cube object and set its relative position.

6

The other answers here dealt with the inverse square radius, but I'm going to look at the squared radius instead (which concept3d touched on, but I believe it merits further discussion). What squares are useful for is distance comparisons. We know that calculating the distance between two points involves a square root, and square roots are expensive to ...

6

6

At midday, RGB of (1,1,1) or plain white light. At sunrise, a little more blue looks pretty good. Tweak until you have good results. At sunset, a lot more red looks good. Tweak as above. At evening or night, go with a dark blue. This isn't really based in reality but it's common enough.

5

The most efficient way to do that would be to not do that. If you have a scene where you want 200 lights to affect an object, you can't use forward rendering anymore. Also, as a practical matter, I'm fairly sure that quite a lot of GL 2.x hardware couldn't handle a uniform array of 400 vec4s. And even if you could, your shader would probably choke ...

5

The default equation for attenuation f(x) = 1/( distance ^(exponent) ) from the images doesn't seem UDK is doing anything differently.

4

The simplest way to do this, is to make the light a child of the character. Position the light where you want it to be in relation to the player, then in the Hierarchy view, drag the light so that it becomes a child of the player. Now when the player is moved, all of its children are moved as well (including the light). Another option is to use one of ...

4

There are the fixed function and programmable shader pipelines. This is much bigger than just lighting, chances are your learning a whole bunch of other outdated stuff. The following are some common functions that are now deprecated: glBegin(...) glEnd() glVertex* glNormal* glColor* glTextCoord* glMultiTexCoord* glLoadIdentity* ...

4

Your main issue is that you need to fix your normals. If you want to calculate smooth normals correctly please check my answers here and here. Also make sure that your normals are normalized. Your second issue is your attenuation values, I often get better results with one attenuation type. So try to use one type of attenuation and try to modify its value ...

3

That depends. Our perceived color of the sun depends on a variety of factors -- the color we observe is due primarily to the scattering of the light in the atmosphere, so the content and quality of the atmosphere has an impact along with the sun's relative position in the sky. Wikipedia's article on color temperature has some reference values for the sun, ...

3

Generally speaking, most people plug in a 45 degree angle in for the FOV. If you do this, a camera is then usually positioned just far enough away to include everything in the scene. No default on this distance because scale is so arbitrary in a 3d virtual world. There is a concept of a default lighting rig where you have 3 directional lights. One lighting ...

2

Does section 27-1 of the following article help? http://http.developer.nvidia.com/GPUGems3/gpugems3_ch27.html I used this a while back and it worked perfectly, the type of projection (orthographic Vs perspective) should not be important as long as you can calculate the inverse view projection matrix.

2

You could provide players with some easy to obtain equipment to see in the dark (a torch, for example), but discourage its use for advanced players by making other equipment options available which result in superior character performance, but do not have the light perk. An easy to acquire torch, for example, could be useful as a weapon itself in the ...

2

You could have alternative, very short, vague descriptions of locations for use at night. Also available interactions with elements of the room could be different. This way the player could be able to for example notice that there is some road sign pointing to some important location (which might be the city) and during day the player could be able to read ...

2

I've already found some time and solution to my problems and I want share it with you. Maybe it will help someone: float distFromCentroid=ACamera.far(); camera.setLookAt(frustum_centroid+dir->direction*distFromCentroid,frustum_centroid); for(int i=0;i<8;i++){ point[i]=ACamera._point[i]*camera.matrix; } min=point[0]; max=point[0]; for(int ...

2

Actually Lights does not contain colliders, but what you can do is add a CircleCollider2D component to a light, then track if your object collide with the collider of this light and only then trace a ray from your object (character) to the light, if the ray hits a collider before hitting the light then you know your character is in the shadow part of this ...

2

The problem is on the line if(Time.time()%120==0) By doing that, you divide the timestamp by 120 and then compare if the decimals are zero. That will happen really rarely as the timestamp will have quite a lot of different values. What you should do instead is to calculate the colour every frame. Perhaps something like this will do: void Update() { ...

2

The normals facing away from the camera are shaded black in your setup. Add more lights into the scene that are shining on parts you want lit up, or set up the lighting with a brighter minimum brightness.

2

That simple lighting does not know anything about other objects in scene, nor shadows they cast. It just does the lighting knowing the light position and surface normal (and eye position for specular). That's it. No occlusion info, no light refraction, no reflection, no anything, just lighting. If you need object shadows, there are separate techniques for ...

1

I can give you an answer for what concern forward rendering and Cg shaders. In the shader first pass (BasePass) Unity set uniforms value of the 1 important directional light and up to 4 vertex lights. Base Pass (Directional per pixel light) uniforms: _WorldSpaceLightPos0 : position in world space of the first directional light _LightColor0 : color of the ...

1

Many games nowadays use both specular maps, which control the intensity of the specular reflection, and shininess maps, which control the size of the highlight. With Phong or Blinn-Phong shading, an increasingly common way to do this is to use an exponential mapping: specularPower = pow(2.0, 13.0 * shininessMap) Often times this is called a "gloss map", ...

1

XMFLOAT3 dir((float)pitch, (float)yaw, (float)roll); XMVECTOR center = XMVectorSet(eye(0), eye(1), eye(2), 0.0); // Se the center to the eye XMVECTOR lightDir = XMLoadFloat3(&dir); XMVECTOR lightPos = (radius * lightDir) + center; // Add the center XMVECTOR targetPos = center; XMVECTOR up = XMVectorSet(0.0f, 1.0f, 0.0f, 0.0f); XMMATRIX V = ...

1

It looks like your geometry may be made of unwelded boxes and you're using smoothed normals (soft edges). If my guess is correct, then the lighting looks off because the smoothed normals point outward from the corner of each box and therefore don't match the flat surface created when you place two boxes next to each other. Try using unsmoothed normals ...

1

One solution Use an odd number in your power function (or some other function that keeps the sign of your previous specular intensity): light_specular_intensity = pow(light_specular_intensity, 9.0); light_specular_intensity = pow(light_specular_intensity, 7.0); There may be other ways to perform the math such that you may still use an even power. The ...

1

The dot product of the each face's normal with the vector from the face to the light position should distinguish which faces are front/back.

1

There is a skybox shader that blends between two sets of skybox textures. Think day and night cycle! If you want to build or animate the skybox from script, use skyboxmaterial.SetFloat("_Blend", yourBlend) to change the blending; can also use SetTexture material functions to setup or change the textures. Video tutorial about day/night cycle: ...

1

I want to answer my own question because i think that after reading some article about it, considering the kind of hardware available on the market, there is no point that can lead me to adopt a fixed pipeline instead of a programmable pipeline based on the shaders. So even if you are targeting an hardware that can let you choose between a fixed pipeline or ...

1

Check your normals! In the first image, each face has three vertices with the same normal as the face. These vertices are not shared between faces. In your data, each vertex is shared by multiple faces. As such, it has a normal computed from the average of the normals of all the faces it's connected to. You need to re-export your data, to get the normals ...

Only top voted, non community-wiki answers of a minimum length are eligible