itsallgoode9 wrote:Not sure if it's possible, but it seems like it should be, assuming the displacement hasn't been updated between renders. Seems like a lot of wasted time to tessellate the displacement geo every single render.
Thoughts?
Depends what is meant by possible -- most anything is technically possible, the question is more whether it can be done with improved performance, and without compromised reliability. In the case of displacement, what factors determine the tesselation? There is first the mesh itself (UVs, triangle groups, etc), followed by the values in the displacement component, the displacement texture, and possibly the global override texture. There are then the pixels in the displacement map itself, and here, we could try to rely on the last-write time of the file, but this not being foolproof, and Maxwell needing to aim for reliability, we should rather keep the old map loaded, then load it again, then run through the two, comparing all the pixels to verify that they have not changed. Beyond this, it may be that the mesh has modifiers (e.g. SubdivisionModifier) being applied prior to displacement, so those need to be compared, as well.
That covers a single hypothetical mesh and its displacement material, but there is also the problem that nothing guarantees object "x" in one MXS to be conceptually the same object as object "x" in another. So, before being able to compare two actual objects, it is first necessary to load both MXS files, in order to run through the displaced objects of each, comparing them to the displaced objects of the other, where comparing means comparing all of the values in the meshes as mentioned above, in order to find whether they actually match up. Leaving aside that this would involve much comparison of floating point values (failure is okay, since it only results in a missed potential optimization), I might guess all of this bookkeeping to take more time, in some cases, than simply dumping the old scene and tesselating meshes again in the new one.
A better option, for cases where a given tesselation result would have remained static across the series of MXS files, might be to allow baking the pretesselated displacement out to an MXS, where you would then reference that MXS in your final production scenes. If you think about it, this is basically a roundabout way of ensuring that none of the factors mentioned above could possibly be in play, since whatever changes you'd have to make in the scene in order to use this approach, those are exactly the same changes you'd have to make to prevent the need for re-tesselating displaced meshes between renders. As far as using displacement as a way of conserving disk space (or network bandwidth), this should usually be inferior, but at least we do get to subtract the weight of both the original mesh, and of the displacement texture. At least, it would give you the option of dealing with such displacements in whichever way might be most appropriate for a given situation.
- By Jochen Haug
- By jurX