I'm learning the Vulkan API, and I came across a little "problem":
Currently my program is able to draw, using the Projection-View-Model matrix transformation, a cube at the axis origin:
I'm using 3 images/imageViews/framebuffers, so for each transformation matrix I have a vector of size 3 that holds them, and everything work perfectly (no errors from the validation layers etc)... the problem is:
I now want to draw another object near my cube, so I thought I just had to update the model matrix twice every frame, the first time to position the cube, the second time for the other object, but this cannot work because the cube isn't drawn immediately when registering the command buffer, but when submitting it, so in the end the command buffer would simply use the second update of the model matrix for both the cube and the other object:
How to handle this situation?
Thanks.
Make the uniform buffer bigger put the second matrix after the first and point the second draw to the correct offset in the uniform buffer.
You can use either separate descriptors or dynamic offsets.
Related
I'm working with 3D meshes (mostly triangle meshes, though occasionally quad- or general polygonal meshes) for which I compute a value for each edge. This value I'd like to visualise using a colour map, i.e. render each edge in a colour corresponding to its associated value.
Is there a way to assign values to edges in WebGL that is more efficient than using a typical drawArrays approach? That is, looping over the edges and storing the vertices pair-wise in a buffer (resulting in a lot of duplicated x, y, z coordinate data) and introducing an additional vertex attribute storing the edge value (the same value for both vertices)?
In OpenGL, I'd use a drawElements approach, store the edge values in a texture (or buffer texture), and then use gl_PrimitiveID in the fragment shader to look up the relevant edge value for the edge currently being processed. Unfortunately, WebGL doesn't know about gl_PrimitiveID, and I don't see a way to emulate it. I briefly thought about instanced rendering (using gl_InstanceID), but that would complicate things and probably end up not being much more efficient...
I am working on an Android application that slims or fatten faces by detecting it. Currently, I have achieved that by using the Thin-plate spline algorithm.
http://ipwithopencv.blogspot.com.tr/2010/01/thin-plate-spline-example.html
The problem is that the algorithm is not fast enough for me so I decided to change it to OpenGL. After some research, I see that the lookup table texture is the best option for this. I have a set of control points for source image and new positions of them for warp effect.
How should I create lookup table texture to get warp effect?
Are you really sure you need a lookup texture?
Seems that it`d be better if you had a textured rectangular mesh (or a non-rectangular mesh, of course, as the face detection algorithm you have most likely returns a face-like mesh) and warped it according to the algorithm:
Not only you`d be able to do that in a vertex shader, thus processing each mesh node in parallel, but also it`s less values to process compared to dynamic texture generation.
The most compatible method to achieve that is to give each mesh point a Y coordinate of 0 and X coordinate where the mesh index would be stored, and then pass a texture (maybe even a buffer texture if target devices support it) to the vertex shader, where at the needed index the R and G channels contain the desired X and Y coordinates.
Inside the vertex shader, the coordinates are to be loaded from the texture.
This approach allows for dynamic warping without reloading geometry, if the target data texture is properly updated — for example, inside a pixel shader.
I am really having a problem with this.
I have a polygon (a quad) which can be any shape. When my mouse is inside the polygon I need to find the x,y values of where my mouse is (inside the quad) as though the poygon were are perfect square. Further explanation; I have a 32x32 texture applied to the polygon and I need to know the x,y of the texture that the mouse is over.
I have some code that works for most shapes but which breaks if TR.Y is less than TL.y for instance.
I have some pretty simple code that tests whether the cursor is inside the polygon (via two triangle tests). But I cannot figure out how to use this to generate an x,y of a virtual square projection.
This problem is killing me. What is the name of operation i am trying to perform? Does anyone know of an explanation where the equations are presented in code form (any kind of code) (rather than just mathematical notation?). Any kind of help would be so appreciated.
I am on the verge of doing a 2nd render with specially formatted textures (each pixel having a unique value) so that I can just colour test to get an approximate x,y match (and precision is something that can be compromised here without causing too much trouble) - but then I will have to work around the DX Lib's attempt to blend and smooth the special texture as it is warped to fill the quad)
**Edit: Code that works for many quad shapes
It depends on method - how the texture is drawn at this quad.
If it uses perspective transform Square=>Quad, you have to use matrix of inverse transform Quad=>Square. Short article
For linear interpolation approach see this page
I am trying to write a little script to apply texture to rectangular cuboids. To accomplish this, I run through the scenegraph, and wherever I find the SoIndexedFaceSet Nodes, I insert a SoTexture2 Node before that. I put my image file in the SoTexture2 Node. The problem I am facing is that the texture is applied correctly to 2 of the faces(say face1 and face2), in the Y-Z plane, but for the other 4 planes, it just stretches the texture at the boundaries of the two faces(1 and 2).
It looks something like this.
The front is how it should look, but as you can see, on the other two faces, it just extrapolates the corner values of the front face. Any ideas why this is happening and any way to avoid this?
Yep, assuming that you did not specify texture coordinates for your SoIndexedFaceSet, that is exactly the expected behavior.
If Open Inventor sees that you have applied a texture image to a geometry and did not specify texture coordinates, it will automatically compute some texture coordinates. Of course it's not possible to guess how you wanted the texture to be applied. So it computes the bounding box then computes texture coordinates that stretch the texture across the largest extent of the geometry (XY, YZ or XZ). If the geometry is a cuboid you can see the effect clearly as in your image. This behavior can be useful, especially as a quick approximation.
What you need to make this work the way you want, is to explicitly assign texture coordinates to the geometry such that the texture is mapped separately to each face. In Open Inventor you can actually still share the vertices between faces because you are allowed to specify different vertex indices and texture coordinate indices (of course this is only more convenient for the application because OpenGL doesn't support this and Open Inventor has to re-shuffle the data internally). If you applied the same texture to an SoCube node you would see that the texture is mapped separately to each face as expected. That's because SoCube defines texture coordinates for each face.
I'm using SharpDX and I want to do antialiasing in the Depth buffer. I need to store the Depth Buffer as a texture to use it later. So is it a good idea if this texture is a Texture2DMS? Or should I take another approach?
What I really want to achieve is:
1) Depth buffer scaling
2) Depth test supersampling
(terms I found in section 3.2 of this paper: http://gfx.cs.princeton.edu/pubs/Cole_2010_TFM/cole_tfm_preprint.pdf
The paper calls for a depth pre-pass. Since this pass requires no color, you should leave the render target unbound, and use an "empty" pixel shader. For depth, you should create a Texture2D (not MS) at 2x or 4x (or some other 2Nx) the width and height of the final render target that you're going to use. This isn't really "supersampling" (since the pre-pass is an independent phase with no actual pixel output) but it's similar.
For the second phase, the paper calls for doing multiple samples of the high-resolution depth buffer from the pre-pass. If you followed the sizing above, every pixel will correspond to some (2N)^2 depth values. You'll need to read these values and average them. Fortunately, there's a hardware-accelerated way to do this (called PCF) using SampleCmp with a COMPARISON sampler type. This samples a 2x2 stamp, compares each value to a specified value (pass in the second-phase calculated depth here, and don't forget to add some epsilon value (e.g. 1e-5)), and returns the averaged result. Do 2x2 stamps to cover the entire area of the first-phase depth buffer associated with this pixel, and average the results. The final result represents how much of the current line's spine corresponds to the foremost depth of the pre-pass. Because of the PCF's smooth filtering behavior, as lines become visible, they will slowly fade in, as opposed to the aliased "dotted" line effect described in the paper.