Slow framerate when objects overlap?

[AW999]

The framerate for one of my programs slowed to a fraction of its earlier value when I (mistakenly) placed all the terrain 'chunks' at the same location - which wouldn't be a problem (easy to fix) except I'm wondering whether any overlap between objects would always slow the framerate, such as if I place trees right on the surface of the terrain, thereby causing a slight overlap for each. If so, this would cause severe problems unless the objects are adjusted so they have a slight gap between them.

[EgonOlsen]

No, that doesn't matter. If you are using the software renderer, it may cause a slight drop of maybe 5% at max, but nothing to worry about. Of course it's getting slower when more geometry is in the view. Maybe that was the problem in your case.

[AW999]

No, that doesn't matter. If you are using the software renderer, it may cause a slight drop of maybe 5% at max, but nothing to worry about. Of course it's getting slower when more geometry is in the view. Maybe that was the problem in your case.

  I don't think that can be the cause, because I just performed the following tests: 1) I ran it with all the terrain chunks in their proper positions but also in the view simultaneously - by zooming back far enough to have a view of all of them - and yet I was getting framerates of over 60.  2) I placed all of the terrain chunks at the same location and then ran it again, and the framerate dropped to 10 - 17 (!). 

[EgonOlsen]

Which renderer are you using? The hardware one, i suppose?

[AW999]

Which renderer are you using? The hardware one, i suppose?

  Yes.

[EgonOlsen]

Well, then it's hard to tell without knowing exactly what your are doing and what your hardware is. There's no performance penalty when objects overlap, so this has to be something else. Maybe some lighting calculations or limited fillrate of the graphics card (but then, it has to be pretty crappy..is it?).

Are you using compiled objects (http://www.jpct.net/wiki/index.php/Compiled_objects)?

[AW999]

Well, then it's hard to tell without knowing exactly what your are doing and what your hardware is. There's no performance penalty when objects overlap, so this has to be something else. Maybe some lighting calculations or limited fillrate of the graphics card (but then, it has to be pretty crappy..is it?).

Are you using compiled objects (http://www.jpct.net/wiki/index.php/Compiled_objects)?

  Yes, I'm using compiled objects.  Would that cause the problem?  My graphics card is a new, modern one - my computer is only a few months old.

[EgonOlsen]

No, that's not the problem. What card is that exactly (if you are on windows, try downloading GPU-Z to find out in case you don't know it)? That it's a new system doesn't really mean that the graphics card is any good...

About how many "chunks" are we actually talking here?

[AW999]

No, that's not the problem. What card is that exactly (if you are on windows, try downloading GPU-Z to find out in case you don't know it)? That it's a new system doesn't really mean that the graphics card is any good...
About how many "chunks" are we actually talking here?

 At that time there were 25 chunks, each with 800 triangles; but as I said it runs extremely fast when the chunks are arranged in proper locations - even when I move the camera to a location where you can see most of the polygons at the same time - in fact it runs fast even when I quadrupled the number of chunks. It's only when they're all placed at the same origin that it slows to a crawl. Could the problem have something to do with collision detection?  Each chunk is set to mode "COLLISION_CHECK_OTHERS".

[EgonOlsen]

Yes, that's possible. You are doing 25 times the number of collision checks, if all chunks are drawn over each other. You might consider to use OcTrees for the chunks (if you aren't doing this already) in collision only mode (i.e. not for rendering (OcTree.setCollisionUse(true), OcTree.setRenderingUse(false)); to speed up collision detection. You usually don't need to use them for rendering when rendering a compiled, chunked terrain.