Speaker radius

[mohij]

I finished the conversion metres -> inch thingy and fixed some bugs.

Left:

On/Off switch

Better lines in 2d/3d view

bigger AABB

[mohij]

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?

[OrbWeaver]

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.

[mohij]

My speaker needs to support it, since the Min/Max Radii are variable. I guess that means some copying from the Light class...

[OrbWeaver]

Yes, you will need to detect the changing of the radius and update the local AABB accordingly.

[mohij]

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.

[OrbWeaver]

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

[mohij]

As I said, I already tried only to change the m_aabb_local. If you want you can try a diff:

speakerRadii.tgz

The speaker folder goes into /plugins/entity

 

I'll try the other thing you said.

[OrbWeaver]

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.

[mohij]

Hm, I tried that for fifteen minutes, but didn't get it to work, I'll try again next time, maybe more luck then ;-)

[mohij]

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

[OrbWeaver]

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

[mohij]

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?

[greebo]

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.

[mohij]

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

[greebo]

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.

[OrbWeaver]

I too have applied your patch and will look at it in due course.

 

I have committed the missing <cassert> include already, since Tel seemed to have this problem in the public forums.

[greebo]

I'm getting constant reproducible crashes now on the entity module startup, I'll have to debug this.

[greebo]

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?

[OrbWeaver]

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.

[greebo]

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.

[OrbWeaver]

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.

[greebo]

Reverted and committed. Now I can finally apply mohij's diff file and look into what's happening there.

[greebo]

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

[OrbWeaver]

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

 

Indeed I am, I will have to check when I get home.