Unit VRMLGLScene

Values for TVRMLSceneRenderingAttributes.WireframeEffect.

Generally, two other attributes may affect the way wireframe is rendered: TVRMLSceneRenderingAttributes.WireframeColor and TVRMLSceneRenderingAttributes.WireframeWidth, quite self-explanatory.

Values

• weNormal: Default setting, model polygons are simply passed to OpenGL. Whether this results in filled or wireframe look, depends on OpenGL glPolygonMode setting, filled by default.
• weWireframeOnly: The model is rendered in wireframe mode.

  WireframeWidth is used as wireframe line width (regardless of PureGeometry).

  Depending on TVRMLSceneRenderingAttributes.PureGeometry value:

  • If PureGeometry then WireframeColor is used as wireframe line color.

  • If not PureGeometry, then lines are colored and potentially lighted and textured just like their corresponding triangles would be colored. So you can control lighting using OpenGL GL_LIGHTING setting and UseLights attribute, and you can control texturing by ControlTextures/EnableTextures attribute.

• weSolidWireframe: The model is rendered as normal, with it's wireframe version visible on top. This is most often called "solid wireframe", since the intention is too see wireframe version of the model but still render shapes solid (e.g. filled polygons with depth test).

  WireframeColor and WireframeWidth are used as wireframe line color/width (regardless of current PureGeometry value).

  This usually gives best results when PureGeometry is on. Then current glColor sets the color of the solid model (and, like said before, WireframeColor sets wireframe color).

  TODO: Note that for PureGeometry = False, the wireframe will still be textured if original model were textured. Also wireframe color will be affected by GLSL shaders, if model defined any. (Wireframe will never be lighted, this is taken care of properly). This is bad, as I would like to never texture or shade the wireframe, regardless of PureGeometry. Basically, the wireframe part should behave always like PureGeometry = True, regardless of the filled model PureGeometry setting. For now, avoid using weSolidWireframe with PureGeometry = False if your model may have textures or shaders. There's no way currently to reuse the same display list, while having normal model textured/shaded and wireframe not textured/shaded. If you really need this effect, you'll need two TVRMLGLScene instances with different attributes rendering the same model.

• weSilhouette: The model is rendered as normal, with silhouette outlined around it. This works quite like weSolidWireframe, except that weSolidWireframe makes the wireframe mesh slightly in front the model, while weSilhouette makes the wireframe mesh slightly at the back of the model. This way only the silhouette is visible from the wireframe rendering.

  WireframeColor and WireframeWidth are used as silhouette line color/width (regardless of current PureGeometry value).

  This is sometimes sensible to use with PureGeometry = True. Then current glColor sets the color of the solid model (and, like said before, WireframeColor sets wireframe color)

  TODO: Note that for PureGeometry = False, the wireframe will still be textured/shaded if original model were textured or used GLSL shaders. See weSolidWireframe TODO notes.

Various things that TVRMLGLScene.PrepareRender may prepare.

Values

• prBackground:  
• prBoundingBox:  
• prTrianglesListNotOverTriangulate:  
• prTrianglesListOverTriangulate:  
• prTrianglesListShadowCasters:  
• prManifoldAndBorderEdges:  

Possible checks done while frustum culling.

This is used for TVRMLGLScene.FrustumCulling (what checks should be done when shapes octree is not available) and TVRMLGLScene.OctreeFrustumCulling (what checks should be done when shapes octree is available).

In the second case, checks done by TFrustumCulling are applied after octree traverse. That is, octree already eliminated some shapes, and fully included some other shapes while traversing. TFrustumCulling are used in this case only as a "last resort", to check only the shapes in octree leaves that are in "possibly-colliding" state with frustum.

Generally, more checks mean that more shapes may be eliminated but also that we waste more time on checks themselves. What is optimal depends on given 3D model, and how you expect the player to view it (e.g. if player usually sees the whole model, then TFrustumCulling checks may be useless waste of time; OTOH, if player stands inside the model composed from many shapes then TFrustumCulling may help).

Values

• fcNone: No checks.

  Setting this as TVRMLGLScene.FrustumCulling turns off frustum culling entirely, which is usually not a wise thing to do... Setting this as TVRMLGLScene.OctreeFrustumCulling let's octree do all the work, which is quite sensible actually.

• fcSphere: Check shape's bounding sphere for collision with frustum.
• fcBox: Check shape's bounding box for collision with frustum.
• fcBoth: Check shape's bounding sphere, and then box, for collision with frustum. This is the most rigoristic check, but usually this is a waste of time: in most cases, when bounding sphere collides, then bounding box collides too.

Default value of Attributes.BlendingDestinationFactor.

Why isn't the default value GL_ONE_MINUS_SRC_ALPHA ? See [http://vrmlengine.sourceforge.net/vrml_engine_doc.php], chapter "OpenGL rendering", section about "mat transparency using blending". And comments below.

In short:

• The disadvantage of GL_ONE is that resulting image will be bright (maybe too bright) where partially transparent objects are.

• The disadvantage of GL_ONE_MINUS_SRC_ALPHA is that the color of opaque object behind disappears too quickly from resulting image (since GL_ONE_MINUS_SRC_ALPHA scales it down).

  Also, it requires sorting for 100% correctness, and sorting is not implemented yet. See TVRMLSceneRenderingAttributes.Blending.

_MINUS_SRC_ALPHA

Options to pass to TVRMLGLScene.PrepareRender to make sure that next call to TVRMLGLScene.RenderShadowVolume is as fast as possible.

For now this actually could be equal to prManifoldEdges (prTrianglesListShadowCasters has to be prepared while preparing ManifoldEdges edges anyway). But for the future shadow volumes optimizations, it's best to use this constant.