| Volumes Of Fun http://www.volumesoffun.com/phpBB3/ |
|
| Incoming PolyVox changes http://www.volumesoffun.com/phpBB3/viewtopic.php?f=14&t=591 |
Page 4 of 4 |
| Author: | kklouzal [ Mon Aug 25, 2014 5:54 am ] |
| Post subject: | Re: Incoming PolyVox changes |
David Williams wrote: 3) Rather than using a PolyVox Mesh instance, you could provide your own mesh class and PolyVox would write directly into that. For example, PolyVox could write directly in OpenGL vertex buffers or an Ogre::ManualObject, thereby reducing how many copies you have to perform. This is beautiful, no longer will I have to deal with Irrlicht's mesh buffer to draw my extracted volume. I do have a couple questions about the functionality provided by this feature. Say I have a volume of 10,000 x 10,000 x 10,000. I extract the entire volume into Irrlicht's mesh class (IMesh). Now I change a small region of the volume and again extract the surface data from the volume but I only extract that small region which was changed into my IMesh. Will this override all of the previous vertex and index data that was in the IMesh? Or will it actually update the IMesh with the changed data? Also with the addition of this feature does this now mean that we will finally see support for specifying material id's on voxels and uvw data will be extracted into our mesh instances? If not it seems kind of pointless to allow extraction into our own mesh classes if we will just have to iterate through the voxel data again to apply multiple textures and texture mapping. |
|
| Author: | David Williams [ Mon Aug 25, 2014 1:50 pm ] |
| Post subject: | Re: Incoming PolyVox changes |
@kklouzal - I'm afraid it won't do anything quite as big as you are hoping. The output from the surface extractors is still just a series of vertices and indices. Previously these always went to the Mesh class which would store them in an std::vector, but now you have the option of provide your own mesh class which does something different with them. You still need to work with regions, and keep track of changes. Updating just part of the mesh is a difficult problem and PolyVox can't do it (though I did see an interesting discussion here). It seems it probably isn't worth attempting. Basically this change is mostly an optimization which could remove the need for some additional copying. But as I say I haven't really tested it - it just came for free when I templatised the extractors on mesh type to support 16 vs. 32 bit indices. I think at some point we might try making use of it in Cubiquity. |
|
| Page 4 of 4 | All times are UTC |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|