Jump to content
  • Advertisement
Sign in to follow this  
CukyDoh

Updating a Texture

This topic is 3917 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

Firstly I'll just say that I haven't been doing Direct3D that long, and that I am finding my way around okay, just that there's waaay too many tempting big red buttons marked "Do not push" sometimes! What I'm trying to do is have a single A8R8G8B8 texture, and then each frame I want to go through each texel's channels, and alter it based on a couple of rules about itself and the surrounding texels. I was talking to one of my lecturers in uni, and he gave me lots of things to look at, although so far the topics seem related definately, but don't seem to be able to do exactly what I'm after, or at least not without being a little too messy or overly complex. The main things he mentioned to me where just manually locking the Texture (Dynamic), and then going through each texel, although I see this as my last resort because it just seems too messy I guess! That and I'm not 100% sure once it's locked what to do when ti comes to how to data is stored, etc. Other than that he suggested looking at things like RenderToSurface() functions to see if I could find any help there. If possible I'd like to be able to do it in a shader of some sort, because I'm enjoying them at the moment, and have got to the stage where I can look up surrounding texels, just not how to then do things to them. If anyone can help, I'd really appreciate it, and am really just looking for the main techniques or functions I should be looking in to, and if possible some rough psuedocode on how to use those techniques. Thanks to anyone who helps!

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by CukyDoh
The main things he mentioned to me where just manually locking the Texture (Dynamic), and then going through each texel, although I see this as my last resort because it just seems too messy I guess!


You have to do the work somewhere, you might as well do it on the CPU so that you can step through it in the debugger and figure out what you're doing.

Once you've got it working on the CPU, maybe you can change the implementation to use a shader, but IMO that's going to be harder for a n00b to figure out than just stepping through code in the debugger on the CPU.

Do you know how to lock a resource and access its pixel data? I discuss that in Chapter 4. 2D Applications in my book. Take a look at that.

Share this post


Link to post
Share on other sites
Is this to be done in real-time as quickly as possible, or are we talking about a precalculation/one-off processing pass?

If it's performance-critical, then you'll probably want to be using the shader-based MRT approach ultimately, as the GPU is designed to do this kind of thing. But legalize makes a good point - debugging a fresh new algorithm inside a pixel shader is a lot of trouble. Take things one step at a time and I'm sure it'll be fine.

In the case of a single pre-calculated texture-generation (for example) or a reasonably slow real-time simulation there's no need to get the video card involved. Your CPU can do the job in absolutely no time.

Admiral

Share this post


Link to post
Share on other sites
Thanks for the replies so far.

I didn't really think I'd have much trouble implementing this on the CPU, and luckily I didn't. The calculations I wanted to run on the texture weren't really too complex, although I did want to take it up a bit more, but I'll wait until I can run it at a real-time frame-rate before that.

I did say in the original post, but I guess it was missed, but; I do want this to run in real-time, calulating an update on the texture every frame. I've got the function working how I want running on the CPU at a bad frame-rate.

I know that it is possible to do this on the GPU, or in a shader of some sort, so I would like to request some more help if possible. I can happily do most things that I want in shaders so far, but I do not know how to do this. I want to be able to send a pair of textures to a shader, run a few calculations on one of them, based on the data from both, and then output/save the updated texture.

What techniques should I take a look at, and does anyone have a link to a nice tutorial or similar on how to begin processing a texture in a shader in this way? Oh and what is a "shader-based MRT"? Multiple Render Target?

Thanks again for any help offered!


EDIT:
After reading a bit more, I think I need to:
- Load my 2 textures and create 1 spare/empty
- Create a RenderToSurface interface
- Set the spare as the render target
- Setup shader to use the texs
- RTS->BeginScene(); RTS->EndScene();
- Render the normal scene using the "spare" tex
- Repeat, alternating the spare and one of the original textures as the render target

Hopefully that's vaguely right, if it is... or isn't, I'd appreciate any help on setting me straight. One of the main things I wanted to know abut that approach is - If I just call BeginScene() then EndScene() will the shader call, or do i need to run a draw() command, and if so what's the best way to get around this?


[Edited by - CukyDoh on October 2, 2007 3:08:54 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by CukyDoh
If I just call BeginScene() then EndScene() will the shader call, or do i need to run a draw() command, and if so what's the best way to get around this?


Shaders run on primitives. If you don't draw anything, shaders aren't executed. So yes, you have to draw something; in this case a quad covering the render target is what is typically done.

Share this post


Link to post
Share on other sites
Quote:
Original post by legalize
In this case a quad covering the render target is what is typically done.


Firstly, thanks for the continued help!

I've got a bit further with this and at the moment have a shader that just copies the texture rather than perform any calculations on it, just so I can test if it all works so far.

I followed the rough steps above, and created the interface, etc. I do have another problem now though, and as I'm still treading on new ground here was wondering if it's a common problem that I'm having, and what the usual/likely causes are.

My texture is rendered/updated with a shader that just copies the existing pixel data. Then the texture is rendered normally to a quad so i can see the result. What happens is that my texture has a scrolling effect, as though i was increasing the uv-coords as time goes on. It seems to be getting the pixel data from 2 or 3 across from where it should be.

My guesses so far are that there is just some in-accuracy with how I'm rendering/updating my texture, such as the quad being slightly larger than the render target (both 256x256), or a filtering problem or something simlar maybe. The problem is that I don't know how to fix these issues as everything (to the degree I understand it at the moment) seems to be setup right.

As usual, I'm open to any suggestions offered!


UPDATE:

I played with my shader and found that it is exactly 0.5 pixels out.

tex0.x += 0.5f/TexWidth;
tex0.y += 0.5f/TexHeight;


I can easily fix this by adding something like the above to my shader, but obviously this isn't the best solution, so would appreciate any help still!

Share this post


Link to post
Share on other sites
Try rendering the quad from -0.5,-0.5 to width-0.5,height-0.5 - otherwise you'll get misaligned pixels vs texels and your texture will slowly crawl.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!