www.jpct.net

jPCT - a 3d engine for Java => Support => Topic started by: Jakes on October 13, 2019, 06:40:54 pm

Title: Low performance when using uncompiled objects
Post by: Jakes on October 13, 2019, 06:40:54 pm
Hello,

I've been using a lot jpct alongside other libs. The problem is, every time I use uncompiled objects, I experience some frame rate drops for a while (like 5/10 secs) and then it gets fine as it seems like its buffering building something on the fly.

Is this normal? Or is there anything I could do to minimize this?

Regards,
Jakes
Title: Re: Low performance when using uncompiled objects
Post by: EgonOlsen on October 13, 2019, 06:51:14 pm
It might be normal, but it's difficult to say from a distance. If a hickup happens, is there some corresponding log output at the same moment?
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on October 13, 2019, 07:28:58 pm
There is a log, but there's nothing I could explicitly say for sure that could be the reason:

Code: [Select]
Java version is: 1.7.0_80
-> support for BufferedImage
Version helper for 1.5+ initialized!
-> using BufferedImage
Software renderer (OpenGL mode) initialized
Software renderer disposed
Using LWJGL's AWTGLCanvas
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Software renderer disposed
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
[ Sun Oct 13 18:23:57 BST 2019 ] - WARNING: Unsupported Texture width (206)...resizing to a width of 256 pixels!
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Loading Texture...from Image
Adding Lightsource: 0
Adding Lightsource: 1
Adding Lightsource: 2
Adding Lightsource: 3
Adding Lightsource: 4
Adding Lightsource: 5
Adding Lightsource: 6
Adding Lightsource: 7
Adding Lightsource: 8
Adding Lightsource: 9
Adding Lightsource: 10
Adding Lightsource: 11
Adding Lightsource: 12
Adding Lightsource: 13
Adding Lightsource: 14
Adding Lightsource: 15
Adding Lightsource: 16
Adding Lightsource: 17
Adding Lightsource: 18
Adding Lightsource: 19
Adding Lightsource: 20
Adding Lightsource: 21
Adding Lightsource: 22
Adding Lightsource: 23
Adding Lightsource: 24
Adding Lightsource: 25
Adding Lightsource: 26
Adding Lightsource: 27
Adding Lightsource: 28
Adding Lightsource: 29
Adding Lightsource: 30
Adding Lightsource: 31
Adding Lightsource: 32
Adding Lightsource: 33
Adding Lightsource: 34
Adding Lightsource: 35
Adding Lightsource: 36
Adding Lightsource: 37
Adding Lightsource: 38
Adding Lightsource: 39
Adding Lightsource: 40
Adding Lightsource: 41
Adding Lightsource: 42
Adding Lightsource: 43
Adding Lightsource: 44
Adding Lightsource: 45
Adding Lightsource: 46
Adding Lightsource: 47
Adding Lightsource: 48
Adding Lightsource: 49
Adding Lightsource: 50
Adding Lightsource: 51
Adding Lightsource: 52
Adding Lightsource: 53
Adding Lightsource: 54
Adding Lightsource: 55
Adding Lightsource: 0
Adding Lightsource: 1
Adding Lightsource: 2
Adding Lightsource: 3
Adding Lightsource: 4
Adding Lightsource: 5
Adding Lightsource: 6
Adding Lightsource: 7
Adding Lightsource: 8
Adding Lightsource: 9
Adding Lightsource: 10
Adding Lightsource: 11
Adding Lightsource: 12
Adding Lightsource: 13
Adding Lightsource: 14
Adding Lightsource: 0
Adding Lightsource: 1
Adding Lightsource: 2
Adding Lightsource: 3
Adding Lightsource: 4
Adding Lightsource: 5
Adding Lightsource: 6
Adding Lightsource: 7
Adding Lightsource: 8
Adding Lightsource: 9
Adding Lightsource: 10
Adding Lightsource: 11
Adding Lightsource: 12
Adding Lightsource: 13
Adding Lightsource: 14
Adding Lightsource: 15
Adding Lightsource: 16
Adding Lightsource: 17
Adding Lightsource: 18
Adding Lightsource: 19
Adding Lightsource: 20
Adding Lightsource: 21
Adding Lightsource: 22
Adding Lightsource: 23
Adding Lightsource: 24
Adding Lightsource: 25
Adding Lightsource: 26
Adding Lightsource: 27
Adding Lightsource: 28
Adding Lightsource: 29
Adding Lightsource: 30
Adding Lightsource: 31
Adding Lightsource: 32
Adding Lightsource: 33
Adding Lightsource: 34
Adding Lightsource: 35
Adding Lightsource: 36
Adding Lightsource: 37
Adding Lightsource: 38
Adding Lightsource: 39
Adding Lightsource: 40
Adding Lightsource: 41
Adding Lightsource: 42
Adding Lightsource: 43
Adding Lightsource: 44
Adding Lightsource: 45
Adding Lightsource: 46
Adding Lightsource: 47
Adding Lightsource: 48
New WorldProcessor created using 1 thread(s) and granularity of 1!
Waiting for renderer to initialize...0
Waiting for renderer to initialize...1
Driver is: igdumdim64/10.18.10.3496 on NVIDIA Corporation / GeForce 840M/PCIe/SSE2
GL_ARB_texture_env_combine supported and used!
FBO supported and used!
VBO supported and used!
OpenGL renderer initialized (using 4 texture stages)
Checking for triangle strip...
Not a triangle strip at position 1!
Subobject of object 34/object36 compiled to indexed data using 24/9 vertices in 0ms!
Object 34/object36 compiled to 1 subobjects in 123ms!
Creating new world processor buffer for thread Renderer Thread
Checking for triangle strip...
Not a triangle strip at position 1!

