Monday, May 25, 2009
Sunday, May 24, 2009
org hungry, org want eat
So recently we've got the particles working, which has been an absolute pain to SORT out, excuse the pun.

Our main issues were with gamebryo's depth sorting and lack of support for most of maya's nifty particle features (maya being our 3D package of choice). Then there were the little things, like particle systems syncing themselves to the same play time, particle life span and emitter animations; it will ALWAYS look weird when bullet impacts sync themselves together so they can play at the same time regardless of creation. And finally no animated textures, and when animated textures were implemented no syncing to the particle animation; everyone likes an animated billboard looking out of place in a animation right?

Thanks to some lifesaving shader work from Josh we fixed our depth sorting issues and implemented our sprite sheet animated textures. And thanks to Eli and the discovery of NiPSEmitParticlesCtlr (time controller) hidden way down the .nif hierarchy (close to Atlantis I'm sure) we managed to fix our syncing issues.

As for our limitations with Maya, well... In retrospect the use of Maya for particle system creation probably was not the best choice (as gamebryos particle support for 3DSMax is exceptional in comparison). A large amount of fields and features (especially ramps over particle lifespans) were greatly missed (although ramps are VERY expensive to calculate on the fly), but with a lot of planning we were able to escape with some acceptable results.

Although we will be using 3DSMax to get some effects (streak particles... not supported with Maya, but are in 3DSMax ~strange) and some of the outcomes of our effects are less than desirable in certain situations (billboard explosions fail in nooks and cranny's).

Next was the implementation of a day night sky dome. The approach to this was very similar to layered paper. Clouds can animate around a center pivot following a spherical path, while the sky dome (which in this case is a sky sphere ~fancy) rotates slowly across it's x axis continually; wallah a dynamic sky. The changes from day to night are handled by a interpolating texture, keeping 4 stages for gradual texture change (day -> dusk -> night -> dawn) textures can interpolate to gives an even MOAR dynamic sky (lovely ^_^)
this is roughly demonstrated in my notes above (the images detail a bit of thought process, pretty diagrams and such... and a few doodles)

Tweaking shaders to get desired results is something we got on top of and sat on recently. Characters especially were something quite frustrating to get right. The behaviour of the rim light was much too strong and was awkwardly lighting characters feet (which looks funky in a dark environment as the character literally floats). After a little head scratching with shader sliders the conclusion was to include a height gradient to kill the rim lights influence closer to the feet (this gives the illusion that character slowly emerge from the darkness rather then floating ~huzzah chutzpah).

Finally, Level of Detail meshes. Thankfully this isn't something that causes brainpain (TM), as some earlier prototyping and research cleared up the programmatic implementation and the artist pipeline. Gamebryos support for Maya LOD groups makes LODing assets... well... easy? However connecting LOD meshes for characters to BoneLODs is a little (a lot) less forgiving for pipeline execution and looks like it could eat a little time in the future (oh dear).
And appropriate exit based off of the introduction
"HALT I AM REPTAR"

Our main issues were with gamebryo's depth sorting and lack of support for most of maya's nifty particle features (maya being our 3D package of choice). Then there were the little things, like particle systems syncing themselves to the same play time, particle life span and emitter animations; it will ALWAYS look weird when bullet impacts sync themselves together so they can play at the same time regardless of creation. And finally no animated textures, and when animated textures were implemented no syncing to the particle animation; everyone likes an animated billboard looking out of place in a animation right?

Thanks to some lifesaving shader work from Josh we fixed our depth sorting issues and implemented our sprite sheet animated textures. And thanks to Eli and the discovery of NiPSEmitParticlesCtlr (time controller) hidden way down the .nif hierarchy (close to Atlantis I'm sure) we managed to fix our syncing issues.

As for our limitations with Maya, well... In retrospect the use of Maya for particle system creation probably was not the best choice (as gamebryos particle support for 3DSMax is exceptional in comparison). A large amount of fields and features (especially ramps over particle lifespans) were greatly missed (although ramps are VERY expensive to calculate on the fly), but with a lot of planning we were able to escape with some acceptable results.

Although we will be using 3DSMax to get some effects (streak particles... not supported with Maya, but are in 3DSMax ~strange) and some of the outcomes of our effects are less than desirable in certain situations (billboard explosions fail in nooks and cranny's).

Next was the implementation of a day night sky dome. The approach to this was very similar to layered paper. Clouds can animate around a center pivot following a spherical path, while the sky dome (which in this case is a sky sphere ~fancy) rotates slowly across it's x axis continually; wallah a dynamic sky. The changes from day to night are handled by a interpolating texture, keeping 4 stages for gradual texture change (day -> dusk -> night -> dawn) textures can interpolate to gives an even MOAR dynamic sky (lovely ^_^)
this is roughly demonstrated in my notes above (the images detail a bit of thought process, pretty diagrams and such... and a few doodles)

Tweaking shaders to get desired results is something we got on top of and sat on recently. Characters especially were something quite frustrating to get right. The behaviour of the rim light was much too strong and was awkwardly lighting characters feet (which looks funky in a dark environment as the character literally floats). After a little head scratching with shader sliders the conclusion was to include a height gradient to kill the rim lights influence closer to the feet (this gives the illusion that character slowly emerge from the darkness rather then floating ~huzzah chutzpah).

Finally, Level of Detail meshes. Thankfully this isn't something that causes brainpain (TM), as some earlier prototyping and research cleared up the programmatic implementation and the artist pipeline. Gamebryos support for Maya LOD groups makes LODing assets... well... easy? However connecting LOD meshes for characters to BoneLODs is a little (a lot) less forgiving for pipeline execution and looks like it could eat a little time in the future (oh dear).
And appropriate exit based off of the introduction
"HALT I AM REPTAR"
Friday, May 22, 2009
Michael Bastiaens -Friday 22nd May
"Captains Log 22/5/09"
This week I was chopping and changing between tasks which included working on the spawn marker, creating sounds, creating other new assets such as scavengable weapons and enemy corpses. I also did some more exports of the weapons as well so its been a pretty hectic week all up. Despite the numerous schedule changes I managing to keep on track on both sides of the schedule just in case we end up reverting to the previous schedule. In any case, next week ill be working on some more enemy corpses and then who knows at this stage XD. The following images are the scavengable weapons in the game which the player finds in order to research the corresponding weapons.
-Michael





This week I was chopping and changing between tasks which included working on the spawn marker, creating sounds, creating other new assets such as scavengable weapons and enemy corpses. I also did some more exports of the weapons as well so its been a pretty hectic week all up. Despite the numerous schedule changes I managing to keep on track on both sides of the schedule just in case we end up reverting to the previous schedule. In any case, next week ill be working on some more enemy corpses and then who knows at this stage XD. The following images are the scavengable weapons in the game which the player finds in order to research the corresponding weapons.
-Michael





Good Times
This week has been good times, i have finished all LOD for my assets, including the Shotgun, and have begun modelling a extra asset, with the possibilty of more extra assets on the way.
Also begun doing some testing of all assets in the level and wrote down any chrash errors and passed them onto the programmers.
Thursday, May 21, 2009
Tuesday, May 19, 2009
Tim Bewick - Week 19
I spent most of Week 19 working on tooltips that tell the player how to control their avatar when they first play the game. I made them so they only appear to tell you how to do something that the player has not done before. I also fixed the avatar's jumping and worked on the loading bar.
Monday, May 18, 2009
Whats left to do in 3 weeks.
Fortunately not that many tasks, unfortunately those that are left are giving us headaches. We finally got some networking going, just need to smooth out some of the animations and physics with our friend mister linear interpolation. Then tweak mother giving birth, AI path finding, a few animations, a few particles and fix a few bugs.
Its gonna be mean, the game is really fun.
Its gonna be mean, the game is really fun.
Art Update ! LOD
Some quick update ya'all :P here's the LOD for both Scientist and 1st Lieutenat, I just realised that I havent posted the 1st Lietenant so watch this space later. Cheers!








Friday, May 15, 2009
Man I'm Beta!
The team has just finished week two of a five week period before beta hand-in and the pressure is starting to mount. During this time, the main focus for the team has been to try and fix features that have been implemented so far as well as getting the gamer experience properly implemented.
My task has been the AI routing. This has given me a lot of trouble over the course of this project. The main challenge has been the fact that the environment is almost completely dynamic. I have been running into cases where the AI agents will almost always get stuck running to a waypoint because the path that it calculated has become invalidated. At the moment, AI agents are using a combination of pathfinding and steering behaviour. This kind of works but I still need fallbacks incase something wrong happens. Some suggestions have been given to me from peers, Darius, and Jon, our new GD Tutor and resident go-to guy. Here are the approaches that I will be trying over the next few days:
- Keep track of waypoints that have been successfully traversed. If the AI agent takes too long to get to its next waypoint, have it backtrack. Add a working memory fact that will change the cost of the edge that could not be traversed so that future AI agents will avoid going that way when pathfinding. Once the fact has expired, reset the edge cost back to the correct cost again. By setting a time limit on how long that edge cost can stay modified, it should stop the edge cost from being invalid for too long (NB: The time limit probably would not be needed if the environment was not dynamic....then again, the agents would probably not get stuck either).
- Place trigger areas around the map that could be problematic for simple pathfinding. If the agent gets into this area, have them perform some action to minimise the possibility of it getting stuck. For example, there are stairs in the area where agents tend to get stuck. I could place a trigger area at the bottom of the stairs that could make the agents jump to the top rather than just walk up it.
- Have designated areas in the map where AI agents can return to where they can easily get to certain areas in the level. If the agent gets stuck, have it try to get to one of these areas where it can begin its search again.
At the moment, I am leaning towards the first one. I'll be back with my progress in the next few days. Keep posted, later days.
My task has been the AI routing. This has given me a lot of trouble over the course of this project. The main challenge has been the fact that the environment is almost completely dynamic. I have been running into cases where the AI agents will almost always get stuck running to a waypoint because the path that it calculated has become invalidated. At the moment, AI agents are using a combination of pathfinding and steering behaviour. This kind of works but I still need fallbacks incase something wrong happens. Some suggestions have been given to me from peers, Darius, and Jon, our new GD Tutor and resident go-to guy. Here are the approaches that I will be trying over the next few days:
- Keep track of waypoints that have been successfully traversed. If the AI agent takes too long to get to its next waypoint, have it backtrack. Add a working memory fact that will change the cost of the edge that could not be traversed so that future AI agents will avoid going that way when pathfinding. Once the fact has expired, reset the edge cost back to the correct cost again. By setting a time limit on how long that edge cost can stay modified, it should stop the edge cost from being invalid for too long (NB: The time limit probably would not be needed if the environment was not dynamic....then again, the agents would probably not get stuck either).
- Place trigger areas around the map that could be problematic for simple pathfinding. If the agent gets into this area, have them perform some action to minimise the possibility of it getting stuck. For example, there are stairs in the area where agents tend to get stuck. I could place a trigger area at the bottom of the stairs that could make the agents jump to the top rather than just walk up it.
- Have designated areas in the map where AI agents can return to where they can easily get to certain areas in the level. If the agent gets stuck, have it try to get to one of these areas where it can begin its search again.
At the moment, I am leaning towards the first one. I'll be back with my progress in the next few days. Keep posted, later days.
Subscribe to:
Posts (Atom)






