Planetside Software Forums

General => Terragen Discussion => Topic started by: Matt on June 13, 2018, 07:18:11 AM

Title: VDB workflow testing
Post by: Matt on June 13, 2018, 07:18:11 AM
I'd like some help to test VDBs exported from Terragen clouds. Who here has experience using VDBs in other software? Better yet, have any of you rendered VDB clouds and understand how to manipulate their scale, density and shading parameters to make realistic renders?

At the moment I have basic VDB export capability working in our Linux build, and the next step is to work out how to scale them appropriately in space in a variety of situations so that they can sit correctly alongside cameras imported and exported between Terragen and other major 3D software that supports VDB files. We also need to figure out how to set density parameters to try to get 1:1 match of optical density (alpha / opacity) for shadow casting, regardless of scale. Eventually we want to be able to take VDBs in the other direction too, i.e. import VDBs to Terragen, but we are not working on that just now.

If you're interested in helping us to test this, please let me know what software you've used VDB with. It would be really great if you can also show examples of any prior work you've done.

You can either post a reply here or send me a private message or email if you prefer. Maybe we can start a VDB testing topic here on the forum, or collaborate offline if that's better for whatever reason.

Thanks! 😀

Matt
Title: Re: VDB workflow testing
Post by: pokoy on June 13, 2018, 08:42:26 AM
I could do some test now that Corona in 3dsmax supports VDB. I have no experience with VDB yet but I know that different packages do things differently (Blender and PhoenixFD have different density/temperature channel scaling for example) so some testing of different VDB file examples would be needed in order to find some middle ground that works for most users.
From what I know most packages allow arbitrary scaling of any channel so users have all the control, I guess it's 'just' a matter of finding a good default.
I could do some tests starting next week until end of June. I'm away for holidays through July and could continue testing after that again.

I haven't rendered VDBs yet since the renderer of my choice didn't support them until recently. But I'm pretty sure I can get something usable in short time, and could test the VDBs in Arnold and Corona in 3dsmax.
Title: Re: VDB workflow testing
Post by: SILENCER on June 13, 2018, 09:46:16 AM
We'd love to give it a shot in LW2018 with Octane.
2018 has VDB import, and Octane renders them like a boss.
The linux thing, however, is a barrier for us.
Title: Re: VDB workflow testing
Post by: Matt on June 13, 2018, 02:55:11 PM
Pokoy,

That sounds great. Yeah, the differences in channel scaling are something I hope to minimise, or at least get an understanding of the differences in various software so we can provide clear advice for users of each program or renderer.

SILENCER,

For this early testing phase I will generate the VDBs, so you won't need Linux. Later on we'll get it running on Windows and Mac.


My plan is to generate some VDBs next week and share them with you. I'll also include cameras (FBX) and terrain export so we can try to get parity between renderers.

Matt
Title: Re: VDB workflow testing
Post by: WAS on June 13, 2018, 02:59:31 PM
No way! I only just found out about open vdb clouds recently due to your v3 clouds Matt, this is so exciting to hear about.
Title: Re: VDB workflow testing
Post by: mdharrington on June 13, 2018, 05:48:10 PM
Would love to do some beta tests as I was one of the originals asking for this.....be using octane/houdini/lightwave.

I think its important to remember some of the important render scale parameters will be outside the scope of the VDB exported fields ....step length being most important.

Octane has the step length parameter in meters...as well as Houdini (AFAIK)....this will greatly affect render density appearance, overiding whatever you put in the VDB file for density (as far as render appearance). This parameter if not precisely matched, will greatly affect density/shadowing/detail appearance but is not integrated into the VDB container (AFAIK)

If TG can have an adaptable control (or equivalent) of the ray step length through the volume....then all things being equal density should appear equal in both TG renders and external.

As long as users are aware that they should scale step length to match TG world size during export (many apps may wish to shrink world scale as opposed to TG)
Title: Re: VDB workflow testing
Post by: pokoy on June 14, 2018, 06:46:01 AM
Quote from: mdharrington on June 13, 2018, 05:48:10 PM
Octane has the step length parameter in meters...as well as Houdini (AFAIK)....this will greatly affect render density appearance, overiding whatever you put in the VDB file for density (as far as render appearance). This parameter if not precisely matched, will greatly affect density/shadowing/detail appearance but is not integrated into the VDB container (AFAIK)

Step length - I guess this is a ray marching accuracy parameter on the renderer side only, totally independent from VDB data. We should test VDBs from TG and other packages with the same ray length settings for consistent and meaningful testing.
Title: Re: VDB workflow testing
Post by: pokoy on June 14, 2018, 06:53:03 AM
What would be nice is a VDB viewer app, to be able to analyze the data... I've found this, but it has to be compiled if I understood correctly:
https://nidclip.wordpress.com/2014/02/26/openvdb-standalone-gui-with-opengl/ (https://nidclip.wordpress.com/2014/02/26/openvdb-standalone-gui-with-opengl/)

Anyone know of a standalone tool independent from any DCC host app?
Title: Re: VDB workflow testing
Post by: ajcgi on June 14, 2018, 11:26:38 AM
Hey Matt. It's a yes to testing that in Houdini here!
Title: Re: VDB workflow testing
Post by: mdharrington on June 14, 2018, 02:42:14 PM
Quote from: pokoy on June 14, 2018, 06:46:01 AM

Step length - I guess this is a ray marching accuracy parameter on the renderer side only, totally independent from VDB data. We should test VDBs from TG and other packages with the same ray length settings for consistent and meaningful testing.

Exactly....it is precisely the ray marching length between samples (some renders may refer to it as quality..but they should be values normalized to meters).  A VDB of 1m with a step of 5m will have the ray pass right through it.

Normally there is zero advantage to having the step length shorter than the voxel cube size....but many advantages to going longer (speed being the main one)
For similar appearance and density comparison the step length must be the same.

A common step length of .5m or 1m are usually render defaults.....but will bring renders to a crawl with a 5km cloud scene. And in such sizes TG may be beneficial sampling a 20-100m step. This is the main difference in values I could see, as TG will commonly have massive scales.

EDIT:
Houdini step length is normalized to voxels not meters. 1 means all voxels sampled, .5 means every second voxel sampled.
Arnold step size is in object space and not world.....likely voxels as well
Octane is 100% in meters
Lightwave is in meters

One really has to pay attention to get meaningful comparisons. Octane and LW will have to know voxel size in order to set step length to match arnold and houdini renders
Title: Re: VDB workflow testing
Post by: SILENCER on June 14, 2018, 07:40:45 PM
Sounds great, Matt.
It'll be interesting to see the TG clouds out of their comfort zone for a little cardio.
Title: Re: VDB workflow testing
Post by: Matt on June 16, 2018, 10:35:10 PM
TESTING: For some reason the forum won't let me post my reply. Is is too long or something?
Title: Re: VDB workflow testing
Post by: Matt on June 16, 2018, 10:36:20 PM
Mike and Alex, I look forward to seeing your tests too. Thanks for the info about step lengths Mike. It sounds like there's a lot to learn here.

