OTOY Forums

Hi Otoy
It's been over a month we talked about motion blur for liquids in 3ds max. just wondering if any progress was made or if you were able to get in touch with autodesk. We cannot even upgrade to octane 3 until we know for sure we will be getting mb for liquids.. Thanks

It matters what exactly you mean by liquids. If the non-static-topology animated geometry loaded as 3ds Max alembic object - as I wrote 3ds Max screws up the velocity data (Octane standalone alembic reader handles it without any problems). The bugreport ticket was posted in Autodesk support system a long time ago (# BSPR-24108), but there is no response from them.
If you have some liquid animation that does not use 3ds Max alembic - you are welcome to give me the scene and I will check if the velocity data is accessible in it.

JimStar wrote:It matters what exactly you mean by liquids. If the non-static-topology animated geometry loaded as 3ds Max alembic object - as I wrote 3ds Max screws up the velocity data (Octane standalone alembic reader handles it without any problems). The bugreport ticket was posted in Autodesk support system a long time ago (# BSPR-24108), but there is no response from them.
If you have some liquid animation that does not use 3ds Max alembic - you are welcome to give me the scene and I will check if the velocity data is accessible in it.

it is non static topology. We use phoenix fd liquids (You can download free demo and try Phoenix fd liquids and see for yourself) or ephere's lucid liquids.

so no response from autodesk I guess we will never see motion blur in 3ds max. I guess otoy is not planning to do much about it since they got no response from autodesk
This sucks

coilbook wrote:it is non static topology. We use phoenix fd liquids

PhoenixFD is supported by Octane (in current TEST versions), and motion blur for its simulator object is supported too. But you can't talk about PhoenixFD liquids as "having non-static topology", 'cause they don't have any mesh topology at all. The PhoenixFD liquids are actually volume grids.
Octane rendering core currently does not support rendering a volumes as meshes with e.g. specular material applied. Currently Octane only supports rendering volume data as a volume. So, if you e.g. apply some emission to PhoenixFD liquid - it becomes visible, it will have a motion blur, but it will be rendered as a volume currently, not as a mesh - so it does not look like a liquid and it can't be used for that kind of rendering (see the example). I've just had a talk with haze (the guy who works on VDB subsystem in Octane core) - perhaps in later versions of Octane rendering core the volume subsystem will be improved in this regard, but currently Octane can only render the mesh data for this purpose.

JimStar wrote:

coilbook wrote:it is non static topology. We use phoenix fd liquids

PhoenixFD is supported by Octane (in current TEST versions), and motion blur for its simulator object is supported too. But you can't talk about PhoenixFD liquids as "having non-static topology", 'cause they don't have any mesh topology at all. The PhoenixFD liquids are actually volume grids.
Octane rendering core currently does not support rendering a volumes as meshes with e.g. specular material applied. Currently Octane only supports rendering volume data as a volume. So, if you e.g. apply some emission to PhoenixFD liquid - it becomes visible, it will have a motion blur, but it will be rendered as a volume currently, not as a mesh - so it does not look like a liquid and it can't be used for that kind of rendering (see the example). I've just had a talk with haze (the guy who works on VDB subsystem in Octane core) - perhaps in later versions of Octane rendering core the volume subsystem will be improved in this regard, but currently Octane can only render the mesh data for this purpose.

1.png

Thank you for explaining! Yes you are right we do have to click preview as mesh in viewport to see it as a liquid during rendering otherwise Octane will not see it

coilbook wrote:Thank you for explaining! Yes you are right we do have to click preview as mesh in viewport to see it as a liquid during rendering otherwise Octane will not see it

Oops, I've just checked and it looks like the PhoenixFD support implementation in current test versions has broken the opportunity to render its simulator objects by Octane as a meshes when "Show mesh" is checked.
I'm going to fix it in next version, so - if the PhoenixFD simulator object will not have the OctaneVolume modifier applied to it, it will be considered a mesh by Octane...

But even if the "Show mesh" option is chosen, I don't see any new channel that looks like a velocity channel for that PhoenixFD mesh... As I said - I've already implemented the support of 3ds Max standard channel data as a velocity-data, but I've not seen so far any 3ds Max objects that generate this channel-data. The only object I've seen - is a 3ds Max' standard alembic object, but it screws up this data during generation...
So, this functionality is currently stubbed in a plugin. As soon as I see at least one 3ds Max object that properly generates this velocity channel data - I will un-stub this functionality.

I talked to Chaos again and they said they will be in touch with Otoy to help you get Octane to work with Phoenix FD. Hopefully it will work soon

Excellent, we look forward to hearing back from them

azen wrote:Excellent, we look forward to hearing back from them

Thanks This is forum linked where we discussed it http://forums.chaosgroup.com/showthread ... Phoenix-FD

Could you also reach out to them through this forum link or email (att: Ivaylo Katev or Svetlin Nikolov, Phoenix FD developer) just in case if they forgot since they seem very busy. Thank you

coilbook wrote:

azen wrote:Excellent, we look forward to hearing back from them

Thanks This is forum linked where we discussed it http://forums.chaosgroup.com/showthread ... Phoenix-FD

Could you also reach out to them through this forum link or email (att: Ivaylo Katev or Svetlin Nikolov, Phoenix FD developer) just in case if they forgot since they seem very busy. Thank you

Hi,

That is understandable. The best route would likely be email to the developers.