I managed to make a LIFO that stores Textures. I attach it here. But I actually need a LIFO and I don’t know how to build it.
For the LIFO I used a “Buffer” node. I’d figure that I could use a “Queue” node to implement the LIFO but it doesn’t work correctly. For some reason which I still didn’t understand it starts to be corrupted, which means, some of the inserts (randomly?) insert an empty (white) texture.
Making a FIFO for storing values was easy using node “SetSlice”. With Textures, the closest I can get to “SetSlice” is the “Buffer” capability of setting a texture in any given index. But since I don’t have shift capabilities in Buffer I still didn’f find a way to implement a FIFO.
Any clues on how a Texture FIFO can be implemented?
Well, joreg, I believe now is the moment you want to kill me. Actually I got the name wrong from the beginning. I managed to make a LIFO by using a buffer. I posted it in the first post of this thread. I just named it wrongly.
Joreg, I’m truly sorry that I made you waste your time building that patch for me :((
What I cannot make is a FIFO, since this involves shifting. And this shifting requires feedback. Or… of course… the Queue node, which has that nasty bug.
I just had this idea for a crazy workaround: I can save the textures as files, do a string FIFO with their filenames instead of the actual textures, and then load them. I’ll give it a try.
Again, everyone please forgive my mistake :(
(Note: I corrected all my posts so that this makes sense to future readers. Having read other people’s contributions, I realized I was the only one explicitly refering to FIFO and LIFO so everything still makes sense)
the white frames you mentioned could apear because your gpu runs out of texturememory. try to lower the texturespreadcount or use a lower resolution for your textures.
if you really want to repatch the queue texture node, you could do it with an attached getslice (node) to the texture buffer node. then shif the indices of getslice. but i think this needs much more performance that the queue (texture) node ?!
Yes, I agree and I would do that. But in order to do that I believe need a closed loop (feedback), which is usually accomplished by using FrameDelay. But FrameDelay doesn’t work with textures and I don’t know how to do it.
Regarding the white frames: You could create a renderer (tty) and see if it throws error messages when a white frame is stored. I think it´ll say something like “Zugriffsverletzung”/“access violation”
@nfg
framedelay with textures: use a Queue (EX9.Texture) set to one frame.
@ele
“repatch the queue texture node, you could do it with an attached getslice (node) to the texture buffer node. then shif the indices of getslice. but i think this needs much more performance that the queue (texture) node ?!”
no. shouldn’t make a difference performancewise.
I wouldn’t have thought of that. So, the trick is to add the renderer in the middle. Cool!!! I had only tried:
Buffer -> IOBox(Node) -> Queue -> Buffer
But… won’t a extra renderer waste some CPU cycles? I believe it wouldn’t be a real problem in this case, but I’m curious to know. After all it’s rendering stuff. Does it make a difference if I use alt-3 to make it into a normal node?
of course the extra renderer costs. and of course hiding its window with alt+3 reduces that cost. still the dx9texture connected to the renderer has to be rendered.
The “quad->renderer->dx9texture->queue->loop to quad” patch doesn’t solve it because it converts the Texture spread into a single spread, while I need to feedback the whole original spread in order to edit it.
Anyway, Queue should do it. That’s why it exists and I guess I’m wasting my time trying to invent the wheel.
I followed bjoern advise and added a TTY Renderer and I did get errors. My textures are really small so I’m not running out of memory for sure. I believe I ran into a bug in Queue which I will report now in the Bug forum. Here’s the link:
Well, joreg, I believe now is the moment you want to kill me. Actually I got the name wrong from the beginning. I managed to make a LIFO by using a buffer. I posted it in the first post of this thread. I just named it wrongly.
Joreg, I’m truly sorry that I made you waste your time building that patch for me :((
What I cannot make is a FIFO, since this involves shifting. And this shifting requires feedback. Or… of course… the Queue node, which has that nasty bug.
I just had this idea for a crazy workaround: I can save the textures as files, do a string FIFO with their filenames instead of the actual textures, and then load them. I’ll give it a try.
Again, everyone please forgive my mistake :(
(Note: I corrected all my posts so that this makes sense to future readers. Having read other people’s contributions, I realized I was the only one explicitly refering to FIFO and LIFO so everything still makes sense)
