First, many thanks to Momoko_Fan for the improvements from jME 2.0.1 -> jME 3, i played a bit around with it's code.
And I noticed that there won't be Multihreading supported from core (What's not bad, but…), so I wanted to ask what kind of Concurrent Framework/Layer/API, will you provide?
I added a Layer on jME 2.0.1, wich supported Multi-threading (I used 3 update-threads, 1 Render-thread, 1 Physics-thread), but it was only abled to Render effectivly Immutable Trimeshes (only Location/Scale/Rotation were allowed to change) multithreaded.
Since it's still in progress (I want to add support for double-buffering Trimesh-data to support nearly all Meshes), I wanted to synchronize myself with the current progress in jME3 about Multithreading.
Many Thanks!
Tim
Multithreading in the core doesn't make much sense… Where are you gonna put it?
I was thinking of doing several things, where first things have higher priority:
- audio runs in seperate thread
- asset loading runs in multiple threads
- skinning/animation runs in multiple threads
- video/rendering runs in seperate thread
As you can see, #4 is last, because its harder to implement and to me doesn't seem like it would yield significant benefit. However recently people are saying an engine can't be termed "multithreaded" if it doesn't have #4…
Actually jME3 already supports threaded asset loading. There's a test for it albeit it doesn't work right now cause it needs a list of assets and these constantly change from revision to revision.
I'm curious about multithreaded asset loading.
Isn't it that you need to block on the GL Thread in order to load textures and display lists or anything to the graphics adapter?
Do you need to make sure this is not done in the middle of a render process or it doesn't matter?
When loading assets, what kind of operations get benefitted (I guess it's I/O and maybe some model loading maths)?
(This topic is a bit obscure to me, so please don't hesitate to develop on the thing).
jjmontes said:
Isn't it that you need to block on the GL Thread in order to load textures and display lists or anything to the graphics adapter?
You don't need to interact with GL if you're just loading textures, models and the like. But to use them yes you do need to upload them to the video card first, but that obviously can't and will not be multithreaded. In jME1/2 this wasn't possible without a great deal of hackery because model loaders were dependent upon the DisplaySystem and Renderer objects being accessible, in jME3 asset loaders are standalone and don't need access to any rendering-related systems to work.
jjmontes said:
When loading assets, what kind of operations get benefitted (I guess it's I/O and maybe some model loading maths)?
Well first of all I/O, then there's compression (if using jME3 packfiles), and then there's parsing. Additionally if you have multiple cores and multiple threads you can load several assets simultaneously which gives a nice performance boost. Thus even if you use loading screens (e.g no dynamic loading) you can still benefit a lot from threaded asset loading if the machine has multiple cores.
Well i would say that multi threaded loading and an own physic update thread are the most important things.
For the first one you an see the benefits greatly in any Ut3 Engine game, wich just loads the minimum needed, and then load higher detail version of models/textures as far as the System supports it.
The question here is, how much is the time difference between loading model x and the time needed to upload data when it is already processed.
The benefit of a own physics thread is obviously I guess, however that is also possible with JME2 mostly, if you use a own Physic-System, wich does not change anything, but adds the changes to the GameTaskQueue, that way the complex calculations are done in a seperate thread. But it seems like a lot of one time objects are created every time the physic updates, maybe we can find a way to reuse them?
Momoko. Thanks for the clarifications. Sounds very reasonable and promising.
Empire Phoenix said:
complex calculations are done in a seperate thread. But it seems like a lot of one time objects are created every time the physic updates, maybe we can find a way to reuse them?
I don't know if there's other better approach than queueing changes, but if done that way then I agree that object creation needs to be avoided. Maybe some kind of circular list can be used? In any case, I think that having such a system may assist the development of some networked games (as a lateral benefit).
I wonder if that is a common approach in commercial/high-end game engines.