Matt
Title: Re: VDB workflow testing
Post by: Matt on June 16, 2018, 10:51:34 PM
Quote from: mdharrington on June 13, 2018, 05:48:10 PM
If TG can have an adaptable control (or equivalent) of the ray step length through the volume....then all things being equal density should appear equal in both TG renders and external.

TG renders more detail than will be exported in the VDB, because its density functions are evaluated on the fly. So if TG had a step length property it would be measured in metres in world space rather than in voxels. However, it isn't an exposed parameter because when TG renders it changes step length dynamically to optimise quality, with "ray march quality" being a master control.

The way TG thinks about rendering volumes, the optical density of a voxel is measured in m^-1 in world space. As long as the ray march quality is not too low to miss important details, ray march quality shouldn't have much effect on mean density. This density will be written directly into each voxel. If some external renderer expects an opacity value rather than density, I'll add an option for that, taking into consideration the expected world size when converting from density to opacity. If some other renderer works with density but has odd behaviour when the voxel sizes are different (which they will be in a multi-resolution VDB) then I'll have to adjust for that when exporting.
Title: Re: VDB workflow testing
Post by: Matt on June 16, 2018, 10:51:39 PM
I don't anticipate changing TG's render output to match an external renderer (unless we discover something wrong or significantly lacking compared to another renderer), but I do want to try to get the external renderers to match TG at shadow opacity, if not other measures. To test for equivalent volume density we'll render a pure black cloud casting a shadow onto a white surface (pure black to eliminate any scattering/GI from the cloud onto the surface). It should be possible to make these black shadow tests look almost the same in multiple packages. After that, we'll add some scattering (albedo) to the cloud, and this is where it gets complicated. With a non-black cloud the shadows on the ground will receive some light scattered through the cloud, and that's where I expect the shadows to look a little different between renderers. Some unbiased renderers might do this better than TG. And then finally we'll look at the light reflected from the cloud into the camera, which is where most volumetric renderers struggle to create realistic clouds. It's going to be really interesting to see how this looks in different renderers and I don't expect to make them look similar. The basic measure of equivalent volume density will come from the black shadow tests.

Matt
Title: Re: VDB workflow testing
Post by: paq on June 17, 2018, 11:49:54 PM
Hi Matt,

I'm really thrilled by this .vdb export feature !
I'm mainly use Clarisse, and as you can see (attach), there are not lots of options inside the vdb attributes and the volume shader, (and I have never used multi-res .vdb).
Anyway I'll love to give an hand with my limited technical knowledge on the subject. I usually use Terragen to render skies, and use some nasty alpha tricks to modulate Clarisse atmosphere.

I had tried once to build a complete skies from different .vdb clouds, and it wasn't that great ( https://www.behance.net/gallery/53179645/Monolyth (https://www.behance.net/gallery/53179645/Monolyth) ).
That said, the cool think with Clarisse, there is no problem to deal with multiple Gig's of data ... but generating huge data is maybe not the goal for the moment.

You might maybe be in touch with Greg Barta (aka Xilofoton). He seems very focused on atmosphere / cloud rendering with "traditionnal" package (Houdini / Mantra / Redshift and Clarisse). Here's is his blog : https://scivfx.wordpress.com/tutorials/ (https://scivfx.wordpress.com/tutorials/)  ... maybe you guys are talking the same language ;)

(let me know if you want his mail address)
Title: Re: VDB workflow testing
Post by: Matt on June 19, 2018, 09:50:39 PM
Let's post test renders in this thread.

Testing Round 1

https://tinyurl.com/ycbscxxk

In this package you'll find:


The square calibration chart should be a Lambert diffuse surface. It has four quadrants that should have albedos of 4.5%, 18%, 36% and 72%. The texture map is intended to contain these values if read into a renderer with gamma 2.2, but sRGB colour space should be close enough.

The 3:2 image aspect ratio may seem an unusual choice, but I did this because it matches the default aperture/film back on the camera, and I thought this might reduce the chance of the FOV being different when you enter the 50mm focal length or import the FBX file.

Our first goal should be to render something in various 3D packages that closely resembles vdb_calib_01_shadow_of_black_cloud_v001.tif (or .exr)

Matt
Title: Re: VDB workflow testing
Post by: Matt on June 19, 2018, 09:57:36 PM
vdb_calib_01 renders from Terragen:
Title: Re: VDB workflow testing
Post by: Matt on June 19, 2018, 10:17:22 PM
Ideally the VDB will load into your scene and appear approximately in the right place above the calibration chart. It won't match exactly because the VDB export doesn't account for the curvature of the planet, but the difference in position should be no more than a few pixels in the render. I will fix this in one of the next rounds.

If you have to make any scale changes or position changes to get something close to my renders, please let me know.
Title: Re: VDB workflow testing
Post by: ajcgi on June 20, 2018, 06:20:02 AM
Hi Matt! This is exciting! I am gonna slowly bring stuff in to Houdini today around the actual work I'm meant to do here. ;)
First issue for me is that there's a scale difference between the grid and the camera of 1000, taking one unit in Houdini to be one metre.
Screengrabs attached. Cloud comes in at the same scale as the grid and sits in place. ;)

[attach=1]
Title: Re: VDB workflow testing
Post by: pokoy on June 20, 2018, 08:46:47 AM
Downloaded, all FBX files worked fine, camera is positioned correctly for me in 3ds max. However, I don't get anything from the VDB, it's completely invisible, even increasing density to high values doesn't make it show up. When testing some example vdb file it worked, yours won't display anything.

I am not sure if it's user error on my side so let's wait until someone else comments here, maybe it's just me. Will give it another test tomorrow and see if I missed something.
Title: Re: VDB workflow testing
Post by: paq on June 20, 2018, 09:32:05 AM
Hi pokoy,

The .vdb loads fine in Clarisse, however the density attribute (or property), usually called 'density' is named 'Easy cloud 01'. There is probably a way to remap the data in 3dsmax.

So I have a first setup in place, done by hand has Clarisse don't load .FBX.
Scaling is right (it's a 10Km large scene).

Direct light exposure is set on 1.5, and I have an env.light on -3 (???)

With the a default volume shader settings, and the overall density reduce to 50%, it looks more like smoke than cloud. I'll post the scene on Isotropix web site (may I Matt ?), because I'm really curious what kind of trick we could use to get a proper cloud look  8)

