Piece and mesh collisions

[SpliFF]

I'd like to introduce some "massive" scale units (think Epic40K Titans). The biggest issue I see with this other than pathing is the complexity of the collision volumes.

Even if I were to use several collision volumes per model they would be invalidated the minute the unit rotated its torso. What's needed here is per-piece or even per-face collisions that can follow unit animations.

Performance-wise you wouldn't enable this for every unit, only those chosen by the mod. In my mod there would never be more than 30 or so super units on an entire map. I see the algorithm being something like:

Code: Select all

if (model->Collides(projectile)) {
  for (piece in model) {
     if (piece->Collides(projectile)) {
        for (mesh in piece) {
           if (mesh->Collides(projectile)) {
               return true;
           }
        }
     }
  }
}

So there shouldn't be a performance hit unless a large unit is being peppered by rapid-fire spam (like 100 gunships) AND the piece being attacked is a very complex mesh (like 100 tri or something).

[Argh]

I have no problem with this being put into the engine, I think that would be cool. However, I should warn you that the problem of the pathfinder is non-trivial.

You'll see clipping issues if you make the square size small enough that it will path reliably, and big beauty problems with empty space around the unit if you use large enough squares to prevent clipping and it won't path very well except on very flat maps.

IDK if anybody's really solved this yet. Talk to the 's44 guys, they needed to solve that issue for their to-scale warships.

[Peet]

Argh, I would like to make something very clear, and usable as a general rule of thumb for various topics like this.

You have no idea what you're talking about.


Spliff, multiple collision volumes (possibly tied to unit pieces) sounds like a good idea. I think that a collision mesh would be simply too slow in an rts setting, though.

[Pxtl]

Couldn't you do it as a hack right now by using some invisible units attached to the main unit? That is, when the unit is created, in lua you spawn a bunch of unselectable smaller "collision sphere" units and then attach them as appropriate (I don't know if you can use lua or you have to COB it to do the attachment). Use some lua to redirect any damage to the collision-sphere units to the mainbody. Of course, there would be lots of smaller things you'd have to watch, like preventing capturing of the sub-parts.

edit

@peet: My only worry about adding more stuff to the current collision system is how many holes people are finding in the non-spherical-volumes stuff. I imagine the same problems would exist for this.

[Peet]

Well the way I would personally implement it would just allow a unit to have multiple, movable collision volumes, retaining their current implementation. Yes any current issues with the system would be retained, but they would be no less fixable (what are the issues with them currently anyway?) than they are now.

[lurker]

If you want to hack it, just use invisible shields.

[Kloot]

My only worry about adding more stuff to the current collision system is how many holes people are finding in the non-spherical-volumes stuff

Given how few (last count: 0) Mantis reports there are about these supposed problems, they must be very small holes.

[lurker]

There is a mantis about the fact that you can't change the aim point because part of adding these volumes removed the offset tags, and units don't aim at the volume for some reason.

[Kloot]

1. the old offset tag only affected 3DO's in the first place
2. weapons aim at a target's center position
3. the center position is pos + model offset and doubles as the coldet volume midpoint
4. the volumes have their own offsets relative to the center position

TLDR: the volumes themselves are never aimed at because they don't need to be for all practical purposes. Their offsets are intended to change the region around a unit where hits are detected, NOT where said unit is targetted (unlike the old tag). Be actually helpful for a change and name some cases that this presents a problem for, I don't like having my time wasted.

[FLOZi]

the old offset tag only affected 3DO's in the first place

Assuming this refers to my offset tag, that is incorrect.

[lurker]

name some cases

You missed all of smoth's being upset at the fact that his flat units in gundam, most notably air fields, have units aim completely over them, doing no damage? They're 3do, so he can't move the 'center'. From what I've seen these tags get a good bit of use on 3do units, and any ability to set an offset would be very nice. It's troublesome when spring doesn't even show the aim center that units use.

Another mantis ticket is that units don't use the collision shapes for aiming, but the invisible model sphere, so units think they can't aim past allies when they easily can.

[Argh]

@Peet: A Size 20 unit that's long and skinny cannot sit side-by-side with other such units, unless it's clipping when in motion. So, it can be pretty awful visually, because of the huge area it takes up on the pathfinder vs. its apparent size visually.

Plus, huge things don't handle terrain angles well at all, and tend to clip like mad. Had to make the Advance Base in P.U.R.E., which is merely Size 10, restricted to very shallow slopes to avoid obvious borks.

Maybe try some experiments before telling me that I don't know what I'm talking about.

