Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


noodleBowl

Member Since 08 Sep 2013
Offline Last Active Jan 30 2015 01:39 PM

Topics I've Started

What to do for debugging

28 January 2015 - 01:16 PM

A few days ago, I wanted to test some initial systems I made and see how they would perform on a computer that wasn't my dev pc.

 

So I handed out some EXEs to my friends, first friend everything runs perfectly. Second friend instant crash! I thought maybe it has something to do with graphics drivers, so they tested it on a different computer... Boom crash again! Having no idea why I added more debug and checkpoint statements. After a hour or so I finally had enough statements to pin point the problem, figured out I never set a GLEW boolean to true

 

Then this got me thinking about debugging. What happens if something like this happens again? I don't want to go back and add a ton of statements every time a problem happens. Normally I would add some global debug variable to switch debugging on/off, but when I think about it that can't be that great of a solution right? I mean, you'ed have a if check for every block of debug statements. That's got to hurt performance to do all those checks, especially if you have a lot

 

So I'm wondering what do you guys do? Or am I doing it?

 

 


Clean up and what to keep in mind

26 January 2015 - 08:59 AM

I'm sorry if this is super broad, but I'm about to do my first clean up phase for my framework and I really want to get the initial foundation down for this so everything is maintainable. Something I feel like that was kind of put on the back burner when it comes to 'general' design practices, because I don't really know what they are when it comes to C++

So I'm wondering what kinds of OO concepts / general things, even if they are little things, that I should keep in mind?
I'm talking about things like The Rule of 3 or little performance tricks and tips

[Design Hiccup] Particles and Transform feedback

20 January 2015 - 08:53 AM

I am currently trying to finish up my particle system. The core of it is built, but I keep running into a major hiccup!

 

For my system I am targeting OpenGL 3.3 and using transform feedback in order to create a State Particle System.

Each of my particles in this current point in time have the following attributes: Current Position, Deviation from the Starting Position, Velocity, Starting Velocity, Acceleration, Current Lifetime, and Lifespan (starting lifetime). In addition to this, each particle is to be represented as a quad and have texture coords for their image.

 

My hiccup or major block comes in with the transform feedback and the output varyings.

In my particle update area, my transform feedback is using GL_POINTS to iterate over each particle where it outputs the new velocity, acceleration, etc. The major drawback/part in this update is that one run of GL_POINTS (one particle update) will output 4 positions (one for each corner of a quad). I do this to prevent floating point discrepancies between the positions, since they should be all the same and a single difference means I get a graphics glitch. After everything is said and done my VBO ends up looking like:

//All particle data is stored in the same buffer
//Particle1                                                                 //Particle2
[Position1, Position2, Position3, Position4, Velocity...][Position1, Position2, Position3, Position4, Velocity...]

My mega block / kicker

My hiccup comes in right here. While I can update the buffer above perfectly, the other major thing I need to do is read it for rendering.

This is the part I cannot seem to get down. Due to the VBO's data and its makeup, my shader cannot properly read in the data. It gets confused and ends up using a Velocity, Acceleration, etc as a position causing my particles to get rendered incorrectly

 

I thought about just having extra dummy data in my VBO, so that my Vertex Pointers would see my VBO data correctly.

Basically I decided to pad the attributes other than position:

