Skip to content

Send emitter parent balls to destiny for line of sight occlusion - #30

Open
phevosccp wants to merge 1 commit into
mainfrom
occlusion-parent-ball
Open

phevosccp wants to merge 1 commit into
mainfrom
occlusion-parent-ball

Conversation

@phevosccp

@phevosccp phevosccp commented Oct 27, 2026 •

Copy link
Copy Markdown
Member

Summary

Follow-up to #22. Emitters on a deployable or wall were occluded by that object's own collision. Trinity now gives each emitter the ball it is mounted on through ITr2AudParentBall (carbonengine/trinity#134).

IEveObstructionQuery2 replaces IEveObstructionQuery. Blue matches interfaces by name, so the new QuerySightlines signature needs a new name. Destiny implements both, so destiny ships first.

Depends on carbonengine/trinityaudioapi#11. The carbon-trinityaudioapi bump follows once the registry has the port.

Testing

  • ctest: 98/98 pass.
  • Frontier client: hull and container emitters are no longer blocked by its own collision, and a separate wall still blocks them.

Trinity tells each emitter which ball it is mounted on through
ITr2AudParentBall. Emitters hold it weakly and the sightline pass hands
it to destiny with the emitter's position, so destiny can skip that
ball's own geometry. Deployables and walls no longer occlude their own
emitters.

IEveObstructionQuery2 replaces IEveObstructionQuery: Blue matches
interfaces by name, so the new QuerySightlines signature needs a new
name.
@phevosccp phevosccp changed the title Pass emitter parent balls to destiny via IEveObstructionQuery2 Send emitter parent balls to destiny for line of sight occlusion Oct 27, 2026

@ccp-zoetrope ccp-zoetrope left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made a suggestion that I don't consider blocking but more of a nice to have if you agree.

* @return False when there is no answer right now (no world loaded, mid-transition). It means "ask
* again", not "nothing is blocked": the caller keeps its previous results and retries.
*/
virtual bool QuerySightlines( const Vector3& source, const Vector3* targets, IRoot* const* targetParents, unsigned int targetCount, bool* outBlocked ) = 0;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're redefining the interface currently I think it would simplify things if both the position of the ball and it's owner travelled together in a struct or something. Something like

struct EveSightLineTarget
{
    Vector3 position;
    IRoot* parent;
}

Instead of having targets and targetParents as separate concepts.

From a readability point of view it makes it easier for me to reason about personally and will make it easier to not accidentally have the parent and position drift while keeping track of them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants