First I want to build a simple MVP and see if it’s actually useful.
The goal would definitely be to keep it simple and accessible though.
But the idea would definitely be something simple and accessible, not a heavy tool like Bongo.
I made a very early UI mockup to illustrate the idea.
This is just a concept, but it shows the timeline / clips approach I had in mind.
The goal is to keep things simple: camera keyframes and basic object animations.
Would something like this make sense?
It’s a tricky exercise to create a balance. If you keep the UI too simple it creates issues later. Do you use after effects much? I think what you have is similar in terms of organisation, and it’s a good direction to head in.
In terms of use, I’m imagining simple “exploded” animations for assembly, possibly with a widget for the timeline that you can use while talking through something.
With too many objects (architectural scene) it does not work very well and the file gets bloated quickly. You also have to be very careful to not mess up everything.
That’s why I suggested the .usd approach. The format is well thought out and the non-destructive approach can also be realized with Rhino. Of course you may just support the features you need, but if your project becomes more serious then it is open to connect to other packages.
Hi @Jess ,
Good point. I was not planning to rely on Rhino snapshots.
The first idea would be to store only the animation data (timeline, clips, transforms) in plugin data, keeping everything lightweight and non-destructive.
Maybe later I could improve the data store, but for the MVP I want to keep things simple.
The idea is to keep it simple, efficient and affordable
I think that might be true for a very rough proof-of-concept, but building something actually usable inside Rhino is quite a bit more work.
Even a minimal MVP already involves:
• a timeline UI with tracks, clips, selection, resizing, scrolling, etc.
• synchronizing the timeline with the Rhino viewport
• non-destructive animation evaluation (no object modification)
• playback with consistent timing
• storing animation data in the Rhino document
• camera interpolation and preview
• export to video from the viewport
• handling large scenes without slowing Rhino down
• making the UI responsive and usable (zoom, snapping, etc.)
An AI can definitely help generating parts of this, but stitching everything together into something stable and usable inside Rhino still takes time.
I’ve been using AI for about 2 years, it is a very helpful coding assistant for some use cases. But it is not realistic to think that AI can code such a plugin in 2 days.
As an example, I’m the creator of SmartPieMenu (radial menu plugin for rhino). It is a 20 000 lines of code plugin, I built it with help of AI for some tricky parts, but AI just can’t consistently manage a repository of 20 000 lines of code or huge architecture projects. Except if you pay 1000$ a week for it.
Another example, the UI prototype I posted few hours earlier in this thread took me about 3 days, and it’s just an MVP. There are many reasons I spent 3 days, one of these is that I have a custom UI library that is 100% OS native, fully GPU accelerated, and runs at 60 FPS consistently (and more). I built it for my first plugin and reuse it now.
So yes, a quick prototype might be possible in a short time, but a practical MVP that people can actually use is a bit more involved
Absolutely! I tried to make a .usd importer but it was not easy for crossplatform use. So I switched to mac-only using RealityKit which supports USD format and it worked quite nice. The interest for my project are humanoids and animation and keeping an eye on interoperability.
I quite like Bongo for animation, Rhino+Bongo is one of the few combinations that I can use to create animations that include pointclouds from 3D scanners.
Here is an early-stage concept video running directly inside Rhino.
This shows very basic keyframe animation with a simple timeline and playhead.
Still very early, but it already helps validating the workflow.
Will you support Snapshots, Named Views, Named Positions and Layer States? Then it would be very usefull. Clipping Planes would be great to have animated while designing and presenting and not just saved and restored as Named Positions,
Remember to include Light Objects, which could change both positions and directions but also colour/intensity and Camera Objects, which could change positions of both Camera and Target but also FOV and Parallel/Perspective mode.
I understand your thoughts. I still recommend looking into Layer States as a minimum, since that is NOT (yet) possible using external alternatives such as KeyShot. Moving things around using a timeline is helpfull but you can use Named Positions for that.
I had for my Daxs Plugin (Gamepad Support for Rhino) something similar (but much more simplistic - without animating objects) in mind to add in the future. While Daxs can do realtime ultra smooth camera fly or walk throughs, i see the the potential to save/ replay the camera tracking path in a way, so it would be possible to manipulate the scene and render it afterwards in better quality. What you have shown so far could be really, really cool.
I would love to have a way to generate a simple camera track, either via an API call or by exporting/importing curves and planes for use in your framework.
Here is another very early demo, this time with simple object translation.
Still very basic, but it shows the idea of quick, non-destructive animation directly inside Rhino.
Goal is still to keep things simple and fast for quick presentation videos.
Still a lot of work, but work in progress
Hi, it’s just a very early stage demo to demonstrate what I want to do and receive some feedbacks to know if Rhino users would be interested in such plugin.
So there are still many things that could look « weird » or wrong.
I’ll post soon a new work in progress video, but still with inverted axis. It’s not the priority, same for the UI design that is ugly but just for testing purposes.
Even a simpler thing like this is a lot of work
