maps in texture surface slot of vrayvolumegrid

[super gnu]

im playing with using procedurals to modify a volume grid. this has to be in isosurface mode to work at all, and there is no viewport preview.

however, even in this mode, while a simple procedural works in there, i want to blend from one procedural to another over the volume.

ive tried gradient ramp in object xyz mode, ive tried a gradient bitmap in the same mode, ive tried bercon gradient.

ive tried using the gradient as a mix map between 2 procedurals, ive tried putting the gradient in one of the texture slots inside a procedural..

nothing works.

if i put the same map in the diffuse texture for the volume, i get a reasonable result, although the mapping is fairly random and needs tweaking of tiling and offset to get a reasonable mapping. but in the texture surface slot, the -best- i can achieve, using really wierd (and different from the diffuse slot)) tiling and offset settings, is a solid transition from one procedural to the other.. not a fade.,

i see that uvw mapping (understandably) is not possible either, adding the modifier just kills the volume grid.

is there -any-way to do more advanced stuff than a single procedural in that slot? or control mapping over the volume?

[Svetlin.Nikolov]

Hello,

What look are you after? Do you have a cache that you want to modify, or do you want to render just the procedural? If it's the former, you should modulate the cache file using the texture maps in the Fire/Smoke options dialogue, otherwise if you want standalone procedural volumetrics, the V-Ray environment fog will do the job for you.

The texture input into the volume grid happens at fixed points, so anything more advanced is matter of transforming your maps before plugging them in - basically you can replace or modulate the emissive and opacity channels of a cache with a map, or use maps for displacement, which can be either 2D over a surface, or 3D vector/velocity displacement.

The surface texture has very limited use - in isosurface mode (mesh mode, ocean and cap will work too), the surface texture entirely replaces the data from the cache file. On the other hand, in the atmospheric modes, it only defines the surface over which you can apply 2D displacement (surface or gradient driven that is). I shut down the preview a while ago because it was causing issues - if you have nightly access, the preview will be back online in a couple of days.

The mapping is in object XYZ - if you put a box with the same size as the volume grid, it should work the same way. I'll have a look why the mapping differs between the atmospheric and the surface textures and will get back to you. I tried to reproduce your issue with both bercon gradient and gradient ramp here and couldn't break it, as long as the mapping is right - would it be possible for you to share a scene for investigation?

[super gnu]

of course, i will send you a scene.

the purpose is to render the procedural as geometry. . i was loading a simple cube VDB then using the texture surface slot, and cutter geometry to produce the form i wanted as a procedural isosurface. its a similar result to using vraymetaballs with a procedural, but a) it seems to render the isosurface *much* faster than vraymetaball, and b) it doesnt require messing around with particles in max.



see couple of attached test renders: these took a short while each. the one inside the rock like structure was admittedly an hour or two. the other more distant was only 5 minutes.





here is an attempt using vraymetaball that took 7 hrs to render.






the end result is a sponge or bread like structure. these types of materials are very hard to do in any way other than with isosurfaces.. displacement really doesnt cut it, and i cannot imagine vrayenv fog is a practical approach either. considering the slowness and reliance on particles of vraymetaball, vrayvolumegrid with a dummy vdb file is the only practical way to do this in vray.


specifically for this test i was trying to do a slice of bread, including crust. this would require an open cell structure for the centre of the bread, blending at the edges to something with a much finer porous structure. i had imagined using objectxyz, and a pair of cellular maps blended by a rectangular gradient ramp, or planar projected bitmap, to achieve the edge transition. however i have so far been unable to get any kind of working gradient blend between 2 procedural maps to work in that texture surface slot.


a couple of other things:

a) you mention this should also work in mesh mode? i cannot get "texture surface" to work at all in mesh mode.

b) you say preview is disabled but should work again soon.. does this include for "texture surface" mode? so i can adjust the procedurals and have proper viewport feedback? that would be amazing.

[Svetlin.Nikolov]

I see - well, then the preview is crucial - it's been down for the surface texture only. I will update you when it's working again - hopefully for tomorrow's nightly. All geometric modes should be working with the updated build as well - I found an issue that might have been causing the mesher to fail.

