Page 2 of 2

Re: Regarding displacement and high polycount

Posted: Thu Mar 11, 2010 9:22 pm
by radiance
Sam wrote:What about using Normal maps ?
I know that they are for real time engine.
But I think, since they usually have 32bit of information, that they can be used like an improved bump ?

Can the renderer use that info to change rays ?
Its better than having no displacement and only bump.
normal maps are indeed better than bump maps, but they don't give silhoutte, self shadowing and true displaced geometry in a raytracer...

Radiance

Re: Regarding displacement and high polycount

Posted: Thu Mar 11, 2010 9:54 pm
by Chris
What about Steep parallax mapping?

And Hardware tesselation that works with gfxcards with Directx 11 api, i see they have it in Mach Studio Pro, but after all it is a scanline renderer. Is it possible to do in a unbiased engine?

Cheers

Re: Regarding displacement and high polycount

Posted: Thu Mar 11, 2010 10:02 pm
by radiance
Chris wrote:What about Steep parallax mapping?

And Hardware tesselation that works with gfxcards with Directx 11 api, i see they have it in Mach Studio Pro, but after all it is a scanline renderer. Is it possible to do in a unbiased engine?

Cheers
No, parallax mapping is a z-buffer technique.
hardware tesselation is only useable if it's exposed to cuda, which it is'nt yet,
and i'm not %100 sure it will ever be available in cuda,
nor if it will be useable in a raytracer...

we'll have to wait and see what nvidia does.

Radiance

Re: Regarding displacement and high polycount

Posted: Fri Mar 12, 2010 3:26 am
by MDkai
I think some "ideas" about the workflow are different when working on GPU based applications.

The main idea of displacement referres to an overall low memoryprint when working with the actually scene, while add detail for the process of rendering since it will eat up your performance anyway.
However if the memory needs 100 meg for 1 mil polys, that already is quite a lot to put the detail where you need it. Sure its easy to populate the scene with too much polys like using archviz stuff (trees, grass or plants), but this is a rendering app and not a sculpting software that needs a quick response on deformations.
I always need to work with what the software is capable of and fortunatly that is waaaaay beyond the conditions like 10 years before ("oh look, it got light support in openGL..". So instead of using the normalmap i made in zbrush, i simply throw in the highres model itself, can't get better than this !

So the question is, do i need a support for displacement when im capable of loading +10 mil polygons (without instancing) ? Sure its neat, as you don't need a software to create the 10 mil mesh, as well as a format that is capable of storing it easily. But i think technically you will have the exact same memoryprint on the gpu when you want to render the displacement on a poly base (again without the use of fancy instancing tricks) or load the mesh as is.
Correct me if im wrong.

Hardware tesselation may improve the scene dynamically if i move around my camera, but on the other hand i plan shots mostly before actually rendering it, so there is already some optimization.
Don't get me wrong, i like to have optional choices, but working with what you have is the way you need to work more often than you wish for ;) Besides a limitation can also be inspiring !
Just my two cents for the night :roll:

Re: Regarding displacement and high polycount

Posted: Fri Mar 12, 2010 9:20 am
by n1k
That's exactly what I thought when started importing HI poly sculpted meshes into octane. Things will be even better when multiple obj files can be rendered in the same scene. I believe that main problem is with animated geometry. You can't do rigging and animation with such high poly meshes.

Re: Regarding displacement and high polycount

Posted: Fri Mar 12, 2010 12:28 pm
by MDkai
Jeah instancing will give significant performance burst while keeping a low memprofile. And for animation, rig department would stab you ;)
However since animation in octane is currently more far away (?), i think by the time it will be implemented, displacement may follow as well.

Even if not, it would still produces great quality with great speed, more you can ask for ^^