3d graphics rendering very slow

hello,

I have a project in which I want to display around 50,000 cubes I make with patches. once I do that, the program becomes extremely slow. especially when I move a camera to see different sides of the object. the program works at the same speed when on my laptop and my PC. But on the computer I have Nvidia graphic accelerator (gvn730 2G memory). I thought matlab automatically uses the gpu to display patches and other graphic objects. but I guess it doesn't. What can I do? its really slow.

thanks

Answer 1

[Mike Garrity]

It's hard to know without more details. Graphics performance is fairly complicated because it involves balancing several different factors. I've been writing a series of posts on the MATLAB Graphics blog on the subject. Perhaps one of them will be helpful. And be sure to check out the comments on those posts because there are lot of good ideas there.

My first guess from your description would be that you're probably seeing the case illustrated by the cylinder example in this post. That's just a guess though, and probably isn't worth much.

[Ehud]

Hi Mike thanks for the quick response. I read the post and there are good advices about idealizing the code to reduce the amount of actions/calculations from the cpu. I attached a screen shot of what I'm doing: the whole red transparent box is a 40X40X40 structure made from a 1-unit cubes (which are made from 6 patches- the edges are deleted). the green objects are balls I create from the same kind of cubes. in order to get this, I create the right number of unit-cubes at the origin and than transfer them to their right position. It is all done in a matrix way (not a loop), means that I create a huge matrix with all the vertices and faces I need and place them so they construct unit-cubes around all the coordinates i want. since the matrices I use are huge, I understand that it takes a lot of time to render the picture every time I rotate the axes (using 'cameraPosition'). this is why I wanted to transfer the calculation from the cpu to the gpu. any idea how to do that?

[Mike Garrity]

So each face is a separate patch object? If so, I think that you're probably going to want to combine them into fewer objects.

The reason is that the graphics card is very fast if you can keep its pipeline full of geometry, but when we have lots of tiny patch objects, we have to keep stopping and making sure the rendering attributes are correct. There's an optimization called "state attribute sorting" which helps here, but it's not perfect. You often end up with what are called "bubbles in the rendering pipeline".

In that post I referred you to, this code fragment is showing how to combine multiple faces into a single patch object:

clf
drawnow
tic
verts = [];
faces = [];
for ix=0:99
  a1 =  ix   *2*pi/100;
  a2 = (ix+1)*2*pi/100;
  v = [cos(a1), sin(a1), -1; ...
       cos(a2), sin(a2), -1; ...
       cos(a2), sin(a2),  1; ...
       cos(a1), sin(a1),  1];
  f = 1:4;
  verts = [verts; v];
  faces = [faces; f + 4*ix];
end
patch('Vertices',verts,'Faces',faces,'FaceColor','yellow')
view(3)
drawnow
toc

However, the transparency in your picture is making me a bit nervous here. As I described in this other post, using transparency in a 3D scene involves an extra depth sort operation which isn't required when drawing opaque objects. If you remove the transparency, does the performance improve a lot? It's possible that the number of patches objects is a red herring, and we should be focused on the transparency part. If that's the case, we might be able to do something tricky like putting the transparent part in a separate axes with SortMethod set to childorder.

Also, the transparency depth sort uses various OpenGL features that the we don't use in other parts of the renderer, so the output of "opengl info" would probably be useful to make sure you're not on a card that's missing a feature that it wants to use.