Cheers.
Title: Re: VDB workflow testing
Post by: ajcgi on June 20, 2018, 09:36:40 AM
To begin with I also got nothing. It took 3 of us here to figure it out at lunch. Ultimately, the density attribute in the vdb is still named 'Easy cloud 01' and not 'density' which Houdini is expecting.

I've now got the scene up to the point where the shadow works! The density on the pyro shader had to be reduced to 0.2 and then it was all go. More images attached. There's a slight offset in shadow position.
Title: Re: VDB workflow testing
Post by: pokoy on June 20, 2018, 09:38:13 AM
Ok, good to know it works. I've tried Arnold today, will repeat with Corona tomorrow.
Even when remapping the channel nothing showed up, maybe the Arnold volume object is hardcoded to use standard names.
Title: Re: VDB workflow testing
Post by: paq on June 20, 2018, 09:45:11 AM
Hi pokoy,

Here's the .vdb with the attribute renamed as density. The file is slightly bigger, I hope Houdini hasn't change anything else during the conversion :S
Title: Re: VDB workflow testing
Post by: sboerner on June 20, 2018, 09:49:48 AM
The cloud remains invisible to me as well. I'm testing it in Maya 2018 with Arnold and I am unable to assign a volumetric shader to it.

In the cloud's attributes panel only one channel, "Easy cloud 01," is listed under Grids and Velocity Grids. Other VDB files include several channels here with names like "density," "heat," etc.

Maya throws six errors when I try to assign the shader, two each for "Easy," "cloud," and "01." So I wonder if this might just be a naming issue since "Easy cloud 01" includes spaces.

[attach=1]

Size of the calibration chart on import is 100 x 100 meters, so that's off by a factor of 100. The FBX camera imports to the correction location.
Title: Re: VDB workflow testing
Post by: ajcgi on June 20, 2018, 09:53:01 AM
Maybe try Paq's file there with the renamed attribute?
Title: Re: VDB workflow testing
Post by: sboerner on June 20, 2018, 09:56:29 AM
QuoteMaybe try Paq's file there with the renamed attribute?

Just saw that, thanks. I'll give it a try.

Edit: That did the trick. The cloud shows up in render view. I'll look at this tonight and will see if I can match the shadow rendering.
Title: Re: VDB workflow testing
Post by: Matt on June 20, 2018, 03:52:32 PM
I'm really pleased to see so much feedback already! Thank you all. I'll take a closer look this afternoon.  :D
Title: Re: VDB workflow testing
Post by: paq on June 20, 2018, 04:53:20 PM
Hello,

So I'm trying to get a little bit of feedback from Clarisse users on the subjet :
https://forum.isotropix.com/viewtopic.php?f=5&t=4027

mdkai has some interesting remark about the shading, but I'm not really sure to follow, it's a little bit out of my range  8)
Title: Re: VDB workflow testing
Post by: Matt on June 20, 2018, 06:45:13 PM
Quote from: ajcgi on June 20, 2018, 06:20:02 AM
First issue for me is that there's a scale difference between the grid and the camera of 1000, taking one unit in Houdini to be one metre.

I think you mean 100? Perhaps the FBX is using centimetres and either Terragen isn't marking the units as cm or Houdini isn't respecting this when reading it in. I don't know if this is something we should fix in Terragen, considering it seems to be loading correctly in 3DS Max. But it's good to know this is happening and how to compensate for it.

Matt
Title: Re: VDB workflow testing
Post by: Matt on June 20, 2018, 06:59:13 PM
Quote from: ajcgi on June 20, 2018, 09:36:40 AM
To begin with I also got nothing. It took 3 of us here to figure it out at lunch. Ultimately, the density attribute in the vdb is still named 'Easy cloud 01' and not 'density' which Houdini is expecting.

OK, I'll fix this. The first example in the VDB docs creates a grid and names it "LevelSetSphere" so I thought this would be interpreted as the name of the volume and that it could be anything. I'll change it to "density".

Quote
I've now got the scene up to the point where the shadow works! The density on the pyro shader had to be reduced to 0.2 and then it was all go. More images attached. There's a slight offset in shadow position.

Nice! Strange that the density multiplier is a seemingly arbitrary value. There seem to be some other differences besides the slight offset in position. The denser parts of the cloud seem denser in your render. Is there a slightly lower density that makes the denser parts look closer to mine? Maybe 0.1?

Matt
Title: Re: VDB workflow testing
Post by: Matt on June 20, 2018, 07:18:04 PM
Quote from: paq on June 20, 2018, 09:32:05 AM
So I have a first setup in place, done by hand has Clarisse don't load .FBX.
Scaling is right (it's a 10Km large scene).

Great to see that this loads and renders in the right place :)

Quote
Direct light exposure is set on 1.5, and I have an env.light on -3 (???)

To test shadow density can you render it without any environment light or GI, just a direct light overhead? It looks like you might need to increase the ray march quality (reduce the step length?)

I do want to see full lighting tests, but it's really useful to have a render that calibrates the basic density without other lighting complications.

Quote
With the a default volume shader settings, and the overall density reduce to 50%, it looks more like smoke than cloud. I'll post the scene on Isotropix web site (may I Matt ?), because I'm really curious what kind of trick we could use to get a proper cloud look  8)

Absolutely, by all means :)
Title: Re: VDB workflow testing
Post by: paq on June 20, 2018, 08:28:17 PM
Hi Mat,

So here's the black cloud, and the shadow.
No gi, Direct Light Exposure : 1.67 (default is 0)
For the 4 zone I have : 4.7%, 17.8 %, 35.4 %, 72%

@density of the VDB is 0.15 (default 1)

I don't see any ray march quality or step length with VDB, only a quality in % for the Camera, reflection, refraction, shadow and GI.
All is set at 100% quality (default 50%)
Title: Re: VDB workflow testing
Post by: sboerner on June 20, 2018, 11:47:01 PM
Black cloud and shadow in Maya with Arnold.

Directional light intensity: 4
Volume Density: 0.003
Scatter Weight: 0
Transparent: 0.5/0.5/0.5
Everything else left at default.

The grid and vdb are scaled x100. Camera imports to the correct position.

For the 4 zones I have: 4.9%, 18.0%, 36.0%, 72.8%
Title: Re: VDB workflow testing
Post by: Matt on June 21, 2018, 01:21:29 AM
I've uploaded a new VDB to the same folder:

vdb_calib_01/scenes/vdb_calib_01_export_v003.vdb

This is named 'density' instead of 'Easy cloud 01'.

Does this solve the problem with visibility that some of you had with v001?

