OpenVDB for games/apps: the Houdini option or the OpenVDB.DLL option?

[necro...@gmail.com]

Hello everyone,

As I learn about OpenVDB I wondered what will be the best way to use it to create apps (or games). I did some research and now I have some questions and ideas that I will like to share with the community.

1. Houdini plug in for Unity3d/Unreal: As I understand OpenVDB is used by Houdini, by using the Apprentice version and watching the videos on SideFX it is obvious that Houdini is a lot more powerful than other 3d software in terms, you can quickly create thousands of polys and manage/move/change them without any delay. I still need to review the plug in, but watching the videos it looks like you have to "cook" or "bake" the files from Houdini and them import them to Unity3d/Unreal. In other words, there is little (or no) chance for real time interactions in your app. (By Real Time  I mean destroy-build-change the 3d geometry in the app/game)
2. Houdini Engine API: The plug in connects Unity3d/Unreal to the Houdini Engine API. I have not check the Engine yet but it could be another option to have real time interactions. Not sure if the API includes a connection to OpenVDB or allows to manipulate VDB files... (must check later)
3.  OpenVDB as DLL: This could be something like the Houdini plug in. The idea will be to create a plug in to wrap the classes and functions you need to call in OpenVDB. 
1. This is required for Unity3d as it does not use C++, the most practical way will be to create a C# class that wraps the C++ call to the DLL.>> http://docs.unity3d.com/Manual/NativePlugins.html

using UnityEngine;
    using System.Runtime.InteropServices;

    class SomeScript : MonoBehaviour {

       #if UNITY_IPHONE || UNITY_XBOX360
   
       // On iOS and Xbox 360 plugins are statically linked into
       // the executable, so we have to use __Internal as the
       // library name.
       [DllImport ("__Internal")]

       #else

       // Other platforms load plugins dynamically, so pass the name
       // of the plugin's dynamic library.
       [DllImport ("PluginName")]
   
       #endif

       private static extern float FooPluginFunction ();

       void Awake () {
          // Calls the FooPluginFunction inside the plugin
          // And prints 5 to the console
          print (FooPluginFunction ());
       }
    }

1. For Unreal it is slightly different, as it uses C++, but if you want to use Blueprint you will need to do something like this >> https://wiki.unrealengine.com/Linking_Dlls

 

#pragma once

 
#include "GameFramework/Actor.h"
#include "Libraries.generated.h"
 
/**
 * Meaningful and useful comment goes here.
 */
UCLASS()
class ULibraries : public UBlueprintFunctionLibrary
{
        GENERATED_UCLASS_BODY()
 
        // Blueprint accessible method.
        UFUNCTION(BlueprintCallable, Category = "Karma Libraries")
        static float getCircleAreaDLL(float radius);    
}

;

I haven not try any of the above options, but I am considering the pro/cons of each one. The Houdini plugin requires a small payment for Indies ($199), the code "just works", you can start right away, the Engine alone could need some coding (if something "extra" is needed that is not included in the plugin). The OpenVDB DLL is free, but it requires a lot more work to have it ready for your app/game. It should not be that much, I was thinking that something like this could work as a basic feature to open, update, remove geometry:

1. OpenVDB will be used mostly as "DB", in other words the role is to store the geometry for the game.
2. Unreal/Unity3d have procedural geometry functions, which are not concerned how you created/destroy/manipulate the geometry, you just provide an input>  
1. http://docs.unity3d.com/Manual/UsingtheMeshClass.html
   
2. https://docs.unrealengine.com/latest/INT/BlueprintAPI/Components/ProceduralMesh/index.html
   
3. Technically you coudl:
1. create a Grid in OpenVDB, 
2. send the information to Procedural Mesh class in the Game Engine.
3. let the Game Engine do everything else as usual (render, materials, collisions, pathfinding,etc)
4. if the geometry needs to be change, then send OpenVDB a request to update the geometry (using OpenVDB classes to manipulate the information in the Grid)
5. retrieve the new geometry as you did previously
4. One pro is obvious is the power to keep a huge amount of data in OpenVDB and real-time interaction with that data (allowing the game to change geometry "on the fly")
5. One con, could be, that sending back and forth information about geometry from the app to OpenVDB and viceversa could reduce the app perfomance. Maybe a good coding could reduce it but eventually the question can only be answered by creating the plug in right?

I personally like the option to use OpenVDB as dll, it promises a lot more power and flexibility, I will try to check Houdini plugin and Engine ( I am loving using Houdini Apprentice). I do not have any code yet for the OpenVDB, I have no idea when I could sit down and work on it, I do  not even have the dll for Windows, that is another challenge to tackle.

Please let me know your ideas and comments about it, if we have many minds processing we could find a great solution faster :)

Regards

Mau