Advanced scene loading

[Marleys Ghost]

I use it....

 

 

 

 

Yes ... you do which makes nearly all of the other waffle moot. Like I said I will stick to just using Loadscene() and not the 3x loop de loop you seem to enjoy which includes Loadscene() ... and you claim is faster than just using Loadscene()..

 

Is this another Ideological moment?

[Canardia]

Not sure why you don't understand the point. LoadScene() takes most time. The rest around it is minimal and not worth to mention, and only to mention since they actually make the game faster. If you want 0 loading times, you don't use LoadScene(), but make your own streaming loader. It's as simple as that.

[Marleys Ghost]

Not sure why you don't understand the point

.

 

 

 

The point is simply just using Loadscene is quicker than using Loadscene plus 2x loop de loops ... which you said was quicker.

 

Obviously its not.

[Canardia]

No, loop 1: 0.0000001 ms, loop 2: 5 sec, loop 3: 0.0000001 ms, loop 4: game loop: 20 FPS faster.

[Marleys Ghost]

No, loop 1: 0.0000001 ms, loop 2: 5 sec, loop 3: 0.0000001 ms, loop 4: game loop: 20 FPS faster.

 

 

You are funny Mika ... you do realise that 0.0000001 ms is 0.1 Nanoseconds, 0.1 one billionth of a second .. and ignoring your claim of a 20 fps increase in a "loop" that was not actually included in the topic, and your figures for how faster your code runs and does things, your own maths show its quicker to just do loop 2 than to do loop 1 + loop 2 + loop 3 or will you now tell me that 0.0000001 ms + 5 sec + 0.0000001 ms is less than 5 sec?

 

[Canardia]

The speed of the game is a very essential part, actually the most important part. Gamelib wouldn't need much of its own LoadMap, if LoadScene would clean up the mess it caused. Plus it doesn't load user made entities anyway, so even if the loading is 2ns slower, its worthless if you don't have all functionality.

[Marleys Ghost]

The speed of the game is a very essential part, actually the most important part. Gamelib wouldn't need much of its own LoadMap, if LoadScene would clean up the mess it caused. Plus it doesn't load user made entities anyway, so even if the loading is 2ns slower, its worthless if you don't have all functionality.

 

 

yeah well so you claim ... I will wait for the convoy of trucks carrying the sodium chloride shipment that I'd need to take with your claim of 2ns (originally 0.2 ns funny how facts and figures seem very fluid in your Ideologies) ...

 

But at least we now agree doing loop 2 on its own is quicker.

[Pixel Perfect]

Sadly I don't think these are considered to be bugs by Josh and will most likely never get done since he's doing LE 3 dev and I guess only bug fixes for LE 2.x?

I don't see a locked 'Feature Requests' section so I'm guessing the current version is still 'open for business' at Josh's discretion.

 

It would be nice though if we (the community) could come up with a better LoadScene() method.

Granted that would be nice, but why would we desire this to be the preferred route over Josh improving the existing one. Why would Josh not want to do this for us if there is a real need for it. Version 2.4 is the current stable product and likely to be the only one for the next year and the very people working with the current engine are likely to form the bulk of the first ones to invest in the new one. Does he not have our interest at heart! Would it really take so much time out of his current development schedule to add a call-back function to LoadScene(). It would only need to pass the total number of items to be loaded and the current count. The Editor could update the SBX file with the count so the LoadScene function wouldn't even need to fully parse the file to obtain this (not that that takes long anyhow).

 

I guess I just prefer the solution to be applied to the source of the problem unless that proves impossible.

[Josh]

