+- tyFlow Forum (https://forum.tyflow.com)
+-- Forum: tyFlow Discussion (https://forum.tyflow.com/forum-1.html)
+--- Forum: General Discussion (https://forum.tyflow.com/forum-2.html)
+--- Thread: issue with Drone rotation value (/thread-4145.html)
issue with Drone rotation value - Wintermute84 - 03-04-2024
Hello! First post, sorry if it's a bit lengthy. I'm creating a tyFlow setup with drones. Simple setup, a drone body with four rotating blades as a tyActor in the event. The blades will have a looping animation while the movement of the drone will be controlled within the tyflow event. The problem I'm having is the blade's rotation speed, and the apparent limit when these drones are placed in tyFlow.
Anytime I raise the rotational value on the source geometry's looping animation to go beyond 180 degrees per frame, tyflow cannot accurately recreate this rotational value, at least when exported as an object which is necessary for our renders.
My drone needs to have a very high rotation for proper motion blur, comparable to the rotation speed of real life drone blades (maybe 1,000 to 2,000 degrees per frame by my math). Raising VRay's motion blur samples or adjusting camera shutter speeds does not resolve this.
Also, I realize working with rotation in 3ds max has it's own built in hurdles which may be causing this but if anyone has any input, it would be greatly appreciated. Thanks!
RE: issue with Drone rotation value - tyFlow - 03-04-2024
So there's a couple of considerations here. Firstly, to capture the fast motion in your particles you need to reduce your sim timestep and also enable cache subframes in the Cache rollout. That will properly transfer the fast motion to your particles. However, the Export Particles operator only sets whole-frame keys on exported particle transforms. That's an oversight on my part...I will make a note to have it export keys on subframes if the sim has a subframe timestep. The next build should be out soon, so check for that update in v1.106.
RE: issue with Drone rotation value - Wintermute84 - 03-04-2024
Hey Tyson! Thanks for your input and thanks for tyflow
what you've said makes sense now that I think about it. And while I do need this for exported object particles to render, I've attempted to reduce the sim timestep (with cache subframes enabled) on every possible frame level just to see if tyflow can correctly local render the blade rotation value from the source geometry, before exporting (I'm assuming you're referring to the time step dropdown for 1/2, 1/4 frame etc. in the modifier stack, unless there's another one).Unfortunately, the rotational values are still not lining up with the source geometry
This is evident in local renders with motion blur enabled and sometimes in the viewport, the results seem to be the same as exported particles.... unless I'm missing something...?But again, thank you for your input, and future build changes that may address the exporting method.
RE: issue with Drone rotation value - tyFlow - 03-05-2024
I'll dig a bit deeper to see what's going on...either way, should be fixed up in v1.106.
RE: issue with Drone rotation value - tyFlow - 03-05-2024
Ah, there's a key setting I forgot about - in the tyActor helper, disable "simple interpolation". When enabled, tyActors will only sample whole animation frames. When disabled, tyActors will sample all relevant subframes as well.
That said, I'm seeing some weirdness occurring on timesteps not evenly divisible by scene ticks...so still something that needs to be fixed in the next build.
RE: issue with Drone rotation value - Wintermute84 - 03-07-2024
(03-05-2024, 01:42 AM)tyFlow Wrote: Ah, there's a key setting I forgot about - in the tyActor helper, disable "simple interpolation". When enabled, tyActors will only sample whole animation frames. When disabled, tyActors will sample all relevant subframes as well.
That said, I'm seeing some weirdness occurring on timesteps not evenly divisible by scene ticks...so still something that needs to be fixed in the next build.
Hey Tyson, I just updated my tyflow to v1.106 and applied all the settings you've suggested so far and the problem still persists :/ when I'm rendering with my tyflow drone setup and the source geometry present, the rotation and motion blur are still not matched. And exporting the particles with all the suggestions applied produces particles that have zeroed out values on their rotation in xyz (and scale is zeroed out as well). I just wanted to bring this to your attention in case you had a different approach within this new build. And thank you again for your input on this
RE: issue with Drone rotation value - Wintermute84 - 03-15-2024
Hey, just wanted to say thanks again! I saw your reply in my 'v1.106 subframe keys bug' post, and after disabling the 'scale to size: 0', I now have the necessary high rotational values on my exported drone blades.
One minor issue, the rotational value still isn't a direct translation. Reducing the time step gets closer and closer and with '1/32 frame', it gets very close. I'm including a screenshot of the curve editor showing the differences.
For my drone project, I only needed a high enough value to achieve the proper motion blur, so these current results work for me! I just wanted to bring this to your attention, should it affect any similar projects that reference this post in the future.
Maybe a potential feature in the future could be implemented in which keys can be directly copied from referenced geometry, instead of baking them (if this isn't already possible)? But that may be rather complicated and only applicable in specific situations.
RE: issue with Drone rotation value - tyFlow - 03-16-2024
Yes in the case of your scene, the rotation won't be exactly the same because the tick(s) from where the rotation values are sourced are not the same ticks where they are applied, due to the time step not being evenly divisible by the frame tick count (it's a rounding issue). Luckily that issue won't be something that really matters considering it'll only happen in situations where objects are spinning too quickly to ever visibly be able to determine their exact angular velocity.