| Computers Forum Index » Computer - Graphics (Algorithms) » Updating only a few pixels on a texture, is there a... |
|
Page 1 of 1 |
|
| Author |
Message |
| Skybuck Flying... |
 Posted: Wed Sep 30, 2009 12:51 pm |
|
|
|
Guest
|
Hello,
Suppose the situation is as follows:
OpenGL is in 2D mode.
There are a few verteces on the screen drawn via gl_points.
There is an input texture and there is an output texture.
Render to texture is used.
What should happen is the following:
1. The input texture should be copied to the output texture.
2. The output texture should only be updated on the few verteces which map
to pixels.
Using a pixel shader to copy each pixel from input texture to output texture
seems wastefull to me ?
So first question is:
1. What is the fastest way to copy a texture to another texture ?
Second question is:
2. Is it possible to tell opengl to only render those pixels which are not
black ?
Maybe some kind of blend option is possible ? Or maybe a replace option is
possible ?
Or maybe some kind of masking ? Like a copy mask... only output those pixels
for which a bit is on.
However this would also require resetting the mask.. so then the question
would be what is the fastest way to reset a mask  and apply mask
updates/bits on/off ;)
So I am wondering if OpenGL/hardware has any special methods which can help
with the stuff described above ?!? and ofcourse if it would be hell-fast !?
 (faster than vertex/pixel shaders?)
