Jump to content
  • Advertisement
Sign in to follow this  
vNeeki

Rendering lots of pixels 1 by 1 ?

This topic is 2351 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi.

I need to do a couple of heavy writes pixel by pixel and i was wondering which could've been the most efficient approach , since from what i read draw/readPixels functions are deprecated and not supported by GLES which i eventually plan to port my code to.

Any recommendations on how to handle this case?

Share this post


Link to post
Share on other sites
Advertisement

Shader? :-).


Its a part of a particle system effect which i update every frame.
IIRC i'll have to set the position for the shader uniform(?) variable every frame to achieve this which will be very slow.

Share this post


Link to post
Share on other sites
Setting a uniform every frame isn't going to be slow. Can you describe in more detail exactly what you're doing? There are many potentially good approaches but without the full info it's hard to give you direction.

Share this post


Link to post
Share on other sites

Can you describe in more detail exactly what you're doing?
[/quote]

I have a 2d map , and im doing some effects to pixel level.ie if you destroy a part of the map , that particular part will be split into smaller particles for a small amount of time.

And the problem is that some parts are very big(512x512) that cause everything to run at 20fps from 1000(!) for a small amount of time.


Setting a uniform every frame isn't going to be slow
[/quote]
Are you sure that setting a uniform forevery particle every single frame won't cause a bottleneck?

Share this post


Link to post
Share on other sites
Hi. I need to do a couple of heavy writes pixel by pixel and i was wondering which could've been the most efficient approach , since from what i read draw/readPixels functions are deprecated and not supported by GLES which i eventually plan to port my code to. Any recommendations on how to handle this case?


The best way would probably be to make a texture the size of your framebuffer, keep one copy of it in RAM and one on the GPU, make the changes to the in RAM texture and then update the texture on the GPU ( using http://www.opengl.or...xSubImage2D.xml ) Updating the texture is fairly slow so you don't want to do it once per pixel, make all the changes first, mark the changed regions as dirty and only update the dirty regions. (you'll need to decide how to create the regions, one region per changed pixel will be extremely slow but if you have 1 pixel in the top left corner and one in the bottom right that is changed you probably don't want to put them in the same region as that region would become incredibly large)

Now since you are making a particle system you might want to consider increasing the size of the particles, reducing their numbers and just setting uniforms for them instead.

If you do need an insane number of particles then you pretty much have to run the entire particle simulation on the GPU (to avoid the transmission costs)

Share this post


Link to post
Share on other sites

[quote name='vNeeki' timestamp='1334040290' post='4929794'] Hi. I need to do a couple of heavy writes pixel by pixel and i was wondering which could've been the most efficient approach , since from what i read draw/readPixels functions are deprecated and not supported by GLES which i eventually plan to port my code to. Any recommendations on how to handle this case?


The best way would probably be to make a texture the size of your framebuffer, keep one copy of it in RAM and one on the GPU, make the changes to the in RAM texture and then update the texture on the GPU ( using http://www.opengl.or...xSubImage2D.xml ) Updating the texture is fairly slow so you don't want to do it once per pixel, make all the changes first, mark the changed regions as dirty and only update the dirty regions. (you'll need to decide how to create the regions, one region per changed pixel will be extremely slow but if you have 1 pixel in the top left corner and one in the bottom right that is changed you probably don't want to put them in the same region as that region would become incredibly large)

Now since you are making a particle system you might want to consider increasing the size of the particles, reducing their numbers and just setting uniforms for them instead.

If you do need an insane number of particles then you pretty much have to run the entire particle simulation on the GPU (to avoid the transmission costs)
[/quote]

Oh wow those sound really great ideas , thanks ! ..Now atleast i've got something to try out smile.png

Share this post


Link to post
Share on other sites

Are you sure that setting a uniform forevery particle every single frame won't cause a bottleneck?


Well you didn't say that first time round. wink.png
But yeah, that will be slow.

Share this post


Link to post
Share on other sites
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

Are you sure that setting a uniform for

[/font]every particle every single frame [color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

won't cause a bottleneck?

[/font][/quote]

I'm kind-of wondering why this parameter needs to be a uniform at all. Perhaps it could be an element in your or a vertex stream?

Share this post


Link to post
Share on other sites
Yeah, if I were you I'd be using attributes, not uniforms.

I'd use the vertex shader to position the particles (just draw each particle as a triangle or a quad). Then if post processing was needed I'd use the fragment shader.

But of course, I might be drawing a different particle effect than you. So far you haven't described what kind of particle effect you're implementing, and some effects may be better implemented in different ways than other effects.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!