I'm sorry to hear about that. I'll forward this to our developers as well so that they'll be further aware of the urgency for this implementation.
Thanks Demian. Its appreciated. Its frustrating when you cant explain to the client why the view is ever so slightly different after a change or an update. In this instance it meant they decided to take their business elsewhere for future renderings after we couldn't exactly match an older view that was generated in Enscape. Granted that particular client was painful to work with and its probably a blessing in disguise, its still a disappointment, and a costly one at that.
with the pictorial impression shown below I would like to deepen again the urgency of this contribution and point out the negative consequences, if this problem is not solved with highest priority.
No matter if there are "only" 3 design proposals from an architect to his customer like Ted.Vitale describes it above or if there are hundreds of graphics the industry: For all of us it is true that the result must always be identical - both concerning the relationship of camera to model target as well as the desired freely definable render resolution. All these parameters must be independent of the used hardware, the used OS and any current random render viewport setup.
We are able to do this out of the box. No matter which computer configuration is available, no matter where the employee is. Every rendering software does this, but unfortunately so far not Enscape.
And these are only parameters that affect my own immediate work. The negative consequences multiply even further! All our graphics produced in this way usually end up in two downstream workflows.
- Either in InDesign for print media or real print layout,
- Or on a web server that fills up our web pages.
If we do not fill these two ways with exactly determined render output, we would suffocate in graphical and CD chaos. In addition, non-compliance with these criteria generates immense correction volumes and thus unacceptably high costs. To avoid any "production risk", we can not release Enscape in our official workflows which is such a big pity, isn´t it ?
It is quite hard to believe that this was not solved from the word go. It's been a known issue from before the birth of Enscape that Sketchup window size changes can wreck view consistency. Why are we waiting on something that shouldn't have been an issue in the first place? As Ted says, there are known ways to fix this. Please implement this asap.
Thanks it might work for me
I want to show you a stable SketchUp Workaround-Workflow that will enable you to reproduce an always identical, fixed and clearly determined SketchUp Viewort Synchronized Enscape rendering result, completely independent of:
- how you have set up your SketchUp program window
- which monitor sice you use
- what aspect ratio size of any SkUp viewport you are eventually using
- on which other equipped computer you will eventually work (for example PC vs Notebook)
- where or under what workplace conditions you work
- who is doing it on any other computer
- synchronizes both: still images and video render export
Since Enscape itself is unfortunately not yet able to provide this capability, since it is highly disadvantageously connected to the given SkUp viewport dimensions, the trick is to manipulate SketchUp itself, temporarily or if desired permanently, so that SketchUp´s own viewport gets assigned a determined fixed size.
Important to understand here is that within SketchUp not the actual pixel numbers are relevant, but only the this way resulting pixel ratio Width to Height.
Also SketchUp itself is part of this dilemma. Also SketchUp itself, after so many years, is unable to disconnect its own exports from its own currently and randomly given viewort aspect ratio.
The possible but well working workaround solution:
By means of the ingenious plugin Eneroth Viewport Resizer, it is possible to assign a desired determined size to SkUp's own viewort. So SketchUp itself already creates the requirements to which Enscape then can refer in it´s capture process. This approach is also suitable for SketchUp´s native own exports for which once was developed for example the plugin SU[CH] by Renderiza (which is no longer available in this free form unfortunately), even if a downstream renderer is not in the play. (so, if you run SU[CH], keep it! )
The example below shows the procedure
Picture 1: shows the adjustment of the SketchUp viewport to a HD ratio.
Even if I´ll intend to make a huge render resolution later, the small screen of my notebook only allows a small SkUp viewport representation and since I only use this setting temporarily for the Enscape rendering production, I decided to use 480 x 270 pixels here.
Picture 2: since I have already set a HD viewport ratio within SketchUp, I can now set the desired render resolution in the Enscape capture window – here I decided to use 7680 x 4320 pixels which simply is a multiple of the done SketchUp viewport adjustment above. Please keep in mind that the only thing that matters is your own determined pixel ratio Width to Height!
- as far as I know, the plugin Eneroth Viewport Resizer is only available for OS Windows
- you must be willing a determined SkUp viewport setting (for example HD) for your scene camera settings
- if several people work on the project, all project associates must have and use this plugin
Hi andybot, hmm, not really so many steps, considering the fact that we, my team and me, finally have a working process of congruence between SU and ENSC (and additionally a process that also runs with my private SU 2017 Make ) The really only additional step is the adjustment of the SkUp Viewport. An Enscape Capture render resolution setting must be done anyway.
now to your question
...can't you just use the camera aspect ratio tool in SU (black bars in the SU window)?...
unfortunately, I don't know or understand what you're describing in your question or what black bars in SkUp Window are - could you please explain or show it to me?