I'm currently working on a XNA project where I need to create a Picture in picture Overlay to displaying a 3D scene from multiple angles. currently I'm trying to use 2 viewports to do this. The main one fills whole screen and is working as desired. The second is placed in one of the corners of the first (overlapping that corner) and is less than a 5th of the size as the first. apart from the size and placement of the viewports the only thing really difference between the 2 is the placement of their cameras with-in the scene.
As long as the second viewport is drawn second and there are no objects close to the camera of the first viewport in the overlapping corner this actually works greate. However if there is an object close to the camera and in the corner of the first viewport objects seem to experience occlusion culling as a result of the first viewport's object. The occluding object of the first viewport is not shown in the second viewports space though.
My question is how would one prevent the "cross viewport culling" from happening? I've searched all over and the closes threads I could find suggest drawing the second viewport to a RenderTarget2D and using a SpriteBatch to display the resulting texture. Though doing so does fix the occlusion issue it does mayhem on the z ordering, CCW culling, and my water effects all of which I've never had issue with using the default render target.
This issue, at least in my case, Seems to have been resolved by simply clearing the depth buffer between drawing the 2 Viewports. I did this by adding the following line between the function calls that draws the individual Viewports
GraphicsDevice.Clear(ClearOptions.DepthBuffer, Color.Black, 1, 0);
I ran in to this solution while trying to use the Stencil buffer to prevent the Main viewport from drawing under the second, but everything I did before this discovery did not really have a noticeable effect. After I removed all the Stencil code and it looks like I'm getting the desired effect. Sorry but I can't really explain how or why this works without messing up the first Viewport cause I have no clue myself.
Related
I'm using openseadragon with the excellent svg overlay plugin.
On Chrome, the app behaves as expected: users can tap to zoom in until a table rendered in SVG is fully visible, the note on the table is legible.
Here's the link to the demo. Zoom out to see the SVG version of the table appear, overlaying the fuzzy raster version of the background.
On Safari on iOS or OSX when zooming past a seemingly arbitrary threshold the table and everything on it start to disappear. The point of disappearance seems to depend on other factors I don't understand, hence this question for insight. For example, a orange circle drawn with two.js will disappear when the scale transform is precisely 51201 (at 51200 the circle is there). For the more complex table SVG, elements on the table will disappear at different scale levels, between ~23000 to 50000. Sometimes they'll disappear and then reappear upon a slight zoom in. Sometimes they'll disappear on zoom and then reappear as I pan around, the objects nearing the edge of the viewport.
IE 11 has a very similar issue.
Has anyone dealt with this before or solved it?
That's a really slick project!
In my experience, that kind of problem with SVG disappearing has to do with extreme amounts of zoom. The good news is you should be able to work around it by changing your viewport coordinates. By default the width of the image is a viewport value of 1, but you can set your image to be width 10,000 or some such, which will look exactly the same on the screen, but it means that the SVG thinks it's zoomed out a lot at first, so when you zoom in you can go a lot further.
If you're using two.js, another possible fix would be to switch over to canvas rendering and use https://github.com/altert/OpenSeadragonCanvasOverlay.
Btw, I'd love to share your project when it's done... please file a ticket at https://github.com/openseadragon/site-build/issues when you're ready and we can add it to http://openseadragon.github.io/examples/in-the-wild/.
UPDATE:
I have posted the code online to demonstrate the issue:
http://cutama.github.io/
To see the problem, position the mouse on the red rectangle and zoom in and out using the mouse scroller. After a while you will see the triangles flickering, then use the left mouse button to rotate.
Controls:
left mouse click&drag: orbit, middle mouse click&drag: pan, mouse scroll: zoom
END UPDATE
I have encountered a strange rendering problem with webgl. Whenever I moved the camera around, some triangles appear to be missing randomly. See pictures below.
I have been digging around but could not find the cause. Any ideas what may be causing this?
This is the normal rendering of the geometry:
Missing triangles:
Another missing triangles:
Did some debugging with webgl inspector.
GL Trace:
Clicking on the missing pixel show that it is being depth culled, but nothing is in front of it...so why is it culled?
Comparison with normal unculled pixel:
Vertex data inside the buffer. The triangles are very small. Is this causing the problem?
I don't know what makes this bug. But, I will list what you might need to consider.
Check you specified correct PrimitiveTopology(It should be gl.TRIANGLES in many case)
Check you rendered wether gl.DrawElements or gl.DrawArrays.
If you are using index buffer, you should use gl.DrawElements
Check you are using correct culling configuration.
Check you are using correct depth comparing function.(If you are not using depth test,you don't need to care about this)
Found the issue is caused by incorrect triangle indices in the model..still not sure why it would cause flickering.
I have a really weird problem. I render some triangles in the scene with D3D10 and what is surprising is that color values of these pixels are not clipped against near/far planes. On the other hand, depth values seem to be clipped fine. Evidence that this works as I have just described is as following:
when I render objects in the z-range that is "within" view frustum, everything is fine
when one object is inside the z-range and one is in front of it (between camera's eye and near plane), the objects inside the z-range "shines thhrough" the object that is closer. So z-buffering is working perfectly fine
I also checked output VS vertices values; all vertices that are outside the z-range and should be clipped (and they are in the z-buffer but are not in the color buffer) have their Z/W values outside [0, 1] interval
Idea idea what could be wrong? I think it might be some render state set incorrectly but I don't really know where to look.
I'm making your comment an answer, as it was exactly the issue I had in D3D11 (same in D3D10).
Make sure that you set DepthClipEnable to TRUE in any D3D11_RASTERIZER_DESC in question.
We are working on a Three.js based WebGL project, and have trouble understanding how transparency is handled in WebGL. The image shows a doublesided surface drawn with alpha = 0.7, which behaves correctly on its right side. However closer to the middle strange artifacts appear, and on the left side the transparency does not seem to work at all.
http://emilaxelsson.se/sandbox/vis1/alpha.png
The problem can also be seen here:
http://emilaxelsson.se/sandbox/vis1/
Has anyone seen anything similar before? What could the reason be?
Your problem is that transparent objects needs to be sorted and rendered in a back-to-front order (if you try to change the opacity of your mesh from 0.7 (transparent) to 1.0 (opaque), you can see that the z-buffer works just fine).
See:
http://www.opengl.org/wiki/Transparency_Sorting
http://www.opengl.org/archives/resources/faq/technical/transparency.htm (15.050)
In your case it might be less trivial to solve, since I assume that you only have one mesh.
Edit: Just to summarize the discussion below. It is possible to achieve correct rendering of such a double-sided transparent mesh. To do this, you need to create 6 versions of the mesh, corresponding to 6 sides of a cube. Each version needs to be sorted in a back-to-front order based on the 'side of the cube' (front, back, left, right, top, bottom).
When rendering choose the correct mesh (based on the camera viewing direction) and render that single mesh.
The easy solution for your case (based on the picture you attached), without going to expensive sorting and multiple meshes, is to disable depth test and enable face culling. That produces acceptable results if you do not have any opaque objects in front of the mesh.
To best illustrate the issue I'm having, I created a short screen grab. Watch it here: http://cl.ly/1o3p3x2e2J1a1d3d2N1Q
Basically, the stars on the screen, as they're animated across the screen from right to left, are dimming and brightening on their own. I'm not intending on this happening. When you zoom in, the issue disappears.
My hunch is that this has to do with the size of the objects being drawn and the pixel boundaries. Is this correct? What is the best way to go about fixing this issue?
Thanks!
---Edit---
Here's how I'm loading the texture: http://pastebin.com/RDc8x7Te
And, here's how I'm setting up OpenGL ES: http://pastebin.com/SpvAqPqA
You use nearest and linear for scaling textures, which are both not very accurate. You might want to use linear for both, or build mipmaps. Also in case you use an orthogonal view, try aligning your geometry on pixels.