Particle Collisions and Cutoff Feature

[Frost_Salamander]

I just recently became aware of this feature: https://wiki.thedarkmod.com/index.php?title=Particle_collisions_and_cutoff

Unfortunately I completely missed it, as when I went to create weather effects in my FMs I just followed this (which doesn't mention it): https://wiki.thedarkmod.com/index.php?title=A_-_Z_Beginner_Full_Guide_Page_3#Rain_and_Snow

The point of this thread is to a) make people aware of it and b) gather feedback from any mappers that have used it so we can get some mapper-focused documentation in the Wiki.  The page above is great for background information about how it works, but as a mapper I really just want to know:

• What are the limitations of this (i.e. when should it be used and when shouldn't it be used)?
• Why isn't it the default behaviour?  Why all this work to get it into the map?
• What built-in support for it exists (particle definitions, materials, etc). Do I need to create all this stuff myself?
• Texture layout vs. Linear layout: what's the difference in the end, pros/cons, why would I use one over the other...
• Why does it need a separate command (runParticle)? Can this just not be bundled in with dmap?
• A clear, step-by-step instruction on how to implement it in a map from beginning to end using a simple use case.

Tagging some users who have relevant experience with this: @stgatilov @Goldwell @Amadeus

Edited January 4, 2024 by Frost_Salamander

[Amadeus]

So, I do have some experience using the particle collisions for Written in Stone. At the time of development, I had to make custom weather particle and material defs in order to get it to work properly. Honestly, while the system is nice when it does work, it is complicated, quite a lot of work on part of the mapper, and can be very finicky. A minor change to the map can break the system (to which, the runParticle command needs to be run again after mapping).

One thing I don't get is why TDM doesn't have core materials that support particle collision right out of the box. There is a small handful of rain materials that support this, but most of the core weather textures, and particularly snow textures, all use "deform particle2" even though that is not supported by particle collision; "deform particle" is the correct keyword for this (as per the article here. 

I can't imagine why a mapper would ever want rain and snow to pierce through brushwork, like a ceiling in a house. And even if the mapper did want that, they could simply place a weather patch on the ceiling to make that happen.

Edited January 4, 2024 by Amadeus

[Amadeus]

I also did find one interesting issue this morning when going through Written in Stone. It seems like the snow particles got cut off at a visportal, which I imagine is a bug:
 

[stgatilov]

Particle collisions cannot be computed in realtime, particles are purely graphical effect which cannot interact with collisions. So the collisions have to be precomputed beforehand, just like dmap precomputes triangulations of brushes. Most of the nuances grow from here.

Quote

Why does it need a separate command (runParticle)? Can this just not be bundled in with dmap?

It was possible in theory to run it automatically during dmap (just like e.g. you never have to run aas tool directly, because dmap calls it automatically), but I'm afraid it would annoy everyone because it may take quite a lot of time depending on settings.

Now that some people have some practice with this, should we change it?

Quote

What are the limitations of this (i.e. when should it be used and when shouldn't it be used)?

Most importantly, collisions are precomputed statically.

If you move the emitter, the collision information becomes wrong.
All objects which seem dynamic are automatically excluded from precomputation, so the particles will still go straight through all the guards and moveables.

Quote

Why isn't it the default behaviour?

What do you mean by "default" behavior?
Default behavior of what? particles?

Like make all particle emitters stop on collisions automatically?
What about cases when mapper wanted particles to pierce walls?
What about moving particle emitters?

Quote

  Why all this work to get it into the map?

The goal was to reduce amount of work actually.
As soon as you are able to set one huge particle emitter over the whole map, I think you don't have to mess with it any more, just remember to execute runParticle occasionally when you want up-to-date collisions.

Before that, mapper had to split the rain patch into many patches and manually tweak every patch so that it stops at proper height. As far as I understand, it was very time-consuming and painful.

As for areaLock, it does not restrict particles to single area. It only disables the whole system if renderer proves player does not see the specified area. As long as the door is open, you should still see rain falling indoors, no?

Quote

Texture layout vs. Linear layout: what's the difference in the end, pros/cons, why would I use one over the other...

Yeah, this is a tough question.

Texture layout:

• Only works properly if particle evolves exactly the same way if emitted from the same location.
• Interacts with texturing: requires you to set non-overlapping texcoords in 0..1 range on the emitting surface.
• The only option in TDM 2.08. Ok for straight-falling rain, but snow is out of question.

Linear layout:

• Only works for a periodic system, i.e. the whole system exactly repeats itself after some time.
• Precomputation might take a lot of time, especially if you insist on a large period.
• [problem for maintainers like me] If particle code is changed in TDM engine, the collisions must be recomputed.
• Was added in TDM 2.09. Supports pretty much any kind of particles, although snow was the main goal.

[Amadeus]

2 minutes ago, stgatilov said:

What about cases when mapper wanted particles to pierce walls?

This does seem like it would be an edge case mostly. I know I wouldn't want to see smoke break geometry, sparks, etc., but I'm happy to be corrected on this. But at the very least, I think the weather particles (like snow and rain) should support particle collision right out of the gate, and it currently doesn't.

[stgatilov]

19 minutes ago, Amadeus said:

One thing I don't get is why TDM doesn't have core materials that support particle collision right out of the box. There is a small handful of rain materials that support this, but most of the core weather textures, and particularly snow textures, all use "deform particle2" even though that is not supported by particle collision; "deform particle" is the correct keyword for this

Because that we would have to copy/paste all rain materials to introduce "deform particle" version. Note that we cannot delete "deform particle2" versions because they are already used, and they cannot be replaced that easily.

Then we would have to copy everything again in order to add versions with collisions.
But I'm sure mappers might want to create rain patches of different size, so we'll probably have to have versions with layout texture 1024 1024, layout texture 512 512, layout texture 256 256, etc.
And then different mappers might have different feelings about the balance between quality and waiting time in case of layout linear, so we'll have many versions of snow too.

All of this causes combinatorial explosion, and we'll get at least ten times more materials and particle decls than we have now, causing a lot of confusion.

Perhaps combinatorial explosion can be avoided if these settings are specified in another file. I guess at that moment I was not brave enough to introduce a new type of decl files.

[Frost_Salamander]

1 hour ago, stgatilov said:

It was possible in theory to run it automatically during dmap (just like e.g. you never have to run aas tool directly, because dmap calls it automatically), but I'm afraid it would annoy everyone because it may take quite a lot of time depending on settings.

Now that some people have some practice with this, should we change it?

I haven't personally run it so not sure how long it actually takes.  @Amadeus how long did it take for WIS?

@stgatilov To make runParticle part of dmap,  is there a way to check if runParticle needs to be run or not first?  For example, if there are no particles present with 'collisionStatic' keyword than just skip it.  I wouldn't say this is big deal, but it's a manual step that the mapper could easily forget to run on release day...

 

1 hour ago, stgatilov said:

What do you mean by "default" behavior?
Default behavior of what? particles?

I meant the default weather materials - but Amadeus covered that in his question - thanks.

1 hour ago, stgatilov said:

As for areaLock, it does not restrict particles to single area. It only disables the whole system if renderer proves player does not see the specified area. As long as the door is open, you should still see rain falling indoors, no?

Actually this doesn't seem to be the case.  The rain seems to stay outside the visleaf if the door is open. In the example screenshot from inside the Inn in In Plain Sight, the rain patch actually extends over the roof of this building.  With the door open, the rain 'stays outside'.  However, you're right and still with this method you need to use individual patches and place them carefully (although I didn't have to worry about the height).  It's not perfect because rain will still poke through awnings and stuff outside.

 

Edited January 4, 2024 by Frost_Salamander

[peter_spy]

2 hours ago, Frost_Salamander said:

Unfortunately I completely missed it, as when I went to create weather effects in my FMs I just followed this (which doesn't mention it): https://wiki.thedarkmod.com/index.php?title=A_-_Z_Beginner_Full_Guide_Page_3#Rain_and_Snow

IMO there should be a warning of some sorts on this page. This tutorial was written by Fidcal ages ago, and there are possibly tons of things that might be severely outdated, and practices that would better be discouraged.

[Frost_Salamander]

Just now, peter_spy said:

IMO there should be a warning of some sorts on this page. This tutorial was written by Fidcal ages ago, and there are possibly tons of things that might be severely outdated, and practices that would better be discouraged.

yeah totally.  One of the outputs of this discussion will be to update that page.

[stgatilov]

16 minutes ago, Frost_Salamander said:

Actually this doesn't seem to be the case.  The rain seems to stay outside the visleaf if the door is open. In the example screenshot from inside the Inn in In Plain Sight, the rain patch actually extends over the roof of this building.  With the door open, the rain 'stays outside'.

I'm not sure you are right. It seems that it is limited by area scissor.
Basically, take axis-aligned 2D bounding box of the door visportal: that would be the scissor of the outer area. The particles should be limited to this rectangle only.

If you move around, this rectangle will change of course.

[Amadeus]

20 minutes ago, Frost_Salamander said:

I haven't personally run it so not sure how long it actually takes.  @Amadeus how long did it take for WIS?

 

so, "runParticle written" took 26 seconds... yeah, that's no small amount of time. Granted, WIS is a large map

Edited January 4, 2024 by Amadeus

[Amadeus]

27 minutes ago, Frost_Salamander said:

yeah totally.  One of the outputs of this discussion will be to update that page.

And hopefully update the particle collision page to provide clear step-by-step instructions for mappers on how to set up rain and snow particle collisions. In my opinion, it seems like weather effects will be the most common use case for this collision system, so simple instructions on how to prevent rain/snow from falling through an interior ceiling will be useful for most mappers 

[Frost_Salamander]

1 hour ago, stgatilov said:

I'm not sure you are right. It seems that it is limited by area scissor.
Basically, take axis-aligned 2D bounding box of the door visportal: that would be the scissor of the outer area. The particles should be limited to this rectangle only.

If you move around, this rectangle will change of course.

Well, if you say so.  If I remove the 'areaLock' spawnarg from the rain patches, it falls through the roof and it looks the same whether the door is open or closed.  I'm just saying that opening the door doesn't seem to make the rain appear inside as you suggested above.

Regardless, I'm not advocating the areaLock method, just reporting observations.

[Goldwell]

@Frost_SalamanderIt has been a good minute since i've played with particle collisions with rain, however I decided to revisit it after seeing your post and I can't seem to get it working.

 

@stgatilov could you please confirm if this is the right flow as it doesn't seem to be working in my map:

 

1) Create a .prt file containing:

   particle rain2_heavy2024 {
       {
           count               100
           material            textures/particles/drop2
           time                0.500
           cycles              0.000
           bunching            1.000
           distribution        rect 0.000 0.000 0.000
           direction           cone "0.000"
           orientation         aimed 0.000 0.040
           speed               "1000.000"
           size                "0.500" 
           aspect              "1.000" 
           randomDistribution  0.000
           fadeIn              0.200
           fadeOut             0.000
           color               0.040 0.040 0.040 1.000
           fadeColor           0.000 0.000 0.000 1.000
           offset              0.000 0.000 0.000
           gravity             0.000

		   collisionStatic
		   mapLayout			texture 512 512
       }
   }

 

2) Create a .mtr file containing:

   textures/darkmod/weather/rain2_heavy2024mtr
   {
       deform particle rain2_heavy2024
       qer_editorimage textures/editor/rain
       nonsolid
       noshadows
       {  //needed to emit particles
           blend   filter
           map      _white
       }
   }

3) Create the appropriate patch in game applying the above texture to it (with the texture fit to it and it facing down)

4) dmap missionname.map

5) runparticle missionname.map

 

