Performance issues

[tiofredo]

It's me again.
Here's the situation :
I'm on a Core 2Duo E7500@2,93GHz, 4Gb RAM, Quadro400, Windows 7 64, and I'm using JOGLViewer.
I'm creating a scene with 4 cameras and 10000 boxes stored on 2 levels loaded from a cached geometry, with a color and no texture (for now, hence my recent post). (also a few texturedQuadrilaterals, but that's less than 10)
If I create the cameras, then the boxes, it takes minutes to finish the creation of all boxes.
If I create the boxes, then the cameras, creation is within seconds, but it takes 20secs for the first camera to display something, and more for the next ones.
After that, I try to move two boxes from the stack, and that's very very slow.
And I should do that with around 50 at the same time.
Any ideas, any leads to improve the speed/performance ?
Thanks for your help.

[Andre]

Have you tried starting the program with more memory?

If you are using eclipse:

right click at your "main-class" -> "Run As" -> "Run Configuration" [left click] -> then opens a new window and you go to the tab "(x)=Arguments" -> then type at the field "VM arguments" -> -Xms256m -Xmx1024m

This should increase the memory you are using.

If you have a lot of objects in the scene, the renderer needs a lot of time. And it is clear, that if you first add the cameras, they are rendered first and if you first add the objects, the objects are rendered first. That's because the renderer moves along the scenegraph and renders first what comes first ;)

[tiofredo]

Hi.
I've setup the Run Configuration already, doesn't change much, I'm using all memory left when the cameras are created and rendering begins.
Could anyone make a simple test on his machine ?
With jogl viewer, create 10000 boxes (via Primitives) and 4 cameras, then move 2 boxes.
Does that take like 10 seconds for each camera to start display, and seconds to refresh ?
That would be really helpful.
I keep looking but I can't find a way to speed up rendering...
Thanks

[gunn]

General tip for using the JOGL renderer: prepare your scene graph as completely as possible before you attach it to the viewer for rendering. This has to do with the way that the backend creates a proxy scene graph: it works best if it gets it all at once and not it little pieces.

Second: where the camera is in the scene graph doesn't matter. The value set by viewer.setCameraPath() picks out the camera to use, regardless of where it is in the scene.

I'm a bit baffled by the performance problems you mention. One place to look would be to create just one box and then attach it to many different scene graph components, using the appearance to control how what color it appears. Or, if you have several different color schemes, just create as many boxes as color schemes and attach those (few) boxes to the many scene graph components. Even if this approach doesn't meet your needs, you could find out if it speeds up things significantly. It would then help debugging efforts.

[tiofredo]

Thanks for the answers guys!
Here's what my sg looks like :

rootNode -> geometryNode-> n Boxes sgc with the same geometry object attached
-> cameraNode -> 4 camera sgc with a Camera and a light on each

The appearance is applied on each Box sgc.

I've tried to make 4 geometryNodes, each with a different color appearance, and randomly add each box sgc to one of those, without any appearance set on my box sgc.
And I create the whole geometry part before the cameras.
Same result.

gunn, maybe I didn't get what you meant.
I have 7500 to 15000 boxes to display in my scene, some added during process, some removed, some moved.
In my mind, for each box I need a sgc plus a geometry attached.
Each box can have one on 6 different geometries once and for all, loaded the first time from an .obj file and cached in a hashmap for the next boxes.
They are supposed to have textures that I'd cache the same way, say 50 different ones. For now, I'm using simple colors via appearance.
Boxes have some attributes (owner, manufacturer, etc) that I need to use to highlight those sharing the same at some point, this by changing texture/color.
Say I wanna have highlighted every ACME box, I'd apply a red color over every ACME box.
You told me in another thread :

For your information: assigning an appearance temporarily has no effect. You need to have the appearance attached to the node when it is rendered for it to have an effect.

I can attach only one appearance to a node, therefore I need to have a node for each appearance and put my boxes sgc as child of each node it matches attributes.
Wouldn't that be a mess for 10k boxes with 50 appearances, where each box could have like 10 parents ?
And what happens if I wanna "reset" the appearance of a box to the one it had when I created it ?

