Jump to content

  • Log In with Google      Sign In   
  • Create Account


GPU based heightmap editor


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 mark ds   Members   -  Reputation: 1132

Like
0Likes
Like

Posted 08 June 2014 - 04:28 PM

Like many others, I'm currently going through tool creation hell!

 

Part of that includes a heightmap editor which I'd gotten quite a way into - but it was CPU based and I was really unhappy with it. So I've deleted it, lock stock and barrel, and I'm going to rethink the whole thing and do it on the GPU.

 

Part of the problem was to do with vertex picking, and applying texture based brushes centred on the 'picked' vertex. Whilst quadtrees are ideal for this, as the map grows (and I want very large maps) edits can become quite a problem as the quad tree is constantly being updated before I can use it to get the vertex currently under the brush, and of course I have to guarantee that the data on the CPU & GPU are in sync. There where several other minor issues which also made the performance inconsistent.

 

My idea is to essentially write a traditional event driven Win32 program (GetMessage, vsync off, vs PeekMessage, vsync on) which triggers the GPU to update the heightmap on 'mouse down' events at fixed time intervals - maybe 20 times per second. For vertex picking, I intend to write to two colour buffers - a normal colour buffer, and a 32-bit RG floating point buffer using colours interpolated from 0.0f, 0.0f to heighmap width and height (e.g. 8192.0f). On mouse move, I can then use the mouse XY coordinates to copy the pixel value under the mouse into a 1x1 texture, which can then be read back by a shader (rounding the RG colour to the nearest integers will give me a precise XY vertex), which in turn can modify heighmap values based around these coordinates using a another texture 'brush'. This also allows for a really simple undo/redo mechanism totally on the GPU by pre-copying an area into a buffer before modifying the original data.

 

The benefits include only using one GPU side set of data, and better performance to boot.

 

 

 

I spent many, many weeks on the original version, so I thought it wise to post here before I embark on version 2!

 

My question is, can anyone think of any problems I may encounter with the above approach, or maybe suggest a totally different approach to a heightmap editor?

 



Sponsor:

#2 SeanMiddleditch   Members   -  Reputation: 4759

Like
2Likes
Like

Posted 08 June 2014 - 11:52 PM

Why is GPU usage and performance so important to you for the _editor_ ? Your work should 100% be focused on (a) what makes it easier for the content creator and then (b) what makes it easier for you to deliver new features and tools to the content creator.

#3 kauna   Crossbones+   -  Reputation: 2284

Like
0Likes
Like

Posted 09 June 2014 - 09:18 AM

I think you shouldn't think the height map as a set of vertices - the vertices are needed only for the presentation. Instead, consider it as a (grayscale) bitmap and all your tools work on that basis. 

 

Cheers!



#4 Wilhelm van Huyssteen   Members   -  Reputation: 927

Like
0Likes
Like

Posted 12 June 2014 - 02:37 AM

Hi.

 

Ive gone through a similiar process with my editor (see video here http://www.gamedev.net/blog/807/entry-2259360-strife-world-editor/). It used to be CPU based but the framerate became so low it was pretty unusable to do continues drawing. I use a grayscale image next to the terrain display to draw on because it seemed better at the time. However for painting textures or placing models onto the terrain i use picking to get the coordinates under the cursor. I use two 24 bit textures. one for x and one for y. i treat the 24bit's (RGB8) as one number so i can go from 0 to 16777216. wich is overkil but only going from 0.0 to 1.0 (wich is 0-255 when using 8 bit textures is way to little if you have a big heightmap).



#5 L. Spiro   Crossbones+   -  Reputation: 12873

Like
0Likes
Like

Posted 12 June 2014 - 03:19 PM

triggers the GPU to update the heightmap on 'mouse down' events at fixed time intervals - maybe 20 times per second.

Why would you update the heightmap if it hasn’t changed?

Are you talking about dragging vertices up and down manually?

It’s really trivial to make a translucent patch for that area and only update that as the user drags the mouse.  Only update the terrain when the user lets go.

 

For vertex picking, I intend to write to two colour buffers - a normal colour buffer, and a 32-bit RG floating point buffer using colours interpolated from 0.0f, 0.0f to heighmap width and height (e.g. 8192.0f). On mouse move, I can then use the mouse XY coordinates to copy the pixel value under the mouse into a 1x1 texture, which can then be read back by a shader (rounding the RG colour to the nearest integers will give me a precise XY vertex), which in turn can modify heighmap values based around these coordinates using a another texture 'brush'.

That sounds like an extremely convoluted way to do picking when it is trivial to take advantage of heightmap terrain’s grid-based layout for real-time picking on the CPU (which will be faster and much less complicated than what you have just proposed).


It sounds as though your tool is slow because you have poor high-level strategies, and the GPU strategies don’t seem any better.
I would suggest looking at what is actually a bottleneck and fix that first.  In my first fixed-function engine I made real-time sunlight by ray-casting every vertex on the terrain against the sun to check whether they were in shadows or not (real-time vertex light-baking) and it ran on low-end machines in real-time.

And whatever bottleneck you think you have regarding updating the terrain is a product of a poor updating strategy.  You don’t need more brute power, you need more efficient approaches.

 

 

L. Spiro


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS