www.jpct.net
jPCT-AE - a 3d engine for Android => Support => Topic started by: peter on June 21, 2016, 11:03:44 pm
-
I am using jpct-ae to rendering over 400 3D objects at once. what FPS amount should I expect? right now I am getting 10fps on android 5.1 galaxy note4 , it's pretty low.
-
That's actually pretty good for 400 objects. Draw calls are expensive (for the hardware, not for the engine) and rendering 400 objects on a mobile device isn't really feasible with good performance. Try to reduce the number of objects or join them into several larger ones if possible.
What kind of scene is this that needs to display so many objects?
-
I rendering some obj file in iPhone4 using scenekit, the performance in ios is much better than Android. I assume iPhone and Android phone should have similar performance since they are both using OpenGL
-
iPhone always uses PowerVR graphic chips. Android uses either PowerVR, Mali, Adreno, nVidia,...they all have different characteristics. Some are more sensitive to draw calls (Adreno for example) then others. In addition, in higher object scenes, the CPU/GPU governor in some devices tends to keep the GPU clock low, because of...reasons.
Which Android device are we talking about here?
-
I tested on Samsung tab 2 Android 4.4 , galaxy note4 Android 6.0.1, nexus 5 Android 5.1 and OnePlus 3 Android 6.0.1
-
it also takes long time to get those objects show on screen, it's doing Creating buffers... and VBO created for object for all 3D objects. it's possible to do those when creating 3D Objects?
-
No, it has to happen in the render thread. But if you don't use 400 individual objects, you can make them share mesh- and compiled data: http://www.jpct.net/wiki/index.php?title=Reducing_memory_usage#Reduce_memory_usage_of_objects (http://www.jpct.net/wiki/index.php?title=Reducing_memory_usage#Reduce_memory_usage_of_objects)
Edit: In addition, and in case you aren't doing it already, consider to use serialized objects instead of the raw 3d formats. That link above contains some Information about this as well.
-
I tested on Samsung tab 2 Android 4.4 , galaxy note4 Android 6.0.1, nexus 5 Android 5.1 and OnePlus 3 Android 6.0.1
Except for the tab2, these are all Adreno powered devices and Adreno isn't really good when it comes to draw calls. That, and multiple draws of smaller objects seem to make the gpu governor think that it can get away with low gpu clock speeds. I have this problem in my RPG as well: In dungeons, which are rendered as many small wall and ceiling elements, it usually thinks that 180mhz is enough albeit it could go up to 600mhz. In the rare cases in which it does, performance easily triples. I tried to battle this behaviour, but it didn't work out...
-
thank you for explaining. there is another problem I have with rendering 400 objects. when the App come back from Pause, jPct will redo all the creating buffer. it says "OpenGL context has changed(2)...recovering for renderer 2/1!" do you know how to prevent this? what does “OpenGL context has changed” mean?
-
It means that...the context has changed!? Or at least it doesn't know any better, so it acts as if it has. If the context changes, all data on the gpu will be lost and has to be retransfered. Context losses can happen when pausing/resuming an app, but they don't have to. You can improve the situation by doing what is mentioned in the last chapter of this post: http://www.jpct.net/forum2/index.php/topic,4549.msg31423.html#msg31423 (http://www.jpct.net/forum2/index.php/topic,4549.msg31423.html#msg31423)
-
I did "mGLView.setPreserveEGLContextOnPause(true);" at onCreateView, the onSurfaceChanged still being called twice after resume
-
onSurfaceChanged() can be called as much as Android likes. I've seen the strangest things happening there. It has nothing to do with the state of setPreserveEGLContextOnPause(). Keep in mind that setting setPreserveEGLContextOnPause(true) is one only part of the solution. You have to check the actual context as well, as mentioned in the thread.
-
To solve low fps problem, I tried merge 477 objects into one large object, after that I got 60 fps. just wondering why it solved the problem?
-
Well, he said that it's because of the number of draw calls, and that Adreno is bad at it. But I'd also like a more detailed explanation. ; )
-
There's actually not much to explain. Draw calls are one of the most expensive operations that you can do in graphics. Different devices behave different, of course, but they all benefit from reducing draw calls.
Another related issue is the GPU governor on Android. That's the part of the OS that takes care of GPU clock rate and such. From my observations, this code tends to up the clock rate only (again, this depends on the device/OS) if the GPU processes larger chunks of geometry. If it processes the same amount of vertices but splitted into smaller objects, the clock rate stays lower, which reduces performance even more.
-
So if I understand correctly:
-> Having xxx Object3D's will result in xxx draw calls for the Object3D's.
-> Having xxx Object3D's merged into 1 Object3D will result in just 1 draw call.
Isn't it possible for jPCT to automatically "merge" certain Object3D's? Not real merging into one Object3D, but just to reduce draw calls. (So I guess geometry-wise merging only)
I don't know if this will increase performance, since I'm not sure if merging itself is cheap performance-wise.
Another thing that might make this idea not work is the individual settings that are possible for Object3D's like different shaders. I don't think merged geometry could work with Object3D's with different shaders for instance.
But okay, for the Object3D's that share most settings, could those be merged geometry-wise?
Well a developer can instead just merge them immediately too to one Object3D, but at the cost of having control over the Object3D's it originally consisted of.
-
That's not really feasible. It's better to leave it to the developer.
-
Well it would be nice to have some automatic geometry-wise merging function to reduce draw calls. Or some helper class or something to allow it, I'm not sure how though.
But it would be nice to have Object3D's merged geometry-wise and still be able to control the Object3D's individually for this example:
When you got loads of Object3D's and you want to keep rotating 1 Object3D, then I guess this idea might be useful. In case you merge the Object3D's into one Object3D, it would be hard to rotate the mesh of the original Object3D you want to keep rotating...
EDIT: On second thought... it might actually be do-able if you create a custom Object3D merger or something, so you still have control over the individual meshes. Any suggestions how to exactly do this though?
-
You can either merge them or keep them under control separately. One could implement a kind of dynamic batching that would cover some applications (for example rendering minecraft-like landscapes), but those might be better off with a dedicated and focused engine anyway. With the means that jPCT-AE provides, you could hack something together with the IVertexController, but it will be very clunky and maybe not worth the hassle.
What do you need this for? Maybe there's a better solution!?
-
Hmm, the thing I'm working on looks a bit like minecraft-like landscapes.
So I thought it would be either this merging idea or the thing that is explained here: http://www.jpct.net/forum2/index.php/topic,4723.0.html
-
I wondered, is it possible to see the source code of the Object3D#mergeAll method jPCT-AE comes with?
-
I'm not sure why that would be helpful...?
-
I wanted to know how Object3D's are merged. Or basically... How are the meshes merged?
-
The data structures of both are copied/merged into a new one. Nothing special happens there...