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

Found it!

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

Here is my test example in attachment: Link

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:

...It might be better to create different animations out of the individual frames and do the blending. You can reuse the frames, so it's not a memory issue.

thanks, will try out that.

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.

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?

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?)

Just as the topic subject says, is it possible to add this in a near future? or is there a way to do it currently?

Regards

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.