Bye,
Skybuck. |
|
|
| Back to top |
|
|
|
| fungus... |
| Posted: Wed Sep 30, 2009 12:51 pm |
|
|
|
Guest
|
On Sep 30, 10:51 am, "Skybuck Flying" <BloodySh... at (no spam) hotmail.com> wrote:
The best place for this sort of posting would be a blog,
there's plenty of free ones.
--
<\___/>
/ O O \
\_____/ FTB. |
|
|
| Back to top |
|
|
|
| Skybuck Flying... |
| Posted: Wed Sep 30, 2009 1:35 pm |
|
|
|
Guest
|
One simple way might be:
1. Don't clear the framebuffer.
2. Set the verteces to be rendered by pixel shaders.
3. The pixel shaders update the necessary pixels.
Before the first run, the framebuffer is copied to a second texture as
well...
So that the framebuffer can function as an input texture as well... via the
secondary texture.
So first texture = frame buffer = output.
So second texture = input texture for shaders = input.
The framebuffer is updated with alterations.
Now there is a little problem.
After the pass is completed the framebuffer must be copied to the input
texture... so that the two are the same again... so that the next round can
begin.
So last question could be:
How to copy one texture to another texture lightning fast ?!?
Can it be done inside the gpu ? Or by some super fast opengl method ?!?
Failing that maybe a triple structure could work let's see if using three
textures might solve it.
Texture1, Texture2, Texture3 are all the same on start.
Texture1 = framebuffer = output.
Texture2 = input.
Texture3 = unused.
Render to multiple textures:
Texture1 = updated.
Texture3 = updated.
^ Voila two of the same textures !
Next round:
Texture1 = framebuffer = output
Texture3 = input
Texture2 = unused.
Render to multiple textures:
Texture1 = updated
Texture2 = updated
^ again two of the same textures ! nice.
Last try one more round:
Texture1 = framebuffer = output
Texture2 = input
Texture3 = unused.
Render to multiple textures:
Texture1 = updated
Texture3 = updated.
Voila back at round one again !
So all that is needed is a little algorithm to swap buffers like that...
And "render to multiple texture feature"
And hopefully render to multiple texture is lightning fast ?!?!?
Bye,
Skybuck. |
|
|
| Back to top |
|
|
|
| Vladimir Jovic... |
| Posted: Wed Sep 30, 2009 5:53 pm |
|
|
|
Guest
|
fungus wrote:
Quote: On Sep 30, 10:51 am, "Skybuck Flying" <BloodySh... at (no spam) hotmail.com> wrote:
Hello,
The best place for this sort of posting would be a blog,
there's plenty of free ones.
I would say "a garbage bin", because his posts contain lots of false
informations.
--
Bolje je ziveti sto godina kao bogatun, nego jedan dan kao siromah! |
|
|
| Back to top |
|
|
|
| Jamie... |
| Posted: Wed Sep 30, 2009 8:46 pm |
|
|
|
Guest
|
Vladimir Jovic wrote:
Quote: fungus wrote:
On Sep 30, 10:51 am, "Skybuck Flying" <BloodySh... at (no spam) hotmail.com> wrote:
Hello,
The best place for this sort of posting would be a blog,
there's plenty of free ones.
I would say "a garbage bin", because his posts contain lots of false
informations.
He's using this as his personal diary..
Must be a new way to save on paper!. |
|
|
| Back to top |
|
|
|
| Skybuck Flying... |
| Posted: Wed Sep 30, 2009 10:32 pm |
|
|
|
Guest
|
Ok,
After some sleep I realizzzed this can't work.
The input texture that was being used as input would not be updated so it
would fall out of sync.
So back to my original idea which was to try and use alpha value's and using
"blend".
However using "alpha's" would make the requirements go up from 3 components
to 4 components.
But if the alpha value can only be 1 bit than that would be nice. But I
doubt that's possible.
Anyway the original idea was to use one input texture and one output
texture.
The output texture would not be cleared.
The pixels would do their work on the output texture... and alpha values and
blend would be used to select either to input/modified/incoming pixel or the
output pixel.
Then after it's all done... the output texture would be *copied* to the
input texture.
So I am not sure if "scripts" can do "texture copies"... because I might be
able to stuff everything into one cgfx effects file and simply do 80.000
passes or so...
But if it can't do texture copies then I would have to fall back on using
opengl api's for each pass or so... that might slow things down...
Or maybe I could include an intermediate pass where simply a quad is drawing
to update the texture completely via a pixel shader or so...
Finally I also wonder if scripts can do "texture swapping" ? ;)
"Hey, leave me your number and I'll get back to you ! "
To be continued ! :)
Bye,
Skybuck =D |
|
|
| Back to top |
|
|
|
| Skybuck Flying... |
| Posted: Wed Sep 30, 2009 10:38 pm |
|
|
|
Guest
|
"Vladimir Jovic" <vladaspams at (no spam) gmail.com> wrote in message
news:h9vnsr$fjr$1 at (no spam) news01.versatel.de...
Quote: fungus wrote:
On Sep 30, 10:51 am, "Skybuck Flying" <BloodySh... at (no spam) hotmail.com> wrote:
Hello,
The best place for this sort of posting would be a blog,
there's plenty of free ones.
I would say "a garbage bin", because his posts contain lots of false
informations.
I don't think so... just this thread had a wrong algorithm at the start...
<- me trying to be super efficient... doesn't always work out ;)
Solution might be to use alpha value's but that requires extra bandwidth and
space.
Bye,
Skybuck. |
|
|
| Back to top |
|
|
|
| Skybuck Flying... |
| Posted: Wed Sep 30, 2009 11:08 pm |
|
|
|
Guest
|
Maybe the alpha solution isn't so good...
This would eat into space for the 4096x4096 space.
Maybe doing a copy at the start isn't so bad.
First input is copied to output to make them the same...
Then the shaders and such/effect are executed...
Which should update the output... this way clearing should not be necessary.
Instead of clearing there would be a copy at the start.
Sounds like a good plan ! ;)
And it doesn't require any extra space for alpha's ! ;)
Also no multiplications needed for alpha's ! ;)
No blending, no nothing of that ! Just overwrites ! ;)
Bye,
Skybuck. |
|
|
| Back to top |
|
|
|
| Skybuck Flying... |
| Posted: Thu Oct 01, 2009 1:38 am |
|
|
|
Guest
|
Actually I just realized something... the gpu performance would probably be
much worse...
Since if I remember correctly the cpu actually does 100 battle rounds !
(100x80.000 cycles ! = 8.000.000 per core ! total of 16.000.000 cycles on
dual core cpu !)
Oh-Oh ;)
GPU will definetly need a smarter algorithm than just "copieing everything"
! ;)
Bye,
Skybuck. |
|
|
| Back to top |
|
|
|
| Nicolas Bonneel... |
| Posted: Thu Oct 01, 2009 1:59 am |
|
|
|
Guest
|
Quote: The best place for this sort of posting would be a blog,
there's plenty of free ones.
I would say "a garbage bin", because his posts contain lots of false
informations.
I don't think so... just this thread had a wrong algorithm at the start...
- me trying to be super efficient... doesn't always work out
There is no way you can be efficient by spending most of your time
writing useless posts on usenet.
And you just flood internet with *wrong* things, he is right.
Quote: Solution might be to use alpha value's but that requires extra bandwidth and
space.
clip(-1), discard, modulate with alpha, add, creating a geometry which
matches pixels you want to rasterize... tons of solutions. I don't know
why I bother answering you, you don't even read the doc. And believe me,
reading the doc will make you much more efficient. It's not because
*you* don't understand the doc that it means the doc is bad.
Don't you realize noone answer your posts ? Don't you ask yourself why ?
I read somewhere you were a phd student...... uhhh... really?? I must be
mistaken. Do you have remaining time to publish?? Is you advisor aware
of your posts ?
--
Nicolas Bonneel
http://www-sop.inria.fr/reves/Nicolas.Bonneel/ |
|
|
| Back to top |
|
|
|
| Charles E Hardwidge... |
| Posted: Thu Oct 01, 2009 2:41 am |
|
|
|
Guest
|
I'm trying out the proposed boilerplate the OpenGL newsgroup is negotiating:
The person posting under the name "Skybuck" is
a troll/idiot who should ignored, not replied to.
If your newsreader has message filters you should
set them to ignore any thread with his name in it.
If you don't have such a newsreader or are reading
via a web browser (eg. Google Groups) then you
should make a mental note to simply *ignore* any
thread started by this person.
Thank you for making comp.graphics.api.opengl a
better place.
--
Charles E Hardwidge |
|
|
| Back to top |
|
|
|
|
