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 !
Related
I'm looking for help with batch rendering. I understand it batches together objects such as sprites, graphics, etc for performance purposes. I have a very large number of objects to display. However, the only assistance I found was this which is so hard to follow. Is there any simple tutorials or guidance out there for this? Ideally, I want a very simple example that batches together 2 sprites and renders them in one draw call. Many thx.
I spoke to the creator of pixi-viewport and he said that pixi has batching built in.
Performance improvements were instead gained by:
Using pixi-cull (a good perf boost if you are also using pixi-viewport)
Switching from Graphics to Sprites
minimising the use of sprite.interactive = true
using text.renderable = false when text is zoomed out (again zooming relates to pixi-viewport)
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'm working on a game using OpenGL displaying sprites, i.e. 2d quad-mapped graphics with no projection, that will be displayed on several different resolution screens. (i.e. iPhone retina/non-retina, iPad.. my next project the problem will expand to desktop resolutions which are far more numerous)
I'm OK with handling different aspect ratios, that can be handled by opengl and my placement of the sprites. I'm also OK with slightly different resolutions - use same art and either border the screen, or display a little bit more info.. but when things start to grow/shrink by like 50%+ it's a major issue.
What is standard procedure for generating the art assets in this situation? Generate for the largest resolution and just let OpenGL worry about resizing during it's rasterizing, or do people generate art sets for each main resolution?
Rasterized sprite art tends to get ugly when it's stretched (interpolated), so I'm concerned.. but generating different sizes really means for practical purposes I have to go with vector drawings and export several resolutions. Limits the artist and is somewhat complicated as far as loading and managing the assets
(Yes, I can "just try it" to an extent, but I already have an idea of the results. I'm looking for solutions people use and angles I maybe wouldn't have thought of. This question does have an answer(s) it's not subjective or lazy)
You are correct that scaling bitmaps tends to make sprites bad. There are a couple of ways of dealing with that:
Draw them (pixelart) at all required resolutions. That is a lot of work but gives you full control.
Draw them (vectors) and render them at all required resolutions. Less work but scaling up or down beyond 50% or 200% might give bad results.
Draw them (3D appliction) and render them at all required resolutions. Quite some work but a very consistent set of sprites.
For each of these options you are free to post-process the bitmaps to clean them up or add details but if you do this for options 2 and 3, you are breaking the chain and will have to apply the changes again when rendering the same set again.
An other option is to limit the variation of resolutions.
As far as I know it is very common in the (game) industry to make all (or the most used/visible) sprites as pixel perfect as possible. This is what they pay the artists for...
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.
I'm working on a game in XNA for Xbox 360. The game has 3D terrain with a collection of static objects that are connected by a graph of links. I want to draw the links connecting the objects as lines projected on to the terrain. I also want to be able to change the colors etc. of links as players move their selection around, though I don't need the links to move. However, I'm running into issues making this work correctly and efficiently.
Some ideas I've had are:
1) Render quads to a separate render target, and use the texture as an overlay on top of the terrain. I currently have this working, generating the texture only for the area currently visible to the camera to minimize aliasing. However, I'm still getting aliasing issues -- the lines look jaggy, and the game chugs frequently when moving the camera EDIT: it chugs all the time, I just don't have a frame rate counter on Xbox so I only notice it when things move.
2) Bake the lines into a texture ahead of time. This could increase performance, but makes the aliasing issue worse. Also, it doesn't let me dynamically change the properties of the lines without much munging.
3) Make geometry that matches the shape of the terrain by tessellating the line-quads over the terrain. This option seems like it could help, but I'm unsure if I should spend time trying it out if there's an easier way.
Is there some magical way to do this that I haven't thought of? Is one of these paths the best when done correctly?
Your 1) is a fairly good solution. You can reduce the jagginess by filtering -- first, make sure to use bilinear sampling when using the overlay. Then, try blurring the overlay after drawing it but before using it; if you choose a proper filter, it will remove the aliasing.
If it's taking too much time to render the overlay, try reducing its resolution. Without the antialiasing filter, that would just make it jaggier, but with a good filter, it might even look better.
I don't know why the game would chug only when moving the camera. Remember, you should have a separate camera for the overlay -- orthogonal, and pointing down onto the terrain.
Does XNA have a shadowing library? If so, yo could just pretend the lines are shadows.