why was the nv_evaluators extension discontinued in NVIDIA's detonator 40 driver?

Hello,

Anyone knows why the nv_evaluators OpenGL extension was discontinued in the new NVIDIA detonator 40 drivers?

Without it, the Bumpy Shiny Patch Demo that is inlcuded with NVSDK won’t run…

Was it replaced by an alternative extension?

I’m not from NVidia, but I’ve used NV_evaluators and there were some performance issues. My implementation was actually faster (but not as flexible, as I didn’t support decimal tesselation).

I hope hardware HOS will show up again soon ! (maybe in a EXT_ extension, this time? )

Julien.

I’d be very interested in a GL_ARB_displacement_mapping. But I guess we’ll have to wait another hardware generation for that

>>Was it replaced by an alternative extension<<

dont think so, one of the nvidia guys posted here a while ago (search) along the lines that they were gonna drop it, + was anyone using it.
IIRC its only done in hardware gf3+

along the lines that they were gonna drop it, + was anyone using it.

On the other hand, why would anyone use it if they were going to drop it ? :slight_smile:

But i agree, if that extension is faster in software than in hardware it’s just useless…

Y.

Again that HW / SW thing.
I think, if an extension produces fast enough results, it doesn´t matter, if it´s HW accelerated or not .

Diapolo

Originally posted by Humus:
I’d be very interested in a GL_ARB_displacement_mapping. But I guess we’ll have to wait another hardware generation for that

It sort of already exists, through ARB_v_p and ARB_f_p. I think that standardized programmability will lead to fewer “feature extensions” (but hopefully to more papers )…

Julien.

We believed that, as implemented, the extension offered little or no value to developers.

  • Matt

Originally posted by deepmind:
[b] It sort of already exists, through ARB_v_p and ARB_f_p. I think that standardized programmability will lead to fewer “feature extensions” (but hopefully to more papers )…

Julien.[/b]

Well, I’m not interested in any kind of presampled DM wannabe. To be useful we need dynamic tesselation with LOD, ala the Matrox way. Matrox have no plans to support displacement mapping in OpenGL so that means we’ll have to wait at least until NV35/R350 comes around or possibly NV40/R400 before we see this kind of functionality exposed in OpenGL.

i think they dropped thie support for their HOS because
a. their interface was very poor designed (for simple implementations) therefore
b. no one used it
c. ATI came up with something much better