PureBasic Forum

Hi,

After some time of developing my CT 3D VIEWER software.
http://www.marc-systems.be/new_2010/Viewer_3d_Examples.htm
I invested my last money in a new computer and new screen.
I was thinking (i 'm not a PC guru) with a good gaming video card, that ogre will be faster to make zoom and rotations.
But I was wrong, can someone tell me why the speed is almost the same as my old slower PC ?

OS: WIN 8.1 x64
PB 5.41 LTS Final - x64
LAPTOP: MSI Leopard Pro
CPU: INTEL i7
GRAPHIC CARD: NVIDIA GTX950M
RESOLUTION: HD (1920x1080)

What do I need to speed up this zoom and rotations ?

thanks,
Marc

@marc_256
If you can give some example code of your slowdowns then someone might be able to give you some ideas to help speed up your code.


To a point this is true. A better card will give you better performance in areas, but the main boost comes from being able to access the newer versions of rendering API.
The problem you're finding is that PB/Ogre is still using the old DirectX and OpenGL fixed rendering pipelines.


If you're not getting artifacts or tearing then Vsync isn't needed. Which is why most games give you the option to turn Vsync on or off.

Quick question how are you rendering those images? It almost looks like planes and if so how many planes are generated and what image resolution are you using?

If you're using planes then you could try static geometries if you haven't already.
You could also look into 3D textures with a shader (similar to how minecraft worlds are generated).

- No sprites, images but cloud mesh.
- I did this, and yes it works a little faster.



What I do is,
1) I convert the CT scanner 2D images to gray scale images (256 grays)
2) I store them in the data memory (+-500 images of 512x512 bits)
3) then I make a transparent 3D cloud mesh of it.
so the user can change the transparency of the pixels to see inside the body or organs.
4) the software rebuilds a 3D cloud mesh (even with i7 x64, takes some minutes to (re)build the mesh).
5) build/make a 3D mesh for OGRE
6) so we can zoom in and rotate the camera/mesh

I made some tests:
1) stable camera and move and rotate the mesh
2) stable mesh and move and rotate the camera

looks there is no difference for now ...

Maybe I 'm a dreamer, if i calculate the mesh volume ...
500 (images) x 512 (pixels in Xaxis) x 512 (pixels in Yaxis) = 131 072 000 (3D pixels)


thanks for helping me here,
marc

@marc_256
Instancing and geometry shaders would be a major help with what you're trying to do. Problem is they are not available in the current PB/Ogre package.

Do you notice any speed improvements if you don't use alpha? If Ogre is doing alpha sorting then I could see that being a major bottleneck for the rendering pipeline.

The question here is also: how? You could triangulate the point cloud, e.g. with (dual) marching cubes. That way the amount of fragments processed is far less. Also you could try uploading the layers themselves and just display planes with each layer as texture.

hello,

For my 2D to 3D image converter, (cancer research)
I convert 2D bmp images to a 3D pixels cloud.
To do that I use a self made algorithm, written in PB.
It work very well but it need about 3...4 minutes to do the conversion. (see below)
So, will there be a significant difference in time when I rewrite my program in ASM ?
thanks,

marco

For my latest experiments in huge clouds of 3d scan (topography), I've tested some tools to convert to meshes. Best ones are Autodesk Recap and CloudCompare(CC). They're pretty good for this task, having needed work force for this kind of job, pretty difficult for only one person !

Anyway, to answer about ASM optimisation, the best optimisation is always in the algorithm, the second one in reducing memory access (few variables leading to CPU using only internal registers), third in reducing global number of sequential operations (allowing parallelism, with tricks like unlooping-thinking in a way of reducing little imbricated loops-), fourth in reducing slow instructions, and so on.
All could be done in any language, ASM being useful at the core of the algorithm. Good asm coders could, by working intensively on a specific problem, find tricks going further, but it takes time and a lot of concentration.

Now, consider also that CPUs are evolving, and some well knowns slow instructions in the past are now fast, so it's better to concentrate on algorithm and the points I've given before thinking to optimisation, especially in ASM, which is harder to debug.

Hi Marc

The Film Industry use the GPU, either OpenCL or nVidia Cuda. I think a bit of research could find you a good, much faster solution.

djes,

You are right, I need to check all calculate time loops in the algorithm (who is huge) one by one,
to convert the (512x512 px) x >500 images.
It is there that I want to use ASM to win some time ...

IdeasVacuum,

It is not specially the visualisation, but the algorithm calculations,
for contrast, and transparency image after image.

thanks,
marc

IdeasVacuum hinted that you may be able to use the GPU to assist you...

Quote from Superuser.com:

PB's ogre implementation is able to handle a lot of polygons with their own mapping and allows use of realtime shaders to alter their rendering (faster than doing it in software). G-Rom and Comtois could help you for this kind of problem. To have greatest speed everything should be in graphic memory, and you should avoid swapping between main memory and graphic memory, so you have to think in terms of what is needed by the graphic card. Shaders are like billions of processors working in parallel, sure you can do miracles with all this power, if you're able to convert your algorithms to a pixel based engine.