Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1059374 Posts in 43070 Topics- by 35024 Members - Latest Member: SimpleApps

October 31, 2014, 12:42:48 PM
  Show Posts
Pages: [1] 2 3
1  Developer / Technical / Re: GLSL variable index for array? on: September 13, 2013, 03:19:33 PM
Blink Could be a bug in the shader compiler, which I think is located in the 3D card driver. I personally would compile 1 shader for each "option", one for each amount of light sources... if 5 lights does not work you can use the 4 lights shader or less.

But that presents another problem: I can get 3 lights to work if I am using an array of size 5. But if I use an array of size 3, only 2 of the lights work using dynamic indexing! I could just use constants to index the array, but I absolutely don't want to resort to that.

I feel like giving up and just using a texture buffer/array/whatever instead of a uniform buffer; why even use the stupid buffer if I can't loop through the data? That's like telling me I can't breathe air!

I really wish it was some asinine thing I'm doing wrong instead of a hardware issue...
2  Developer / Technical / Re: GLSL variable index for array? on: September 12, 2013, 11:34:16 PM
"No errors" for both compiling and linking, though the compilation warned me about appending "f" or "F" to my float values wouldn't work in pre-110 GLSL. I also changed the member of my light struct to be "act" instead of "active", but to no avail. I can only access the 4th and 5th lights using constants.
3  Developer / Technical / Re: GLSL variable index for array? on: September 12, 2013, 06:35:15 PM
Also just to cover all bases in case your "50" in the loop there isn't actually a constant in the shader but another uniform that might be also an issue. For similar reasons (no dynamic branching).

That isn't it; the array size is constant.

I did end up lowering the number of lights in the array to 5. Of the 5, only the first three lights work when using a dynamic index. The other two lights only work with a constant index. For reference, here is my fragment shader implementation:

Code:
#version 330

struct light
{
vec4 color;
vec2 position;
float radius;
int active;
};


in vec4 colorIn;
out vec4 outputColor;


layout(std140) uniform LightArrayBlock
{
light lightElement[5];
};

uniform vec4 ambientLightIntensity;

void main(void)
{
outputColor = colorIn * ambientLightIntensity;

for(int i = 0; i < 5; ++i)
{

float xFact = lightElement[i].position.x - gl_FragCoord.x;
float yFact = lightElement[i].position.y - gl_FragCoord.y;

float distance = sqrt((xFact*xFact) + (yFact*yFact));
float attenValue = lightElement[i].radius/( 1 + distance + (0.02*distance*distance) );

//apply the actual color of the light
vec4 attenColor = lightElement[i].color * vec4(attenValue, attenValue,attenValue, 1.0);

//Augment the color, IF the light is active
outputColor += (lightElement[i].active * attenColor);
}

//HACK FOR THE FOURTH LIGHT TO WORK
float xF = lightElement[3].position.x - gl_FragCoord.x;
float yF = lightElement[3].position.y - gl_FragCoord.y;

float d = sqrt((xF*xF) + (yF*yF));
float aValue = lightElement[3].radius/( 1 + d + (0.02*d*d) );

//apply the actual color of the light
vec4 aColor = lightElement[3].color * vec4(aValue, aValue,aValue, 1.0);

//Augment the color, IF the light is active
outputColor += (lightElement[3].active * aColor);
}

Is it really implementation dependent? It seems like, if the first three lights work fine, then the last two not working is some other problem, right? If I couldn't use dynamic indexing, wouldn't all of the lights fail? This is incredibly frustrating...
4  Developer / Technical / GLSL variable index for array? on: September 11, 2013, 02:10:44 PM
Hey all,

So I have an array of 50 light structs in my C++ program, which look like this:

Code:
basic_light
{
  basic_color color;
  2D_point position;
  float radius;
  int active;
};

And I am uploading them to a fragment shader using a Uniform Buffer Object. The Uniform Block Interface looks like this:

Code:
layout(std140) uniform LightArrayBlock
{
  basic_light lightElements[50];
}

With structs on the fragment shader that look like this:

Code:
basic_light
{
  vec4 color;
  vec2 position;
  float radius;
  int active;
};

And I'm using a loop to access all of my lights in the fragment shader:

Code:
for(int i = 0; i < 50; ++i)
{
  //somehow access lightElements[i]
}

So... things are screwing up here. The lights can't be accessed regularly using this loop. However, I noticed that I can access any element just by using a constant:


