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!
No comments:
Post a Comment