I think there are easier ways to clean up those hidden models. You could set a global Lua variable and add some code in each script to self-delete the model after it's done loading, if the condition is true. Or if you don't feel comfortable with that, set a key in the script like "deleteme"="1", and then have a recursive function in your program that scans the scene hierarchy and deletes those models (after unparenting the model's children).

[macklebee]

Is there really that many hidden or dummy meshes in a scene to even worry about it or make the claim that it increases the fps by 20 by taking them out? Most objects in a scene do not have these dummy meshes, only things like lights, emitters, coronas and the occasional thing like the atmosphere object. And they can easily be added to the object that they are emanating from... so personally do not even see the need. Of course there is always the person who apparently is making a scene with 1000 individual pointlights objects in one scene where all the lights can be seen at one time and are not emanating from an obvious light source like a lamp or bulb, where it might be helpful to remove the dummy meshes... But smartly build your scene in the first place then you shouldn't have these problems.

[VeTaL]

IMO, one of the best solution is just to save number of objects at the beginning of sbx file, so there would be no need to run through it for the first time.

[Josh]

Is there really that many hidden or dummy meshes in a scene to even worry about it or make the claim that it increases the fps by 20 by taking them out?

I don't think there is any significant performance loss. I wouldn't worry about it one bit.

[Rick]

I don't think there is any significant performance loss. I wouldn't worry about it one bit.

 

 

I think it depends on how you use this. If you go the route of "Thingoids", reusable Lua "objects", then you could potentially end up with a bunch of junk models hanging around that aren't needed. This is one of the reasons it doesn't make sense to require a script be attached to an actual model. There should just be "game objects", which aren't models, that you can attach scripts to. With this approach a complex scene could end up with a ton of these dummy models, and could affect the fps. Then again, you could probably just hide the mesh, but they would still be taking up memory, probably not much, but they still wouldn't be needed.

 

When I was doing my Thingoids I had probably 15 (?) in one very very basic scene. Add to that the other LE entities like lights and such and it was probably like 20 in a scene that took about 20 seconds to get through. These were basic Thingoids too. No AI stuff, so a scene for a AAA game could end up with a good number of pointless models.

 

It is what it is today, but it could have been and can be made in a better way.

[Josh]

Those models are invisible and don't collide. They won't even get iterated through in the renderer or physics.

[Rick]

That's good to know, but I assume that's only because we have to apply the invisible.mat to them. I assume they still take up memory(probably not much though)? Either way they become useless, and it's kind of a pain to have to copy over those models to each new Thingoid I make knowing it's kind of pointless.

[AggrorJorn]

one other problem I have is that I that the scene loads rely quick. That would indicate that there is no time to even show a loading screen. Yet the previous scene is still there. Freeing a scene goes way slower then loading a new scene. So what I am going to do for now is checking whether the previous scene is completely empty and then remove the screen.

[Canardia]

You should do it like in Crysis: show the loading screen until the user presses space. The text to press space comes only after the level is loaded. It's a great idea, because you can take a break during the loading screen, and when you come back you don't miss the cutscene and don't get shot when the next level starts because you are AFK.

[Rekindled Phoenix]

Can't we call LoadScene() and either...

 

1. Cycle through another loop as a separate thread waiting for a callback to tell us the scene has loaded all necessary layers.

 

or

 

2. Allow LoadScene to display a predetermined loading screen specified to the engine by a property / MAT object.

[AggrorJorn]

Well there are many ways to handle this and that is probably the reason it doesn't exist yet. But the thing Lumooja suggests isn't a bad idea. Let the program hold until a key is pressed. The disadvantage to this in my opinion is that you have to manage your scene more by code then letting the editor taking care of it. Sounds in the level start to play as soon as they are loaded. you would have to look up all sounds and set them to a low volume. If your game has some kind of camera path animation that starts right at the beginning then you need to trigger this after the key is pressed instead of when the level is done loading.

[Rekindled Phoenix]

I really wish this was a Native feature to the LE engine. I hate waiting for all of the assets to load as my thread sinks into unmanaged code (compared to .Net "managed" DLLs). There is no way I can make an additional render call by another thread without throwing an exception.

 

 

Josh, is and updated LoadScene() this something that will be fixed for 3.0?

[ZioRed]

Yes I agree that a deeper management of the scene loading should be implemented, e.g. Unity's Application scene loading methods seem useful for this and it would be nice if we had something similar too (loading async/additive and get loading progress percentage).

[Wchris]

Those models are invisible and don't collide. They won't even get iterated through in the renderer or physics.

can someone confirm this ?

i'm pretty sure in 2.4 i could collide with the athmosphere and lights bodies with debugphysics enabled.

[Rick]

I actually remember being able to collide with them in the past also. Not sure if it's been fixed or not.

[Rekindled Phoenix]

I may have a solution for those who use .Net to call LoadScene() and render with a progress bar without using custom OpenGL calls.

 

I shall post more tonight later when I have time.

[AggrorJorn]

Yes I agree that a deeper management of the scene loading should be implemented, e.g. Unity's Application scene loading methods seem useful for this and it would be nice if we had something similar too (loading async/additive and get loading progress percentage).

Looking at those methodes I say that that is exactly what is needed here. A couple of commands that allows the program to have more control and values available to see what is going on with the scene loading. Here is the suggestion:

 

- LoadScene ( scene ) //load the scene
- IsSceneLoading ( boolean) //returns true or false whether the scene is still loading and/or previous scene is removed yet.
- GetLoadingProgress (integer progress) // returns the percentage of what is loaded.