//All particle data is stored in the same buffer
//Particle1                                                                                                                                                         //Particle2
[Position1, Position2, Position3, Position4, Velocity, DummyVelocity1, DummyVelocity2, DummyVelocity3...][Position1, Position2, Position3...

But I get left hooked by my transform feedback, since output varyings can only write the exact way they are configured and have no ability to offset or skip certain blocks of data. My attributes run over each other when updating, making me run into the same problem above.

 

I thought to combat this I could just write more/double up on my output varyings. But I get right hooked by the GL_MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS limit as I easily am already close to the maximum.

Once I start using texture coords or even if I decide my particles need another attribute I will go over the max. Making this solution a no go sad.png

 

Now, I'm left kind of in the dark as to what to do. I thought about doing a double update pass, where I run though my "non render attributes" and update them, outputing the results to a VBO. Then running a secondary update, using results from the first update to update each particle's position and the output from this update would go to a third buffer and get used in the render. Something like:

 
//First pass: updating the velocity, acceleration, etc. Uses its own varyings
glBindBufferBase(GL_TRANSFORM_FEEDBACK_BUFFER, 0, nonRenderVBO);
glBeginTransformFeedback(GL_POINTS);
glDrawArrays(GL_POINTS, 0, particleCount);
glEndTransformFeedback();
 

//Second pass: updating the positions. Uses its own varyings
glBindBuffer(GL_ARRAY_BUFFER, nonRenderVBO);
glBindBufferBase(GL_TRANSFORM_FEEDBACK_BUFFER, 0, positionVBO);
glBeginTransformFeedback(GL_POINTS);
glDrawArrays(GL_POINTS, 0, particleCount);
glEndTransformFeedback();
 
/*Later on: use the positionVBO in my render method*/

 

BUT I feel like this is a very horrible idea / poor solution.....

 

Any ideas on what I could do so I can get over this roadblock? Any help would be appreciated


Transform feedback and offsets?

18 January 2015 - 08:57 PM

I'm currently working with transform feedback in OpenGL 3.3 and I'm having some trouble with the output varyings.

I have a few output variables that need to be quadrupled. Since I currently have roughly around 7, which may go up more, I'm worried that I will come close to maxing out. My max is 64 according to the value I get back from GL_MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS .

In my current setup, I can get back data BUT
I need to skip over some spots when I write to the output buffer in order to read from it properly.
 
With my current l VBO, my data is setup to look like:
//VBO layout
POS0 , VELO0 , POS1 , VELO1 , POS2 , VELO2 , POS3 , VELO3 | POS4 , VELO4 , POS5 , VELO5 ....

//Actual data inside
320.0, 250.0, 1.0, 1.0, 320.0, 250.0, 1.0, 1.0, 320.0, 250.0, 1.0, 1.0, 320.0, 250.0, 1.0, 1.0 | 100.0, 100.0, 1.0, 1.0,....
When the transform feedback is activated and it is done writing to my buffer, I get the following output
//Actual data after transform feedback has run once; The position2OUT and position3OUT are written over the wrong spots in the buffer
320.0, 250.0, 1.0, 1.0, 320.0, 250.0, 320, 250.0, 320.0, 250.0, 1.0, 1.0, 320.0, 250.0, 1.0, 1.0 | 100.0, 100.0, 1.0, 1.0,....
It literally writes the data back how they are setup. Messing up the layout of the VBO originally created
Varying setup:
const GLchar *varyings[5];
varyings[0] = "position0OUT";
varyings[1] = "velocityOUT";
varyings[2] = "position1OUT";
varyings[3] = "position2OUT";
varyings[4] = "position3OUT";

updateProgram.AddTransformFeedbackVaryings(5, varyings, GL_INTERLEAVED_ATTRIBS);
Is there a way to setup an offset of some kind for output varyings?
So that my position1OUT, position2OUT, and position3OUT will be written to their correct spots?

The only other thing I can think of is just to write junk data to the buffer using an out array variable and getting it to work with the
transfomm feedback. Giving me more output varyings in the bank to use, at least I think this will happen

I was trying something like in my shader:
#version 330 core

in vec2 positionIN;
in vec2 velocityIN;

out vec2 positionOUT[4];
out vec2 velocityOUT[4];

void main()
{
positionOUT[0] = positionIN;
/* other setting code */
}
But I get errors when compiling. It complains that I 'cannot convert in 2-component vector of float to 2-component vector of float'.
So I'm not sure if the syntax is wrong or I really can't do that sad.png

Bad Practice? Multiple VAOs

14 January 2015 - 09:19 AM

I'm rounding out a particle emitter I'm creating, which uses transform feedback. As you can guess, I have a update method to update my particles and then a render method to actually show them on the screen.

To avoid floating point issues, in my transform feedback I'm using GL_POINTS and then out 4 values per input.
E.G Update code:

//CPU side of things
glBeginTransformfeedback(GL_POINTS);
glDrawArrays(GL_POINTS, 0, particleCount);
glEndTransformfeedback();

//In my Shader code
//My Shader Inputs/Outputs
in vec2 positionIN;
out vec2 position0OUT;
out vec2 position1OUT;
out vec2 position2OUT;
out vec2 position3OUT;
When I hit the render method I use my buffer that I just wrote to, I am Ping-Ponging the buffers too, to get the particles on the screen. Where I use glDrawElements and GL_TRIANGLES, so I'm basically expanding the points from the transform feedback into a quad.
//CPU side of things
glBeginTransformfeedback(GL_POINTS);
glDrawArrays(GL_POINTS, 0, particleCount);
glEndTransformfeedback();

//In my Shader code
//My Shader Inputs/Outputs
in vec2 positionIN;
out vec2 position0OUT;
out vec2 position1OUT;
out vec2 position2OUT;
out vec2 position3OUT;

Here is where my question comes in. In order for this to happen I believe I need 4 VAOs.

1 VAO for the way the data should be interpenetrated in the update method. This VAO skips redundant data since I want avoid recalculating the same information over and over.

1 VAO for the way the data should be interpenetrated in the render method. Does not skip data and interprets 1 GL_POINT from the transform feedback as a quad's vertex.

A additional VAO for each of the above because I need to Ping-Pong my VBO buffers.


So am I creating a situation for myself where I'm falling into a bad practice?
Is this too many VAOs for one object, where there is a high chance that there will multiple instances of this object?

Would it be better to just bind the buffer I need?

//Example: code in update mehtod
glBindVertexArray(renderVAO)
glBindBuffer(GL_ARRAY_BUFFER, vbos[currentVBO]);

/* Other code for transform feedback */


PARTNERS