Jump to content
The Dark Mod Forums

Speaker radius


Recommended Posts

  • Replies 123
  • Created
  • Last Reply

Top Posters In This Topic

Okay, wierd question: Is an entity reconstructed everytime it is translated in some way? I ask because the m_aabb_local seems to be initialized only once on construction of the entity and isn't changed from then on. Is it sufficient to place my AABB checking methods (which AABB is the biggest?) in Speaker::construct() and everything will work?

Link to comment
Share on other sites

Is an entity reconstructed everytime it is translated in some way?

 

Not, not as far as I know.

 

I ask because the m_aabb_local seems to be initialized only once on construction of the entity and isn't changed from then on.

 

The local AABB is relative to the origin of the object, therefore it is not affected by translations. If the entity was resized then the AABB would need to change, but I don't know if there are any entities (other than lights) which actually support resizing.

Link to comment
Share on other sites

I tried to change m_aabb_local, but the results were different (the rendered box of the sound shader got the size of the outer radius, but the aabb that defines when to render and when not staid). Now I tried to change the RenderableSolid/WireAABB this way:

void Speaker::updateAABB() {
 // set the AABB to the biggest AABB the speaker contains
 //m_aabb_local = m_entity.getEntityClass()->getBounds();
 AABB newAABB = m_aabb_local;
 newAABB.includeAABB(m_speakerRadii.localAABB());
 m_aabb_solid = RenderableSolidAABB(newAABB);
 m_aabb_wire = RenderableWireframeAABB(newAABB);
}

but get this error:

libs/entitylib.h: In member function 'RenderableSolidAABB& RenderableSolidAABB::operator=(const RenderableSolidAABB&)':
libs/entitylib.h:323: error: non-static reference member 'const AABB& RenderableSolidAABB::m_aabb', can't use default assignment operator
plugins/entity/speaker/Speaker.cpp: In member function 'void entity::Speaker::updateAABB()':
plugins/entity/speaker/Speaker.cpp:207: note: synthesized method 'RenderableSolidAABB& RenderableSolidAABB::operator=(const RenderableSolidAABB&)' first required here 
libs/entitylib.h: In member function 'RenderableWireframeAABB& RenderableWireframeAABB::operator=(const RenderableWireframeAABB&)':
libs/entitylib.h:336: error: non-static reference member 'const AABB& RenderableWireframeAABB::m_aabb', can't use default assignment operator
plugins/entity/speaker/Speaker.cpp: In member function 'void entity::Speaker::updateAABB()':
plugins/entity/speaker/Speaker.cpp:208: note: synthesized method 'RenderableWireframeAABB& RenderableWireframeAABB::operator=(const RenderableWireframeAABB&)' first required here

I also tried to change that function to non-const, but it didn't help. No idea what's wrong.

Link to comment
Share on other sites

It's complaining because there is no operator= defined for AABB (I think). Instead, try writing

 

AABB newAABB(m_speakerRadii.localAABB());

 

although this may still complain if AABB does not have a copy-constructor, in which case you will probably need to define one.

 

I'm not sure what m_aabb_solid and m_aabb_wire are for, but I don't think we need to worry about renderable AABBs for the speaker class -- you don't actually want to see the AABB, it just needs to be there so that the renderer knows what to render.

 

Perhaps the method only needs a single line in fact

 

m_aabb_local = m_speakerRadii.localAABB();

 

(after making sure that an operator= is defined for AABB).

Link to comment
Share on other sites

Thanks, I'll look at the changes when I have some time.

 

For reference, the svn diff function should also be able to include newly-added files, meaning that you don't need to send these separately. I suspect you have to use svn add locally before they will appear in the diff.

Link to comment
Share on other sites

I believe it is the Cullable interface.

 

class Cullable
{
public:
 STRING_CONSTANT(Name, "Cullable");

 virtual VolumeIntersectionValue intersectVolume(const VolumeTest& test, const Matrix4& localToWorld) const = 0;
};

 

