RealFlow Mesh Velocity Pass

[bigbossfr]

Use an expression ?

[alainfx]

Use an expression ?

As it's a string, and not an integer, I assumed it wouldn't work.
How stupid I can be when I'm tired...
theAttr = ("pathToFiles" + frame + ".vrmesh");

[bazuka]

hehe, why dont u ask people its simple
1. import 1st vrmesh
2. open vrmesh node and in file name replace Mesh01.0001.vrmesh -> Mesh01.%04d.vrmesh (if u have 4 digit then its %04d if its 5 then %05d)
and have fun

i was the one who asked vlado to make rf converter

[bigbossfr]

1) Select your mesh_vraymesh
2) Add an attribut integer, called "Frame"

addAttr -ln "frame"  -at long  mesh_vraymesh;

3) Connect the timeToUnitConversion1 to your attribut :

connectAttr -f timeToUnitConversion1.output mesh_vraymesh.frame;

4) Now create an expression like this :

string $frame = `getAttr mesh_vraymesh.frame`;
setAttr -type "string" mesh_vraymesh.fileName ("scenes/pSphere"+ frame +".vrmesh");

I use an extra attribut for the time. The reason is, in an extra attribute, the time will be evaluate to each frame in bach render.

[alainfx]

I didn't know the standard %04d syntax was allowed, that's really great !
Thanks !

[ALFRED_ST_MEDIA]

oh the irony....I just fired off an email to nextlimit asking when there would be a renderkit for vray. consider me educated.

So, to re-cap, the pipeline is:

- export RF .bin files
- batch convert .bin to .vrmesh with ply2vrmesh.exe
- create proxy in maya pointing to .vrmesh file, using %04d syntax (e.g. myFile.%04d.vrmesh)
- live happily ever after.

Sound about right?

p.s. Bazuka, that ocean particle test on vimeo is pretty sweet. Nice work.

[bazuka]

@ALFRED_ST_MEDIA

thx my friend, i send email to NL too about renderkit for vray, but i got negative response, they wont make it, so i asked them to share SDK but they wont share that either...
so we will have to wait for next realflow ver i think its v6 when they will share everything, they will publish SDK for everything inside realflow...

cheers

[alainfx]

oh the irony....I just fired off an email to nextlimit asking when there would be a renderkit for vray.

i send email to NL too about renderkit for vray, but i got negative response, they wont make it.

I also asked them about renderkit for vray (several times), they answered they focus on renderkit for Maxwell and Mantra.
So, as mentalray and RenderMan are already supported, VRay is one of the only main renderers to NOT be supported, too bad...

[alainfx]

I didn't know the standard %04d syntax was allowed, that's really great !

As a feature resquest for VRay, I think it would be very useful to get an offset attribute that changes the %04d stuff.
Because, if you want to offset the anim for a few frames, you currently have to rename all your vrmesh files.
Or use an expression to control the file name (but it's not as user-friendly as the %04d syntax).

[vlado]

As a feature resquest for VRay, I think it would be very useful to get an offset attribute that changes the %04d stuff.
Because, if you want to offset the anim for a few frames, you currently have to rename all your vrmesh files.
Or use an expression to control the file name (but it's not as user-friendly as the %04d syntax).

If you use one single animated proxy, you can change the offset. The ply2vrmesh crash is now fixed in the nightly builds.

Best regards,
Vlado

[alainfx]

If you use one single animated proxy, you can change the offset.

Yes, but usually bin file are between 400Mb and 1Gb (in HD productions), so a sequence of 200 frames will produce a single animated file of 200Gb, which will kill the network.
It's a lot better to have a different vrmesh for each frame.

The ply2vrmesh crash is now fixed in the nightly builds.

Thanks !

[bazuka]

@vlado

vlado could u plz send me link for nightbuilds? i have already send u an email...

thx

[bigbossfr]

Yes, but usually bin file are between 400Mb and 1Gb (in HD productions), so a sequence of 200 frames will produce a single animated file of 200Gb, which will kill the network.
It's a lot better to have a different vrmesh for each frame.


Thanks !

No, like this post : http://www.chaosgroup.com/forums/vbu...ighlight=proxy

The .vrmesh files are indexed; V-Ray can find out exactly where each frame is without wading through the whole file and will load just the part that it needs. So from that point of view, there is no difference between single and multiple files.

Best regards,
Vlado

So, you can have a big vrmesh !

[sewer]

@vlado

vlado could u plz send me link for nightbuilds? i have already send u an email...

vlado please send me too

Best regards
Seweryn

[MartinB]

Following this thread I got motion blur working as expected for simple realflow mesh's converted to vrmesh's (in the 5-15mb range) but as soon as the complexity increases ply2vrmesh crashes during the conversion process.

It goes during the Subdividing Voxel phase, on 90-100mb files it seems to consistently happen around the 37.8 mark. I've tried it with a few different simulations now.

This is on fedora 12 with 2.00.04 vray release. Machines have 16gig's of ram but also tried it on a couple of 64gig machines and it goes at the same point so don't think its a memory issue.

Cheers for any help
Martin

> ./ply2vrmesh.exe ParticleMesh_ST01_00004.bin 
Coverter of .ply .obj .bin and .geo files to .vrmesh files
Copyright (C) 2003-2011 by Chaos Group Ltd. All rights reserved.
Build from Apr 28 2011

Converting file "ParticleMesh_ST01_00004.bin"
Output file is  "ParticleMesh_ST01_00004.vrmesh"
Reading .bin file... done                                                            
Calculating vertex normals... done                                                            
  Number of faces: 3254229
  Number of vertices: 1626967
  Number of texture vertices: 1626967
  Number of vertex normals: 1626967
Reading voxel... done                                                            
SubSegmentation fault (core dumped)

EDIT: Just did some further testing and on a 100 frame sequence, all the files below 20mb convert fine, as soon as it hits 21-22Mb they start failing. So frames 0-16 were ok, 17-30 failed as the mesh complexity went up, then 31-100 converted ok as the fluid started settling.