DIS filtering not working as expected

[Amerio.Stephane]

Hi, as we are starting to use multiple DIS emitters, we start to see unwanted behaviors:

Normally, the DIS filtering should be done like that, sequentially:

1. if PDU.exercise != IG.exercise then DISCARD PDU (ie don't talk to other exercises) (this works OK)
2. if PDU.app == IG.app AND PDU.site == IG.site then DISCARD PDU (ie don't talk to self) (this works OK)
3. ACCEPT PDU (this works PARTIALLY)
   • By default in Unigine, the PDU is accepted only if the PDU.app!= IG.app AND PDU.site == IG.site. Then the entity is correctly loaded with it's correct ID. In other cases the PDU is accepted but it's broken: the resulting entity ID does not create/load the correct entity, and the entity is shown with some long long int ID, and not it's DIS type. The entity is also placed at the origin and NOT where it should be. Sometime the entity is removed after some time with no DIS packet (DIS time out) and sometimes the broken entity sticks and is never removed.

You can very easily test it with the simHE tool I shared with you.

[silent]

Hi Stephane,

Multiple DIS emitters sounds scary, so far we also never encountered such setups :)

Could you share a bit more detail about the issue and the exact steps to reproduce it? That would be extremely helpful. In particular, we’re interested in the following:

Quote

By default in Unigine, the PDU is accepted only if [...]. In other cases the PDU is accepted but it's broken

What are the "other cases" - could you please give us a bit more information regarding them? The only case we think of is the "PDU.app == IG.app AND PDU.site != IG.site". Is that correct?

Are you also using custom filter for DIS? If so, could you please tell us how you are filtering the packets and tell exact PDU.app/PDU.site/PDU.exercise are you using and what expect result you want to achieve?

Thank you!

[Amerio.Stephane]

Our IG is configured as: IG.app=100, IG.site=1, IG.ex=1

 

Sending PDU.app=3001, PDU.site=1, PDU.ex=1:

OK

 

Sending PDU.app=3001, PDU.site=3, PDU.ex=1:

KO (the white cube and the 196673636 entity are at the world origin)

It should have been exactly like the previous image. If I stop sending the DIS entity and wait for the DIS timeout, then nothing changes, the bogus entity is still there. If I change back to send with PDU.site=1, then the helicopter is back and the bogus one is removed.

 

Sending PDU.app=100, PDU.site=1, PDU.ex=1 (so the same values as the IG):

KO. There should not be any entity apart id 0. Again, if I stop sending the entity, it should be removed after a timeout, but it isn't removed.

 

If I then send with a DIS.app=101 (so different from IG):

KO. The helicopter is back (as expected), but the bogus entity is still there (it will never be removed).

 

I haven't look into the CustomPacketIDFilter but I will give it a try. But anyway, I think the behavior "out of the box" should be the expected standardized one (still, it's a good idea to have this customization level if needed).

EDIT: Looking at the API, I think it isn't usable "as-is" because you shouldn't filter just by looking at the 3 ID values independently (app, site, exercise): you actually need to filter based on the 3 values at once! So the API should be changed in a future revision...

 

For some context, we typically used - until recently - only one DIS emitter to populate and liven up our scenarios (adding some air traffic, boats, and poor lost people to be rescued in the mountains). But for future scenarios, we also want to integrate with other simulations, both on site and off site. All will be running DIS. Some will be other helicopters, some will be traffic, etc. On site, our main simulation will be required to communicate both CIGI (with the IG) and also DIS (so the other simulators can see us too), so our IG will see both the CIGI and DIS. That's why we need some way to tell apart PDU we want to see and those we want to ignore. AppID and SiteID are exactly made for that.

 

 

Edited October 27 by Amerio.Stephane

[silent]

Hi Stephane,

Thank you for the clarifications!

Yes, a refactoring of the DISConnector plugin will be required to support filtering by all three values (app/site/ex) simultaneously, in order to prevent any potential collisions between resulting Entity IDs.

We plan to carry out this refactoring shortly after the 2.21 release, as it's not yet clear whether we'll be able to include additional features in that version. In any case, I believe we now have all the necessary information to proceed with this task.

Thanks again for your detailed explanations!