|
I've been reading this a lot http://www.opengl-tutorial.org/
|
#
?
Feb 6, 2015 02:06
|
|
|
|
| # ? May 24, 2024 12:26 |
|
|
I'll try reading that tomorrow, thanks. In the meantime, what's the easiest way to get the (x, y, 0) coordinate when clicking on the screen(the place where a ray intersects the world center plane z=0)?
|
|
#
?
Feb 6, 2015 02:12
|
|
|
If you just mean the position local to the window then probably from whatever windowing API you are using. If you mean getting a worldspace position then something using "unproject" like this: http://stackoverflow.com/questions/9901453/using-glms-unproject
|
|
#
?
Feb 6, 2015 16:11
|
|
|
nye678 posted:I recommend the OpenGL SuperBible sixth edition. I'd second this, it's not free but convenient if you get the online version. It's not perfect and would work a lot better if it were laid out like a website but it's still markedly better than any online tutorial website I've seen. I have a glsl question, I'm trying to store image data with: code:To clarify, the image bound is 8 bit per channel rgba as well. I'm a dope and my texture format wasn't what I thought it was. Sex Bumbo fucked around with this message at 21:18 on Feb 24, 2015 |
|
#
?
Feb 11, 2015 21:47
|
|
|
I don't know if Google is failing or I am but I'm unable to find a function I could use to get the viewport transformation matrix out of OpenGL. I'm making a thing that is purely 2D (so no perspective or "view" or anything like that), I'm creating the context with GLFW (and I assume it handles the viewport transformation as well, I do not touch it myself). I need the viewport transformation so I can map mouse cursor position on the window coordinate space to the actual model coordinate space. I think I understood it pretty well, I have to just calculate the -1.0...1.0f "normalized device coordinate", then transform that with the inverse of the viewport transformation to get model space coordinates so I know how much I need to move (translate) the model when panning with a mouse. I do not set the viewport transformation matrix anywhere, I assume glfwCreateWindow() sets it so I'd need to get it from somewhere (either from OpenGL or GLFW). Edit: Or hmm I guess it is possible that I just have no transformation on the vertices, because I'm doing "all" in my own vertex shader. For zoom I'm just multiplying all the vertices with a uniform. This is pretty confusing, mainly because there are a buttload of different OpenGL versions that seem to work totally differently (or you're supposed to use them in a totally different matter). If I understood it correctly in "modern" (no idea about versions) OpenGL you're kind of supposed to handle all the transformations yourself in the shaders and not use those OpenGL functions? Hyvok fucked around with this message at 16:06 on Feb 19, 2015 |
|
#
?
Feb 19, 2015 14:13
|
|
|
Modern GL doesn't give you matrices, for better or worse. The viewport and viewport transform are not the same thing. The viewport is set by glViewport(). It specifies where to draw within your window, in window coordinates. The viewport transform doesn't exist unless you created one. You seem to be on the right track. A typical 2D camera does two things: - Pan by adding x/y offset to every vertex position, which go into the shader as world-space coords - Divide all vertex positions by the width/height of the render region, scaling it down to view space
|
|
#
?
Feb 20, 2015 21:19
|
|
|
If you have the modelview and projection matrices from your shader and the viewport values from the current context, you could use gluUnProject(). But yeah, that sounds like overkill for a 2D scene.
|
|
#
?
Feb 20, 2015 22:00
|
|
|
As a general rule, don't request state back from either OpenGL or DirectX. You should theoretically always "know" the state, because it's either some documented default value (lol) or because you set it yourself, and can just ask your own program what it is rather than asking OpenGL. If you want to do a 2D "zoom", the most straightforward way is to do some sort of scaling inside of a shader. A higher level way of thinking about this is to modify your view transforms, which get sent down to shaders in the form of uniforms. Outside of the shaders it's going to look like "SetViewTransform(...)" where the aforementioned function is something that you wrote yourself or got from a library, but not anything in OpenGL. As such, "GetInverseViewTransform()" will be coming from the same place. Such transforms are not and should not be managed by OpenGL because they can be laid out in any way you want. For example in a 2D scene you might want a 3x2 matrix to represent your view transform, which is enough for scale, rotation, and translation. But you could also just use scale rotation and translation independently, coming out to four floats instead of six. One way isn't necessarily better than another which is why it shouldn't be handled by the low level graphics API. Sex Bumbo fucked around with this message at 00:38 on Feb 21, 2015 |
|
#
?
Feb 21, 2015 00:35
|
|
|
You could draw world/model positions to an offscreen buffer and use glReadPixel() on that buffer using mouse x and the window height minus mouse y. As long as you remember not to use an internal format that clamps its values it should work. It's not too performant, though, but if it's 2D that shouldn't matter.
|
|
#
?
Feb 21, 2015 07:11
|
|
|
I'm new to graphics programming and am trying to render a simple triangle using Direct3D 11, but nothing is showing up and I've been staring helplessly at my code for a while now. Can someone who is familiar with D3D take a look and tell me what I'm doing wrong? I'm sure it's something silly like an incorrect stride, but I've exhausted all the normal failure points I could find by Google. My code is here and my shader is here.Boz0r posted:Are there any recommendations for books teaching modern OpenGL (or DirectX)? I'm using this book so far for DirectX 11 and have been impressed with it so far, not holding my issue above against the book.
|
|
#
?
Feb 22, 2015 09:31
|
|
|
Joda posted:You could draw world/model positions to an offscreen buffer and use glReadPixel() on that buffer using mouse x and the window height minus mouse y. As long as you remember not to use an internal format that clamps its values it should work. It's not too performant, though, but if it's 2D that shouldn't matter. I would advise against using glReadPixel, unless this is just to verify your transform math is correct. If anyone needs help doing the inverse screen coordinate to world coordinate transform I'm sure someone can help with that. EkardNT posted:I'm new to graphics programming and am trying to render a simple triangle using Direct3D 11, but nothing is showing up and I've been staring helplessly at my code for a while now. Can someone who is familiar with D3D take a look and tell me what I'm doing wrong? I'm sure it's something silly like an incorrect stride, but I've exhausted all the normal failure points I could find by Google. My code is here and my shader is here. code:
|
|
#
?
Feb 22, 2015 22:41
|
|
|
Sex Bumbo posted:You need to reset the data stream with either Seek(0, 0) or something else (?) before you pass it into new Buffer(). I don't know SharpDX that well, but that will fix it. This needs to be done for both your vertex and index buffers. Yep, this is it. Thanks, would never have thought of that. Have a picture of the first-ever results of my graphics "engine"!  The shading model is a bit more primitive than UE4's, but I'm catching up fast.
|
|
#
?
Feb 22, 2015 23:08
|
|
|
I have a DirectX issue. I have the following resources: indirectBuffer, indirectUav: a buffer created for indirect dispatch, along with an unordered access view of it constantBuffer: a constant buffer, of course outputBuffer, outputUav: a structured buffer created with the append flag I try to do the following code:I can verify that things like sourceBox and the values in indirectBuffer are correct. I verified by reading back the values, at which point the program works again, I'm guessing because the readback is creating a synchronization in the same way Flush() is. My hypothesis is that the data written in the first dispatch is not being read correctly by the DispatchIndirect call. Can I create a device memory barrier of some sort? I tried some nonsense in my compute shaders like calls to AllMemoryBarrierWithGroupSync() that didn't seem to do anything. I'm running on an AMD card with a driver from 11/20/2014. An R7 200 series. I haven't tested this exact problem on my NVidia card but I don't recall it happening (though it may have been). E: if I don't call CopySubresourceRegion on my constant buffer and instead hard code the count value into my second compute shader, it ends up working. Sex Bumbo fucked around with this message at 23:29 on Mar 9, 2015 |
|
#
?
Mar 9, 2015 19:25
|
|
|
Actually, does anyone have much experience using DirectX Append/Consume buffers? Previously I was doing Append/gather using the [] operator, but I tried switching to using Consume() and it deadlocks my driver (2/5/15). I assume Append/Consume buffers are implemented as a scan/reduce algorithm so I'm just going to roll my own Append/Consume buffers for now.
|
|
#
?
Mar 11, 2015 19:12
|
|
|
^^^ I guess no one uses those much here, but I got my stuff working, sorta. It only works on AMD with a bunch of flushes sadly, but it's fine on NVidia. I was making a marching cubes implementation (for no reason really).   There's a lot of room for optimization but it can generate about 200 million triangles per second on a nvidia 550gtx ti, not counting the density function which will vary by complexity. The above images run at something like 400-500fps. I have no interest in porting this to opengl since I'm just dicking around but I feel like what I want is the DirectX equivalent of glMemoryBarrier??? And DirectX 12. I want that too. E: It would also be nice to have a good scan implementation in HLSL. I made my own cruddy one that's probably really slow. On CUDA you can use all sorts of magical functions like shuffles which aren't available in HLSL. Theoretically, the NVidia driver could be doing some sort of optimization in Append/Consume buffers that isn't possible in compute shaders, right? Either way I wish more people wrote about compute with regards to 3D graphics applications. Sex Bumbo fucked around with this message at 19:10 on Mar 16, 2015 |
|
#
?
Mar 16, 2015 19:03
|
|
|
^^^ I can't help with any of the DirectX stuff unfortunately, but nice Tangle  I've been writing a blog about my own voxel adventures: http://ngildea.blogspot.co.uk
|
|
#
?
Mar 19, 2015 17:09
|
|
|
|
|
#
?
Mar 19, 2015 19:41
|
|
|
MarsMattel posted:^^^ I can't help with any of the DirectX stuff unfortunately, but nice Tangle Cool videos; the fact that it's voxel terrain mains you should be able to make structures such as caves the player can go into right? Otherwise it seems like it'd do the same thing as a height map.
|
|
#
?
Mar 19, 2015 20:05
|
|
|
MarsMattel posted:^^^ I can't help with any of the DirectX stuff unfortunately, but nice Tangle Oh nice -- are you planning on doing a gpu version? I was thinking of doing a DC or DMC implementation after I get MC optimized, as there should be a lot of reuse. I mostly just like spitting out millions of triangles as fast as I can. High Protein posted:Cool videos; the fact that it's voxel terrain mains you should be able to make structures such as caves the player can go into right? Otherwise it seems like it'd do the same thing as a height map. DC extracts isosurfaces, which can be represented by voxel volumes but can be other things too. So yeah you can make caves, floating things, loops, any number of shapes. It could even do a heightmap. E: "I'm now using an edge collapse approach to simplify the meshes rather than vertex clustering via the octree" Why was this? It sounds like it would be a lot slower. Also, are the seams visible where you stitch blocks together? Sex Bumbo fucked around with this message at 20:33 on Mar 19, 2015 |
|
#
?
Mar 19, 2015 20:19
|
|
|
High Protein posted:Cool videos; the fact that it's voxel terrain mains you should be able to make structures such as caves the player can go into right? Otherwise it seems like it'd do the same thing as a height map. Yeah that's right. I'm just using 2D noise and turning that into a 3D field by doing something like this: density = position.y - (max_height * noise2D(position.x, position.z)). Sex Bumbo posted:Oh nice -- are you planning on doing a gpu version? I was thinking of doing a DC or DMC implementation after I get MC optimized, as there should be a lot of reuse. I mostly just like spitting out millions of triangles as fast as I can. Some of it is on the GPU currently, planning on moving the whole thing over soon. That's one of the reasons for ditching the octree simplification (there won't be any octrees in the GPU version) the other was not being happy with the mesh quality with the vertex clustering. There was a poor 'distribution' of tris really small ones with really big ones etc and lots of intersecting triangles. There is an "improved" version of the contouring algorithm to specifically handle the intersections but it is horrific. In comparison the edge collapse produces much better meshes with no intersections, and I've got an OpenCL impl of that. Do you mean are there artifacts on the seams? You can see them in the video in the wireframe mode, joining the simplified meshes together.
|
|
#
?
Mar 21, 2015 22:56
|
|
|
MarsMattel posted:Do you mean are there artifacts on the seams? You can see them in the video in the wireframe mode, joining the simplified meshes together. Yeah in the video I could only see them in wireframe, I was wondering if they're apparent when shaded as well. Which edge collapse simplification algorithm are you using? That's not done in opencl is it?
|
|
#
?
Mar 22, 2015 04:42
|
|
|
They shouldn't be apparent/stand out when shaded since they share the normals and positions with the non-seam vertices. Yeah, the simplification can be done in OpenCL too but unfortuantely I don't have enough data to make it worthwhile at the moment. Right now I need to explicitly upload the mesh data (as a triangle soup) to OpenCL then run the simplification and then pull it back down again before passing it to OpenGL. That is too slow at the minute and typically the CPU implementation beats the pants off it. I'm hoping when the mesh gen is on OpenCL then its more competitive. The algorithm is Instant Level of Detail. I currently cheat a bit and only consider the edge end points and the edge midpoint as valid places for the vertices to be moved to which saves quite a bit of computation at the expense of the mesh quality. I've now get a reliable SVD solver so I should be able to hook that up to the mesh simplification stuff.
|
|
#
?
Mar 22, 2015 19:32
|
|
|
Ah thanks! What's your motivation for using OpenCL vs OpenGL compute? I haven't used OpenCL at all.
|
|
#
?
Mar 22, 2015 21:26
|
|
|
This is the first thing I've used OpenCL for personally. I didn't actually consider Compute shaders much, I went for OpenCL since that seemed to have a lot more samples, books, etc available. I guess it could all be done with compute shaders
|
|
#
?
Mar 23, 2015 11:43
|
|
|
I have a question about DX11. I'm using C++. I've been following beginner's tutorials for getting models into the screen. The general structure / logic of it is to build a vertex buffer for each model, and the model has a render function which calls IASetVertexBuffers, IASetIndexBuffer, and IASetPrimitiveTopology, and then calls the vertex/pixel shaders. Textures get passed in through a cbuffer struct, among position, normals, texture coords... I read somewhere that it's better to consolidate vertex buffers into one giant buffer, and I refactored the code to do just that. My issue is with how to properly address the textures for all the models. Right now, I've separated out the IASetVertexBuffer etc. calls, and the call to the vertex/pixel shaders, such that the vertex buffer gets passed in once, then a loop runs through setting a sampler state per texture, calling PSSetSamplers, and DrawIndexed also in the loop. I could pass in an array of textures, but I'm only just barely understanding the vertex and pixel shader code presented in the tutorials so far, and I don't know how a pixel shader could determine which texture to use at the given pixel, or if, instead, a giant texture ought to be patched together and sent into the shader, or an entirely different method I'm not thinking of. For reference to how my code looks like so far, I've been following http://www.rastertek.com/ tutorials, and I'm around tutorial 12 so far (with changes I've made to consolidate vertex buffers). Just let me know if there's any more information needed to clarify my issue.
|
|
#
?
Apr 2, 2015 21:03
|
|
|
Texture management shouldn't change just from sharing a vertex buffer between multiple meshes. You can draw separate parts of the mesh by using the StartVertexLocation parameter in Draw and DrawIndexed. If you want to pack multiple meshes into a single draw call, then yeah you would need to either bind many textures or bind a texture array or atlas.
|
|
#
?
Apr 2, 2015 23:04
|
|
|
Sex Bumbo posted:If you want to pack multiple meshes into a single draw call, then yeah you would need to either bind many textures or bind a texture array or atlas. This is what I'm aiming at: packing multiple meshes into a single draw call. My confusion lies in how the pixel shader would know which index in the texture array to call for that pixel. Right now, I just reference a single texture, and use a texcoords variable to find which pixel color to draw. If there's an array of textures in there, what's a good way of finding which texture to start with when referencing coordinates? Edit: Or, you mentioned something called an atlas (I don't know what that is). Is that a better-fitting solution to the problem I'm describing? Are there some good resources on solving my problem with either an array or atlas? Nahrix fucked around with this message at 23:39 on Apr 2, 2015 |
|
#
?
Apr 2, 2015 23:37
|
|
|
Nahrix posted:This is what I'm aiming at: packing multiple meshes into a single draw call. My confusion lies in how the pixel shader would know which index in the texture array to call for that pixel. Right now, I just reference a single texture, and use a texcoords variable to find which pixel color to draw. If there's an array of textures in there, what's a good way of finding which texture to start with when referencing coordinates? Simple solution: pass the texture array index for each piece of geometry as a vertex attribute, and pass that through to the pixel shader. Less simple solution: encode the index of the texture array into one of the vertex attributes you are already passing to the vertex shader (e.g. use 2 bits from the x component tex coord and 2 bits from the y tex coord to encode up to 16 indices). Depending on the size of your atlases and the precision of your vertex attributes, you might be able to get away with this without a loss of image quality. Less less simple solution: pack all your individual textures into a single huge texture (you can go up to 16K by 16K these days) and then post-processes the texture coordinates of your meshes to index directly into that. This is what Sex Bumbo meant by "texture atlas".
|
|
#
?
Apr 2, 2015 23:48
|
|
|
shodanjr_gr posted:Simple solution: pass the texture array index for each piece of geometry as a vertex attribute, and pass that through to the pixel shader. I see. I think a modified version of your second method ("Less simple") would ideally work for me. Now that I know what an atlas is, I'm not sure it would work, in a practical sense, for a scene that has models dynamically added / removed, as it would require a reprocessing of the atlas, and putting it back on the graphics card. What I mean by "modified version" is using a second TEXCOORD (or other variable in the layout; I'm not familiar with them all yet), so I don't potentially cause issues with drawing textures. Although, I'm thinking that you suggested using a few bits in an existing variable, because it's an unreasonable amount of waste to use an entire other TEXCOORD (or other variable), for a texture index. Edit: grammar Nahrix fucked around with this message at 00:35 on Apr 3, 2015 |
|
#
?
Apr 3, 2015 00:25
|
|
|
Nahrix posted:I see. I think a modified version of your second method ("Less simple") would ideally work for me. Now that I know what an atlas is, I'm not sure it would work, in a practical sense, for a scene that has models dynamically added / removed, as it would require a reprocessing of the atlas, and putting it back on the graphics card. What's the application that this will be used for? Combining meshes by material is an optimization that might not be necessary for whatever it is you're making, unless this is just a learning exercise. A common bottleneck for many 3D programs is frequent state changes. The entire problem is eliminated if everything rendered uses the same state (same set of textures, same vertex/index buffers, same rasterizer state, etc). But depending on how extreme you want to get with this it will potentially add a large work overhead. Also if you're using DX11, there's no specific TEXCOORD semantic. You can just name things whatever you want in your input layout, with a healthy number of formats available.
|
|
#
?
Apr 3, 2015 02:34
|
|
|
Nahrix posted:I see. I think a modified version of your second method ("Less simple") would ideally work for me. Now that I know what an atlas is, I'm not sure it would work, in a practical sense, for a scene that has models dynamically added / removed, as it would require a reprocessing of the atlas, and putting it back on the graphics card. quote:What I mean by "modified version" is using a second TEXCOORD (or other variable in the layout; I'm not familiar with them all yet), so I don't potentially cause issues with drawing textures. Although, I'm thinking that you suggested using a few bits in an existing variable, because it's an unreasonable amount of waste to use an entire other TEXCOORD (or other variable), for a texture index. Exactly! The whole idea of approach #2 is that you don't actually use an additional variable in your vertex layout and you do not generate another array of vertex attributes (which would waste memory). So, if you are using 16-bit texture coordinates, you would pack the 14 most significant bits of the actual coordinate component and then use the other 2 to encode "half" of your texture index. Repeat for the other texture coordinate component to get the remaining 2 bits. Then combine and enjoy. But as Sex Bumbo said, this entire thing will only really matter if you use A LOT of different textures (100s). If you are using 10 or 20 or whatever, just render your meshes in "batches", grouped by texture (assuming that the rest of the render state is the same). shodanjr_gr fucked around with this message at 07:04 on Apr 3, 2015 |
|
#
?
Apr 3, 2015 06:56
|
|
|
Sex Bumbo posted:What's the application that this will be used for? Combining meshes by material is an optimization that might not be necessary for whatever it is you're making, unless this is just a learning exercise. This is just a learning exercise; I'm not aiming for productivity. shodanjr_gr posted:Generally speaking, atlases are created "offline". You bake all the textures that you would need into the atlas and never touch it again. There exist more advanced techniques that will do this kind of swapping in real-time e: and also allow you to exceed the max texture size limits imposed by the GPU (if you're interested, look up "virtual texturing" or "partially resident textures"). Thank you both for the help!
|
|
#
?
Apr 3, 2015 19:50
|
|
|
Just want to post this here, since good, bulky test scenes can be surprisingly hard to find: http://graphics.cs.williams.edu/data/meshes.xml
|
|
#
?
Apr 15, 2015 18:14
|
|
|
D3D11's documentation re: usage modes is confusing me, especially about whether it's possible to write to a default-usage buffer from the CPU (the usage docs seem to suggest it isn't, but the UpdateSubresource docs suggest that it is). Is there an efficient way to set up something so that I can fill a structured buffer with a bunch of data with the CPU, then have a compute shader do some work on it that transforms it in-place, then use it as input to a later draw call? Or do I need to create a dynamic buffer for the CPU-written stuff and a default-usage buffer for the output? (I'm trying to have a compute shader do IDCT and doing it in-place will use half as much memory if it's possible, basically.) OneEightHundred fucked around with this message at 04:22 on Apr 18, 2015 |
|
#
?
Apr 18, 2015 04:18
|
|
|
OneEightHundred posted:D3D11's documentation re: usage modes is confusing me, especially about whether it's possible to write to a default-usage buffer from the CPU (the usage docs seem to suggest it isn't, but the UpdateSubresource docs suggest that it is). RE your first question, dynamic buffers can be updated using map/unmap (and, I think, UpdateSubResource), while default usage buffers can only be updated using UpdateSubResource. I've seen nvidia slides that said UpdateSubResource is implemented in terms of map/unmap. With map/unmap it's possible to get better performance due to the flags you can pass. For example by passing the discard flag, the driver can give you a fresh new buffer while the GPU is still operating on the previous one. However you can also create your own ringbuffer like mechanism to avoid writing the textures the GPU is using; it all gets complicated rather quickly. Personally I just tend to use map/unmap for frequent, array-like access and UpdateSubResource for more rare bulk updates.
|
|
#
?
Apr 18, 2015 19:42
|
|
|
Had a fun time debugging a gles shader. Apparently writing something like:code:
|
|
#
?
Apr 21, 2015 23:06
|
|
|
Sex Bumbo posted:Had a fun time debugging a gles shader. Apparently writing something like: Doesn't everything in the for loop pretty much have to be constant? WebGL threw errors about that for me, don't know about ES.
|
|
#
?
Apr 22, 2015 04:49
|
|
|
The typical hack around that is:code:
|
|
#
?
Apr 22, 2015 07:19
|
|
|
Tres Burritos posted:Doesn't everything in the for loop pretty much have to be constant? WebGL threw errors about that for me, don't know about ES. I don't think loops need to be constant in WebGL, but afaik there isn't real integer support in WebGL. I.e. the concept of floatBitsToUint should be meaningless since according to the spec: quote:Integers are mainly supported as a programming aid. At the hardware level, real integers would aid Suspicious Dish posted:The typical hack around that is: Is this a typical problem? Weirdly stuffing an integer that wasn't derived from a float worked fine. It felt like some weird overly aggressive optimization was being attempted in the glsl compiler and it hosed itself over.
|
|
#
?
Apr 22, 2015 18:48
|
|
|
|
| # ? May 24, 2024 12:26 |
|
|
Does anyone use the gles emulator? I only just started and I've already run into a few things that work both in opengl and non-emulated gles leading me to believe that support in the emulator is lacking. Alternatively I could be doing bad things that happen to work by luck.
|
|
#
?
Apr 22, 2015 22:48
|
|