Jump to content

  • Log In with Google      Sign In   
  • Create Account


AverageJoeSSU

Member Since 30 Jun 2007
Offline Last Active Jul 07 2014 03:14 PM
-----

Topics I've Started

Calculate Position as 0 to 1 between two planes.

12 February 2014 - 06:44 PM

I'm struggling to understand the equation on page 55 of the following paper.

 

http://web.cs.wpi.edu/~rich/courses/imgd4000-d10/lectures/camera.pdf

 

the previous page 54 explains the premise behind the equation.

 

Here is my code in Unity3d to try and reproduce it:

zForward = new Vector4(gameObject.transform.forward.x,gameObject.transform.forward.y,gameObject.transform.forward.z,0);
        plane = new Vector4(gameObject.transform.up.x, gameObject.transform.up.y, gameObject.transform.up.z, 0);

Vector4 playerPos = new Vector4(player.transform.position.x,player.transform.position.y,player.transform.position.z,1);

Debug.Log(Vector4.Dot(plane,playerPos)/Vector4.Dot(plane,zForward));

gameObject has a collider that is triggered when the player walks in it. I then try to calculate the field from that paper...

 

The author suggests that the math in the equation is wrong, but i'm not sure what he is trying to do WITH that exact math there. seems to me like it is missing some sort of position or something of the plane??? just a guess.


Reflecting on implmenting coroutines in a massively state driven game.

06 February 2014 - 12:20 PM

I am full steam ahead with a game I am making with a team, and we are approaching the point of no return on one of our subsystems/architectural choices, and my lack of experience with it is frightening me.

 

It is Coroutines. We have implemented our state management using coroutines, and while i feel we have an excellent grasp of exactly how Coroutines in Unity behave, I am not, as you would say in poker, "all in" quite yet.

 

