It appears to me that gl_FragCoord is not sufficiently defined in the ES shading language specification: here
What is missing in my opinion is a specification of where pixel centers are supposed to lie: at integer coordinates or right between them. In contrast the regular Shading Language Specification of gl_FragCoord has this nailed down: here
Worse even I get mixed results on different platforms: An ARM Mali T604 seems to follow the .5 convention whereas an Adreno 330 seems to put the pixel centers at full integers (both tested on Android 4.4.2).
Can someone enlighten me on what's best practice here?
Going through the actual specification document, I found this:
1.1.4 Changes from OpenGL GLSL 3.3:
Removed:
* Layout qualifiers: index, origin_upper_left and pixel_center_integer
I don't know these qualifiers were omitted from OpenGL ES, and I couldn't find a clear mention which convention is the correct one (or if it's left for implementations to decide), although I think the traditional way is at half-integer coordinates. In any case, looks like you'll have to add some code to e.g. round the values down to get consistent behaviour.
By the way, the man pages are not to be trusted - they tend to omit a lot of stuff and contain errors. Specification is always the authority.
Related
I'm new to glTF and I would have a very basic, and maybe naive, question. Sorry, and thanks for your understanding and your help.
We have a C++ application where we handle geometry primitive entities, like boxes, cones, cylinders, and so forth.
For visualizing the geometry entities we currently use Coin3D, which have corresponding geometry shapes: Box, Cone, ...
We now would like to add a glTF exporter too, and I have started to explore the glTF specs.
I must say, in the official documentation, and on the web, I could not find any support in glTF for basic geometry shapes.
Therefore, my questions are:
is that true, that glTF has no notion of, let's say, a Box, or a Cone? Or did I missed something obvious?
If the answer to 1) is "NO", are there tested/supported/suggested implementations for basic shapes? I have only found some "example" shapes, like the Box here; but I could not find any collection of implementations of basic shapes. Again, did I miss something?
Are there any best practices, or documentation, on how to implement basic geometry shapes in glTF?
The short answer is you're correct, glTF does not currently store basic geometric shapes directly as a box, cone, cylinder, etc. The format is intended to be a runtime delivery format, not an asset interchange format.
As such, the internal data structures within glTF are designed to mimic the raw data that would typically be fed into a GPU using a graphics API such as OpenGL, WebGL, etc. Entire blocks of glTF data can often be pulled off a disk or network and handed over directly to a graphics API for rendering, with minimal pre-processing.
This means that all of your basic shapes must arrive as the GPU expects to find them: triangulated. Even a simple box is made up of twelve triangles, and because the sides don't share normal vectors, the normal "vertex attributes" are different, hence triangles from different sides of the box don't share vertices (again, because the GPU wouldn't accept that as a raw input). The benefit is that a WebGL client doesn't have to think very hard about what to do when it receives a glTF, it can just start cramming data into the graphics pipeline to get things moving.
For a broader overview, the ever-popular glTF - What the Duck diagram is widely considered an excellent starting point, and the glTF Tutorials are a good follow-up to that.
I can't find the word in any dictionary, neither in regular ones nor etymology ones. Only Wikipedia says:
The modern use of "shader" was introduced to the public by Pixar with their "RenderMan Interface Specification, Version 3.0" originally published in May 1988.
I know it's a program that runs on the GPU, but how did the Pixar guys come up with the name shader for it?
Although shader is not part of most dictionaries, the noun shading should be. dictionary.com, for example, defines it as
a slight variation or difference of color, character, etc.
This is is exactly what a shader does: It allows the programmer to add variations of color to a surface.
Shades is a very very very important factor in human vision. It allows recognizing shapes. And it's so because we live in a planet with plenty of shades, because of mainly Sun.
Realism needs shades. The Sun is not the only light. Conclusion: Good coloring implies shading from one or several lights. "Shaders" is the natural name for that programs that do it.
The SDL documentation for SDL_RenderCopy says that the texture will be stretched, but I can find absolutely no information about how the stretching will be done.
My experiments on Linux show that stretching is not anti-aliased. Can I rely on this? Will it behave the same way on other platforms? Will it not change in future versions?
Searching for anti-aliasing in SDL Wiki yields only 1 result, and it refers to the OpenGL configuration; the Wiki seems to be silent on how the stretching of textures is done. I’m writing a pixel-art game that won’t look good if anti-aliasing is applied, so I’d like to make sure it will never be anti-aliased.
Yes, it is guaranteed that by default SDL2 uses the nearest pixel stretching. You need to explicitly enable any other format by hinting it (explained at http://wiki.libsdl.org/SDL_HINT_RENDER_SCALE_QUALITY).
Good look at your game.
I'm trying to make a C++ OpenGL representation of our Solar System as a way to teach myself OpenGL, so please keep your answers simple.
The problem I have is that planets are very far away, so everything else is beyond the clipping plane when viewing from any given planet. How do I move the clipping of C++ OpenGL 3.1 plane to, say, 2000000000? I'd prefer a simple code snippet if you can.
I've looked up SO and forum posts about this, but they're either so old that nothing applies (using legacy APIs or just dead links), or so complex that I can't work out what they're saying.
Clipping planes are defined by the perspective projection matrix.
If you use glFrustum, change the last argument passed to it to 2000000000.0.
If you use your own matrix, set 10th element of your matrix array to:
(2000000000.0+nearClippingPlane)/(nearClippingPlane-2000000000.0)
(the formula is (far+near)/(near-far))
and 14th to:
(-4000000000.0*nearClippingPlane)/(2000000000.0-nearClippingPlane)
(the formula is (-2.0*near*far)/(far-near))
2000000000 is very big value, however, so Z-fighting may occur if you add details such as mountains.
I am looking for an algorithm or library (better) to break down a polygon into triangles. I will be using these triangles in a Direct3D application. What are the best available options?
Here is what I have found so far:
Ben Discoe's notes
FIST: Fast Industrial-Strength Triangulation of Polygons
I know that CGAL provides triangulation but am not sure if it supports holes.
I would really appreciate some opinions from people with prior experience in this area.
Edit: This is a 2D polygon.
To give you some more choices of libraries out there:
Polyboolean. I never tried this one, but it looks promising: http://www.complex-a5.ru/polyboolean/index.html
General Polygon Clipper. This one works very well in practice and does triangulation as well as clipping and holes holes: http://www.cs.man.ac.uk/~toby/alan/software/
My personal recommendation: Use the tesselation from the GLU (OpenGL Utility Library). The code is rock solid, faster than GPC and generates less triangles. You don't need an initialized OpenGL-Handle or anything like this to use the lib.
If you don't like the idea to include OpenGL system libs in a DirectX application there is a solution as well: Just download the SGI OpenGL reference implementation code and lift the triangulator from it. It just uses the OpenGL-Typedef names and a hand full of enums. That's it. You can extract the code and make a stand alone lib in an hour or two.
In general my advice would be to use something that alreay works and don't start to write your own triangulation.
It is tempting to roll your own if you have read about the ear-clipping or sweep-line algorithm, but fact is that computational geometry algorithms are incredible hard to write in a way that they work stable, never crash and always return a meaningful result. Numerical roundoff errors will accumulate and kill you in the end.
I wrote a triangulation algorithm in C for the company I work with. Getting the core algorithm working took two days. Getting it working with all kinds of degenerated inputs took another two years (I wasn't working fulltime on it, but trust me - I spent more time on it than I should have).
Jonathan Shewchuk's Triangle library is phenomenal; I've used it for automating triangulation in the past. You can ask it to attempt to avoid small/narrow triangles, etc., so you come up with "good" triangulations instead of just any triangulation.
CGAL has the tool you need:
Constrained Triangulations
You can simply provide boundaries of your polygon (incuding the boundaries of the holes) as constraints (the best would be that you insert all vertices, and then specify the constraints as pairs of Vertex_handles).
You can then tag the triangles of the triangulation by any traversal algorithm: start with a triangle incident to the infinite vertex and tag it as being outside, and each time you cross a constraint, switch to the opposite tag (inside if you were previously tagging the triangles as outsider, outside if you were tagging triangles as insider before).
I have found the poly2tri library to be exactly what I needed for triangulation. It produces a much cleaner mesh than other libraries I've tried (including libtess), and it does support holes as well. It's been converted to a bunch of languages. The license is New BSD, so you can use it in any project.
Poly2tri library on Google Code
try libtess2
https://code.google.com/p/libtess2/downloads/list
based on the original SGI GLU tesselator (with liberal licensing). Solves some memory management issues around lots of small mallocs.
You can add the holes relatively easily yourself. Basically triangulate to the convex hull of the input points, as per CGAL, and then delete any triangle whose incentre lies inside any of the hole polygons (or outside any of the external boundaries). When dealing with lots of holes in a large dataset, masking techniques may be used to significantly speed this process up.
edit: A common extension to this technique is to weed weak triangles on the hull, where the longest edge or smallest internal angle exceeds a given value. This will form a better concave hull.
I have implemented a 3D polygon triangulator in C# using the ear clipping method. It is easy to use, supports holes, is numerically robust, and supports aribtrary (not self-intersecting) convex/non-convex polygons.
This is a common problem in finite element analysis. It's called "automatic mesh generation". Google found this site with links to commercial and open source software. They usually presume some kind of CAD representation of the geometry to start.
Another option (with a very flexible license) is to port the algorithm from VTK:
vtkDelaunay2D
This algorithm works fairly well. Using it directly is possible, but requires links to VTK, which may have more overhead than you want (although it has many other nice features, as well).
It supports constraints (holes/boundaries/etc), as well as triangulating a surface that isn't necessarily in the XY plane. It also supports some features I haven't seen elsewhere (see the notes on Alpha values).