Jump to content
The Dark Mod Forums

mohij

Member
  • Posts

    244
  • Joined

  • Last visited

Posts posted by mohij

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

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

  3. 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?

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

  5. 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?

  6. More questions: The sphere/circles disappear once the speaker itself is out of the view, I guess this is not a desired effect. I probably have to set the AABB of the speaker to the outer radius or let them have their own AABB, but those are just guesses.

     

    The 3d view shows the lines of the 2d views which looks quite bad. I did some sort of separation with:

    if((state & RENDER_FILL) != 0) {
    	speakerDrawRadiiFill(m_origin, m_radii);
    }
    else {
    	speakerDrawRadiiWire(m_origin, m_radii);
    }

    but it obviously doesn't work.

     

    Atm the code draws three circles (one for each viewport), so the 2d viewports show all three circles, which doesn't look good (two of the three always look like lines, in 3d view all three circles are visible). Is there a way to draw things specific to a viewport? - Or even better, don't draw the circles directly as circles, but as a surrounding line of the 3d sphere, since that would look good in both, the 3d view port and the 2d views... I guess that will be a bit more complicate and involve the viewport vector or so, but it would really look better.

     

    Should I give this thing some nicer textures? - How?

     

     

    That's probably it for today. If things work out bad, that's even it until next weedend, but we'll see.

  7. With some trial-and-error I already fixed the first thing, I used m_aabb_local.origin, no idea what it does, but it works ;-P hehe.

     

    I think a button isn't that hard to do, so, I guess I'll try.

     

    Yet another question, I think angua already mentioned it, the spheres all seem a lot to small. Angua said the values have to be converted from metres to doom3 units. Any clue what the ratio metres/doom units is?

  8. Two more:

    Atm I have

    if (m_useSpeakerRadii)
    	renderer.addRenderable(m_speakerRadii, localToWorld);

    Which works, but renders the spheres only around the sound entity when it is located in global {0,0,0}, otherwise the spheres are located somewhere different than the entity. I guess the reason is localToWorld. But I have no idea what else could go in there since I basicaly just copied it.

     

    Should I add a switch that turns the spheres on/off? Or use the turn lightVolumes on/off switch?

  9. I think I have it done basicly. I simply copied the entire OpenGL code over from GTK-Radiant :-P.

    One small problem is left, I need three Vector3 functions that were obviously removed from DarkRadiant (vector3_scaled, vector3_added, vector3_to_array). Should I copy them too or rewrite the thing to work without them (probably more work)?

  10. Okay, finally got back to this.

     

    But still the observers are sort of a riddle to me...

    an example:

    in the .h file there is:

    OriginKey m_originKey;
    
    
    void originChanged();
    typedef MemberCaller<Speaker, &Speaker::originChanged> OriginChangedCaller;

    and in the .cpp file:

    m_originKey(OriginChangedCaller(*this))
    
    
    m_keyObservers.insert("origin", OriginKey::OriginChangedCaller(m_originKey));
    
    
    void Speaker::originChanged() {
     m_origin = m_originKey.m_origin;
     updateTransform();
    }

    It seems I need to write both, a class: OriginKey and a function: originChanged().

    Then I have to create a MemberCaller with my new function, the OriginChangedCaller. Then instanciate the OriginKey class with my OriginChangedCaller and finally parse another OriginChangedCaller that is member of the OriginKey class to the keyObserver.

     

    Seeing that I just want to observe three values and get notified when they change, does that really mean I have to write three classes (those that are already there all are in an extra file...) and three functions? Or do I miss the wood for the trees?

  11. I did an svn up and now radiant doesn't compile anymore :-(

    I get

    g++ -o build/release/plugins/archivezip/plugin.os -c -pipe -DPOSIX -DXWINDOWS -W -Wall -Wcast-align -Wcast-qual -Wno-unused-parameter -Wno-non-virtual-dtor -Wreorder -fPIC -O2 `xml2-config --cflags` -fPIC -Ibuild/release/radiant -Iradiant -Ibuild/release/include -Iinclude -Ibuild/release/libs -Ilibs -Ibuild/release/include -Iinclude plugins/archivezip/plugin.cpp
    include/itextstream.h: In member function 'virtual int TextInputStream::underflow()':
    include/itextstream.h:58: error: 'assert' was not declared in this scope
    scons: *** [build/release/plugins/archivezip/plugin.os] Error 1
    scons: building terminated because of errors.

  12. I need to check for the soundShader (to retrieve the SoundRadii class) and the s_min/max Distance keys so I can call the appropriate render.

    I guess I could either check for the values in render(), which would cause a lot of overhead, or I could add some sort of key observer. I guess the key observer is the way to go.

    The genericEntity class (which I copied) already contains some sort of observer, but I don't understand how it works. Any clues or other classes from which I could copy would be appreciated...

     

     

    btw. the Radiant shows five keys which could be of relevance for this: s_shader, s_mindistance, s_maxdistance, s_minDistance, s_maxDistance.

    I'm not sure which of those are relevant for the render. The original plan was to only retrieve the values from s_shader, but s_min/max Distance seem to allow to override those and perhaps s_min/max distance do something similar. Some clarification would also be helpful.

  13. Well then, this is the patch with the SoundManager changes: soundManager.diff.

    I only briefly tested it (copied changes over to clean checkout, got it to compile, one test run), but I guess it works.

     

    I think I'll restart with the Speaker class with a 1:1 copy of genericEntity. Since then it'll compile and work for once. I think I won't get anywhere when I continue to mix the light and genericEntity class without understanding what I do... <_<

     

    Oh, should I now actually go with the name == "speaker" check?

×
×
  • Create New...