For the Python Scripting, it is necessary to specify in the OS environment variables the path to the Python executable.
If you are using Windows and Python installed by Anaconda, then you will need to append to the Path environment variable the paths to your installation of Anaconda, like that (depends on where Anaconda is installed): C:\Anaconda3;C:\Anaconda3\Scripts;
On Windows, it might be necessary to restart your system after that. All the rest should be detected automatically during the launch of SAMSON.
Also, to be able to use Python Scripting in SAMSON you will need the next Python packages installed: jupyter, qtconsole, numpy. These packages should be installed automatically if you installed Python using the Anaconda installer. You can verify your installation (https://docs.anaconda.com/anaconda/install/verify-install) and check whether the necessary packages were installed. If they are not installed (which is the case for installation using the Miniconda installer), you can install them via:
conda install jupyter qtconsole numpy
From here you can solve your issue related to the dll file, what you need to do is check missing Burutter.dll and copy the setting and save the dll file setting in your PC then you are able to replying of dll files.
First of all I have to thank you for the quick response. Funnily, I thought of using const_cast on the matrix pointer beforehand but considered it as too "hacky".
There should be several possibilites how one could introduce this into the API:
Each camera gets a state that determines whether it implements a symmetric or asymmetric projection including two methods that query and set the state. Then, an additonal method (possibly like SetPlanesAsymmetric(float left, float right, float top, float bottom)) could be used to transfer the wanted plane values to SAMSON. This approach would leave the old API intact, if the symmetric projection is the standard state.
Derive a class like SBDAsymmetricDocumentCamera from the currently available SBDDocumentCamera, overriding all methods concerning the projection matrix. This is probably the least favourable alternative, although the old API would still be valid.
The camera gets two additional methods SetValuesSymmetric(float aspect, float fovy, float zNear, float zFar) and SetValuesAsymmetric(float left, float right, float top, float bottom, float zNear, float zFar). Then, the GetProjectionMatrix() and GetProjectionMatrixTranspose() methods would have to be changed to take an additional boolean input parameter determining which kind of matrix is wanted. This would break the old API and I am not sure how this would propagate to the convenience display methods like SAMSON::displayCylinders(...).
Unfortunately I do not know which of these possibilities (and I probably missed some additional ones) would fit best into your way of writing SAMSON.
For every node, you create you need to invoke create function, and then if you want it to appear in the DataGraph this node needs to be added to a parent node:
auto camcopy = SAMSON::getActiveCamera()->clone(); // clone the camera
camcopy->create(); // create the node
document->addChild(camcopy); // add the created camera into the active document
... some modifications of the camcopy
SAMSON::getActiveDocument()->setActiveCamera(camcopy); // set the active camera
Not instead, in addition: having, at the installation of the App, a list of pre-saved settings, with still the possibility to save and load your own settings.
-- for example, with the Crystal Creator App, having the 'diamond settings', the 'SiGe settings', or for ARPS, some classical configurations of Ef and Er : the '10x speed up settings', '5x speed up settings' ... --