Code:
//this all works fine
lightElements[13]
lightElements[27]
lightElements[46]

I've seen some stack overflow posts asking about this same problem, but I haven't seen any kind of workaround that doesn't look really sucky. Anyone here know how I might fix this?

Thanks for any comments or advice!
5  Developer / Technical / Re: OpenGL particle System: gl_points? on: August 13, 2013, 09:41:11 PM
Thanks for the advice! Yeah, I just finished a very simple geometry shader that billboards sprites. I understand that moving things from CPU to GPU is expensive, but the geometry shader is optional; is spitting out 3 new vertices in this optional stage cheaper than just shoving them into the vertex shader to begin with? I'm assuming this is the case. It is certainly somewhat easier to set up.

I'm also aware of the "reuse memory" thing. Though, if I get transform feedback to work, I won't have a ton of objects anyway; everything should be moving around on the GPU, not the CPU... to my understanding.
6  Developer / Technical / Re: OpenGL particle System: gl_points? on: August 10, 2013, 05:09:03 PM
So, I've been looking into things more, and I am attempting to use transform feedback to make this particle system in 2D. I am getting nowhere fast (I apologize if this should be put into a new thread).

I'm been searching everywhere and trying to piece together some kind of understanding about transform feedback. I think I get it, but I have a few questions:

  • Do I even need transform feedback? I understand that keeping things sequestered on the GPU will give me the freedom to use more particles than a CPU implementation, and I would like the freedom to have particle systems moving hundreds of particles around. But do I absolutely need TF for this?
  • I get the part where the geometry shader is able to create primitives on-the-fly. My confusion stems from WHERE it actually does this. I can't pinpoint the spot in the shader where this takes place(in the examples I've seen).
  • As far as I understand it, one VBO is used to store updated information about all the particles; this is when glEnable(GL_RASTERIZER_DISCARD) is used. The second VBO is used to actually render the particles on the screen; the information in this VBO was updated previously. The two VBOs continually switch places; with one serving as the "Update Me!" VBO and the other serving as the "Render Me!" VBO... is this correct?

Anyway, I'm having a tough time wrapping my head around this... maybe there is a simpler way to create a particle system that doesn't involve learning a bunch of new OpenGL stuff all at once?

Thanks for any help/advice!
7  Developer / Technical / Re: OpenGL particle System: gl_points? on: August 07, 2013, 05:03:16 PM
As mr. Balster pointed out, you can texture them - so you get always-camera-facing particles way easier than with quads - they should be somewhat faster too, since the vertex shader is run only one fourth of the time and is probably a bit simpler.

I may do that; my game is in 2D, so I probably won't be changing the perspective at all anyway.

The main reason I use (flat shaded) points for a particle system rather than texture quads, though, is that they look better in a lot of cases.

Could you elaborate on this?

EDIT: Also, thanks for the heads up @ThemsAllTook. I just confirmed your caveat for my setup.
8  Developer / Technical / Re: OpenGL particle System: gl_points? on: August 07, 2013, 11:59:01 AM
You can make a point display a texture of variable certain size oriented toward the camera, if you write a little shader for that purpose.

This works in modern OpenGL as well, correct?
9  Developer / Technical / OpenGL particle System: gl_points? on: August 07, 2013, 07:21:11 AM
Hey all.

I'm in the process of making my first particle system in OpenGL. I saw a few tutorials talking about using GL_POINTS... but this is kind of limiting, right? There isn't really a whole lot you can do with those compared to using quads, which you can just wrap a texture over. So is there any reason to use GL_POINTS for a particle system? Or really, anything else at all?
10  Developer / Technical / Re: 2D normal map creation on: July 25, 2013, 12:01:01 PM
Just test it and see what happens... Then tweak it.

That's the plan! Though, what I probably should have done, was make a very simple normal map... a map of a square or something, and then try out lighting calculations using that. At the moment I don't even have the lighting calculations or infrastructure to support normal maps, so I'm kind of dealing with two things at once.

Thanks again to everyone! Glad I am a bit further on my way to understanding/using this stuff.
11  Developer / Technical / Re: 2D normal map creation on: July 19, 2013, 12:30:52 PM
OK. I am going to experiment a bit with a spritesheet I made and see if I can get anywhere interesting. I'll report back asap!

