The first time SCNView renders a scene is very slow - ios

I want to load Collada files dynamically in SceneKit at runtime. I have used copySceneKitAssetst to generate the .DAE file and put it my server. The app can download it from the server and use this file to init a SCNScene (refer to http://www.the-nerd.be/2014/11/07/dynamically-load-collada-files-in-scenekit-at-runtime/).
There is no error when executing "./copySceneKitAssets" and the models can be rendered properly. I have called [scnView prepareObject:gameScene shouldAbortBlock:NULL] before setting gameScene to the scnView.scene.
The problem is that the first time scnView renders the gameScene, its very slow (a few seconds). Even the main thread is blocked during this period which means UIs cannot refresh,h and sometimes the app is killed by iOS.From the second time it renders the scene,it's very fast and main thread works well.But if we delete the App and reinstall it,the problem comes again.
Any help is appreciated.

I think prepareObjects(_:withCompletionHandler) (defined on SCNSceneRenderer) is worth a look. It loads resources on a background thread.

Related

GLscene - Long delay between adding scene objects and scene appearance

I have a routine which adds a few hundred (mainly TGLextrusionsolid) objects into the scene.
The routine loads all the objects into GLscene with no problems in a few milliseconds but after exiting the loading code and allowing entry back into the main processing loop the program hangs for several seconds.
I presume this is caused by GLscene building the scene in its internal routines.
Once the scene appears on the screen after a few seconds, everything is fine, it can be rotated and zoomed at full speed.
Is this long delay between loading the objects and the scene apearing on screen normal?
Is there any way to stop it hanging the main thread whilst its doing its stuff?

Architecture of a SceneKit game, multiple view controllers for menu screens?

I'm working on a SceneKit game using Swift, and I'm thinking about the best way to organize the various screens/ states surrounding the actual main game scene. I have a simple prototype which consists of three states:
Splash Screen (choose game type) ->
Game ->
Game over screen (choose to play again or return to splash)
In the prototype I opted to go for UIKit to do the UI elements, rather than a SpriteKit overlay. Although it's just buttons at the moment, which would be easy enough to do in SpriteKit, I might in future want to add sliders (eg an options screen to set control sensitivity etc), text entry etc, and then you end up recreating great chunks of uikit.
So at present, each of the 3 scenes described above has its own UIViewController. The Splash and Game ViewControllers have their own SCNViews and SCNScenes, and the GameOver is a modal that displays over the main Game scene.
This structure isn't really ideal, as it means that the main game SCNScene gets reloaded whenever the viewDidLoad of the GameViewController fires. The main SCNScene is quite detailed so takes a few seconds to load, and with repeated cycles this seems to create memory issues. After 2 cycles of Splash -> Game -> GameOver I get a memory warning, and after the third cycle Xcode loses the connection to the iPhone (which seems, in my experience, to be caused by memory issues).
I would like to have a main GameViewController that loads the most frequently reused assets once, but still be able to segue between the various menu screens.
So what are the options here?
I thought perhaps I could have a main GameViewController which controls the loading and unloading of SceneKit assets and has the sole SCNView. Its viewDidLoad method would only be fired once, when the app first starts. Then, each of the other views would have a very minimal UIViewController, which would be presented as modals over the main GameViewController, with "OverCurrentContext" selected.
I wanted to ask whether this pattern sounds feasible, and how others organise their SceneKit games. I'm still quite new to native iOS development, so it could be that I'm missing some basic game design pattern.
My Experience with the use of only one GameViewController (my current work for MAC OS X: i started a a 'small' 3D game with a MainMenu/start screen, a Hud and 2 or 3 complete different 3D Scenes - this shall be ported then to IOS, too):
In the last week i tried what you asked for, to use only one GameViewController for "all" that stuff - for me it seemed to be the easy and "good" way to do it - but even after lot of hours with all my tricks I've learned the last years i was not able to reload load another (or change) 3D scene (or even not another sprite kit scene hud) after a scenekit scene is loaded in a single ViewController.
Maybe there is difference between MAC OS X and IOS but i even tried this in an iOS version and it has the same behavior.
What i was able to do: You can modify a loaded 3D scene or change data in the sprite kit hud etc., so you are able to use one 3d scene to add or show the things up when they are needed but as far as my tests here showed, you will need one ViewController to show up a complete new different 3d scene or 2d/3d Menus etc. I will post my further experiences as soon as I'm a step further. i hope this helps a little.

Problems going back and forth between scenes (Sprite Kit)

I am new to the iOS platform and have written an app using Sprite Kit and Xamarin. To transition between scenes I am using NavigationController.PushViewController with a "Back" button on the new scene to return. This works fine.
My problem occurs when I go back and forth between the original scene and next scene about 3 times. The frame rate (and overall application) slows to a crawl, and depending on which scenes, will hard crash. This happens only on device and not in the simulator. My gut instinct says I'm leaking memory somewhere / not cleaning up properly, so I have just started getting up-to-speed with Instruments. Note that each scene has about 5-8 images on it.
Questions:
What is the proper way to clean-up after transitioning out of a scene back to the previous one? I am explicitly calling RemoveAllActions() and RemoveAllChildren() to ensure clean-up.
What is my best strategy when using Instruments? I've only just begun to experiment with an Allocations trace, but there are a lot of allocations and knowing what to look for is challenging.
Any help is appreciated. I am considering dumping Sprite Kit altogether since my app doesn't really need it (I wanted to experiment) and because it has been a challenge building the app with all kinds of deep crashes (e.g. SKShapeNode, which is very problematic).
Thanks.

How to implement a loading screen using storyboard?

In a Corona app using the storyboard library, what are the best practices for adding a loading screen between scenes? I'm guessing it should go somewhere in scene:enterScene() but I'm not sure how to make it work with Corona's rendering process. As I understand it, if I do the following, the loading screen would never be displayed since Corona waits until the code path has finished and then draws everything at once.
function scene:enterScene( event )
showLoadingScreenOverlay()
loadEverything()
hideLoadingScreenOverlay()
end
Is the correct approach to create a new storyboard scene for the loading screen itself? If so, how can I load the other content in the background while the loading scene is displayed?
In your case, you should be using loadScene():
http://docs.coronalabs.com/api/library/storyboard/loadScene.html
This will only call the createScene part of your new scene2...
Then what you could do is update loading progress in the createScene of scene2, and verify every x milliseconds in your original scene1 the loading progress. When it is 100%, just call goToScene in scene1 and it will load scene2 instantly.

Application shown but not responsive for up to 5 seconds prior to calling applicationWillEnterForeground

While attempting to optimize load speed I started placing timers in different places and looking at the performance. The app uses OpenGL and Core Data and has a decent amount of screens and artwork.
But the largest part of the lag seems to be taking place prior to applicationWillEnterForeground (assuming it's not a cold load)
The app shows up and is displayed and the UI is unresponsive for close to 5 seconds. I start a timer and print a time as soon as I can press a button. The time between applicationWillEnterForeground and when I can press the button is 200 milliseconds.
What can be causing my application to be slow to load prior to applicationWillEnterForeground or what can I do evaluate what is happening there? Instruments does not seem to display any information about that part of the launch.
Other testing app I have don't seem the same performance. Is it the bundle size or the amount of memory used by the application? Loading dynamic libraries?
This was related to OpenAL. The app was not closing the OpenAL context and for some reason this caused considerable problems when closing and reloading the app. The app uses CosCos Denshion so I to make sure to call these.
[CDAudioManager end];
[SimpleAudioEngine end];

Resources