Brick wall - terrain deformation

Still learning a lot about unity - things to do and not to do.
Like for example - can't have a collider trigger onEnter events with another collider if one of them is not a rigidBody.  I was planning on using a cube/rectangular mesh near the front of the bulldozer blade  - partially sunk into the terrain and look for collisions - and lower the terrain accordingly.  No dice.  God forbid, I give this 'scout' object a rigidbody - the bulldozer bucks like a wild bronco!


After a bunch of false starts, I landed on a technique with some promise - I placed a narrow plane out in front of the blade and fired raycasts through the vertices to the terrain below.  Upon intersection, I lowered the terrain below it.  I added another plane further in front to RAISE the terrain - to simulate the bulldozer scraping/pushing dirt.  It seemed to work ok - but I had to up the dozer scale to ensure I had enough terrain vertices to make a realistic 'flattened' area.  After a couple of hours of playing around (and adding an FPS display), I realized my performance had gone out the window.  After adding some ad-hoc profiling, my slowdown pointed towards the built-in Unity terrain setHeights functions.  After lots of web searches and reading, I determined this is a dead end.  The performance of setHeights for Unity Terrains is just way too prohibitive for this sort of work.   :(
If I were to create my own mesh based terrain 'thing', I'd run into the same performance issues that Unity had/has to deal with (and I am assuming they are a lot smarter than I).  I COULD abandon the bulldozer scrape/move capabilities and concentrate only on excavator/backhoe style digging - but that's not what I want.

Looks like I need to look at voxel based methods now- including such mathematical marvels as Marching Cubes!

I'm turning Toon!

While I don't intend to have a LOT of verts/polys in my game - I'm told that the Unity terrain alone on IOS can slow things down considerably.   No need for high-poly detailed models - and more so, not sure I need photo-realistic terrain or trees.   I ran into the same issue with DemolitionFX years ago.  I started out with it feeling like a more hardcore simulation - that didn't seem like that much fun.  It took my young son, Ben to point out that "everybody likes monkey's with hammers!".  So I will be ultimately switching to more of a toon-shaded (cel shaded) look and feel.
I'm enamored by some of the low-poly vehicles I find on SketchUp that I believe I can import (via Blender and then Unity.  I am hoping that at some point I can develop the skills to articulate these things (even if I just break them up into a few separate objects and control them with Unity scripting).

So I intend to continue prototyping - learning the bells and whistles of Unity and making sure I can implement all the features.  Then I will probably take a break and go on an 'asset' and 3d modeling bender where I find/create/buy the assets we need and learn to use the tools to properly manipulate them.  Finally - a clean write incorporating all I've learned.  Then probably an optimization cycle (playing with IOS and Android devices) and a re-write - then release!!

Birdseye view and transitioning into FP

Today I accomplished my goal early.  Wanted to prototype an overhead view (current my design says this will be one of the main views) that supported panning and zooming.  Works!  Then when clicking on vehicle I wanted smooth camera transition down from the sky into first person view on the vehicle.  Delved into the world of lerp and slerp (ended up using slerp because I liked the effect) and got a fairly cool effect.  I will probably play with Hotween or iTween later - I like their simplicity more.
      Next up is selecting units WITHOUT jumping into them - and showing info/fuel info.  Double click will bring you to first person view.  Eventually will probably create a context menu and eventually have to deal with mobile interface options like the long press and pinch-zoom.

Multiple Vehicles, Cameras and FP view

My goal for the day was to prototype having multiple vehicles shown in a 'birdseye' view and be able to select one, control that vehicle from an FP view and then revert back to birdseye view.
This forced me to understand communicating between scripts (objects) and some raycasting for the mouse pointing logic to select an object.

  I did raycasting before in my Three.js prototype to keep the vehicle along the normal to the ground  but in this prototype, however, I just let the physics engine deal with that aspect.  Not sure if the FP view will be one I end up using at all (was thinking an offset third person view would be better) but it might be an option.  2 additional goals for tomorrow - getting the camera to smoothly 'lerp' from birdseye to first person (instead of just snapping) and also allow user to pan/tilt birdseye camera as necessary (including a easy 'direct overhead' mode).

After that, the plan is to change the 'operate' function to be double click and single click will highlight the unit - giving floating health/fuel bar and other stats.

Re-Engaging Gold Mining Game with Unity

Fired up the latest version of Unity (4.1) this weekend to see how hard it would be to reproduce some of the terrain deformation work I prototyped using Three.js a while back.  Turns out, not too hard!

In a single day (a few hours here and there), I had basic terrain with moving vehicle (imported 3d model of bulldozer) and the ability to knock down trees.

Day 2 gave me ability to deform the terrain - not pretty yet but it works -AND adjusting the textures.  

Camera follows the vehicle and I worked a bit to get it to NOT steer like a car, but instead be able to pivot like a real tracked vehicle can do

I originally had mesh collider around the trees but they ended up doing crazy flip flops down hills when knocked over.  Tried cylinder - but they rolled too much.  Ended up with just a box collider around the trunk which did pretty well.





Started doing the scripting in javascript, but switched over to C# because it makes more sense to me.  It's easier for me when I find an example or code snipped to convert from javascript to C# than it is to go in the other direction.  Not too much code at the moment - just for the vehicle movement and camera follow - and of course, the terrain deformation.