Testing releases threads are not for these discussions. They are for bugreports of current testing releases only, this is clearly stated in the rules there.
This must be your area of knowledge as an experienced 3ds Max artist - about "where you can get the velocity channel data from into your 3ds Max scene geometry object". The rendering plugin just reads this standard data supplied by 3ds Max from the object's standard data channels. If you are able to fill in any additional channel by this data (to not use the one screwed up by 3ds Max) - I could unblock this feature in plugin's code, and you will be able to choose this channel as the one that supplies the velocity data for an object. I've implemented this feature in a plugin a long time ago, but it does not make sense before 3ds Max bug is fixed, so it is stubbed currently.mikinik wrote:in what format is still possible to transmit information about motion vector data channel, except alembic?
As I already explained on this forum many times before - 3ds Max has an obvious critical bug in its Alembic subsystem. If you are experienced enough to understand this - I can give some more technical details about it:
When I investigated it some time ago - I even digged into disassebling of some parts of non-Octane code to be sure this is a bug. 3ds Max' alembic subsystem is clearly screwing up the velocity channel in all frames after the very first one (I explained it in details in my previous posts in old release threads). The other channels are OK, only velocity channel is broken. And as the disassembling had shown - this happens somewhere deeply in 3ds Max' AlembicImporter subsystem: the complex
non_topo_data data object (of type MeshDataInterpolated) filled in by this system has the full array of Vector3 values (representing velocities read from .abc file), but the flat array of float values stored in the same complex data object and representing the same data (just as a flat copy of the first one storing complex Vector3 objects) is screwed up when is filled in - so that these two arrays that must have absolutely the same data are already different on the stage of filling this data in from .abc file by 3ds Max' AlembicImporter subsystem. And exactly the second, screwed up array of float values is returned by this subsystem to the plugin as a "velocity channel data" (when a plugin calls something like UVVert *velocityMap = mesh->mapVerts(channelIndex);). So it's nothing to do with the plugin here. All I can do - just wait before Autodesk fixes this.I've checked VRay too during all these invesigations, just in case. VRay's rendering engine works very differently in comparison to Octane's GPU rendering core, so you can't rely on the assumption that if VRay plugin does something then Octane plugin must be able to do it the same way. In this case - VRay is able to generate its own velocity channel data for meshes with non-static topology. And VRay writes this data on top of the broken velocity channel data after it was read (and broken during it) from .abc file.
