Speaker radius

[greebo]

No problem, as it seems I'll be darkmodding the whole day anyway - I'm motivated right now.

 

Btw: did you get my PM concerning Tels?

[OrbWeaver]

I don't see any crash, the function appears to work OK (showing an inner and an outer radius).

[greebo]

This means std::cout for teh win. Hopefully this won't take too long to debug.

[greebo]

It didn't take long to find the bug: the GlobalSoundManagerModuleRef was missing in the entity module, that's why the call to GlobalSoundManager() crashed in the callbacks.

 

I can see the radius now and I think that works fine. I can also see the problem with the radius disappearing when moving the center off-screen - I'll look into fixing this.

 

edit: I changed the Speaker::localAABB() to return m_aabb_borders instead of m_aabb_local (which is just the small entity cube). The speaker doesn't disappear now. But: there is something amiss when changing the maxDistance to large values. The speaker including radius disappears now again, but not immediately (the box must be farther off-screen a bit).

 

I can only guess that the unit conversion (metres Doom units) in RenderSpeakerRadii::localAABB() or somewhere else is not fully performed? I might be wrong of course. Mohij, did you check whether the AABB of the speaker radius is always correctly set?

[OrbWeaver]

Regarding the two AABBs, I suggest using only a single AABB which always includes the speaker radius (i.e. it is equivalent to m_aabb_borders). This means that the speaker entity would be rendered if its radius was onscreen even if the "show speaker radii" button was off, but I don't think this would be a performance issue because it is only a small unshaded cube.

[mohij]

greebo: I tried using my m_aabb_border in localAABB() again and it still doesn't show correct results over here. Could you post the relevant code? (what else could influence this?)

 

No, I didn't check wether the speaker AABB is correct, but if I remember correctly I once accidentially changed the renderer to draw the speaker box st the size of the bigger AABB and that looked correct (the box exactly surrounded the biggest circle (ironicly the thing still disappeared at small box size...)).

I also didn't check for correct conversion of metres-> inch, but the conversion shouldn't influence the AABB, since conversion is done long before on parsing the soundShader.

[greebo]

I think I just replaced the line in localAABB() to return m_aabb_borders.

 

Here's my current state (including some debug output you can ignore): http://208.49.149.118/TheDarkMod/DarkRadia...dii_greebo.diff

 

I didn't look too far into it, but this is how I would approach this problem. I would try to send the current AABB to std::cout as soon as it gets changed (in updateAABB()). There should exist a stream insertion operator to conveniently pass the AABB objects to the stream. Then I would see if these number made sense or whether they could be problematic.

[greebo]

I've lost the overview over this topic, I must admit. Mohij, how is the status of the speaker radius code? Are you waiting on my input or are you still working on that or burned out on that or didn't have time?

[mohij]

Actually I didn't find the time in the last 3 weeks, since I had (maybe have) to manage all the things concerning my studies (I was on an excursion entire last week, I just came home an hour ago). I guess things will start to relax a bit now. And since there isn't much left on this, I should really finish this now, I guess. I'll probably find time on monday evening.

[greebo]

Ok, sounds good.

[mohij]

Well, except for some debugging I didn't get far today.... :-(

[greebo]

Nevermind, this is how things can go. Just keep at it.

[mohij]

What I found out: the m_aabb_border is set correctly. Still the radii disappear when the box get's out of sight. After moving the speaker, things work. So my question is, what happens on translation?

[greebo]

So my question is, what happens on translation?

After translation, the new origin is baked to the entity's spawnargs (after you release the mouse button). During the mouse drag the "original" origin is staying the same, and a "working copy" is used.

 

You can look at freezeTransform(), maybe there is some sort of AABB recalculation in there, which is not called at construction time?

[Fidcal]

While you're deeply into this and mentioned doom units, someone might satisfy my curiosity as to why the min/max distances (spawnargs) are not in doom units. I estimated them at 40 doom units.

