OTOY Forums

Thanks coilbook, we're in touch with Svetlin.

This is a reply from RedShift team about supporting liquid motion blur:

"Hello Greg,

Yes, we plan on adding support soon for using motion vector information from realflow to support motion blur with changing topology.

Best regards,

Nicolas"

I guess they do not know about API bug. But if those guys will get liquid motion blur before Octane 3ds max will, since octane motion blur has been around for 2 years, it will be a big shame. We will see who will get mb first for liquids in 3ds max.

JimStar, hi! please explain why you can't make an import alembic file using octane proxy, in bypassing 3ds max?

coilbook wrote:I guess they do not know about API bug. But if those guys will get liquid motion blur before Octane 3ds max will, since octane motion blur has been around for 2 years, it will be a big shame. We will see who will get mb first for liquids in 3ds max.

There is nothing to be "a big shame" for Octane here, please read carefully the detailed explanations I have already given many times before.
It is not a renderer-plugin's responsibility to generate and expose the velocity vectors channel for any 3ds Max' native or third-party plugin's geometry. Octane plugin is a rendering plugin, not a geometry generator plugin or alembic-wrapper plugin. Octane rendering core must have the velocity channel supplied by geometry object (that is by geometry generator plugin, or by 3ds Max native geometry object) to render vertex motion blur for non-constant topology meshes. This channel must be supplied together with all other geometry object's data (UV channels, etc...), and this must be done by the supplier of this geometry. Octane is nothing to do with this. Octane renderer is just a consumer of this data, no matter is it a plugin or Octane standalone application - this is how Octane rendering core works. Standalone will not render any vertex MB for non-constant topology mesh too, if velocity vectors data is not present for this mesh in an input.

As I already wrote - currently there is only one object in 3ds Max that at least tries to supply the velocity channel to rendering plugins - this is an alembic object. And currently this object completely screws up this supplied channel's data, so there is no use for this data for others (but at least - nice try ). There are no other known objects that supply velocity channel with their geometry, including PhoenixFD simulator object. Before starting to blame Octane you should have at least open the channels list of any PhoenixFD simulator object and see that there is no velocity channel present in it. So, all what the PhoenixFD team is going to do (after I've explained this to Svetlin) - is just expose the velocity channel data of PhoenixFD simulator geometry (which this object must already have internally) to outside world, among other geometry's channels, so that other (e.g. rendering) plugins can access it. This does not mean that "those guys will get liquid motion blur" because PhoenixFD is not a rendering engine to "get motion blur". But what it can do - is supply the velocity channel to other (rendering) plugins, so that those plugins can use this data and "get motion blur" rendered.

So, I've already wrote this a long time ago: as soon as you find at least one 3ds Max object that supplies velocity vectors channel with its non-constant topology geometry - Octane plugin will immediately be able to render MB for this object properly. If PhoenixFD simulator object will be the first of those and will do it properly (in contrast to 3ds Max alembic object) - this will be the first 3ds Max non-constant topology geometry, vertex motion blur for which is rendered properly by Octane.

Sorry, JimStar I did not mean it in that content. RedShift is also GPu renderer so if they can get it to work I see no reason why Octane cannot do it since it is way more advanced than redshift.

p.s. by the way did autodesk ever responded? how can we fix it if they will never respond. So if they never respond OCtane will never have mb for liquids.

3ds max octane is the largest community and stuff like mb for liquids should be number one priority to get it working since more and more people use Octane for animation.

"So, I've already wrote this a long time ago: as soon as you find at least one 3ds Max object that supplies velocity vectors channel with its non-constant topology geometry - Octane plugin will immediately be able to render MB for this object properly."

RealFlow does not, Phoenix does not. Lucid does not . Does it mean we will never see it? Ireally dont know what to do. We have tons of ideas with water animation but no mb. All other renderers can do it and my favorite one cannot

By the way how come iRay and VRay RT both GPU rednerers can have motion blur for liquids?

coilbook
RedShift is a biased renderer, it uses absolutely different rendering principles and has different rendering engine. So you can't compare them in many aspects. As I wrote - Octane rendering core must have the velocity vectors channel for a non-constant topology meshes supplied with these meshes to render vertex MB for them. Period.
In contrast to that (again, as I already mentioned previously) - e.g. VRay does not need this velocity channel supplied from outside too. Thus it deals OK with 3ds Max alembic object's crappy data - it just does not use the velocity channel "supplied" by it.

If in later versions Octane rendering core will become able to render vertex MB for non-constant topology without velocity vectors data in an input - then automatically any Octane plugin too will become able to render any such non-constant geometry without requirement of its velocity channel to be supplied. But this could only be implemented on the Octane rendering core level (if at all), not on a plugin's level.
So, it looks like your concern here is more about the Octane rendering core itself in general, not about 3ds Max plugin. Thus it could make more sense for you to ask in the standalone section of the forum about the possibility of implementation of vertex MB for non-constant topology meshes without mandatory requirement to have the vertex velocities data in a mesh's data input...

JimStar wrote:coilbook
RedShift is a biased renderer, it uses absolutely different rendering principles and has different rendering engine. So you can't compare them in many aspects. As I wrote - Octane rendering core must have the velocity vectors channel for a non-constant topology meshes supplied with these meshes to render vertex MB for them. Period.
In contrast to that (again, as I already mentioned previously) - e.g. VRay does not need this velocity channel supplied from outside too. Thus it deals OK with 3ds Max alembic object's crappy data - it just does not use the velocity channel "supplied" by it.

If in later versions Octane rendering core will become able to render vertex MB for non-constant topology without velocity vectors data in an input - then automatically any Octane plugin too will become able to render any such non-constant geometry without requirement of its velocity channel to be supplied. But this could only be implemented on the Octane rendering core level (if at all), not on a plugin's level.
So, it looks like your concern here is more about the Octane rendering core itself in general, not about 3ds Max plugin. Thus it could make more sense for you to ask in the standalone section of the forum about the possibility of implementation of vertex MB for non-constant topology meshes without mandatory requirement to have the vertex velocities data in a mesh's data input...

Thank you for explaining. I will ask them.

JimStar wrote:In contrast to that (again, as I already mentioned previously) - e.g. VRay does not need this velocity channel supplied from outside too.

Are you sure? after clearing velocities channel. How is it that, nothing is generated? vrayRT too, that does not generate, just can't.
How can it work without data on velocities channel? Where a render can take this information? As renderer can generate velocity information if the first frame number vertex = 1, and in the last their 100, trace location one vertex in neighboring frames not succeed.

Here in this forum thread becomes clear that the velocities information is needed renderer. http://forums.chaosgroup.com/showthread ... velocities

I suspect that you're lying. If information is generated by the renderer, why it does not produce on the geometry directly from 3DS Max. Why did import the file through a proxy? I think the vray developers have done this on purpose to circumvent 3DS max, namely, the error of which you speak, and get velocity data directly to the render.

coilbook wrote:I will ask them.

I know answer.