Learning OpenVDB Lightwave 2019

[starbase1]

I've decided to have another run at getting my head around Lightwave 2019, particularly tempter by OpenVDB this time around, which definitely looks like it plugs a gap in my volumetric armoury.

But where to start?

The few sample scenes are not much help at all - is there any structured training out there? (Including paid for)? Any more sample scenes available to download?

Nick

[prometheus]

Depends on which VDB tool you wan´t to start with?
Volumes, meshing etc? gas solver, particles etc?

Check some of Olivers tutes to get started..
https://www.youtube.com/user/Officia...arch?query=vdb

Then you have some paid ones on Liberty3D, which deals with both standard volumes (primitive item volume mode) and vdb creation..don´t know anything about wether or not they are good though.
https://www.liberty3d.com/2019/08/ne...nus-tutorials/

For some other basics and gas solver, there are threads here and there on the forum where I have added some info.

[Areyos Alektor]

Yes these are good starting points and do not forget the documentation:
https://docs.lightwave3d.com/lw2019/...lation/openvdb

[starbase1]

I've bought the first Liberty 3d tutorial, and have tried others...

I'm getting cool results, but I'm nowhere near in control!!!

I've got one cool scene based on a end on view of a supplied fireball scene, could make a good exploding star.
Is there a straightforward way to slow down the simulation speed? For example, so it develops at 1/5th the rate?

Cheers,
Nick

[starbase1]

https://www.youtube.com/watch?v=lelY...ature=youtu.be

Here's the results of the end on view of the fireball I mentioned.

Rather cool, though as I said, I'd like to slow it down

[prometheus]

https://www.youtube.com/watch?v=lelY...ature=youtu.be

Here's the results of the end on view of the fireball I mentioned.

Rather cool, though as I said, I'd like to slow it down

Is that really how an unstable star would look like? red dwarf shooting flares? or a gamma burst? gamma burst would be directional from poles I think.
And we really have to get the terms right here don´t we?
Talking about a fireball, that is associating to scale around a soccerball, stars..a different association of scale

As for your question..
I think TurbulenceFD has a time scale controller, while the VDB gas solver hasn´t..so don´t think that is possible yet other than postprocessing.
I couldn´t find nodes or functions in there to adjust time slowing down anyway.

What you could do is to use the envelopes for some of the channels, the texture channels seem to be poorly implemented as they have no other gradient than previous layer,, maybe by hacking
and adding the procedural texture node editor and enter nodes that way for the temperature channel for instance, then add a scalar layer with distance to object, if it could work I do not know, just tried it with Dpont´s scalar + layer, and it just crashed, so not gonna spend much time on that.

So you are left with envelopes, but that would be hard in terms of slowing down the end.
I haven´t checked out all the options though, may be possible with nodal control of air temp, or forces.

O by the way, one option and suggestion..as I have been using that every now and then, instead of full mesh fluid control of the velocity, you could use a particle emitter shooting out from various places, could be a multimesh with tiny surface parts around the main mesh star, or by emitting particles from points.
But you do not plug it by using particles as fluid generator/emitter, you simply just use the particles velocity fed in to the fluid mesh force input, this means the initial velocity of the fluid will be in the direction that the particles take, and also will slow down based on particle velocity I think, so that is one way that could make the fluid slow down in the end, this approach means it just adapt the velocity direction and speed since it is a force, but it will not let you inherit the particles full trajectory, just the force velocity.


