Height map advice

Run! Seriously... if it's for a job this is a rabbit hole you may want to know about prior.

That said, you could convert the data to a luminance texture... how many increments of resolution is what I think might be slightly awkward/challenging.

So, you could make a low res bit map and increase luminance of certain bits. If you want it to look "smooth" and make mountains or whatever, you'll need to filter the map somehow, but then the question becomes more of an aesthetic issue.

This may give you some food for thought:

http://developer.nvidia.com/node/19

Cool idea, the live nature of it. I'd be thinking of it in slightly different terms than George. I'd try getting a matching overlay of your data translated to grayscale. Then try kineme 3D -- it has a height field patch. Use the grayscale as the height field. You can use the height field patch as the 3D object and plug your photo image into the 3D Renderer "image" input. You can change exposure, gamma, blur, resolution, etc. on the grayscale "data" image.

I think this isn't hard at all actually. There's two parts to it:

1. Making the data representation. Easy enough. Use a render in image, with an iterator in it. Each iteration will render 1 person.

All you need here is a black background, and a sprite to represent the person (sprite position comes from their location on the map). The sprite should be a gaussian gradient texture (or similar), with additive blend, and maybe 25% opacity. This way each person is a 'bump' on the texture, and several people in the same area will have an additive effect for a taller bump.

1. Making the visualisation. What you need here is a GLSL shader, with a GLSL mesh inside (give it plenty of points for a higher quality mesh).

All you need inside it is a straight texture in the fragment shader (which is already written in the default shader :). In the vertex shader, you also need a texture - you read in your height map here. Then offset the vertex Z position by the texture value, this creates your bump.

If you want lighting + shadows like in your example pic, you'll need a bit more work in the shader. And you'll need very basic GLSL knowledge to do it, although it's pretty simple without lighting and the default shader basically shows you 90% of what you need to do.

Give me a shout if you need any help with it.

GLSL -- also a super cool idea!

That's what I was trying to relate when I'm talking about making a bitmap of the data and using that to influence the height, and then blurring or whatever. We're just using different terms to say the same thing.

I'm not trying to relate that it's strictly a hard thing to do, only that if it's a visualization of large amounts of people, or it has to very precisely represent people in "height levels", it may get kind of pricey. A lot of it hinges on the quality of heightmap needed. It could get untenable quickly.

There are a bunch of heightfield shader examples knocking around, and CL examples as well.

It doesn't need to be expensive at all. The only expensive parts in the method I suggested there are the iterator (which will probably handle 100+ people anyway, and could be avoided with a fairly simple plugin) and the shader (which is pretty trivial for even a moderate GPU at high quality).

If you think about what it's doing, it really isn't much. Drawing sprites, with additive blending, mostly. Fairly small sprites. A decent GPU would handle 10,000+ people, I'm sure, it's just fillrate limited and it's not drawing many pixels.

If you wanted a huge map that can be zoomed in etc., you just use different detail levels, so you have a few sets of map images. Then you can zoom in and out of the map with good quality, and only render the number of pixels on the screen. The height map resolution wouldn't change, you'd just draw the sprites smaller (making it faster!). And the mesh doesn't change resolution ever, so there's no performance impact there.

I think we agree here, but maybe I'm looking at the cup as half empty. (How sunny of me.)

I think doing 10,000 iterations, plus the heightfield is edging up there, but the machine one is going to run it with is going to also make a difference. I think the theoretical "iteration avoiding" plugin will likely be necessary, depending on count. I know that's exactly the way I've handled avoiding the iterator; by making a patch that generates positions and another objects.

The glsl grid does have that vert limit - and there are issues with it popping offscreen, as you know. Then, cl support on some machines is pretty horrible. It's one of those things that can turn from simple to very hard, depending on count. I agree with your point about the setup being simplistic conceptually. If one just went into it blindly, depending on the context, it could get more complex.

I would be particularly sure to try to avoid ati machines if cl is used for the heightfield....The cl heightfield is much faster than other methods when the drivers support cl and gl texture. If not, it's very sub-par.

When I said "run" I was being a bit hyperbolic, but with these caveats in my mind.

You could probably handle this at full speed on a netbook. It's only the QC iterator that slows it down ;)

I've actually done stuff very similar to this before, on an older box (with radeon 2600). Speed was good - and I even had a setup with an iterator drawing lots of sprites with additive blur to make the height map (not for a situation like this though). The glsl grid at 256x256 is likely enough, because you don't need fine detail. And you're not moving the vertices far, so the 'disappearing' bug isn't a problem at all.

Oh, one more suggestion: The people presumably don't move fast. That means you don't need high framerate for the height map update, just for the actual 3d view (assuming it's interactive or animated). You could have a separate comp drawing the hightmap (with say 1m people, updated every 10 seconds) and passing the image to the rendering comp.

And before I forget: with additive blending and large numbers of people, you'll want more accuracy. I found 16bit colour was enough, but that's only supported on ATI i think, so go for 32 if it's an issue.

Interesting thought on dividing the load like that... Yeah, if people don't update too often that could be an ideal route. Good call.

Also add "potentially crappy drivers" to possible issues besides the iterator.

Considering that the 'render' comp would be gpu-loaded, and the 'height-map generator' would be cpu-loaded (because of the iterator) you could probably run them on a single box too. Or is the iterator heavily threaded?