The main thing that bugs me, is that while Coroutines make state switching so so easy, there are a couple of operations that become non trivial (at least i think they are non trivial, maybe I'm wrong). The best way to describe our implementation using Coroutines is that it is a State Stack, with the option of having another state run in parallel. This description is terrible as the very word "State" is misused, but alas i think you get the point.

 

The issue at hand with a State Stack is our ability to plain ole switch to x state from y state where y is not above/below x on the stack.

 

It requires a check in every state between the two in order to make that switch. Now, in a JRPG, this might be fine, as mostly you progress from one state to another, and in a very few cases need to change to something as I previously described.

 

To that end i have provided an interface IState, which has prepare, validate, and clean methods. Every state in the game must prepare values for the state to run, and every frame validate that it is the correct state to be in, and on exit, clean itself up. The saving grace of the above is the Validate() method, for it will allow multi-state traversal across a stack. And if we take care as to how we cleanup a state (for example all Major state transitions: ExploreMode, CombatMode, WorldView Mode, Menus. If all of these modes cleanup with fading out the camera, then theoretically they all can go from one to another with no problem.)

 

Anyways, I certainly do not want to turn this into a rant smile.png. Thanks for reading and any thoughts are welcome!


Modelling Stylized "high fidelity" environments for games.

26 November 2013 - 01:15 PM

I'm a bit surprised at how little information there is on this.

 

Perhaps because it is lumped in with general modelling techniques, but I find that when it comes to modelling a "game level" there are a lot of things that are just different.

 

Of course a lot of tips can be found on Valves modelling reference wiki:

https://developer.valvesoftware.com/wiki/Category:Level_Design

 

But when it comes to the modelling aspect of it, what are some good things to take into account?

 

I use Maya and Zbrush. I can create high detail models all day in zbrush, but can get in trouble if i dont provide a base mesh first. And Zbrush is getting so fancy now with panel loops and things, that i can easily, drastically change the topo of a mesh with high fidelity detail. I'm sure that i could just go back to the base mesh and move it around, but is this the "correct" way to do things?

 

I've heard that good environments are simple in areas that are not the focus of the player and complex in areas that are.

 

I've also heard that simple color palletes (maybe a little more saturated too?) help achieve a clean look.

 

Also, what about keeping a room a singlular hull of geometry? is this really neccessary?

 

Any other tips would help a great deal. I am between intermidiate and noob with Maya and Zbrush when it comes to flat out modelling stuff.

(i know how to rig and animate).

 

Thanks!


How do you convert World Position to Field of View angle.

16 August 2013 - 07:41 PM

I am doing some camera calculations and would like to convert the target's world position into Offset angles from the center of the screen, based off of the veritcal and horizontal Field Of View.

 

this picture explains what I am after:

 

Attached File  FOVAngles.png   1.03MB   7 downloads

 

I tried getting spherical coordinates by converting cartesian to spherical, but it isnt exactly right, since i want them to be offsets from the center of the screen and those angles are not. I AM able to convert any viewport point to offset angles, and could convert the target to a viewport point as well, but that would get weird results when the character is not in the field of view.

 

Maybe i can add an offset to theta of the spherical coord to get its orgin at the center of the screen?

 

Here is code i have so far which i know is wrong but will provide context with what i am attempting to do.

Vector2 zeroOffset = new Vector2(CameraGame.HorizontalFov / 2, Camera.main.fieldOfView / 2);

        Vector3 charPosViewSpace = Camera.main.worldToCameraMatrix * target.position;
        charPosViewSpace += Camera.main.transform.position;

        //Convert View Space Postion to Spherical Coordinate.
        float r =
            Mathf.Sqrt((charPosViewSpace.x * charPosViewSpace.x) +
                       (charPosViewSpace.y * charPosViewSpace.y) +
                       (charPosViewSpace.z * charPosViewSpace.z));

        float S = Mathf.Sqrt((charPosViewSpace.x * charPosViewSpace.x) +
                             (charPosViewSpace.y * charPosViewSpace.y));

        float phi = Mathf.Rad2Deg * Mathf.Acos(charPosViewSpace.z / r);
        float theta;
        if (charPosViewSpace.x < 0)
            {
            theta = Mathf.Rad2Deg * (Mathf.PI - Mathf.Asin(charPosViewSpace.y / S));
            } else
            {
            theta = Mathf.Rad2Deg * Mathf.Asin(charPosViewSpace.y / S);
            }

        Debug.Log("xAngle: " + theta + " yAngle: " + phi);
        Debug.Log("SafeZone: " + SafeZone);

Here is how i get viewport coords to FOV angles:

public void calcAngles()
        {

        Vector2 zeroOffset = new Vector2(CameraGame.HorizontalFov / 2, Camera.main.fieldOfView / 2);

        minRange = new Vector2(CameraGame.HorizontalFov * x1 - zeroOffset.x,
                                       CameraGame.HorizontalFov * y1 - zeroOffset.y);
        maxRange = new Vector2(CameraGame.HorizontalFov * x2 - zeroOffset.x,
                                       CameraGame.HorizontalFov * y2 - zeroOffset.y);
        }

Question on Calculating Camera For Dynamic Camera System (GOW Talks)

03 August 2013 - 02:12 AM

I've dived in to the PDF's for the Dynamic Camera System from the God of War series.

 

I've mostly got it setup in Unity,

 

Except there is no mention of exactly how the internal values are used to calculate the transform of the camera. The values are as follows:

 

"the angle from the look vector of the camera, to the target. This is a 2d diagram, but in 3d this is a

pair of angles, from the horizontal, and the vertical, in camera space. We use the angles, so that we
can easily represent the cases where the target is behind the camera. It also makes it easier to
apply the safe zone constraints, as these are internally represented as a pair of angular ranges in
the same space.
* the angle of the camera to the world, again, 2d diagram, consider that dotted line to be zero
degrees. In 3d we use an euler, because they
ʼ
re easy to manipulate and visualise.
* and the distance to the target plane"
 
Any Ideas?
 
The PDF is here:

PARTNERS