Vertex Displacement Mapping Broken By Latest Drivers?

looks like with all the bug reports we sent them, they finally decided to take action.... in a very unpleasant manner though.

Annoying, isn't it... So it doesn't work on your system, either?

a|x

For those of us with ATI cards [I've just recently ordered a PCI ATI upgrade for my PPC G5, so I'll be joining the ranks of the vertex displacement mapping frustrates all too soon], I think its wait for the update to roll out.

Part of my idea is to have a fall back graphic card [the old nVidia default GeForce 5200 FX], not sure if I'll have to swap out the AGP nVidia to get display from the ATI, or if both can sit in situe concurrently.

I'll find out.

My two cents, either Apple updates ATI graphics before Snow Leopard, [June 2009 ?], Snow Leopard will contain the fix [what about 10.5.7 users], or the ATI fix will be the first Snow Leopard update.

According to my searches this is a problem that has been fixed driver wise elsewhere , for other OS, sometime ago now.

{I think I might roll back the ATI graphics driver for 10.5.7 and stick with the bundled river if that's an option.}

For me: it still works! \o/

At least, I opened one of my old displacement experiments, and I still see a nice, displaced surface. I'm on an ATI 2600 card, with 10.5.7. And I'm using my "image to generic rgb" plugin to prepare the texture.

It is running a bit slow though, I hope it's not running on the CPU. I'll test more.

Still works without the plugin, using a plasma generator as the source. Either they've disabled VS sampling on older cards, or you're doing it wrong. Can't see it being the latter.

It gets better! It works without the plugin! THEY FIXED IT*! \o/

*(selected video cards only, terms and conditions apply)

Quote:
It gets better! It works without the plugin! THEY FIXED IT*! \o/

*(selected video cards only, terms and conditions apply)

Bollocks.... That's very annoying. For me, of course, not you...

You were right above though: I may be doing it wrong. I just tried to sample the texture in the VS, and then pass the r channel to the FS as a varying, and output it as the fragment color. I get a black output when in hardwareGL mode, and the expected blurry version of the input texture when in softwareGL mode, so it looks to me like they've just disabled it entirely in the drivers for my card.

Glad it works for you, anyway..

a|x

Hmm.

Somebody send me a test file!!! heheh... it never seemed to work for me in the first place using the "workaround". I never got what I expected out of the setup... the thought of it is extremely cool though.

Actually.... it DOES work for me with the Plasma Image patch.... And with still images, so I was wrong. Should have done some more tests before shooting my mouth off....

Having said that, the old OpenCV trick definitely doesn't seem to work now. Could I try your color-converter plugin again psonice? I seem to have mislaid it. maybe you could post it here... (pretty please)

a|x

I've found a v.1.0 'Remove Colorspace' plugin, but it seems to crash QC now. Maybe you have a new version, psonice (fingers crossed).

a|x

Here's a displacement with the OpenCV trick (still works on an Intel GMA950)

If you follow the note, and bypass the opencv step, it crashes (instructions are in a note in the composition).

Still crashes for me (so Intel GMA950 behaviour is 100% unchanged)

I have had some reports of reliable kernel panics due to some texture treachery we were doing for one of our custom plugins (soon to be rolled into a GLTools release), and testing identically on 10.5.6 did not panic. Pretty quirky, if you ask me... (panic on both ATI and Nvidia, so it's something closer to Apple's side...)

[I made some handling changes to work around the panic, so the public version won't be bad ;)]

lol....

Does this look like a kineme3D plane with noise applied to you? Or are people getting more useful depth detection/displacement than me?

What is it that is supposed to cause less "depth"... lack of luminosity?

I pretty much always get the same depth all across the image. When I do a little duplicate chain with the color convert, and use something else as the displacement image than the diffuse, it doesn't really change anything either.

This doesn't give me the smoothness that I can at least figure out how to get with Vade's Rutt Etra (awesome plugin). It is like random vertex distortion.

Very odd...

I just tried your test QTZ, and it works! But if you bypass the OpenCV resize, it doesn't. Or, more specifically, the displacement image doesn't seem to be sampled in the VS. Maybe that's a 'powers of 2' issue with the texture dimensions?

In this case though, if I connect the Video Input directly to the Displacement Map input of the GLSL shader... boom.. crash, just like before. Which is odd, because I wasn't getting the crash with the simple shader I was testing earlier.

So... inconclusive. Maybe nothing actually has changed... I'm sure I don't remember having to resize the image before though- I used to just run in into the QC image > OpenCV Image patch, then straight into the OpenCV > QCImage patch, and it would work.

a|x

I think it's quite a low-res mesh that's being displaced. The principle is the same though. Vade used smoothing of the displacement image (with a blur), I think, and of course rendered the vertices as lots of lines, rather than a continuous mesh.

a|x

Just tried chris's glsl "crash", and can confirm that's it's 100% not crashing now!

I can connect the video directly to the GLSL shader, no crash, and I get displacement. Check the attached screenshot out - it even supports NPOT textures! (Oh, the inspector didn't capture. But the resize is set to 320x240.)

Preview	Attachment	Size
	displaceworks.jpeg	114.22 KB

No 1.1, but the plugin is here if you want to check you have the right version: http://kineme.net/Applications/Compositions/psonicescompositionsandstuff...

It still runs fine here - does the example comp in the zip work OK? If not, mail me a crash dump and I'll take a quick look. If it's something not obvious I've not really got time to investigate at the moment, but I can send you the source if you want to investigate.

i'm personnally on a Ge8600, and never did gfx update (nor 10.5.7... still on 6). I've got a couple shows running, so i'm getting paranoid at updating...

(but i did send them bug reports and feature requests when i was on 1600....)

EDIT: double checked. It is working here without any hack. apologies to all engineers.

Hiya,

thanks for that. The example in the .zip works fine for me. Then again, it's using a still image as the displacement-map, which has always worked for me without any colour-conversion (and still does). However, if I pass the iSight feed through the converter plugin (this version doesn't crash), it still doesn't work. It doesn't crash, either.

On the other hand, if I pass it through the chain QC Image to OpenCV Image > OpenCV Resize > OpenCV to QC Image it works, so there's something more to it than simply the colorspace issue.

Anyway, the fact they've fixed it for your machine means, hopefully, that fixes for other GPUs are on the way.

Do you think the shader is running on the GPU on your machine, psonice? The massive slowdown when I drop QC into softwareGL mode suggests to me that when it does work on my machine in hardwareGL mode, it is actually running on the Graphics-card, but I may be wrong. I know it's sometimes hard to know when software-rendering fallback is happening.

a|x

Cool, glad it's working for you! I've got a suspicion the X1600 has been problematic in a number of ways for Apple. There seem to be a few glitches I've hit in the past that seem to be specific to this GPU. I guess it's not really a priority any more, either, since it's quite old.

Unfortunately, I don't think I'll be investing in a replacement laptop anytime soon, much as I'd like to.

a|x

Oh, video input is the one thing the plugin doesn't support, as the video image isn't RGB :) Render the video in a render-in-image and pass the output of that into the plugin, that should work.

Remember that when you drop to software GL, it's doing ALL rendering in software (i.e. all the masses of drawing, not just the vertex shader!) so it's very hard to tell. Best way would be to write a really complex vertex shader and watch CPU usage I guess. I'm not seeing a whole lot of CPU being eaten by this, so I guess it's running on the GPU.

Well, I got all excited by this being fixed and made a pretty landscape thingy. This might only work on radeon 2600+ cards, but let us all know if it works on anything else. It needs the kineme texture plugin, so make sure you have that installed or you won't see much :)

Instructions: Fly around with the mouse, and mess about with the controls. Set the texture size lower to speed it up - unfortunately reducing the size also increases the size of the mountains (it's kind of a weird zoom..)

Question: I'm scrolling the height map (which results in flying around the mesh) using a bunch of billboards moving in a render in image. Which is crap and slow, I should use an affine transform patch and just translate the image. But the affine transform outputs a black image once I go past a certain size (1k x 1k works, 1k * 2k breaks). Anyone know why?

Preview	Attachment	Size
	landscape.jpeg	101.44 KB
	landscape.qtz	93.03 KB

Fixed version for older cards. Needs the image -> generic RGB plugin, which you'll find here: http://kineme.net/Applications/Compositions/psonicescompositionsandstuff...

Also added mesh resolution to this, turn that up + down and watch the CPU usage to see if it's running in software or hardware :)

Oh, and this composition is a completely horrible hacky mess, good luck figuring out what's what :D

psonice wrote:
It needs the kineme texture plugin, so make sure you have that installed or you won't see much :)

eek -- the currently-released leopard version of the texture plugin has a pretty severe memory leak when you animate textures through it (i.e. change some parameter, etc).

I've got a build that fixes this, but I've not gotten around to releasing it. If this bug bites anyone, let me know and I'll package up the update and make a proper release of it. (along with a much newer compiler, with the associated speed benefit of that).

No worries, I'm not animating any kineme textures (seeing as it takes around 20 seconds to generate a texture, that would be a really, really bad idea :D )

Which reminds me, these 2 compositions will lock QC up for quite a while when it loads. You'll get a beach ball, and nothing will happen. For ages. Just give it time, and blame it on cwright :D

Couldn't you just offset the coords for the texture-generator instead of moving billboards?

Ah, sorry. I'd forgotten how slow the texture plugins run.... Maybe you could roll your own Perlin Noise generator. I've been trying to get a CIFilter Perlin texture generator working for a while now, without success. Wasn't there one posted here a while back though?

EDIT Here http://kineme.net/Applications/Compositions/PerlinNoiseCIKernel in fact

a|x

I've made a little clip with a tiny tweak to Smokris' Perlin CIKernel, to allow the texture to be scrolled.

a|x

Hmm.. this kind of 10% fixes it. This perlin is too simple (1 octave or something), so the mountains end up very smooth and rounded. It does get around the scrolling issue, though. Other problems:

• the perlin is only half of the heigh map, we need turbulence too
• I think this method might mean that the perlin texture gets redrawn every frame, instead of just offset (the original version just scrolled a repeating texture)
• the perlin generator seems to fail at >1024 resolution :(

I've come up with an ideal solution, but not implemented it yet:

• Create the landscape as a one-off, repeating texture
• Generate the sea/wave texture per frame, like now
• Handle the scrolling inside the vertex + fragment shaders. It would just need the mountain texture sampling at the right offset and repeating, then combining with the water texture which is just a max + conditional.

That would remove a ton of unnecessary steps, and should be nice and fast. I still want to know why the affine transform patch produces black output at high res though :)

The perlin generator is very useful btw, even if it doesn't quite work out here. I'll keep hold of that for future use.

Texture translate guys. That's the quickest method of animating the texture (fps wise) with the texture plugin (translating in conjunction with CI is an interesting approach as well).

"quickest" in this case means 0.01 fps or so :D (using the kineme texture translate patch). If you meant the image transform patch, it doesn't tile the image.

Lol... I have to check this out, haven't had much time... I guess "in general" translate flies for me, as opposed to tweaking the actual texture generator, which creates more of a hit. That sounds extremely slow!!!

There is a really cool example somewhere that uses the translate and a scroller for some typography stuff, that is way efficient. After seeing that, it changed the way I approach the textures.