in OpenGL I have drawn a transparent cube in orthogonal projection, the enviroment has a front ligth.
The result is reported in figure.
What I don't understand is why there is a missing edge?
gl.Enable(OpenGL.GL_BLEND);
gl.BlendFunc(OpenGL.GL_SRC_ALPHA, OpenGL.GL_ONE_MINUS_SRC_ALPHA);
I use a DrawElements() function that uses indices.
Are there any suggestions?
This is caused by depth testing. OpenGL renders one triangle (or square) at a time. When depth testing is turned on, it skips rendering a pixel if it's already rendered something in front of that pixel. This is good for solid objects, but it doesn't work for transparent ones, because the back parts have to be rendered first or else they don't get rendered at all.
There are many ways to do transparency, but none of them are particularly nice. Unfortunately, whichever way you slice it, transparent objects are just not as easy to render as opaque ones.
So here are some ways to render transparent things:
Sort the faces and render back-to-front.
Sort the faces and render front-to-back, so the back is invisible.
Use face culling and render twice: cull front faces and render, then cull back faces and render. This gives the same effect as back-to-front by getting OpenGL to do it for you. Only works for convex objects (cubes are convex) and if you have more than one transparent object you still have to sort the objects.
Use face culling to cull back faces. This gives the same effect as rendering back-to-front, by getting OpenGL to do it for you. Same caveats as the previous one.
Use a different blending mode where the rendering order doesn't matter, such as multiplicative or additive, and turn depth testing off. Multiplicative blending mode removes light without adding it - looks like cellophane instead of stained glass - you'd need a white background. Additive blending mode looks like one of them sci-fi spaceship control screens - it makes its own light and you can also see through it.
Depth peeling and linked list buffers are two techniques which do separate sorting for each pixel, but they require more intense processing and very complicated shaders.
Raytracing (enough said)
If all the faces are the same colour, you can just turn depth testing off and it will look okay. Since the faces are all the same you can't tell they are rendered in the wrong order. This works for your red cube but it won't work if you add different colours or a texture.
To properly render a cube with a translucent interior, not just a translucent surface, you need a volumetric translucency effect which is also more complicated and out of scope here. You would render the back, the front, and apply a different amount of translucency depending on the distance between them.
I resolved thaks to user253751 putting this to instructions:
gl.Enable(OpenGL.GL_DEPTH_TEST);
gl.DepthFunc(OpenGL.GL_ALWAYS);
Related
How do I remove this "giggly" effect when slowly moving a sprite?
I have tried adjusting Antialiasing values in QualitySettings and Filter Mode in ImportSettings in the Unity Editor but that doesn't change anything.
Ideally, I would like to keep the Filter Mode to Point (no filter) and anti aliasing turned on to 2x
The sprite is located inside a Sprite Renderer component of a GameObject.
I have uploaded my Unity Project here: http://www.filedropper.com/sprite
I really don't know how to fix the problem... Can anyone help with my personal project?
I cooked up a quick animation to demonstrate what's happening here:
The grid represents the output pixels of your display. I've overlaid on top of it the sliding sprite we want to sample, if we could render it with unlimited sub-pixel resolution.
The dots in the center of each grid cell represent their sampling point. Because we're using Nearest-Nieghbour/Point filtering, that's the only point in the texture they pay attention to. When the edge of a new colour crosses that sampling point, the whole pixel changes colour at once.
The trouble arises when the source texel grid doesn't line up with our output pixels. In the example above, the sprite is 16x16 texels, but I've scaled it to occupy 17x17 pixels on the display. That means, somewhere in every frame, some texels must get repeated. Where this happens changes as we move the sprite around.
Because each texel is rendered slightly larger than a pixel, there's a moment where it completely bridges the sampling points of two adjacent pixels. Both sampling points land within the same enlarged texel, so both pixels see that texel as the nearest one to sample from, and the texel gets output to the screen in two places.
In this case, since there's only a 1/16th scale difference, each texel is only in this weird situation for a frame or two, then it shifts to its neighbour, creating a ripple of doubled pixels that appears to slide across the image.
(One could view this as a type of moiré pattern resulting from the interaction of the texel grid and the sampling grid when they're dissimilar)
The fix is to ensure that you scale your pixel art so each texel is displayed at the size of an integer multiple of pixels.
Either 1:1
Or 2:1, 3:1...
Using a higher multiple lets the sprite move in increments shorter than its own texel size, without localized stretching that impacts the intended appearance of the art.
So: pay close attention to the resolution of your output and the scaling applied to your assets, to ensure you keep an integer multiple relationship between them. The blog post that CAD97 links has practical steps you can take to achieve this.
Edit: To demonstrate this in the Unity project you've uploaded, I modified the camera settings to match your pixels to units setting, and laid out the following test. The Mario at the top has a slightly non-integer texel-to-pixel ratio (1.01:1), while the Mario at the bottom has 1:1. You can see only the top Mario exhibits rippling artifacts:
You might be interested in this blog post about making "pixel-perfect" 2D games in Unity.
Some relevant excerpts:
If you start your pixel game with all the default settings in Unity, it will look terrible!
The secret to making your pixelated game look nice is to ensure that your sprite is rendered on a nice pixel boundary. In other words, ensure that each pixel of your sprite is rendered on one screen pixel.
These other settings are essential to make things as crisp as possible.
On the sprite:
Ensure your sprites are using lossless compression e.g. True Color
Turn off mipmapping
Use Point sampling
In Render Quality Settings:
Turn off anisotropic filtering
Turn off anti aliasing
Turn on pixel snapping in the sprite shader by creating a custom material that uses the Sprite/Default shader and attaching it to the SpriteRenderer.
Also, I'd just like to point out that Unless you are applying Physics, Never Use FixedUpdate. Also, if your sprite has a Collider and is moving, it should have a Kinematic RigidBody attached even if you're never going to use physics, to tell the engine that the Collider is going to move.
Same problem here. I noticed that the camera settings and scale are also rather important to fix the rippling problem.
Here is What Worked for me:
Go to Project Settings > Quality
Under Quality Make the default Quality as High for all.
Set the Anistropic Texture to "Disabled"
Done, And the issue is resolved for me.
Image Reference:
enter image description here
I'm working on image transitions for my digital photo frame and am trying to achieve this transition:
It's more of a radar-style transition with the wiping effect going from one side to another in a 180 degree angle. Although, it doesn't appear that "blocky", I just spaced out the rectangles for illustration purposes. The entire thing should be a smooth transitions without any FPS stuttering effects.
My logic is to draw the specific part of the image at (theta) rotation angle like my drawing above - but that will end up drawing 100's of rectangles that sweeps across the screen.
Is there a more efficient way to do this? If not, could I have a few code tips to point me in the right direction?
It is practically impossible to have without any FPS shuttering especially in bigger screens because WinForms uses CPU only rendering. You will have to embed OpenTK (if you want to use OpenGL) or Direct3D frame inside, or maybe WPF where you do the animation.
If you use any of them (for example OpenGL), you have to load it as a texture, and the animation would be done on the triangle level (dragging the corners only) not on the image itself.
If you want to have a curved surface, like a real page transition, I recommend to use a bezier patch as is found here: http://nehe.gamedev.net/tutorial/bezier_patches__fullscreen_fix/18003/
This coding takes a lot of time, and is much more over the purpose of StackOverflow (to setup a full OpenGL/DirectX control + how to do a Bezier patch if you want to set it up).
If you don't want to embed anything, you may look to this transformations tutorial using WPF, but I'm not 100% sure that this is what you need:
http://www.codeproject.com/Articles/14895/WPF-Tutorial-Part-Transformations
I'm writing a game in c#, using opengl immediate mode rendering. Many times, transparent polygons do not appear correctly due to bring incorrectly sorted. I've been searching a lot but cannot find a tutorial on how to quickly do depth sorting. My attempt way be calculating the depth of each transparent triangle from the camera using List.sort, but that was incredibly slow ( seconds per frame, not frames per second)
Is there a standard way to do depth sortinng?
Are there any good tutorials for c# on how to do it?
Is there a fast way to do it?
Order-independent rendering of translucent polygons may be one of the most painful effects to get right in a generic manner. That's why people use various tricks with different tradeoffs between speed and quality. The simplest approach is to simply render your geometry in two passes:
Render all opaque geometry.
Disable depth-writes GL.DepthMask(false) and render your translucent geometry.
This way, your translucent polygons will be depth-tested against opaque polygons, but will not modify the depth buffer (i.e. they won't be depth-tested against other translucent polygons.)
This is simple, fast and avoids the necessity of sorting polygons. The downside is that it only works for translucent effects that use additive or multiplicative blending (the so-called "commutative" blend modes). For other blending effects, you will either have to sort your translucent polygons, or use a technique such as depth peeling.
References:
http://www.openglsuperbible.com/2013/08/20/is-order-independent-transparency-really-necessary/
https://gamedev.stackexchange.com/questions/43635/what-is-the-order-less-rendering-technique-that-allows-partial-transparency
https://developer.nvidia.com/content/interactive-order-independent-transparency
http://developer.download.nvidia.com/SDK/10/opengl/src/dual_depth_peeling/doc/DualDepthPeeling.pdf
I am working with C#, Monogame and XNA 4.0. In my scene I have a lot of cubes. Some are connected, some are not. I would like to render the edges of the cube with another shader than the filling. Besides that, I would like to render the outer edges of connected cubes in another color (or thicker) than the edges within the cube-object. Here is a small painting to make clear what I want to do (sorry for my bad painting skills, but I think you will get it).
I know how to render a cube with a specific shader and I am also able to render the wireframe but I was not able to connect both methods. Besids that, the outer lines can not be rendered differently with this approach.
I tried it with post-effects like the edgefinding of comic shaders but in this approach I am not able render only specific edges. Besides that if two cubes are next to each other the shader does not recognize the edges.
I am not searching for a ready-to-use solution from you but I would be glad to get some tips/approaches/tutorials/similar projects/etc on how to achieve my goal. Are there some shader experts out there? I am at my wit's end.
(If you however would like to post a ready to use solution I would not be miffy :D)
It is a shame you're not using deferred shading, this would be pretty straight forward to implement if you were.
If you can access the normal and material for each pixel on screen through a texture lookup you can easily post-process this. You could use a 3x3 filter kernel and search for sufficiently large normal discontinuities (this would catch silhouette edges) and also search for pixels that lie on the transition between material IDs (this would catch the edges between blue and orange cubes). If your filter neighborhood satisfied either of these two conditions, then draw a black pixel to form the outline.
You should be able to do this if you use MRT rendering when you draw your cubes, and encode the normal + material ID into an RGBA texture (x,y,z,material).
The basic theory is described in this paper (pp. 13). In this case instead of using the depth as the secondary characteristic for outlining, you would use the material (or object ID, if you want EVERY cube to have an outline).
I am making an RPG game using an isometric tile engine that I found here:
http://xnaresources.com/default.asp?page=TUTORIALS
However after completing the tutorial I found myself wanting to do some things with the camera that I am not sure how to do.
Firstly I would like to zoom the camera in more so that it is displaying a 1 to 1 pixel ratio.
Secondly, would it be possible to make this game 2.5d in the way that when the camera moves, the sprite trees and things alike, move properly. By this I mean that the bottom of the sprite is planted while the top moves against the background, making a very 3d like experience. This effect can best be seen in games like diablo 2.
Here is the source code off their website:
http://www.xnaresources.com/downloads/tileengineseries9.zip
Any help would be great, Thanks
Games like Diablo or Sims 1, 2, SimCity 1-3, X-Com 1,2 etc. were actually just 2D games. The 2.5D effect requires that tiles further away are exactly the same size as tiles nearby. Your rotation around these games are restricted to 90 degrees.
How they draw is basically painters algorithm. Drawing what is furthest away first and overdrawing things that are nearer. Diablo is actually pretty simple, it didn't introduce layers or height differences as far as I remember. Just a flat map. So you draw the floor tiles first (in this case back to front isn't too necessary since they are all on the same elevation.) Then drawing back to front the walls, characters effects etc.
Everything in these games were rendered to bitmaps and rendered as bitmaps. Even though their source may have been a 3D textured model.
If you want to add perspective or free rotation then you need everything to be a 3D model. Your rendering will be simpler because depth or render order isn't as critical as you would use z-buffering to solve your issues. The only main issue is to properly render transparent bits in the right order or else you may end up with some odd results. However even if your rendering is simpler, your animation or in memory storage is a bit more difficult. You need to animate 3D models instead of just having an array of bitmaps to do the animation. Selection of items on the screen requires a little more work since position and size of the elements are no longer consistent or easily predictable.
So it depends on which features you want that will dictate which sort of solution you can use. Either way has it's plusses and minuses.