Tag Info

New answers tagged

0

I have founded the solution: https://www.youtube.com/watch?v=xf0VD4ba4ns In this video's desc link shows a file that I used to the new code wich is working


2

boost::ptr_vector is, underneath the hood, a std::vector<void *>. Not only is it not possible to use the ptr_vector to directly supply an input to glBufferData (et cetera), but it is a phenomenally bad way to store vertex data in general because of the extremely poor cache locality of the data If you were to use std::vector<vertex> vertices; ...


0

In order to transform the hemisphere points into the space of the normal, you need to set up a coordinate frame. Your second example is closer to something which will work, but keep in mind that you should only construct M once. Basically, your code fails because it makes a comparison between vectors. Such operations make very little geometric sense, because ...


0

For further reference, I came through the exact same problem and added the answer to this with code here: http://stackoverflow.com/questions/24910929/use-of-gldrawelements-i-dont-understand


0

Update drivers. Find an OpenGL 4.0 to 1.2 wrapper API. (Good luck with that.) Use mesa3D, and compile it as a software implementation of OpenGL. This, however, will still result in something too slow for realtime-rendering. Get a better computer/graphics-card. Use DirectX. (If it has better support.)


0

I am not super familiar with the topic but I did do a little digging for you to try and come up with some easy to understand tutorials or articles. I hope you find at least one of these useful to you. I tried to avoid links that used deferred rendering. Link One Link Two Tutorials Advanced Rendering in OpenGL Random Tutorial Website


1

I'm not exactly sure what you want to hear, but I think deferred lighting is still the best for many light sources. The way you do that is that first you gather all the geometry properties by rendering the scene without any lighting at all. You basically render the scene in 4 versions into a buffer called G-Buffer: color, normal, depth, position. You may ...


1

Are you dynamically creating the buffer for the draw call each frame? If the walls never (or rarely) change then a vbo will be a good optimization.


1

It might sound dumb, but make sure V-Sync is not enabled. And yes, reduce the draw calls to gain fps. If you have multipled shaders and textures, make sure you don't make unnecessary switches between them, like first draw all objects which use texture0 and not one object with texture0, then another one with texture1 and then back to texture0 etc. really try ...


0

Yes. The standard OpenGL headers are all written for C, although the book is written in C++ so that they can use their supplied classes. Most windowing frameworks, including SDL and GLFW, as well as GLEW for loading extensions, are also written in C. Even SFML has a set of C bindings.


0

You can use OpenGL natively in either C or C++, the API has always been implemented in C. You can also use OpenGL calls in C++ exactly the same way you would in C.


2

OpenGL is natively written in C. For C++ you usually use wrappers. So yeah, don't worry, it'll work just fine in C as always :) I would suggest to read a more modern book though, a lot has changed with OpenGL 3+.


2

They are not equivalent. In the GLSL shader you use the same texture coordinate for your diffuse and normal map (gl_TexCoord[0]). In the CG shader you use separate ones (TEXCOORD0 and TEXCOORD1, which is presumably not set).


3

