www.si-community.com

Mr.Core wrote:well, seems like something is messed up, because i see warnings about conflicting versions. To be sure, delete all openvdb stuff ( workgroups with ice nodes\arnold shaders from the sitoa folder ). then, 1) redownload archive 2) unpack and connect the VDB2SI_WG folder in the plugin manager 3) unpack the "extractToSITOAdir" into the C:\Users\username\Autodesk\Softimage_XXX\Addons\SItoA\Application\Plugins\bin\nt-x86-64 4) restart XSI

also you need to have installed vs2012 redistributable

First of all, mental ray shaders ( mi ) must work even if the arnolds package is not found

hi i did what u said
and it give me that error below
by the way .. in a new scene the shader doesnt appear in render tree
but the scene with the file render with arnold and 3 shader appear in ice tree.. black body is not there

you might have more response posting in the Arnold mailinglist....

try to disconnect the vdb workgroup, then connect it again ( this should set loading order to load arnold plugin dir first then vdb stuff ), or wiat till I will post an update of shaders without that piece of intel bs ( i mean tbb.dll )

works ok for me!



thank you Oleg, what is not clear here is that you have implemented a whole load of existing VDB code & functionality inside ICE compounds with this - so the cloud rendered here is completely procedurally generated with ICE and VDB nodes. no houdini involved ;) fantastic stuff, it is tremendously useful for some of us Softimagers to remain in touch with latest industry developments. it seems openVDB is more popular and succesful than Field3D ?

You are welcome, Rob I'd like to get some feedback and wishes on future implementation since it is not always clear how to better implement something here and there. I think openvdb has a far better spreading because of it's wide set of tools for volumetric processing, while field3d is only format by itself ( if i am not mistaken ). And i have feeling that openvdb has more agressive promotion

this is amazing!
played around with it a bit.

i'd love to see a connection to emFluid. (is that possible?)
or more examples for ICE only situations.

unfortunately i don't have anything to show yet. i'll go on and try again.

thank you very much Mr.Core

>>i'd love to see a connection to emFluid. (is that possible?)
Nothing special have to be done - emfluid just need to export in .vdb format and thats enough

...Nothing special have to be done...

i used "VDB Voxelize Particles" which worked so far.
but as this only translates "point-/-size/-velocity/-position", no voxelgrid/velocitygrid... i didn't get a cool look at all.

so guess caching to .vdb is needed...(?)



EDIT:

emfluid just need to export in .vdb format

how do i do that?

i dont have emfluid, but suppose we have access to raw voxel grid values, then you can build something like this:

however, I heard somewhere emfluid has native exporting to vdb, so ask Eric for this to make sure

thanks Mr.Core
i followed your setup, but had to change some stuff.

it renders quite ok, but there's something wrong with the voxelsize.
not shure about it.

thats an emfluid pointcloud Tartan? that so will not work that way, but good effort you could go down that path andemit some particles and advect them through your emfluid sim.. but the easy way would be to do like Oleg says and export the fluid grid cells as a vdb file - which version of emfluid are you on? the latest versions or so support this. I know this because we tested the exported vdb sequence in houdini.
now we do not have to.

Mr.Core wrote:You are welcome, Rob I'd like to get some feedback and wishes on future implementation since it is not always clear how to better implement something here and there. I think openvdb has a far better spreading because of it's wide set of tools for volumetric processing, while field3d is only format by itself ( if i am not mistaken ). And i have feeling that openvdb has more agressive promotion

excellent, well a list or an idea of which bits of VDB code you have implemented into ice nodes and what are there compound names.. or have you converted the entire cookbook!? going inside the compounds you made like solidify level set is actually change grid class. and then I am trying to go to the VDB docs to find where this is detailed but not having much luck to find the correct section or parts of the VDB docs so a wish to make it easier to translate some correlation between the library code functions names in the docs and the ICE compounds.. somehow? eg which compounds are or where are the VDB iterators, or the Tools

Utilities and Tools

OpenVDB provides utility functions and classes for the manipulation of grids and the data they hold. Tools such as those found in GridOperators.h compute vector quantities from scalar data or vice-versa. Other tools perform filtering (Filter.h and LevelSetFilter.h) and interpolation (Interpolation.h) as well as sampling (GridTransformer.h), compositing and constructive solid geometry (Composite.h), and other transformations (ValueTransformer.h). OpenVDB also supports advanced finite difference computations through a variety of local support stencils (Stencils.h).

a simple matter to do some more experimenting & reading on whats there - and I see there is a lot converted already , its a heck of a lot of stuff!

**edit** and a request - I do not see these below:taken from http://www.openvdb.org/download/openvdb_toolset.pdf I wonder if even VDB guys have done all these yet!
Gradient
tools::gradient
Mean curvature
tools::meanCurvature
Closest-point transform
tools::cpt
Divergence
tools::divergence
Laplacian
tools::laplacian
Buoyant density in an incompressible
fluid simulation
Magnitude
tools::magnitude
Curl
tools::curl

because in theory this should be way faster to do large scale neighbor lookups using vdb nodes than nearest neighbours in ICE itself?!

...export the fluid grid cells as a vdb file...

i'm using emFluid4. haven't yet found out how to export vdb...

ok. looks like this does the trick to match voxel grids and data content of emFluid and VDB.

still some issues.
e.g. i build the colorGrid inside emFluid as it does not exist like so. looking up with closest location decreases performance massivly...
also i expected a little bit more details with a cell size of 0.2...

I do believe you are turning the emfluid visualizer particles to VDB rather than the actual fluid grid.

version 4.0 you can cache the grid to Bafl format. for VDB it is the same way just rename to vdb in the export - but it could be a later version than you currently have