Any DCC with incremental scene saving?

[wesserbro]

I mean when you are able to save only changes made to previous scene version. Like, for example, you have a scene of 1gb, but are messing around with some expression, adding drivers, maybe few keyframes. All this takes some kilobytes but you actually need to store yet another GB, back up that extra GB, so much waste of space... I started to wonder about this after my HDD become unstable and i was in need to quickly duplicate 50Gb project to another drive, praying to god hdd would not crush in the middle of the coping operation. With "save changes\difference only" the project could be 10 times smaller and so much easier to back-up.
I'm not saying i would use any 3d software just because it has such a feature, but i just wonder if any has one.

[nodeway]

Switch to Houdini. HIP files are very small. To have a 1GB HIP file you would have to force saving geometry with a file or lock the node chain. By default HIP saves series of operations, so no geometry data is saved inside and everything from disk is referenced.

And each time you press CTRL+S it saves incremented copy of the file in special folder called "backup", that is created in the same folder your main HIP file resides.

[myara]

AFAIK,no.

But Hard disks are very cheap nowadays. Buy a new one.
Or better SSD.

I haven't used Houdini and probably never will but referenced assets won't be saved in any software so you could replicate that feature if you want.

Lightwave used to save everything in separated files and I think Softimage 3D did too ( haven't used Softimage 3D).
Personally I prefer one scene file.

[Bullit]

What you asking is not typically asked called incremental scene saving.

[wesserbro]

What you asking is not typically asked called incremental scene saving.

yeah, people just asking about saving with adding numbers to scene name and keeping previous. I thought it was a misconception, so i gave it a new meaning ))

[wesserbro]

Switch to Houdini.

Actually im familiar with Houdini, but thinking about all this scene size stuff it somehow never came to my mind.
And yeah, houdini's system is much more comprehensive than referencing. You can in fact modify your geometry but it still would be just a stack of operators on top of the original geo file. One more '+' to Houdini's karma in my chart)

[luceric]

it's bad practice to have a scene that big. In those cases, you should have most of your assets separate, and a scene to assemble the assets by reference. It would also be bad performance and workflow-wise to seek to keep all procedural to save on scene size.

Not only would your scene smaller, when you make changes to the parameters on these reference models, Softimage will save the modifications to external "delta" files. That's your incremental save right there.

There is no software that I'm aware that is written to and "patch" your scene files with the delta of your modifications. Many reasons for this.

First, scene files writing is made to prevent data loss, i.e. avoid losing everything because there has been a disk error or power failure. In order to implement this, the existing file is first renamed, the new one is written, and then the old one is deleted if the write was successful. So yes, you need to have twice the disk space to save a scene, and that's for your protection.

Secondly, the changes you made may not fit in the exiting file, for multiple reasons. For example, imagine changing the value "0.0" to "1000.0" in an ASCII file: there is no space, everything must be moved down 3 characters. Also, most binary scene files are some how compressed, and so you cannot simply seek to a given position and patch a 32-bit value to another value. An imaging if you changed a string, like an expression. There are checksums, compressions, and just knowing where the data was saved which make things complicated.

It's possible to construct a system to support this, but it involves creating a file format is essentially a file system in a file, with extra buffer space and free space management. It exists (for example COM Structured Storage) but it's never really caught on. XSI and Avid DS are using that kind of file, but when incrementally changing chunks of data in those files, the file size continually grows as new data is allocated and now-freed space is loss. Eventually the file needs to be re-written anyway to optimize the storage and read speed, which deteriorate as the file gets fragmented.

[wesserbro]

Indeed comparing ASCII files is not a great idea, but i was actually
thinking of some kind of binary and XML-like structure combination.
So that when a value has changed only it can be stored into the new xml-like file.
And when the scene is opened, program goes up from scene.001 to scene.xxx replacing old values with newer one(if exist)
And about meshes..
For example you have a project of medical visualization. Bunch of heavy objects converted from mri scans. You create scene.000 with only them.
referencing it to your scene.001. On some iteration you need to modify the mesh of object X (but keep previous version).
You break referencing connection, make a copy into actual scene (local) and modify the mesh.
Then you create another iteration, on which you do not need to modify object X, so you reference it from previous scene to keep space.
But later again we need to alter it, and there are 100 of such objects (bones for example) which you may will to modify at any iteration.
So you referencing and 'de-referencing' back and forth like insane
or more likely you end up having scenes after some iteration containing all the actual geometry with no referencing.

It could be pretty neat to have a system that manages all this for you.
Not a major problem to say the least, special case, but again, i was just wondering )

And if you ask me what would i prefer: to back-up some data 50 times through each scene iteration on the same HDD or back-up only deltas to 2 different places (another drive and cloud storage) i choose the last.