+1
Forwarded, thank you!
+1
Forwarded, thank you!
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.
Hi All
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 ?
Best
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
Hi Everybody
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:
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!
)
https://stg-extensions.sketchu…/eneroth-viewport-resizer
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!
Restrictions:
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?