If I understand the rules correctly the whole scene has to be built between the WorldBegin/WorldEnd blocks. If I have multiple frames, I can have all of them in one rib file if I want. But after every FrameEnd, the whole graphics state and memory is cleaned. Is that correct?
In the mentalray mi - files there exists the possibility to modify an existing scene incrementally. Of course the whole thing works a bit different, but for large scenes this could save a lot of diskspace and time if I only have to update my camera instead of the whole scene.
So my question is: Is something like this possible in rib? Or is is as I said, that all informations are deleted after a FrameEnd block?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To save disk space you can factor out common rib code into archives, then use RiReadArchive (or RiProcedural) to pull them in at render time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-06-26
Also don't forget to use retained geometry for large number of the same object for instancing. In RenderMan this is done by wrapping the geometry in RiObjectBegin/RiObjectEnd and calling it with RiObjectInstance ;)
Eric Back (WHiTeRaBBiT)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks a lot. Can you tell me what is the difference of RiObjectBegin/End with RiObjectInstance and using an inline archive with ArchiveBegin/End and referencing later this archive?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-06-26
This is how I understand it…
ReadArchive loads everywhere its used
DelayedReadArchive only loads when the bounds are within view
In both cases each call to ReadArchve loads a new object in memory even if they are referencing the same file (this may vary from renderer to renderer but officially this is how it should work).
ObjectBegin/End loads the object in memory only once and can be referenced multiple times with ObjectInstance making it perfect for instancing. Here's a fast simple example of ObjectInstance for instancing…
Not at all. This is completely different. Objects can only contain a subset of the Ri calls. Namely call which are context free. This is basically geometric primitives & transformations (in object space).
Anything else is subject the interpretation within the current attribute state. A RIB archive (or an in line archive) potentially contains information that must be interpreted in the current attribute context or even the current global context. There could be references to light handles, environment variables, RIB conditionals etc. in there. In renderers like PRMan & 3Delight you can add co-shader handles and resources to that list even.
This is why any archive must be 'played back' immediately and cannot be expanded lazily, like objects.
That is also why the designers of the original RMan spec made this distinction with the resp. constraints for objects.
That being said, the file reading will likely be cached in RAM by the operating system in the example you gave. But as far as the renderer is concerned, this is re-loaded, re-read (and potentially re-tessellated, if visible/hit by rays) just as if it was a different piece of geometry.
RIB (inline) archives must there be treated like normal Ri stream. Object instances, on the other hand, can share data. Depending on implementation this can be just the bounding box, the whole geometry definition or even tessellation and cached parts of the shading that are attribute stack independent.
-Moritz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I understand the rules correctly the whole scene has to be built between the WorldBegin/WorldEnd blocks. If I have multiple frames, I can have all of them in one rib file if I want. But after every FrameEnd, the whole graphics state and memory is cleaned. Is that correct?
In the mentalray mi - files there exists the possibility to modify an existing scene incrementally. Of course the whole thing works a bit different, but for large scenes this could save a lot of diskspace and time if I only have to update my camera instead of the whole scene.
So my question is: Is something like this possible in rib? Or is is as I said, that all informations are deleted after a FrameEnd block?
To save disk space you can factor out common rib code into archives, then use RiReadArchive (or RiProcedural) to pull them in at render time.
Also don't forget to use retained geometry for large number of the same object for instancing. In RenderMan this is done by wrapping the geometry in RiObjectBegin/RiObjectEnd and calling it with RiObjectInstance ;)
Eric Back (WHiTeRaBBiT)
Thanks a lot. Can you tell me what is the difference of RiObjectBegin/End with RiObjectInstance and using an inline archive with ArchiveBegin/End and referencing later this archive?
This is how I understand it…
ReadArchive loads everywhere its used
DelayedReadArchive only loads when the bounds are within view
In both cases each call to ReadArchve loads a new object in memory even if they are referencing the same file (this may vary from renderer to renderer but officially this is how it should work).
ObjectBegin/End loads the object in memory only once and can be referenced multiple times with ObjectInstance making it perfect for instancing. Here's a fast simple example of ObjectInstance for instancing…
Display "0001.tif" "framebuffer" "rgb"
Format 800 800 1
Translate 0 0 1
ObjectBegin 0
Sphere 0.25 -1 1 360
ObjectEnd
FrameBegin 1
WorldBegin
TransformBegin
Translate 0 0 0
ObjectInstance 0
TransformEnd
TransformBegin
Translate 1 0 0
ObjectInstance 0
TransformEnd
TransformBegin
Translate 1 1 0
ObjectInstance 0
TransformEnd
TransformBegin
Translate 0 1 0
ObjectInstance 0
TransformEnd
TransformBegin
Translate -1 0 0
ObjectInstance 0
TransformEnd
TransformBegin
Translate -1 -1 0
ObjectInstance 0
TransformEnd
TransformBegin
Translate 0 -1 0
ObjectInstance 0
TransformEnd
TransformBegin
Translate 1 -1 0
ObjectInstance 0
TransformEnd
TransformBegin
Translate -1 1 0
ObjectInstance 0
TransformEnd
WorldEnd
FrameEnd
Eric Back (WHiTeRaBBiT)
Okay, but should:
ArchiveBegin "myarchive"
Sphere 1 -1 1 360
ArchiveEnd
WorldBegin
TransformBegin
Translate 0 0 0
ReadArchive "myarchive"
TransformEnd
TransformBegin
Translate 1 0 0
ReadArchive "myarchive"
TransformEnd
…
WorldEnd
… do something very similiar? The archive is read once as soon as it is defined, and is reused later?
Not at all. This is completely different. Objects can only contain a subset of the Ri calls. Namely call which are context free. This is basically geometric primitives & transformations (in object space).
Anything else is subject the interpretation within the current attribute state. A RIB archive (or an in line archive) potentially contains information that must be interpreted in the current attribute context or even the current global context. There could be references to light handles, environment variables, RIB conditionals etc. in there. In renderers like PRMan & 3Delight you can add co-shader handles and resources to that list even.
This is why any archive must be 'played back' immediately and cannot be expanded lazily, like objects.
That is also why the designers of the original RMan spec made this distinction with the resp. constraints for objects.
That being said, the file reading will likely be cached in RAM by the operating system in the example you gave. But as far as the renderer is concerned, this is re-loaded, re-read (and potentially re-tessellated, if visible/hit by rays) just as if it was a different piece of geometry.
RIB (inline) archives must there be treated like normal Ri stream. Object instances, on the other hand, can share data. Depending on implementation this can be just the bounding box, the whole geometry definition or even tessellation and cached parts of the shading that are attribute stack independent.
-Moritz
Thanks moritz, this is good to know.