Matt
Title: Re: VDB workflow testing
Post by: ajcgi on June 21, 2018, 05:18:57 AM
Quote from: Matt on June 20, 2018, 06:59:13 PM
Nice! Strange that the density multiplier is a seemingly arbitrary value. There seem to be some other differences besides the slight offset in position. The denser parts of the cloud seem denser in your render. Is there a slightly lower density that makes the denser parts look closer to mine? Maybe 0.1?
Matt

I haven't had much of a play with the shader on the cloud itself yet, so that will be having some effect. I agree 0,2 is arbitary. I've tried 0.1 but that seems too light. Image attached.

I'll try the new vdb later on.
Title: Re: VDB workflow testing
Post by: ajcgi on June 21, 2018, 05:23:48 AM
I lied. I tried it now. Works immediately now Matt.
Title: Re: VDB workflow testing
Post by: pokoy on June 21, 2018, 07:27:24 AM
Ok - the 'vdb_calib_01_export_v003.vdb' works fine. It really seems Arnold expects some standard names for the channels of the vdb.
FYI - there's also a velocity channel included in the file (also in the first vdb file you posted) having the same channel name.

Test with 3dsmax and Arnold 1.2.926

Direct Visibility and Shadow
The strange thing is that the Arnold volume shader has a transparency parameter which is set to 0.3679 (0-1 space). With this value, density has to be at 0.18. The shader doesn't accept more than 2 decimal places so who knows what exact value needs to be, but it looks like a good match. Disabling transparency will result in a black cloud and shadow, so I've left this value where it was.
I thought it's meant to produce 0.5 in sRGB, but it seems to be an arbitrary value, if it's linear it should be 0,2176 to produce 0.5 in sRGB, if it's in 2.2 gamma it should be 0.7297 to produce 0.5 in linear space - no clue what the reasoning is behind this as a standard value.

Scattering/GI
This is where transparency controls everything again. If I want the cloud to look good I need to increase the value but then the shadow will be a lot lighter than in TG's example. The GI result further down is what comes out when rendered with the same shader that matches the diffuse/shadow render.

I guess it all comes down to how volumetrics work in Arnold, there's no simple way to achieve the same results for diffuse/shadow and GI.
General light intensity has to be around 1.68 to produce a close match to TG's exposure/brightness.

vdb_calib_01_black_cloud_no_shadows---3dsmax_Arnold---Density-0.18.jpg

[attachimg=1]


vdb_calib_01_shadow_of_black_cloud---3dsmax_Arnold---Density-0.18.jpg

[attachimg=2]


vdb_calib_01_white_cloud_with_gi---3dsmax_Arnold---Density-0.18.jpg

[attachimg=3]

Going to test with 3dsmax and Corona next, either today or tomorrow.
Title: Re: VDB workflow testing
Post by: pokoy on June 21, 2018, 10:08:38 AM
Also, after playing with the VDB trying to get a decent cloud look, I have to say that TG renders clouds way better than anything I've seen from Arnold and Corona so far. Way more realistic and surprisingly not much slower, even faster with higher GI bounces. Well done ;)
Title: Re: VDB workflow testing
Post by: sboerner on June 21, 2018, 11:38:45 AM
QuoteI've uploaded a new VDB to the same folder:

vdb_calib_01/scenes/vdb_calib_01_export_v003.vdb

This is named 'density' instead of 'Easy cloud 01'.

Does this solve the problem with visibility that some of you had with v001?

Thanks, Matt. The new VDB works well.

QuoteDirect Visibility and Shadow
The strange thing is that the Arnold volume shader has a transparency parameter which is set to 0.3679 (0-1 space). With this value, density has to be at 0.18. The shader doesn't accept more than 2 decimal places so who knows what exact value needs to be, but it looks like a good match. Disabling transparency will result in a black cloud and shadow, so I've left this value where it was.
I thought it's meant to produce 0.5 in sRGB, but it seems to be an arbitrary value, if it's linear it should be 0,2176 to produce 0.5 in sRGB, if it's in 2.2 gamma it should be 0.7297 to produce 0.5 in linear space - no clue what the reasoning is behind this as a standard value.

Scattering/GI
This is where transparency controls everything again. If I want the cloud to look good I need to increase the value but then the shadow will be a lot lighter than in TG's example. The GI result further down is what comes out when rendered with the same shader that matches the diffuse/shadow render.

I guess it all comes down to how volumetrics work in Arnold, there's no simple way to achieve the same results for diffuse/shadow and GI.
General light intensity has to be around 1.68 to produce a close match to TG's exposure/brightness.

I'm curious why my Density setting for the Arnold volume shader has to be so much smaller to produce the same result (0.003 vs. your 1.68). Setting it to 1.68 here gives me a solid black cloud. I've matched your transparency setting (0.368 on my system) and that works fine. Tonight I'll mess around with the Scatter and Transparent settings to see if I can get some natural looking clouds. (So far I've left Scatter Weight at 0 to replicate the black cloud and shadow.)

I'm using Arnold Core 5.0.2.4, not sure if that makes a difference.


Title: Re: VDB workflow testing
Post by: pokoy on June 21, 2018, 11:46:30 AM
Quote from: sboerner on June 21, 2018, 11:38:45 AM
I'm curious why my Density setting for the Arnold volume shader has to be so much smaller to produce the same result (0.003 vs. your 1.68). Setting it to 1.68 here gives me a solid black cloud. I've matched your transparency setting (0.368 on my system) and that works fine. Tonight I'll mess around with the Scatter and Transparent settings to see if I can get some natural looking clouds. (So far I've left Scatter Weight at 0 to replicate the black cloud and shadow.)

I'm using Arnold Core 5.0.2.4, not sure if that makes a difference.
Not sure but maybe units make a difference here. I've set my scene to work in meters and the plane is 10km as in the original TG scene, if you have different settings in your scene it could make a difference. I may have to update Arnold, actually I'm seeing that a new version is out. But honestly, the volume object support in Max is a bit basic, so maybe they've messed up how vdb files import and render, I guess the implementation in Maya is much more solid.

Update - I see in your post that your vdb is scaled x100, maybe that's why.
Title: Re: VDB workflow testing
Post by: sboerner on June 21, 2018, 11:54:44 AM
The VDB and grid both came in at 100m on import, so I had to scale them to 10km. I'll remove the scaling to see what difference that might make. Good thought, thanks.

My understanding is that there were some significant changes between Arnold 4 and 5. Many of the shaders were also updated. So maybe that's making a difference, too.
Title: Re: VDB workflow testing
Post by: pokoy on June 21, 2018, 12:06:17 PM
Quote from: sboerner on June 21, 2018, 11:54:44 AM
The VDB and grid both came in at 100m on import, so I had to scale them to 10km. I'll remove the scaling to see what difference that might make. Good thought, thanks.

My understanding is that there were some significant changes between Arnold 4 and 5. Many of the shaders were also updated. So maybe that's making a difference, too.

