WPF 3d rotation animations - wpf

I have a few 3d rectangles on my screen that I want to pivot around the Y axis.
I want to press down with the mouse, and rotate the 3d object to a max rotation, but when the user moves their mouse, I want to slightly rotate it so that it looks like a see-saw (rotating from a range of -13 to 13 degrees on the Y-Axis).
At the moment, I can do this, but my frame rate really really suffers when I move the mouse quickly. So for example, when I click the left side of the rectangle, I generate a storyboard and animation objects, then rotate the 3d object to -13 degrees. Then when I slightly move the mouse to the right, I want to rotate it to -12.5, and so on...
Again, I can do all of this, its just that the performance suffers greatly! It goes down to 5-FPS in some cases... which is not acceptable.
My question is am I doing this the best way? How else could you animate a rotation base on the users position on the screen?
Thanks for any help you can provide!
Mark

I assume you are doing the following:
Using a separate Model3D for the object you are rotating & including it in a Model3DGroup
Giving it a RotateTransform3D containing an AxisAngleRotation3D
Animating the AxisAngle3D's Axis property in the Storyboard
If my assumptions are correct I think we can conclude the problem is efficiency in rendering, since the CPU required to update a single Axis value, recompute the Transform, and update MILCore is negligible.
I can think of several ways that could improve the rendering performance:
If your Model3D being rotated is a GeometryModel3D backed by a MeshGeometry3D, do as much as you can to simplify the mesh and the materials used. It can also help to substitute a different mesh for closeups.
If the Model3D being rotated is a GeometryModel3D that uses VisualBrush brushes, during animation temporarily replace the VisualBrush with an ImageBrush containing a BitmapImage that is a snapshot of the Visual underlying the VisualBrush as of the instant the animation starts. When the animation ends, put backthe VisualBrush. The user probably won't notice that the contents of the object freeze temporarily when it rotates. (Note that this same technique can be used if your Visual3D is a Viewport2DVisual3D.)
If the Model3D being rotated is combined into a Model3DGroup with other objects but lies entirely in front of or behind the other groups, separate the model into its own separate Viewport3DVisual, appropriately layered to get the effect you want.
Simplify lighting or Material types
Monitor the actual frame rate and if it is going too low when using the storyboard, rotate the object immediately to where the mouse indicates without using an animation.

MSDN presents some tips on what impacts in WPF 3D performance. If you didn't stumble on it yet, check the items on "Performance Impact: High" list.
Edit: In march 2009, Josh Smith published an article on CodeProject that involves rotating 3D objetcs. Maybe you want to check his solution.

Related

Speed of Thousands of Rectangles (with a Stroke!!!) in a WPF Canvas

this is my fist question here,
but I didn't find a real answer to my question.
I work on a visualization program and use C# and WPF.
I need to draw a treemap. I actually create Rectangle objects and then add them to the Canvas which works really nice and is very useful, since I also add event handlers to those rectangles (mouse click).
I have a problem with the performance though.
When I add the rectangles and set the Stroke property (SolidColorBrush) the whole process is slowing down extremely. Without those strokes set the speed is ok.
I already improved the performance a little by adding Rectangle objects to a newly created Canvas object and then adding this new Canvas object to the original Canvas object (so not all rectangles are direkt children of the original Canvas, which should help speeding things up).
So my question is how it is possible to add a Stroke to all those Rectangles without breaking the speed.
You can find a comparison of the 'strokeless' and 'stroked' treemap versions in the links.
Treemap without Strokes
Treemap with Strokes
Thank you very much for your help!
edit:
Ok, I have found a solution!
Sorry for writing here first, but I already searched for hours to find a solution but now I found out tht the problem was my used SolidColorBrush!
I have something like this:
public static SolidColorBrush TreeMapBorderBrush;
And I use this Brush to set the Stroke property of every Rectangle that should be added to the Canvas. But exactly that was the problem.
The code looked like this before:
rect.Stroke = Visualization_Helper.TreeMapBorderBrush;
I changed it to this now:
rect.Stroke = Visualization_Helper.TreeMapBorderBrush.Clone();
So I only work with a copy of that Brush on each Rectangle now, which speeds up the processing like there was no Stroke (like in my question)!
Just for your information! Weird!

Zooming into a Canvas without modifying the size of specific child controls

So I realize that I am venturing outside of the intended use of a Canvas here and will likely have to come up with a more manual solution. However, not being overly experienced in WPF I was hoping that there may be some solution which would allow me to continue using a Canvas control and the features it gives you for free.
The issue revolves around a Canvas which is used to zoom in and out of an image and some number of child controls that belong to the Canvas. These child controls are to be placed at various positions on the image and, as such, the Canvas works nicely in that it handles all of the layout/positioning for me as I zoom in or out.
However, one drawback is that the Canvas scales these child controls up as I zoom into the image, causing them to become too large to be usable in practice. What I am looking for is a solution that allows me to zoom into an image that belongs to a canvas without also zooming up the size of the child controls, preferably handling the layout for me.
I have tried modifying the width and height of these child controls as the zoom factor increases or decreases, but there is a slight lag time and it all looks a bit 'jerky'.
If it comes down to it I will simply do all of the zooming/panning/layout myself, but I thought I would ask first just to make sure that I am not missing anything that would allow me to tell the Canvas to not scale the size of certain controls. Thanks in advance.
You can bind the children's RenderTransform to the inverse of the Canvas' transform, see my answer to this similar question on rotation.
This is more of a thought than an answer, but what if you set a transform on the element that you did not want scaled that was the opposite of the canvas itself. So for example, if the canvas had a scale transform of 2.0, set the element to have a scale transform of 0.5. You could probably accomplish this by binding the transform values together using a value converter.
You'll probably want to make sure the element has a render transform origin of 0.5,0.5 so that it scales from the center.

