The simplest one only implements this interface, with the InitNew, Clone and Draw methods. The Draw method has access to the Carmenta Engine drawable, and can use its drawing methods to create the visualization. Using this interface gives you a few things for free: Carmenta Engine can do automatic hit-testing of the visualization for selection purposes, and the visualization can also be cached by Carmenta Engine, to improve performance, especially in a TileLayer.

If the drawing primitives of the drawable are sufficient to do the visualization, but you need greater control over hit-testing for selection, you may also implement the ICustomVisualizerHitTest interface. Drawing and caching is performed the same way as before, but now hit-testing is not done automatically by Carmenta Engine, instead it is delegated to the hit-testing interface. See ICustomVisualizerHitTest for more information.

The last variant should be used only when the drawing capabilities of the drawable is insufficient for your needs. Instead of implementing this interface (and maybe ICustomVisualizerHitTest), you implement the ICustomNativeVisualizer interface. With this interface, you may draw directly to the underlying, native graphics object, typically a Windows DC or an OpenGL context. See ICustomNativeVisualizer for more information. However, using this method has several drawbacks compared to the others: Your custom visualizer only work with one type of drawable, you may have to implement your own hit-testing, and you will not get any visualization caching.

The simplest one only implements this interface, with the initNew, clone and draw methods. The draw method has access to the Carmenta Engine drawable, and can use its drawing methods to create the visualization. Using this interface gives you a few things for free: Carmenta Engine can do automatic hit-testing of the visualization for selection purposes, and the visualization can also be cached by Carmenta Engine, to improve performance, especially in a TileLayer.

If the drawing primitives of the drawable are sufficient to do the visualization, but you need greater control over hit-testing for selection, you may also implement the ICustomVisualizerHitTest interface. Drawing and caching is performed the same way as before, but now hit-testing is not done automatically by Carmenta Engine, instead it is delegated to the hit-testing interface. See ICustomVisualizerHitTest for more information.

The last variant should be used only when the drawing capabilities of the drawable is insufficient for your needs. Instead of implementing this interface (and maybe ICustomVisualizerHitTest), you implement the ICustomNativeVisualizer interface. With this interface, you may draw directly to the underlying, native graphics object, typically a Windows DC or an OpenGL context. See ICustomNativeVisualizer for more information. However, using this method has several drawbacks compared to the others: Your custom visualizer only work with one type of drawable, you may have to implement your own hit-testing, and you will not get any visualization caching.

The simplest one only implements this interface, with the initNew, clone and draw methods. The draw method has access to the Carmenta Engine drawable, and can use its drawing methods to create the visualization. Using this interface gives you a few things for free: Carmenta Engine can do automatic hit-testing of the visualization for selection purposes, and the visualization can also be cached by Carmenta Engine, to improve performance, especially in a TileLayer.

If the drawing primitives of the drawable are sufficient to do the visualization, but you need greater control over hit-testing for selection, you may also implement the ICustomVisualizerHitTest interface. Drawing and caching is performed the same way as before, but now hit-testing is not done automatically by Carmenta Engine, instead it is delegated to the hit-testing interface. See ICustomVisualizerHitTest for more information.

The last variant should be used only when the drawing capabilities of the drawable is insufficient for your needs. Instead of implementing this interface (and maybe ICustomVisualizerHitTest), you implement the ICustomNativeVisualizer interface. With this interface, you may draw directly to the underlying, native graphics object, typically a Windows DC or an OpenGL context. See ICustomNativeVisualizer for more information. However, using this method has several drawbacks compared to the others: Your custom visualizer only work with one type of drawable, you may have to implement your own hit-testing, and you will not get any visualization caching.