Just had a look, I'm on 5.0.2.4 too, there's a new plugin/bridge version but I doubt it will make a difference. Will update and repeat the test, though.
Title: Re: VDB workflow testing
Post by: paq on June 21, 2018, 12:10:05 PM
Quote from: pokoy on June 21, 2018, 10:08:38 AM
Also, after playing with the VDB trying to get a decent cloud look, I have to say that TG renders clouds way better than anything I've seen from Arnold and Corona so far. Way more realistic and surprisingly not much slower, even faster with higher GI bounces. Well done ;)

Yop, Terragen clouds looks amazing, and I really hope I will lean some tricks in this topic to enhance the result in Clarisse ... (I think Clarisse and Arnold are pretty close)


[attachimg=1]
Here's a test using the density channel as emitter (thanks to Démian from Isotropix). It's allready better than the default smoke look I had, but clouds are now self emitter :(

@Matt isn't any other possible data that you could generate in the .vdb that "we' could use to enhance the lack of inside scattering in our test ?

Quoting a reply from mdkay (Clarisse forum)

how does the shader (sic) fake the extra lightboost..

The volume shader in clarisse can mimic these phenomena with the scatter value for forward or backward transmission. But that value is static through the entire medium unless a property is provided to multiply it with.
Something like a SDF value which gives a value how close a point is to the surface of the vdb ...
Something Matt sure can add..otherwise a run with Houdini would help as well.



But in the other hand, I couldn't resist to render  the VDB in a 'real' scenario, and for a 5Mb file, it's not that bad at all  8) ...