I used particles in to the force grid here, (tested blender to render though after exporting VDB, but you can see in the end a wire anim how the particles are shooting out and the fluids using it´s force to adapt.
Sample is too low in resolution though for any serious "good" work.




For full trajectory you would have to use particles as the fluid emitter itself, which then could yield blobs as a drawback.

[prometheus]

Here´s the nodal setup(not from the sample above, just a fresh setup), particle settings rough, explosion set to 10 and increased particle resistance.
As you can see, no blobs determined by particle size, it only uses the velocity and particle scaling, to push the fluids from the gas solver.

I don´t think TurbulenceFD or even Blender has this feature to use particles as "Force input only"

Oops, while testing I routed this wrong, this screenshot is actually using the particle as source, I was fooling around and forgot to change some settings.
for the correct with only force as input, you need to have the mesh to volume source fed in to the source grid.

In this case, the actual particle emitters particle size values controls the size of the fluid around each particle.

[prometheus]

Correction of the nodal setup..



Also buoyancy is killed off, so the fluid doesn´t rise.

[starbase1]

It may take me a while to work through all that, thank you!

[starbase1]

A thought regarding pacing of the generated animation.

This stuff has a scale - by which I mean, if you size everything up, you don't just get a bigger version, you get something different.

One of the things I want to get the hang of is volcano smoke - and these small scale animations change much roo fast. Bt it occurs to me, if I make it bigger, it will take longer for the warm air, or whatever, to rise through the height of the object.

So I figure working at a larger scale should slow things down the way I want...

(Also on my todo list, increase the frame rate of the scene, and see if there's a smaller change per frame...)

[prometheus]

A thought regarding pacing of the generated animation.

This stuff has a scale - by which I mean, if you size everything up, you don't just get a bigger version, you get something different.

One of the things I want to get the hang of is volcano smoke - and these small scale animations change much roo fast. Bt it occurs to me, if I make it bigger, it will take longer for the warm air, or whatever, to rise through the height of the object.

So I figure working at a larger scale should slow things down the way I want...

(Also on my todo list, increase the frame rate of the scene, and see if there's a smaller change per frame...)

Yes, good to have thoughts on that, I need to check out the physics on this as well.
Clouds rise faster..higher with warm air, and less with cold air, how well this works within the properties of gas solver is something that needs to be covered.

As for Larger scale´s, yes, you could set up a smaller scale and larger scale and see how that goes with the same air temp, though larger scales means higher resolution and huge GB sets of cached VDB, and much much longer simulation times.
As for vulcano..did you check the latest demo of embergen, he demonstrates some new stuff and showcases a vulcano as well..just pure awesomeness being able to tweak and get feedback in pretty much realtime.
I must get hold of this someday, have to free some space..make some backups then start trying the trial, which you can save out VDB´s from within a 14 day trial, then try and render in Lightwave.

Check 53:21 in the clip when he opens and showcases the Vulcano, mostly talking about shadows in their render engine, while very nice and pretty much realtime rendering directly in embergen, the full quality of volume rendering is best served in another full path tracing PBR volumetric renderer, exported to Lightwave or octane, or what else is out there.

[prometheus]

By the way, didn´t you purchase some of the vdb tutorials from liberty3D? if you did, were they lacking coverage of these functions?

Also..the gas solver is very unstable in simulation prediction, it refuses to clear cache in memory properly, so you may tweak things just to realize they do not take effect because of that..and you think
it is the settings not working properly.

for instance, I can have a vector force set to pull the smoke to x direction, when I remove it..it still contains that vector force to the left..which is completely wrong, saving the scene and reloadin and it behaves as it should.

[starbase1]

By the way, didn´t you purchase some of the vdb tutorials from liberty3D? if you did, were they lacking coverage of these functions?

Also..the gas solver is very unstable in simulation prediction, it refuses to clear cache in memory properly, so you may tweak things just to realize they do not take effect because of that..and you think
it is the settings not working properly.

for instance, I can have a vector force set to pull the smoke to x direction, when I remove it..it still contains that vector force to the left..which is completely wrong, saving the scene and reloadin and it behaves as it should.

Yes, I bought the first one - progress is slow because I am trying styff out and the renders are not quick!

Also...
1. Just moved to a new country, and am settling in...
2. My main PC is refusing to boot, so fixing that is a priority!

[prometheus]

Yes, I bought the first one - progress is slow because I am trying styff out and the renders are not quick!

Also...
1. Just moved to a new country, and am settling in...
2. My main PC is refusing to boot, so fixing that is a priority!

Oki,
Yeah computer hassle is energy sucking.
So you moved where? and from?

[starbase1]

OK, a few things to cover here!

https://www.youtube.com/watch?v=ibtwbnZak20

Experiment with a modified supplied scene, (textures, lighting, added some movement)

But the big thing I did was to increase the frame rate in the scene, and then slowed the resulting video.
This seems a pretty good way of adjusting the pace of things! Not a perfect reproduction, but rather good.

Smaller steps also seemed to significantly reduce the calculation time per frame, which makes sense if it's an iterative process converging on a solution.

On the personal side, I've moved from London Uk, to Chisinau, Moldova!