Is the performance normal or slow?

Hello!



Take a look at the screenshot. This a simple LoD test for my project, implemented on a plane (which later on will be a face of a cube, which later will be shperified to get you_know_what :slight_smile: ).







Uploaded with ImageShack.us



This runs on QuadCore CPU with 8gb RAM, but with integrated GPU.

Each of the color “page” (that consists of 72 triangles) represents an “object” attached to rootNode.



Is this kind of performance normal, taking in account the ammount of triagles, objects, that can be seen in the left bottom corner? :expressionless:



By the way, this scene have about 30 fps if I run it on my iMac with NVIDIA GeForce GT 120 graphics with 256 MB of dedicated GDDR3 memory, but I found it slow anyway.

It's not the number of triangles that matters.

I think the problem is there are a lot of objects, ~2200 seems very high.

ie a scene with 1 object with the same amount of triangles would run a lot faster.



I don't know if that's applicable to your test case, though.




update



I have changed the triangle count of each node so to check the object vs. performance assumption.

The scene below has 4 nodes (4 objects. The display shows 18 because of text, which is also and object… 14 objects to be exact) with huuge amount of triangles each. The results aren’t too good, imo…







These 4 blocks appears to be solid, but it’s a wireframe actually.

hmmm… you're right there must be something else.

Are you using the wireColor.j3md for your material?



what is your integrated GPU ?

nehon said:

Are you using the wireColor.j3md for your material?

yes

nehon said:

what is your integrated GPU ?

"Intel(R) G45/G43 Express chipset" according to device manager.

A few factors at play here…


of objects: 2000 is not that much, but on the GeForce its always better to have less.


Video card: Intel GMA was not designed to handle the vertex/triangle counts in question. I would also recommend installing the latest driver.

Wireframe Mode: This is probably the biggest bottleneck. Most consumer-oriented video cards are not designed to render wireframe models, disabling wireframe mode may increase performance by a magnitude.

So a few things I would recommend you try:
- Try rendering without wireframe mode, on both the Intel and the GeForce.
- Try rendering the "optimized" mesh with only 1 object, on the GeForce.
- Update drivers for both cards.
Momoko_Fan said:

- Try rendering without wireframe mode, on both the Intel and the GeForce.

Looks like the problem was in wireframe mode after all. This screenshot was taken from iMac, each node has 100x100 vertices, giving 19602 triangles.

Hi



I am doing an GeoEditor for the open source project www.l2jserver.com (Lineage II Java emu).

The geo is spiltted in 17x17 regions where each region has 256x256 blocks which has 8x8 cells where every cell represents 16 world units.

There are 3 types of blocks. Flat with only one height, Complex with 8x8 cells where each has its own height and NSWE, and MultiLayer which is like complex but each cell can have a max of 127 layers.<br /> <br /> Each cell is only a small/big box and simple textured. (256x256 texture)<br /> So when i wanna display a larger region of like 17x17 blocks with like 200k polygons the fps goes down to ~13 fps.<br /> (Core2 Quad Q9300, nVidia GeForce 8800GT latest driver, 8gbyte ram)<br /> <br /> I am using java swing gui and created the canvas inside it.<br /> <code><br /> AppSettings settings = new AppSettings(true);<br /> settings.setWidth(640);<br /> settings.setHeight(480);<br /> settings.setFrameRate(30);<br /> //settings.setUseInput(true);<br /> //settings.setUseJoysticks(false);<br /> settings.setAudioRenderer(null);<br /> <br /> JmeSystem.setLowPermissions(true);<br /> <br /> _driver = new DisplayDriver();<br /> //_driver.setPauseOnLostFocus(false);<br /> _driver.setSettings(settings);<br /> _driver.createCanvas();<br /> _driver.startCanvas();<br /> <br /> _context = (JmeCanvasContext) _driver.getContext();<br /> _context.setSystemListener(_driver);<br /> <br /> _canvas = _context.getCanvas();<br /> _canvas.setSize(settings.getWidth(), settings.getHeight());<br /> </code><br /> <br /> The "DisplayDriver" is an simple extension of com.jme3.app.Application<br /> When having no geo loaded it shows an empty screen with like 3-4k fps, and the swing gui starts lagging.<br /> I putted an simple Thread.sleep(1ms) into the update() of the DisplayDriver to avoid such high fps and give the swing some cpu...and suddenly the fps on the larger scene went up to like 42 fps! A short view into the taskmanager shown that the app is suddently using 2 threads (50% cpu load).<br /> <br /> Well...its not about beauty…only about speed. So what is wrong with the Thread.sleep that activate a second magic core? (the problem is only on 3/5 starts of the app a second core is used).



Here some more code:



@Override

public void update()