[attachimg=2]
Title: Re: VDB workflow testing
Post by: pokoy on June 21, 2018, 12:14:05 PM
Great result! Yeah that emitter thing was the only way to get something usable in Arnold for me, too. In Corona I could set up a realistic density/absorption combo but still, TG looks better. It's close to impossible to get any details, it all looks very fluffy most of the time with Arnold/Corona.
Title: Re: VDB workflow testing
Post by: KlausK on June 22, 2018, 11:33:39 AM
Hi,
this is a LightWave 2018.3 render right out of the box.
But it is not really done according to Matts rules.
So, don`t look at it this way.
I was simply curious what would come out at all without using a 3rd party render engine which seems to be the thing to do to these days.

- the small picture shows how LW imports the fbx and the vdb file here with LWs default settings for the vdb.
- I repositioned the camera
- moved the vdb a little bit closer to the front edge of the plane
- turned of off the luminosity on the plane - I guess I wasn`t meant to do so
  (took me a while til I noticed that. Wondering, why the heck I couldn`t get shadows on the plane...doh)
- that is why the small plane is in the front right right. Forgot to take it out again.

- lightsource is a distant light pointing straight down, intensity 3.14lx, no falloff

- the vdb is loaded into a null obj set to OpenVDB Primitive type
- emission channel set to density (LW read that from the file)
- scattering channel set to density also
- absorbtion channel not used
- scattering scale on both channels set to 0.01
- step size set to 1m
- interpolator was set to quadratic

The rendering took about 45 minutes on my machine.

CHeers, Klaus
Title: Re: VDB workflow testing
Post by: pokoy on June 22, 2018, 02:24:53 PM
I finished a batch of renders from 3dsmax with Corona (v2 release candidate 4)

Density had to be set to 2.5 to match TGs output.
With GI enabled, I finally had some success to get something that looks close to TG. Corona simulates anisotropic scattering, by using values from 0.6 to 0.85 (forward scaterring) it finally looked more like clouds instead of a white or gray mass. It was surprising to see that not even 10 GI bounces were enough to get a convincing look so I left it the default limit which is 25. A render with
constant scattering direction at 0.825 is attached.

Using the vdb density channel as scattering input instead of constant and a custom gradient on the output curve I came very close to the GI render from TG but it took to long to render, I'll try to play around with the options another time.


vdb_calib_01_black_cloud_no_shadows---3dsmax_Corona---Density-2.5.jpg

[attachimg=1]


vdb_calib_01_shadow_of_black_cloud---3dsmax_Corona---Density-2.5.jpg

[attachimg=2]


vdb_calib_01_white_cloud_with_gi---3dsmax_Corona---Density-2.5_ScatterDir-0.825.jpg

[attachimg=3]


For comaprison - with isotropic scattering direction (uniform light scattering in all directions) the volume looks all white:
vdb_calib_01_white_cloud_with_gi---3dsmax_Corona---Density-2.5_ScatterDir-0.0.jpg

[attachimg=4]


In conclusion, I don't see a reason why the density exported from TG should be changed, we all seem to get good results with it and looking at how differently the density is interpreted depending on the renderer it's hard to say whether the density from TG is off or not.

Matt, would it be possible to get a vdb file with more detail?  ;D

Thanks for the interesting challenge btw, it helps to understand how different media affect scattering direction in light, very interesting stuff.
Title: Re: VDB workflow testing
Post by: Oshyan on June 22, 2018, 05:04:23 PM
It would be interesting to know your render times on any tests that are trying to reproduce the TG cloud scattering.

- Oshyan
Title: Re: VDB workflow testing
Post by: Matt on June 22, 2018, 07:59:06 PM
Quote from: pokoy on June 21, 2018, 07:27:24 AM
FYI - there's also a velocity channel included in the file (also in the first vdb file you posted) having the same channel name.

I guess this is a 3dsmax thing because I only write one grid to the file and it's called 'density' now.

Quote
The strange thing is that the Arnold volume shader has a transparency parameter which is set to 0.3679 (0-1 space). With this value, density has to be at 0.18. The shader doesn't accept more than 2 decimal places so who knows what exact value needs to be, but it looks like a good match. Disabling transparency will result in a black cloud and shadow, so I've left this value where it was.
I thought it's meant to produce 0.5 in sRGB, but it seems to be an arbitrary value, if it's linear it should be 0,2176 to produce 0.5 in sRGB, if it's in 2.2 gamma it should be 0.7297 to produce 0.5 in linear space - no clue what the reasoning is behind this as a standard value.

0.3679 ~= e^-1

This factor makes sense considering how density is usually converted to transparency: transparency = exp(-density * distance). Technically you shouldn't need a parameter like this if you also have a density multiplier (the transparency could be hardcoded at 0.3679), but I can see how it might be more intuitive to set coloured transparency this way. I don't know why the density multiplier needs to be 0.18, but I guess it might be scaled that way for backward compatibility reasons.

Quote
Scattering/GI
This is where transparency controls everything again. If I want the cloud to look good I need to increase the value but then the shadow will be a lot lighter than in TG's example. The GI result further down is what comes out when rendered with the same shader that matches the diffuse/shadow render.

I guess it all comes down to how volumetrics work in Arnold, there's no simple way to achieve the same results for diffuse/shadow and GI.
General light intensity has to be around 1.68 to produce a close match to TG's exposure/brightness.

What scattering/albedo controls does it have?

Matt
Title: Re: VDB workflow testing
Post by: Matt on June 22, 2018, 08:29:32 PM
Quote from: paq on June 21, 2018, 12:10:05 PM
Here's a test using the density channel as emitter (thanks to Démian from Isotropix). It's allready better than the default smoke look I had, but clouds are now self emitter :(

@Matt isn't any other possible data that you could generate in the .vdb that "we' could use to enhance the lack of inside scattering in our test ?

Quoting a reply from mdkay (Clarisse forum)

how does the shader (sic) fake the extra lightboost..

The volume shader in clarisse can mimic these phenomena with the scatter value for forward or backward transmission. But that value is static through the entire medium unless a property is provided to multiply it with.
Something like a SDF value which gives a value how close a point is to the surface of the vdb ...
Something Matt sure can add..otherwise a run with Houdini would help as well.


In the past, Terragen faked the internal scattering according to the density function, and we had "fake internal scattering" parameters to control that. But that was in Cloud Layer V2. Now in Cloud Layer V3 and Easy Cloud it isn't faked, it's calculated by scattering rays through the voxels using principles from physically based rendering, although I do cache a few things and take some shortcuts to make it faster than a properly unbiased method. A good physically based volume shader should be able to do the same, if it has a good phase function and enough scattering events (or bounces). Terragen's cloud shader is optimised to approximate hundreds of scatters within the same volume, but has a limited number of bounces between separate cloud layers (or between cloud layers and surfaces) where this optimisation isn't used (although this might be added in future).

Matt
Title: Re: VDB workflow testing
Post by: Matt on June 22, 2018, 08:53:20 PM
Quote from: pokoy on June 22, 2018, 02:24:53 PM
I finished a batch of renders from 3dsmax with Corona (v2 release candidate 4)

Density had to be set to 2.5 to match TGs output.
With GI enabled, I finally had some success to get something that looks close to TG. Corona simulates anisotropic scattering, by using values from 0.6 to 0.85 (forward scaterring) it finally looked more like clouds instead of a white or gray mass. It was surprising to see that not even 10 GI bounces were enough to get a convincing look so I left it the default limit which is 25. A render with
constant scattering direction at 0.825 is attached.

This looks great. What does it look like if you increase this parameter to 0.99, or even 1.0 if that works?

Quote
Using the vdb density channel as scattering input instead of constant and a custom gradient on the output curve I came very close to the GI render from TG but it took to long to render, I'll try to play around with the options another time.

You shouldn't need to fake it like that. It looks like Corona is already doing a good job with this, and maybe it just needs to be tweaked a bit more. My TG render might be a little too dark at the edges. I just used the defaults.

Matt
Title: Re: VDB workflow testing
Post by: Matt on June 23, 2018, 12:53:25 AM
Quote from: Matt on June 22, 2018, 08:29:32 PM
In the past, Terragen faked the internal scattering according to the density function, and we had "fake internal scattering" parameters to control that. But that was in Cloud Layer V2. Now in Cloud Layer V3 and Easy Cloud it isn't faked, it's calculated by scattering rays through the voxels using principles from physically based rendering, although I do cache a few things and take some shortcuts to make it faster than a properly unbiased method. A good physically based volume shader should be able to do the same, if it has a good phase function and enough scattering events (or bounces). Terragen's cloud shader is optimised to approximate hundreds of scatters within the same volume, but has a limited number of bounces between separate cloud layers (or between cloud layers and surfaces) where this optimisation isn't used (although this might be added in future).

To be fair, TG's scattering isn't physically correct for a few reasons. There's a sort of transition between voxel-level scattering and scattering done with the high resolution density function. Different parts of the phase function are handled separately in order to get a high quality result fast. The ways some of these things are merged aren't exactly physically correct. The phase function used for direct visibility to the camera is based on the non-physically based paramers "sun glow amount" and "sun glow power" which gives the artist a lot of control over the silver lining and dark edges, while the higher order scattering which works at the voxel level uses a couple of extra parameters which also are only loosely physically based ("softness" and "param C"). Energy is preserved, but only approximately. How radically this deviates from a purely physically based solution probably depends on the chosen parameters, but scattering parameters are uniform throughout the volume so there's no explicit attempt to cheat the brightness in the cloud centres at all - the brightness emerges naturally due to the larger number of paths that connect the sunlight to the camera.

Matt
Title: Re: VDB workflow testing
Post by: pokoy on June 25, 2018, 09:10:50 AM
Thanks for the explanation, Matt, this helps to understand the differences. I guess you are also querying the noise function for some visual non-physical shortcuts, that's probably why I couldn't get the small details to be as prominent as in TG's render with Corona.

Totally missed that forward scattering has been already mentioned in the post with results from Clarisse.
I will do a render with a direction coef of 0.99 (the range goes from -0.99 to 0.99 for this parameter in Corona) but from the tests I did I recall that the outer boundaries of the cloud would render too dark since light is not scattered towards the viewer unless you happen to look at the light source 'through' the cloud.
What's interesting is that the silver lining effect is nicely visible with values from 0.5 - 0.7. Since this gives realistic results for the silver lining I think that's the range this parameter has to be set to. This also explains why TG features a separate sun glow section for clouds, it would be probably hard to control the silver lining in a realistic way if it was only density and scatter parameters.

Also, in order to get the cloud to receive any light on the bottom in the thicker areas a lot of GI bounces are needed. I can go as far as 100 in Corona (or completely unbiased) but that will take really long. My tests were done with 25 bounces, anything below that just weren't enough, and it's quite noisy too. I wonder how many bounces TG does for light scattering within the cloud.

The transparency in Arnold - interesting to see the 'scientific' reasoning behind that value. I find the controls a bit too arbitrary though but will try to get something more usable. I guess it will be very noisy and slow since scattering bounces need to be increased a lot for clouds.
Title: Re: VDB workflow testing
Post by: ajcgi on June 25, 2018, 11:58:15 AM
That's all interesting info.  :D Hopefully I can take another look at this in Houdini over the next couple of days. Btw, I think the default FBX settings within Houdini probably interpreted metres as something else and went haywire with the scaling. I'll check that too once I get around to it. Need the clock cycles for TG rendering today, funnily enough.  ::)
Title: Re: VDB workflow testing
Post by: pokoy on July 03, 2018, 12:00:57 PM
Matt, you asked for a render with scattering direction at maximum (0.99) from Corona, here it is:

[attachimg=1]

I can do a progression render from 0.0 to 0.99 (in 0.1 steps) when I'm back from holidays if it's helpful.
Title: Re: VDB workflow testing
Post by: pokoy on July 04, 2018, 11:34:50 AM
I had some free time, here's the progression from 0.0 to 0.99 for scattering direction. It's interesting how much this affects the cloud's look.

Update - I zipped the GIF file, for some reason it didn't play the animation.
Title: Re: VDB workflow testing
Post by: pokoy on July 04, 2018, 11:59:47 AM
This just in: Disney released a detailed cloud VDB for research and testing purposes.

Link: https://www.disneyanimation.com/technology/datasets (https://www.disneyanimation.com/technology/datasets)
PDF description of the cloud file: https://disney-animation.s3.amazonaws.com/uploads/production/data_set_asset/1/asset/Cloud_Readme.pdf (https://disney-animation.s3.amazonaws.com/uploads/production/data_set_asset/1/asset/Cloud_Readme.pdf)

I guess it's particularly interesting for Matt in order to see how a Disney-standard cloud VDB looks like (and to have a nice visual example of the rendered result from their Hyperion renderer).
Title: Re: VDB workflow testing
Post by: ajcgi on July 04, 2018, 12:20:33 PM
Quote from: pokoy on July 04, 2018, 11:34:50 AM
I had some free time, here's the progression from 0.0 to 0.99 for scattering direction. It's interesting how much this affects the cloud's look.

Is this animated? It's static on my work machine at least. Chrome and IE. Win7
Title: Re: VDB workflow testing
Post by: pokoy on July 04, 2018, 12:23:10 PM
Quote from: ajcgi on July 04, 2018, 12:20:33 PM
Quote from: pokoy on July 04, 2018, 11:34:50 AM
I had some free time, here's the progression from 0.0 to 0.99 for scattering direction. It's interesting how much this affects the cloud's look.

Is this animated? It's static on my work machine at least. Chrome and IE. Win7

I just updated the original post with a zip of the GIF file, that should work.
Title: Re: VDB workflow testing
Post by: ajcgi on July 04, 2018, 12:27:25 PM
Ah brill. Thanks. Looks good. I have a very rudimentary knowledge of Houdini's Pyro shader so I'll run the scene past a colleague at some point and see if we can figure something out. Defaults are very flat, like the end of your GIF there.
Title: Re: VDB workflow testing
Post by: SILENCER on July 06, 2018, 09:53:44 AM
A little time opened up at work yesterday, so we slugged both the Terragen and newly released Disney VDB files into Octane for LW 2018. Rendered on an array of 14 GTX TitanX cards.

The Terragen file smacked right into place. Looked a little muddy at first. Honestly I don't have a lot of VDB experience since I usually just do cloud stuff in TG.

However, that Disney one was crazy. It took the adjustment parameters from Octane's medium handler like a boss. Looked great right out of the box.

I'll go back to the TG file today and try to dial it in to look right. With the job we're doing currently, VDB from Terragen would be a gigantic WIN.
Title: Re: VDB workflow testing
Post by: pokoy on July 06, 2018, 09:57:34 AM
Same here, can't wait to have the vdb export available in TG.

Could you post a result of the Disney cloud file? I'm experimenting with Corona right now, and while it does look quite good the Hyperion render is out of competition so far.
Title: Re: VDB workflow testing
Post by: SILENCER on July 09, 2018, 12:02:29 PM
pokoy:

Can't let anything out of the building. The show is in lockdown. But the Disney VDB is a monster, even at half rez.


However, a new Terragen VDB of some colossal culumus would be the bomb, should Matt care to output another run.
Title: Re: VDB workflow testing
Post by: Suppybird on July 10, 2018, 05:55:44 AM
Can someone tell me how tp appear the images ?
Title: Re: VDB workflow testing
Post by: Suppybird on July 10, 2018, 06:04:51 AM
Can someone tell me how tp appear the images ?
Title: Re: VDB workflow testing
Post by: ajcgi on July 10, 2018, 12:44:07 PM
[attach=1]

Do this. Hit 'more attachments' and do it again.
Title: Re: VDB workflow testing
Post by: Suppybird on July 11, 2018, 01:38:52 PM
Please release VDB exporter Immedially. The artist always get headache when making cloud for VFX, and I'm very tired of Houdini's cloud. This is my Terragen cloud's rendered by Arnold For Cinema 4D and Clarisse. Arnold is the most unbiased renderer sp It's not cheat. and because it's not cheat so need 50 bounce and the result is very realistic. Volumetrics in Clarisse is not completely unbised so have to cheat.


So, I must say again. Hey Matt, please ! Release the tool right now. Thank you !
Title: Re: VDB workflow testing
Post by: WAS on July 22, 2018, 02:50:28 AM
Quote from: Suppybird on July 11, 2018, 01:38:52 PM
Please release VDB exporter Immedially. The artist always get headache when making cloud for VFX, and I'm very tired of Houdini's cloud. This is my Terragen cloud's rendered by Arnold For Cinema 4D and Clarisse. Arnold is the most unbiased renderer sp It's not cheat. and because it's not cheat so need 50 bounce and the result is very realistic. Volumetrics in Clarisse is not completely unbised so have to cheat.


So, I must say again. Hey Matt, please ! Release the tool right now. Thank you !

Oh those look nice! I miss C4D, I have Release 8 (I believe it is)  somewhere in it's box. Is Houdini compatible with those older versions?
Title: Re: VDB workflow testing
Post by: freedomfries on September 24, 2018, 05:08:03 PM
I'm interested in trying Renderman 22 for Maya...

Besides clouds in the sky, might we be able to create .vdb elements for things like cloud nebulae? Would be pretty sweet.
Title: Re: VDB workflow testing
Post by: Matt on September 24, 2018, 06:15:00 PM
As long as it's made with a cloud layer and "localise" is enabled, its density field will be exportable to VDB.
Title: Re: VDB workflow testing
Post by: Suppybird on September 25, 2018, 08:25:28 PM
Quote from: WASasquatch on July 22, 2018, 02:50:28 AM
Quote from: Suppybird on July 11, 2018, 01:38:52 PM
Please release VDB exporter Immedially. The artist always get headache when making cloud for VFX, and I'm very tired of Houdini's cloud. This is my Terragen cloud's rendered by Arnold For Cinema 4D and Clarisse. Arnold is the most unbiased renderer sp It's not cheat. and because it's not cheat so need 50 bounce and the result is very realistic. Volumetrics in Clarisse is not completely unbised so have to cheat.


So, I must say again. Hey Matt, please ! Release the tool right now. Thank you !

Oh those look nice! I miss C4D, I have Release 8 (I believe it is)  somewhere in it's box. Is Houdini compatible with those older versions?

Ofcourse no :)) . But you should the newest version, too powerful, most easy to use, very insance comfortable .  When Terragen OpenVDB is released, you can play it with anyshape easily inside Cinema 4D newest version.
Title: Re: VDB workflow testing
Post by: Macao on January 11, 2019, 05:22:55 PM
Looks brilliant, can't wait for that update !
Title: Re: VDB workflow testing
Post by: Oshyan on January 11, 2019, 05:30:48 PM
OVDB export is available now in the latest 4.3 release, though it only works on Linux (and thus is only available with a Professional license).

- Oshyan
Title: Re: VDB workflow testing
Post by: Suppybird on February 15, 2019, 03:25:08 AM
Have any news about VDB exporter for Window?
Title: Re: VDB workflow testing
Post by: Oshyan on February 15, 2019, 04:01:19 PM
No update on the Windows version. When it is available we will definitely let everyone know.

- Oshyan
Title: Re: VDB workflow testing
Post by: D.A. Bentley (SuddenPlanet) on February 18, 2019, 08:05:35 PM
I found this today (It could be useful for testing / research):
https://www.technology.disneyanimation.com/clouds (https://www.technology.disneyanimation.com/clouds)
Title: Re: VDB workflow testing
Post by: Oshyan on February 19, 2019, 04:35:16 PM
Yes, when we get to VDB import we'll almost certainly test that data. Very curious to see how that cloud renders in Terragen. :D

- Oshyan
Title: Re: VDB workflow testing
Post by: D.A. Bentley (SuddenPlanet) on February 22, 2019, 06:21:29 PM
Hi Oshyan / Matt,

I wanted to get some more clarification on what settings affect VDB Exports. 

I know most of the settings are on the Optimisation / Optimization tab of the cloud, but the size of the cloud affect the voxel buffer size too (Cloud depth, Radius).
Are there any other settings that can alter the voxel buffer size?

What about the "Accelerate empty space"?

What about "Transition dist. (voxels)" which has a default value of "8"?

Thanks,

-Derek

Title: Re: VDB workflow testing
Post by: Oshyan on February 22, 2019, 10:16:47 PM
Matt is away for the weekend, but I'll do my best to answer, within what I know, and he can clarify/correct when he gets back.

The size or depth of the cloud doesn't generally change the number of voxels, which is what I would call the "voxel buffer size" (the "size" being the size of the buffer as a whole, rather than individual voxels). It does change how they're distributed, i.e. what size each voxel is (how much area each voxel covers), so perhaps that's what you mean. If you want to maintain detail while increasing cloud depth or area of coverage, you need to increase voxel count. You can see these values for x, y, z voxel distribution updated beneath the voxel count slider, and it is affected by cloud depth, etc.

Transition Distance only applies to using voxels for shadows, which doesn't affect VDB export as far as I'm aware.

I'm not sure about Accelerate Empty Space, but I would guess it has no effect for VDB export. My understanding is this just limits cloud visibility calculations to the voxel area, but the VDB export *only* exports the voxels, so on or off shouldn't make a difference as far as I can imagine. But I've been wrong before. ;)

- Oshyan
Title: Re: VDB workflow testing
Post by: D.A. Bentley (SuddenPlanet) on February 23, 2019, 11:14:48 AM
Thanks Oshyan!

One other thing I wanted to ask is if it is possible to make -exportvdb work with the -f frame ranges like it does with rendering images?

I have been animating certain cloud settings to get different cloud shapes (mainly the seed value) so for example I set my frame range in Terragen from 1-256, and animate the seed with a linear curve from 1-256 as well, so at frame 79 I am going to be exporting the cloud with seed 79.

Currently I have been making a batch file / shell script (.sh) with each line in the .sh file specifying the .tgd file and commands to export one .vdb file.
In doing this I have to manually save out each .tgd at the frame I want exported.  When exporting hundreds of little vdb clouds this takes awhile.

So it would be nice if I could just do something like this instead:
./terragen -p project.tgd -exportvdb "Easy Cloud 01" output.vdb -f 1-56, 61,62,89, 111-189, 253,255

That way I could do everything I have been doing but just working with one .tgd file.

Lastly, if this is possible and I isn't too much to ask would it also be possible to add a voxel override switch to specify the millions of voxels to use?
./terragen -p project.tgd -exportvdb "Easy Cloud 01" output.vdb -voxels 800 -threads 8 -frames 1-100, 256

Just some ideas.  :)  I have found using Notepad++ can help me with some of this when having to work with hundreds of separate .tgd files, but it sure would be handy to have these two additional command line switches.

Thanks,

-Derek
Title: Re: VDB workflow testing
Post by: paq on February 23, 2019, 11:33:39 AM
Hehe Matt is aware for this 2 requests  8)

For the second question I copy/paste his reply (hope he doesn't mind)

You can set the frame in the command line using the -f argument, in the same way you would if you're rendering a frame. That will get you a different point in the animation. However, the cloud filename doesn't know about file sequences, so you'll need to declare the number in the filename. If you're able to script something, you could write a loop to generate the filenames and execute Terragen with the -f argument. However, I don't know how stable the output will be in a sequence.

Didn't had the time yet to try that script suggestion.
Title: Re: VDB workflow testing
Post by: amandas on June 10, 2020, 10:21:04 AM
Quote from: D.A. Bentley on February 23, 2019, 11:14:48 AMThanks Oshyan!

One other thing I wanted to ask is if it is possible to make -exportvdb work with the -f frame ranges like it does with rendering images?

I have been animating certain cloud settings to get different cloud shapes (mainly the seed value) so for example I set my frame range in Terragen from 1-256, and animate the seed with a linear curve from 1-256 as well, so at frame 79 I am going to be exporting the cloud with seed 79.

Currently I have been making a batch file / shell script (.sh) with each line in the .sh file specifying the .tgd file and commands to export one .vdb file.
In doing this I have to manually save out each .tgd at the frame I want exported.  When exporting hundreds of little vdb clouds this takes awhile.

So it would be nice if I could just do something like this instead:
./terragen -p project.tgd -exportvdb "Easy Cloud 01" output.vdb -f 1-56, 61,62,89, 111-189, 253,255

That way I could do everything I have been doing but just working with one .tgd file.

Lastly, if this is possible and I isn't too much to ask would it also be possible to add a voxel override switch to specify the millions of voxels to use?
./terragen -p project.tgd -exportvdb "Easy Cloud 01" output.vdb -voxels 800 -threads 8 -frames 1-100, 256

Just some ideas.  :)  I have found using Notepad++ can help me with some of this when having to work with hundreds of separate .tgd files, but it sure would be handy to have these two additional command line switches.

Thanks,

-Derek

Definitely upvoting voxel switch pushed to the commandline, as well as overrides for localization.