[...REPEATS the same 5 lines above, for 200+ times...]

VBO created for object 'object3526'
VBO created for object 'object3363'
VBO created for object 'object3328'
VBO created for object 'object3424'
VBO created for object 'object3427'
VBO created for object 'object3464'
VBO created for object 'object3467'
VBO created for object 'object3398'
VBO created for object 'object3523'
VBO created for object 'object3518'
VBO created for object 'object3344'
VBO created for object 'object3320'
VBO created for object 'object3390'
VBO created for object 'object3368'
VBO created for object 'object3387'
VBO created for object 'object1442'
VBO created for object 'object3315'
VBO created for object 'object2429'
VBO created for object 'object1263'
VBO created for object 'object3430'
VBO created for object 'object3555'
VBO created for object 'object2040'
VBO created for object 'object3446'
VBO created for object 'object3539'
VBO created for object 'object3502'
VBO created for object 'object3366'
VBO created for object 'object3331'
VBO created for object 'object3579'
VBO created for object 'object3520'
VBO created for object 'object3635'
VBO created for object 'object3611'
VBO created for object 'object40'
VBO created for object 'object1592'
VBO created for object 'object3576'
VBO created for object 'object3336'
VBO created for object 'object3379'
VBO created for object 'object3552'
VBO created for object 'object3531'
VBO created for object 'object3470'
VBO created for object 'object3606'
VBO created for object 'object3595'
VBO created for object 'object3440'
VBO created for object 'object3507'
VBO created for object 'object3632'
VBO created for object 'object3603'
VBO created for object 'object3563'
VBO created for object 'object3462'
VBO created for object 'object3616'
VBO created for object 'object1259'
VBO created for object 'object3590'
VBO created for object 'object3480'
VBO created for object 'object3600'
VBO created for object 'object3478'
VBO created for object 'object3488'
VBO created for object 'object41'
VBO created for object 'object3392'
VBO created for object 'object2427'
VBO created for object 'object3360'
VBO created for object 'object3475'
VBO created for object 'object3411'
VBO created for object 'object3494'
VBO created for object 'object3574'
VBO created for object 'object3483'
VBO created for object 'object3571'
VBO created for object 'object3598'
VBO created for object 'object3512'
VBO created for object 'object3419'
VBO created for object 'object3550'
VBO created for object 'object3624'
VBO created for object 'object43'
VBO created for object 'object3422'
VBO created for object 'object3323'
VBO created for object 'object3352'
VBO created for object 'object2437'
VBO created for object 'object38'
VBO created for object 'object1255'
VBO created for object 'object3384'
VBO created for object 'object3358'
VBO created for object 'object3558'
VBO created for object 'object36'
VBO created for object 'object3587'
VBO created for object 'object3630'
VBO created for object 'object3456'
VBO created for object 'object3614'
VBO created for object 'object3350'
VBO created for object 'object1257'
VBO created for object 'object3504'
VBO created for object 'object42'
VBO created for object 'object2435'
VBO created for object 'object3454'
VBO created for object 'object3472'
VBO created for object 'object3318'
VBO created for object 'object3608'
VBO created for object 'object3486'
VBO created for object 'object3403'
VBO created for object 'object3414'
VBO created for object 'object3515'
VBO created for object 'object3566'
VBO created for object 'object3542'
VBO created for object 'object3374'
VBO created for object 'object1590'
VBO created for object 'object3582'
VBO created for object 'object3496'
VBO created for object 'object3568'
VBO created for object 'object3451'
VBO created for object 'object3584'
VBO created for object 'object3536'
VBO created for object 'object3622'
VBO created for object 'object3400'
VBO created for object 'object3627'
VBO created for object 'object3592'
VBO created for object 'object3510'
VBO created for object 'object2062'
VBO created for object 'object3326'
VBO created for object 'object1440'
VBO created for object 'object3438'
VBO created for object 'object3376'
VBO created for object 'object3432'
VBO created for object 'object2431'
VBO created for object 'object3406'
VBO created for object 'object2433'
VBO created for object 'object1253'
VBO created for object 'object3408'
VBO created for object 'object3619'
VBO created for object 'object3499'
VBO created for object 'object3334'
VBO created for object 'object3547'
VBO created for object 'object3355'
VBO created for object 'object1261'
VBO created for object 'object3560'
VBO created for object 'object3528'
VBO created for object 'object3416'
VBO created for object 'object3339'
VBO created for object 'object3371'
VBO created for object 'object2038'
VBO created for object 'object3459'
VBO created for object 'object2064'
VBO created for object 'object3347'
VBO created for object 'object3534'
VBO created for object 'object3443'
VBO created for object 'object3448'
VBO created for object 'object3491'
VBO created for object 'object3382'
VBO created for object 'object3342'
VBO created for object 'object3544'
VBO created for object 'object3395'
VBO created for object 'object3435'
Compiled 147 VBO!
Max. anisotropy supported: 16
0(1) : warning C7554: OpenGL requires sampler variables to be explicitly declared as uniform


