wtf? Vrscene size is exploding

[fixeighted]

I thought I'd try the cloud service for this little animation. The max file size is 850mb but I'm exporting the vrscene and at 47% it's already 31gb. Now I did not expect that and it is made doubly annoying
as the cancel does not work at all.
For future reference, why is this file size necessary and is there anything I can do to avoid it?
The file is a car driving - so it is the car model, some terrain and some forest items, if that helps.
It clearly makes Chaos cloud use impossible at this point. Any render farm would not do this to the native file, so I'm perplexed.

[super gnu]

unfortunately (and this is a problem with vrmesh too) it saves all geometry for every frame for animation, instead of saving the transforms like it should. this seems a fairly major issue and defect for a format which deals with animated stuff.

[fixeighted]

LOL no?! Surely that's not how it's supposed to work....so basically it would take longer to save as a scene and then to upload to the sever than it would to render it out on my Galaxy S10 phone
Hmm, I shall shelve that idea and revert to Rebus or one of the multitude of others.
At least I just found the other cancel button, so that's a result

[psanitra]

One way to deal with this is to export the car to Alembic,which is pretty much made for stuff like that, it does both transform and deformation geo very well. Then reference the alembic back to your scene via vrproxy.

[^Lele^]

Are you sure of this?
The vrscene format *does* allow for transforms, however it has no way of using those if, f.e., one skinned the car meshes to bones, rigidly that it may be, or used some other transformation method which didn't directly change the node TM.
In this respect, i highly doubt a different caching format could do magic: one would only offload the size of the vertex cloud animation somewhere else.
If you have a scene which you think should allow for transforms but doesn't, please send it to support, for they'll want to take a look.


below, a sample from an animated box (via direct TM manipulation and keyframing).

// Frame at time 1

Node Box001@node_1 {
  transform=interpolate(
    (2, Transform(Matrix(Vector(1, 0, 0), Vector(0, 1, 0), Vector(0, 0, 1)), Vector(-25.7465648651123, 96.23505401611328, 0)))
  );
}

// Frame at time 2

Node Box001@node_1 {
  transform=interpolate(
    (3, Transform(Matrix(Vector(1, 0, 0), Vector(0, 1, 0), Vector(0, 0, 1)), Vector(-24.67288017272949, 95.05358123779297, 0)))
  );
}

// Frame at time 3

Node Box001@node_1 {
  transform=interpolate(
    (4, Transform(Matrix(Vector(1, 0, 0), Vector(0, 1, 0), Vector(0, 0, 1)), Vector(-23.21703720092773, 93.44384002685547, 0)))
  );
}

[fixeighted]

My model has a rig yes, so are you saying that it looks at what the rig is doing and bakes it per-frame?
If that is the case then that would explain the size, as it's adding keyframes for every single object that moves, which seems a bit overkill

Anyway I'll look at the Alembic option if only out of interest, so thanks for that pointer.

[^Lele^]

It's essentially adding snapshots of meshes it perceives as *deforming*.
Alembic will do the same, most likely.

[fixeighted]

Thanks - what I thought. What a shame

[psanitra]

As Lele was saying, this is standard behavior,not just for v-ray max, but other apps and renders, that`s just how stuff works. If your rig creates deforming geometry, then it`s per frame mesh. For cars, people usually break stuff to nulls/dummies, link,/parent it, and animate nulls, so it`s all just transforming geo and it will be lightweight. Unless your car is crashing or something and you need deformation....

[fixeighted]

Hmm, well it's not really deforming, just translating, so the wheels spin and the body moves in accordance as you'd expect and they are indeed just links to the quite simple rig dummies.
Maybe there is something else that is odd in the scene.
I could send this to Rebus for example and it would just be the original max file size.

[^Lele^]

As said above, we'd be happy if you could send the scene to support, in the event it was a bug.
With a max file, you'd have to reupload it wholly each time you made a change, with a vrscene file you can upload incrementally.
There's a hundred ways to skin the same cat, that's also why it's important for us to see what it is you're doing with the geo.

[fixeighted]

Yes I am going to investigate this when the sequence finishes here in a few hours. If I cannot find the culprit I'll link to the file.

[^Lele^]

Notice that to dump vertices positions, the mesh has to have something that modifies them (even with a no-op).
For example, say you bound a world-space modifier to a mesh, like a wave, but set all its values to 0, so that it had no visible influence.
That mesh would still have to be dumped by the vertex, instead of by the transform.
This is why i spoke of rigid *skinning*, instead of parenting.
Tyre squashing would be a good candidate for mesh dumping, for example.

[fixeighted]

This is something I'll check. I did add a deformation warp to a tyre but am not actually using it. Although that could be a cause it is only the one warp.....could that account for 70 gigs of data you think, given that the tyre is quite a dense mesh?

[^Lele^]

vrscene packs the data very tightly, but it can only go so far.
It essentially turns your live max file into a render cache (meaning you won't pay the chaos cloud to compute the stack results in max at each frame, as you would with a live max file and other services, at the expense of upload times.), and render caches can definitely be very very big.
In production, normally one tends to split them up so to better manage them, but yes, 100gb of deformed meshes are about par for the course, with a car of any decent detail: consider a static car in max can quite easily top 1gb, times 100 frames (if the scene forces the whole car to be dumped), and there you have it.
What exactly is happening with your file, though, i don't really know yet.