I just tried to create the 10k boxes with no appearance at all, it's still very slow.

Could anyone just give a try at such a setup (10k boxes, 4 cameras, a few different colors, maybe some movement) on his machine ?
That would give me some precious hints about the situation.

[gunn]

Any chance to post the code for this problem, as a single Java class? That would ensure that the results could be compared to what you're seeing.

I've played around a bit anyway. I create a scene with 10000 boxes and 10000 sgc's. It takes about 9 seconds to start up and draw an image. I assume that's mostly creating the jogl proxy. Then, I get around 6 fps when rotate the scene, most of the boxes are visible.

I'm running on a MacBook Pro with 2 GB, 2.4 GHz Intel Core 2 Duo, Nvidia GeForce 8600M GT. It's about 3 years old.

Here's the code. To run it you'll need to download the "discretegroup" project from the svn repository
http://fs.math.tu-berlin.de:8000/svn/jtem. I'm not able to check right now if there's a working guest account.
Maybe that's not so important. What might be important for you is to notice that i've turned off edge and vertex drawing:

Code: Select all

		ap.setAttribute(CommonAttributes.EDGE_DRAW, false);
		ap.setAttribute(CommonAttributes.VERTEX_DRAW, false);

That might be causing the slow-down in your code.

Code: Select all

package de.jtem.discretegroup.tutorial;

import de.jreality.geometry.Primitives;
import de.jreality.math.MatrixBuilder;
import de.jreality.plugin.JRViewer;
import de.jreality.plugin.basic.Scene;
import de.jreality.scene.Appearance;
import de.jreality.scene.SceneGraphComponent;
import de.jreality.shader.CommonAttributes;
import de.jreality.util.CameraUtility;
import de.jreality.util.SceneGraphUtility;
import de.jtem.discretegroup.core.DiscreteGroup;
import de.jtem.discretegroup.core.DiscreteGroupSceneGraphRepresentation;
import de.jtem.discretegroup.core.DiscreteGroupSimpleConstraint;
import de.jtem.discretegroup.core.Platycosm;

public class CubeExample {

	public static void main(String[] args) {
		// construct a 3d discrete group
		DiscreteGroup dg = Platycosm.instanceOfGroup("c1");
		dg.setConstraint(new DiscreteGroupSimpleConstraint(10000));
		dg.update();
		// create a scene graph representation of the group
		DiscreteGroupSceneGraphRepresentation dgsgr = new DiscreteGroupSceneGraphRepresentation(dg);
		// construct a scene graph component to represent one fundamental domain
		SceneGraphComponent fundDomSGC = SceneGraphUtility.createFullSceneGraphComponent("fundDomSGC");
		Appearance ap = fundDomSGC.getAppearance();
		ap.setAttribute(CommonAttributes.EDGE_DRAW, false);
		ap.setAttribute(CommonAttributes.VERTEX_DRAW, false);
		fundDomSGC.setGeometry(Primitives.box(.5,.6,.4, true));
		MatrixBuilder.euclidean().translate(.1,.2,.3).assignTo(fundDomSGC);
		// attach it to the scene graph representation
		dgsgr.setWorldNode(fundDomSGC);
		// this will generate a jReality scene graph
		dgsgr.update();
		JRViewer.display(dgsgr.getRepresentationRoot(), false);
		JRViewer jrv = JRViewer.getLastJRViewer();
		Scene scene = jrv.getPlugin(Scene.class);
		MatrixBuilder.euclidean().translate(0,0,60).assignTo(scene.getAvatarComponent());
	}

}

And here's an image:

[gunn]

Update: I just had a chance to run the code from my previous post on a "high-end" desktop machine (with for example Nvidia Quadro 5600 GPU) and collected the following statistics: start-up in 2 seconds, 60 fps. About exactly 10 times faster than the results on my laptop.

[tiofredo]

Hi gunn.
Thanks for the test.
I used the ap settings, the cameras load in 5, 8, 11, 15 seconds, and the movements are much more fluid.
I couldn't test your sample as I don't have a login/password.