{

if (speed == 0)

return;



super.setPauseOnLostFocus(false);

super.update();

final float tpf = timer.getTimePerFrame() * speed;



secondCounter += timer.getTimePerFrame();

int fps = (int) timer.getFrameRate();

if (secondCounter >= 1.0f)

{

_fpsText.setText("FPS: " + fps);



long free = Runtime.getRuntime().freeMemory();

long cur = Runtime.getRuntime().totalMemory();

_memText.setText(“Mem: " + ((cur - free) / 1024 / 1024) + “/” + (cur / 1024 / 1024) + " MB”);

secondCounter = 0.0f;

}



try

{

Thread.sleep(2);

}

catch (InterruptedException e)

{

// TODO Auto-generated catch block

e.printStackTrace();

}



updateGrid(tpf);

updateActions();



_rootNode.updateLogicalState(tpf);

_guiNode.updateLogicalState(tpf);

_rootNode.updateGeometricState();

_guiNode.updateGeometricState();



stateManager.render(renderManager);

renderManager.render(tpf);

}







@Override

public final void initialize()

{

super.initialize();



guiViewPort.attachScene(_guiNode);

viewPort.attachScene(_rootNode);



for (int i = _materials.length, j; i-- > 0;)

{

for (j = MaterialIndex.VALUES.length; j-- > 0;)

{

_materials[j] = load(MaterialIndex.VALUES[j], MaterialColor.VALUES);

}

}



_logo.move(0, 0, -1);

_logo.setPosition(0, 0);

_logo.setWidth(650);

_logo.setHeight(620);

_logo.setImage(assetManager, “/data/img/inc_logo_big.png”, false);



// _guiNode.attachChild(_logo);



_guiFont = assetManager.loadFont(“Interface/Fonts/Default.fnt”);

_fpsText = new BitmapText(_guiFont, false);

_fpsText.setSize(_guiFont.getCharSet().getRenderedSize());

_fpsText.setLocalTranslation(0, _fpsText.getLineHeight(), 0);

_fpsText.setText(“FPS:”);

_guiNode.attachChild(_fpsText);

_memText = new BitmapText(_guiFont, false);

_memText.setSize(_guiFont.getCharSet().getRenderedSize());

_memText.setLocalTranslation(0, _memText.getLineHeight() + _fpsText.getLineHeight(), 0);

_memText.setText(“Mem:”);

_guiNode.attachChild(_memText);



GeoBox.DISPLAY_DRIVER = this;

GeoBox.DEFAULT_COLOR_FLAT = MaterialColor.BLUE;

GeoBox.DEFAULT_COLOR_COMPLEX = MaterialColor.GREEN;

GeoBox.DEFAULT_COLOR_MULTI = MaterialColor.RED;

GeoBox.DEFAULT_COLOR_SELECTED = MaterialColor.ORANGE;

GeoBox.DEFAULT_COLOR_HIGHLIGHTED = MaterialColor.CYAN;



_navigateHandler = new NavigateHandler(cam, inputManager);

}





And a screenshot:

Geo Editor on 2 threads



