I understand that most textures are normalized except GL_TEXTURE_RECTANGLE.
However, I can't find information on GL_TEXTURE_EXTERNAL_OES. Are the coordinates normalized or in the range of [0, imageWidth], [0, imageHeight]?
I would also appreciate if you mention where you got the information from. I couldn't find it on khronos website.
They use normalized texture coordinates. You can address them with texture coordinates in the range [0.0, 1.0]. While it might have been nice to point that out in the extension spec, they probably thought it was not necessary because it's just like all other textures in OpenGL ES.
Source: Tried it on a Kindle Fire HDX 7" tablet.
Like you I frustratingly couldn't quickly find a definitive statement. However...
The extension documentation for OES_EGL_image_external mentions both that:
Their default min filter is LINEAR. It is an INVALID_ENUM error to set the min filter value to anything other than LINEAR or NEAREST.
And:
The default s and t wrap modes are CLAMP_TO_EDGE and it is an
INVALID_ENUM error to set the wrap mode to any other value.
Which are pretty clear clues that coordinates aren't normalised if you're used to dealing with non-power-of-two textures. Indeed the whole tenor of the extension — that one to three hardware sampling units may be used, that some varyings may be lost and that only a single level-of-detail is permitted — strongly reserves the right for an implementation to do the exact same thing as if you'd sampled Y, U and V separately from non-power-of-two sources and combined them arithmetically yourself.
But in terms of providing a thorough finger-on-paper answer: CLAMP_TO_EDGE is defined by the appropriate man page as:
GL_CLAMP_TO_EDGE causes coordinates to be clamped to the range (1/2N, 1 - 1/2N), where N is the size of the texture in the direction of
clamping.
... which, again, makes little sense if coordinates were normalised (though it wouldn't actually be undefined).
So I'm willing to gamble strongly that they're not normalised.
Related
I want to export an image in Google Earth Engine and I want the pixel size to match some in-situ plots with dimensions 2mx30m. How can I set the scale parameter to match this diamesions?
What I currently have (for pixel size 30mx30m):
var myimage= sat_image.reduceRegions(my_points, ee.Reducer.first(),30)
print(myimage)
Export.table.toDrive(myimage,
"pts30",
"insitu_points")
Instead of specifying the scale parameter, specify a crsTransform parameter. It is a “a row-major ordering of the 3x2 transform matrix”, as the documentation puts it, which means that you should specify a list of numbers like
crsTransform=[xScaling, 0, 0, 0, yScaling, 0]
Note that these numbers are not the same as the scale parameter. The scale parameter specifies meters of nominal scale per pixel. These number specify distance in the projection's coordinate system per pixel. For example, if the projection's numerical units are degrees, then the crsTransform factors are degrees per pixel. Thus, it is usually a good idea to specify a crs together with crsTransform so that you know what projection you're measuring with.
Also, this may not be the best option for such very non-square pixels. Consider, instead of using reduceRegions on points, converting your points to rectangle features and then using reduceRegion with a mean reducer. This will have a similar effect, but lets you choose the exact shape you want to sample with.
I'm not sure how well either option will work or whether there are further issues to deal with — I haven't done anything like this myself. But I looked around and there is very little discussion crsTransform at all, so I figured it was worth writing up.
The specs for the web audio API dynamic compressor node refer to some curve being drawn over various decibel values. How can I visualize that curve?
For filter nodes, the web audio API provides a getFrequencyResponse method that produces data that can be visualized on a 2D canvas.
Is there a similar method for the dynamic processor node? Or are there well-known formulas used to compute the magnitude of the node's effect on various dB values?
I'm not sure exactly how to calculate the curve for knee, but I'm pretty sure it shouldn't be super difficult. Ignoring the knee, here's what you'd need:
First, you'd start out with a line that has a slope of 1 (45 degree angle, up and to the right). Another way of saying that is that output = input
Then, when you hit threshold, you change the slope of the line to match your compression ratio. So if your ratio is 2.3:1, your slope above the threshold would be output = input / 2.3.
Anyway, I'm sure if you do some searching, you can figure out how to factor in the knee. It's probably just a parabola that joins the two slopes (with a vertex at the point where they would normally intersect if the knee was 0). Then you just need to figure out what the value does, but if you read the Web Audio spec, the unit for knee is dB – which leads me to believe this isn't really implementation-specific. I think there probably is a Right Way™ to do it.
Unfortunately there is no way to examine easily the effect of the dynamic compressor node. And the actual implementation isn't specified in the WebAudio spec. The only way to know the effect is to examine the source code. Or perhaps feed a sine wave of different frequencies to the node and examine the output to see what is happening, experimentally. This might be hard to capture the effect of all of the parameters.
I am making a game that involves solving a path through graphs. Depending on the size of the graph this can take a little while so I want to cache my results.
This has me looking for an algorithm to hash a graph to find duplicates.
This is straightforward for exact copies of a graph, I simply use the node positions relative to the top corner. It becomes quite a bit more complicated for rotated or even reflected graphs. I suspect this isn't a new problem, but I'm unsure of what the terminology for it is?
My specific case is on a grid, so a node (if present) will always be connected to its four neighbors, north, south, east and west. In my current implementation each node stores an array of its adjacent nodes.
Suggestions for further reading or even complete algorithms are much appreciated.
My current hashing implementation starts at the first found node in the graph which depends on how i iterate over the playfield, then notes the position of all nodes relative to it. The base graph will have a hash that might be something like: 0:1,0:2,1:2,1:3,-1:1,
I suggest you do this:
Make a function to generate a hash for any graph, position-independent. It sounds like you already have this.
When you first generate the pathfinding solution for a graph, cache it by the hash for that graph...
...Then also generate the 7 other unique forms of that graph (rotated 90deg; rotated 270deg; flipped x; flipped y; flipped x & y; flipped along one diagonal axis; flipped along the other diagonal axis). You can of course generate these using simple vector/matrix transformations. For each of these 7 transformed graphs, you also generate that graph's hash, and cache the same pathfinding solution (which you first apply the same transform to, so the solution maps appropriately to the new graph configuration).
You're done. Later your code will look up the pathfinding solution for a graph, and even if it's an alternate (rotated, flipped) form of the graph you found the earlier solution for, the cache already contains the correct solution.
I spent some time this morning thinking about this and I think this is probably the most optimal solution. But I'll share the other over-analyzed versions of the solution that I was also thinking about...
I was considering the fact that what you really needed was a function that would take a graph G, and return the "canonical version" of G (which I'll call G'), AND the transform matrix required to convert G to G'. (It seemed like you would need the transform so you could apply it to the pathfinding data and get the correct path for G, since you would have just stored the pathfinding data for G'.) You could, of course, look up pathfinding data for G', apply the transform matrix to it, and have your pathfinding solution.
The problem is that I don't think there's any unambiguous and performant way to determine a "canonical version" of G, because it means you have to recognize all 8 variants of G and always pick the same one as G' based on some criteria. I thought I could do something clever by looking at each axis of the graph, counting the number of points along each row/column in that axis, and then rotating/flipping to put the more imbalanced half of the axis always in the top-or-left... in other words, if you pass in "d", "q", "b", "d", "p", etc. shapes, you would always get back the "p" shape (where the imbalance is towards the top-left). This would have the nice property that it should recognize when the graph was symmetrical along a given axis, and not bother to distinguish between the flipped versions on that axis, since they were the same.
So basically I just took the row-by-row/column-by-column point counts, counting the points in each half of the shape, and then rotating/flipping until the count is higher in the top-left. (Note that it doesn't matter that the count would sometimes be the same for different shapes, because all the function was concerned with was transforming the shape into a single canonical version out of all the different possible permutations.)
Where it fell down for me was deciding which axis was which in the canonical case - basically handling the case of whether to invert along the diagonal axis. Once again, for shapes that are symmetrical about a diagonal axis, the function should recognize this and not care; for any other case, it should have a criteria for saying "the axis of the shape that has the property [???] is, in the canonical version, the x axis of the shape, while the other axis will be the y axis". And without this kind of criteria, you can't distinguish two graphs that are flipped about the diagonal axis (e.g. "p" versus "σ"/sigma). The criteria I was trying to use was again "imbalance", but this turned out to be harder and harder to determine, at least the way I was approaching it. (Maybe I should have just applied the technique I was using for the x/y axes to the diagonal axes? I haven't thought through how that would work.) If you wanted to go with such a solution, you'd either need to solve this problem I failed to solve, or else give up on worrying about treating versions that are flipped about the diagonal axis as equivalent.
Although I was trying to focus on solutions that just involved calculating simple sums, I realized that even this kind of summing is going to end up being somewhat expensive to do (especially on large graphs) at runtime in pathfinding code (which needs to be as performant as possible, and which is the real point of your problem). In other words I realized that we were probably both overthinking it. You're much better off just taking a slight hit on the initial caching side and then having lightning-fast lookups based on the graph's position-independent hash, which also seems like a pretty foolproof solution as well.
Based on the twitter conversation, let me rephrase the problem (I hope I got it right):
How to compare graphs (planar, on a grid) that are treated as invariant under 90deg rotations and reflection. Bonus points if it uses hashes.
I don't have a full answer for you, but a few ideas that might be helpful:
Divide the problem into subproblems that are independently solvable. That would make
How to compare the graphs given the invariance conditions
How to transform them into a canonical basis
How to hash this canonical basis subject to tradeoffs (speed, size, collisions, ...)
You could try to solve 1 and 2 in a singe step. A naive geometric approach could be as follows:
For rotation invariance, you could try to count the edges in each direction and rotate the graph so that the major direction always point to the right. If there is no main direction you could see the graph as a point cloud of its vertices and use Eigenvectors and Priciple Compoment Analysis (PCA) to obtain the main direction and rotate it accordingly.
I don't have a smart solution for the reflection problem. My brute force way would be to just create the reflected graph all the time. Say you have a graph g and the reflected graph r(g). If you want to know if some other graph h == g you have to answer h == g || h == r(g).
Now onto the hashing:
For the hashing you probably have to trade off speed, size and collisions. If you just use the string of edges, you are high on speed and size and low on collisions. If you just take this string and apply some generic string hasher to it, you get different results.
If you use a short hash, with more frequent collisions, you can get achieve a rather small cost for comparing non matching graphs. The cost for matching graphs is a bit higher then, as you have to do a full comparison to see if they actually match.
Hope this makes some kind of sense...
best, Simon
update: another thought on the rotation problem if the edges don't give a clear winner: Compute the center of mass of the vertices and see to which side of the center of the bounding box it falls. Rotate accordingly.
I have set up a frustum with fov=50, near=0.1,far=1000,aspect ratio=3/2
yet it isn`t coming nice--my object appears to be compressed on far side.suggest something that might help.
A screenshot would help. But I think I understand your problem. What you're observing are the effects of an affine projection. The parameter fov is a bit misleading, as it might suggest you have some angular projection (fisheye) which is not the case. What actually happens is, that the extents of the near projection plane are placed so that it's borders are seen under the fov angle. However the near plane is just that, flat that means, so very large fovs look very unnatural.
I don't know the specs of the iPhone's graphics capabilities from heart, but if I'm not mistaken it supports vertex shaders. So instead of the affine frustum projection method you could implement a totally different kind of projection model, like sterographic or mercator (depending on what your needs are). Operations are then no longer performed in terms of linear matrix multiplication.
As a side note: Those values for near and far distance are too extreme, almost all of the depth buffer precision will be between 0.1 and ~20, due to the nonlinearity of depth buffering in perspective mode.
can someone point me to a paper/algorithm/resource/whatever that tells me how to implement a texture minification filter (applies when texels are smaller than pixels) in a raytracer?
thanks!
Since you are using ray tracing I suspect you are looking for a high quality filtering that changes sampling dynamically based on the amount of "error". Based on this assumption I would say take a look at "ray differentials". There's a nice paper on this here: http://graphics.stanford.edu/papers/trd/ and it takes effects like refraction and reflection into account.
Your answer to yourself sounds like the right approach, but since others may stumble across the page I'll add a resource link as requested. In addition to discussing mipmapping (ripmapping is basically more advanced mipmapping), they discuss the effects of reflection and refraction on derivatives and mip-level selection.
Homan Igehy. "Tracing Ray Differentials." 1999. Proceedings of SIGGRAPH. http://graphics.stanford.edu/papers/trd/
Upon closer reading I see that Rehno Lindeque mentioned this paper. At first didn't realize that it was the right reference because he says that the method samples dynamically based on the error of the sampling, which is incorrect. Filtering is done based on the size of the pixel's footprint and uses only one ray, just as you described.
Edit:
Another reference that might be useful ( http://www.cs.unc.edu/~awilson/class/238/#challenges ). Scroll to the section "Derivatives of Texture Coordinates." He suggests backward mapping of texture derivatives from the surface to the screen. I think this would be incorrect for reflected and refracted rays, but is possibly easier to implement and should be okay for primary rays.
I think you mean mipmap'ing.
Here is an article talking about using them.
But nether say how to chose which mipmap to use, but they are often blended (the bigger and smaller mipmap).
Here's a one more article about how Google Earth works, and it talks about how they mipmapping the earth.
thank you guys for your answers, but since I didn't find any appropriate techinque i created something myself which turned out to work very well:
i assume my ray to be a cone with a coneradius of half a pixel on the imageplane. when the ray hits a surface, i calculate the ellipse which is projected onto the surface (the ellipse from the plane-cone intersection). Then, using the texturecoordinate derivatives at the intersection point, i project this ellipse into texturespace. now i know which part of the texture lies under my pixel and can subsample this area
I Also use RipMaps to improve the quality - and i chose the RipMap level based on the size of the ellipse in Texturespace