|
SilverLining
|
If you receive this message when you run your application that links in SilverLining, it's due to a mismatch between the dynamic runtime libraries we linked SilverLining against, and the dynamic runtime libraries installed on your system.
One solution is to ensure you have the most recent service packs installed for Visual Studio, and run Windows Update to apply any security patches that have been released since then. SilverLining is always linked against the latest updates from Microsoft. Be sure to install the latest redistributable dependencies from Microsoft with your application, to prevent this same issue on your user's systems.
An even better solution is to avoid the dynamic dependencies on the Visual Studio runtimes altogether. If you can, set your project settings to use the non-DLL versions of the runtimes. You can change this under the 'runtime library' property under the C++ / Language Settings property page. You may then link in the non-DLL versions of the SilverLining libraries as well,and avoid what's commonly known as "DLL hell" by statically linking the correct runtime directly into your application.
Another solution, if you have a full-source license for SilverLining, is to recompile the SilverLining libraries from source. That will cause them to link against whatever runtime libraries are installed on your system, which should also solve this issue.Again, if you're using the DLL runtimes, it's critical that you redistribute the same runtimes with your application.
Under Windows, there is a very good chance that you are linking against a different C++ runtime library than SilverLining wasbuilt against. Crashes inside an iterator or a mutex object inside of SilverLining are indications that this is what's going on. This sort of trouble can result when you are using the "ignore specific libraries" linker setting to work around linker errors from other third party libraries you are using.
Usually, this can worked around by ignoring the "msvcrt" variant that is causing trouble. Which one will depend on your specific configuration. For example, one customer who had trouble using the Multi-threaded debug (non-DLL) runtime was excluding libcmt.lib to work around other linker issues with the C runtime libraries, and got up and running by excluding msvcprtd.lib.
If you're using the evaluation version of the Windows SDK, SilverLining will display a dialog box when the Atmosphere constructor is invoked, warning you about the time restriction on the SDK. If you instantiate your Atmosphere object after your application is in full-screen mode, some applications will not be able to handle a dialog box being displayed while full-screen mode is active. To work around this, instantiate your Atmosphere object before entering full-screen mode.
If you are experiencing a crash the first time you call Atmosphere::DrawSky(), odds are you are calling DrawSky()from a different thread and/or rendering context than the one that was active when Atmosphere::Initialize() was called. Initialize(), DrawSky(), and DrawObjects() should all be called from the same context, and you should maintain individual Atmosphere objects per context.
Another situation may be OpenSceneGraph applications running with multiple monitors. The only OSG sample included with the SDK that handles multiple windows is the "OpenSceneGraph MultiWindow" example; please refer to it for guidance in using SilverLining in multi-window setups.
There are several cases that might cause the initialization of SilverLining to fail; here are the error codes returned from Atmosphere::Initialize for each:
E_RESOURCES_PATH_INVALID: This error will occur if the file SilverLining.config could not be opened within the resources path you specified in your call to Atmosphere::Initialize(). Usually, this means that your resource path is incorrect. Make sure the backslashes in your path are escaped, and that your path includes a trailing backslash, and double-check that the path you specified exists. The SilverLining SDK will be installed to different paths depending on whether you're on a 32-bit or 64-bit OS, for example.
E_CONFIGURATION_FILE_NOT_FOUND: If the file SilverLining.config within your resources directory could not be parsed for any reason, this error will be returned. Generally, this means the config file has been modified incorrectly or is otherwise corrupt.
E_CANT_LOAD_RENDERER_DLL: SilverLining will construct a path to the appropriate renderer DLL based on whether you're using DirectX or OpenGL, your Visual Studio version, and 32 or 64 bit builds. These DLL's are stored within your resources directory; an example path might end up being resources/vc10/win32/SilverLiningOpenGL-MT.dll for instance. If the renderer was unable to load this DLL at runtime, then this error will be returned. If you haven't moved these DLL's out of this location and you are specifying a valid value for the renderer parameter of Atmosphere::Initialize, please contact suppo.nosp@m.rt@s.nosp@m.undog.nosp@m.-sof.nosp@m.t.com and indicate what renderer you're using, what version of Visual Studio, and whether you're using 32 or 64 bit versions of our libraries. Also send us a copy of your call to Atmosphere::Initialize().
E_CANT_INITIALIZE_RENDERER_SUBSYSTEM: This means SilverLining was unable to get some basic information from OpenGL or DirectX and was unable to set up its buffers for rendering to textures. Usually, this means you called Atmosphere::Initialize() before your rendering context was set up, or from outside of your rendering thread altogether. Be sure you're within the context you intend to use for rendering when calling Initialize(). SilverLining also requires a lockable backbuffer, if you're using an engine that does not provide this (such as Ogre3D,) set the render-offscreen setting in resources/Silverlining.config to "yes" to disable direct use of the backbuffer.
E_CANT_LOAD_METABALL_TEXTURE: This error will return if the file wispy-metaball.tga could not be loaded from within your specified resources directory path. Contact suppo.nosp@m.rt@s.nosp@m.undog.nosp@m.-sof.nosp@m.t.com if you haven't moved or modified this file.
Be sure to call Atmosphere::SetUpVector() and Atmosphere::SetRightVector() prior to calling Atmosphere::Initialize() so we know which way is up. Also, take care in setting the handedness parameter of Atmosphere::Initialize.
SilverLining assumes that the current modelview and projection matrices represent your camera's view when Atmosphere::DrawSky() is called. Some engines will reset their modelview and projection matrices outside of their own internal rendering code. When this happens, your sky will appear static or won't be in the right place at all. You may need to explicitly obtain your modelview and projection matrices, and set them directly via OpenGL or DirectX prior to calling Atmosphere::DrawSky().
Having too many cumulus congestus clouds in a scene tends to be the main performance hog; the first thing you should do is ensure your cumulus congestus cloud layers aren't bigger than they need to be. The number of clouds we need to render increases with the square of the size of these layers. Reducing the density of these cloud layers will also help.
Beyond that, there are several settings in the file resources/SilverLining.config that you can adjust, in order to make your own trade-offs between performance and visual quality.
Start with the setting cumulus-congestus-voxel-dimension. The bigger you make this, the fewer voxels will be required to render each cumulus congestus cloud. Increasing this will help quite a bit, but the clouds will look a little less complex as a result.
If you are using stratocumulus clouds, their bottleneck is fragment processing - the resolution of the display will affect performance more than anything. You can tweak performance by adjusting the preprocessor definitions in the stratocumulus shaders themselves - open them up from the resources/shaders file for the renderer you are using, and you'll see ways of adjusting the sampling rates at the top of the shader. Switching from STRATOCUMULUS to STRATOCUMULUS_PARTICLES will also help a great deal with performance if you need large cloud layers.
If your viewpoint changes slowly, configuring SilverLining to use impostors more aggressively may help quite a bit. By default, the setting of cloud-backdrop-distance is set to a distance of 50km. Bringing this in closer to the camera will cause more cumulus clouds to be rendered to a ring of impostors surrounding the camera, which can yield big framerate improvements.
cull-interior-voxels will prevent SilverLining from rendering voxels that are unlikely to be visible, and helps a little bit as well.
Finally, if you notice a slowdown only when the sun is in view, this is probably due to the occlusion test being done to prevent the sun from producing lens flare when it's occluded by clouds or other objects. If you can live without that test, setting lens-flare-disable-occlusion = yes will help a lot (in Resources/SilverLining.config). If you're using OpenGL you can configure SilverLining to use asynchronous pixel buffer objects for this task, by setting lens-flare-use-pbo = yes. This will let you have occlusion tests on the sun for lens flare, but without blocking. This may cause issues if you are doing deferred rendering to a texture however - in that case, you're better off disabling lens flare occlusion entirely.
This seems to be an issue specific to older NVidia drivers, related to our use of vertex buffer objects. To work around this, either update your drivers, or set the environment variable SILVERLINING_NO_VBO to 1 on your system (and restart your development environment to pick it up.)
Try opening up the file resources/SilverLining.config in a text editor, and set "disable-shaders" to "yes". Although we test SilverLining on a wide variety of systems, our shaders will sometimes compile in unexpected ways on new hardware we haven't encountered yet. Disabling shaders will cause SilverLining to fall back to more compatible methods of transforming its vertices, at a slight performance cost. If you run into this situation, please contact suppo.nosp@m.rt@s.nosp@m.undog.nosp@m.-sof.nosp@m.t.com with your system information (especially what graphics card you're using) so we can support shaders on your system going forward.
If you're using a geocentric coordiante system ("Earth Centered Earth Fixed"), be sure to read the section Using SilverLining in Geocentric or ECEF (Earth Centered Earth Fixed) Coordinates for important information on how to position cloud layers in these systems.
Some users render everything relative to the eyepoint. This causes problems, since SilverLining assumes that the modelview matrix you pass in represents the camera location and rotation, and that this matrix is consistent with the matrix OpenGL or DirectX is using for drawing. The best way around issues like this is to push your own special modelview matrix onto the stack using glPushMatrix prior to calling Atmosphere::DrawSky or Atmosphere::DrawObjects, then construct an equivalent modelview matrix that assumes the origin is at (0,0,0) instead of the eyepoint. Such a matrix will include the camera rotation and translation. Make this new matrix your modelview matrix, and pass it into Atmosphere::SetCameraMatrix - then call Atmosphere::DrawSky or Atmosphere::DrawObjects, and then restore your original modelview matrix prior to doing your own drawing.
Atmosphere::DrawSky() and Atmosphere::DrawObjects() will render to any render targets currently active at the time. If you need to render only to specific render targets, you'll need to edit the fragment shaders inside the resources/shaders directory. OpenGL 2.0 shaders have a -frag.glsl15 extensions, and DirectX shaders have a .fx extension. Under OpenGL, you'll want to replace our assignments to gl_FragColor with specific elements of gl_FragData[] instead. In OpenGL, you can do this in one place within the UserFunctions-frag shader file (use glsl for OpenGL 2, and glsl15 for OpenGL 3) in the writeFragmentData function.
Send us a note at suppo.nosp@m.rt@s.nosp@m.undog.nosp@m.-sof.nosp@m.t.com. Even if you haven't purchased a license yet, we'll do what we can to help get you up and running.
1.9.6