Another way to do this is to make a texture that maps each RGB to a colour on the palette, an image like this (from the NES colours): Then in a post processing shader you can the RGB colour from your regular image in a way like this: uniform sampler2d paletteMapping; vec3 mapColor( vec3 realColor ) { vec3 mappedColors = floor( realColor * 16 ); ...


0

This problem is called Color quantization. Basically for each pixel you want to find a closest color present in the palette. This can be done by partitioning the 3D color space into regions each of which containing exactly one palette color. The partitioning can be performed using e.g. Voronoi diagram, octree or any other spatial partitioning data structure. ...


0

I'm not using a tessellation shader but I just ran a quick test trying to skip a variable past the geometry shader: // vertex shader out float foo; //[...] foo = 0.5; // ignore foo in geometry shader // fragment shader in float foo; The result was a warning and an error: WARNING: Output of vertex shader 'foo' not read by geometry shader ERROR: Input ...


0

I think you'd have to setup a seperate program object where the shader chain doesn't have a tesselation shader, but I suppose this isn't desirable most likely. Just simply letting the variables pass through the shader would be the best option I guess, I don't know about tesselation shaders specifically but if they're like the vertex shader a simple line of ...


0

Seeing as you want to keep the state of the matrix before the translation, I'd suggest using a matrixstack, this openGL tutorial explains it quite well: http://www.arcsynthesis.org/gltut/Positioning/Tut06%20Fun%20with%20Matrices.html However, for this method I assume you perform your matrix multiplication with the vertices in GLSL. If that's not the case ...


1

If I write a game engine that uses OpenGL 1.5 (not assuming what else I do), is it portable now and is it still portable five years from now or are/will support for OpenGL by hardware and drivers (be) exclusive to their (much more farther along) target OpenGL versions? Currently, all of the features provided by any OpenGL version x <= 3.0 are ...


6

OpenGL 1.x is not likely going to disappear on PCs. A great number of luminaries in the GL community consider the explicit compatibility mode and deprecated features of GL 3.1 to be a mistake. The last time GL was scheduled for a massive break in compatibility, Khronos backed out and delivered an incremental update. While nobody can see the future, it's ...


3

The short answer, OpenGL really changes after version 3.1, that being said don't use OpenGL function calls directly, but actually build a small wrapper around it. One way to do it is to make a class that is responsible for all openGL calls, this can be replaced once you want to upgrade to newer versions. You can for example have a Texture resource class that ...


0

Since it's about 2D tiles and 1,000,000 is an awfully big number (so each tile will be a small rectangular area a few pixels big), the most efficient way of doing this would be to draw a textured fullscreen triangle. Really, no kidding. There's no need for geometry here. UXGA only has 1,920,000 pixels total (1.9 pixels per tile), and 1080p will have just ...


0

Either way should be fine (although note that you need buffer objects in order to do instancing). Your primary bottleneck is going to be elsewhere: fillrate, overdraw and ROP.


0

Using a VBO means that the data for drawing will sit in GPU memory, which is better (performance wise) than if it would be in main memory. Using instancing means drawing multiple instances of the same geometry (using different parameters based on the instance ID). Those things do not exclude each other! You can draw with instancing from a VBO - if many of ...


1

I tried compiling it from the command-line as follows: cgc -profile glslf -entry FS_Main test.cg This gave the following error output: test.cg test.cg(18) : error C1066: invalid type in type constructor test.cg(18) : error C1010: expression left of ."rgb" is not a struct This immediately highlights the fact that you used texture2D on line 18 instead of ...


4

The prevalent advise is fewer big buffers are better. Ideally one buffer big enough to hold everything. This also allows you to use 1 VAO per vertex layout. Along with persistently mapped buffers, it makes for a powerful GPU memory management in your application. However, it does burden you with extra work to ensure your data is aligned correctly, that you ...


0

Since your game is 2D, I will assume, as I read in your comments, that there is no "camera". I will assume that you have a view rotation around the player called viewRot. Your player is the center of rotation as well as the center of the bullet. We will first rotate the bullet around itself because it seems logic to me to apply self transformations before ...


-1

Calculating UV in vertex shader: uv.xy = mul(world2object, cameraWorldPos-mul(object2world, (0,0,0,1)))+(0.5,0.5)


0

The only difference you would have is that you are doing texture lookup based on UV instead of direction. This would mean that each cube vertex would need a uv or you would need a routine to calculate the appropriate uv based on the view direction ... which is basically us back at using texCUBE, with the exception that texCUBE is probably going to be more ...


0

By mapping out the transformation on graph paper, traversing the steps in reverse from result to original point, I was able to figure out the exact steps needed to answer my question. Instead of just building on my matrices with functions, I created several different matrices, each with their own part of the transform (rotation, translation). I then ...


3

This is less a problem with Box2dLights, and more a problem with setting up Box2d collision fixtures to match your sprites. The Box2dLight rays are colliding with the CircleShape fixture you attached to the box2d body. CircleShape chain = new CircleShape(); chain.setRadius(10); Instead, this should be a Polygon shape with the same dimensions as your box, ...


1

By no means you need to recreate the buffers every time. Why don't you create all your buttons once and then draw them as needed? Buttons are immutable things. Suppose you had a class Button, that incorporates all the stuff needed to draw a button, such as textures and the vertex buffer: class Button { Texture texture; VertexBuffer buttonVerts; ...


-1

Depending on your compiler, when you divide PI in your calculations then the result could be interpreted as either a float or an int. From what I recall, the C++ standard demands that the result of an arithmetic operation on basic data types will always have the same signature as the left hand operand. However, not all compilers follow the standard. Because ...


2

It really depends on the geometry that your world consists of and how you set your orthographic projection and camera up relative to that world. Most of the time, when people make 2D games with orthographic projections, they don't bother actually creating 3D geometry. Usually everything is a quad with a texture applied, or simple 3D geometry without much ...


3

You don't need to perform backface culling manually in the geometry shader. (It's possible it could be an optimization to do so, if culling allows you to skip some expensive work in the rest of the geometry shader. But that seems unlikely to be the case.) Triangles can't have incomplete adjacency information. The vertex buffer for GL_TRIANGLE_ADJACENCY ...


