Hey, here's my attempt to upgrade the Blender 2.4 convex hull script to Blender 2.6x

http://www.pasteall.org/29606/python

The past week and this week I have working on getting my program to be able to load and create multiple vector fields dynamically. I am also working on adding different properties to these vector fields so that forces can be applied to different objects and a direction property will also be applied to the velocity of different objects. I am trying to find other properties that could be useful to better represent an underwater simulation.

Andrew Harmon - Weekly Report #4

This week I've been working on attempting to combine textures with lighting. The first step is to send the texture coordinates from the model into the shader. Within the shader the vertex input will be the color, position, and world normal. The vertex output will be the same. They should look like this...

struct VertexShaderOutput
{
float4 Position : POSITION;
float3 WorldPosition : TEXCOORD0;
float3 worldNormal : TEXCOORD1;
float4 Color : COLOR0;
};

struct PixelShaderInput
{
float4 Color: COLOR0;
float3 Position: TEXCOORD0;
float3 worldNormal : TEXCOORD1;
};

In the pixel shader the texture coordinates will be added to the lighting to create the look of a texture in a naturally lit environment. Here's a link that I found helpful. http://digitseven.com/texturing.aspx

Weekly Report (Feb 25)

This week had a few issues come up while combining projects. Making the FMZ's convex in Maya is harder than it looks. However, I did find an "ancient" python script for Blender 2.4 that creates a convex hull--and on a test, it worked! I'll look over it to make an updated script for Blender 2.6x, but I'll need a little time--especially given some other endeavors that require attention.

Also, something is wrong with the NPCs' motion paths. Occasionally, they just wander out into space.

-Jason

If anyone is looking for the Convex Hull Script, I found it within this forum:

http://blenderartists.org/forum/showthread.php?65972-Espresso-v1.1-(full-source)&p=610630

Weekly Report (Feb 24)

I've been combining my two projects together, so that magnetic surfaces and block pushing can both be used. However, I have been having issues with getting the block pushing to work right. For some reason, the camera won't interpolate correctly and then the game soft-locks. To try and fix this issue, I've basically doubled all of my variables that have to do with collision - one set for the walls, and the other set for the blocks. I'm getting closer, but there are still problems.

Weekly Report (Feb 18)

Hey, Jason here.

This week was uneventful--although I was trying to resolve an issue with the NPC's facing and the Bezier paths, it did not work out.

I uploaded last week's more stable version to our new svn server.

Here is the math I used to make the middle Bezier control point formula--in case someone sees what I missed.

The goal is to complete:

B(t) = (1-t)(1-t)a + t(1-t)b + t*t*c

given that I know B'(t) for t=1 and t=0, a, and c.

I was using the derivative to solve for b because t=0 should be startT and t=1 should be endT:

B'(t) = 2(1-t)(b-a) + 2t(c-b)

startT = 2(b-a)

=> 0 = 2(b-a) - startT

endT = 2(c-b)

=> 0 = 2(c-b) - endT

2(b-a) - startT = 2(c-b) - endT

startT - endT = -2b+2a +2c-2b

startT - endT = 2(a + c) - 4b

4b = 2(a + c) - startT + endT

b = (2(a + c) - startT + endT)/4

I could have made an error on campus--I'll check on it Monday.

Andrew Harmon - Weekly Report #3

One interesting thing that I did recently that someone could possibly find useful was creating a fog affect in an underwater ocean scene. The basic concept is that the further an object is from the camera, the more the color changes from one to another. So in a way the scene becomes kind of like a 3D gradient.

The changes that need to be made will take place in the fragment or pixel shader. First you must initialize your fog color, as well as the fog start distance (where does the change of color begin to take place in relation to your camera) and also the fog end distance (at what point is there no longer a change in color based on distance).

The remaining bit of code looks like this.

float diffuseIntensity = saturate( dot(-lightDirection, input.WorldNormal));   
float4 diffuseColor = lightColor * diffuseIntensity;  
float4 specularIntensity = specularColor *  pow( saturate(dot(input.refractVector, input.directionToCamera)), 1.0);   
float l = saturate((input.Position.z - FogStart) / (FogEnd - FogStart));

return float4(lerp(input.Color,FogColor, l));

input.Position in this case is the camera position. You will use this to figure out how far the pixel is from your camera. And based on the you will use the lerp function to effect the color based on "l". (that is an l as in lion, not the number 1)

You will then return color based on the calculation.

Weekly Report

This past week I have worked on getting my code to work to get the water simulation to work. I have used that content processor to load the models ( cube and cylinder).  In the update function I define a zone for each shape with its vertices. To decide how the cylinder's velocity is affected, I check how many vertices of the cylinder are in the cube zone and multiply the percentage by a velocity change. So when the cylinder is within the cube its velocity changes. I have added another cube to get the cylinder going back and forth between the two cubes.

Weekly Report (Feb 11)

