[Peder]

The way it has been told to me is that instancing is of no use at render time. At rendertime all instances, symbols etc. Are exploded and take up the same amount of memory as noninstanced objects. The value -as I understand it - is when editing these instances and perhaps also when refreshing the screen in simpler viewing modes. It also makes the file size smaller on the HD.

Pls correct me if I am mistaken...

Here is a quote from the FZ support guys:
-- Symbols DO NOT save Memory. Not in formZ, and not in ANY program. They may reduce the size of your file itself, but it will still require the same amount of memory to render the file regardless of whether or not the objects are symbols. (Symbols are actually exploded "internally" during the rendering process.) Symbols are primarily a convenient way to work with repetitive objects, allowing multiple objects to be edited and updated quickly, as well as allowing one symbol to be quickly changed into another one.

Peder

[michaelplogue]

C'mon guys! We don't even have a functional z-depth, volume fog, SSS, camera motion blur, displacement, you-name-it functions yet (the list goes on....), and you want instancing already?? Do you honestly think there's any chance of that happening anytime in the near future?

And I believe that Peder is correct. Instancing will only keep your scene files small. When the scene is actually being rendered, it has to 'load' all of the polys for the instanced geometry . So, in the case of Maxwell, your MXS is still going to be large, instancing or not.

[zoppo]

The way it has been told to me is that instancing is of no use at render time ...
Peder

That is what i thought how it works, too. But then - how can they possibly render a scene with BILLIONS of polygons?!

10000trees X 26400triangles= 264.000.000 triangles
15000cars X 788722triangles = 11.830.830.000 triangles

Even with the upcoming memory optimizations there is no way to do this in mw. And it it would be impossible for any other program if it really "exploded" all data at rendertime ...


Edit: right ...

We don't even have a functional z-depth, volume fog, SSS, camera motion blur, displacement, you-name-it functions yet (the list goes on....), and you want instancing already??

[JTB]

If Peder and michaelplogue are correct then it is not a very important, however would like to see an answer to zoppo

On the other hand, as michaelplogue mentioned, there are many useful features missing so instancing is not a top priority.

As I have said before, I am an engineer, not a CG artist so my main concern is to deliver my job well done to my clients, and respect the deadline. That's why I always speak about speed improvements, that's why I thought this can be a good thing to have.

[The Pixel Artist]

The way it has been told to me is that instancing is of no use at render time. At rendertime all instances, symbols etc. Are exploded and take up the same amount of memory as noninstanced objects. The value -as I understand it - is when editing these instances and perhaps also when refreshing the screen in simpler viewing modes. It also makes the file size smaller on the HD.

Pls correct me if I am mistaken...

Peder

If Peder and michaelplogue are correct then it is not a very important, however would like to see an answer to zoppo

Actually no, this is quite different from normal instancing, as it's "proxy object" based instancing. So this helps out tremendously at render-time as virtually none of this geometry is save in the scene file or in memory at render time (and why you can render billions of polys in a scene fairly easily). This works exactly like Vray and it's proxy objects (which I use continually for my work).

It works by referencing an object outside of the main scene file, for example, a high poly car or tree. Then you place low poly "proxy" versions of that object in your scene (for location). This could be a box or even a single poly (or a vector representation, as it vray) . You can copy this object thousands of times in your scene (or scatter it or maybe using a particle system). The beauty of this is that only the proxy stand-in object is saved in the scene file (not the original mesh) and only one copy of the high-res original is loaded into memory at render-time, then dynamically used in the core as needed.

For quick example, you need to copy 10,000 trees over your scene, the main tree mesh has a millions polys (plus materials/textures), but the proxy object representation of it in the scene is a single poly (or whatever). So that would be 10,000 polys saved in the scene file that represent the location of the 10,000,000,000 polys actually be dynamically loaded and "displayed" at render-time.

Proxy objects, along with displacements are my two most important tools in Vray. I use it for most of my vegetation setups (some good examples LINK1, LINK2, LINK3, LINK4). I simply couldn't live without them, and frankly, they're the two features that have kept me from moving to either Maxwell or Fry (well, until now at least). That said, Fry's version of proxy instancing seems to even go beyond Vray's implementation, as far as functionality, as you can use your own object and the option for dynamic color changing/shifting... very, very cool!

Anyhow, hope that makes sense.

[Maya69]

Wainting september for release !!!!!

[rivoli]

But then - how can they possibly render a scene with BILLIONS of polygons?!

proxies are not loaded at once in ram, rather they are dynamically loaded on the fly when needed. in this way you don't chock the system trying to have massive scenes loaded and stored in ram all at the same time.

[Hybaj]

Wainting september for release !!!!!

I think it'll be released in octember

[JTB]

@The Pixel Artist
Thank you very much for such a detailed answer, let's hope NL will add this very soon... It will be a great tool for everything!!!

[michaelplogue]

But for unbiased renderers, don't you have to have all of the polygons loaded for it to work properly?

[Fernando Tella]

Wainting september for release !!!!!

I think it'll be released in octember

Or even fourteenember.

[ricardo]

But for unbiased renderers, don't you have to have all of the polygons loaded for it to work properly?

Spot on. There is no free lunch.

This way every time a ray crosses the bounding box of an instance the high-res geometry has to be scaled/rotated/translated in place for the engine to check if it touches something. In maxwell it happens pretty often.

You are trading memory usage for tons of CPU cycles.

Ricardo

Edit: there is one intermediate approach, used by renderman, where you have a set of many resolution geometries that will be selected according to the distance of each instance to the camera.

This way you don't carry more polygons than you need and don't have to replace everything a million times.

[droid42]

This way every time a ray crosses the bounding box of an instance the high-res geometry has to be scaled/rotated/translated in place for the engine to check if it touches something. In maxwell it happens pretty often.

Instancing is actually much simpler than this. Instead of transforming the whole geometry of the duplicate object/shape, it's possible to transform the ray itself, which is a relatively cheap operation. e.g. the instanced duplicate is translated +5 units relative to the original ... the intersection test just needs to translate the ray -5 units and exactly the same effect is achieved as moving the whole object +5. The same applies to scaling and rotation. Great care is obviously required regarding the order in which the various transformations are applied. The tricky stuff comes with applying different materials to the instanced object (best achieved with some form of material mapping table).

Very cheap and very simple. POV-Ray has been doing that for well over a decade and I'm guessing that every other instancing implementation out there uses a similar approach (which is very well documented in even the most ancient of ray-tracing introductory texts). The same approach is essential for CSG operations on primitives.

The memory overhead for an instanced object is negligible ... probably around 50-100 bytes for the transformation matrix data. Per above, the CPU overhead is tiny (certainly a drop in the ocean compared to the effort involved in intersecting a ray with the whole scene).

Edit: there is one intermediate approach, used by renderman, where you have a set of many resolution geometries that will be selected according to the distance of each instance to the camera.

This way you don't carry more polygons than you need and don't have to replace everything a million times.

The Renderman approach is clever indeed (it's the Reyes algorithm ... "Render Everything You Ever Saw"). It basically works by considering a high-level primitive and tesselating it into the minimum number of micro-polygons required to render a smooth representation of it i(view-dependent). Very cunning but has little application for unbiased renderers IMHO.

Ian.

[michaelplogue]

This is very interesting stuff. I was thinking that the renderer would have to work similar to how a 3d app would work, but there are significant differences that I hadn't considered.

This got me thinking about how difficult this could be, depending on the scene and materials used - especially when you have to take into account reflective/refractive materials. I started imagining the paths that would have to be calculated for a large number of instanced chrome spheres under an HDRI sky.........

I got dizzy and threw up.........

[ricardo]

This is very interesting stuff. I was thinking that the renderer would have to work similar to how a 3d app would work, but there are significant differences that I hadn't considered.

This got me thinking about how difficult this could be, depending on the scene and materials used - especially when you have to take into account reflective/refractive materials. I started imagining the paths that would have to be calculated for a large number of instanced chrome spheres under an HDRI sky.........

I got dizzy and threw up.........

Add overlapping bounding boxes and it gets even better...

The software is right, we just need more CPU power and more RAM. And it wont take long.