Light Map projection

What i'm trying to do is making a "light projector" with visible ray(like with fog) also called volumetric light;
and which project a image (bitmap) ;
Because i would like to keep this project connected with a wpf application ( to get brush, position, rotation from data), i've choose to use WPF 3D
But it seem that WPF can't handle light projection or render ray.
So to do that, i have extruded each pixel of my source bitmap into a polygon colored by a solidColorBrush of the pixel color.
and keep the pixel order with (x,y) position.
For performance issue, i've set all the bitmaps to 32x32 px ( 1024 polygon for only one light !!)
But the result is too pixelated as you can see on the picture.
Moreover, it probably take much memory for nothing ...
my question is, how can i make it smooth or even rethink the extrusion system to optimize performance ...
Is any other tehnology that can be integrated into a wpf application and do that better or easier ?
Thanks, and sorry my English is pretty bad ...
alt text http://www.visualdmx.fr/pic_example.png

WPF high performance drawing - should I group by brush color?

In Direct2D they recommend drawing similar things together, to avoid unnecessary GPU state changes. They also do some drawing operation reordering behind the scene just for that.
I have to draw a lot of rectangles which can have one of two colors. I'm thinking of doing the drawing in two passes, one for the rectangles with the first color and another for the ones with the other color.
Do you have any idea if this will improve the rendering speed? The speed I have right now is not that great. I draw into a DrawingContext obtained from a DrawingVisual.
I really don't know what effect grouping by brush will have, but there are some things you should check first:
Make sure all brushes, pens and other freezables are frozen.
Simplify your visual tree, try to reduce element count.
Try to reduce the number of elements that change every time you update your drawing.
Read: http://msdn.microsoft.com/en-us/magazine/dd483292.aspx

WPF: Creating snappable grid lines with variable spacing

I'm currently creating a MSPaint-like WPF-application and struggling with the implementation of a snappable grid.
The painting of the grid is no problem with a VisualBrush and a Rectangle but the problem is that these lines are then purely for looks and can't be easily changed (for example highlighted when the snapping to a specific line triggered).
My other idea was to have a 2 Canvas solution where 1 Canvas is used for the elements and one Canvas (who is positioned above the other) contains all the grid lines. However I have the feeling that this would mean quite a performance hit.
Are there any other possible ways to implement this kind of functionality?
Efficiency considerations of a two-panel approach vs DrawingContext
I have good news for you: You are wrong about the significant performance hit. Your two-canvas idea is nearly optimal, even if you use individual objects for the grid lines. This is because WPF uses retained-mode rendering: When you create the canvas, everything on it is serialized into a compact structure at native level. This only changes when you change the grid lines in some way, such as changing the grid spacing. At all other times the performance will be indistinguishable from the very fastest possible managed-code methods.
A slight performance increase could be had by using DrawingContext as Nicholas describes.
A simpler and more efficient solution
Perhaps a better way then drawing individual lines on the grid canvas is to use two tiled visual brushes (one horizontal, one vertical) to draw all unhilighted lines, then use Rectangle(s) added in code-behind to hilight the line(s) you are snapping to.
The main advantage of this technique is that your grid can be effectively infinite, so there is no need to calculate the right number of grid lines to draw and then update this every time the window resizes or the zoom changes. You also only have three UIElements involved, plus one more for each grid line that is currently hilighted. It also seems cleaner to me than tracking collections of grid lines.
The reason you want to use two visual brushes is that drawing is more efficient: The brush drawing the vertical lines is stretched to a huge distance (eg double.MaxValue/2) in the vertical direction so the GPU gets only one drawing call per vertical line, the same for the horizontal. Doing a two-way tiling is much less efficient.
Adorner layer
Since you asked about alternatives, another possibility is to use Adorner and AdornerLayer with any of the solutions above rather than stacking your canvas using eg a Grid or containing Canvas. For a Paint-like application this is nice because the adorner layer can be above your graphic layer(s) yet the adorners can still attach to individual items that are being displayed.
You might consider drawing your grid using the DrawingContext inside of OnRender. Drawing this way does not introduce new UIElements into the visual tree, which helps to keep performance up. In some ways, it is similar to what you are currently doing with the VisualBrush, which also does not create new UI elements per copy.
However, since you will actually be individually drawing each line instead of copying the look of a single line, you'll be able to highlight the grid line(s) that participate in snapping without changing the colors of those that do not.
If you are going to go down this route, make sure to have a look into GuidelineSets for positioning your guide lines (more details here), since you'll probably want to have your guide lines snap to the device's pixels so that they draw sharply.

Resources