I'm making a model of human anatomy . there is about 2100 mesh and model.
I used Helix 3d toolkit to import all files into a scene but that takes a long time to import (about 20 second) and scroll and rotations are slow. and that takes 800 meg of RAM.
objects are optimized and the sum of vertics must be less that 2 million.
i don't need shadows or any special effect. but i need scroll , zoom , hit testing and ..
what format should i use for saving models? i think .obj files are slow. should i use 3ds? or xaml?
should i use 2000 modelvisual3d or one with 2000 Geometrymodel3d ?
or should i use XNA?
can i disable some features to speed things up ?
tnx
you could try to save them as .vtk (visual toolkit) and load them with a library like three.js in a webgl canvas. (it also understands collada)
Very interesting idea to present 3D "Alive" - interactive human anatomy within WPF3D.
what format should i use for saving models? i think .obj files are slow. should i use 3ds? or xaml?
I am sure that .obj is one of fastest. In loading it is slow but in working it is.
should i use 2000 modelvisual3d or one with 2000 Geometrymodel3d ?
One ModelVisual3D and not 2000 Geometrymodel3d if it is possible by coding. Geometrymodel3d is for different materials. It has .Geometry, .BackMaterial and .Material.
or should i use XNA?
XNA more faster but not interactive. You are working at application not at game.
can i disable some features to speed things up ?
Very interesting task. At model preparing remove all back materials, made materials as simple as possible, take into account to meshes that you do not need. Provide camera rotation if it is possible.
You can send me model and I will try to help.
Related
I'm trying to write an CAD-like application in WPF(.NET 4.0) that needs to be able to display a lot of 2D points/lines. It will be used to display CAD-plans of entire cities with zoom, pan, rotate and point snapping on mouseover.
Right now I purely use WPF. I read the objects from the CAD file draw them into a StreamGeometry, use it as stroke of a new Path and add it to a Canvas, with several transforms.
My problem is that this solution doesn't scale well enough. It works fine with small CAD-files, but when I want to display like half a city(with houses and land boundaries) it is very very delayed.
I also tried to convert my CAD-file to an image, but
- a resolution a 32000x32000 is sometimes not enough
- when zooming out the lines are too thin.
In the end I need to be able to place this on a Canvas(2D/3D) as background.
What are my best options here?
Thanks,
Niklas
wpf is not good for a large 3d models. im afraid it is too slow. Your best bet is direct 3d or openGL
However, even with the speed of direct3d,openGL you will still need to work out how to cull as many polygons/vertices as possible before the rendering of the scene if you are trying to show an entire city.
there is a large amount of information on this (generally under game development)
there are a few techniques including frustrum culling, near and far plane culling.
also, since you probably have a static scene you may be able to use binary spacial partitioning.
As I understand the subject is 2D CAD system within WPF.
Great! I use it...
OpenGL and DirectX are in infinite loop OnDraw always. The CPU works all the time.
WPF/Silverlight 2D is smart model.
Yes, total amount of elements (for example, primitives inherited from Shape) must be not so much. But how many?
I tested own app (Silverlight). WPF will be a bit faster I hope...
Here my 2D CAD results. Performance is still great. Each beam consists of multiple primitives.
Use a VirtualCanvas like this one from Chris Lovett.
I am looking to style my application with some graphic elements. Icons and other thinks.
Is it better from performance and best practise point of view to use vektor graphics (XAML) or turn my graphic to a PNG?
And Why?
I am aware of the fact that vector graphics are scaleable... this is just a performance questions on large xaml based apps.
You have to weigh your own needs. If it's solely performance, then I'd say that depends on the number of images. If they're a large number then XAML would indeed be more performant, otherwise it would be negligible.
But I have to say for sheer maintainability, especially since you're talking about icons and such, you're far better off with bitmaps and I'll tell you why. Anyone and their brother can edit an icon. You can't say the same with vector graphics. If you want to replace your icons at some point, you simply replace the image. You don't have to go through the hassle of either creating and/or finding vector images and then (most likely) having to convert them to XAML through an export filter. Additionally, there are literally millions of CC licensed icons in bitmap form that you could use for nothing more than attribution.
Yes, there are some hassles with bitmaps (such as some quirks dealing with the ActualWidth/ActualHeight) from time-to-time, but those are minor, in my opinion.
ADDED: Yi-Lun Luo from Microsoft stated vectors are faster back in 2008. With the release of version 3 in 2009, Silverlight has taken advantage of the GPU which makes vectors even faster, if you enable it as well as if you also use BitmapCache. So on from a purely performance standpoint, vectors would be faster, theoretically.
Advantages of XAML over PNG:
Scaling - XAML drawings are made of vectors so are able to scale. Scaling beyond a factor 2 can cause issues (rounding off errors when scaling down and too little detail when scaling up).
Dynamic coloring/animations - You can easily manipulate the colors and points or even curves in the drawing using animations.
Advantages of PNG over XAML:
Speed in loading/caching - PNG can be cached on the GPU. Never more bytes on disk than 4 bits per pixel (+ some overhead)
Pixel perfect - what the designer draws is shown in the app. This is a lot harder when using vectors.
You pick depending on your needs and measurements of performance, load and files sizes.
As I said on the title.
I just want to know which is better between using image files and drawing vector shapes (or path).
I know that using vector is better for appearance but what about performance.
And if this depends on cases. Can anyone explain.
(This question may include WP7, Silverlight, WPF or even in general cases.)
Here is a general answer to compare pros/cons of Bitmap (what I think you mean by "image file") vs. Vector.
Bitmap-based images (gif, tiff, jpeg, png, bmp) are essentially the concept of mapping colours (and other data such as alpha layer) to a pixel grid. Different file formats offer variations of what is supported and levels of compression but this is the high-level concept. The complete map of pixels and data is stored in the file as a matrix/table.
Vector-based images, as you say, are path based. Instead of storing information by pixels, the file format will store geometric points and data.
The pros for bitmaps are:
They usually render faster than a vector. This is because there is minimal computation involved in presenting the image (just take the pixel map and display).
They handle "photographic" content better than a vector.
They are more portable than vector. GIF, JPEG, PNG, BMP are more standard than any vector format (where usually Adobe has the market)
The cons for bitmaps are:
They don't scale without degradation (pixelization)
Manipulation (i.e. resizing, blurring, lighting, etc) of a bitmap is more processor expensive than a vector
The files are usually much larger than vector-based files
The pros for vectors are:
Flexible for scaling and manipulation
Smaller file formats than vector
Ideal for print and animation (i.e. manipulating a shape to produce the animation effect)
The cons for vectors are:
Render time, depending on the complexity of the vector, can be longer
Portability most formats are highly proprietary
Work for "graphic" based images but not useful for photorealism
Hope this helps.
Jeremiah Morrill gave a great overview of WPF rendering that basically shows a vector will always be more expensive to render than an image. Basically an image gets treated as a directx texture...no matter the size, scaling or whatever, there is a set constant cost for rendering an image. As Jer's overview shows, even the simplest vector image takes a number of operations to render in WPF. The moral of the story is that when giving an option, go for the image instead of vector.
Based on our experience with Windows Phone 7 (Non-mango) apps, we find using Images instead of using drawing produces a far more responsiveness hence UX Performance for continuous animation in pages. (YMMV)
I would initially say that images render faster than vectors. The complexer the vector, more time it takes to render. The bigger the image, more time to render.
I'm going to speculate that (in Silverlight terms) most of the current video hardware is capable of directly handling the images rendering getting so a boost in the performance. I'm not sure if calculations for vectors can be done at video hardware level.
From the point of view of Windows Phone 7, you'll typically get faster rendering of images/bitmaps rather than paths/vectors. As a general rule for mobile development, due to the constrained resources on the device and the increased need to consider performance, if you can do something once, such as preparing an image, at design (or compile) time that definitely preferable to doing it multiple times on each client.
Be very careful of applying rules across platforms (WPF, Silverlight & WP7) as they are used for different things in different situations and are under different constraints. Things you have to consider on the phone may not be as much of an issue in a WPF app running on an high powered PC.
What is the best approach to render charts and then save them on a hard drive for further distribution using WPF?
I found a number of ways to accomplish this by using the following types:
DrawingVisual - creating a object of this type and then rendering graphics on its context;
Shape - deriving from the Shape class and then overriding its DefiningGeometry property where the actual rendering is happening;
PathFigure - adding LineSegment-s to an instance of this class and then adding this instance to a Canvas;
Adorner - deriving from it and then overriding its OnRender method;
WritableBitmap - rendering on it and then adding the bitmap to a Canvas.
Of course I'm going to write an app to test how fast each of these will be. But can anybody tell me:
whether am I on the right track?
are there any other means to do such rendering?
which one of them is the best in
terms of performance?
It all depends on your actual usage, in your case you mention saving on the hard drive for "further distribution" - I'm going to assume you are saving them as an image (jpg or png) and not as wpf objects (xaml).
You should consider if WPF is the right tool for the job, WPF is a UI framework and not a generic image processing library, it may be best to use something else entirely for generating images.
For a reasonable number of points your performance bottleneck will be encoding the image and saving it to disk - not actually rendering it - so you should choose the method that is easier for you to code.
All the articles about high performance WPF charts are a: about charts with 10,000 points and more (because that is where the performance problems are), b: about charts you display in your GUI (because otherwise you can use an image processing library to create the bitmap) and c: charts that change all the time (so they work nicely with data binding) - there's a reason why they don't talk about saving charts to disk.
For a very large number of points:
The fastest way to draw in WPF is to inherit from FrameworkElement (not Adorner) and override OnRender.
When the data changes often it is recommended to use multiple DrawingVisual objects because then you don't have to re-render everything when one value change - but this is not relevant for you since the image won't change after you save it anyway.
WritableBitmap is used for raw bitmap access, you use it when you decide to give up on all the nice layout and drawing WPF gives you because you can't take the overhead, if this is the case you should re-read my first point above.
So, to summarize, you are asking the wrong question :-) if you need to save images to disk than either the WPF rendering speed is not your bottleneck or you shouldn't be using WPF to begin with. If you do use WPF just pick whatever is easiest for you to code.
BTW: Adorners are used to display "floating" elements above the normal UI, you can use them for tooltip-like features but not for the main chart rendering (and you probably don't want them at all since your main usage is saving the image to disk), FrameworkElement is the base class you are looking for.
Is there any disadvantage of using ModelVisual3D over Model3DGroup. How much can the resource/performance impact possibly be?
ModelVisual3D gives me much more than Model3DGroup does but AFAIK everything that can be done with Model3DGroup can alos be done with ModelVisual3D.
So why not just always use ModelVisual3D?
The answer is Yes. Having many ModelVisual3ds will be orders of magnitude slower than using a Model3DGroup
My understanding is that ModelVisual3D is more akin to a UIElement, i.e. more of a heavy weight object. MSDN says about ModelVisual3d:
"Provides services and properties that are common to all visual objects, including hit-testing, coordinate transformation, and bounding-box calculations."
So if you wanted to 100 clickable 3d objects in your scene you would need 100 ModelVisual3d elements.
Model3DGroup (along with GeometryModel3D) on the other hand is a Model3D - the building blocks of 3d models. A single Model3D can appear as the content for several ModelVisual3Ds. Model3Ds are more lightweight than ModelVisual3D.
If you wanted to construct 3d models from building blocks (like Lego), you could define several GeometryModel3Ds, then combine them together using a Model3dGroup.
Yes, the class naming is horribly confusing, and I don't think the Daniel Lehenbauer sheds any light on the subject for the average human.