My application present a (raster) moving map.
I need to be able to show the map rotated base on any given angle.
The program is currently in VC++/MFC but the problem is generic.
I have a source bitmap (CBitmap or HBITMAP) and draw it to the device context (CDC) using StretchBlt.
While this works fast and smooth for angle=0 (and the user can grab the map smoothly with the mouse), this is not the case if I try to rotate the bitmap and then present it (the rotation of the bitmap using SetWorldTransform() or so takes hundreds of miliseconds and this is too slow).
I think that the solution is to be able to relate only to the pixels that currently on the screen and not rotating the original source bitmap - and this is the key.
If someone has experience with similar implementation then it might save me lots of trial and error efforts.
Thanks!
Avi.
It looks like SetWorldTransform is extremely slow:
http://www.codeguru.com/Cpp/G-M/bitmap/specialeffects/article.php/c1743
And while the other options presented in that article are faster, there are of course other better solutions like this:
http://www.codeguru.com/cpp/g-m/gdi/article.php/c3693/ (check the comments for fixes and improvements as well)
Also here are some non-Windows centric fast rotation algorithms:
http://www.ddj.com/windows/184416337?pgno=11
Note that if you guarantee power of 2 dimensions you can get significant speed improvements.
As follow up to my question and provided answer, let me summarize the following:
I used the algorithm mentioned at http://www.codeguru.com/cpp/g-m/gdi/article.php/c3693/.
It works and provide pretty good performance and smooth display.
There were some bugs in it that I needed to fix as well as simplify the formulas and
code in some cases.
I will examine the algorithm mentioned at http://www.ddj.com/windows/184416337?pgno=11 to see if it provides some break through performance that worth adapting it.
My implementation required using a large source bitmap, so I needed to modify the code so I will not rotate the whole bitmap each time but only the relevant portion that will be displayed at the screen (otherwise performance would be unacceptable).
Avi.
Related
We're trying to visualize a massive graph that transforms over time but we're unsure which platform would be powerful enough to do this.
We tried using Unity, but importing the 50.000 vertices was a big problem already. With static Batching we could get up to 100fps, but we want to change the vertices color depending on parameters. Therefore static Batching was not an option. We tried using other batching systems in combination with different rendering pipelines but then we could get 20 fps at most. We concluded that unity probably isn't the best platform for our purposes since there is so much stuff happening in the background.
try doing some optimizations like
I think your problem is all about performance these is some performance tips as i see 50K vertices are good
rendering only what camera see by using Occlusion culling
Make objects that dosnt move mark as static by selecting it and check static in top right corner in inpector
back light instead of realtime lighting & reflections
try use texture map to use same material on multiple objects and select material> inspector check Enable gpu instancing
good luck !
I've been studying 3D graphics on my own for a while now and I want to get a greater understanding of just how everything works. What I would like to do is to create a simple game without using DirectX or OpenGL. I understand most of the math I believe, but the problem I am running up against is I do not know how to get control of the pixels being displayed in a window.
How do I specify what color I want each pixel in my window to be?
I understand I will probably run into issues with buffers and image shearing and probably terrible efficiency problems, but I want to create my own program so that I could see from the very lowest level, of the high level language, how the rendering process works. I really have no idea where to start though. I've figured out how to output BMPs, but I would like to have a running program spitting out 20+ frames per second. How do I accomplish this?
You could pick a environment that allows you to fill an array with values for pixels and display it as a bitmap. This way you come closest to poking RGB values in video memory. WPF, Silverlight, HTML5/Javascript can do this. If you do not make it full screen these technologies should suffice for now.
In WPF and Silverlight, use the WriteableBitmap.
In HTML5, use the canvas
Then it is up to you to implement the logic to draw lines, circles, bezier curves, 3D projections.
This is a lot of fun and you will learn a lot.
I'm reading between the lines that you're more interested in having full control over the rendering process from a low level, rather than having a specific interest in how to achieve that on one specific platform.
If that's the case then you will probably get a good bang for your buck looking at a library like SDL which provides you with a frame buffer that you can render to directly but abstracts away a lot of the platform specifics issues. It has been around for quite a while and there are some good tutorials to give you an idea of whether it's the kind of thing you're looking for - see this tutorial and the subsequent one in the same series, which should be enough to get you up and running.
You say you want to create some kind of a rendering engine, meaning desinging you own Pipeline and matrice classes. Which you are to use to transform 3D coordinates to 2D points.
When you have got the 2D points you've been looking for. You can use say for instance on windows, you can select a brush and draw you triangle values while coloring them at the same time.
I do not know why you would need Bitmaps, but if you want to practice say Texturing you can also do that yourself although off course on a weak computer this might take your frames per second significantly.
If you aim is to understand how rendering works on the lowest level. This is with no doubt a good practice.
Jt Schwinschwiga
I want to build a obj to draw a realtime graph but I have performance limitations
size of graph is static.
in repaint the graph
I can redraw all the needed line.
I have other way that save the graph on bitmap memory
and each time copy it on the screen
which way is better?
what is faster copy bitmap or draw lines?
I guess it depends on what you are trying to display. Showing a few lines should not pose any performance problems (if done well), but doing anything more graphics-intensive can be more problematic.
It also depends on what you use for drawing. GDI is easy but slow; GDI+ is also easy, can be prettier (antialiasing, etc.) but is also quite slow (or used to be when I tried it); OpenGL is fast but a bit trickier.
So it's a question with no easy answer, not knowing all the details of your needs. I think I would draw directly, and if it's not fast enough then check other options. What you'll probably need anyway is a double-buffering system, to avoid flickering (check http://www.codeproject.com/KB/GDI/flickerfree.aspx)
You can take a look at http://www.codeproject.com/KB/miscctrl/High-speedCharting.aspx. It's a charting control which seems to be quite fast.
Let me describe the "battlefield" of my task:
Multi-room audio/video chat with more than 1M users;
Custom Direct3D renderer;
What I need to implement is a TextOverVideo feature. The Text itself goes via network and is to be rendered on the recipient side with Direct3D renderer. AFAIK, it is commonly used in game development to create your own texture with letters/numbers and draw this items. Because our application must support many languages, we ought to use a standard. That's why I've been working with ID3DXFont interface but I've found out some unsatisfied limitations.
What I've faced is a lack of scalability. E.g. if user is resizing video window I have to RE-create D3DXFont with new D3DXFONT_DESC while he's doing that. I think it is unacceptable.
That is why the ONLY solution I see (due to my skills) is somehow render the text to a texture and therefore draw sprite with scaling, translation etc.
So, I'm not sure if I go into the correct direction. Please help with advice, experience, literature, sources...
Your question is a bit unclear. As I understand it, you want easily scalable font.
I think it is unacceptable
As far as I know, this is standard behavior for fonts - even for system fonts. They aren't supposed to be easily scalable.
Possible solutions:
Use ID3DXRenderTarget for rendering text onto texture. Font will be filtered when you scale it up too much. Some people will think that it looks ugly.
Write custom library that supports vector fonts. I.e. - it should be able to extract font outline from font, and build text from it. It will be MUCH slower than ID3DXFont (which is already slower than traditional "texture" fonts). Text will be easily scalable. Using this way, you are very likely to get visible artifacts ("noise") for small text. I wouldn't use that approach unless you want huge letters (40+ pixels). Freetype library may have functions for processing font outlines.
Or you could try using D3DXCreateText. This will create 3D text for ONE string. Won't be fast at all.
I'd forget about it. As long as user is happy about overall performance, improving font rendering routines (so their behavior looks nice to you) is not worth the effort.
--EDIT--
About ID3DXRenderTarget.
EVen if you use ID3DXRenderTarget, you'll need ID3DXFont. I.e. you use ID3DXFont to render text onto texture, and then use texture to blit text onto screen.
Because you said that performance is critical, you can delay creation of new ID3DXFont until user stops resizing video. I.e. When user starts resizing video, you use old font, but upscale it using texture. There will be filtering, of course. Once user stops resizing, you create new font when you have time. you probably can do that in separate thread, but I'm not sure about it. OR you could simply always render text in the same resolution as video. This way you won't have to worry about resizing it (it still will be filtered - along with the video). Some video players work this way.
Few more things about ID3DXFont. There is one problem with ID3DXFont - it is slow in situations where you need a lot of text (but you still need it, because it supports unicode, and writing texturefont with unicode support is pain). Last time I worked with it I optimized things by caching commonly used strings in the textures. I.e. any string that was drawn more than 3 frames in the row were rendered onto D3DFMT_A8R8G8B8 texture/render target, and then I've been copying that string from texture instead of using ID3DXFont. Strings that weren't rendered for a while, were removed from texture. That gave some serious boost. This solution, however is tricky - monitoring empty space in the texture, removing unused strings, and defragmenting the texture isn't exactly trivial (there is nothing exceptionally complicated, but it is easy to make a mistake). You won't need such complicated system unless your screen is literally covered by text.
ID3DXFont fonts are flat, always parallel to the screen. D3DXCreateText are meshes that can be scaled and rotated.
Texture fonts are fuzzy and don't look very clear. Not good for an app that uses lots of small text.
I am writing an app that can create 500 text meshes, each mesh averaging 3,000-5,000 vertices. The text meshes are created once, then are static. I get 700 fps on a GeForce 8800.
I've seen antialiasing on Windows using GDI+, Java and also that provided by Photoshop and Gimp. Are there any other libraries out there which provide antialiasing facility without depending on support from the host OS?
Antigrain Geometry provides anti-aliased graphics in software.
As simon pointed out, the term anti-aliasing is misused/abused quite regularly so it's always helpful to know exactly what you're trying to do.
Since you mention GDI, I'll assume you're talking about maintaining nice crisp edges when you resize them - so something like a character in a font looks clean and not pixelated when you resize it 2x or 3x it's original size. For these sorts of things I've used a technique in the past called alpha-tested magnification - you can read the whitepaper here:
http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf
When I implemented it, I used more than one plane so I could get better edges on all types of objects, but it covers that briefly towards the end. Of all the approaches (that I've used) to maintain quality when scaling vector images, this was the easiest and highest quality. This also has the advantage of being easily implemented in hardware. From an existing API standpoint, your best bet is to use either OpenGL or Direct3D - that being said, it really only requires bilinear filtered and texture mapped to accomplish what it does, so you could roll your own (I have in the past). If you are always dealing with rectangles and only need to do scaling it's pretty trivial, and adding rotation doesn't add that much complexity. If you do roll your own, make sure to pay particular attention to subpixel positioning (how you resolve pixel positions that do not fall on a full pixel, as this is critical to the quality and sometimes overlooked.
Hope that helps!
There are (often misnamed, btw, but that's a dead horse) many anti-aliasing approaches that can be used. Depending on what you know about the original signal and what the intended use is, different things are most likely to give you the desired result.
"Support from the host OS" is probably most sensible if the output is through the OS display facilities, since they have the most information about what is being done to the image.
I suppose that's a long way of asking what are you actually trying to do? Many graphics libraries will provide some form of antialiasing, whether or not they'll be appropriate depends a lot on what you're trying to achieve.