About my code, here's the thing:
I'm working in a component based architecture which layers code in several objects.
I'm gonna try and give you something extracted from that.

[tiofredo]

I've managed to extract the code from the layers, performances are the same.
I've also stripped some objects taht are created just like 20 times in the whole scene, some texturedquadrilaterals.
Note that I've added some textures but I can't get them right so far.
Thanks for the help!

[gunn]

I took a look at your code (it pretty much froze up my laptop so I didn't do much testing).

One suggestion: Due to fixed point precision in OpenGL rendering pipeline, you should be careful when setting the near and far clipping planes. The following code will probably lead to rendering artifacts:

Code: Select all

camera.setFar(500000);

It appears you only need something on the order of 10000-20000 for this far clipping plane.

And, it also helps at the same time to set the near clipping plane to some larger value, say 1.0, since the crucial number is the ratio of the two values. I'm not sure what the default for the near clipping plane is, but the larger you can set it, the better the results will be (unless of course you start clipping out stuff you don't want to).

Of course, you may have good reasons to be setting the far plane so high, in that case, just ignore this suggestion.

[tiofredo]

Hey gunn!
Thanks for the test.
I've set far to 500000 because I receive data in meters, and when I tried loading an .obj file with a model supposed to be designed in centimeters, I had to scale it to make it look good, etc.
It lead me to multiply every data I received by a 100 factor (meters -> centimeters), same with the camera far...
I just made some tests without the 100 factor, and I scaled down the object instead of scaling it up, changed far and near, etc.
It works, speed is basically the same, but it's bearable since I've turned off vertex and edge drawing.
Setting near at 1.0 is fine, I'll see if I can set it at a bigger value during load tests.
Far is set at 5000, which I might lower to 4000, since I'm displaying a 3000 meters long scene.
Apart from that, does my code looks correct to you ?
Thanks for the help.

[gunn]

Here's some impressions and suggestions for your code:

Why are you building your viewers from scratch? You get lots of nice features if you use the JRViewer class (de.jreality.plugin.JRViewer). Almost all the tutorials use this class, if you want to see how to use it. Specific examples also addressed in de.jreality.tutorial.viewer package.

Don't put the world (what you want to view) as a child of the camera. It's virtually impossible to then have the camera do its job. If you move the camera, the world moves rigidly with it, so the image rendered by the camera doesn't change. Add the world node to the root node of the scene graph, and the camera node as another child of the root node. This point would be taken care of automatically if you used JRViewer. The viewer knows where the find the camera via setCameraPath(), so it can be put anywhere in the scene graph.

Small optimization point: add the appearance attributes as high in the graph as you can, to save repeated evaluation. That means, the lines

Code: Select all

		appearance.setAttribute(CommonAttributes.EDGE_DRAW, false);
		appearance.setAttribute(CommonAttributes.VERTEX_DRAW, false);

belong at the root appearance, rather than at the leaf nodes. If you want to override, you can do that in the leaf.

As noted in another thread, to get the textures to work, you'll need to figure out texture coordinates for your box and set them as done in http://www3.math.tu-berlin.de/jreality/ ... _a_factory.

I would also probably look into whether you need to add a separate appearance for every box. You are caching some reused items, such as the image data; why not cache the whole appearance? Then, all you have to do is change the attributes of that one appearance and all the boxes using that appearance will change their appearance. As it is, if you change the image it has no effect since the original image is hard-coded into multiple appearances.

[tiofredo]

Here's some impressions and suggestions for your code:

Why are you building your viewers from scratch? You get lots of nice features if you use the JRViewer class (de.jreality.plugin.JRViewer). Almost all the tutorials use this class, if you want to see how to use it. Specific examples also addressed in de.jreality.tutorial.viewer package.

Hi.
I'm using this because I wanted to control everything and it seemed the right way to use JOGL, considering we have a 3D video card and I thought JOGL would be efficient.
But if I can have a snippet replacing the addComponentWithCamera method, why not ?

