Blender doesn’t have it. Max has it:
ah, ok, I understood it wrong 
Workarounds:
1 set a decimate modifier to only be active in viewport
2 for file linking: make a decimated version of your mesh, and group both the objects. decimated only viewport, full res only render. When you link it you’ll have a sort of proxy
1.- it’s not a good workaround, when you open the scene the simplify modifier process time is super big as soon as you work with complex models, what the decimation of proxies does in max is to skip parts of the model, so it’s fast, it’s not trying to get a closed mesh or a correct mesh, it’s just skipping parts to make it faster.
2.- Yes, that works and I think it’s a good partial solution, having that as an implemented simplified workflow could be good, we may be able to pack that in the form of a simple addon
But in the end there are other things for proxies, for example animated proxies.
I’ll put an example that I think I mentioned earlier, but I didn’t reach the possible solution:
- We have a 1 million polys tree
- Then we rig and animate that tree in a loop of 100 frames
- There may be an option to store that tree in a form that it saves the geometry to a disk file (alembic or other file format) and then we have those 100 frames stored.
- Now we want to create a forest, hence we load that tree
- Now we have 100 tress moving at the same time, we cannot delay or randomize the animation because we are loading one shape at one frame
- But, and that’s just an idea, if we load the 100 frames in memory we should be able to randomize the animation of all the trees as much as we want, because we have all the possible variations in memory, that would be like 100 trees.
- Let’s say we decide to have 5 starting points for the animation, at each render frame we should have the equivalent to 5 trees, but not 100 tress, this of course is way more than 1 tree, but waaaaay less than 100 trees.
- From this starting point there may be further optimizations, like storing deltas for the geometry that has changes, and store just 1 base geometry and the deltas for the current frame, MAYBE, and just maybe, this could help also, I’m no expert in this area at all.
- This would be the same as having the same tree cached 5 times with 5 times the disk space used, and it probably would be faster to read since we only have to read 1 file from disk, not 5.
Now regarding viewport performance, yes, a point cloud would be very welcome, I already spoke about this with @fclem some time ago, he said he was going to look at it once he get some time, we showed him how the performance improved in max from forest pack examples and he liked the idea, I hope he don’t forget ( @fclem don’t forget please, this is not only for proxies but for anything in viewport )
Anyways, maybe a different thread should be made to talk about proxies in viewport?, since this is a Cycles thread…but I understand in this case things are very entangled so I’m not sure
3 Likes
Apologies for the late reply… loads of stuff on and, uhh, I didn’t get notification of the thread replies…!
I wasn’t referring to geometry in any way, just textures.
The issue with Blender in its Simplify section of Cycles renderer is that it resizes the image textures at render time. Also, all textures become a unified size.
Therefore issue:
1 - All high res textures need to be loaded and downsized at render time, every single time. When loading across the network, this can take a very very long time especially if you’re dealing with exr or 16bit tiff files at 10k+.
2 - Resizing all to a specific size and not a size factor means that all previous work done on texture size relationships to geometry (as per usual practice) has gone out the window - eg a texture may even get scaled up or stretched if it is non-uniformly produced (eg not power of 2)
We need an option in Simplify to specify the location of the proxy (low res textures) which are generated prior to rendering or if a new texture is loaded, or aren’t (its done manually by the user via a script or external program) - we are just overriding the path of the existing texture to a new location without overwriting the original texture path’s name) so that it can be flipped back on for final rendering.
This ensures that in development we’re not waiting for absolute ages to either load big textures off a local disk or off a server. This will therefore speed up productivity and responsiveness of the software, giving the impression that it is much much faster than normal…!
Again, please take a look at max’s Proxy system for the type of thing I’m talking about. Very simple and does the job. The resulting proxies can also be used with the Viewport texture decimation to speed up viewport performance in Eevee.
Pete
1 Like
This would work great if there was a cache modifier, similar to houdini’s cache, fileche and rop nodes.