I don't think that's very likely
What did you mean by "that'? I'm not sure which idea you're objecting to.

As the renderer works on each pixel, it determines which objects must be queried for a color, and exactly what the position is in UV space, in 3D space, the Normal of the surface, etc. It sets all these variables up, U, V, P(x,y,z), N(x,y,z), etc. It then calls the shader. The shader is then interpreted with those parameters and returns a color. This is performed over and over again. As each color is returned from the shader, the renderer stores that in an accumulation buffer. The size of this buffer grows in proportion to the size of the render and has nothing to do with the amount of data needed to perform the shading calculations.

The data needed to perform the calculation for each node produces one number or one color. Once that node feeds its info to the other nodes, it is no longer needed. I suppose there is space set aside for each intermediate result, but even with 100 nodes, that's going to be puny.

I'll grant you that each node in the shader that is currently being edited is occupying memory for its little preview, but those are discarded as soon as you selected a different prop and your not in the material room. I verified that with a shader of 131 nodes in memory, they increased Poser's memory use by about 4 megs. This makes sense since each is 100 by 100 by 3 bytes for RGB times 131 = 3,930,000 bytes. When I selected another object, the memory was released. This is not rendering memory - it is only needed while you're editing in the material room, for the previews under each node.

As you reposition a camera, the graphics engine would have to regenerate the entire bitmap
What bitmap are you talking about? The only bitmaps in memory during rendering are those referenced by ImageMap nodes and the render itself. The different perspective views of the various textures are generated point by point, not in response to camera position changes. There are no images that are prepared in advance because of the camera position.

Nor are there any pre-calculated bitmaps because of lighting. That is the whole point of a shader - it receives all the variables of light strengths, light positions, light directions, object position, surface normal direction, camera position and so on. Given all these numbers, it computes a color. Then it gets called for the next pixel, and the next, and the next. Each value returned from the shader is stored in the accumulated render.

The answer to how I come to know that is that:

1. I'm a professional programmer
2. I've written renderers before
3. I've read a lot about the REYES renderer, particularly the renderman shader (which Firefly is an example of)
4. Notwithstanding the other 3, I just tested it.

I loaded a one-sided square into a scene. I scaled it to just fill my preview. My render was was 653 by 653 pixels. I rendered the square with with my cloth shader that has 131 nodes in it. Memory at idle was just over 87 megs, as the render proceded it rose to 117 megs, an increase of 20 megs during the render.

I then saved the render and replaced the shader with an ImageMap containing the rendered cloth. After repeatedly selecting the ground and clicking "reload textures" i got it to unload the memory and return to the original 87 meg. I then rendered - memory rose to 119 megs, and increase of 2 megs. The raw bytes of an image that size in memory is 1.7 megs, plus you could expect a bit more for book keeping and image caching for interpolation. Thus the rendered image was identical, but there was an extra 2 megs of information in memory during the render.

I repeated this 10 times for both scenarios and got the same measurements every time.

Is that convincing?

---

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)