The renderer supplies a View which is a subclass of VolumeTest, and invokes the intersectVolume() method on all renderable objects to test for their visibility. The cullable object then calls back methods on the VolumeTest (e.g. TestPoint() or TestAABB()) to determine an intersection value -- completely enclosed, partially enclosed or not enclosed (and therefore not rendered).

Link to comment
Share on other sites

I did a small (hopefully fool proof) test:

VolumeIntersectionValue Speaker::intersectVolume(
const VolumeTest& volume, const Matrix4& localToWorld) const
{
Vector3 radiiVector (100, 500, 200);
AABB bla (m_aabb_local.getOrigin(), radiiVector);
return volume.TestAABB(bla, localToWorld);
}

Still the object disappears exactly when the speaker box gets out of view.

So what's wrong here?

Link to comment
Share on other sites

const AABB& Speaker::localAABB() const {
Vector3 radiiVector (100, 200, 300);
return AABB (m_aabb_local.getOrigin(), radiiVector);
}

That causes, independent of the values of the vector, that the speaker disappears once a specific point (always the same spot, slightly next to the center of the speaker) is out of the view. That's also a strange result...

 

Would it help if I'd upload my current code?

 

Edit: here it is

and this time I even got it to work with svn :-)

Link to comment
Share on other sites

I merged your changes in and I'm doing a fresh recompile right now. Lately, I got a few crashes while loading the entity module (before your changes too), hopefully these can be fixed by a fresh compile.

 

I'll post back here what I can find, although this may take a bit. :)

Link to comment
Share on other sites

The crashes were introduced in revision 2229, before that everything works fine. In the log I can only see the removal of the requiredGameDescriptionKeyValue method from iradiant.h which has been replaced by the corresponding game::Manager calls. I can't quite see why this should cause crashes, but there is something going on.

 

I hope I can debug this using std::cout's as many of the ModuleRef stuff happens in the constructors' initialiser lists. Does everything work fine under Linux?

Link to comment
Share on other sites

I certainly haven't noticed any crashed under Linux, I will try a full recompile and see if that causes anything.

 

If necessary this change can be rolled back, once the new module system is done it will probably all be different anyway.

Link to comment
Share on other sites

I dug into this for the last hour and could locate the crash in the GlobalMRU instance, with the call to GlobalPreferenceSystem(). I added the missing ModuleRef to the RadiantDependencies, but this didn't help. After redirecting the call directly to the GetPreferenceSystem() as a workaround, the program continues but crashes somewhere else, so I conclude that there is some weirdness going on. Everything worked fine before, I can't imagine where things go amiss here.

 

I think I'll take the easy road and revert the changes from rev 2229, because as you said the problem might go away when the new modulesystem is in place.

Link to comment
Share on other sites

I dug into this for the last hour and could locate the crash in the GlobalMRU instance, with the call to GlobalPreferenceSystem(). I added the missing ModuleRef to the RadiantDependencies, but this didn't help.

 

Yes, that's exactly what happened when I tried to fix up the Radiant/RadiantCoreAPI classes. I didn't know that the existing change was also causing this problem though.

 

I think I'll take the easy road and revert the changes from rev 2229, because as you said the problem might go away when the new modulesystem is in place.

 

Agreed. The change is not important for now, and the sooner we dispose of the whole mess the better.

Link to comment
Share on other sites

I'm getting a crash as soon as I add a soundshader to a speaker entity (or when I'm loading a map with an existing speaker). I don't have any debugger here yet, I'll have to setup Ubuntu on my laptop first - I'm tired of debugging with std::cout's in my Windows environment for now. I don't know whether Ubuntu will run at all on this system and I'm not too enthusiastic on installing it right now, so this may take a while. ;)

 

Does it run on your end, OrbWeaver? (I assume you're at work now?)

Link to comment
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.


  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 3 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...