maps in texture surface slot of vrayvolumegrid

[Svetlin.Nikolov]

Hey,

The fixes are in today's nightly (26563) - the mesh preview is working again, the object xyz mapping is now correct too - you need just one tile for the VVG container.

Also, added the no-cache container size/resolution MXS params - "empszx", "empszy" and "empszz". These are in voxels and will resize the container in the viewport as well, so if you want to use them to refine the resolution, they must go together with scaling the container too.

With the attached scene from the previous page of this thread, I can get about the same result without a cache as the original after setting empszx=empszy=empszz=200, the VVG scale to 4.0% along all axes. The bread and crust cell sizes must be increased to about 10 and 2.5 respectively, and the spreading must be corrected too. I just found that after changing the scale of the VVG, the preview mesh is not cut by the gizmo, so you can workaround it by disabling and enabling the preview panel's 'show mesh'. I'm yet to see what's wrong with it...

Good luck! If you have any issues, ping me

[super gnu]

great! cant wait to try it.

ive yet to download the nightly, but a quick question: when creating a vvg, it opens the file load dialog immediately, and only creates the vvg after you choose a file. has this behaviour changed to allow creation without a cache?

[super gnu]

ok hm, seems i do not have nightly access. i thought i did. i have a login for the nightlies site, but i can only see the stable builds.. the nightlies folders are all there, but they are empty. can you help?

[Svetlin.Nikolov]

Umm, you should ask the support team about access. If you have a licensed Phoenix, you could ask for Phoenix nightly access instead and try out the new stuff (regarding your thread about the solar flares). Conditions for nightly access to Phoenix are much more relaxed currently than V-Ray's - basically if you want to get your job done or you report issues, you are in.

About creating the grid without a cache - if you cancel the open dialog, the grid won't delete itself and will remain cacheless. You could also erase the cache path of a volume grid that has some cache loaded.

[super gnu]

ok ive emailed them. ive actually been granted permission twice, once for vray 2 then again after the update to vray 3. i think i just never actually downloaded a nightly, so didnt realise it wasnt working until now.

wrt phoenix.. i wish i was a phoenix owner. ive not yet had a job yet where i can justify the outlay though. i keep hoping ill get a project that demands lots of water or fire at a decent quality. for the solar flare effect, ive managed something reasonable with pflow for my purposes..

now, were you to tell me that phoenix can now do plastic deformation and mapped variable viscosity (i have a personal project and i want a field of mixed chunky mud, stones and water, last time i tried with phoenix (pre flip solver) it couldnt do it, and i managed to get much further in houdini, although the learning curve got way too steep for a novice, and the project went on hold)

then id probably buy it just for myself.

[Svetlin.Nikolov]

Negative, this would be out of reach for Phoenix at the moment too Well, keep me posted when you get the build - I might be able to throw in a fix for the cutter preview not updating when scaling...

[super gnu]

ok so im still waiting for my nightly access to be fixed.. apparently "nightly access is not for commercial customers" which is news to me, as i had nightly access before, twice, and ive never heard of anyone being rejected, esp. people who have been using vray since the early original beta versions.. and provide tons of bug reports and feedback. ho hum, hopefully it can be reconsidered.


anyway, i attach a vdb file. i created it with the "bulletfx" vdb modifier.. simply spits out a vdb cache from a piece of geometry.

if i create a volumegrid, and choose this cache, i get an empty volume grid. if i go to "third party channel mapping" i can see a channel called "0" is mapped to smoke. however the grid remains empty.

id suggest the vdb is incompatible or something, but i sent it to the developer of bulletfx, and he sent a screengrab back of it working perfectly in his vrayvolumegrid. apparently he copied my simple workflow. open volumegrid, choose vdb file, no preset. use smoke channel.

his worked, mine doesnt.

Sphere0200.zip
any ideas?

[Paul Oblomov]

Houdini viewport is also empty.

[Svetlin.Nikolov]

The wonders of software Seems like the [0] is an automatic assignment for a nameless channel in the vdb, and not all of our code is prepared for nameless channels.

Could you check if there is an option anywhere to name the channel in the exporter? This should help work around the issue with the current VVG. The fix is ready, but I wonder why the vdb was exported this way and if this really was intended.

[super gnu]

The wonders of software Seems like the [0] is an automatic assignment for a nameless channel in the vdb, and not all of our code is prepared for nameless channels.

Could you check if there is an option anywhere to name the channel in the exporter? This should help work around the issue with the current VVG. The fix is ready, but I wonder why the vdb was exported this way and if this really was intended.

I will ask the developer. It's very strange that he got it to work immediately. He didn't specify which vray version he was using, but I have 3.3.03. I know it worked cos I saw a screen grab.

[super gnu]

ok, going back to the original theme of the thread, i finally got my nightly access back, and the viewport preview of the texture surfacing works great!.. HOWEVER, the maxscript cell size controls seem to have no effect.

i type em in, and it prints out the size in the maxscript listener, but the volumegrid does not change. even if i refresh the preview.

ive tried the suggested 200, and all the way up to 2000, but the grid size and preview resolution remain unchanged. this is with a grid created without a vdb file.

this is using the latest 26568 nightly.

on a vaguely related note, i had hoped that vraytriplanartex would work with implicit surface rendering mode, but it doesnt.


edit: in fact, objectxyz mapping doesnt work on the implicit surface either. if i have it in mesh mode, im able to apply the same procedural texture i used to generate the surface to the diffuse slot, and it matches perfectly. in implicit surface mode, i get microscopic tiling of the texture in the diffuse.

[Svetlin.Nikolov]

Hey,

You're typing in the size params with a selected volume grid like this, right? $.empszx=200

The object xyz mapping on the isosurface's surface is wrong indeed, I will have a look at that too - by now I only checked the mappings needed to generate the isosurface itself.

Btw, anything new on the bullet vdb? I didn't push the fix into the nightlies yet in case there is something more to it.

[super gnu]

yes, Ben, the developer, has fixed the exporter to name the channel "density" and it works fine now.

and no, i wasnt typing them like that. i was typing them without the $.

as mentioned previously im *really*hopeless with maxscript.

[super gnu]

another question, now im playing with higher grid sizes: obviously with a 1kx1kx1k grid and above, ( needed for nice sharp mesh-based stuff, since its tied to the grid size) it takes a right age (nicely multithreaded i see to generate the mesh.

i had hoped the "detail reduction" in the preview rollout would allow me to reduce the workload when tweaking textures, but it seems to have no effect. neither does turning on or off "auto reduction"

obviously i cant just start with a low grid size and increase later, as it changes the scale too.

[Svetlin.Nikolov]

That's right, we don't have a viewport reduction for the mesh currently, but I think it could be applied to the surface texture at least. 1K^3 is a billion voxels, so it really should take quite a while to get anything going on in the viewport, so I should try to get the reduction working in the next several days.