CIGI issues with LOS Segment / Vector both requested

[Lales.Charles]

Hi,

We noticed an issue with LOS Segment / Vector both requested with same params with src coord system CigiLosVectReqV3_2::Entity and checking 10m bellow the entity.
Separately, both work fine and answer valid offsets. Even intersection masks are fine ;)
But requested together -> Unhandled exception at 0x00007FFFCAA6B0BE (ucrtbase.dll) in cigi_2-9_x64d.exe: Fatal program exit requested.

In our host implementation, here are CIGI packet / version used:

• LOS Segment request -> CigiLosSegReqV3_2
• LOS Vector request -> CigiLosVectReqV3_2

It is reproduced with CIGI demo 2.9, only ig_config.xml updated.

Any clue?

Kind regards,
Charles

Related to this topic, are all object intersect validated?

For example ObjectWaterGlobal works fine, but ObjectWaterMesh not really, even with intersect mask set to all. 

[morbid]

Hi Charles,

I assume you're using a custom CIGI Host application.

Can you send us a full Call Stack?

34 minutes ago, Lales.Charles said:

For example ObjectWaterGlobal works fine, but ObjectWaterMesh not really, even with intersect mask set to all. 

Last time I've tried this with WaterMesh it worked. Can you give some more info on the issue?

Thank you.

[Lales.Charles]

Hi,

For the water I setup the world with default ground, add WaterMesh instead of WaterGlobal, setup intersect mask, and run it -> no intersection detected / sent to host.
Exactly the same world, but MeshStatic instead, with same intersect mask -> intersection detected / sent to host.

Regarding the LOS Segment / Vector issue, yes it is in-house CIGI host / wrapper or IG abstraction.
What is disturbing is that only segment request is fine, only vector as well, but both crash.

Pack LOS Segement request

CigiLosSegReqV3_2 req;

req.SetLosID( id );
req.SetReqType( CigiLosSegReqV3_2::Extended );
req.SetUpdatePeriod( los.update_period );

if ( los.source_point_coordinate_system ) {
	req.SetSrcCoordSys( CigiLosSegReqV3_2::Entity );
	req.SetEntityID( los.source_entity_id );
	req.SetSrcXoff( los.source_x_offset );
	req.SetSrcYoff( los.source_y_offset );
	req.SetSrcZoff( los.source_z_offset );
} else {
	req.SetSrcCoordSys( CigiLosSegReqV3_2::Geodetic );
	req.SetSrcLat( los.source_latitude  );
	req.SetSrcLon( los.source_longitude );
	req.SetSrcAlt( los.source_altitude  );
}
if ( los.destination_point_coordinate_system ) {
	req.SetDstCoordSys( CigiLosSegReqV3_2::Entity );
	req.SetDestEntityID(      los.destination_entity_id );
	req.SetDestEntityIDValid( los.destination_entity_id_valid );
	req.SetDstXoff( los.destination_x_offset );
	req.SetDstYoff( los.destination_y_offset );
	req.SetDstZoff( los.destination_z_offset );
} else {
	req.SetDstCoordSys( CigiLosSegReqV3_2::Geodetic );
	req.SetDstLat( los.destination_latitude  );
	req.SetDstLon( los.destination_longitude );
	req.SetDstAlt( los.destination_altitude  );
}

req.SetResponseCoordSys(
		los.response_coordinate_system ? 
		CigiLosSegReqV3_2::Entity : CigiLosSegReqV3_2::Geodetic
		);
req.SetAlphaThresh( los.alpha_threshold );
req.SetMask(        los.material_mask );

*outgoingMsg << req; //operator call pack

Pack LOS Vector request

CigiLosVectReqV3_2 req;

req.SetLosID( id );
req.SetReqType( CigiLosVectReqV3_2::Extended );
req.SetUpdatePeriod( los.update_period );

if ( los.source_point_coordinate_system ) {
	req.SetSrcCoordSys( CigiLosVectReqV3_2::Entity );
	req.SetEntityID( los.entity_id );
	req.SetSrcXoff( los.source_x_offset );
	req.SetSrcYoff( los.source_y_offset );
	req.SetSrcZoff( los.source_z_offset );
} else {
	req.SetSrcCoordSys( CigiLosVectReqV3_2::Geodetic );
	req.SetSrcLat( los.source_latitude  );
	req.SetSrcLon( los.source_longitude );
	req.SetSrcAlt( los.source_altitude  );
}

req.SetResponseCoordSys(
		los.response_coordinate_system ? 
		CigiLosVectReqV3_2::Entity : CigiLosVectReqV3_2::Geodetic
		);
req.SetVectAz(      los.azimuth );
req.SetVectEl(      los.elevation );
req.SetMinRange(    los.minimum_range );
req.SetMaxRange(    los.maximum_range );
req.SetAlphaThresh( los.alpha_threshold );
req.SetMask(        los.material_mask );

*outgoingMsg << req; //operator call pack

Would you see anything wrong?

Kind regards,
Charles

[morbid]

17 hours ago, Lales.Charles said:

For the water I setup the world with default ground, add WaterMesh instead of WaterGlobal, setup intersect mask, and run it -> no intersection detected / sent to host.
Exactly the same world, but MeshStatic instead, with same intersect mask -> intersection detected / sent to host.

Confirmed, Water Mesh has major intersection issue and HAT/HOT wouldn't work for this object. I'm afraid we have no time to fix it before stable 2.10. As a workaround I suggest adding the same Static Mesh as a separate object with disabled viewport mask. HAT/HOT request will return it's value.

As for the crash, we had caught something very similar once, but we can't reproduce it. Will continue to investigate. Call Stack from your side could be helpful.

Thanks.

[cash-metall]

Hello, Charles! 

Сan you attach the stack trace and log.html when the application crashes again? Maybe network capture via WireShark? 

 

[Lales.Charles]

Hi,

Please find attached CIGI (anonymized) packets host -> IG with different requests:

• only segment / vector -> OK
• both -> KO

As you can see, we're sending numerous CIGI packets simultaneously:

Kind regards,
Charles

losbothsegmentvector_anon.pcapng lossegmentonly_anon.pcapng losvectoronly_anon.pcapng

[cash-metall]

Hi, Charles

I could not reproduce this problem. not at 2.9 not at 2.10.
it seems like the problem is in something else....

can you try to test (on a clean IG without weather, without an entity) send only these two requests in one package?