It is currently Tue Feb 28, 2017 7:57 am

All times are UTC

Post new topic Reply to topic  [ 1 post ] 
Author Message
 Post subject: Deprecation of some PolyVox features
PostPosted: Fri Nov 09, 2012 3:23 pm 
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1795
For the upcoming release of PolyVox we are deprecating some of the current functionality. These are parts of PolyVox which do not work well, are not useful, or cause a lot of confusion to users.

This functionality will still be present in the next release, but it is being marked with a macro which will generate a compile warning if you try to use it. It is also being marked as deprecated in the API documentation. It will then be removed in some later release.

The details of what is being deprecated are below. You can use this thread to discuss any of these deprecations and how you should work around them.

ChangeLog.txt wrote:
Deprecated functionality
The following functionality is considered deprecated in this release of PolyVox and will probably be removed in future versions.

MeshDecimator: The mesh decimator was intended to reduce the amount of trianges in generated meshes but it has always had problems. It's far too slow and not very robust. For cubic mehes it is no longer needed anyway as the CubicSurfaceExtractor has built in decimation which is much more effective. For smooth (marching cubes) meshes there is no single alternative. You can consider downsampling the volume before you run the surface extractor (see the SmoothLODExample), and in the future we may add support for an external mesh processing library.

SimpleInterface: This was added so that people could create volumes without knowing about templates, and also to provide a target which was easier to wrap with SWIG. But overall we'd rather focus on geting the real SWIG bindings to work. The SimpleInterface is also extreamly limited in the functionality it provides.

Serialisation: This is a difficult one. The current serialisation is rather old and only deals with loading/saving a whole volume at a time. It would make much more sense if it could serialise regions instead of whole volumes, and if it could handle compression. It would then be useful for serialising the data which is paged into and out of the LargeVolume, as well as other uses. Both these changes would likely require braking the current format and interface. It is likely that serialisation will return to PolyVox in the future, but for now we would suggest just implementing your own.

VolumeChangeTracker: The idea behind this was was to provide a utility class to help the user keep track of which regions have been modified so they know when they need the surface extractor to be run again. But overall we'd rather keep such higher level functionality in user code as there are multiple ways it can be implemented. The current implementation is also old and does not support very large/infinite volumes, for example.

Offline Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1 post ] 

All times are UTC

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created