Jason here,

This week, I discovered and resolved issues with the nav graph generation method. The biggest problem was occurring when nodes that should have been navigable were not usable; the graph generator thought they had already been traversed.

Also, NPCs can move along Bezier curves, but it could use some tweaking as far as their ability to turn around goes: as NPCs move along the path, their direction is not completely related to their movement direction--this was done in order to create a smoother transition between portals: it appears more continuous in that case, but looks terrible when they need to turn around.

I am not sure what next week's plans are--if the group will be combining the projects, then that will be the focus, but if not, then I will direct my attention to implementing the NPCs' various states and movement behaviors--so far, these states include things like: retreating, attacking, evading, moveToLocation, following, wandering, and idling.

I had been thinking about these behaviors, and I believe that it would be interesting if the NPCs had their own hierarchy in which they may hunt each other as well as the player.

This applies mainly to Myriem, Matthew, and me: make sure the objects that you create code for can be loaded dynamically from an Autodesk fbx file, a text file, or some other medium that is not compiled into the game; I'll be choosing fbx format mainly because model editors can function as our level editors.

I already proved the feasibility of the concept with the nav graphs, and it makes it easier to make levels in the long run.

I can give advice on how certain elements could be loaded if you all want me to.

Later

Weekly Post 2

This past week decided on what bounding volume to use to represent represent the sub and sea creatures.  I decided on multiple bounding spheres.  I used Maya to place spheres that approximately fit to a shark model.

Then XNA fits bounding spheres to each mesh. I do collision detection on the bounding sphere for the shark mesh first and if a collision occurs then I check for a collision with the smaller, more accurate spheres.

Andrew Harmon - Update #2

A simple solution I found for creating a caustic effect on objects is by first creating a wave function like this one.

float wave(float x,float y,float timer)

{
  float z = 0.0f;
  float octaves = 5;
  float factor = 1.0f;
  float d = sqrt(x*x+y*y);

 do {
     z -= factor* cos(timer*0.001*speed+(1.0f/factor)*x*y*wavesize) *
         0.3*sin(timer*0.001*speed+(1.0f/factor)*x*y*wavesize) * 0.8*sin(timer*0.001*speed+       (1.0f/factor)*x*y*wavesize);
 factor = factor/2;

octaves--;

} while (octaves > 0);

   return 2*amplitude*d*z;

}

This function will update be used to change the normal of triangles made up by the vertices in your scene. The triangle normal will be multiplied by the world normal, and then the world normal will be used to adjust the reflection and refraction vectors These values will be used to ultimately change the diffuse color of the object, and the specular intensity. . Here’s an example of how I did it.

float4 worldPosition =  mul(float4(position, 1.0), world);

float3 reflectionVector = normalize(reflect(-lightDirection , worldNormal));

float3 directionToCamera = normalize(cameraPosition - worldPosition);float3 refractVector = normalize(refract(-lightDirection, reflectionVector, 0.333));

float diffuseIntensity = saturate( dot(-lightDirection, worldNormal));

float4 diffuseColor = lightColor * diffuseIntensity;

float4 specularIntensity = specularColor *  pow( saturate(dot(refractVector, directionToCamera)), 1.0);

Weekly Report (Feb 4)

Last night, I finished the recursive algorithm that generates the next hop information for each Free Move Zone (FMZ), destination, and portal. It loads an Autodesk fbx environment using the content processor, and, based on some mesh naming conventions, it automatically generates the FMZs and portals within XNA. I had been fighting with simple issues--like accidentally resetting the center point of my portals--but now it is good to go. Here's the reasoning behind next hop forwarding:

• Each FMZ (f) has a set of portals (p) that lead to other FMZ's
• I go through every other FMZ (g) and I use A* to find the shortest path to each zone in g after going through each of the portals in p.
• If you cannot navigate to a zone from a portal in p, it is assigned a distance of -1, and otherwise, it is assigned the distance that is measured between portals until you reach the zone (adjacent zones in f and g have distance 0 because they share a portal).
• Using this information, I can determine the fastest route to a point within a destination FMZ given a point that is within the starting FMZ.

Later today--to make doubly sure I don't get behind--I'll be making some simple NPCs navigate between areas--to start off, they will only move in straight lines between portals to reach the center point of some zone or another.

I'll post some code samples for both topics after I make sure the NPCs navigate well.

Signing off,

Jason

2/3/12 Weekly Post

This week I have worked on refining my engine for block pushing. It's finished now, and you can grab the code here. The camera now interpolates to face the direction of the block you are going to push. Also, it intelligently picks which block to push based on which one you are facing, and if you are facing it at a shallow enough angle.

There is a simple HUD as well that shows the player's coordinates, as well as if you meet the requirements for pushing a block and if so, the block's coordinates as well.

Next week I will begin developing new mechanics that are equipment based, to get us closer to developing actual puzzle sections of the game.

-Matthew