EDIT: Alright, I'm back. Here is a small experiment I tried using the hemisphere posted by Oskuro. However, I flipped the hemisphere to reflect orientation of sert's hemisphere, given that those are the colors I've seen most in other normal maps I've looked at. I'm sure this map I created here isn't entirely right; I created it manually just going off of what I thought it should look like.



I haven't actually edited my framework/shaders yet to handle a normal map, so I'm going to go ahead and start looking into that. In the meantime... does this look even remotely correct?
12  Developer / Technical / Re: 2D normal map creation on: July 16, 2013, 09:45:27 AM
OK. I am going to experiment a bit with a spritesheet I made and see if I can get anywhere interesting. I'll report back asap!
13  Developer / Technical / Re: 2D normal map creation on: July 15, 2013, 09:59:56 AM
Not sure if this is asking too much, but could anyone walk me through it in more of a step-by-step fashion? Like, baby steps.

I think I understand the spheres posted by surt and Oskuro, but correct me if I'm wrong: the middle of the sphere represents normal vectors that are heading straight towards the camera, while the other colors represent vectors angled further and further away from the camera. The edges of the sphere represent vectors that are orthogonal to the Z axis pointing towards the camera.

So, I think I get that part. What I don't understand is how to choose the colors that should be represented at each pixel in a sprite. And I don't understand how to build a heightmap. Should I be using a heightmap or manually painting in the normal map? And if I had to do it manually, how do I decide which colors to use?

Sorry if that is an overload of questions, I'm just trying to wrap my head around it. Thank you all for your help so far!
14  Developer / Technical / 2D normal map creation on: July 11, 2013, 10:07:48 AM
I am currently trying to build an application that will help me manage 2D sprites and metadata, so I can easily import them into my game. I know there are tools already available, but I am doing this from scratch to benefit from the learning process.

One feature I would like to include in this application is an option to create normal maps for a spritesheet. I don't completely understand the process yet, but I have been doing some research. These are the links I have looked at so far:

PDF explaining normal map gimp plugin

Paper about bump maps and refraction

Normal mapped sprites in Legend of Dungeon

Normal maps in Spelunky (first image)

So, my questions are:
  • Shouldn't the normal map for a sprite be created differently depending on the perspective the game is in? For example, Spelunky is a side-on view, while the perspective for a Secret of Mana or Pokemon type game is more overhead.
  • Is there any tutorial that exactly explains the in-depth process behind creating a normal map? I understand that the RGB channels are used to describe XYZ, respectively... but what determines the values? I feel like the steps in the Legend of Dungeon explanation jump a bit too far from one step to another, and I'm missing something.

Thanks for any help/suggestions!
15  Developer / Technical / Re: 2D Lighting in OpenGL... a few questions on: July 05, 2013, 01:12:41 PM
@notnowlewis I had already seen the first two, but I haven't seen the second two links. Thanks for the help!

I actually inserted some code that allowed me to move the position of my "light" around, and it definitely looks like a point light. But as has been said already, I probably need some shadows to make everything look good.

One thing that I haven't accomplished very well is making my quads respond to light in a more believable way. Whenever I move the point light closer/further from a quad, that quad just has its own colors augmented between 100% and 0%, based on distance. I think I need to edit the equation a bit so that the quads get a kind of highlight and appear white when the light passes over them.
16  Developer / Technical / 2D Lighting in OpenGL... a few questions on: June 28, 2013, 11:54:30 AM
Hello again TIGSource! I'm starting my epic journey into the world of lighting in OpenGL 3.3, for a 2D game.

Background: Right now, I have quads that are rendered using a single VBO. The VBO has vertices (0,0) (0,1) (1,0) (1,1), and is scaled to whatever size I need. I render a texture on this quad whenever I need to display a 2D sprite.

I have been fooling around with my fragment shader, just implementing simple ambient lighting, and a few different effects based on glFragCoord. I feel comfortable moving on to more complicated things.

Questions:

  • Could the lights in OpenGL (like GL_LIGHT0) be used for a 2D game? I guess I don't really understand what they are used for. I know there is some kind of misconception that there is a maximum of 8 lights, but this isn't actually the case... what are these lights and how do they pertain to me?
.

  • I understand that a texture of a white circle with a gradient can be used to create some simple lighting effects in 2D. Is this used at all in more complicated systems? I understand the concept here, and if it isn't that useful outside of very simple lighting effects, I'd like to avoid it altogether.
