Unit VRMLRendererOptimization

Parses and removes from Parameters[1]..Parameters.High parameter --renderer-optimization, and sets RendererOptimization to the value specified by user.

Doesn't change RendererOptimization if command-line option not specified.

See view3dscene documentation [http://vrmlengine.sourceforge.net/view3dscene.php] for description.

Describe what parameters are parsed by RendererOptimizationOptionsParse. This is nice to use e.g. in help text (e.g. the one printed in response to "--help" command-line parameter).

Convert string S to a TGLRendererOptimization value. Raises exception if illegal value of S.

For a list of allowed values run [http://vrmlengine.sourceforge.net/view3dscene.php] with --help (or just look at the implementation of this unit :)

This is used by TVRMLGLScene.Optimization to describe what kind of optimization should be done.

Values

• roNone: No optimization. No OpenGL display lists are constructed. So calling PrepareRender and ChangedAll is very fast. On the other hand, rendering is significantly slower, as display lists often help a lot.

  Use this if you plan to change the scene at runtime a lot (or when you're going to render TVRMLGLScene object very few times, say, only 1-2 frames, in some special situations) Then building display lists would be only a waste of time, since they would have to be rebuild very often.

• roSceneAsAWhole: Treat the scene as a one big static object. One OpenGL display list is used, that renders the whole object. This is great optimization if the scene is static (otherwise rebuilding display lists too often would cost too much time) and you're sure that user will usually see the whole scene (or just a large part of it).

  Note that this nullifies the purpose of TVRMLGLScene.RenderFrustum and TVRMLGLScene.RenderFrustumOctree methods. And the purpose of the TVRMLGLScene.Render method with a parameter <> Nil. That's because the scene will always be rendered fully to OpenGL.

  Also, this is not good if some parts of the scene cannot be put on display list. This concerns things with TVRMLShapeState.EnableDisplayList = False, which currently means only MovieTexture nodes. TODO: we should fallback to roSeparateShapeStates automatically in such cases. For now, this will result in MovieTexture nodes being static (i.e. movie will not play).

  If the scene is static but user usually only looks at some small part of it, then building octree for the scene and using roSeparateShapeStates and TVRMLGLScene.RenderFrustumOctree may be better.

• roSeparateShapeStates: Build separate OpenGL display list for each TVRMLShapeState on list TVRMLScene.ShapeStates. Use this if

  1. you will change from time to time only some small parts of the scene (since this will allow to rebuild, on changing, only some small display lists, as opposed to roSceneAsAWhole, that has to rebuild large display list even if the change is very local).

  2. and/or you know that usually user will not see the whole scene, only a small part of it. See TestShapeStateVisibility parameter of TVRMLGLScene.Render and TVRMLGLScene.RenderFrustum and TVRMLGLScene.RenderFrustumOctree.

  3. Another advantage of roSeparateShapeStates is when you use TVRMLGLAnimation. If part of your animation is actually still (i.e. the same ShapeState is used, the same nodes inside), and only the part changes — then the still ShapeStates will use and share only one display list (only one — throughout all the time when they are still!). This can be a huge memory saving, which is important because generating many display lists for TVRMLGLAnimation is generally very memory-hungry operation.

     You can achieve even much better memory saving by using roSeparateShapeStatesNoTransformation.

     This is achieved by TVRMLOpenGLRendererContextCache methods ShapeState_Xxx.

• roSeparateShapeStatesNoTransform: This is like roSeparateShapeStates but it allows for much more display lists sharing because it stores untransformed ShapeState in a display list.

  Where this is better over roSeparateShapeStates: If you use TVRMLGLAnimation when the same ShapeState occurs in each frame but is transformed differently. Or when you have a scene that uses the same ShapeState many times but with different transformation. Or when you do animation by VRML / X3D events that change properties of "Transform" node. Actually, "transformation" means here everything rendered by TVRMLOpenGLRenderer.RenderShapeStateBegin, which includes modelview transformation, texture transformation and all lights settings. In such cases, roSeparateShapeStatesNoTranform will use one display list, where roSeparateShapeStates would use a lot (or require needless recalculation for VRML events). What exactly "a lot" means depends on how much frames your animation has, how much ShapeState is duplicated etc. This can be a huge memory saving. Also preparing scene/animations (in PrepareRender) should be much faster.

  This saved me 13 MB memory in "The Castle" (much less than I hoped, honestly, but still something...). This greatly boosts performance of VRML animations of Transform nodes.

  Where this is worse over roSeparateShapeStates:

  • roSeparateShapeStatesNoTransform can be used only if you don't use Attributes.OnBeforeVertex feature and your model doesn't use volumetric fog. If you do use these features, you have no choice: you must use roSeparateShapeStates, otherwise rendering results may be wrong.

    See [http://vrmlengine.sourceforge.net/kambi_vrml_test_suite.php] file kambi_extensions/fog_volumetric/break_no_transform_final.wrl (versions for VRML 1.0 and 2.0 are available) for a demo.

    Reasons: because TVRMLOpenGLRenderer.DoBeforeGLVertex uses Render_State.CurrMatrix.

  • In some cases roSeparateShapeStatesNoTransform may be a little slower at rendering than roSeparateShapeStates, as this doesn't wrap in display list things done by TVRMLOpenGLRenderer.RenderShapeStateBegin. So modelview matrix and texture matrix and whole lights state will be done each time by OpenGL commands, without display lists.

    Will this affect rendering speed much ? If your scene doesn't use lights then the speed difference between roSeparateShapeStates and roSeparateShapeStatesNoTransform should not be noticeable. Otherwise... well, you have to check what matters more in this case: memory saving by roSeparateShapeStatesNoTransform or additional speed saving by roSeparateShapeStates.

  This is achieved by TVRMLOpenGLRendererContextCache methods ShapeStateNoTransform_Xxx.