Enscape settings in the cloud please

  • Hi,


    In many situations several people work on the same design and images must look the same for a coherent presentation.

    So usually we send to each other the xml files from C:\Users\“username” \Documents\Enscape\Settings


    This workflow is not so great though. Once some adjustment is done then the files have to be copied again.

    So could you place the xml file in the enscape cloud and make it sharable somehow between users?


    Thank you!

  • I think even better would be to save the settings in the Enscape 'favorite' views. That way you don't have to worry about loading the right file for the right view. It will also be easier to do batch rendering because each view can have unique settings (different time of day, exposure, fov, dof, ...)

  • Well I organize by view, let's say I have one view: Building entrance, and 3 presets for it Morning, Mid day, Evening.

    So then if I have an adjustment of the camera: Building entrance v2, I just save the view and I use the same presets for the time of the day from before.


    So I don't have to make another set of presets for my second camera.

    It could also happen that someone else might want to use the Morning preset for a completely different camera.

  • I see what you're saying, but in our case there's almost always one setting that will be unique to that view. It's not just time of day that changes.


    - FOV narrower or wider

    - DOF on or off (or different focus)

    - interior image needs different exposure than exterior (even if at same time of day)

    - Image adjustments (contrast, saturation, lensflare etc)

  • We literally make thousands of Enscape shots a year. Each one with slightly different settings. It would be an impossible search for us. I don't need an extra file, I need it embedded in my project so I don't have to think about it.

  • Hmm, not sure how easy would be for one software so save information in another's software file format, it would need some development from McNeel.


    But, I can imagine Enscape picking up some attributes which are already in Rhino.
    Some are saved in the 3dm file and picked up by enscape for camera synchronization. For example:

    Camera position, Fov.


    Moving further, I see that Rhino6 has the "Attribute user text" in place for geometry. So for geometry I could setup any information to be picked up by any software.

    If they setup attributes for named views or cameras in Rhino then the process could be quite clean. Enscape would write those attributes in the 3dm file and read them later.

  • Hmm, not sure how easy would be for one software so save information in another's software file format,

    ? This is the whole concept that Enscape is based around: reading the native application's file format to generate the model and taking the native application's input and reproducing the same movements in the Enscape window. And the info does not need to be held within the native file: Enscape just needs to know the 'name' of the current file and be able to retrieve the relevant information - where that is stored could be anywhere (eg in the cloud, in another file, locally...)


    Also note that Enscape is capable of saving DOF, sunlight, etc. settings already - just has to be a scene within a camera path rather than a static scene.

  • Also note that Enscape is capable of saving DOF, sunlight, etc. settings already - just has to be a scene within a camera path rather than a static scene.

    yes but that camera path and its keyframe settings are still saved in an external xml file, not inside the project (which is totally fine for video editor).


    But for images, I still believe a different approach is necessary.


    I believe each package (rhino, revit, sketchup, archicad) has an API method to append data in the file. I think Enscape already 'kind of' does it for the assets. So I'm 90% sure it's technically possible (100% sure for Revit).

  • But for images, I still believe a different approach is necessary.

    Yes. Attributes in Rhino for the Named View that enscape will write and read.


    Example:

    Key: FOV, Value: 60

    Key: Saturation, Value: 30


    So then you have everything in the 3dm file, exactly as you wish, also correlated nicely with the rhino named views.

  • Why?

    What settings can a still image have that a point on a path would not?

    We make far more images than videos. Perhaps we end up making a handful of videos for the entire duration of the project, but in that same time we will literally make thousands of images, and often we need to reproduce the same image week after week.


    Managing all the xml's to pull that off is going to be a nightmare. and we have to remember what XML goes with what view (unless you save the camera position in the XML's as well).


    And now imagine I want to batch render those, I would have to select all the right views, and pair the right xml's with them.


    Not saying it's impossible to pull it off with external files, but saving it inside our program would be a lot more practical and save us a lot of time.

  • :Shrug: I don't think that the program cares where the data is stored, as long as it can read it.

    One of the main reasons for this debate is that Enscape should store the data against the specific camera position (/view information): So no management of XML's would be required.


    Personally I don't really care how it's done or where the info is stored, but second-guessing the developers and telling them what is or is not possible within their own program is pointless.

  • Personally I don't really care how it's done or where the info is stored, but second-guessing the developers and telling them what is or is not possible within their own program is pointless.

    Who second guessed the developers? I don't think they've weighed in on this issue yet.


    Edit: I think you've misread my post. My comment about 'not impossible to pull it off' was about our office using external files to do our daily work. We could do it but it would be unpractical. I didn't say anything on what is practical/unpractical in terms of programming.



    Quote

    I don't think that the program cares where the data is stored, as long as it can read it.

    No the program doesn't, by my users do.