getBitmap Cannot access GFXDefaultStaticDiffuseProfile ... help?

#1 Hi Steven,

getBitmap () only works if there actually exists a bitmap. In most cases you delete the bitmap after you've uploaded it into a texture.

If you still want to access the data in the bitmap, lock the texture, and then you can access the pBits member in GFXLockedRect. Sometimes there can be depth information in the bits you retrieve, and you have to account for that and skip it if you don't want it.

This method isn't fast as data is sent from VRAM to RAM, but if you don't already have the bitmap in memory, it's the only way.

#2 Stefan, Thanks for the reply.

This is in a procedural texture-generation function where the old texture gets updated over time. Would it be better to store the bitmap in a class variable, update it each time and rebind it to the TextureHandle?

This would mean storing duplicate copies of the texture in RAM and VRAM .. but eliminate data transfers VRAM->RAM. Interesting trade off.

I'll try both approaches and report back.

As an aside:
- is transfer of data VRAM -> RAM slower than RAM -> VRAM?
- I thought the point of a "TextureHandle" was so that I could keep track of and interact with a texture. Not exactly?

Thanks!

#3

Quote:
Would it be better to store the bitmap in a class variable, update it each time and rebind it to the TextureHandle?

This would equal an upload of the new bitmap to the texture, which is on the card. You can specify if you want to delete the bitmap in system RAM after doing this, or if it's kept so you can reference it.

Quote:
- is transfer of data VRAM -> RAM slower than RAM -> VRAM?

No idea, sorry. I would guess RAM -> VRAM, but got nothing to back that up with. On the other hand, RAM -> VRAM has more uses and has always existed, so it might be more developed.

Quote:
- I thought the point of a "TextureHandle" was so that I could keep track of and interact with a texture.

Well, the texture has to exist on your GPU as well or you can't render it. As soon as you change the texture on CPU, it has to upload the changes to the card. Doing this requires the data to travel across the bus, and that's slow.

What are you trying to accomplish here? There might be a more simple approach.

#4

Quote:What are you trying to accomplish here? There might be a more simple approach.

Short Answer: It worked great in TGE. I want it to work in TGEA.

Long Answer: This is a procedurally generated (cloud) texture, where the clouds billow-and-change over time. I haven't looked at the generation algorithm in a while but I believe the previous texture is used as input to the algorithm to generate a revised texture.

At any rate I tried removing the 'getBitmap()' so it would have no knowledge of a previous texture on each cycle. I got a cloudy field with flashing blue squares.

I would rather get a clean port of the openGL ==> GFX code so I can make an apples-to-apples comparison. If I try to change a good algorithm to fix a broken rendering routine (as in the previous paragraph) then I have no idea which one is broken anymore.

#5 I changed local-var 'bitmap' to be a persistent class-member. Rather than trying to fetch the texture out of VRAM on each iteration, modify it and send it back - I keep a copy in RAM, update it, and send it one-way to VRAM each time.. This works and the entire class seems to be functioning correctly now. Thanks for your help! =)

Quote:In most cases you delete the bitmap after you've uploaded it into a texture.

GFXTexHandle myTex( bitmap, &GFXDefaultStaticDiffuseProfile, false, mTexName);

I thought the 'false' in this line of code (from original post) prevented it from deleting the texture. "bool deleteBmp"... I still don't fully understand, once I've assigned an image to a textureHandle why can't I get the image back out of the texture handle. If it is to be rendered it must still be there, correct?

#6 Setting that to false _should_ prevent the GBitmap from being deleted. Obviously, if you only allocate the bitmap in stack memory, it'll delete itself when you run out of the functions scope, though.

I'm not sure if changing the profile to something else would help, too.

Quote:
If it is to be rendered it must still be there, correct?

Like I said before, it's on your GPU. There's a bus between CPU and GPU, and it takes time for data to travel in between. If you want to open a TextureHandle and access the data it contains (ie, transfering) you can lock it, or access the bitmap it was made with - if it's still around. The former method is slow, the latter one is faster but obviously takes more memory to support.

If you're doing procedural cloud generation, that would be a perfect fit for a shader. You should avoid locking textures as it eats framerate, and updating any non-tiny bitmap takes tons of time if you're doing it per frame on the CPU. I did this recently with a 512x512 bitmap, and the for loop took like what, 30% of the time spent? Ouch. Just saying :)

#7 Stefan, thanks helping me understand this better! :)

#8 No problem! This forum needs more questions like these asked, so keep it coming. =)

#9 I've tried Steven's first method, but getBitmap crashes (the texture ptr is valid though). The GFXLockedRect method also crashes on subsequent unlock call. So, basically nothing works and there is a dearth of documentation on GFX. Could you post the code that you got working?