• Create Account

# RnaodmBiT

Member Since 27 Nov 2010
Offline Last Active Dec 19 2013 04:11 PM

### In Topic: Deferred shading and point light range issue

18 December 2013 - 04:48 PM

``` vec4 CalcPointLight(vec3 worldPos, vec3 normal)                                                                        \n \
{                                                                                                                       \n \
vec3 positionDiff = (UnifShadingPass.mLightPosOrDir.xyz - worldPos);                                                   \n \
\n \
float dist = length(positionDiff);                                            \n \
\n \
float attenuation = clamp(1.0 - (dist / UnifShadingPass.mMaxDistance), 0.0, 1.0);                                                                                                                   \n \
vec3 lightDir = normalize(positionDiff);                                                                             \n \
float angleNormal = clamp(dot(normalize(normal), lightDir), 0, 1);                                                   \n \
\n \
return angleNormal * attenuation * UnifShadingPass.mLightColor;                                                      \n \
} ```

That *should* do it, note how the formula is a little different, also the clamp will tidy things up a little bit. As for your falloff you will need to form some kind off function to get you a desired curve.

### In Topic: Deferred shading and point light range issue

18 December 2013 - 03:17 PM

It is because you are calculating your light strength at each pixel as 1/r^2 which is physically correct, but when using point light volumes as you are results in the shown issue, There are two options:

1) Change the light strength to being 1 - dis / maxDis which will give you a linear light strength to the edge of the lights 'radius' but isn't physically correct

2) You can change the light volume from being a sphere at the lights position to being a fullscreen quad. This essentially will calculate the light strenght for ALL pixels which is physically accurate since light strength is an inverse squared relationship (1/r^2). Since 1/r^2 will never actually be 0 then your point light will have even a tiny effect on pixels extremely far away and a large effect on very close pixels.

I hope that explains your issue.

### In Topic: Convex Polygon SAT Collision

12 October 2013 - 03:59 AM

I made a half-baked physics engine a few years back using C# and XNA. When I did it I stored all the points of the polygon in a simple list, such that p0 -> p1 formed an edge and p1 -> p2 formed the next edge. You just have to make sure they are all clockwise or counter-clockwise otherwise you will end up with weird shapes.

In 2D space the normal of a line is another line perpendicular to it. So using this you don't actually have to store the normal, you can determine it from calculations as you need it, but it will need to be as a Vector2 as that is the correct way to do the projections you will need.

### In Topic: Many-worlds interpretation

06 October 2013 - 02:23 AM

If you were to literally incorporate many worlds, then whenever there is a probabilistic even in your game, you need to clone the game world n-times, once for each possible outcome, and then continue the simulation for each branch. After just a small number of events, you've got billions of copies of your game running, with no one true version of events, which doesn't sound useful!

This isn't necessarily true as you could store the events as they happen, a very primitive example is actually the ability to undo changes made when editing a document (and to a certain extent, redoing them also. You've probably noticed that once you go back, make a change, you can't redo any undos from the previous branch). So long as you can convert all the important things into functions of time so you can get their values when not sitting on a key-event, you could essentially store the world based on the events that happen. As to which world is the 'true' version, one possible solution is that you can only jump back in time, which means you can edit something in the past which changes the future but once you have jumped back in time, you would then have to proceed naturally again. You could potentially include the option to simulate forwards in time without considering how the user might influence the world which would allow for travel forwards in time but that could be potentially tricky (i.e. what if the player gets killed?). Thinking about it, a save point in a game is actually very similar to what I am describing, but that's just one way of looking at it.

I was under the impression Time Travel would be harder if the Many-Worlds theory was correct. Because you would have to specify what universe to be in unless it's set by default.

It really depends on how you want to implement it into a game, personally I think it has amazing potential, but it does for the most part only seem reasonable in single-player or co-op modes, although the aforementioned Achron game seems to have done a nice job of using it.

### In Topic: Many-worlds interpretation

05 October 2013 - 10:11 PM

I have often thought about this myself and my personal take on it would be time travel.

Consider playing through a game, reaching some climactic point, realizing you are in a spot of trouble, being able to 'jump' back to a previous point and alter the flow of events, the key part being that you could make it better or worse. You would have to limit this ability some how.

A good example of this is http://www.achrongame.com/site/

They have a full RTS game with this ability allowing you and your opponent to battle it out across the four dimensions.

If you could create some form of fast procedural world development system you could jump through time altering events such as sparking a war between two countries to change the face of the world. It has enormous potential as a gameplay mechanic but will be very difficult to implement in a fair manner.

PARTNERS