Don't put the world (what you want to view) as a child of the camera. It's virtually impossible to then have the camera do its job. If you move the camera, the world moves rigidly with it, so the image rendered by the camera doesn't change. Add the world node to the root node of the scene graph, and the camera node as another child of the root node. This point would be taken care of automatically if you used JRViewer. The viewer knows where the find the camera via setCameraPath(), so it can be put anywhere in the scene graph.

I guess the world is what I call geometryNode ?
I've got geometryNode and cameraNode as children of the rootNode, first one having components with geometry as children, second one having component with camera as children.

Small optimization point: add the appearance attributes as high in the graph as you can, to save repeated evaluation. That means, the lines

Code: Select all

		appearance.setAttribute(CommonAttributes.EDGE_DRAW, false);
		appearance.setAttribute(CommonAttributes.VERTEX_DRAW, false);

belong at the root appearance, rather than at the leaf nodes. If you want to override, you can do that in the leaf.

Done, thanks!

As noted in another thread, to get the textures to work, you'll need to figure out texture coordinates for your box and set them as done in http://www3.math.tu-berlin.de/jreality/ ... _a_factory.

I would also probably look into whether you need to add a separate appearance for every box. You are caching some reused items, such as the image data; why not cache the whole appearance? Then, all you have to do is change the attributes of that one appearance and all the boxes using that appearance will change their appearance. As it is, if you change the image it has no effect since the original image is hard-coded into multiple appearances.

I'll dig into unwrapping very soon.

For now, we are in a simulation mode, where colors are fine, but soon we'll need colored textures instead of plain colors.
Caching appearances might be a good thing indeed.
I'll have to figure out lots of thing though.
A box can have like 10 different geometries (small, big, large, round, etc. which won't change duiring the scene display), I can cache those.
About the textures, each box has a "type" property that won't change (wooden, plastic, metal, etc.), but I have a color that can be changed.
So the textures are like smallwoodenred.png (cacheable too)
All this means that when I need to change the color of all the boxes from ACME, they won't use the same red texture because they have a different geometry and type.
Obviously that would be easier if I stuck with colors and forget textures...
Or I'd have to create hundreds of nodes grouping boxes according to 10 more criterias, each having many different values...
I guess that would be a mess...

[gunn]

It looked to me like you were adding the geometry as a child of the camera node; I see now I was wrong about that.

Have you looked into the jReality developer's tutorial? http://www3.math.tu-berlin.de/jreality/ ... r_Tutorial If not, I strongly recommend doing so. Almost all the examples use JRViewer, and the JOGL viewer too. You can just go through and play with the webstarts to see if there seem to be any examples relevant for your task. You can see there how to use JRViewer instead of rolling your own viewer.

With textures and appearances: the default texture mode multiplies the polygon shader diffuse color ("polygonShader.diffuseColor") by the texture color, channel by channel. So with as single B&W texture you can easily create a host of different colored textures. That should reduce the number of appearances you need, or at least the number of different textures.

[Andre]

Here's some impressions and suggestions for your code:

Why are you building your viewers from scratch? You get lots of nice features if you use the JRViewer class (de.jreality.plugin.JRViewer). Almost all the tutorials use this class, if you want to see how to use it. Specific examples also addressed in de.jreality.tutorial.viewer package.

Hi.
I'm using this because I wanted to control everything and it seemed the right way to use JOGL, considering we have a 3D video card and I thought JOGL would be efficient.
But if I can have a snippet replacing the addComponentWithCamera method, why not ?

I already wrote you that the viewer and the rendering backend are two different things.

You use jogl as a rendering- backend and you are building the viewer from scratch.
You should use jogl as a rendering-backend further, but you should build your viewer with the JRViewer.class.

JOGL-Viewer just descibes that the viewer uses JOGL as rendering-backend.
Software-viewer describes, that the viewer uses software as rendering-backend.
JRViewer describes the kind of viewer you are using. Some more kinds of jReality viewers are Viewer from Scratch, ViewerApp jRViewer, JRViewerVR etc. All the Viewer can use JOGL or Software as a Rendering-backend.

Please follow our suggestions and read and apply the manuals which we recommend you. otherwise we can't help you.