Piece and mesh collisions

Piece and mesh collisions

Requests for features in the spring code.

Moderator: Moderators

User avatar
SpliFF
Posts: 1224
Joined: 28 Jul 2008, 06:51

Piece and mesh collisions

Post by 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).
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Piece and mesh collisions

Post by 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.
User avatar
Peet
Malcontent
Posts: 4384
Joined: 27 Feb 2006, 22:04

Re: Piece and mesh collisions

Post by 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.
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: Piece and mesh collisions

Post by 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.
User avatar
Peet
Malcontent
Posts: 4384
Joined: 27 Feb 2006, 22:04

Re: Piece and mesh collisions

Post by 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.
User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Piece and mesh collisions

Post by lurker »

If you want to hack it, just use invisible shields.
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: Piece and mesh collisions

Post by 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.
User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Piece and mesh collisions

Post by 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
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: Piece and mesh collisions

Post by 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.
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6241
Joined: 29 Apr 2005, 01:14

Re: Piece and mesh collisions

Post by FLOZi »

the old offset tag only affected 3DO's in the first place
Assuming this refers to my offset tag, that is incorrect.
User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Piece and mesh collisions

Post by lurker »

Kloot wrote: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.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Piece and mesh collisions

Post by 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.
User avatar
Peet
Malcontent
Posts: 4384
Joined: 27 Feb 2006, 22:04

Re: Piece and mesh collisions

Post by Peet »

If you're so supremely well-versed on this topic, tell me: what is the relationship between footprints and collision volumes?
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Piece and mesh collisions

Post by 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.
User avatar
Peet
Malcontent
Posts: 4384
Joined: 27 Feb 2006, 22:04

Re: Piece and mesh collisions

Post by 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.
User avatar
SpliFF
Posts: 1224
Joined: 28 Jul 2008, 06:51

Re: Piece and mesh collisions

Post by 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.
User avatar
Snipawolf
Posts: 4357
Joined: 12 Dec 2005, 01:49

Re: Piece and mesh collisions

Post by Snipawolf »

not square, but rectangular.

so, 4x4 is square, 6x4 is rectangle.
User avatar
SpliFF
Posts: 1224
Joined: 28 Jul 2008, 06:51

Re: Piece and mesh collisions

Post by 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:

Image

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.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Piece and mesh collisions

Post by 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.
User avatar
SpliFF
Posts: 1224
Joined: 28 Jul 2008, 06:51

Re: Piece and mesh collisions

Post by 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).
Post Reply

Return to “Feature Requests”