Maurice and Samba sent me some new data,
In this scene the BHA is oscillating a lot more than in the previous one, also the Borehole has a stairs-like shape.
As a result there are some big visual bugs :
- the cylinders of the borehole seem to collide with each other.
- The trajectory interpolation doesn’t work at some points.
- the BHA deformation doesn’t work properly.
Looks like I’ll have a lot of debugging to do in the next few days !
This week we talked about the wrapper/interfaces the library should have.
C++ :
pros : this is the native language of the API, so it’s the most flexible interface.
cons: the client application has to be linked to the library with exactly the same compiler (Visual Studio 2008) or it won’t work, it also requires a lot of headers.
C:
pros: C can be loaded from almost any other language, as Schlumberger wants to be able to load the API from fortran it seems to be a good choice. Also the DLL is not compiler dependant.
Finally, there is only one header to distribute and a DLL.
cons:
We can only use structures and functions so we won’t have access to all the features of the API.
All the functions have to be loaded from the dll using “GetProcAddress”
Can’t handle exceptions.
.NET:
pros: object orientated, we have access to all the API features. It’s compatible with any other .NET language (most of Schlumberger softwares are written in .NET).
cons: it requires the .NET framework at runtime.
Matlab: This is using the C interface.
So I decided to implement a C interface and Matlab wrapper for the moment. Later I’ll try to also write a .NET interface.
Apparently the university virtual reality room is only for research, students don’t have access to it.
I’m going to use VRJuggler for the VR part, and I know you can create some dummy devices to emulate the wand and head tracking, so I’ll do that for the beginning. And later I’ll ask the new visualization intern at Schlumberger to do some tests for me in the iCenter.
The demonstration crashed on my supervisor’s machine, and it still doesn’t work on Maurice’s computer, but it works on some other Schlumber scientists’ machines so I’m not too sure where the problem comes from.
It also works fine on the labs machines and on my housemates’ computers.
This week I’ve been trying to contact different people from the School of Science and Engineering in order to see if they could let me use Matlab on one of their machine, but without any success : nobody replied to me.
I’ve also tried to contact Jean Luc Lugrin, to have more details about how it works to book the virtual reality room, and have more details about the equipment available. He didn’t reply neither yet.
So this morning I went in person to the school of science, somebody told me to go to the ICT helpdesk in the Stephenson Building, and there they told me there was Matlab in all their labs, and that I could use any of them.
I went to one of the lab, to check if I could log in, and everything is fine.
I’ve started to do some research about how to call C++ DLLs from Matlab, here are a few links :
http://www.mathworks.com/support/tech-notes/1600/1605.html#C_warning
http://osiris.tuwien.ac.at/~wgarn/programming/DLLs_for_Matlab.html
http://www.mathworks.com/support/tech-notes/1600/1605.html
I need to look into it in more details, but I have the impression I just need to write an interface which will call my C++ code. As my library tries to avoid using objects on the client side, it shouldn’t be too hard to do.
Next step is to work on the VR part if I can get in touch with Jean Luc, otherwise I’ll start the matlab interface.
It took me a lot of time to track a fex bugs and fix them :
- The library is now statically linked to the CRT libraries. ( some explanations about the different libraries can be found here)
The main problem I had was coming from std::string : if I exported it in the Library, it wouldn’t link correctly in the application.
So now there is not any public string attribute left in the classes. And for some reason I can only pass Strings from the main application to the library by reference (if I pass them by copy I get a memory heap corruption).
For example in the TextOutput class I had forgotten a ‘&’ and it was crashing each time I was calling this function. I have no idea why this was happening, and it has been really hard to isolate and fix this bug, because the TextOutput class is used by all the classes of the API so every small change made to this class requires to recompile the whole API ( > 10 minutes…)
- The demonstration applications were crashing on some machine when the user was closing them :
This bug has been particularly hard to track too, because it was not happening on my machine.
I’ve looked on internet, and some people were suggesting to generate the linker map file and to find to which instruction the address was corresponding. Unfortunately I didn’t manage to find the correct address, so instead I reduced the number of lines called in a test program until I was able to isolate the bug.
And apparently the problem was coming from the fact that I was deleting the OpenGL buffers at the end of the execution.
I’ve checked the OpenGL documentation : http://www.opengl.org/sdk/docs/man/xhtml/glDeleteBuffers.xml
and they don’t say anywhere that I’m not supposed to free the buffers at the end. On the other hand since I don’t remove the buffers anymore, I don’t have any memory leak, and no more error, but I’ll still have to check later why it’s doing that.
- I can now have several OpenGL windows at the same time, having different contexts but sharing the same resources.
When I was thinking that I had a problem with my depth buffer on the child window, actually it was a problem of initialization of the projection matrix. (the near and far planes were not initialized…), which is why the depth buffer was not working as expected and also the shaders didn’t seem to work.
I have recorded a new video demonstrating the two windows system, I’ll post it later.
I’ve finished to implement the new way of loading a BHA (cf previous posts), and the animation is working too.
The BHA is one single mesh made of cylinders of different diameters.
The positionning and deformation are done in a shader.
All the information is passed using a 2D float texture : each row represents a different time.
On one row there is for each node the angle(1 float), the position (3 floats) and the colour value(1 float).
The time is passed as a uniform variable.
I’ve created a “Time” resource in the CoreManager, everything in the API which is using time is using this variable.
This means by controlling this single variable, it’s possible to control any animation which occurs in the API.
Here is the interface of the TimeController :
float operator()(); //return time
void play();
void playBackwards();
void stop();
void increaseSpeed();
void decreaseSpeed();
void nextFrame();
void previousFrame();
void setSpeed(const float);
void setDeltaFrame(const float);
void setDeltaSpeed(const float);
void setTimeLimits(float min,float max);
void disableTimeLimits();
And I’ve created a Wx toolbox, which basically just calls the above methods :
This week I showd my supervisor the demonstration applications that I showd at Schlumberger.
We talked about the best way to create chilren windows which share the same OpenGL resources that the main window.
So to sum up :
There is :
- a device context per window
- a rendering context.
There are two ways to share resources between two windows :
1) at each window update we link/unlink the device context of the window which needs to be refreshed to the rendering context.
=> According to my supervisor this technique is slowing down the application a lot.
2) each window has its own rendering context, and we tell the rendering contexts to share their resources.
=> That’s what I need to do.
In a first time, I’ll try to create several windows in a standalone application, once it will be working properly I’ll try to integrate it in Wx.
This week, I also need to find who to contact in order to have access to Matlab, and to the VR Cave.
I’m also going to finish the implementation of the new BHA modelling and animation.
Last friday I went to Schlumberger to give another presentation.
This one was mainly centered on the 4D surface and the BHA positionning inside the borehole.
There is no big change to do to it, they are happy with the way it works at the moment.
There has been one suggestions : they would like to be able to split the surface in several sections along the depth axis, so that in the case of a trajectory rotating on itself they don’t lose any information.
We discussed for a while to decide wether or not we should use procedural shapes instead of obj models.
problems with obj files :
- too many vertices on one circle of the cylinder shape, and there might not be enough on the length.
- the stabilizer (blue shape on the following drawing), is made out of two small cylinders with a bigger one in between, the length and diameter of each of this cylinder may vary. This makes it impossible to scale using only x,y and z scaling factors.
On the other hand, using procedural shapes fix these problems, but we will lose the small details on the components. (it’s a purely aesthetic problem).
Instead of having a list of components to map onto a skeleton, we directly have a list of bones which are defined by a length and an outside diameter. Each bone is identified by a name.
In the previous drawing, the nodes represent the articulation between two bones. There are three reasons for passing from one bone to another :
- a change of diameter (nodes 2 and 3)
- a change of component (nodes 1,4 and 6)
- a deformation of the component (node 5)
This will be described in a CSV file, and from now on it will be called a “BHA file”.
Example of CSV file:
ELEMENT,LEN,OD
n,m,m
1,0.09700000,0.21460000
2,0.03600000,0.21460000
The second file will contain the offset information for each component at each time.
It will be called “BHA position File” or “deformation file”
“TVD” “NS” and “EW” now represent an absolute position (instead of an offset)
Note: the user can provide a position file without a time column to show the BHA in one position only.
The last file is called a “BHA colour file”, it looks like a calliper file: 1 (optional) column for the time, 1 column “Node”, followed by a number of columns of colour data.
For example if there are 20 colour data columns, it means one column represents 18 degrees.
They confirmed that they were not interested in having a big GUI. They’re really only interested in the API side. So I’m going to remove it from the milestones and keep it for the very end.
I’ve run the demo applications on several employees’ laptops (new and old laptops), and it worked fine on all of them : no slow downs, no big memory or CPU usage.
Which means, I can keep the shader solution for the deformation.
You can now have several opengl windows running at the same time. They are all sharing the same opengl context which means they’re sharing the vertex and index buffers.
with several windows you can :
- visualize different data on the same models. For example one window will map the ratio current angle / max angle onto the BHA, and the second window will map the current offset.
- monitor several things at the same time. For example you can follow the drilling bit in one window, and display a graph in the child window.
However I still have two bugs :
- There is no depth test in the children windows.
- The children windows don’t have access to the shaders.
For the moment it’s not possible to link the same camera to two windows at the same time.For example, you move the camera in one of the window and the camera is automatically moved in the second one as well.
Following the last BHA Mapping post :
- I’ve implemented a shader version of the BHA Mapping :
The shader is using two uniforms:
- the size of the texture used to pass the parameters
- a texture sampler
All the data is passed through the texture.
the first 6 values represent the x,y and z scaling factors, the number of articulations in the component skeleton, the maximum angle of deformation, and the maximum vector offset.
Then for each articulation we have :
- the z distance from the front of the component
- the angle of deformation
- an offset vector.
Note: the maximum angle and maximum offset are here to compute the colour value of the vertex, they may vary depending on what we want to represent: we might want to visualize the value of the current deformation angle over the maximum angle of this component, or it could be over the maximum angle of the entire BHA.
Then the shader is :
- scaling the model
- moving the vertices according to the offset vector
- rotating the vertices according to the deformation angle.
- transforming and shading each vertex.
It’s working fine:
- almost no pre processing required
- no duplication of data
- the user can change the information mapped onto the BHA during the execution.
- the shader is quite small, so it’s not too expensive to run. For the moment I’m not doing the light calculation, so I’m skipping the normal transformation.
All the parameters are passed using one row of the texture, the obvious way of implementing animation is to use one row=one time.
This will be the next step.
For the moment I don’t have the models for the BHA components. The only one I have is the drilling bit. So I’m using cylinders for the other components.
The good thing about using procedural shapes is that I have the exact tesselation I need: not too many vertices on one circle, and more vertices on the length so that I can deform the cylinder accurately.
I’ve made a test and used the drilling bit to represent all the models: it was really slow, even though I was drawing only 1000 ft of bha in a 15000 ft well.
I need to implement a visibility test: all the components are never all visible at the same time. http://www.lighthouse3d.com/opengl/viewfrustum/
I need to check with Maurice if we could use procedural shapes instead of the obj files.
