Idea about improving the Loadscene command

full.metal.coder · Post by **full.metal.coder** » Wed Jul 30, 2008 8:12 pm

And where do we find this mechanism? Unless I am mistaken you are an admin of Irrlicht Sf.net project so you can easily commit any needed changes without having to wait for your patch being noticed so if you got something ready feel free to share it

hybrid · Post by **hybrid** » Wed Jul 30, 2008 8:41 pm

Unfortunately, the SF SVN commits don't have the idea-to-code interface implemented, yet. Hence, it's only possible to commit actual code.

But since this was a discussion about possible ways to do such things I thought to share ideas. If you just want to read about finished code, just skip such discussions.
BTW: I already commited your OnNode interface...

full.metal.coder · Post by **full.metal.coder** » Wed Jul 30, 2008 9:05 pm

It's alright. I just inferred from your post that you had something (at least almost) ready ("my async load mechanism") but if it is not the case it is still interesting to discuss the issue with more details.

As for committing my patch thanks for your quick action. There is a little problem left though, as I explained on the tracker : I uploaded a wrong version of the patch (the one before proper testing). It is required to move the OnCreateNode() call to the end of the readSceneNode() funtction for the handler to be useful (otherwise attributes are not handled and position/rotation/mesh/... are not set so the handler is much less interesting).

hybrid · Post by **hybrid** » Wed Jul 30, 2008 11:54 pm

Yeah, that was fixed. I hope it's not a problemt hat all children are loaded first now, but that's not easily avoidable IMHO.
I referred to a previous discussion about the async I/O, which the new thread now unfortunately missed. I think I explained some ways to change the usual mesh loaders to deferred loaders that time. There's not much sense in loading meshes only partially (at least it could be arbitrarily difficult to find proper breaks), but decoupling the loading mechanism can also help to offload some I/O to other threads, while the caching of Irrlicht could be done in a finalize step. Moreover, the deferred mechanism would allow for ressource saving and better load balancing.
But I guess the most useful application is for scene loading. I'll have to sketch some things first, but the basic idea is to use a proxy element which will hide the actual loader, and provides several ways to use the loader.
Maybe we should collect the requirements we'd expect from such an addition, and possible ways to solve those things.

sudi · Post by **sudi** » Thu Jul 31, 2008 9:48 am

well we could have some thread meshloading with smartpointers.
lets say the getMesh("blubb") return a smartpointer pointing to the mesh. well if the mesh is not really big it is directly loaded but if it is bigger it returns a empty smartpointer(pointing to NULL) then when the mesh is correctly loaded the smartpointer points to it. the scenenode would have to check if the smartpointer is already initialized or not and then accordingly set the mesh to display. same stuff with loading a scene/scene element. bc i guess loading the actual scenefile doesn't take really long it could be loaded diretly but the meshes and textures are all loaded like i described it above. or u simply return a dummyscenenode by loadScene which will then be used to attach the scenenodes of the scene file which are later loaded. anyway just some thoughts.

rubenwardy · Post by **rubenwardy** » Thu May 31, 2012 5:55 pm

hate to start an old thread, but has this been done yet?

If so, how do I use it

If not are there any tutorial / code i can use

REDDemon · Post by **REDDemon** » Fri Jun 01, 2012 3:50 pm

I have few ideas for loading scene in background. Simply extend event system with messages. When some data is loaded a message is sent to main loop to accept that data. Even chunks can use messages- > "LOAD_NEXT_CHUNK_EVENT", "FILE_LOADED_EVENT" etc...

in this way queue policy can be used. If multiple requests are sent, main loop will not freeze but will continue to stream certain request while all other messages waits for next loop etc.

Should be the right moment for redesign from scratch GUI and event system. Also had some idea about that ^^. I'm using similiar system with SDL and is working very well!
And there are also certain GL extensions that are already streamed by vendor's drivers so you can even send a whole texture or VBO to GPU that it will not freeze the scene. don't know if it will work for DX.

Jackie1234 · Post by **Jackie1234** » Sun Jun 03, 2012 5:33 pm

i have another idea to improve the loadScene command.
maybe it should have option to pass a parent scenenode to the loaded scene. that way u could use the the sceneformat to prepare probs for ur game then load them and have it seperate from the rest of the scene. so u could use it to setup particle system load them and directly have a handle to them. and when passing NULL as parent the scene is loaded like now.

I like this idea. Has he got a patch for this or is it planned ?

hybrid · Post by **hybrid** » Mon Jun 04, 2012 8:28 am

That's already integrated in the engine, but only as part of Irrlicht 1.8. So right now it's only accessible via SVN/trunk code.

Irrlicht Engine

Idea about improving the Loadscene command

Re: Idea about improving the Loadscene command

Re: Idea about improving the Loadscene command

Re: Idea about improving the Loadscene command

Re: Idea about improving the Loadscene command