jPCT - a 3d engine for Java > Support

Loading performance - Cotninuation

(1/2) > >>

Jakes:
Hello,

after the recent topic "Low performance when using uncompiled objects", the mais issue seemed to be the preWarming of textures, which seems to be solved.

Altought, when using a huge cluster of objects of the same type, there seems to happen a loading of some sort, while the console is outputting these:

Not a triangle strip at position 1!
Remapping 2022 vertex indices!
Creating vertex cache (48528 bytes)!
Vertex indices will be mapped!
Subobject of object 0/object2 compiled to indexed data using 4932/4932 vertices in 20ms!
Checking for triangle strip...
Compiling source object...
Checking for triangle strip...
Not a triangle strip at position 1!
Remapping 68 vertex indices!
Creating vertex cache (1632 bytes)!
Vertex indices will be mapped!
Subobject of object 2/object4 compiled to indexed data using 102/102 vertices in 2ms!
Object 2/object4 compiled to 1 subobjects in 2ms!
Object 5233/object5235 precompiled!
Compiling source object...
Checking for triangle strip...
Not a triangle strip at position 1!
Remapping 162 vertex indices!
Creating vertex cache (3888 bytes)!
Vertex indices will be accessed directly!
Subobject of object 6/object8 compiled to indexed data using 960/960 vertices in 5ms!
Object 6/object8 compiled to 1 subobjects in 6ms!
Object 5234/object5236 precompiled!
Object 5235/object5237 precompiled!
Delayed pre-warming done!
VBO created for object 'object5226'
VBO created for object 'object5220'
Compiled 2 VBO!
Object 'object3482' shares compiled data with object 'object11'
Object 'object4333' shares compiled data with object 'object11'
Object 'object3152' shares compiled data with object 'object11'
Object 'object4338' shares compiled data with object 'object11'
Object 'object2954' shares compiled data with object 'object11'
[x 1000 more]
...
Checking for triangle strip...
Not a triangle strip at position 1!
Subobject of object 5239/object5241 compiled to indexed data using 24/9 vertices in 1ms!
Object 5239/object5241 compiled to 1 subobjects in 1ms!
Object 5242/object5244 precompiled!
Object 5243/object5245 precompiled!
Checking for triangle strip...
Not a triangle strip at position 1!
Subobject of object 5246/object5248 compiled to indexed data using 24/9 vertices in 0ms!
Object 5246/object5248 compiled to 1 subobjects in 1ms!
Object 5249/object5251 precompiled!
Object 5250/object5252 precompiled!
Checking for triangle strip...
Not a triangle strip at position 1!
[x 1000 more]
...
Checking for triangle strip...
Not a triangle strip at position 1!
Subobject of object 5785/object5787 compiled to indexed data using 24/9 vertices in 0ms!
Object 5785/object5787 compiled to 1 subobjects in 1ms!
Object 5788/object5790 precompiled!
Object 5789/object5791 precompiled!
VBO created for object 'object5451'
VBO created for object 'object5409'
VBO created for object 'object5570'
VBO created for object 'object5598'
VBO created for object 'object5591'
VBO created for object 'object5731
VBO created for object 'object5444'
VBO created for object 'object5514'
VBO created for object 'object5647'
VBO created for object 'object5255'
VBO created for object 'object5696'
VBO created for object 'object5633'
VBO created for object 'object5521'
VBO created for object 'object5353'
VBO created for object 'object5773'
VBO created for object 'object5640'
VBO created for object 'object5549'
VBO created for object 'object5542'
VBO created for object 'object5710'
VBO created for object 'object5724'
VBO created for object 'object5479'
VBO created for object 'object5605'
VBO created for object 'object5689'
VBO created for object 'object5752'
VBO created for object 'object5703'
VBO created for object 'object5668'
VBO created for object 'object5654'
VBO created for object 'object5766'
VBO created for object 'object5759'
VBO created for object 'object5437'
VBO created for object 'object5528'
VBO created for object 'object5619'
VBO created for object 'object5500'
VBO created for object 'object5262'
VBO created for object 'object5311'
VBO created for object 'object5745'
VBO created for object 'object5465'
VBO created for object 'object5388'
Compiled 79 VBO!
Object 'object5301' shares compiled data with object 'object4'
Object 'object5623' shares compiled data with object 'object4'
Object 'object5595' shares compiled data with object 'object4'
Object 'object5588' shares compiled data with object 'object4'
Object 'object5448' shares compiled data with object 'object4'
Object 'object5462' shares compiled data with object 'object4'
Object 'object5315' shares compiled data with object 'object4'
Object 'object5700' shares compiled data with object 'object4'
Object 'object5567' shares compiled data with object 'object4'


during this period, a huge freeze starts and only stops after these have stop writing to the console.

The last JAR that was made to solve the preWarm issue, seems to lack the "World.compileAllObjects(FrameBuffer)" which I think could solve this loading process?

