Jump to content
The Dark Mod Forums

Recommended Posts

  • Replies 123
  • Created
  • Last Reply

Top Posters In This Topic

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?

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
  • 5 weeks later...

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? :)

Link to post
Share on other sites

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.

Link to post
Share on other sites
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?

Link to post
Share on other sites

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. :)

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to post
Share on other sites

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.

Link to post
Share on other sites

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).

Link to post
Share on other sites

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 ;-)

Link to post
Share on other sites
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 :D

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites
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. :laugh:

 

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.

Link to post
Share on other sites
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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...