Hi,
I read at spot3d.com
Fly-through - this will compute a light cache for an entire fly-through animation, assuming that the camera position/orientation is the only thing that changes. The movement of the camera in the active time segment only is taken in consideration. Note that it may be better to use World Scale for fly-through animations. The light cache is computed only at the first rendered frame and is reused without changes for subsequent frames.
So, so far I know, the fly-trough option isn’t build in to VfR now. But couldn’t this function be implemented, if the user selected a curve (camera path), so that VfR know, which way the camera will fly?
-Micha
Re: Fly-through mode for Animations
The issue at the moment is that Vray must sample ALL the points on the animationto determine the calculations for LC passes. Right now (especially with Rhino’s built in animation tools) Rhino does not export any data beyond the exact frame in which it is rendering. As you’ll recall this is essentially the same issue with motion blur. Working with Bongo, the solution (although not currently implemented) has to do with manually generating all of the data for the whole animation sequence by progressing through all of the frames via the bongo timeline in a “pre-pre render pass”.
With Rhino’s built in animation tools its much harder because there is no directly accessible evidence/marker of the camera’s position through the rendering. What I mean by that is that vray would require much more information to process that kind of data from Rhino’s built in animation tools…ie which curves, how many frames, animation type… which would have to be generated/“found” ourselves on top of generating all of the camera information that would result from that.
In the end, the animation implementation isn’t even there at the moment, but as it stands there are extra steps to connect any animation implementation to use Rhino’s built in animation tools. Hopefully that explains things a little bit more
Re: Fly-through mode for Animations
I suppose so, I don’t explain it enough. I don’t want to get LC calculation along an automatic detected path per Bongo. My request is, why not add a option at the “fly-trough” feature - “select camera path”. So, Vray could know, which path will be used. OK, only simple fly-throughs with a single path are possible, but for many cases good enough. From the infos at spot3d I understand, that only the path is needed for the LC calculation.
I got the idea of “path selction” from the Rhino render plugin AIR - screenshot attached. The user create a path, set a curve name and choose the path name from the flytrough menu.
Like for the motion blur, I think, it’s possible to implement simple solutions without big effort. Motion blur for design renderings (like Maxwell), single path flythrough for LC architecture animation (like AIR).
Re: Fly-through mode for Animations
Micha,
Bongo, Rhino’s built-in animation tools, and motion blur are all the same issue. You explained yourself fine, but please read my explanation. The heart of the issue is that Vray needs to know where the camera’s been and where the camera is going. Right now, Rhino does not export any of that information to us, which means we have to generate it ourselves.
Re: Fly-through mode for Animations
No no, not Bongo, object motion blur for single images like the Maxwell solution. Not for animation, but best for design visualisations or architecture viz with moving cars and people. Vray needs the infos, what the direction of movement is, right? For single images it should be no problem, like the Maxwell plugin show. I try it - it’s very nice and simple.
Re: Fly-through mode for Animations
That would be very very nice !
Renee
Re: Fly-through mode for Animations
As far as I know object HAVE to be animated in order to generate any vector/motion information that can be used for motion blur.
Re: Fly-through mode for Animations
At Maxwell the user save an initial position and move/rotate the object to a new position. Now, the render engine know both positions and the motion/vector is defined.
Re: Fly-through mode for Animations
So how is that different from doing that via different key frames?..doing some very simple motion blur (like people in a scene) doesn’t require more than keying two frames, with a slight change from one to the other. Although a timeline isn’t involved for the Maxwell thing, its just about the same…set position one, then position two…done.
Just to clarify (because I think there might be some miscommunication on this), but you don’t have to be rendering out a whole sequence to get Motion Blur. It can be rendered for a single image.
Re: Fly-through mode for Animations
I’m not sure I understand the last answer. I mean, since Bongo give no data about the animation, why not implement an easy solution without Bongo? Yes, the position change between two keyframes could be used, but you say, it’s a problem, so why not an easy solution? I wonder me, that my request cause so much posts. Is Bongo a problem or not? If yes, an easy solution ala Maxwell could be great, if Bongo is no problem, than it could be used. Bbut don’t forget, 500,- € for this little animation tool is much money, so the Maxwell solution could be good for any Rhino user. 
Only I want, if my clients need a photo rendering with an object in motion, I want to be able to create it. No animation, no bongo, single photo rendering.
Re: Fly-through mode for Animations
There’s no problem with Bongo, its simply that we need to get the animation information in a particular way in order to create any LC flythroughs or motion blur. We just need to take the steps to implement it. The reason why its not there at the moment is because the demand for animation within Rhino is relatively small so we’ve chosen to focus our resources into features that are much more valuable and usable for the large majority of our users (ie floating licenses).
This is of course, the wish forum, so I’m not discounting the wish. I think for people who want to do some small motion blur things and use Rhino’s built-in animation tools then there’s no need to bring Bongo into the picture, yet they should still be able to use those features if thats what they need. Two things to keep in mind though…first, when it comes down to it, whether its through bongo or not, we still need to retrieve/generate the data to do those calculations…and secondly, when not using bongo, implementing those features requires additional UI and workflow considerations, which only means that there is more involved in adding those.
Re: Fly-through mode for Animations
Hm, I mean motion blur not for animation tools and not for Bongo, simple like Maxwell, for all still image render users. I can’t belive that implement a new UI needs a so big effort. An object based properties page for Vray is needed by all means for visibility options and other object related settings. A little motion blur option should not be a problem.
I don’t use Maxwell, because it’s to slow, but the plugin development is impressiv, some interesting innovative features (visible env at the background …) and many basic features like visibility options.
Re: Fly-through mode for Animations
I’m not sure what your not getting, but whether you’re doing an “animation” or not, we will still need to generate the same data. Bongo or another separate “non-animation” solution doesn’t matter, what matters is that we will need to make some additions to the scene export process to do it. I don’t know how many other ways to say it other than that.
I can’t belive that implement a new UI needs a so big effort.
The last thing we want to do is add to the UI issues that we already have. Any new UI is going to need to have much more consideration to its design then we’ve had before. If you want another thing thats going to be clunky and have an unstreamlined workflow, then we can get you a UI pretty quick. I’d prefer not.
Re: Fly-through mode for Animations
I mean, Bongo is the only tool for object animation. This tool is quite expensive for the little basic animation functions. An animation independent object motion blur could be good for any designer or architect to get a nice motion effect at still images without to pay 500,- € extra. So, a Bongo independent solution is it worth to implement.
And what’s the problem to tell Vray at which way should be collected LC samples? Do I understand right, the fly-trough function needs only a path, no camera anggle, no camera direction, only the places there the camera will be? If it is so easy, why not let the user select a path curve?
Re: Fly-through mode for Animations
… an other thought about Bongo and motion blur: how many percent of the Rhino user are Vray user? How many user of the Vray user are Bongo user? How many Vray+Bongo users need motion blur for object animations? How often need this user rendered motion blur?
Motion blur for all still image VfR users could be great.
I remember me on an animtion that I have rendered some years befor - I add a motion blur effect per video filter of Virtualdub.
Object based motion blur for design renderings could be great to show moving design details at stills without extra cost. (Hmm, on the other side, if one of my clients needed it, than I could use my dusty Maxwell license.)
Re: Fly-through mode for Animations
(Hmm, on the other side, if one of my clients needed it, than I could use my dusty Maxwell license.)
Which would again take years ;D. In a pinch I would actually render out two passes…one of the main scene, and one of what you would like to be motion blurred. Then in photoshop you can comp them together and get a motion blur effect by the Motion Blur filter on just the second layer. Fairly simple and takes an extra 3 minutes as opposed to days with the other option.
Re: Fly-through mode for Animations
Yes, this would be fast. If the user need, that shadows and reflections match perfect, a good workflow would be:
* render scene with object invisible for camera (to get the scene with shadows and reflections of the object)
* renderwindow of the object with mask channel (render object with all shadows and reflections from the scene)
It’s a pity, that mask channel and object visibility are not direct supported (basic options, very old wish), newer users must look at the forum for the workarounds. :-\
Also, Photoshop can be used for linear motion parallel to the screen only, other directions are not so easy.
Re: Fly-through mode for Animations
Motion blur as suggested workflow above, then use a perspective distortion…I’ll play around a little today if you need an example.
Yea, we need to get all the rest of the channels in there as well.
Re: Fly-through mode for Animations
An other question: in which 3D space is the LC calculated?
For example I render an object from one side and save IM/LC. Than I render the object from the other side based on LC/IM cache. It looks bad, because the IM has sampled at the visible areas of the first rendering only, that’s right. So, I enable “incremental add ..” for the IM. Now, the IM cover the whole object. The LC cache too? I set my object to a chrom material and enable “use for glossy rays”. Anything looks perfect, based on the cache of the first rendering.
So, is it right, that I need one LC calculation and a handfull IM calculations as basic for a turntable animation?
So, if the LC calculate the whole scene, what is the limit? If I render an interior with three rooms, will I get a LC cache for all rooms per single rendering of the first room?
Re: Fly-through mode for Animations
The way LC is structured you cannot add to the solution after it has been compiled from the generating raycasting structure to the sampled points. The solution is automatically compiled when the solution is finished. Therefore a saved LC map cannot be added to in the same way a saved IR map can be added to. The only way to really do that is to sample multiple camera locations which is what Flythrough Mode does. This basically means that until we add Flythrough mode you will need an LC calc for every frame, and in its current form you would only be able to use this for animations. IOW having a list of views within the scene would not work with LC compiling into one map.
With the exception of Photon Mapping/Caustics all of the other calculation methods are view dependant, meaning that they will only be valid for the view that rendered the solution.