.

  • I understand that there are basically 3 different types of light: ambient, diffuse, and specular. Will I still be using these concepts in a 2D environment?
.

  • One thing that is bothering me is point lights. My understanding of a point light is literally a point in space that is a source of light; the effect of the light on the surrounding objects/environment is weaker as the distance from the light increases. Do I need to use an actual OpenGL point primitive paired with a home-rolled shader to achieve this kind of light? I'd rather not use the "texture of a white circle" thing because I would like the light to be hindered by walls, which can't be done using the texture approach.


I apologize for the long winded questions. I also apologize if I missed something obvious in my research. Thanks for all of your help TIGSource!

EDIT: I also really like the idea of creating normal maps for characters and objects in the game and using these with shaders for some interesting effects... I ~think~ I understand how to do this, but I would probably need to know how to implement point lights first...
17  Developer / Technical / Re: OpenGL function calls crash program on: June 15, 2013, 09:21:57 AM
Thanks @Polly, that seems to have done the trick! I will update if there are any further troubles.

So is this the issue I am running into (via wikipedia):


    C compilers do not name mangle symbols in the way that C++ compilers do.
    Depending on the compiler and architecture, it also may be the case that calling conventions differ between the two languages.

For these reasons, for C++ code to call a C function foo(), the C++ code must prototype foo() with extern "C"


18  Developer / Technical / Re: OpenGL function calls crash program on: June 15, 2013, 08:51:09 AM
@ThemsAllTook my stack trace isn't helping me out much. The function I am calling is a member function of an instance class. This member function calls an OpenGL function defined in another translation unit. The last function that is seen in the stack trace is the member function, with this:

Frames below this may be incorrect and/or missing.

And the message is that I had an Access Violation when executing location 0x000000000 (or something akin to that).

I have tried using the extern keyword... I have used it before successfully, but I guess I am kind of confused right now how I should use it. My function pointers are declared like this:
Code:
PFNGLATTACHSHADERPROC glAttachShader;
PFNGLBINDBUFFERPROC glBindBuffer;
PFNGLBINDVERTEXARRAYPROC glBindVertexArray;
PFNGLBUFFERDATAPROC glBufferData;

So, I tried using extern as follows:

Code:
extern PFNGLATTACHSHADERPROC glAttachShader = NULL;
extern PFNGLBINDBUFFERPROC glBindBuffer = NULL;
extern PFNGLBINDVERTEXARRAYPROC glBindVertexArray = NULL;
extern PFNGLBUFFERDATAPROC glBufferData = NULL;

But that blew up even more.

I guess I am kind of confused why the static keyword doesn't work. Using it allows my program to compile and allows other translation units to see these function pointers. But this is obviously wrong since using these functions in different translation units always leads to a crash.

Also, thanks for the help so far everyone!
19  Developer / Technical / Re: OpenGL function calls crash program on: June 14, 2013, 01:43:56 PM
I have since removed the namespaces surrounding the function pointers in the header file... but I still get the same error when encountering these functions... Cry
20  Developer / Technical / OpenGL function calls crash program on: June 14, 2013, 12:52:31 PM
Hey all,

I'm working on a small library for making games using OpenGL. I created a static library into a .lib file in MSVC, and I'm using that library for a sample game to test that the library works.

The problem I am running into has to do with calling the function pointers that point to OpenGL extension functions. I am manually loading in the OpenGL extensions using wglGetProcAddress (I want to do things manually so I understand more of what is going on). I think it has to do with the way I'm setting up my code:


ogl_framework.h
Code:
#ifndef _OGL_DRAWING_H_
#define _OGL_DRAWING_H_

#ifdef _WIN32
#include <windows.h>
#include <gl\gl.h>
#pragma comment(lib, "opengl32.lib")

#include "glext.h"
#include "wglext.h"

#endif // _WIN32

#include <math.h>