But ingame the rain just ignores the brushes and falls right through:

 

Even using "particle_collision_static_blocker" "1" on this water entity, had no impact

[stgatilov]

On 1/13/2024 at 6:10 AM, Goldwell said:

3) Create the appropriate patch in game applying the above texture to it (with the texture fit to it and it facing down)

4) dmap missionname.map

5) runparticle missionname.map

Any warning during dmap?

Does your patch have [0..1] non-overlapping texcoords?

[Goldwell]

1 hour ago, stgatilov said:

Any warning during dmap?

Does your patch have [0..1] non-overlapping texcoords?

No warnings during dmap

 

re: the patch, how do I check if a patch has a "[0..1] non-overlapping texcoords"?

Is it correct in interpreting that to mean the texture has been fit to the patch? If so then yes.

 

This is the patch copied from DR if that helps:

 

<?xml version="1.0" encoding="utf-8"?>
<map version="1" format="portable">
  <layers>
    <layer id="0" name="Default" parentId="-1" active="true" hidden="false"/>
  </layers>
  <selectionGroups>
    <selectionGroup id="415" name=""/>
    <selectionGroup id="416" name=""/>
    <selectionGroup id="417" name=""/>
    <selectionGroup id="418" name=""/>
    <selectionGroup id="420" name=""/>
    <selectionGroup id="421" name=""/>
    <selectionGroup id="423" name=""/>
    <selectionGroup id="424" name=""/>
  </selectionGroups>
  <selectionSets/>
  <properties>
    <property key="EditTimeInSeconds" value="20837"/>
    <property key="LastCameraAngle" value="69 332.186 0"/>
    <property key="LastCameraPosition" value="20.0088 1653.64 531.677"/>
    <property key="LastShaderClipboardMaterial" value="textures/darkmod/nature/snow/snow_rough01"/>
  </properties>
  <entity number="0">
    <primitives>
      <patch number="0" width="3" height="3" fixedSubdivisions="false">
        <material name="textures/darkmod/weather/rain2_heavy2024mtr"/>
        <controlVertices>
          <controlVertex row="0" column="0" x="-448.000000" y="1712.000000" z="720.000000" u="0" v="0"/>
          <controlVertex row="1" column="0" x="-448.000000" y="1568.000000" z="720.000000" u="0" v="0.500000"/>
          <controlVertex row="2" column="0" x="-448.000000" y="1424.000000" z="720.000000" u="0" v="1.000000"/>
          <controlVertex row="0" column="1" x="-76.000000" y="1712.000000" z="720.000000" u="0.500000" v="0"/>
          <controlVertex row="1" column="1" x="-76.000000" y="1568.000000" z="720.000000" u="0.500000" v="0.500000"/>
          <controlVertex row="2" column="1" x="-76.000000" y="1424.000000" z="720.000000" u="0.500000" v="1.000000"/>
          <controlVertex row="0" column="2" x="296.000000" y="1712.000000" z="720.000000" u="1.000000" v="0"/>
          <controlVertex row="1" column="2" x="296.000000" y="1568.000000" z="720.000000" u="1.000000" v="0.500000"/>
          <controlVertex row="2" column="2" x="296.000000" y="1424.000000" z="720.000000" u="1.000000" v="1.000000"/>
        </controlVertices>
        <layers>
          <layer id="0"/>
        </layers>
        <selectionGroups/>
        <selectionSets/>
      </patch>
    </primitives>
    <keyValues>
      <keyValue key="classname" value="worldspawn"/>
      <keyValue key="difficulty0Name" value="easy"/>
      <keyValue key="difficulty1Name" value="medium"/>
      <keyValue key="difficulty2Name" value="hard"/>
      <keyValue key="shop_skip" value="1"/>
    </keyValues>
    <layers>
      <layer id="0"/>
    </layers>
    <selectionGroups/>
    <selectionSets/>
  </entity>
