Access Information and Version Support
Virtually all of the HOOPS/3DGS, HOOPS/MVO, and HOOPS/Stream APIs are available and behave in a platform-independent fashion, consistent with HOOPS' design as a platform-independent API. Any limitations are covered below.
- General notes
- iOS 5.X and higher is supported on iPad, iPad2, iPad3 and iPhone4/4s/5 hardware, using the Xcode 4.0+ toolset from Apple.
- The 3DF libraries are provided via a single static library which contains the HOOPS/3DGS, HOOPS/MVO and HOOPS/Stream components, and located at [hoops]\dev_tools\hoops_ios\lib (both the native ARM library for the actual devices, as well as the x86 emulator library are provided).
- A simple HOOPS-based iOS demo application has been provided in the package for Visualize 19.24 and higher. Its source code and project file is located in [hoops]\demo\ios\ios_simple. This application is for demonstration purposes only and is not necessarily intended to be a starting point for your own iOS application. For more information, see the iOS section of the prototyping page.
- The OpenGL2 Driver documentation lists current HOOPS/3DGS driver limitations.
- HOOPS/MVO-specific notes
- touch-interface support is provided via HTouchManager, along with touch-enabled variants of several operators, including HOpCameraManipulateTouch, HOpCameraPanTouch, HOpCameraZoomTouch
- touch-enabled variants of the markup/construct/create/markup/object operators are NOT currently provided. These include: HOpMarkup[type], HOpConstruct[type], HOpCreate[type], HOpObject[type]
- Developers should refer to the src for the 'touch' enabled operators listed above, as well as HTouchManager, in order to create their own custom-behaving touch-enabled versions of GUI handlers in the list above. Core annotation and markup creation/save/restore functionality is still provided (via HUtilityAnnotation and HMarkupManager).
Development Notes
Developers wishing to prototype and develop HOOPS-based iOS applications must first become familiar with OSX development fundamentals, iOS app-development, and the array of platforms constraints: limited screen real estate, reduced CPU/GPU power compared to desktops/laptops, limited amount of flash-memory, lack of a hard drive, absense of a conventional file system, side-loading of files, iOS GUI application development, application distribution, and so on. Please remember that HOOPS/3DF strictly provides SDK-level classes and subroutine libraries to enable you to build custom 2D/3D interactive applications, and does not include end-user apps that can be OEM'ed or redistributed. Some HOOPS usage guidelines for iOS:
- Scene-graph organization: Ensuring that you have a well organized (optimized) scene graph is essential to reduce memory usage, thereby allowing you to load larger models as well as boost performance. See Segment Organization for further details.
- Rendering settings: using the appropriate rendering settings for items such as 'display lists', 'polygon handedness' and 'backplane culling', will help ensure maximum performance. See Rendering Performance for further details.
- Fixed framerate: we have been encouraging developers to prototype and incorporate this technique for a few releases now, and it will probably be particularly important to leverage under iOS. This technique allows you to set a specific framerate (along with very useful extent-culling), thereby ensuring a specific framerate independent of the model complexity. HOOPS/MVO provides high level support for fixed-framerate, while the underlying HOOPS/3DGS capability of time-bounded-updates provides core support.
- Memory usage: Your application logic needs to manage/track its memory allocation/usage (it's not done automatically by the Operating System), and your application's usage of any sub-components such as HOOPS has the same needs. For example, if you load 'too large' a model(s) into HOOPS, relative to the available system memory, HOOPS will simply continue to populate its scene graph and the required memory allocations will eventually fail, resulting in an ungraceful exit/crash. While this is the situation on any Operating System with finite memory, the 'memory wall' on iOS devices is much closer than on, say, a 64-bit OS with 4GB of memory. Please refer to the Programming Guide entry on Memory for some guidelines on memory-usage tracking and memory conservation.