namespace eagle_alpha
{
namespace ogl_framework
{
//Function pointers for extensions, should be platform agnostic
static PFNGLATTACHSHADERPROC glAttachShader;
static PFNGLBINDBUFFERPROC glBindBuffer;
static PFNGLBINDVERTEXARRAYPROC glBindVertexArray;
static PFNGLBUFFERDATAPROC glBufferData;
static PFNGLCOMPILESHADERPROC glCompileShader;
static PFNGLCREATEPROGRAMPROC glCreateProgram;
static PFNGLCREATESHADERPROC glCreateShader;
static PFNGLDELETEBUFFERSPROC glDeleteBuffers;
static PFNGLDELETEPROGRAMPROC glDeleteProgram;
static PFNGLDELETESHADERPROC glDeleteShader;
static PFNGLDELETEVERTEXARRAYSPROC glDeleteVertexArrays;
static PFNGLDETACHSHADERPROC glDetachShader;
static PFNGLENABLEVERTEXATTRIBARRAYPROC glEnableVertexAttribArray;
static PFNGLGENBUFFERSPROC glGenBuffers;
static PFNGLGENVERTEXARRAYSPROC glGenVertexArrays;
static PFNGLGETATTRIBLOCATIONPROC glGetAttribLocation;
static PFNGLGETPROGRAMINFOLOGPROC glGetProgramInfoLog;
static PFNGLGETPROGRAMIVPROC glGetProgramiv;
static PFNGLGETSHADERINFOLOGPROC glGetShaderInfoLog;
static PFNGLGETSHADERIVPROC glGetShaderiv;
static PFNGLLINKPROGRAMPROC glLinkProgram;
static PFNGLSHADERSOURCEPROC glShaderSource;
static PFNGLUSEPROGRAMPROC glUseProgram;
static PFNGLVERTEXATTRIBPOINTERPROC glVertexAttribPointer;
static PFNGLBINDATTRIBLOCATIONPROC glBindAttribLocation;
static PFNGLGETUNIFORMLOCATIONPROC glGetUniformLocation;
static PFNGLUNIFORMMATRIX4FVPROC glUniformMatrix4fv;
static PFNGLACTIVETEXTUREPROC glActiveTexture;
static PFNGLUNIFORM1IPROC glUniform1i;
static PFNGLGENERATEMIPMAPPROC glGenerateMipmap;
static PFNGLDISABLEVERTEXATTRIBARRAYPROC glDisableVertexAttribArray;
static PFNGLUNIFORM3FVPROC glUniform3fv;
static PFNGLUNIFORM4FVPROC glUniform4fv;
static PFNGLUNIFORM1FVPROC glUniform1fv;

//actual functions
void Enable2D();
void Disable2D();

#ifdef _WIN32
bool InitializeExtensions(HWND);
bool InitializeOpenGL(HWND, int, int, float, float, bool);
void ShutdownOpenGL(HWND);
bool LoadExtensionList();
GLenum OGL_Error_Checking();
char* Get_OGL_Version();

//Function pointers for windows WGL extensions
static PFNWGLCHOOSEPIXELFORMATARBPROC wglChoosePixelFormatARB;
static PFNWGLCREATECONTEXTATTRIBSARBPROC wglCreateContextAttribsARB;
static PFNWGLSWAPINTERVALEXTPROC wglSwapIntervalEXT;
#endif // _WIN32
}
}

#endif // _OGL_DRAWING_H_


And here is the code that decides to crash:


TextureQuadObject.cpp

Code:
#include "TextureQuadObject.h"

namespace eagle_alpha
{

TextureQuad::TextureQuad()
{
vertexArrayID = 0;
vertexBufferID = 0;
indexBufferID = 0;
}

TextureQuad::~TextureQuad()
{

}

bool TextureQuad::InitQuad()
{

// Allocate an OpenGL vertex array object.
eagle_alpha::ogl_framework::glGenVertexArrays(1, &vertexArrayID);

// Bind the vertex array object to store the vertex buffers and vertex attributes we create here.
eagle_alpha::ogl_framework::glBindVertexArray(vertexArrayID);

// Generate an ID for the vertex buffer.
eagle_alpha::ogl_framework::glGenBuffers(1, &vertexBufferID);


I know some of it looks ugly, I'm working on fixing it...

So I believe it has to do with the function pointers of ogl_framework.h being static. If I use these functions within ogl_framework.cpp (not shown) they work like a charm. But I want to use these functions from outside this translation unit, as per the example above.

I need these function pointers in the header file so other translation units can access them using the eagle_alpha::ogl_framework namespace. They need the static keyword to resolve scope issues.

Not sure exactly how to proceed, but I'm going to keep fooling around with it to see if I can fix it entirely. Thanks for any/all help or criticism!
Pages: [1] 2 3
Theme orange-lt created by panic