Unless I’m missing something (which I might be!) there is no way to enter camera position/rotation explicitly? It is only set with a keyframe after navigating with the mouse and keyboard, which makes it nearly impossible to get a perfectly straight camera pan. (As a workaround, I have been editing the .xml file which works but is kind of annoying)
I think it would also be great if the paths could reference existing curves in rhino to give more complete control.
Hey @cwm_1 , thanks a lot for your post. There is indeed no way to enter the camera position/rotation explicitly. I can gladly file this wish as a corresponding feature request - maybe you have specific idea in mind how the camera position (in which form) especially would be entered? Regarding the second wish, so you have a curve in Rhino, to which keyframes would be automatically attached (when placing keyframes in Enscape near, or on the curve), or how do you envision that exactly?
Thanks a lot in advance for your further feedback. You can share your thoughts/ideas to these subjects in as much detail as you like, so that I’ll be able to file faithful requests to our agenda which reflect exactly what you’d like to see implemented into Enscape!
@cwm_1 You could shift your workflow more to Rhino. You save the fine adjusted key views of your animation at Rhino and later you recall view by view and press the “k” button. I was gone this way I created my last Enscape animation.
I would like to edit the Enscape camera path too, maybe it could be possible to export the Enscape path (and cameras) back to Rhino and later forward to Enscape again.
@cwm_1 But maybe you find a Rhino script writer who can read the Enscape xml file to Rhino and later write it back. So, maybe you get the wanted tool faster than waiting for more votes at the developing agenda.
With the rhino curve, I imagine the camera position moving along the rhino curve. The total duration of the shot would be entered by the user into enscape. There would be an option for the velocity to be either constant along the curve, or to use the parameterization of the curve to determine velocity.
There would still need to be keyframes for camera rotation. The user would add them at user-determined timestamps, and could edit the rotation values explicitly. I don’t have a personal preference for the form of the rotation, just something that would let me get a fixed angle for a pan.
The user could add as many curves as they wanted, and go through the same process for all of them, effectively creating a sequence of shots. (the shots could also be created with the keyframe method of course!) They could then save out all the shots as a single video file, or batch render the videos as individual files.
I see @cwm_1 , thanks a lot for the further detailed response. I’ll file this subject as a dedicated feature request accordingly. We’ll also add further improvements with 2.5 to allow for better/smoother camera paths overall, so stay tuned for that!
Also @Micha , would you like me to file what you’ve requested as feature request as well? Is there anything you wanna add to it, or maybe you want to briefly generally elaborate what you wish to see implemented exactly?
@Demian_Gutberlet I don’t feel so comfortable to adjust the camera in the Enscape environment. Maybe it would helpful if the camera path could be edit by moving the path from “outside” like I can do in Rhino. For example my paths shoot through a space divider of an interior and it would be easier to adjust the path, if the path could edit by not viewing through a camera. Also it would be nice, if additional control points could be added, without to add a camera at this place.
I would very much support further development of the video tools - but only toward to the point of setup/creation (post-editing can, and arguably should be done elsewhere) insomuch, it would be great to get:
Explicit “classic” camera moves (i.e. dolly, tilt, track, pan, etc)
Closed-loop paths (return position to 0)
Fixed-target (camera movement free but always facing)
…and, most importantly, stacked/batched outputs… so that we can cue a series of short-shots then smash render-run, head home for the day and return to a set of video files - which we can hot-swap in as references to more extensive post-production workflows.
(use case example) we do an extensive amount of design optioneering - and we would love to have the means to establish a consistent (speed, distance-from and focus) “turntable” shot, then set it to run a (batch) exports of a series of design scenarios to output a bin of video files that we could then blended into one another (in Premiere)
Whilst there’s no hardship cutting out the b-roll bits between shots from a “freeroam” recording IRL - rendering those frames for no reason is another matter altogether!
@jvrmartinns you need grasshopper, were you able to open the gh file? it’s literally just generating the camera coordinates (as text) along a path that you can then bring back into enscape using the xml file. Did anyone else get that to work?
I believe setting up enscape video paths is easier now, but still there isn’t the level of granularity a camera position and target curve offer. Further to Nick’s script, here is a GrasshopperPlayer script with a few more inputs. It builds the *.xml as a function of:
rhino file units (from my understanding enscape requires the xml units to always be in meters)
camera position curve
camera target curve
desired number of keyframes in the enscape video editor, this controls how closely the effective camera path will follow (this previewed in the viewport)
a video clip start time [h] for the sun position
a video clip end time [h] for the sun position
a video clip duration
The GrasshopperPlayer script outputs the contents of the *.xml which must then be saved manually. This should be easy to use and may be run using the GrasshopperPlayer command.
For quick interation, the second, standard grasshopper script below is more suitable as the outputs from the panel may be streamed to the desired *.xml file live as the input curves are changed in the viewport.
This is great, thanks for posting and sharing (and for picking the thread back up after four years)!
One question for you and anyone following along: if this were native in Enscape, what would the ideal version look like? Curves picked from the host model with a live-updating preview, or an import/export round trip so the path can be authored and re-edited outside? We’d rather build from how you’d actually want to work than guessing at it so please let us know what the ideal workflow for you looks like!
Both Enscape and the host applications have changed quite a lot since the thread started, so we just want to be sure that future development aligns with what you need!