Sorry folks for posting such a trivial issue! The issue is solved. I was using the wrong function. Here goes the correct one:
float len = glm::length(testVec);
The member function of the same name returns the number of components instead (i.e. vec2::length will always yield 2, vec3::length will always yield 3, etc.).
OpenGL is a state machine. An OpenGL context holds that state. The state contains information such as which textures are bound to which texture units, which attachments the current FBO has, and things like that.
When you set the current context, you are switching all the state from the old context to the new context. Here's an example:
In DX12, a descriptor is a small record, basically a pointer, that tells the GPU where to find some data such as a constant buffer. Since each object is going to have its own constant buffer data with its own particular transforms, lighting/material properties, etc., each object also has to end up with a separate set of descriptors to point to its individual ...
The direction vectors start at +15 degrees on the YZ plane, and continue in increments of -2 degrees down to -15.
There's your problem—by generating the rays that way, you're doing something more like a spherical projection or fisheye projection, not a linear perspective projection. The nonlinear projection is the origin of the curvature you see.
To get a ...
Why are they deprecated?
Those functions are deprecated because the OpenGL API moved in favor of a programmable pipeline in contrast with the old fixed pipeline. The programmable pipeline allows the flexibility necessary to enable a wide variety of effects and solutions that before were difficult or not possible at all to implement. You can still access ...
Rather than using an image, I would suggest doing this kind of effect using a shader. I'm not familiar with Cocos2d-x, but some quick googling suggests that it can work with shaders. You'd use a pixel shader that calculates the distance of each pixel to the center of the pulse effect, then applies a function based on that distance to define the shape and ...
I believe a common solution is to split the camera transform used to project the grid from the camera transform that is used to render the grid. At perspectives close to top-down, the two cameras coincide, but as the viewing camera gets close to a horizontal perspective, the projection camera deviates and tries to keep a minimum inclination, i.e. it hovers ...
Figured it out :) The dominos are now being placed along the X and Y coordinates generated by the function.
The original code in the question was plotting a wave of points outwards from the centre position or origin and was not what I wanted. What I needed was for each point to follow the Archimedean spiral with a certain space between the spirals.
This is not really a CG issue but you appear to have an integer division problem. Assuming mMaxThreads is an integer, (threadIndex / mMaxThreads) is always 0 and ((threadIndex + 1) / mMaxThreads) is 0 for all threads but the last one, where it is 1. So one thread is doing all the work.
Practically speaking, probably not - try printing the size of each type using sizeof. Probably GLuint is 32 bits and size_t is 64 bits - so 32 bits are thrown out; but float and GLfloat are probably both 32 bit IEEE 754 numbers. "Probably" sprinkled above, because technically speaking the sizes of C ints, floats and the float format are compiler dependent, ...
Your if condition makes me suspicious. You should include the diffuse and specular shading if the intersection test didn't hit an object; that is, if intersections > ldist. So, your code should look as follows:
if (intersections > ldist)
colour += diffuse(...);
colour += specular(...);
Your comparison with 0.0000001f suggests that you've ...
You can be both realistical and real-time. the secret is to change representation each time the information get under the Shannon-Nyquist (i.e. grid) scale: from geometry to normal maps to shading models. This paper is made for you: http://maverick.inria.fr/Publications/2010/BNH10/index.php (see also Yoube videos)
The problem appears to be unintentionally transparent surfaces
Although the image is grainy, it is sufficiently clear to estimate that all of the darker regions are due to surfaces facing away from the light, rather than due to shadows cast onto surfaces facing towards the light. So it does seem that there is a problem, and the lack of shadows is not just ...
The counter you want is built in the shader as gl_VertexID.
However you have 16 attributes of 4 components each to work with. Take 2 components for the texture coordinates and you have 62 float values to play with. If you need 6 components per blend shape (3 pos + 3 normal) you get 10 blend shapes to work with per object per frame. If you leave off the ...
Short answer, set the precision of the image to a higher value.
When looking at a gamma correction curve, you can see that the lower values get changed much more, this means that the difference between lower values will get greater and that causes this effect. You have a limited amount of values for a color channel and this means that when it ...
Many years ago I worked on a ray tracer that handled parametric surfaces, so this is unlikely to be state of the art, but, IIRC, I used a combination of interval arithmetic with (binary?) subdivision and Newton-Rhapson.
The interval arithmetic + subdivision constructed (conservative) bounding boxes which could be used for intersection rejection. I think I ...
is it correct having such a big light?
I don't see any problem with having a big area light. That said, it also depends on the scale of your scene. If the light is large compared to it, shadows will tend to be more diffuse, like under an overcast sky.
shadows are missing.. [...] Can you help me understanding why?
I haven't found any blatant mistake, but ...
Firstly, as @trichoplax correctly pointed out, your randomPoint function calculates a point in a cube, then uses rejection sampling to return all points that are inside a unit sphere. In order to return points on a sphere, you would need to change the greater than to an equals. That said, rejection sampling is very inefficient.
A better way to sample a ...
Vector has a few different semantics from static arrays. For one it's a struct containing a pointer a capacity and a length (at the very least). That means that sizeof will not reflect how much data is actually stored in there (that only works on static arrays).
If you need to get the size in bytes of the data then you need
const UINT vertexBufferSize = ...
The problem is actually in your fragment shader:
color_out = texture(source_image, gl_FragCoord.xy);
The texture() function accepts normalized coordinates which range from 0.0 to 1.0. The gl_FragCoord built in contains window coordinates which range from (0.0, 0.0) to (window width, window height).
To fix this, change the fragment shader to this:
Front-to-back traversal is the idea that when traversing a ray through the acceleration structure, we want to examine nodes that are in front, i.e. closer to the camera, before other nodes. If you only want the first intersection with a surface (as usual in ray tracing), then if you get an intersection in the front node you don't need to traverse any nodes ...
The parametric equation for a spiral is:
x &= &(a + b \theta) \times \cos(\theta)\\
z &= &(a + b \theta) \times \sin(\theta)
The direction on the spiral point is simply the derivative of the system with respect to $\theta$. Thus the direction is:
The vertex shader only runs per vertex, not for every point in the square. So the four vertices are mapped to (±2, ±2), and then the GPU draws a polygon between those vertices, which does cross the viewport.
The points interior to the polygon do not go through the v.y = v.y/v.z transform, so the resulting point set is not $(-\infty,-2] \cup [2,\infty)$ ...
This isn't really a direct answer to this question (that already has an answer anyway), but might interest people who want to implement this algorithm in 3D.
I had to try implementing this algorithm to generate 3D spirals in blender using Python (could easily be converted to drawing with PIL or Matplotlib in 2D). So here's the algorithm and result:
Instead of using a perspective projection you would use a orthographic projection.
Then the trick is to position the bounding box to in front of the normal camera.
An additional option is to add a skew/shear operation so it maps the light direction to the vertical and keeps the horizontal ground plane horizontal.
This avoids leaving a large dead zone ...
I don't have any experience with Gradient Domain Path Tracing, but here are my thoughts:
There seems to be a different problem
If you look carefully at the little spikes of distortion in the final image, you will see that they are all lit from the same direction - on their top left side at a consistent 45 degrees. The sphere also appears to be lit from ...
What you are looking for is a way to get access to individual pixels in an image, in a way that you can modify those pixels with CPU code.
Once you have that you'll want to find software rendering / software rasterization methods.
A great place to start would be reading up in the various bresenham algorithms.
There is a lot of info out there on that. Here ...
There appear to be two problems with the image.
The background is showing through along the line between adjacent triangles.
The colour displayed is not always from the closest intersection.
Note that the background colour is white, rather than black, due to the line:
PutPixelSDL(screen, x, y, vec3(1, 1, 1));
Why this ...
My advice would actually be to stick with solution 1 unless and until something more is needed. It's the simplest and easiest to understand, and it should be quite feasible to make it perform well.
On the one hand, it may seem wasteful to re-filter the points and re-upload a bunch of data to the VBO every frame. I guess that this is why you say it is a "bad ...
According to the GLFW docs, the context version hint acts as a minimum version, i.e. the context you actually get may be a higher version than what you request. However, the context should be backward-compatible, so even if you get a GL 3.x context you're OK to use GL 2.x code.