I wonder what to do with the box dimensions though - in Phoenix, you could regulate them by adjusting the grid size of the simulator, but with the volume grid you should either have a dummy cache only to be used for getting its box, or when the cache is absent, the box could be fixed in size and the size could be controllable by script. Note that the size in voxels determines how coarse will the procedural be when voxelized (the surface texture doesn't query the procedural during rendering, it splats it into a grid beforehand so all other render systems will work like with an aur/f3d/vdb cache).

[super gnu]

ahh ok! i assumed the procedural coarseness was controlled by the isosurface step size.. i have just been using this generic cube vdb and setting detail with step size. didnt see any obvious resolution limits... maybe the vdb was just high enough resolution that i didnt see this limit.. or are we referring to coarseness when using mesh mode/preview etc...


my dream (possibly not one of my actual dreams, i do have slightly more ambition) is to be able to choose a piece of geometry and fill it with a volumetric mesh like this.. in a couple of clicks kinda thing. there used to be a plugin called vrayiso back in the day, but it dissapeared. very useful for rock, plants, sponge, food etc etc.


being able to use volumegrid without a cache, so it automatically generates a box, and with a scriptable size/ resolution, might be a great compromise.. would be fairly trivial to then script an interface that creates a box based on the bounding box of your selected clipper geometry, and allows you to choose the detail level. and i dont even script!


the mesh mode ( assuming the detail can be cranked high enough without killing the computer) would be *extremely* useful too (possibly more so than an iso-surface, however cool those are.) , as it could be collapsed/ proxied/textured/edited...

[super gnu]

here is a file that shows the issue with using gradient ramp or similar..

volumegrid testure surface issue.zip


open and render, you can see a hard step between the two procedurals rather than a blend of any kind.

there is another option in the material editor.. a bercon noise with a mapped "size" parameter.. however that exhibits the same "solid step rather than gradient" thing.


ive also tried with a bitmap set to object space projection, i get the same issue.


when applied as a diffuse map to the same volume grid, these textures seem to work as expected.

[super gnu]

i forgot to include the vdb file.. in this case i was actually using a generic icosahedron vdb from the openvdb page.. i assume that wouldnt make any difference over a cube for this purpose.icosahedron.zip

[super gnu]

quick update to say, if you set the tiling of the gradient ramp to 18, it works to an extent.. no idea why you need such a ridiculous tiling number.


also, if you put the same gradient in the diffuse slot of the assigned material, it repeats many many times.

with tiling of 1, it still repeats 7 times across the surface. setting the tiling in that case to 0.1 gives a more reasonable result.

definitely something screwy. in one case needs unreasonably high tiling number, and in the other strangely low.

surely a tiling of 1 should work in both cases to map the texture once across the object.

[super gnu]

a test blending 2 cellular maps with a gradient ramp, with a bit of noise in the gradient ramp slots to mess it up a bit.

that is with tiling of 18 repeats for the gradient ramp. it approximately tiles once across the grid with this number. wierd huh?

it now needs some texturing based on the same gradients etc, but for that id need extremely different tiling numbers, and it would be very hard to get a perfect match.

[Svetlin.Nikolov]

Affirmative - definitely something fishy with the mapping, still looking for it...

[Svetlin.Nikolov]

Alrighty - it's fixed, but will be in a nightly as early as the 28th - we're locking down the codebase during the holidays so builds won't get broken while people are missing.

Going to add the hidden param for the size as well and will update you when you can try a new build. Thanks for reporting this!

[super gnu]

brilliant! thanks, i look forward to trying it out.. just to clarify, this will be in the nightly of vray? or does it come in phoenix first?

[Svetlin.Nikolov]

Same time - in case you have access to phoenix nightlies, I will tie the grid dimensions to the surface texture's box when there is no cache, so it will be more convenient than scripting for the VVG.

[super gnu]

unfortunately i dont have a phoenix license, so scripting it is.. since im pretty useless when it comes to scripting, hopefully you can give me some hints when the new build becomes available. many thanks!

[Svetlin.Nikolov]

Hehe, no worries, we'll set it up.