Forum Replies Created
-
Posts
-
Hi,
We compile with Windows daily and we do not have that behaviour: as expected, only the modified files are recompiled. My guess is that you have a problem with the configuration of your Visual:
– Ensure that you do build with “Build” (F7) and not “Re-Build” (Alt+Shift+F7)
– You said (in a previous past) you are using CMake 3.2. I’m using 2.8. Perhaps that is a point ?
– Try to restart the source code compilation from scratch in a new directory (including running cmake) to prevent interferences from scoria of previous misconfigurations.Clément Forest
Digital-TrainersFrom your first message:
You are compiling in Debug but you do not have Qt debug binaries for x64. You should compile in release and it should work. You can also look for those debug files.From your second message:
The compiler is asking for libgccxxxx.dll, which is somewhere surprising because you are compiling with Visual. My guess is that the debug files you found were compiled with gcc. I am not sure that you can mix easily Visual and gcc in a same project.If you do want to compile in debug, you should find the Qt debug libraries compiled with Visual, or compile it yourself, or switch back to 32 bit, as the archive in the sofa site includes the debug version.
Clément Forest
Digital-TrainersYou do not have runSofa.exe because the compilation still fails.
The first error message tells that you are using a compiler for x64 but your Qt dependency is 32 bit. Which compiler have you selected with CMake? Check that you choose the 32 compiler (or that you use a Qt for 64bit).
The other errors are a consequence of that first one.
Clément Forest
Digital-TrainersAlso, the warnings you have in the CMake are not important. They are here because the CMakeFiles were written for an older version of CMake (2.8.8). But they should not cause any problem.
As said in your error message, you can remove them by activating “Options” -> “Supress dev Warnings”
Clément Forest
Digital-TrainersHi Saleem,
Sory for the delay.
Below is what I do here to compile Sofa from scratch on Windows 32 bit. Following https://www.sofa-framework.org/oldwiki/index.php/Getting_Started#Building_on_Windows as a canvas.
1- Clone sofa sources from the Git repository.
2- Get Qt binaries from Sofa website (qt4.8.5_msvc2012_x86.7z). Place the qt4win directory in the tools directory of the sofa sources.
3- Get the dependencies (sofa-win-dependencies-21-11-2013.7z) and place the include lib and licences directories in the root of the sofa sources.
4- Launch CMake (I am using 2.8.11), create a separate directory for compiling, choose VC12 as a compiler.
5- Run configure twice. On the first one, every thing is red, on the second one, only one line is red: QT_QMAKE_EXECUTABLE.
6- Set QT_QMAKE_EXECUTABLE variable so it points to tool/qt4win/bin/qmake.exe
7- Run configure twice (the last one is done without errors), then Generate
8- Open the solution file and compile it.Do this and tell me at which step you have a difference with me.
PD. Sorry for my previous message. I thought Qt was not found but that was incorrect as it says “Q_WS_WIN – found”
Clément Forest
Digital-TrainersOK.
It looks like your cMake doesn’t find your Qt headers. Do you have them correctly installed ? Check in your cMake that the variable QT_QTCORE_INCLUDE_DIR is correctly set.
Regards,
Clément Forest
Digital-TrainersHi Saleem,
It is not clear from your message whether or not you have actually launched the compilation (sorry to ask, but you said you were not a software developer 🙂 ).
Also, have you checked the ‘SOFA_APPLICATION_RUNSOFA’ option in the cmake ? This will generate the runSofa.exe application when you compile.
I am sorry that you have problems exporting your sofa scene in Blender SOFA. If you want you can send me your examples and I’ll try to figure out what goes wrong. My mail is Clement.Forest, and the domain is digital-trainers.com.
Best regards,
Clément Forest
Digital-TrainersHi,
I have never used it, but you might have a closer look to the grasping examples in the OptiTrackNatNet plugin, and see if you can adapt them to your application. In particular the “stick” contact response might fit your needs (according to its name).
If that does not fit, I unfortunately believe that you will have to write your own component as I am not aware of other publicly available components that could be used without any coding from your side.
Regards,
Clément Forest
Digital-TrainersHi Sarrami,
The PersistentContact Plugin was an attempt to solve the problem of physical grasping when the instrument is moving. The point was to record the contacts between the torus and the instrument at a given time step and to try to maintain the torus at the same point relatively to the instrument.
As far as I remember, it has never worked satisfyingly.The GrapingManager is a controller which should be placed in your instrument graph. By reading the code (I never used it) what I can say of it is:
– It is controlled by the keyboard (or by the “active” data)
– It allows you to open or close your instrument (given that your opening articulation is placed correctly)
– It also activates some collision models when the grasping is activated. In the example scene in OptiTrackNatNet plugin, that collision model has a contact response set to “stick”.You have some examples of grasping tools:
– in the OptiTrackNatNet plugin, which use the GraspingManager controller
– in the Xitact plugin, which use a FrictionContact approach.The other examples I know of are unfortunately not publicly available. They use objects similar to the GraspingManager that do more or less the following things:
1- detect the closing of the instrument (usually a threshold for your closing angle),
2- look in the contact managers for contact between your instrument and the object you want to grab,
3- punctually deactivate the collisions between your instrument and the object
3- create a bilateral constraint between the two objects, or replace it manually at each time step.Regards,
Clément Forest
Digital-TrainersHi Hugo.
We try to code camera manipulations the same way it is done in the usual GUI. We have no mouse interaction with the scene yet (but we plane to do it).
By pre-set actions, I mean that the client can only tells the server to “do action number X”, but can not access nor modify the graph directly. This would be possible using our SFE/TCP interface, but we deactivate it for security reasons. The actions we can do are: send a force to a given object, modify a data on the fly (eg. mass, young modulus, friction coefficient), displace or hide objects, reset the scene, …
The current limitations I am aware of are:
– no texture for now (but that could be done easily),
– no mouse interaction (for now),
– topology modifications and on the fly addition of objects are not correctly handled.
– no more than one client by html page.The latency you feel is due to the network. If your server and client are in the same host or close enough, you won’t have any latency. If you use your phone, you’ll have (much) more.
Clément Forest
Digital-TrainersYes you can.
It does not need to be in the same project, but your CMakeLists.txt will need to use AddLinkerDependencies to link with that other project.
Do not forget to use the SOFA_CLASS macro in your class definition !
Regards,
Clément Forest
Digital-TrainersCollision group only allow simple management of collision behaviour. As far as I remember:
– Group 0 elements collide with everything (including other elements from group 0)
– Group i elements collide with everything except elements in the same group.To have a more subtle control, you will have to use the contact manager to deactivate the collision response for a pair of collision groups.
In your case, you will have to assign a different group to each jaw, as they behave differently. Then add a rule to deactivate the response between the upper jaw and the torus, and probably one to deactivate the response between the two jaws.
Clément Forest
Digital-TrainersThose errors are due to inconsistent DLL linkage. The most probable is that you did something wrong regarding the macros SOFA_BUILD_YOURPLUGIN and SOFA_YOURPLUGIN_API.
Check that:
– your CMakeFile defines a SOFA_BUILD_YOURPLUGIN macro
– your code uses that macro to determine the value of your SOFA_YOURPLUGIN_API macro
– your headers use that SOFA_YOURPLUGIN_API macro, and not the one from another plugin.Clément Forest
Digital-TrainersTo check if a model collides with another, you have to look into the detection output of the NarrowPhase. This is a list of pairs of collision models. You have to check for an element that contains collision models from both models. You’ll also have to check that the element is actually a collision (ie. that the distance is below the contact distance).
One possibility to move your rigid model is to create a constraint (eg. by deriving PairInteractionConstraint).
To deactivate the collision between two objects, you can change the collision group of one of your models, so it is the same than the other, or you can add a rule to the ContactManager to set the corresponding response to “null”.
Regards,
Clément Forest
Digital-TrainersDear Wong,
I have tried your scene and in my case, the torus only penetrate the tool when the grasper is closed too much (more than PI/4).
You torus is rigid, therefore, if the constraint solver can not find a solution for the whole torus, you will have some penetrations, and this is what happens in your scene when you close the jaws too much. A deformable torus might reduce your problem (but it will be slower).
To answer to your question regarding grasping, I know two ways to model it.
1- Physically. By this, I mean by relying only on the SOFA contacts resolution algorithms, like you do in your scene. In my experience, it burdens the simulation a lot (due to the high number of contacts) and is also quite unstable, particularly when the tip of your instrument is translating.
2- Non physically. In this method, when your grasper is closing, and until it opens back, you deactivate the collision with your torus and fix its position relatively to the grasper through a constraint or a controller. This method is of course much more stable than the previous one. The drawback is that you will have to write some code of your own, as I am not aware of publicly available objects that would do this for you.
Finally, I have some small remarks regarding your scene:
– your collision models are way too complex. Your jaws should be modelled as simple boxes. With such a complex model, you get a huge number of contacts which make the constraint problem harder to solve, and the simulation slower.
– similarly, you might try to decrease your alarm and contact distances.Regards,
Clément Forest
Digital-TrainersThe two directories have to be merged.
Clément Forest
Digital-TrainersHi,
If nothing changes, this is probably because your shaders are not loaded, or are not correct. Are you sure you have placed your files in a directory in the search path of Sofa ? Do you have any error message in the console ? You can look in Debug to see if everything is OK from that side.
Once you are sure that the files are loaded, I would suggest that you use an OpenGL debugger (such as API trace) to see where the problem comes from. You can also start with one of the example scenes in Sofa that already use shaders, and then modify them little by little.
Clément Forest
Digital-TrainersActually, shaders are very dependent from the software you use. As far as I know, there is no easy way to move them from one program to an other one without having to understand correctly all its inputs.
As I said in my previous answer, the complexity of the shaders is mostly caused by the number of lights in the scene. Therefore, if you export your shaders from Blender with only one light, it is possible to understand the meaning of each unfXX input and initialise them by setting their value using a OglFloatVariable, or even directly into the shader’s code.
Now, depending on what you actually want to achieve, you might have advantage to recode your own shader or to use/write a viewer with a better OpenGL support than runSofa.
Clément Forest
Digital-TrainersHi sarami,
OglFloatVariable and family set the value of one variable in the shader. The id should be the name of that variable in the shader.
Which script did you use to export your shaders ?
As far as I know, the GLSL shaders exported from blender can not be used easily as all variables are named with non meaningful names (eg. unfXXX) so you have to read the code to try to understand their meaning. If you have only one light in your scene, that can be feasible.
—
Clément Forest
Digital-Trainers
