Height map advice

mattgolsen's picture

I'm looking to create a composition that's sort of a live height map and I sort of need a push in the right direction to get started. I'd like to achieve the same sort of result as the attached file.

The concept is that I've got a list of people, and each person would be assigned at a specific real world point on an image of a location, their position will never change, but a certain number that is associated with them will change throughout the day, "pushing" their area to an increased height. These numbers will be grouped by their team in a structure.

My first instinct is to do something with meshes, but I've never really done anything with them, or really know where to start.

Any ideas or advice?

PreviewAttachmentSize
crimesf.jpeg
crimesf.jpeg23.42 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

gtoledo3's picture
Re: 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.

gtoledo3's picture
Re: Height map advice

This may give you some food for thought:

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

jersmi's picture
Re: Height map advice

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.

psonice's picture
Re: Height map advice

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.

jersmi's picture
Re: Height map advice

GLSL -- also a super cool idea!

gtoledo3's picture
Re: Height map advice

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.

gtoledo3's picture
Re: Height map advice

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.

psonice's picture
Re: Height map advice

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.

gtoledo3's picture
Re: Height map advice

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.

psonice's picture
Re: Height map advice

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.

gtoledo3's picture
Re: Height map advice

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.

psonice's picture
Re: Height map advice

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?