Floating polar ice, part 2

Since last time on floating polar ice environment, I’ve fixed all those “obvious things” and improved the ice blocks!

Details below on Blender work, UBER, pushing and long-jumping.  First, here’s the video!

 

Spent much of Saturday learning 2 things for my ice blocks (which will hopefully be useful in future modeling jobs, eh-hum!)

Blender

Firstly, modeling the ice block with Blender (with links to tutorials, etc used — some of which I’d done before but it’s nice to have a simple list of references, eh!):

1. Clone original object (in case wish to start again)
2. Fracture to create detailed object
3. Duplicate and ensure it has unique data blocks,
4. Bake AO map, normal map, etc.
5. (after playing with UBER below, realize I’d prefer to hand-paint the translucency map so…)
6. Texture paint translucency map (I painted to black and white though this needs moving to either the Albedo’s Alpha channel or the AO map’s green channel for UBER).

UBER

The second thing that took most of Saturday was fiddling with UBER shader‘s (yes, it’s name is all capitals) refractive and translucency capabilities.  I’d previously gotten reasonable results for the PlayerSetupArena’s ice walls but, on reflection (see what I did there … er, ‘cuz I spent ages fiddling with all those optics parameters, oh never mind 😉 ).  Yes, on reflection, I realized I’d used an amount of emission to get the blue-ish hue from the ice.  While that worked OK in a static environment with no time-of-day changes, it ruins the PBS capability for nighttime.  As such, I think I need a different way.  For the PlayerSetupArena I’m toying with adding some point lights behind the ice walls that slowly rotate around the arena.  I’ve not done it yet but will post a (hopefully very pretty pic) once done.

However for the ice-blocks floating on the ocean, I eventually concluded that UBER has difficulty with Realistic Water‘s shader.  I suspect (after some invetigating) that both UBER and RW do a grab pass to get information about what is behind them to do their refractive effects.  This likely needs unifying to get them to work together.  For now I’m resetting the floating ice blocks back to Unity Standard shader since the effect is still very pleasant.

Madness, Ceto and Beautify

Lastly (on the aesthetics front), to tie-off my comments last time about the recent Unity Asset Store Madness sale, I also tweaked the RW ocean shader to give some ripple highlights using its Fresnel capability.  They aren’t everything I’d envisaged but might actually be better.  Let me know your thoughts!  RW doesn’t do volumetric subsurface scattering which I’d really like but neither does Ceto — the water shader in the sale.  As such, I decided not to buy that and save for PlayWay if I ever need more (which I think is the most impressive one).  Instead, at the recommendation of a few dev friends, I picked-up Beautify.  It is another post-effect and sharpens up the image.  I suspect I’ll need to combine it with Scion to save passes later but for now, it’s added a lovely ‘pop’ to my aesthetic so good suggestion, guys!

Gameplay

Lastly (really this time), a couple of gameplay bits!

Several people made the same comment on the last picture of the floating ice — “Jump! Jump!” and “Push him!“.  Yep, that’s all in there!  I’ve included it in the video to satisfy the schadenfreude of my audience 😉

However I also discovered a ‘feature’ of my movement controller that allows jumping much larger gaps than I’d previously believed — by rolling, releasing and double-jumping, you can long-jump!  This wasn’t something I built in intentional but is actually quite a lot of fun so I’ll be labelling that a feature.  The big question is whether it’s accessible enough for regular players to use or is it primarily for expert players to access secrets!  (your thoughts as always are most welcome 🙂 )

p.s. Are blog posts like this better?  I’m not writing them as I go so they’re twice less useful to me (I can’t use you for Rubber Duck Debugging and it takes time to write them instead of more GameDev!) but I think the overall feeling is nicer.  What do you think?  Would you prefer more dev ponderings? more conclusions? half-way? other?  TTYS!

Voxel LOD generation

LOD (Level of detail) now working for voxel *generation* as well as building.

Here’s a YouTube at full res for the LOD-lovers like me out there 😉

As discussed in the last post, the generation phase is deciding on the matrix (8x8x8 for LOD0) of numbers that comprises a voxel ‘ChunkData’ whereas the building phase is turning those numbers into a ‘Chunk’ with a ‘Mesh’ — a thing you can actually see and interact with.

This new work means:

• LOD0 (white boxes) contain 512 floats and 128 triangles = unchanged.
• LOD0i (yellow boxes) contain 512 floats but only 2 triangles = unchanged.
• LOD1 (cyan boxes) contain 1 float and 2 triangles = the NEW bit!

You can see how that’s much less memory and much better performance — especially for covering *much* larger arenas!

Yep, open(er) world campaign mode, here we come!

p.s. As with most gamedev or even programming, this took a great deal of frustrating tweaking including upgrading Unity and several assets then creating a whole new way to investigate details about voxel spaces that are generated on threads.  I know, implementation details.  I’m happy to discuss and the answer will involve phrases like “Marching Cubes”, “Isovalues” and lots about “neighbours”.  Ask if you’re curious / suffering from insomnia 😛

Oh and there’s still plenty of work to do before someone asks “is it done yet”.  There’s a reason I don’t show the Snowmen moving around in it yet 😉

#ScreenShotSaturday: PID Controller rolling a Rigidbody along AStar under BT!?

Continuing from yesterday’s short one, today is Saturday so hope for a biggie with lots of awesomeness … and definitely not getting tangented creating a #ScreenShotSaturday since I did that earlier in the week 😛

The picture is the PID Controller successfully controlling the rolling Rigidbody along an A* path including a section ramped sideways to the direction of travel (to show it compensating for the disturbance caused).  Of course, the whole thing is under the control of a Behavior Designer behaviour tree.  The cyan line is the current move vector and red line that hovers, growing and twisting above it, is the force vector it’s trying to apply (along with a fading history).  The purple cross on the floor is its current waypoint along the path.  The yellow or green wire sphere is its range it will accept to that waypoint.  Sadly GifCam got some oddity on the third section of the path where the screen went all green but I think it’s still quite cool to watch 🙂

For context, this is the development view of my Snowman AI needing more health.  In Snowman Scuffle, the snowmen fuel the snowballs they throw with their own health = snow!  Obviously injury also results in their losing snow health.  To regain snow, Snowmen need to roll in some snow that’s appropriately smooth, deep, etc.  I have developed an A* path generator that determines where is ‘good snow’ (perhaps I’ll go into detail on that some time if I need to work on it more or by request).  Once the AI gets the path from that system, this aspect then is responsible for getting the Snowman rolling along it at a speed appropriate to gain the snow health it needs.

In fact, this is a blog post not a tweet, why don’t we push the boat out and have… another animation!

Here you can see (again in development view), the snowman shooting at a target dummy (which turns red when hit — I’ve since fixed the missing seen here).

And, when in-game, we get

(Note, most of my animated GIF lacks image effects that usually run — GIFs just don’t like all the extra colours, etc!)

Y’know what?  Per my “post more often” resolution, I’m gonna post this to link from my #ScreenShotSaturday tweet then continue my devlog post separately.

P.s. Hmm… so that whole “definitely not getting tangented creating a #ScreenShotSaturday” thing kind’a didn’t work, huh!  A morning of finding old screenshots, tweaking WordPress and creating a new header image.  Still, at least the devblog is semi public now!  Gulp.  Right, tunes on, fresh coffee in-hand — definitely back to applying the PIDController path-following logic to non-rolling … by first diagnosing that weird Behavior Designer bug!