Tuesday, November 15, 2016

Team PPJ - 10/31 - 11/15

This week, the word of the sprint was "implementation." As of right now, every hero asset is in the Unreal Project, if not in a scene. Tyler's goal, Cory's ball, and the capsule stage has been implemented and lots of progress has been made from our previous boxy prototyping stage.

Progress has mainly been focusing on adding definition and textures to hero assets, and in preparation for the addition of an AI there has been a few character designs created. A placeholder particle effect has been added to the ball to aid visibility, in preparation for an upcoming ethereal light-based particle trail.

Coding-wise, a rough AI has been coded but not implemented, and continual refinements are being made to the ball/whip interaction. In addition, a system has been implemented that allows the player to calibrate their platform's size, based on the current size of the Vive play area.

Enjoy visual examples of the team's progress:

AI design 1

AI design 2

AI design 3

Capsule glass

Tool 1

Tool 2

Ball final

Elevator material 1

Elevator material 2

Elevator material 3

Goal

Platform 1

Platform 2

Implementation and refinement 1

Implementation and refinement 2


Daniel Ingman - 10/31 - 11/15

This week I spent time refining the tool model, creating character designs for the AI opponent, and working on materials for the final stage build.

The tool model now has emitter arms and a nozzle, which will emit plasma arcs when the gravity beam is engaged. In addition to emitting plasma arcs, the arms are articulated and will move and react to the player engaging and disengaging the whip.

3/4 view

3/4 view

Side view

Top view


The AI character designs drew lots of influence from contemporary mecha and robot designs, notably the Tsugumori from Knights of Sidonia and various mobile suits from Gundam.

The advanced design, displayed color neutral

The blocky design, displayed with Hachigen branding

The sharp design, displayed with Doskoi branding


The material for the final stage is meant to be a mixed-material setup, with metal bracers holding a shell of futuristic glass. I was able to work on a textured glass material, however the general consensus in the group that it needs to be more "futurey", which will be deliberated on further. Likely this will include emissive lights and animated energy layers.

Future glass tho

The effect of the glass can be seen in this GIF
Pros:
  • Glass material in its early stages adds a lot of visual interest to the arena
  • Tool model is ready for materials
Cons:
  • Time management: workloads for this class and other classes are reaching a fever pitch

Total hours spent: 18 hours
  • Second pass hero asset: 7 hours
  • AI character designs: 6 hours
  • Glass material: 5 hours

Cory Zicolella 11/1 - 11/15

Well, for these last two weeks for me, honestly it's been rather straight forward.  I've been working almost exclusively on the ball hero asset, as it is probably the one thing you (should) always be looking at.  I ran into some issues between weeks, and have since addressed them so the current model is in about as best shape as it can be.

Originally, a big worry was the style of the ball and the polycount that both Unreal 4 and the Vive could handle.  It was decided that the base primitive would be a quadball set to 25/25/25 subdivisions.  Given that it is a spherical object that could potentially be in the player's face, the ball required much hard-modeled detail.  Not only will a normal map not be able to accomplish what a mesh can, specifically in VR and in your face, normal maps tend to not work at all and look bad.  So, my first pass of the ball had about 90,000 tris when all edge loops were placed where they needed to be; this isn't simply a circle, it has plates on it, and without edge loops, it looked less than desirable.

Personally, worrying that this high of a polycount would be an issue in the future, and needed to address some other issues the team had anyway when I brought it back to critique, I started from the drawing board.  This time, the quadball base was only 15/15/15 subdivs, I made certain to turn on symmetry so the model would look identical on all sides, and I used half as many edge loops.  Unsmoothed, the ball was 36,000 and smoothed, it was about 50,000.  Plus, I made it in about 3/4 of the time.  Noticing that I increased efficiency by effectively 50%, I decided that this was a good design on the ball, and the team liked it as well.
(I hate maya nothing will render for me more than a corner of the window.  Same with any orthographic views.  I haven't been able to fix it.  Here's viewports.)

Side View

Front View

Bottom View

Top View - the center is a pane of glass


