OTOY Forums

We converted all our current scenes to .dds texture format (originally used .pngs and .jpgs) and suddenly all our Displacement nodes stopped working. We're not sure if this is Octane issue or our .dds encoder issue.

It's sort of fixable when you put Baking texture node before the Displacement node but it kinda lowers the quality and it would be nice to have the option to use .dds directly without any extra nodes.

Software used: Cinema 4D 2025.0.2 + Octane 2024.1.2

EDIT: Working files attached.

What led to the .dds in the first place? A cross-platform pipeline?
The likelihood of that encoding format being utilized in the offline-rendering domain (Octane and alike) is close to zero.

EXR, TIFF and all variants including "mip-mapped converted containers" are the supported, established and recommended ones.

When it comes to texture authoring and the related optimization measures, there are things to consider.

Worth mentioning displacement would require higher precision, bit-depth and so forth, for superior results.
EXR 32-bit, single channel (e.g. R) is recommended over all the others.

I just carpet bombed my scenes with .dds conversion. I've been using .jpg and .png images up to this point and then our TD said "try .dds, it's faster" and I conducted the following test which had absolutely bonkers results.



This carpet bombing conversion led to EVERY texture present in the scenes being converted to .dds, this means the displacements as well. It's not really big issue, we'll keep using .pngs or .psd files for displacements. It was just weird everything accepted these .dds files except the displacement node.

An optimized* set of OpenEXR texture files will surpass PNG in all aspects, including performance and file weight, for both textures and render output (export). PSD is also not recommended, but comes handy in edge-cases.

Converting to OpenEXR (and if Octane ever gets mip-mapping, to that) is worth considering. One of the previous link details about the file format and glances over relative performance. This could be done in bulk via available tools or a custom script.

JPG is acceptable, especially for "non critical" texture types such as displacement and extreme manipulations (processing).

To emphasis on the situation: PNG is and should be considered a forbidden format, particularly in CGI / VFX.

*such as:
- single channel for non-color textures
- appropriate bit-depth and compression type according to the texture type
- loaded with the appropriate Octane texture import options according to the file specifications in question

I think I'm getting confused a bit here. You're trying to explain that .dds isn't supported by Octane Displacement node because no artists would really ever consider .dds as an texture input for the Displacement node and would rather stick to formats like .exr? If that's the case then I understand why the support wasn't included. That being said - I think there is no harm in adding such support?

The .dds format is unconventional in the offline rendering / VFX "world", close to non-existent.
In other words, this is what would be considered an edge-case or niche-request that will only benefit a minority, unlike EXR or TIFF support for textures (and export) and variants such as custom mip-mapping containers. But it is supported.

Furthermore, Octane is seemingly already benefiting from a cached GPU compressed textures system, which would normally make the DDS conversion redundant and unnecessary.

It has its benefits and downsides, as pointed out here.

Seemingly no mention of displacement, which would be too impacted by compression algorithm and expectedly result in "artifacts", lower precision.

abstrax wrote: OctaneRender™ 4 RC 1

Changes since OctaneRender V4 XB4:
New 8:1 GPU texture compression
You can now compress RGB or greyscale image textures for rendering via the image import preferences. Compressed textures use just 1/3 to 1/8 the VRAM of normal RGBA textures while rendering. Compressed textures incur zero speed loss, and are often visually and perceptually identical to their uncompressed counterparts in many cases. Octane can now also load compressed DDS files directly into texture nodes where they will automatically preserve their specified compression settings when stored in GPU memory.

I'm surprised more artists aren't using .dds when it makes octane live viewer startup this much faster. In some cases I measured 4 times faster octane startup time compared to .png and .jpg formats.

Some non-exhaustive probable reasons with a multitude of external factors:

• DDS container, and its set of compression algorithms, has seemingly been much more present on the online than offline rendering side.
• Painter does not support .dds export, Mari does.
• offline rendering "standards" and/or conventions were mainly driven by CPU production renderers, which for most, support some form of EXR/TIFF and "mip mapped" format.
• OpenEXR and TIFF check more boxes overall, in addition to their wider implementation in computer-graphic programs of all sorts.
• OpenEXR is open, offers a palette of compression (efficiency), is cross-industries compliant not exclusive to a specific use case but several (versatility) and frequently maintained.
• Neural Texture Compression Is seemingly a novel compression approach of this era.

While there is much more to detail about image/texture file formats and compression algorithms, "if it works, it works", where .dds is beneficial and where other file formats are more suited for a given situation (e.g. EXR for displacement data encoding from source).

Edit: DDS appears to support floating point data but this may not be supported in this particular context. That's for a developer to confirm.