It is currently Sat Aug 22, 2020 3:41 am


All times are UTC




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: Don't generate VDBs
PostPosted: Sat May 06, 2017 7:13 am 

Joined: Fri May 05, 2017 11:02 am
Posts: 2
Hello,
I'm currently working on a healthcare project where I use your (FANTASTIC!) Cubiquity engine to manage a huge quantity volumetric data.
I need to reconstruct isosurfaces to be used in a realtime project (Unity3D) and I follow the pipeline:
  • create a Volume Data and a Volume component for each object I need to build
  • Once populated all the volumes, add the Volume Renderers
  • When the isosusrfaces have been built, I remove all but the meshes that I'll use

Everything works great, but I have a huge bottleneck in the pipeline that destroys my build time performance: every time I build a volume data ( through Cubiquity.VolumeData.CreateEmptyVolumeData ), a vdb file is generated. I'd like to work without generating any file on the file system, because I'll destroy the volume data and the volume renderer after a few time.

Is there a way to work without generate any VDB file?

Thanks you so much
Alex


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Don't generate VDBs
PostPosted: Wed May 10, 2017 6:47 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
Hi, sorry for the slow reply. I don't think there is a way do do what you request as the use of a voxel database is fairly key to the way Cubiquity works. If I understand correctly, you are actually just using Cubiquity as a way to generate the initial mesh from the volume data, and after that is done you don't need to perform any further modifications? If so then Cubiquity might not be the best approach, because you'll pay quite a high cost for the ability to modify the mesh which you are not using. Perhaps just a basic C# Marching Cubes implementation would be better?


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Don't generate VDBs
PostPosted: Wed May 10, 2017 7:42 am 

Joined: Fri May 05, 2017 11:02 am
Posts: 2
hi, thanks for your reply.

Yes, you got it the way I'm working.

I've tried to use a simple marching cube approach, but the result was not so amazing.
The resulting meshes were not smooth enough, and (I suppose), cubiquity partially implements the algorithm on GPU, speeding up the calculation process. The meshes generated by cubiquity looks very fine.

(isn't it?)

I'd like to use only the piece of code of cubiquity that works for this purpose (as it's free and now open source too), but I suppose that to isolate it is not not so easy. Moreover, I cannot find the complete code of cubiquity (the repository I've found refers to the previous version of the engine).

Moreover, I cannot exclude - at the time - that in future I could need for the full features offered by cubiquity.

thanks again for your reply


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Don't generate VDBs
PostPosted: Sat May 13, 2017 8:16 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
Alexandros wrote:
The resulting meshes were not smooth enough, and (I suppose), cubiquity partially implements the algorithm on GPU, speeding up the calculation process. The meshes generated by cubiquity looks very fine.


The algorithm is actually implemented only on the CPU, with the mesh being passed to Unity for rendering on the GPU. It is quite a high-quality implementation which indeed handles smoothing and is written in C++ for performance. However, it might be slowed down by the fact that it supports dynamic modification (I've never actually compared it to other implementations).

Alexandros wrote:
I'd like to use only the piece of code of cubiquity that works for this purpose (as it's free and now open source too), but I suppose that to isolate it is not not so easy. Moreover, I cannot find the complete code of cubiquity (the repository I've found refers to the previous version of the engine).


The Marching Cubes implementation is part of PolyVox library, which is used by Cubiquity, which is in turn used by Cubiquity for Unity3D. This means the code is quite tightly coupled to the underlyng data structure and will be difficult to separate (as well as being written in template-heavy C++). However, it was originally derived from Paul Bourke's implementation which is much simpler and might be much easier to port to C#. This might all be too much work though, if what you've got is working well enough.


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

All times are UTC


Who is online

Users browsing this forum: Majestic-12 [Bot] and 2 guests


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:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created StylerBB.net