[Hervé]

supporting image...

[Polyxo]

Hi Hervé, I personally have never made good experiences with Maxwell-Displacement, I always found it way too slow,
that's why I wondered... Typically adding displacement decreases render speed to about 1/4 or even less, at least on my machine.
Looking at your example-image and taking a 3DCoat-Maxwell-Workflow given I personally would opt to export a far denser mesh
which already looks pretty much like the image on the right and would do the rest with a Normal Map.

[Hervé]

heyy..

well I do see your point... but dense meshes in animation are a no go.. besides we have access to a large renderfarm.. so no problem...

[Polyxo]

heyy..
well I do see your point... but dense meshes in animation are a no go.. besides we have access to a large renderfarm.. so no problem...

I see your point now too , but I could still generally imagine that using a Low Poly Proxy which gets exchanged on a per frame base atrendertime by a
normalmapped HiRes object was a lot faster - at least if the heavily detailed object itself isn't animated and only caused pain in Timeline-Scrubbing.
But that's now really not Ptex related...

[Hervé]

Well to tell you... we're kinda do this... indeed we use Excellent Maya displaceD..

[jwiede]

I cast another vote for PTex support. It really is an improvement over the "UV dance".

While 3DC can take a PTex-textured object and downconvert it to conventional maps for apps that don't natively support PTex-format textures, that isn't the same as "native PTex-format support". Native support for PTex-format textures themselves would offer additional benefits. The built-in (standardized) procedural and layering support provided for in the PTex format would be particularly nice to have in Maxwell.

A German company, at2 Software, just released native PTex shader support for Cinema4D. Maybe they have a cross-platform PTex processing core that could easily be licensed and incorporated into Maxwell? Just a suggestion.

[Polyxo]

While 3DC can take a PTex-textured object and downconvert it to conventional maps for apps that don't natively support PTex-format textures, that isn't the same as "native PTex-format support". Native support for PTex-format textures themselves would offer additional benefits. The built-in (standardized) procedural and layering support provided for in the PTex format would be particularly nice to have in Maxwell.

As Ptex files are not useful for use with a Simball (= there's no image-files) native read-capability made a lot of sense after the implementation of Fire:
For tweaking materials appearance directly on the Render-Object. Fwiw: 3DC can also export Ptex directly, without getting frozen to an image.

[naxos]

+1

[gadzooks]

I would like to see this as well!

[simmsimaging]

+1. It's a growing part of the normal workflow.

[jwiede]

Okay, so 11 months later, any word on this? Having "native" PTex support would be quite useful.