</map>

 

[stgatilov]

It should work I think.

[datiswous]

On 1/4/2024 at 5:22 PM, Amadeus said:

I also did find one interesting issue this morning when going through Written in Stone. It seems like the snow particles got cut off at a visportal

Would that also work with the water particle from a water arrow? Currently water-arrow splash particle moves down and would take out other torches, even a floor below.

See: This topic and this topic.

You could alter the particle, but it's probably easier if you could block it on a case basis. So you place a vp directly above the ceiling in the room under or something.

[Amadeus]

18 minutes ago, datiswous said:

Would that also work with the water particle from a water arrow? Currently water-arrow splash particle moves down and would take out other torches, even a floor below.

 

I'm happy to be corrected if I'm wrong, but I don't think so. There are some limitations with particle collisions for particle models, as shown on the wiki article here, but it might be worth testing anyway just to see what happens. I should also note that that visportal glitch is something I haven't been able to replicate, and I've really tried to

[datiswous]

I guess I should have read the whole wiki page first..

[datiswous]

On 1/13/2024 at 6:10 AM, Goldwell said:

Even using "particle_collision_static_blocker" "1" on this water entity, had no impact

Is this post describing a similar issue?

 

[Amadeus]

I think it's worth mentioning here that as of dev17095-10833, there are now several weather materials with static collisions enabled available for mappers to use. These are found in the textures/darkmod/weather/ folder and are called "rain2_downpour", "rain2_light", "snow2_flurries", "snow2_light", etc. You still have to run the "runParticle <mapname>" command after dmap (this must be done every time the proc file changes), but at least now you don't have to mess around with making custom materials. I've also added instructions in the material descriptions. 

More info can be found at the bugtracker here: #6545

[stgatilov]

On 1/13/2024 at 6:10 AM, Goldwell said:

@Frost_SalamanderIt has been a good minute since i've played with particle collisions with rain, however I decided to revisit it after seeing your post and I can't seem to get it working.

@stgatilov could you please confirm if this is the right flow as it doesn't seem to be working in my map:

Interestingly, I noticed that particle collisions don't work properly even on the demo map sometimes.

I have just found that "texture" layout is broken in Release builds of TDM (but works fine in Debug builds which I usually use). Most likely this is caused by MSVC optimizater bug.

Due to the bug, UV bounds of the emitter are computed incorrectly, so vast regions of the emitter surface have no collisions whatsoever. This is easy to detect if you compare with "correct" version: generated incorrect TGA files have randomly different size (i.e. they are randomly cropped).

I have no idea when this bug started happening in TDM. I feel lazy to bisect in tdm_installer...
The workaround will be in the next dev build of course (let's hope it will work properly).