Jump to content
System downtime for updates - Sunday 13 July 2025 ×
The Dark Mod Forums

Recommended Posts

  • Replies 123
  • Created
  • Last Reply

Top Posters In This Topic

Posted

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?

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

Posted

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.

Posted

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

Posted

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.

Posted

I tried to solve the bigger aabb thing and some clue on what is responsible for the rendering optimization would be really helpful, since I can't solve it with trial and error ;-)

Posted

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

Posted

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?

Posted

Maybe I remember incorrectly, but I think I had to change the localAABB() method also to return a larger box (back when I added the light_center vertex). I could be wrong though, but it's an easy test.

Posted

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

Posted

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

Posted

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?

Posted

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.

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

Posted

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

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

    • JackFarmer

      "The Year of the Rat." 
      😄

      Al Stewart must be proud of you!
      Happy testing!
      @MirceaKitsune
      · 1 reply
    • datiswous

      I posted about it before, but I think the default tdm logo video looks outdated. For a (i.m.o.) better looking version, you can download the pk4 attached to this post and plonk it in your tdm root folder. Every mission that starts with the tdm logo then starts with the better looking one. Try for example mission COS1 Pearls and Swine.
      tdm_logo_video.pk4
      · 2 replies
    • JackFarmer

      Kill the bots! (see the "Who is online" bar)
      · 3 replies
    • STiFU

      I finished DOOM - The Dark Ages the other day. It is a decent shooter, but not as great as its predecessors, especially because of the soundtrack.
      · 5 replies
    • JackFarmer

      What do you know about a 40 degree day?
      @demagogue
      · 4 replies
×
×
  • Create New...