Tag Info

New answers tagged

0

Try turning off Boost: http://assimp.sourceforge.net/FAQ.html ENABLE_BOOST_WORKAROUND = ON As explained there its not really required, and its big. When we build Boost for Qt3D 1.0 we didn't use Boost because of compile issues.


1

I don't know why people automatically jump to premature generalization/optimization when questions like these pop up. There is something to be said about being preemptive and realizing when a component in a system is likely to be swapped out. All of the answers about "don't worry and code away till you need to change it" generally get people into trouble in ...


0

Figured it out by looking other shader examples and hopefully it will benefit others. elapsedTime can be added to the computation or offset and will animate the effect, some use sin/cos as well.. uniform float elapsedTime;


0

Rotations occur relative to the origin, so you want the camera to be 100 units away already before you rotate it if you want the camera to stay focused on the origin. This image will hopefully make it clear (source page): The view matrix you would use is then (I apply the transformations from right-to-left): view = inverse( rotate(90) * translate(100) * ...


1

This is an old topic, and I had a similar problem to the topic. I had my texture coordinates just fine, but by lerping the camera position (which changed my element's positions) like so: public static void tween(Camera cam, Direction dir, Vec2 buffer, Vec2 start, Vec2 end) { if(step > steps) { tweening = false; return; } ...


6

Best practices: One central loop in main / rendering thread which also handles sound, network buffering etc. - basically, this centralises communication with OS and other threads. All processor-intensive tasks (for example, mesh building, AI, physics) may be submitted ad-hoc, in bite-sized work units, to existing worker threads. These threads are kept ...


0

I've found what I've done wrong: for (w = 0; mask[sum + w] == type && !done[sum + w] && w < 15 - x; w++) {} The code above was wrong, because it incremented w first and then it checked everything. Therefor the code should be: for (w = 0; w < 15 - x && mask[sum + 1 + w] == type && !done[sum + 1 + w]; w++) {} This ...


1

I found this tutorial on the OpenGL wiki a month ago. It explains the basics of skeletal animations; but I hope it is good enough for what you are trying to do, if not, you can also search skeletal animation opengl on google, because there is much more on the opengl wiki about this topic.


3

Your struct is likely being padded by the compiler. The only guarantee offered by a struct is that its members will be sequential in the order they are declared. Compilers are free to add as much or as little padding as they like. C and C++ contain a handy macro for determining offsets within structs. I'd recommend using it rather than manually working out ...


4

You don't set these values in the shader. You set them in your program, generally when first creating the texture (though it can be set or changed whenever). If you've already uploaded your texture data to OpenGL then all you have to do is this: First bind the texture if it is not already. glBindTexture(GL_TEXTURE_2D, texture_id); Then set the ...


0

It's not immediately obvious how you're using OpenGL. If you are just sorting your tiles on the CPU and rendering them from far to near the following method won't help. If you are using an actual isometric projection matrix and a depth buffer this may help, it's how I do picking with OpenGL and perspective projection. Use the following code to read back the ...


1

One way of doing this is creating and loading an image into memory that is as large as the background. However, this seems like a horrible waste of memory. To affect the whole screen with a fragment shader you don't need a full-screen texture, just a full-screen polygon (one quad or two triangles). The four vertices would have attributes on them. At the ...


0

I suggest you make a skybox: A skybox is a large cube which you render around your camera which will give you the ability to pass each pixel through a fragment shader. And you can render anything onto the skybox: a color, an image, a gradient, etc. Just be sure to call glClear(GL_COLOR_BUFFER_BIT || GL_DEPTH_BUFFER_BIT); A good tutorial on this topic is ...


1

If you are just filling with a solid color then you could pass that color to the fragment shader as a uniform, and process it from there. Use a full screen quad for the fragment shader to render onto. Another way is to this to render the background to an FBO and do the full screen quad trick but apply the FBO texture to it. This would be very memory ...


0

I suggest another approach: First you render your world and sky, etc. just like you would do normally. Then you have to sort the clouds (or the vertices of the clouds) from closest to the camera to furthest from the camera. You then test if the camera is inside a cloud, if this is the case, you will have to turn off back face culling so that the insides of ...


0

I got it, too. For me it was an issue with the Texture. On NVIDA things worked out fast. But my optical optimisation caused an ATI card to nealy resign. I work with a texture of size 4720 x 5600 (about) and modern cards work well with it. I tried to optimize borders using Wrapmode=GL_CLAMP_TO_BORDER_ARB . Therefore I need to supply the border argument to ...


0

I think there's a special shader for that. To lighten the alpha calculation, it might only consider the first alpha from the mesh from the POV, and blend everything else behind it that has no alpha (or that is not clouds). From the inside of a cloud, other clouds are no longer visible.


-1

Khronos recently announced the release of the all-new Vulkan API, which will complement (and in some cases replace) OpenGL and OpenGL ES. Vulkan is a low-overhead API designed to bring code “closer to metal”, boosting performance and efficiency. It is based on AMD’s Mantle API, and the final spec is expected later this year. In this post - A Brief Overview ...


-1

I fixed it with: glOrtho(0, width, height, 0, 0, 1);


0

Picking in OpenGL can be done, by rendering the primitives you want to check for, assigning each one a unique color, based upon which you can look it up. Then you can check what color is rendered for example on the center of the screen, this way getting the object pointed at. This was done in older games, but is frowned upon, because it can be a huge ...


0

I think the only solution is to do a 2 pass rendering (as Janos said). But the clouds first need to be Z-Ordered. Then render the outside faces of all clouds (back culling), and then render all inside faces (front culling). This will prevent seeing the inside faces from outside, and the sorting will prevent seeing a cloud behind another cloud. Remember ...


1

As described here (last chapter), please check the value of the field renderCalls in your SpriteBatch (you have only one unique SpriteBatch instance right ?), this should tell you the real number of draw calls that the batch has made. If you have more renderCalls than what you would expect then maxSpritesInBatch value is too low or your sprites have ...


1

Set culling to cull front faces first, then render your clouds. This will render the backfaces. After that, switch culling to cull backfaces, and render the clouds, which will render the front faces on top of the back faces. This will prevent rendering your backfaces on top of the front faces, but still keep back faces visible all times. Update: From the ...


0

Sounds like the clouds have both inside and outside faces. Make your cloud double sided but don't turn off backface culling.


2

That structure is not aligned correctly, which may be the source of your problem. To form an array using std140 out of PLight, you need to pad it with an extra float at the end. Otherwise, PLight pLights[TOTAL_LIGHTS] is misaligned and you will fetch the wrong memory from pLights [1] -- everything will be off by 1 scalar component on the second light in ...


1

Modern hardware performs early stencil testing using the same sort of tile-based approach as early depth. It can reject large groups of fragments before they make it to the fragment shader stage. That means shader units will not waste time calculating data they are just going to throw out anyway. You add an extra 8-bits of memory per-pixel (pretty much a ...


0

Non-constant indexing into uniform array can be tricky and depends on GLSL version. I think that what you are doing should be within spec (even for GLES 2.0), but it still might be problem. See for example what GLES 2.0 GLSL 1.0 spec says about indexing uniform array in fragmen shader: Apendix A section 5 In the vertex shader, support for all ...


2

The other answers already mention that you're getting a dangling pointer and should return the strings. But reading shaders from a file, really comes down to putting the whole file into a string. Here's one way to do it: // Read shader file into one string std::string shaderSource; if ( !readFileIntoString( shaderFileName, shaderSource ) ) { return ...


1

const char* vertex_shader = load_shader("test.vert").c_str(); const char* fragment_shader = load_shader("test.frag").c_str(); will result in dangling pointers (with undefined behavior if you dereference it), after you assign the char* to the variable the temp std::string (and backing array you just got a pointer to) gets deleted. const std::string ...


6

You are using pointers to data inside a temporary object: const char* vertex_shader = load_shader("test.vert").c_str(); const char* fragment_shader = load_shader("test.frag").c_str(); Which means both vertex_shader and fragment_shader are pointing to invalid memory, since the strings returned by load_shader get destroyed at the end of each statement. ...


0

To avoid gimball lock you have to use quaternions. Since you are using the GLM library you already have code for that. q1 = cos(a/2) + i ( x1 * sin(a/2)) + j (y1 * sin(a/2)) + k ( z1 * sin(a/2)) q2 = cos(a/2) + i ( x2 * sin(a/2)) + j (y2 * sin(a/2)) + k ( z2 * sin(a/2)) q3 = cos(a/2) + i ( x3 * sin(a/2)) + j (y3 * sin(a/2)) + k ( z3 * sin(a/2)) a = ...


0

Read this through and my best guess is that there is something wrong here: root->finalMatrix = root->animationMatrix * root->offsetMatrix; How is offsetMatrix calculated? And what is it supposed to do (I know somekind of offset). Would also like to see these calculations: //rotation glm::mat4 R = ... //calculate rotation matrix based on time ...


1

What you could do is use a pool of big VBOs, with a PoolManager. The PoolManager would only allocate "big" VBOs, each one having the same size, for example 4/16/256MB, not sure of how much vertex data you have... Each VBO in the PoolManager would have associated lists of "used" and "free" regions (a region is defined by an offset from VBO start and a ...


2

A Vertex Buffer Object (in short VBO) is an object(buffer) that holds vertex data. It's your job, as the programmer, to fill the VBO with this data (usually Vertex positions, texture coordinates and normals) and then send it to be handled by the GPU. This is an example of VBO initialization: glGenBuffers( 1, &vbo ); // Generate a VBO handler ...


0

VBO's (Vertex Buffer Object) are used to upload data to the GPU (Graphic Processing Unit, in other words your graphic-card). The data does not have to be vertices, it could be used for anything. The data can also be changed later on.


3

I can give one small piece of advice. Don't do this in your render loop: viewMat = getUniformLocation(sp, "viewMat"); modelMat = getUniformLocation(sp, "modelMat"); projMat = getUniformLocation(sp, "projMat"); maxIterLoc = getUniformLocation(sp, "maxIterations"); centerLoc = getUniformLocation(sp, "center"); scaleLoc = getUniformLocation(sp, "scale"); ...


0

You are correct that you cannot take the same window with the same GL context and change between fullscreen and windowed. What I have done is set up my rendering system (and input, etc...) to generically set itself up, and extended that slightly to allow it to re-set itself up without leaking memory. So when the application first launches, everything is ...


1

If you really want to target OpenGL, GLES and WebGL you should reuse as much code as possible but it's not a simple task. OpenGL and OpenGL ES are fairly similar. In fact a lot of the code can be reused between the two. WebGL isn't quite as easy as, you're right, you need to recompile with emscripten which is a whole separate task. Your project ...


1

As stated in the comments, drawing points is as simple as drawing GL_POINTS instead of GL_TRIANGLES, you'll need one vertex instead of three of course. Now to your non-structured input: Of course it is structured. It may not be in the format OpenGL expects, but it definitely has some sort of structure, some format you're able to parse. In case of a ...


1

The simplest solution to this would be simply buffering the vertices into a VBO like you normally do, then rendering them as GL_POINTS instead of GL_TRIANGLES or GL_TRIANGLE_STRIP. This will give you a cloud of dots, that you can rotate the usual way with your vertex shader. If you want nicely sized circles, you should use a geometry shader to create a ...


1

Some ideas: You could ignore the issue, and do what you're currently doing. Assuming those texture and shader comparisons are to OpenGL IDs (which are just integers), it's unlikely those checks are going to create a huge performance bottleneck. Comparison of integer values on modern CPUs is rather fast. Unless your profiler has told you this is currently a ...


1

What a dump question. I put the cubemap to the wrong samplerCube. I assigned the map to cubemap[1] not cubemap[0]. Great example of "I wouldn't do something like this. The error must be somewhere in the OpenGL code!" :D


0

The official OpenGL documentation is well done, but IMHO you need a background of how a game is structured, what is and how a shader works and - first of all - how the rendering pipeline works. If you have time (and money), Real-Time Rendering gives you the theory you need. Anyway, from my experience I understood that the best way to learn how to write a ...


0

I would STRONGLY RECOMMEND you to follow this YouTube tutorial series: 3D Game Engine Development Tutorial It is a good starting point to learn the basics and although the tutorial is based on Java, you should be able to recreate it in any languages you prefer. (:


1

I was in the same boat a couple of years ago. All engines will have some abstractions that are strange and take some getting used to. Building your own engine will cause a lot of heartache and difficulties you did not expect down the road. I had to move my engine over to Box2D just to handle the massive undertaking physics had on my project. If you're ...


0

There are multiple issues with this code. First of all your quad vertices are not centered around the origin, this doesn't have to be a problem but note that it will use the corner of the quad as the pivot to rotate the sprite then. Secondly, you are rotating on the X-axis. This seems weird since the general direction your camera in looking in is the -Z ...


1

You generally use a window provided with the library that supports OpenGL. I don't have any experience with JOGL but it seems it works with Swing, although apperantly with a small performance penalty. LWJGL, another alternative for OpenGL in Java provides a window library with it which is native to C/C++ and is normally used for OpenGL rendering.


1

The way to do this is with a FBO (Frame Buffer Object). You can render each pass to a FBO and use it as a texture input in the next stage, any kind of deferred shading and post processing is reliant upon this functionality. https://www.opengl.org/wiki/Framebuffer_Object


0

Okay so I solved it: 1. Make sure glEnable(GL20.GL_BLEND_COLOR); is on and the blend function is Gdx.gl.glBlendFunc(GL20.GL_BLEND_SRC_ALPHA,GL20.GL_ONE_MINUS_SRC_ALPHA); 2. Edit the light texture in something like GIMP to double check that your background is transparent. 3. MOST IMPORTANT Make sure the lightFramebuffer is Format.RGBA4444 or ...


2

It depends on multiple factors including... How much geometry you are raycasting against (more = slower) The resolution you are rendering your color picking at (higher = slower) How you've implemented either solution (CPU raycasting? vs GPU color picking? or something else?). Resource constraints -> if your application is already CPU bound, and has plenty ...



Top 50 recent answers are included