| Volumes Of Fun http://www.volumesoffun.com/phpBB3/ |
|
| Updating Strategies http://www.volumesoffun.com/phpBB3/viewtopic.php?f=14&t=238 |
Page 1 of 3 |
| Author: | GM_Riscvul [ Wed Jun 29, 2011 12:28 am ] |
| Post subject: | Updating Strategies |
Alright as some people know I am creating a procedural terrain engine using polyvox. I assume several people here are. Eventually I would like to have editable terrain. When terrain is edited, I assume the mesh has to be reextraced in order to display the changes. I was wondering if there was a way to extract only the affected area and then using that small mesh overwrite the affected meshes being used by the rendering engine (in this case OGRE). The reason is to make the areas being decimated as small as possible. This should make decimation rather fast, as most areas then needing to be decimated would be small and quickly done. If so would anyone be willing to share their thoughts on the process? This might end up not being about PolyVox at all. I apologize if I end up being in the wrong forum, but for now it seems to apply. Thank you. |
|
| Author: | DefiniteIntegral [ Wed Jun 29, 2011 3:14 am ] |
| Post subject: | Re: Updating Strategies |
I don't think it's going to be feasible to edit an existing extracted mesh because that would mean adding/removing vertices and re-ordering indices. If you are using marching cubes, the best approach would probably be to extract a full resolution mesh and make a copy of it immediately. Attach the full res mesh to the scene, then decimate the copy in a background thread and when that is complete, remove the full res mesh and replace it with the decimated one. For extraction speed you will probably want to extract a small area like 32x32x32 (or less... is it possible to extract a region smaller than the block size?) To aid rendering speed you could re-extract larger areas eg 128x128x128 over time in areas where no editing is occuring to reduce batch count. Due to time restrictions I have not implemented this feature in my own code so I can't give you much advice in that area. |
|
| Author: | David Williams [ Wed Jun 29, 2011 10:46 pm ] |
| Post subject: | Re: Updating Strategies |
Yep, I think the trick is to have your landscape consisting of a number of meshes. In one dimension your voxels might go 0-1023, and you your could generate seperate meshes for 0-32, 32-64, 64-96, etc.Obviously you actually have to break it up in three dimensions, but hopefully you get the idea. In the above example, if voxel 17 is modified you only need to regenerate the first mesh. But note that if voxel 32 is modified then you have to regenerate both of the first two meshes (I think this only applies with smooth terrain, not cubic terrain). You need to choose your mesh size appropriatly. Make it too small and you'll end up with too many batches, hurting rendering speed. Make it too large and it'll take too long to regenerate each mesh. DefiniteIntegral wrote: To aid rendering speed you could re-extract larger areas eg 128x128x128 over time in areas where no editing is occuring to reduce batch count. Due to time restrictions I have not implemented this feature in my own code so I can't give you much advice in that area. I am also intrested in trying to combine batches when appropriate. Use a single big batch when possible, or smaller ones to allow for local changes or for culling purposes. It could be done by reextraction or also by stitching together existing meshes. I'm not yet sure of the best way to share/combine the vertex and index buffers. It's an area for future research... |
|
| Author: | David Williams [ Thu Jun 30, 2011 8:37 pm ] |
| Post subject: | Re: Updating Strategies |
David Williams wrote: I think this only applies with smooth terrain, not cubic terrain Actually I take this back. As pointed out here, when you modify border voxels you do need to reextract more than one mesh even when working with cubic meshes. |
|
| Author: | GM_Riscvul [ Sun Jul 03, 2011 5:44 pm ] |
| Post subject: | Re: Updating Strategies |
Quote: You need to choose your mesh size appropriatly. Make it too small and you'll end up with too many batches, hurting rendering speed. Make it too large and it'll take too long to regenerate each mesh. Yes I suppose I will have to experiment to see what size allows for an acceptable generation/extraction/decimation speed. I was hoping there might be a good method for avoiding decimating to much mesh at one time. I had another question that is related. What strategies have been used to determine how many 'chunks' to pull at a given time. Of course a view limit is a good general strategy for a maximum limit on chunks being pulled, but is there some good strategies for pulling less chunks. For example. Much of the underground portion of my maps will never be seen by the viewer, and most of the sky will be empty. Is there a way to avoid extracting more chunks than are necessary? I haven't thought of any way to avoid pulling out to maximum view range in the sky, but I have thought of a possibility for avoiding the extraction of too many chunks below ground. I've thought perhaps I could only pull one more chunk below ground unless there is an empty voxel on the edge. Then I need to continue generating chunks until the empty space (the cave) is finished being extracted out to the maximum view radius. Any thoughts? Thanks for the help. |
|
| Author: | David Williams [ Sun Jul 03, 2011 6:26 pm ] |
| Post subject: | Re: Updating Strategies |
You probably want some seperation beteween what is extracted and what is rendered. That is, you can probably extract everything withon 1000 voxels, but only actually render those meshes which are in the camera frustum. If you want to handle meshes which are in the view frustum but hidden behind other meshes then you might look at hardware occlusion queries. |
|
| Author: | GM_Riscvul [ Wed Jul 20, 2011 9:09 pm ] |
| Post subject: | Re: Updating Strategies |
Thanks for the help so far. I've been getting alot of questions answered. I have run into another question I haven't been able to answer so far. I am considering dividing my volume into 32x32x32 size chunks. How do I find out which 'chunk' the camera (or player) is currently in? This seems to be critical to finding out which regions need to be extracted and where I should save chunk data. It must be somewhat obvious as I have not seen it mentioned anywhere, but I am at a loss. |
|
| Author: | beyzend [ Wed Jul 20, 2011 10:19 pm ] |
| Post subject: | Re: Updating Strategies |
What I do is I use: Code: floor(worldPosition / 32.0) Where 32.0 is the length per region in blocks. This works for negative blocks because floor function points toward negative infinity. So for example, a world x of -1.0 should be in the -1 region because world x of 0 should be in the 0th region. And with floor it works. |
|
| Author: | GM_Riscvul [ Thu Jul 21, 2011 1:27 pm ] |
| Post subject: | Re: Updating Strategies |
Quote: What I do is I use: Code: floor(worldPosition / 32.0) This much I have figured out. I'm not sure where the worldPosition comes from. I assume thats easy when editing voxels, but I would like to know the camera's position in the voxel world. How do I convert the camera's position to a voxel position? |
|
| Author: | ker [ Thu Jul 21, 2011 2:07 pm ] |
| Post subject: | Re: Updating Strategies |
depending on your setup you don't need to convert anything at all. 1. you should align your volume center to your graphical center (basically this means, you don't do anything, it's easier that way) 2. if you want 1 graphical unit to be less or more than 1 voxel unit, you need only to scale your camera coordinate by the same factor and then use the resulting coordinate as world coordinate (this works for any coordinates, not just cameras) |
|
| Page 1 of 3 | All times are UTC |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|