OTOY Forums

Hi,

what is the maximum texture size and polygon count supported by octane renderer ?
I have digital terrain models (DTMs) with about 2 Billion triangles (around 10 GB memory model size)

Currently I render those models with my own self written ray-caster that makes heavy use of LOD techniques and a large CPU memory (12 GB RAM) in order to be able to render such large models.

Now it would be very interesting to use an GPU-based renderere like octane instead of the CPU based one.

However, my question is: Am I limited with octane to the GPU's memory (i.e. "only" 1-2 GB) or does octane implement some kind of streaming/GPU-caching/LOD mechanisms in order to support such very large models ?

Thanks & Regards,
ZX81

P.S.: what about the new "Fermi"-cards with 6GB+ GPGPU-RAM ? Would octane support those cards to make full use of the 6GB ?

Hi,

As octane is an unbiased ray tracer it needs to be able to find every triangle at once while rendering the scene, so the whole model needs to be loaded into the gnu memory at this time.

PCI bus speed and lag is too slow to use main system memory.

The latest 6gb frame based tesla boards will allow a large polycount, but billions is definitely not possible.
I think, depending on your type of models that 10 to 30 million is the maximum with 4 to 6 gb of video memory at this time.

Radiance

so the whole model needs to be loaded into the gnu memory at this time.

ok, I see. thanks for the clarifying answer !

I think, depending on your type of models that 10 to 30 million is the maximum with 4 to 6 gb of video memory at this time.

I think I don't quite understand those numbers. I would have thought that at least 100 million should be possible with 4GB GPU memory.
Does octane actually use around 300 bytes per model point ?
I thought something like 30 bytes (i.e. a dozen or so floats for vertex coordinates and surface color descriptor) would suffice...

Thanks & Regards,
ZX-81

P.S.: I have invested much time in writing optimized CPU-based renderes but have now reached a "critical point" at which I think that the future definitely belongs to the GPGPU approach ...
My current "2-gigapolygons engine" already utilizes any available CPU cores (easily loads all 24 cores in a dual Xeon hyperthreaded Hexacore workstation) but the render times for *really* large models (i.e. Gigapolygon-models), while acceptable for still images, are still unsatisfactory for animations.

A rough calculation of the raw rendering powers show that a modern GPGPU hardware should outperform
the fastest available CPU-based hardware (like a 2x6 core MacPro) by about a factor of ten ... and at a factor of ten less the cost

ZX81 wrote:

so the whole model needs to be loaded into the gnu memory at this time.

ok, I see. thanks for the clarifying answer !

I think, depending on your type of models that 10 to 30 million is the maximum with 4 to 6 gb of video memory at this time.

I think I don't quite understand those numbers. I would have thought that at least 100 million should be possible with 4GB GPU memory.
Does octane actually use around 300 bytes per model point ?
I thought something like 30 bytes (i.e. a dozen or so floats for vertex coordinates and surface color descriptor) would suffice...

Thanks & Regards,
ZX-81

P.S.: I have invested much time in writing optimized CPU-based renderes but have now reached a "critical point" at which I think that the future definitely belongs to the GPGPU approach ...
My current "2-gigapolygons engine" already utilizes any available CPU cores (easily loads all 24 cores in a dual Xeon hyperthreaded Hexacore workstation) but the render times for *really* large models (i.e. Gigapolygon-models), while acceptable for still images, are still unsatisfactory for animations.

A rough calculation of the raw rendering powers show that a modern GPGPU hardware should outperform
the fastest available CPU-based hardware (like a 2x6 core MacPro) by about a factor of ten ... and at a factor of ten less the cost

Hi, I was talking about practical scenes, including triangles, acceleration structures, vertex normals for smoothing, material data, textures, etc...
Unfortunately we cannot disclose technical information about the engine's internal beyond that, for commercial reasons (we have to pay our rent too! ...

Eg, I can see customers working comfortably for various industries with datasets up to 20M polies (depending on the type of model) on a 4-6GB tesla card, not billions.

Yours,
Radiance

Hey,

in relation to this topic, is there some sort of efficient instancing planned for Octane render? I often work with scenes where I want poly environment like a forest for backgrounds, specially for large scale scenes for arch viz like a tourist settlement or somesuch, you get the picture, so poly and object count can get pretty high.


Do you believe such scenes will be eventually possible with octane, or any other gpu unbiased renderer, anyway?

Instancing is planned yes.

Chris

Hey,

Instancing is planned soon, it's not hard at all to implement in octane, it's on our short term list...

Radiance

radiance wrote:Instancing is planned soon

good to hear that

radiance wrote:Hey,

Instancing is planned soon, it's not hard at all to implement in octane, it's on our short term list...

Radiance

Off hearing this its a relieve... I mean, being in a short term list...

What is Instancing? Is it something like vray proxy?