2

Here is a link on how mix openGL code with the SFML, are you sure that the GLFW feature that you are looking for, aren't on the sfml already, because in my experience there is no reasone for mix up this two library.


5

In C and C++, you just wouldn't get the functions to run it. You'd send the request for a 4.4 context and get a NULL context back (indicating that it wasn't created.) You'd make a wglGetProcAddress call and get NULL back for the function that you requested an address to. If the hardware doesn't support it then your stuck without. There might be a chance ...


0

The field of view for the shadow map needs to be large enough to cover the whole cone of the spotlight. So if the cone is made wide enough to illuminate the whole object, the shadow map FoV will need to be wide enough to see all of it. If the shadows are getting too blocky, you'll need to increase the shadow map texture resolution. If the field of view ...


0

i think you mean the 3 dimensional offset of the holographic sight that is positioned relative to the actual frame. i think the best way to simulate the reflected projection of the dot / cross is to offset a sprite from the glass a little bit to the front of the gun ( but still ceeping it inside the frame / housing of the sight ). Also render it from the ...


1

You are not so far off with your observation. The approach you describe in both cases is OK but needs refinement. Shadows When looking into shadows you need to consider different issues. As you describe you can handle everything dynamically. The process is basically as you describe, except for directional lights and spotlights you would use "normal" 2D ...


1

I am just rehashing what @yuumei said, but since he did not post an awnser: You are creating the vao object with: glGenVertexArrays(1, &vao); As such you need to delete it with: glDeleteVertexArrays(1, &vao); Here is the documentation for glGenVertexArrays. What happens here is that the value in vao is the same value with some other buffer ...


2

The most efficient method of updating vertex data would be to do it on the GPU. To do this you can use transform feedback. Transform feedback works by letting you write out changes to your vertices in the vertex shader back to your vertex buffer. Or if you need to calculate the positions cpu side for some reason, glMapBufferRange may be the next best ...


1

Although libgdx largely abstracts away the OpenGL component for most of the basic things, you can still use it in your code for the more advanced stuff. Usually though, if you dig a round for a while you'll probably find that about 99% of the time whatever you want to do with OpenGL has already been implemented somewhere in libgdx. Source: ...


8

Vertex and fragment shaders run concurrently, not sequentially, and the GPU automatically load-balances between them, so it's not possible to meaningfully assign specific timings like 7 ms for one and 1 ms for the other. However, you can do a simple experiment to measure where the bottleneck lies: set the view-projection matrix to all zeros for all your ...


1

the limitation you're finding is somewhat related to the history of OpenGL. Prior to OpenGL 3, a fixed-function pipeline was employed. This roughly means than OpenGL would execute the exact same processing on all vertices. The only way you could modify the output was by changing the input arguments of the pipeline (vertex positions, colors, light properties, ...


2

It is possible that your issue may be due to the lack of use of the invariant qualifier in your shaders. Quote from the book OpenGL ES 2.0 Programming Guide: There is a keyword introduced in the OpenGL ES Shading Language invariant that can be applied to any varying output of a vertex shader... The issue is that shaders are compiled and the compiler ...


1

Have you verified that all variables used are initialed before using them? Using a variable that you have not yet assigned values to can cause flickering. For instance, if you have a variable that is created like this: vec4 secondaryColor; vec4 color = vec4(0.1, 0.1, 0.1, 1.0); void main() ...


1

Here is a shader that does an outline in the simplest way that I know of. It just uses the dot product of the normal and light to cutoff colors based on the normal angle. Really, I suppose the view direction should be used instead of the light position but this gives control over the direction of the edge highlighting if you want that. There are 3 color ...


2

You should generate a distance field instead of a simple mask. In each pixel in the empty area, instead of storing 0 you store the distance to the closest pixel containing terrain. So you can return a black pixel if the value is for example between 0 and 0.1. There are multiple algorithms to compute distance fields, so I let you find one that would suit ...



Top 50 recent answers are included