linvanchene wrote:Is the geometry loaded completly in the VRAM?
yes.
linvanchene wrote:Or are there mixed solutions possible where the geometry is loaded from the RAM?
in theory yes; cuda can use shared system ram. in practice this would mean, octane would render about a factor N+ slower, since the memory bandwith between gpu and system ram is about a factor N slower than the bandwith between gpu and vram. where N is a number from 10 to much higher; so i doubt we will see this anytime soon.
linvanchene wrote:For octane for ds:
Are the geometry and textures actually loaded twice in the octane plugin for DS?
One time in the CPU for the DS viewport and one time in the VRAM for the octane Plugin?
no. thew viewport is just the rendered image grabbed from vram. the plugin stores nothing except plain node parameter data (no textures, no geometry). the only thing it needs to take from system ram is the amount of bytes to display the rendered image in the viewport (x pixels * y pixels * 4 in bytes - read below about the vram need of rendered image).
linvanchene wrote:Basic question:
When using GPU based render engines is loading actual modeled geometry in some cases more memory efficient than loading a model with normal or bump maps?
afaik no. fore a given area, storing additional triangles does always need more memory than storing height information by using a grayscale color map.
linvanchene wrote:Can someone point me in the direction of a forum thread / webpage where VRAM and how its size is calculated is explained?
don't know one; it is easy to tell for textures:
- a grayscale image needs x pixels * y pixels in bytes
- a color image needs x pixels * y pixels * 4 in bytes
note: the plugin/octane only uses a texture map once per type; if you use the same image in 10 slots while maintaining the same type (floatimage vs. image) it'll need vram only once. if you mix types, octane will need vram once per type. the way how octane finds out about multiple uses of the same texture map by the way is the path on disk; using the very same image map from different locations will also require more vram.
in addition the render film (aka output image) - as long as stored in vram...
- needs x pixels * y pixels * 20 in bytes
(this is because the render film holds not only 4 bytes of color data, but additional data need to calculate tonemapping, post processing, ...)
you can neglect node parameter data; this ranges in kilobytes.
the geometry itself would need to be counted; and the plain number of triangles don't exactly result in the vram size needed, since octane does something called voxelizing, where at least i don't know a formula to calculate the real need. hopefully we see some additional stats from the octane plugin version anytime soon, so it would be possible to at least show those numbers when voxelizing is done.
if you like to do some research yourself, you may use the standalone - there you will get all those numbers, including geometry data ram usage...
and the same might apply to this request - creating normal maps on the fly would be a possibility for future versions (you will still have the limitation, that you can't use bump + normal within the same material node), but hopefully octane is faster in supporting them directly 