[Crispy]

A lot of speaker stuff is almost in metres. If you want a speaker to have a radius of X doom units, go to Google and type "X inches in metres". The number you get back is the appropriate radius.

 

I say "almost in metres" because 1 Doom unit is not 1 inch. It's more like 1.1 inches. It was probably meant to be 1 inch when the sound code was written, but nothing else uses that scale.

 

1 meter = 39.3700787 inches, so yeah, 40 Doom units is about right.

[Fidcal]

Wow - my guesstimate was pretty good. I think I worked it out in-game by edging along until I found where the sound ended then checking it in DR. I should have spotted the 'inches in a metre' relationship. But what use is it I cannot imagine to have different units. One or the other but not both. Anyway, if this radius display comes off OK it won't matter so much.

[mohij]

I nailed it down to m_transformChanged(). That's an external callback, so no idea what it actually does...

[greebo]

The m_transformChanged is pointed at InstanceSet::TransformChangedCaller. The callback is connected during at construction time by the EntityNode.

 

The InstanceSet::TransformChangedCaller (see libs/instancelib.h) is some sort of relay which calls transformChanged() on all Instances of the given Node in question (there is usually only one Node for each Instance, except for Models, but this is not the case here).

 

So the call will arrive at scene::Instance::transformChanged. This in turn walks through the entire subgraph (all child objects) of the Node in question and calls transformChangedLocal, which sets a few flags, including m_boundsChanged.

 

The subsequent call to Instance::boundsChanged again sets the m_boundsChanged flag to TRUE (which will trigger a bounds re-evaluation the next time worldAABB is invoked) and calls GlobalSceneGraph().boundsChanged() (which triggers a callback to the SelectionSystem and the WorkZone).

 

*gasp*

 

In the end, the m_transformChanged call will set the m_boundsChanged flag to TRUE, so the next time someone calls worldAABB() (usually the renderer frontend does that for culling), the method Instance::evaluateBounds is invoked. This will go through and include the localAABB() of the Instance.

 

I can't actually help you in explaining where things go wrong, but maybe this gives you a clue. Do you have a debugger at hand for stepping through that?

 

Let me know if you feel like punching someone (preferably the one who created this cobweb of callbacks).

[mohij]

So if I get this right, it is normal that I have to call the InstanceSet::boundsChanged() before the bounds are updated. Then there is no bug in there at all, I simply didn't call anything like that. So the only question left is, how to call that thing best. Do I have to add a callback?

 

 

btw. I nearly forgot, in order to get the allowance to work on DarkRadiant, I have to inform the guys I "work for" that I am an IBM employee. I guess posting in here should suffice ;-)

[Tels]

So if I get this right, it is normal that I have to call the InstanceSet::boundsChanged() before the bounds are updated. Then there is no bug in there at all, I simply didn't call anything like that. So the only question left is, how to call that thing best. Do I have to add a callback?

btw. I nearly forgot, in order to get the allowance to work on DarkRadiant, I have to inform the guys I "work for" that I am an IBM employee. I guess posting in here should suffice ;-)

 

Welcome, oh slayer-of-SCO

[OrbWeaver]

btw. I nearly forgot, in order to get the allowance to work on DarkRadiant, I have to inform the guys I "work for" that I am an IBM employee. I guess posting in here should suffice ;-)

 

Heh, so am I.

 

I wasn't aware of that rule though. FWIW I haven't felt the need to ask "permission" to work on something which is (1) completely unrelated to my job and (2) not done using company resources or time.

[New Horizon]

I would tell them to stuff it. lol

[OrbWeaver]

I would tell them to stuff it. lol

 

I just don't tell them at all. Given that they hate my guts already (because I won't suck their greasy corporate cock like they expect) I don't want to give them any more reason to kick me out, at least not until I've found a proper job to go to.

[mohij]

@OrbWeaver: Hm, that doesn't sound like you'd like the job...