From there, I took to RoadKill, recommended by Mike C., to do the unwrapping--this came with its own set of difficulties however.  I needed to learn the program, and also in my initial trial it wasn't functioning correctly.  After conferencing with Mike over a sample object with screen sharing, I got it down and got to unwrapping.  This program really really enjoyed making a bunch of edits where I didn't choose it to, though, so plenty of time went into damage control and making sure the UVs were as good as they could be.  That being said, RoadKill still seemed to think my entire ball's textures would be stretched out (as per the colormap), so I brought it into Maya to check, ran some tests, showed it to the group, and agreed it was okay for texturing.

Green = Good, Red= tight, Blue = stretched. But Maya's checkerboard revealed it was OK.
On another note, RoadKill is like UV layout, so that's cool.
Maya's Colormap UV - not nearly as bad


So we moved forward with a base texture on the ball of tiled fiberglass, topped with some grime and scratched glass to give the aesthetic we're trying to capture.  Moving forward this can definitely be refined, and the plan is to have the centerpiece as an emissive that fades away and acts as a visual shot clock to the player.  The glassed area will also show the team logo the player is on, and the ball will be accented with colors accordingly.

That was the main amount of my work this week, but I also edited together the video draft for my group.  That took a few hours, and aside from running into capture issues with attempting to get widescreen (which after some efforts we had to get to work on editing the mirrored footage), but I believe it came out well.  This is just a rough trailer and it can most definitely be refined in the future.

Pros-

  • Alot of work got done in this last sprint, and I'm happy about it
  • Managed to cut poly count in half
  • Learned a new program
  • Finally got to do some video editing (!!)
  • This week displayed alot of teamwork
Cons-
  • Alot of work takes ALOT of time
  • Other classes are really becoming a bother right about now
  • 7/11 still has subpar food, but hey its open after 11pm
  • I basically made an asset and entirely recreated it as it was finished
  • MAYA HAS THE STRANGEST BUGS THAT NEITHER MY TEAM NOR GOOGLE CAN FIGURE OUT, SEND HELP, SOS.

Tyler Schacht PPJ 11/1 - 11/14

The past few weeks I was once again working on the Goal asset.  I had some issues with maya.  I was so into the project that I forgot to save.. and well, maya crashed making me lose all of my progress.  However, I was able to get the final model down, UV it, and then put on some animation using the blueprint system in Unreal.  Animating it with code will allow the CCI team to easily change the animation when a goal is scored.  In the last week I spent time trying to find a good way to capture VR gameplay.  Unreal Engine 4 defaults to only rendering one "eye" on the desktop and it isn't widescreen.  I also spent sometime trying to better understand UE4's material system with Cory.

 Total Hours: 35 hours
 - Goal: 14 hours
 - VR Footage Research: 2 hours
 - UE4 Material Learning/Relearning: 4 hours
 - Meetings: 15 hours

Negatives: Had a really rough last week, an exam, a 10 page research paper, and a whole bunch of sleepless nights.  I wasn't doing too hot.

Positives: Despite my negatives for the past two weeks, I felt like I was able to get a lot done for senior project.

Monday, November 14, 2016

Mike Cancelosi PPJ 11/7-11/14


This week I put a lot of work into making materials for the elevator. I have a glass pane texture, a lights texture, and I'm starting a default swirly metal texture for the basic walls.




As for the actual layout of the elevator, I have a small sketch which unfortunately I couldn't take a picture of.

Pros: Got a good start on the elevator. I think it is going to look pretty good.
Cons: Skipped Saturday's meeting

Total Hours Spent: 15

Ryan Badurina - Oct. 31 - Nov. 15 PPJ

The past two weeks involved texturing and polishing the player platform and implement that into the game.  Aside from the general meetings and development sessions, Week 7 saw the completion of the platform model for use in our game, although it wasn't implemented until a week later.

Bottom view of the platform (1st Pass Textures)



Top view of the platform (1nd Pass Textures)




Texture Map for 1st Pass Textures



During week 8, after discussing with Mike and Andrew, we decided to design the platform as a more "dynamic" piece in the game.  Rather than have a single platform mesh that scales and distorts, which can make it look ugly when looking at it up close, we wanted a dynamic platform made of several meshes that adjust, scale, and generate using an algorithm based on the VR room scale.

The inner base of the platform, allowed to be scaled and distorted as it cannot be seen.

The propulsion / gravity engine, not meant to be scaled but duplicated at certain intervals

The outer plates meant to cover the base.  Will be dynamically duplicated based on room scale size.


