Batch Rendering Inefficiencies with 2.7

  • Just a few quick comments:


    As far as I know, the Revit api does not offer a way to tell whether 2 views have the exact same geometry. Even if they share a viewtemplate that locks all values, there are still things like hide in view, section box, view phases, temporary hide, temporary view,... I think it makes more sense to leave the call to the user: update each view while batch rendering or not?


    It would be nice if Enscape could save time of day and camera position in the render settings. That way it would be much easier to make reproduceable rendering. However, I don't think this is likely to happen.


    I agree that it would at least help if we could update a camera from within Enscape, (updating both camera position and sun position) (unless of course there's a view template that locks the lighting settings). This could be done with an extra button in the menu, but even better would be a 'camera manager' layover panel in the Enscape render window (similar to the camera editor from the video tool) that shows you the name of the active camera and time of day and has buttons for "update camera", "save new camera", "save settings" , ...etc


    Personally, I wouldn't focus too much on view templates. Enscape exists on 5 platforms. I think the cleaner solutions are going to be the ones that build on generic concepts that exists on all platforms. Although they are named differently in each platform each program has the concept of a 'camera/view', so it makes sense to use that as a corner stone of Enscape's system. View templates don't really exist as a concept in Sketchup and Rhino for instance.


    We use Enscape's Revit, Sketchup and Rhino version and love when the experience is consistent across the different platforms. It also makes it easier to follow tutorials from another platform and share tips&tricks etc. I wouldn't be surprised if it helps development as well if the 5 platforms are working in a similar way.

  • It would be nice if Enscape could save time of day and camera position in the render settings. That way it would be much easier to make reproduceable rendering. However, I don't think this is likely to happen.

    I believe it is inevitable that Enscape will mimic what Lumion, Unreal, D5, etc do with "Scenes" that save all render settings, and a "Timeline" that allows one to arrange the "Scenes". It seems very popular and has strong advantages. It also fits right within Enscape's "ease of use" philosophy. I am not really a fan of "quasi-video editing" within a rendering package, but I suspect that I am in the minority with that opinion.

  • Pieter Your point about a level playing field across the applications is well taken.


    Pieter  renderwiz i'm interpreting your above points support the idea of having Enscape handling the properties of the view directly in its own UI, is that correct?


    Like...are we suggesting that Enscape control the below elements within its own dialogue box (it will basically have its own VGO Panel)???


    aka..all of the below controled DIRECTLY in Enscape UI (not pulled from a view's view properties)


    Model Categories and Subcategories

    Imported Categories

    Filters

    Worksets

    Design Options

    Detail Level

    Parts Visibility

    Discipline Setting

    Lighting Settings

    Phasing

    Phase Filter

    Section Box

    Temporary Hide/Isolation

    Manual Override by Element

    Linked File properties for all of the above

  • No because these concepts only exist in Revit. For me it makes sense that these things are left to the host application which already has many tools (like view templates) to handle all these settings efficiently. It would also be a gigantic development effort.


    The only 2 settings that I'd like to be governed by Enscape (in an ideal world) are the camera positions and sun position. You would still select a revit view from which Enscape should get the geometry, but camera positions and sun positions would be managed by Enscape. This is similar to how many other applications do this (as mentioned by renderwiz). It's interesting that you can re-use a revit view as an Enscape view, but it's kind of limiting that you NEED a revit view if you want to save a camera position or time of day in Enscape.


    But like I said, I think given the current implementation that's unlikely to happen. And there might be other solutions to get to easily reproduceable renders. Like suggested in the other tread, an easier way to update cameras (so we can tweak camera position and time of day and save that back to the camera) would be a good step in the right direction without needing a major overhaul.

  • No because these concepts only exist in Revit. For me it makes sense that these things are left to the host application which already has many tools (like view templates) to handle all these settings efficiently. It would also be a gigantic development effort.


    The only 2 settings that I'd like to be governed by Enscape (in an ideal world) are the camera positions and sun position. You would still select a revit view from which Enscape should get the geometry, but camera positions and sun positions would be managed by Enscape. This is similar to how many other applications do this (as mentioned by renderwiz). It's interesting that you can re-use a revit view as an Enscape view, but it's kind of limiting that you NEED a revit view if you want to save a camera position or time of day in Enscape.


    But like I said, I think given the current implementation that's unlikely to happen. And there might be other solutions to get to easily reproduceable renders. Like suggested in the other tread, an easier way to update cameras (so we can tweak camera position and time of day and save that back to the camera) would be a good step in the right direction without needing a major overhaul.

    Pieter not sure I agree with you. They've already implemented a BIM mode. It seems like the only way to really solve the problem. Anything else is a workaround.

  • 30 views in a few minutes vs 5-10 times longer isn't very specific. For example 30 views in 2 minutes vs. 10-15 minutes IMO is worth the wait for the ability for each view to render with respect to view properties. In previous versions if you wanted to render views with different view settings you would have to manually make each view the active document and then select the render button. To do this for 30 views was a very tedious process probably taking nearly an hour. Now it is much faster taking only 10 minutes.

    I'm a little late coming back to this. As others have said, you're right, under some scenarios the new batch rendering works great. But for some workflows, like at the firm I work for, we sometimes need up to 150 views, all with the same exact view settings. So in our case, this went from a half an hour process to over 3-4 hours.... and this is on a $7,000 render computer...

    I think all we need is a way to toggle which default setting we want. That would solve all of the problems people have mentioned in this thread