Two fixes - implementation of SoTextureCoordinateObject and draggers working with moving cameras

#1 Merged at 7c3f74f
  1. Gerhard R

The two commits fix two things: - implemented SoTextureCoordinateObject for linear texture functions - fixed draggers so that interaction works correctly even if the camera is moving while a user moves the dragger

Comments (13)

  1. Roy Walmsley


    I see that sometime ago you raised this pull request. I have been looking at your proposed changes to the SoDragger file. Can you explain what the problem was and why the change you propose works?



  2. Gerhard R author

    Hi Roy,

    Good to see that someone is again interested in Coin3D :). Are you becoming an active maintainer ?

    About the SoDragger.

    SoDragger stores a SbViewVolume data structure to compute the projection of the 2D mouse pointer onto the dragger geometry. This includes the projection information from the current camera, the camera transformation and any other transformation along the path to the dragger. However, the dragger computes this information only once, at the beginning of the interaction (mouse down event). After that it is assumed to be fixed.

    We were using Coin3D in a large virtual reality/augmented reality framework and for us the camera usually represented the head mounted display of a user. So the camera was tracked by some real-time tracking device and would move also during dragger interaction. Therefore the above information would be wrong and the interaction would become difficult or even impossible.

    My fix changes that so that the dragger always updates this view volume data structure. basically, I only had to add the code to the SoDragger::getViewVolume(void) method. However to make various symbols visible, I also had to move them before the getViewVolume implementation. That is the second part of the change.

    It is not the most efficient way, but should not be so expensive as it only happens on an interaction event. As the FIXME comment by pederb states, it would be better and more efficient if the SoHandleEventAction would already compute the transformations along the paths.

    let me know, if you have any other questions. I would be happy if the fix goes into some publicly used version of Coin3D.

    cheers, Gerhard

  3. Bastiaan Veelo

    I can confirm that SoDragger has this problem. I don't have a head mounted display (yet) but we do work with 3Dconnexion Space Navigator, which allows us to change the view direction during dragging.

    However, I think (haven't tried it but just by looking at it) that testing for vvdata and the dbaction can stay where they were, and only do

      if (PRIVATE(this)->draggercache && PRIVATE(this)->draggercache->path) {
        PRIVATE(this)->viewvolume = vvdata->vv;

    inside getViewVolume(). Would you agree, Gerhard?


    1. Gerhard R author


      I am not sure, but I just looked at the full code of SoDragger.cpp and I see that the implementation in getViewVolume was moved from setCameraInfo(). So I think it needs to be as it is, because otherwise the vvdata struct and the callback action are not initialised.

      cheers, Gerhard

      1. Bastiaan Veelo

        I assumed that getViewVolume() would only be called after picking the dragger, which would cause the initialisation. But this may not always be the case, I don't know. So it is safer to do it your way.


  4. Bastiaan Veelo

    While at it, could you explain a little about the second fix? (Next time maybe make separate pull requests for each fix.)

    • Does this make the implementation complete? Then the FIXME note by pederb can go.
    • dummy_object is not dummy anymore? -> name change.
    • Would you be able to fill in the gaps in the documentation? (I have no idea how and where this is used...)
  5. Gerhard R author


    yes, the second fix for SoTextureCoordinateObject just adds the missing implementation. Basically it allows to set a generic 4x4 matrix for texture coordinate computation. See the OpenGL docs for details:

    We used this for projective texture mapping, then the 4x4 matrix is the projection matrix into the "virtual camera" that projects the texture onto the geometry.

    To your questions: yes, I think it is complete that way well, it is still pretty much a dummy just to be able to return a const & Vec4. So name change is maybe not necessary * Not really. I currently don't have time to work on this anymore. I stopped working with Coin3D several years ago. This pull request was the last attempt to contribute to it :)

    Do you have more plans with it? I have a bunch of general extension nodes that could easily be added.

    1. Bastiaan Veelo

      OK thanks.

      Well, since Kongsberg gave up Coin3D it is now up to its users to keep it alive. Luckily Roy stepped up as the new maintainer. We are still organising ourselves, but I think there is enough interest to keep it going; I certainly hope it will.

      You are very welcome to share your extension nodes. If not in Coin, they could find a home in SmallChange. It would be best if you can adopt the same license (but you can keep the copyright) in order to keep legalities as simple as possible.

      This is the mailing list:!forum/coin3d-discuss

      Thanks, Bastiaan.

  6. Roy Walmsley

    Thanks for all the comments, Gerhard and Bastiaan. I will test your code changes in my application and let you know.

    While we are considering draggers can I also ask you to glance at issue #28 which I raised some time ago. Maybe one of you could test the code change for me.

    Gerhard, if you are willing to share your extension nodes then please let us know what they are. I will start off a forum thread on the topic, with a list of ones I could share.




  7. Gerhard R author

    Hi Roy,

    I posted a list of nodes on the google group. I didn't know this existed, very nice to still see so much interest in Coin3D.

    I won't have time in the next month to help with anything at all, but might be able to help with some integration work after that.

    cheers, Gerhard

  8. Roy Walmsley


    I have implemented both these fixes in my viewer application. I was able to test the dragger change and that is OK. I don't have a model to really test your SoTextureCoordinateObject change. Is it possible, or practical, for you to supply me with one?


  9. Gerhard R author

    Hi Roy,

    Here is an example IV file. The image in the Texture2 node can be any image you want. The idea is that the texture should be projected onto the cube as if it is thrown by a video projector onto the geometry. so the front of the cube will have a smaller image than the back etc.

    I am not sure what the resulting image will look like for this file, I fixed this several years ago and I don't have a running Coin3D installation for over a year on my machine.

    cheers, Gerhard

    #Inventor V2.1 ascii
    Texture2 { 
        filename "portal_home_color.png" 
        wrapS CLAMP
        wrapT CLAMP
    TextureCoordinateObject { 
        factorS 1 0 0 0 
        factorT 0 1 0 0
        factorR 0 0 0 0
        factorQ 0 0 1 0.5
    Cube {}