Updating ANVEL versions with plugins



  • I have been using ANVEL 2.0 with a number of plugins installed. I recently updated to version 2.5 and most of the plugins loaded correctly after being moved to the new folder but a few returned errors in the log window and did not load.
    07:47:36.40: Could not load dll: SensorPlugin.dll
    07:47:36.40: LoadLibraryExA failed with error 0: The operation completed successfully.
    07:47:36.40: Unloading previously unloaded dynamic library SensorPlugin.dll
    File locations referenced should still be the same and I did not see any version references within the source code of the plugin.
    Is there an extra step for updating these?



  • @dsb0029,

    Thanks for your question! The best practice is to actually rebuild the plugins and link against the 2.5 ANVEL libs, otherwise we can't guarantee that they will "just work" with another version of ANVEL. Any number of small changes could've impacted the SensorPlugin functionality. If rebuilding doesn't do the trick, let us know and we can take a look at your plugin.

    Regards,
    ANVEL Team



  • @ANVEL-Team

    We have re-compiled the SensorPlugin for ANVEL 3.0, and I've tried loading the plugin through File>Load Plugin... in the ANVEL window. The Log Window prints "Loading dynamic library C:\Program Files\Quantum Signal, LLC\ANVEL Academic Edition 3.0\bin\x64\Release\Plugins\SensorPlugin.dll", no errors are printed, but no new sensors appear in the Assets window.

    Are there any quick suggestions as to why a sensor would not load in from a plugin?

    Thank you for your assistance!



  • @ANVEL-Team

    Update: Adding SampleSensorStaticAssetParams to the SampleSensorFactory() in the sensor .cpp file, as per the SensorPlugin example included with ANVEL 3.0, allowed the sensor to be loaded in and appear in the Assets window. I’m not sure why the plugin didn’t need these asset params defined when it worked in 2.0.

    Thanks!



  • @swm0022 said in Updating ANVEL versions with plugins:

    @ANVEL-Team

    Update: Adding SampleSensorStaticAssetParams to the SampleSensorFactory() in the sensor .cpp file, as per the SensorPlugin example included with ANVEL 3.0, allowed the sensor to be loaded in and appear in the Assets window. I’m not sure why the plugin didn’t need these asset params defined when it worked in 2.0.

    Thanks!

    Thanks for the update; we're glad you got it working! The sensor plugin was refactored for 3.0 as better example (in our opinion). Previously, user feedback indicated that it was a bit hard to use as a mostly stubbed out shell.

    Regards,
    ANVEL Support



  • We have compiled this plugin into ANVEL 2.5 and there is an issue with some of the functions in this code.

    	pSensor_ = Anvel::Sensor::GetWorldObject();
    		
    		bool ans = pSensor_->HasPhysicsObject();
    		if (ans == true) {
    			LogMessage("physics object");
    			physObj = pSensor_->GetPhysicsObject();
    			physObj->SetAffectedByGravity(false);
    		}
    		else {
    			LogMessage("no Physics object");
    		}
    

    In ANVEL 2.0 this pSensor pointer will have a physics object attached to it which other functions take the velocity of the sensor from. In 2.5 and 3.0 the pointer can still reference a position but the velocity, and probably the whole physics object are NULL. Has there been a change to these functions?
    Also, is there a resource for the functions in the ANVEL namespace. The External API is well documented but there is nothing on these in the wiki.



  • @dsb0029,

    We'll look into the issue with the null physics object. In the meantime, check out the internal API code documentation from the "Help > Open API Documentation" menu option from within ANVEL.

    Regards,
    ANVEL Support



  • @dsb0029,

    I have a few followup questions. Although there have been several little changes to how objects work from 2.0 to 3.0, nothing specifically has changed in the functions that you're using:

    Is the issue that the sensor is missing a physics object entirely, or that it reports it does have a physics object but returns a null pointer instead of a correct pointer?

    Why not derive velocity by taking the change in position of the objects over the change in time?

    Regards,
    ANVEL Support



  • Thanks for pointing me to the internal documentation. From what I can tell the sensor lacks a physics object. pSensor indicates that there is none and physObj is NULL. I assume that means the problem is elsewhere in the code. An instantaneous velocity is preferred in this program because it is used to simulate GPS receivers, which use signals to determine velocity at one time, not integration. It can be changed if that is the only way.



  • @ANVEL-Team hasSensorObject() returns false, and a null pointer is returned with getSensorObject()



  • We worked around the physObj issue by getting the physics of the parent of the sensor object. This works when the sensor is placed on a vehicle, but not when it's on the ground.

    A new issue involves the Anvel::Rendering::RendererManager DestroyLineRenderable() function.

    Anvel::Rendering::RendererManager::GetSingleton().DestroyLineRenderable(lineId_[visSv[i]]);

    The above line crashes Anvel when the simulation is run with an "unknown, unhandled exception," even when we ensure that the lineId[index] refers to a valid, present renderable ID.

    We tried working around this by creating an instance of the RendererManager class and calling the DestroyLineRenderable directly on it, but it logged a message in Anvel "Registering message that has previously been initialized", and we could not pan around in the environment window any more.



  • @dsb0029 said in Updating ANVEL versions with plugins:

    We worked around the physObj issue by getting the physics of the parent of the sensor object. This works when the sensor is placed on a vehicle, but not when it's on the ground.

    You should be able to add a asset reference to your sensor definition XML; the asset itself will have a physics object that should suit your needs in this case.

    Regards,
    ANVEL Support



  • @dsb0029 said in Updating ANVEL versions with plugins:

    A new issue involves the Anvel::Rendering::RendererManager DestroyLineRenderable() function.
    Anvel::Rendering::RendererManager::GetSingleton().DestroyLineRenderable(lineId_[visSv[i]]);
    The above line crashes Anvel when the simulation is run with an "unknown, unhandled exception," even when we ensure that the lineId[index] refers to a valid, present renderable ID.
    We tried working around this by creating an instance of the RendererManager class and calling the DestroyLineRenderable directly on it, but it logged a message in Anvel "Registering message that has previously been initialized", and we could not pan around in the environment window any more.

    Generally speaking, you should not create a new RendererManager since it's a singleton. What are you trying to do exactly? This is just a guess, but if you're trying to destroy a debug renderable with that call it might cause issues. If you send us over your code, we may be able to help debug further.

    Regards,
    ANVEL Support



  • The goal of this part of the code is to create visible rays that constantly point from a sensor to the visible GPS satellites. The sensor is on a vehicle that can move to the lines need to update which was achieved by creating them and then deleting old ones in a loop. The line posted above is near the beginning of the loop while the lines are created later using.

    lineId_[visSv[i]] = Anvel::Rendering::RendererManager::GetSingleton().CreateLineRenderable(points, .02, Anvel::Color::Green);
    Currently the delete function is turned off because of the crashes so lines accumulate. A solution may be to check that the first function has something valid to delete for the first loop but I don't know how to do this.

    Also, what is a singleton in the context of ANVEL. We could not find this in the documentation.



  • Problems resolved
    Using the parent object for physics seems to work without problems. As for our other crashes the command
    Anvel::Rendering::RendererManager::GetSingleton().DestroyLineRenderable(DLineId_[i]);
    will cause a crash with no feedback (unhandled no exceptions) if it is called on a target that is not valid. My plugin uses this command to update rendered lines in a loop with a varying number of iterations so this happened often. A working fix is to store data from the previous loop to control the delete function. I would like to know if there is a way to check that an Id is valid for a function before calling that function because that would be an easier and more stable way to fix this problem.



  • @dsb0029,

    As it looks like you discovered, a Singleton is type of class that can only allow one instance to be created for the duration of the program. Once it is created, you can access it by calling the static method GetSingleton() or GetSingletonPtr() on the specific Singleton. World::Manager::GetSingleton() is commonly used, for example.

    We suggest using Debug Renderables instead of Line renderables for this task - they allow for thinner lines than line renderables and that's how ANVEL's built-in GPS shows the satellite constellation.

    Here’s a basic summary of how we accomplish something pretty similar internally. Note that we use the debug renderable instead of the line renderable, as it allows more customization and thinner lines, plus it is structured for rapid updates. Make sure the Debug visibility checkbox is enabled to see the results:

    In the GPS Sensor header file:

    #include "Core/Renderable.h"
    

    In the GPS Sensor data members:

    IRenderableID m_debugRenderable = kInvalidIRenderableID;
    

    In the GPS Sensor implementation file:

    #include "RendererManager.h"
    

    In the constructor of the GPS sensor:

    m_debugRenderable = Rendering::RendererManager::GetSingleton().CreateDebugRenderable( params.m_assetName + "DebugRenderable", EmptyShape() );
    

    In the destructor of the GPS Sensor:

    Rendering::RendererManager::GetSingleton().DestroyDebugRenderable( m_debugRenderable );
    

    During the update portion:

    //Create a vector of Vector3s that represent start/end pairs for each ray.
    std::vector<Vector3> debugLines; 
    //Create a vector of colors that represent the color of each debug line.
    std::vector<Color> colors;
    
    for( auto& ray : rays )
    {
        //For each display ray, add an entry for the start and end
        debugLines.push_back( ray.Start);
        debugLines.push_back( ray.End );
        //For each display ray, record the color of the start and end points (usually the same color)
        //but, you can have blocked rays report as a different color than successful rays, etc)
        colors.push_back( Color.Red );
       colors.push_back( Color.Red );
    }
    
    //Update the position of the renderable to match the actual position of the sensor
    //If the ray coordinates for the debugLines are in World Space, then the renderable should be located at 0,0,0. Otherwise, it should
    //track the position of the GPS sensor’s world object.
    Rendering::RendererManager::GetSingleton().UpdateDebugRenderable( m_debugRenderable, truePosition, Quaternion::Identity() );
    //Update our renderable to use those lines.
    Rendering::RendererManager::GetSingleton().AddDebugLines( m_debugRenderable, debugLines, colors );
    

    Hopefully this helps!

    Regards,
    ANVEL Support


Log in to reply
 

Looks like your connection to ANVEL Forum was lost, please wait while we try to reconnect.