Well i tried to make one without the “Thread.sleep” and suddenly i have good framerates all the time and it`s running on 2 cores all the time. <.<



Well maybe you have some advices for me to make framerates like “KayTrance” in the post above.



Thanks for all replys :slight_smile:

Forsaiken

I don’t exactly understand whats the whole thing about Thread.sleep() and how it has to do with two cores, I am kinda confused lol

Anyways, you might want to consider using AppSettings.setFrameRate() as that’s the preferred way of limiting framerate in jME3.

forsaiken said:
I putted an simple Thread.sleep(1ms) into the update() of the DisplayDriver to avoid such high fps and give the swing some cpu...and suddenly the fps on the larger scene went up to like 42 fps! A short view into the taskmanager shown that the app is suddently using 2 threads (50% cpu load).


Using Thread.sleep() as a means of reliable control is a pretty impossible notion. Individual systems will have differently sized time slices. At a tiny value, such as 1ms, only sleeping for a single millisecond will be damn near [if not completely] impossible. Without any guarantee made by the operating system, there's no way of predicting what the actual sleeping time will be..

Sry for writting a little confusing.



Sometimes the app starts with only one core (only 25% cpu usage). Then the framerate is very low, too (8-13 fps).

After some more tests the problem suddenly never appeared again, even after removing the sleep.



I just setted a general frame limit of 30fps in the app settings.

Anyways… “Kay Trance” is able to view over a million of polygons with over 100 fps.

I wonder how he does it o.o



I also started the app without any canvas impl…like in all jme3 test classes.

I never get over 43 fps with 100-300k polygons.


“Kay Trance” is able to view over a million of polygons with over 100 fps.

If you check the object count you'll see, that there are just few objects, but with high poly count. This picture was takes for testing purpose only. As Nehon told, it's not the number of triangles that matters.
KayTrance said:

“Kay Trance” is able to view over a million of polygons with over 100 fps.

If you check the object count you'll see, that there are just few objects, but with high poly count. This picture was takes for testing purpose only. As Nehon told, it's not the number of triangles that matters.


Ahhh...
So the number of calls (writing the buffers to video card, more objects more calls) limits the speed.
Or is there maybe an way to "optimize" it on the java side to only do the limited stuff i need at higher speed?
For example removing the Collections.synchronizedList to make the iterations faster?

Thx for answere :)

Ok the weird bug with only 25% cpu usage and low fps appeared again…

I just deleted the native libs that got extracted and setted the JmeSystem.setLowPermissions(false);

After the lib got extracted i setted it back to JmeSystem.setLowPermissions(true);

And also replaces the dlls with the one that i deleted before.



Before i deleted the native libs everything was fine…there was not other change!



But see urself

Weird Bug



Edit: Attached log of console excluding logs for Nodes

10.09.2010 11:21:35 com.jme3.asset.DesktopAssetManager

INFO: DesktopAssetManager created.

10.09.2010 11:21:35 com.jme3.system.JmeSystem initialize

INFO: Running on jMonkey Engine 3 Alpha 0.6

10.09.2010 11:21:35 com.jme3.system.Natives extractNativeLibs

INFO: Extraction Directory #1: file:/D:/Programme/geoeditor/libs/

10.09.2010 11:21:35 com.jme3.system.Natives extractNativeLibs

INFO: Extraction Directory #2: D:Programmegeoeditor

10.09.2010 11:21:35 com.jme3.system.Natives extractNativeLibs

INFO: Extraction Directory #3: D:Programmegeoeditor

10.09.2010 11:21:35 com.jme3.system.lwjgl.LwjglCanvas$1 addNotify

INFO: EDT: Creating OGL thread.

10.09.2010 11:21:36 com.jme3.system.lwjgl.LwjglAbstractDisplay run

INFO: Using LWJGL 2.5

10.09.2010 11:21:36 com.jme3.system.lwjgl.LwjglAbstractDisplay initInThread

INFO: Display created.

10.09.2010 11:21:36 com.jme3.system.lwjgl.LwjglAbstractDisplay initInThread

INFO: Adapter: nvd3dumx,nvwgf2umx,nvwgf2umx

10.09.2010 11:21:36 com.jme3.system.lwjgl.LwjglAbstractDisplay initInThread

INFO: Driver Version: 8.17.11.9621

10.09.2010 11:21:36 com.jme3.system.lwjgl.LwjglAbstractDisplay initInThread

INFO: Vendor: NVIDIA Corporation

10.09.2010 11:21:36 com.jme3.system.lwjgl.LwjglAbstractDisplay initInThread

INFO: OpenGL Version: 3.2.0

10.09.2010 11:21:36 com.jme3.system.lwjgl.LwjglAbstractDisplay initInThread

INFO: Renderer: GeForce 8800 GT/PCI/SSE2

10.09.2010 11:21:36 com.jme3.system.lwjgl.LwjglAbstractDisplay initInThread

INFO: GLSL Ver: 1.50 NVIDIA via Cg compiler

10.09.2010 11:21:36 com.jme3.system.lwjgl.LwjglTimer

INFO: Timer resolution: 1000 ticks per second

10.09.2010 11:21:36 com.jme3.renderer.lwjgl.LwjglRenderer initialize

INFO: Caps: [FrameBuffer, FrameBufferMRT, FrameBufferMultisample, OpenGL20, Open

GL21, OpenGL30, ARBprogram, GLSL100, GLSL110, GLSL120, GLSL130, GLSL140, GLSL150

, VertexTextureFetch, TextureArray, TextureBuffer, FloatTexture, FloatColorBuffe

r, FloatDepthBuffer, PackedFloatTexture, SharedExponentTexture, PackedFloatColor

Buffer, TextureCompressionLATC, MeshInstancing, VertexBufferArray]

10.09.2010 11:21:36 com.jme3.renderer.Camera

INFO: Camera created (W: 640, H: 480)

10.09.2010 11:21:36 com.jme3.renderer.Camera

INFO: Camera created (W: 640, H: 480)

10.09.2010 11:21:36 com.jme3.input.lwjgl.LwjglMouseInput initialize

INFO: Mouse created.

10.09.2010 11:21:36 com.jme3.input.lwjgl.LwjglKeyInput initialize

INFO: Keyboard created.

10.09.2010 11:21:37 com.jme3.renderer.lwjgl.LwjglRenderer updateUniformLocation

WARNUNG: Uniform m_VertexColor is not declared in shader.