can you please add both changes to one last jar, if it's not too much trouble?

So my question is:
Could this be the cause?
If not, is there anything I can do before starting the scene to avoid this altogether?

I've even removed all the textures from my scene in order to dismiss this possibility, and it still happens, and the more objects I add onto the scene, the more this "loading period" takes. It's a bit nerve wracking because the number of objects is not that great and I'm not even in the middle of the development.

PS: I tried to use the "Config.glVerbose = false" to hide the previous log text, but it seems that some text is always being output, is it possible to reduce these info lines with an option? (any log describing the compilation process at runtime)

many thanks,

Jakes

EgonOlsen:
You can configure the logger in the Logger class. Just set the log level to something higher (like http://www.jpct.net/doc/com/threed/jpct/Logger.html#LL_ERRORS_AND_WARNINGS) and the messages should disappear. The compileAllObjects-method is still there, I've just renamed it so that it reflects better what it actually does. It's now called prewarmAllObject(<FrameBuffer>)

Jakes:

--- Quote from: EgonOlsen on January 19, 2020, 11:17:04 pm ---You can configure the logger in the Logger class. Just set the log level to something higher (like http://www.jpct.net/doc/com/threed/jpct/Logger.html#LL_ERRORS_AND_WARNINGS) and the messages should disappear.
--- End quote ---

Thanks, I'll give it a go.


--- Quote from: EgonOlsen on January 19, 2020, 11:17:04 pm ---The compileAllObjects-method is still there, I've just renamed it so that it reflects better what it actually does. It's now called prewarmAllObject(<FrameBuffer>)

--- End quote ---

Regarding this, issue, I've tried a lot of scenarios so far:

1. Creating all of the objects hidden, starting the scene with only 1 or 2 simple objects, wait like 5 or 10 seconds, and show all of the 4000 hidden objects: and this way no hiccuping happens at all, it works as if all of them were already loaded.

2. Creating all of the objects visible, starting the scene with 4000+ objects: The scene freezes and has huge frame drops for like 3 or 4 seconds.

3. Used the World.prewarmAllObjects(FrameBuffer) combined with TextureManager.preWarm(FrameBuffer) and here is where the weird behaviour starts as I'm describing below:

- If everything is processed quick enough, then nothing different happens, it loads, and there will be a slowing down of the simulation for 2 or 3 seconds before everything starts running smoothly, so nothing seems to differ when using the World.prewarmAllObjects(FrameBuffer).

But

- if I take longer, after the TextureManager.preWarm(FrameBuffer) which outputs the message "Delayed pre-warming done!" then this shows up on the log afterwards: "Compiling object object6278/com.threed.jpct.Object3D@2d12a01f!
[ Sun Jan 19 22:54:28 GMT 2020 ] - WARNING: Object object6278 hasn't been build yet. Forcing build()!" and nothing happens, as if the application just stops its cycle. and it freezes here forever:


is there anything that I could be missing? As I said previously, If I hide all the objects for a while and then show them up, everything seems to flow normally, but if they start out visible from the start, there will always be some slowness and freezing.

EgonOlsen:
Seems like a dead lock between the render and the main thread. Are you getting some messages like this:


--- Code: ---Waiting for renderer to initialize...<some number up to 50 here>
--- End code ---

?

Jakes:
No, it just freezes at that stage.

Compiling object object5811/com.threed.jpct.Object3D@63dbf1b0!
Compiling object object5813/com.threed.jpct.Object3D@7cd88d07!
Compiling object object5815/com.threed.jpct.Object3D@6d130699!
Compiling object object5816/com.threed.jpct.Object3D@7c165ec0!
Compiling object object5818/com.threed.jpct.Object3D@20a6cee5!
Compiling object object5822/com.threed.jpct.Object3D@27592d22!
Compiling object object5824/com.threed.jpct.Object3D@4fa2275c!
Compiling object object5829/com.threed.jpct.Object3D@1ec631dc!
Compiling object object5831/com.threed.jpct.Object3D@65f3724c!
Compiling object object5833/com.threed.jpct.Object3D@51d50fde!
Compiling object object5834/com.threed.jpct.Object3D@7b04e1ca!
Compiling object object5835/com.threed.jpct.Object3D@7d83d3de!
Compiling object object5836/com.threed.jpct.Object3D@59cad432!
Compiling object object5839/com.threed.jpct.Object3D@13314cac!
[ Thu Jan 23 00:18:27 GMT 2020 ] - WARNING: Object object5839 hasn't been build yet. Forcing build()!
[...Freezes Here...]


but this only happens when the loading process takes more time and this line appears:

Delayed pre-warming done!

so, what it looks like is, when this line shows up beforehand the precompilation of the objects, the whole program freezes.

I think it has something to do with that, other than that I cant really say.

Navigation

[0] Message Index

[#] Next page

Go to full version