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

Login with username, password and session length

 
Advanced search

997945 Posts in 39129 Topics- by 30533 Members - Latest Member: KellyStark

April 16, 2014, 11:20:17 PM
  Show Posts
Pages: [1] 2 3 4
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.
Pages: [1] 2 3 4
Theme orange-lt created by panic