Day 16: A Little Ambience

After some investigation into the lighting issue I was having yesterday, it looks as though I set the wrong direction on the light, causing some very dark shading in places. I had also set the direction of the light to change too quickly. After fixing it, we should be fixed, correct?

Nope! Those dark parts still showed up. It looks as if the lighting needed to be combined with an ambient aspect (of which I completely forgot), so I pulled that in. However, the ambient color isn't a hot cyan...

Looks like the alignment of members in the c-buffers (buffers that hold constant information across shaders) is quite important! Important enough to not reverse diffuse and ambient color information. The actual ambient coloring:

Which, when added to the actual diffuse lighting, greatly improves the lighting of the scene and makes it good enough to move on:

As for homework? Yes, we actually got some homework! It was going over a demonstration of code optimization done by a Mr. Mike Acton from a GDC 2015 talk. That is, going over the proper order of looping variables on a matrix when one side (height) greatly exceeds another. Row-major seemed like the answer, but we're required to actually show the profiling and averages on Excel. Simple, right?

Eh. eeh. The way that I'm setting up the matrix seems to be a little off. The height is something like 8192 * 1024, but the width ranges from 2 - 512. At some point, the INT_MAX is reached and I'm not sure I can alloc that much memory at once. I'll have to inquire about the assignment tomorrow.

Day 15: Abnormal Normals

Today was a great day to celebrate one's birthday! I'd tell all the details, but this is a serious blog for serious discussions.

As for serious discussions, I did manage to find some time to calculate some normals. Instead of providing set normals like I did in previous OpenGL work, these normals have to be calculated for procedurally generated terrain. Think of taking each point of the triangles to render and then calculating the cross product.

However! One can also weight the sums for smoother coloration of intensity. That said, I did kinda mix up the normals and calculated weighting without transferring to a new array. The product...

Oh no! Luckily I separated the calculated normals from their weighted forms. However...

Yikes! Things are so dark and visually janky! This will require more research to see what exactly's up.

Day 14: Sandy

Today was the start of plenty of bugfixing on the capstone project from playtesting yesterday! Most of it was spent on a single bug, though.

When doing timers on effects, the time is affected by global time dilation. That is, when the player slows the world, the time it takes to do things is also affected. In the case of objects that ignore global time dilation, the objects should ignore it on a timer, correct? Apparently setting timers over again only halts the figure, so I had to do a manual timer based on DeltaTime.

However! It seems that DeltaTime gets arbitrarily small when I use CustomTimeDilation and Global Time Dilation in the equation, and doesn't bother to change during some cases. With this nondeterministic nature, I'm defaulting to a constant change without DeltaTime for the required effects.

As for my programming project? I had to pull back to render triangles over lines, but the desired effects get TGA files rendered as textures! Turns out the font problem I'm dealing with isn't part of TGA loading, as the files render just fine:

As for next steps? While the singular texture is mesmerizing, some lighting will definitely do to help the situation.

Day 13: Spiral Twister

Today marked the day of a successful playtest! Texture management in the terrain program is at a steady and slow pace, so no particular progress yet.

But yes! A successful playtest. We had a few hours at the Geekeasy to make sure we had plenty of external feedback, and got a lot of good word out regarding our game!

That said, we have plenty of bugs to work through.

As for things in my spare time, I was also working with vector fields to produce turbulence effects in an attempt to please my producers (producer). Unfortunately, UE4 doesn't support the dynamic vector fields that leads to adhesive collision like in other turbulence effects. Luckily enough, I can manipulate it to produce neat effects like a spiral spout or that thing from Twister, only purple:

Day 12: Time!

Today's not too much of a visual day, mainly due to the nature of today's work.

Programming project? Made a bit of a class that helps to smooth out the metrics I've been taking on the terrain generation. The fractal process takes roughly 0.514 seconds to 1.15 seconds on the turbulence noise generation. No contest there! Next up comes texturing.

As for capstone? I finally got in the working purified crystal texture, but today was mainly spent ironing out bugs and making sure that everything works the way it should.

Which was spent continuously building whenever my team made an extra change. Yeeesh. We are getting better with punctuality, though! No last-second changes before external playtesting tomorrow!

Day 11: Noise v. Fractal: Dawn of Justice

And the noise-based terrain is also as complete!

Pray tell, how does noise-based heightmapping work? Imagine that you assign a random value to a set square of textures. This is basic noise, but it does not produce a pretty sight:

If we zoom in the actual values (that is to say, set the positions[z][x] = noise[z/8][x/8]) we can get a little averaged control, right?

If you like New York.

There's also the idea of smoothed out terrain, which actively takes noise and bilinearly interpolates it for each position (give or take a bit of change from the fractional portion of a float value). Vary this by positions divided by a set size and you get something slightly more interesting (size: 64):

Still looks like a bed of spikes, so we'll need to smooth it out further. Based on the concept of turbulence, or adding noise in at different octaves, we now have a function to specify a size and work its way down a series of octaves, adding their smoothed noise. It's a bit more costly, but produces some impressive looks:

Which one to choose, though? They each have different things to change; the fractal side has randomness reduction and amount of subdivisions, but its points are limited by the amount of subdivisions. As for noise, there is no limit on a square's side, and the amount of octaves can deepen the detail.

I did a test with chrono's duration casting and tested the amount of ticks required for each function. In this case, the fractal generation takes half as much time to load as the Perlin turbulence noise (!!!)

What to choose? For the final product, diamond-square takes the cake. What's next? Texturing time!

Day 10: Realistic and Not-So-Realistic

What was today? A fair bit of capstone work was done today; I worked some distance based visibility text for the tutorial text and fixed the bugs on the bridge projectile so that the spawner would properly face the player and bridge projectiles wouldn't get stuck inside themselves.

The main event? Terrain generation! After finally figuring out the diamond-square algorithm (and remembering to properly reduce randomization per subdivision), we finally have some realistic looking terrain!

As for the next algorithm? Noise turbulence texturing! How does that look?

Yeesh, looks like we'll have to smooth that one out.