The only way to solve it that I think makes sense is to treat really big things with non-square footprints as a collection of footprints, and offset them roughly according to the current heading. Be a bit expensive, but probably is doable. I'm tempted to try prototyping it with Lua, using "units" that just serve as the "footprints" that would get constantly made / unmade every few frames. It would probably even work, but I'm scared about the cost of that many createUnit callouts on a regular basis.

[Peet]

If you're so supremely well-versed on this topic, tell me: what is the relationship between footprints and collision volumes?

[Argh]

Nothing at all. But part of the OP was about the desire to make Large Things, which is the only place where complex treatment of collision volumes is even worth the overhead, anyhow.

I'm basically reminding people that this is a fairly complex issue- you can't just throw in multiple collision volumes, and voila, large things make sense now. There is a scale, somewhere around size 8 or so, where the empty space that starts surrounding a non-square Unit because of the footprints starts to become really obvious. It's a problem that's needed solving for awhile.

[Peet]

In that case I apologize. It appeared (particularly due to your terminology) in your first post that you were talking about collision volumes affecting pathfinding.

[SpliFF]

I must be missing something. If footprints must be square then why are they defined using footprintX *and* footprintZ?

As for massive units I thought of a method that could work. On each slowUpdate iterate over massive units with more than one collision volume and test each volume to see if its bottom is below a certain height (something mod-configurable like maxBlockingHeight). If the piece is below maxBlockingHeight then work out how many ground squares it blocks based on the size of the collision volume and mark those squares as BLOCK_MOBILE.

Once again the apparent cost of this check is substantially reduced by massive units being a relative rarity, even late-game. Without cheating it is rare to see more than 30 T4 units in supreme commander and the stuff I want is more like T6.

The complexity of setting up the collision volumes can be solved by adding a PIECES collision type and splitting up the model in the modelling software. Even a massive model really shouldn't require more than about 20 pieces.

Finally, supporting this should do no harm. It can only cost cycles when activated (ud->massive==true && ud->collisionType=='pieces') so it won't hurt mods which don't have massive, irregularly shaped units.

[Snipawolf]

not square, but rectangular.

so, 4x4 is square, 6x4 is rectangle.

[SpliFF]

Actually there is one final piece to this puzzle. You'd want to add a BLOCK_MASSIVE path square type that fills the entire footprint of any massive object. This type would prevent massive units clipping but still allow smaller units to enter the unoccupied spaces. Terrain features like cliffs would also count as BLOCK_MASSIVE.

For anyone wondering why any of this is necessary here's a useful picture:



As you can see its footprint(s) to normal units are only a tiny fraction of its overall volume.

Anyway, attaching invisible, untargettable, unselectable, unkillable units to the feet would serve the same purpose but I'd like to see a less hacky solution.

EDIT: Actually, there is a final, very difficult problem. The walking animation would have to pause or push friendly units aside as the feet descend. Obviously you would make no such considerations for enemy units. Currently the feet would embed in your own units (or kill them). Maybe you could determine in advance where a foot will fall and reserve that place but I don't imagine this would be easy.

[AF]

devise a building that is equal toa footprint. Test for the nearest location it can be built on, and then clear it of units, and plonk the foot down.

[SpliFF]

that's even hackier than attaching units. Most could be done in lua sure but some new Lua->C interfaces would still be required. The required pseudo-sequence is:

Code: Select all

onStartAnim(anim, piece) do
   pos = piece.pos
   for (frame in anim.frames) do
      pos = pos*frame.transform
      if pos.y - (piece.height/2) < blockingHeight then
          -- piece will reach ground unit level at pos
          SetGroundBlocking(pos.x, pos.y, BLOCK_MOBILE)
          -- move units already there
          units = GetUnitsAroundPoint( pos, piece.radius )
          for (unit in units) do
              if IsFriendly(unit) do
                 if (frame.walltime > 5000) then
                    -- more than 5 seconds till footfall. tell units to get away.
                    OrderEvacuate(unit, pos, piece.radius)
                 else
                    -- not enough time to move. shove units away
                    PushUnit(unit, GetAngle(piece.pos,pos), piece.radius)
                 end
              end
           end
        end
   end
end

The biggest issue being that many of the functions I used don't actually exist. Other alternative methods would be to pause the unit before footfall if the area isn't cleared of friendlies or simply crush any friendlies not quick enough to move. Perhaps even a combination (give units a maximum evacuation time before the massive unit gets impatient enough to squash them anyway).