The whole process isn't entirely complete yet, as I need to verify if this type of design route is alright with the coders, but I'm making headway in the process and hope to have it by alpha at the earliest so I can refine it in the future.

Meeting(s):
  -Week 7 General Meeting:  2 Hours
  -Week 7 Development Session:  4 Hours
  -Week 8 General Meeting:  2 Hours
  -Week 8 Development Session:  5 Hours
Week 7:
  -Platform Texturing:  5 Hours
  -Platform UVing:  2 Hour
Week 8:
  -Redesigning Model: 5 Hours
  -Redesigning UVs:  2 Hours

Total Time (2 Week Period):  27 Hours

Pros:
  -Septa is back and working, allowing me to go on campus a lot more for meetings and important development sessions.
  -Current version of the player platform is modeled and textured, and is currently in the game for preliminary testing with the room scale function.

Cons:
  -The redesign of the platform isn't complete yet; still need to hammer down some designs to make it work with the coders.
  -The term is almost done, which means things are starting to get really busy for not just myself but everyone else on my team.
  -Part-time work still takes up some time, but not as much as before now that the new system for Virtua is completed.

Andrew DiNunzio - 11/7/16-11/14/16

This week my primary goal was getting the "Resistance to Bending" force implemented for the Gravity Beam and making it overall more fun to use.

Based on the math I had previously worked out, I implemented it in blueprints, but found that the ball was moving towards my hand instead of a distance of l away from my hand. I added a hacky workaround (hacky in the sense that I don't know why it's necessary just yet), where I added l to the position the ball whips to.

In addition, I also added an additional launching force to the ball when it is released, which helps increase the pace of the game. The direction of this force applied is somewhere between the ball's current velocity and the direction of the player's hand when they release, depending on how fast the player is swinging their arm. Faster swinging motions result in the force being closer to the hand's direction than the ball's current velocity.

In addition, as a group on Saturday, we created a title scene that will be used to transfer the player to the game arena. Unfortunately, the computers in the lab still didn't have Visual Studio's Extensibility Tools Update installed, and it seemed our admin privileges were revoked, so we could not reinstall it. We therefore were unable to actually implement the menus.

We did however manage to get some of the assets imported into the project.

I also spent a few hours trying to decouple the logic of the whip from the MotionControllerPawn but ran into issues.

My thought was to have a somewhat-abstract Input class (perhaps it could simply be an Interface) that would have AIInput and MotionControllerInput as subclasses, then make the Whip component *have an* Input component. Then my plan was to add two of these to the MotionControllerPawn. I'd pass the Left Controller in to the first Whip component (to its MotionControllerInput), then the Right Controller into the other component. Since each would be responsible for its own polling input (pulling from the controller passed to it), it should work for both hands.

Then, the AIInput could implement all of the methods needed by the Input (like GetForwardVector, GetLocation, etc.), and they'd essentially share the same interface.

I'm having difficulties setting this up though.  I don't see any way to make one Actor *have* another Actor. It can have an ActorComponent though (aside from storing it in a variable - maybe that's the way, which would unfortunately require polling from within whatever is holding the whip). When I try to make the Whip an ActorComponent, I don't see any way to make that component *have a* Spline Component or a Spline Mesh Component, as used right now.  So I could make the Whip an Actor instead, then I could make it have these components, but then since I can't make an Actor *have an* Actor, I can't make the MotionControllerPawn have Whip components.

Maybe it'd be easier for now to keep the whip logic coupled with the MotionControllerPawn, then the AI's Actor would essentially duplicate the code. I don't like that solution, but I don't know of any better way. Looking at the PlayerController and AIController, they may be helpful, but I doubt it'd be worth the time investment to learn about them since there's still the issue of tying it with Spline Meshes and attaching it to other Actors.

The current progress is shown below, including the newly created force on the whip.






 Time spent: Total: ~15 hours

6 hours - Implementing Resistance to Bending force
4 hours - Creating title scene
3 hours - Trying to decouple the Gravity Beam / Whip from the MotionControllerPawn
2 hours - Rearranging some logic for imported assets

Pros:

  • Our gravity beam feels good enough for an Alpha now.
Cons:
  • Unable to successfully decouple the whip mechanics from the motion controller so far. May need to just copy whip logic to the AI Actor temporarily.
  • Still using Git, since I haven't been able to find a free SVN hosting site with enough storage space, while also allowing 10 people to have access.