Shader program compiled and linked fine!
Tangent handle not found (tangents needed: false)!
Shader compiled!
Title: Re: Low performance when using uncompiled objects
Post by: EgonOlsen on October 13, 2019, 07:32:22 pm
I fail to the relation between the log output and your question, because your question was about uncompiled objects while the log shows the usage of compiled ones...
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on October 13, 2019, 08:53:11 pm
Yes, the reason is mainly because I wrote a procedure that either compiles all of the objects (when using compiled mode) or  only compiles sprites (billborded ones, because they're a part of a framework based pool Structure).

but I'm only using 200+ compiled vs the full 3400+ compiled scene, which is when its way smoother without any stutter os hickups.

which in this example, I have some hickups on the start as you said, but if I were to compile the full scene, I don't have any problem whatsoever.
Title: Re: Low performance when using uncompiled objects
Post by: EgonOlsen on October 14, 2019, 12:54:45 pm
You can try to do these at startup- Maybe that helps:

http://www.jpct.net/doc/com/threed/jpct/TextureManager.html#preWarm(com.threed.jpct.FrameBuffer) (http://www.jpct.net/doc/com/threed/jpct/TextureManager.html#preWarm(com.threed.jpct.FrameBuffer))

http://www.jpct.net/doc/com/threed/jpct/World.html#buildAllObjects() (http://www.jpct.net/doc/com/threed/jpct/World.html#buildAllObjects())

But actually, compiled objects are more likely to cause initial hickups...which puzzles me a bit here...
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on October 15, 2019, 10:43:00 pm
You can try to do these at startup- Maybe that helps:

http://www.jpct.net/doc/com/threed/jpct/TextureManager.html#preWarm(com.threed.jpct.FrameBuffer) (http://www.jpct.net/doc/com/threed/jpct/TextureManager.html#preWarm(com.threed.jpct.FrameBuffer))


I already knew about this kind of optimization, I've read all the wikis you have to help improve 3D scenes, and I'm already using all the tips.

Quote
http://www.jpct.net/doc/com/threed/jpct/World.html#buildAllObjects() (http://www.jpct.net/doc/com/threed/jpct/World.html#buildAllObjects())

didn't know about this one though, but everytime I'm loading a new object onCreateScene event I'm building each one right on the spot, so, no help so far.

Quote
But actually, compiled objects are more likely to cause initial hickups...which puzzles me a bit here...

Really? I've used this framework for a lot of projects and tests of mine, and every single one worked better without any setbacks or staggering when compiled, but everytime I use uncompiled objects (around 90% of them) the more it grows the worse it gets.

But quick note, it might help on understanding this, this only happens once any tipo of object becomes rendered for the first time, after that, all the copies of that will be loaded quickly without any hickups. lets say that I have a "database of 3 objects":

- Ball
- Chair
- Car

I load the Ball and put it in the scene in front of the camera, it will reduce my frame rate to around 10fps for like 1 or 2 secs, and then its all good, back to my fixed 60. after that I can load as many Balls as I want that i will be fine for the time the program is running. The same will happen for the Chair for the first time, and then will be fine the other times it will be rendered.

Can we take a guess that this could be due to java itself? Or maybe OpenGL while sending the objects to the GPU?
Because it seems like some kind of caching, that on the second time is already there which wont stagger my game the second times.

on another note, I though of loading all objects to a test scene the first time while loading but to no result because they need to be displayed, and that will be a weird user experience and will crash my memory.

so I'm stuck
Title: Re: Low performance when using uncompiled objects
Post by: EgonOlsen on October 16, 2019, 12:32:06 pm
Actually, the uncompiled pipeline renders individual polygons by pushing them to the GPU triangle after triangle. That's slow in itself, but I don't see why this should cause such a performance drop.
Can you provide me with a simple test case that shows this problem?
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on October 16, 2019, 01:17:24 pm
In the past, I've also came across this same problem while dealing with individual polygon structure passed on the pipeline when using no VBOs, therefore I would assume that this is not entirely a Java/jPCT problem, the strange thing is the way this happens, it only seem happen the fisrt time each object is rendered.

About the sample, sure, do you want a package of the code? Lemme wrap it up with a simple example and some objects that I have here with a compiled and uncompiled case.
Title: Re: Low performance when using uncompiled objects
Post by: EgonOlsen on October 16, 2019, 01:35:20 pm
Yes, just some simple example that compiles and shows the issue.
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on October 19, 2019, 06:58:51 pm
Here is the test with both modes, compiled and non compiled, you can also check the result image to analyze the data.
you can see that in every graph there's a little "warm up" for the non compiled objects.
Title: Re: Low performance when using uncompiled objects
Post by: EgonOlsen on October 20, 2019, 03:20:01 pm
I would be hard pressed to say that I really see the mentioned effect in these tests...Here are the graphs as they look when running the tests on my machine from Eclipse with -Xmx and -Xms both set to 1024m in the test's runtime configuration:

Compiled:

(https://jpct.de/stuff/Result-Compiled.png)
(I guess it's too fast so the graph is out of scale, but as we don't have a problem with compiled objects, I don't mind it)

an uncompiled:

(https://jpct.de/stuff/Result-NonCompiled.png)

What am I looking for here? The lower framerate at the beginning? That would be caused by the JIT compiler warming up, because it gets smaller when you start the test with -server -Xcompile. Anyway, when looking at the rendered output, I can't even notice this phase, so I'm not sure if that's what we are talking about?

How do these graphs look on your machine? Oh, and another idea, just in case it's somehow caused by the graphics driver: Try Config.glVertexArrays=false before setting up your actual scene. Maybe that changes something....
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on October 20, 2019, 05:49:35 pm
Thanks, yes the difference in both machines is clear, but there still persists the "warming up" which I also thought it could be caused by the JIT, but if that were to be true, why aren't compiled objects reacting in the same way?

Compiled:
(https://i.imgur.com/pcpq4wP.png)

Non-Compiled:
(https://i.imgur.com/z3qNQk7.png)

Machine Specs:
Core:  i7-4510U @ 2.00GHz
Ram:  12 GB
OS:    Win 8.1 64x
GPU:  GeForce 840M, Graphical Clock: 1029 MHz
Java:  7, 64x

its clear that in both machines (even with different specs) we still have the warm up, but although its just a short initial period, it will happen everytime a different object comes into play (rendered) which is a bit weird, because when using compiled objects such behaviour is nonexistent.

I thought this could besome kind of caching on the application side once we are using computer memoty to store the objects to be sent to the pipeline every frame, so that could lead to the warm up, but could it be optimized on the jPCT framework? Or is it really java's only fault here?

Anyway, I tried the VM params (-server -Xcompile) you used and "Config.glVertexArrays=false;", and it got a little better:
(https://i.imgur.com/OhF13e7.png)
 but on bigger scenes with a lot more dynamic stuff happening, I still expierience the warm up everytime a new object comes into play.

Anyway, even if this "issue" got somehow better, there still be performance issues when expanding the scene, as we can see on the "non-compiled" case. Thereforce I'll bet on the compiled scene, so I gotta hit the road on learning GLSL so I can use more dynamic lighting and stuff.

thanks a lot for your time on this matter.

Title: Re: Low performance when using uncompiled objects
Post by: EgonOlsen on October 21, 2019, 08:53:31 am
From an engine perspective, there's nothing going on for uncompiled objects that could cause this IMHO. There's no caching or any other kind of one-time processing involved when rendering an uncompiled object for the first time.
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on October 28, 2019, 04:50:48 pm
Title: Re: Low performance when using uncompiled objects
Post by: EgonOlsen on October 31, 2019, 10:16:15 pm
If it happens only when an object comes into view for the first time that uses a mesh that has never been used on any other object before, then it might be the buffer filling for the compiled data that gets transfered to the GPU. jPCT-AE has a method to do this beforehand (http://www.jpct.net/jpct-ae/doc/com/threed/jpct/World.html#compileAllObjects() (http://www.jpct.net/jpct-ae/doc/com/threed/jpct/World.html#compileAllObjects())), but desktop jPCT hasn't. I guess I didn't see it as an issue on the desktop. I think that I could add it to the desktop version at least when not using the AWTGLRenderer (you aren't using that, are you?) but I want to be sure that it's actually the issue. If it is, there should be a log message like

Quote
Subobject of object 12/blah compiled to...

each time the pause happens. Is there?
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on November 01, 2019, 07:41:03 pm
I've compiled a sample log from an execution and attached it to the post. (I had to zip it so it could pass the file size limit)
Well, I don't know if its that issue or not, but I'm seeing a lot of these:

    Subobject of object 7225/object7227 compiled to indexed data using 24/9 vertices in 0ms!
   Object 7225/object7227 compiled to 1 subobjects in 0ms!


do you think it could be this?

Quote
I think that I could add it to the desktop version at least when not using the AWTGLRenderer (you aren't using that, are you?)

It is in fact written on the log "Using LWJGL's AWTGLCanvas", so I guess it is in fact being used, but does it have anything to do with this issue?

I'm using the FrameBuffer.enableGLCanvasRenderer() to get the renderer I need to use Hardware accelerated rendering.

Note: to help tracking what's happening, I've added information to let you know what's the operation being performed before some blocks, in this format:

"LOG: --------------------[Media] is STARTING----------------"
"LOG: --------------------[Media] is ENDING----------------"


this would be a block of execution, for instance.
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on November 02, 2019, 06:24:26 am
I've done some tests, and it seems that it could be something like what you said.
Every time a new object comes into play and becomes visible inside the camera frustum, a new line of log will appear with the next content followed by some dragging and freezing of the simulation:

   Object 'object1579' shares compiled data with object 'object15'

and the simulation keeps running fine afterwards, until new objects are created in front of the camera while writing more of these lines to the console.
Title: Re: Low performance when using uncompiled objects
Post by: EgonOlsen on November 04, 2019, 02:56:11 pm
Ok, I'll go and see if I can port the compileAll method from jPCT-AE or if there was a reason not to other than my false assumption that it isn't needed... ;)
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on November 04, 2019, 06:27:19 pm
Many thanks for your time!
Title: Re: Low performance when using uncompiled objects
Post by: EgonOlsen on November 06, 2019, 10:32:59 pm
I did something. It's called compileAllObjects(<FrameBuffer>) and can be found in World. It doesn't seem to cause a crash, so that's a good start. I'm not sure how much it helps though. There might still be the uploading of the actual data to GPU left at rendertime, but everything else should be done if you call this method. The GL renderer had be enabled when doing so or otherwise, the method will do nothing. Please give it a try: https://jpct.de/download/net/jpctapi_132b1.zip (https://jpct.de/download/net/jpctapi_132b1.zip)
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on November 07, 2019, 04:16:18 pm
So I tested it out yesterday, and apparently 2 results happened:

- I tested it after the GL context is created (meaning a FrameBuffer) and nothing much changed, perhaps due to the GL data being sent through the pipeline for the first time as you said before.
- I tested it the first time an iteration happens (onProgress) to guarantee that there is in fact an existent GL context, but the result is mostly the same, sometimes faster but its non-deterministic, which I think might have to do with the loading of the GL VBOs into the GPU.

now my question is: How come we can't pre-load all these beforehand on a loading moment, so that those mid simulation loadings are avoided altogether?
Other frameworks allow for a preloading of all data (Textures, animations and 3Dobject models), no? Because no other game or simulation, I ran before, ever done that while in the middle of a running scene.

Isn't there any way to pass all the VBO data into the GPU synchronously beforehand and receive an "ok" when its done so I can progress further on loading the next ones before I can start the simulation itself? (Something like loading a texture, where you send the pixeldata to the GPU and it responds back with ok or not ok, and you proceed to load the next one?)
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on November 07, 2019, 04:29:13 pm
I've gathered some information while browsing the web and came across something similar:
  https://community.khronos.org/t/opengl-glbufferdata-cause-stuttering-while-loading-terrain-lod/76292/11 (https://community.khronos.org/t/opengl-glbufferdata-cause-stuttering-while-loading-terrain-lod/76292/11)

And something to try to solve the asyncronous problem:
  https://www.gamedev.net/forums/topic/677398-opengl-check-if-vbo-upload-is-complete/ (https://www.gamedev.net/forums/topic/677398-opengl-check-if-vbo-upload-is-complete/)

but from what I can tell, this seem to be a known problem, and hard to deal with.

My idea is to try to load each object individually in front of the camera, behind an overlay that conceals it so that it can be loaded beforehand in order to avoid any future stuttering of the simulation. Do you whink this will solve the issue itself?


Title: Re: Low performance when using uncompiled objects
Post by: EgonOlsen on November 08, 2019, 01:06:41 pm
It might be possible to do the VBO transfer beforehand as well. I'll try to look into it this weekend. The reason why this doesn't happen, is because all GL related operations have to take place in the GL thread (which owns the context). Depending on the renderer, this can either be applications main thread or the awt event dispatch thread of Java or a normal Java thread. To ensure that it always happens in the correct thread, some operations are postponed until jPCT can be sure to be in the right place. I never saw these little hickups as a problem myself (didn't notice them at all), so I kept it that way.
Have you tried to disable VBO support in Config (http://www.jpct.net/doc/com/threed/jpct/Config.html#glUseVBO (http://www.jpct.net/doc/com/threed/jpct/Config.html#glUseVBO))? In that case, the transfer doesn't happen and these hickups should go away in case they are really caused by this.
Title: Re: Low performance when using uncompiled objects
Post by: EgonOlsen on November 09, 2019, 02:44:09 pm
Try this one. It should also prefill the VBO: https://jpct.de/download/net/jpct.jar (https://jpct.de/download/net/jpct.jar)
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on November 11, 2019, 12:05:19 pm
So I tried to set Config.glUseVBO to false, and did a lot of different combinations and cases, and still got the same results, perhaps my graphics card always tends to use VBO? Some say that the latest cards only have support for VBO and Display Lists are becoming deprecated.

I also tried with uncompiled objects (with and without textures, with more or less objects) but got to the same result.

Quote
Try this one. It should also prefill the VBO: https://jpct.de/download/net/jpct.jar

Thanks, I'll give it a go when I get home later on.

Btw, no need to call World.compileAllObjects(FrameBuffer) or any other method on this change?

Title: Re: Low performance when using uncompiled objects
Post by: EgonOlsen on November 11, 2019, 12:33:24 pm
No, you need to call that method anyway. It now does the prefilling in addition to what it did before.
Title: Re: Low performance when using uncompiled objects
Post by: EgonOlsen on November 11, 2019, 01:23:08 pm
So I tried to set Config.glUseVBO to false, and did a lot of different combinations and cases, and still got the same results, perhaps my graphics card always tends to use VBO? Some say that the latest cards only have support for VBO and Display Lists are becoming deprecated.
I guess the driver could do something like that, yes. After all, OpenGL is a client/server model (with the client being the application and the server being the driver/GPU) and you can't be sure which data resides on the client or gets copied over to the server in the process.
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on November 13, 2019, 07:02:46 pm
So, I've run some tests with a lot of different cases, and it seems that everything seemed to be fine with the structures.

I ran some detailed analysis, and I haven't checked any differences whatsoever while using the new Jars, the problem persisted, so I took it a little deeper.

And I found that:
- New tests (with and without the new Jars) indicate that without textures the issue is non-existent.

So I tried to use the TextureManager.preWarm(FrameBuffer) (which I was already using before) in different moments and events, but to no success.
So I was reading the Wiki, and it says: "This method isn't guaranteed to do anything, if the renderer doesn't offer any pre-warming." -> Could it be this? How can I check this?

So, in conclusion it seems that the issue only exists when using big-textured compiled objects, otherwise, it runs smoothly regardless of the numer of vertices/faces or count. The staggering only happens every time a new texture comes to play stuck on an object.

PS: I'm trying to arrange a different setup/machine to try to test out the different scenarios to check if the issues are Mesh, VBO, Display List, Texture or Graphics card related.
Title: Re: Low performance when using uncompiled objects
Post by: EgonOlsen on November 15, 2019, 12:04:47 am
The OpenGL renderer does support it, so it should actually do something. How large are these textures and which graphics card are you using for your tests?
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on November 15, 2019, 04:20:05 pm
These textures vary from 512x512 to 4096x4096, the ones giving the major hiccups are the 2048x2048 and 4096x4096. when I removed them, everything worked fine, without hiccups at all (some so small you wodnt notice them 512 textures were harmless), using both the old and new jars.

So I removed the preWarm() I was using, and chaged it to the first cycle iteration of the simulation progress, and still had the same results as if there were no effect at all.
The example was a sphere with a 4096x4096 texture on it and 2 more of the same size with alpha channels. (only right before looking at the object you will have a small freeze-frame for 0.3/4 secs and it would continue normally afterwards)

I am building a single case scenario now with the same example, to test on my other machine, I will send you today the results and the project if you want them.
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on November 16, 2019, 04:25:30 am
Found it!

It seems that the AWTJPCTCanvas is not assuming the preWarm action.

Here is my test example in attachment: Link (http://s000.tinyupload.com/download.php?file_id=02727082229894854150&t=0272708222989485415060246)

I've tested with 2 spheres with 2 4096x textures each, every time each one comes to play, there's a short freezing of the simulation.

I checked that this behavior doesn't apply when using the LWJGL Display combined with the preWarm, but when I'm using the Canvas generated by the "FrameBuffer.enableGLCanvasRenderer()" the preWarm seems to be ignored as you can check on this image below:

(https://i.imgur.com/stom68W.png)
Title: Re: Low performance when using uncompiled objects
Post by: EgonOlsen on November 19, 2019, 08:21:29 am
Oh, you are using the AWTJPCTCanvas renderer!? I wasn't aware of that, I always thought you were using the "normal" GL renderer. In that case, it's pretty clear that the preWarm doesn't help. That's because with the  AWTJPCTCanvas renderer, your application and the rendering are running in two different threads and your application can't access the GL context hence it can't execute preWarm directly and just ignores the call. I would have to make sure to push the preWarm() into the rendering thread's pipeline and execute it from there. I'll look at it.
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on November 19, 2019, 11:42:00 am
Yes, I'm sorry I wasn't clear about that.

Yeah, I'm using the separate canvas because I'm writing an editor tool with some AWT components on the side, so it helps using a smaller viewport mixed with other stuff.

and yes, I figured that was the reason, since there are no syncronization wit this component. Well, thanks a lot, if you need any help on my side, just let me know.
Title: Re: Low performance when using uncompiled objects
Post by: EgonOlsen on November 19, 2019, 07:49:46 pm
Please try this jar: https://jpct.de/download/net/jpct.jar (https://jpct.de/download/net/jpct.jar)

I've modified the behaviour so that prewarming should happen when using the AWTGLRenderer too. Please note that I've renamed the method World.compileAllObjects() to World.prewarmCompiledObjects(), because that's what it does. It doesn't actually compile anything but it uploads objects on which compile() has already been called.
Title: Re: Low performance when using uncompiled objects
Post by: Jakes on November 20, 2019, 11:33:27 am
It worked!

Finally I can run the simulation in a smoother way, and it keeps stable without any staggering along the way.

BTW, I'm only using the TextureManager.preWarm(), the World.prewarmCompiledObjects() for some reason changed my objects orientation, prolly because of the "building" process of those objects. I'll have a look into it afterwards.

But thanks again man, if you want to publish that I'll download the offical version from the site.

I think this thread can finally rest now after a month of intense testing.

Regards,
Jakes