I do not get any errors and the program runs fine. Please let me know what might be the problem, because there seems to be no problem with allocating and storing the texture(which i am loading from a volume actually).
Do you allocate a LOCAL variable to hold your 3D texture, like so:
unsigned char image[512][512][256][3];
?
In this case, it is possible, that you just run out of memory. That´s similar to a stack-overflow with a recursion, that gets too deep.
This problem is easy to solve, by either
-making that variable global
or
-allocating it dynamically, via new
If you already do it dynamically, but get this error, you should check, if there is a restriction in your compiler-settings, which doesn´t allow to allocate that much memory (but i am not sure, if there are such restrictions on current compilers, at all; i only know that from Turbo Pascal 7.0).
thanks a lot for the reply. I am using dynamic allocation and the odd part is that just a few moments ago i tested the program with
only 512x512x256 not 512x512x256x4 (store only intensity instead of rgba) and it works without any errors.
its really strange because if the memory is being allocated correctly even for 512x512x256x4 why should glteximage3d have a problem?
thanks,
alark
i have a geforce fx 5600 which says it has 256 mb memory on the card. does that mean its enough or does some mem get used for other purposes like framebuffer etc?
-alark
Originally posted by alark: does that mean its enough
That means it’s all it has
So if you have a 256Mb 3D texture, you won’t have room for any display lists (for example). It’s almost certain you’re running into a memory limit if just the texture takes all the gfx card RAM
any suggestions about what i could do? i was thinking of splitting it into 2 textures of 512x512x256x3 and 512x512x256 but i dont think it will work since cumulatively i will still be sending the same amt of data to the gfx card. please let me know if u have any suggestions.
-alark
Originally posted by alark: any suggestions about what i could do?
You’re absolutely right to consider splitting it up. The “normal” method is to use 3D “bricks”. You create a smaller 3D texture that will fit in the card’s memory and render a different section of the texture each time. Once each texture has been rendered to the framebuffer, it’s not needed on the gfx card so it can be replaced with another section (from the PC’s RAM). This is obviously slower, and you need to be careful about the rendering order and also where the blocks overlap to prevent artifacts.
There’s some previous posts in this forum that will give you more info. Do a search for “volume rendering” or “3d texture” and you’ll see what I mean …
If the card can’t handle 256mb then it should keep the texture in RAM automatically, so that shouldn’t be the problem…
In the error message it says that you or the gl driver or both are allocating 3.75gb of mem, so that has to be the problem being the 2gb the limit for most win32 apps (in other OS’s I don’t know, but it’s pretty close to the 4gig barrier anyway). At least that’s what I can understand from it.
Maybe the driver is allocating temp memory that breaks the limit, who knows… Breaking up the texture might help in this case…
Consider buying an Opteron or an Athlon64 when it comes out .
Originally posted by alark: as i mentioned in the first mail, its for volume rendering wherein a volume is loaded into a 3d texture.
thanks,
alark
instead of using an RGBA texture, you could use an indexed texture. That would reduce your volume-size by 4(8-bit indices) or 2(16-bit indices). Load the look-up-table as a dependent 2D texture (e.g. 256x1 for 8-bit indices). The main advantage is you could efficiently change the volume’s appearance by just changing the LUT.
.