thank you so much for these details - if I understand it correctly, it is only the Roughness Map which generates the shine entirely according to its own transparency values? - but not the Albedo anymore ...
Posts by EGIE
-
-
Prima! Prima! Prima! - again !!
This is just perfect - for example because without the overload of unnecessary model content. And as always - these AO renderings are so good as well!
And these few details are perfectly staged also
You manage to make the floor shine completely, although there are spots which shine so much more like being wet. I know how to use a Refection Map, but then all unmapped areas remain matt without any shine. Please please please - explain to me how you manage that 
-
Hi All - I had already posted this Render[IN]-Example in a similar post here recently. I think, having an artificial horizon at +-0.00 by default is ok.
However, to enable a manual numerical adjustment of the Ground Altitude is unavoidable: either so that this consistently unusable horizon can no longer be seen (like to see in the screenshot below) or to adjust it to our desired heights ... -
... and to emphasize how important and cool and indispensable this view synckronization is, I share this most wonderful, very entertaining and really worth seeing video here. (The matching scene starts at 21.50 and adds also Podium Render into the range of tools which use the right view matchin concept)
Enjoy !
Concept Art – Chris Rosewarne | 3D Basecamp 2018
-
The shadow sharpness slider is included in the latest Preview version only (it's independent from the software you're using it with (Rhino/Revit/Sketchup/Archicad).
This is a correct observation - shadow resolution is higher around the camera, which may somtimes result in worse shadow quality when you're using a very narrow field of view (as you're then normally more far away from your model). We're working on improving that for the next version.
Another good practice is not to use a large terrain mesh/ground plane around your building. The larger your scene's extends the more has to fit on a limited shadow texture resolution, which inevitably leads to light leaking and other issues we've seen here.
hmm - my current model has no terrain at all - only the pure building model in the otherwise empty SkUp space, and I don't want to think about the fact, that just adding a little bit of land would inevitably lead to even worse results
if that is possible at all - So good to hear you're working on it for the next version...It is totally impossible to avoid any environment - so this suggestion has nothing to do with "best practice" but rather with "most unrealistic"
"...which may somtimes result in worse shadow quality when you're using a very narrow field of view..." I don´t understand what you mean here ?
What I notice here is very unusual for renderers: Enscape has much less difficulty in calculating so perfect interiors. Of all the exteriors, which everywhere else are the simpler discipline in lighting and shadow calculation, Enscape does´t reach any acceptable constant quality level so far -
is that already your reality or also rather a wish only
and yes - it´s cool!
-
...thank you Demian very much for this clarification and I'm glad my clumsy video could help
.
How unfortunate that the horizontal alignment was the wrong decision here (this is not meant badly !), because, at least as far as it concerns SketchUp as the "mother"-CAD, it prevents any hardware and softwarelayout independent effective teamworkflow at all.So I kindly ask you to move this PRIO #1++ Requirement into your development (as far forward as possible
) as it is a minimum basic requirement.
Best, Egie -
I installed the newest Preview yesterday - hmm, this Shadow Bug doesn't seem to go in a better direction i think
Besides the well known very unclean shadow calculation itself, shadow artifacts are added now (see wall area and picture border)
(Edit: pic#2 on the right is rendered with the previous Preview) -
... and may we hope, that you (and your friends) will translate your Guide e-Book from Vietnamese into English as well ?!?
(a really excellent work example - congratulations!) -
... impressive indeed - does this only affect the rendering (somehow like Twilight does it)) or even the geometry itself?
-
-
... if Enscape could match SkUp´s 2-point perspective - a dream would come true
As far as I know, this is not possible so far. That´s why Enscape offers its own 2-point perspective feature at least, but unfortunately without matching SkUp´s -
Thanks, Great result, Yes!
but much more it is a so loud demand for a working mirror feature ...
-
... only as an Information: Artlantis Render Studio has the ability to disable exactly the Color Bleeding phenomenon which is excellent.
Colour saturation in general doesn´t get affected by this setting.
-
-
... Hi and thanks to all
finally I found the time to make a new attempt to illustrate why Enscape´s image export concept is wrong - and please forgive me the used term "wrong", because I don't know how else to name it. "Wrong" also because Enscapes concept is based on the false assumption that the width of a render scene is the right decision.Yes, I have already succeeded in this overlapping or matching - but this is only possible because of the artificial situation of my own workplace. As soon as I work on another place, nothing works or better "fits" anymore, and especially not when several people are working on the same project which is the standard case in most offices!. It is not right to insist on the random proportions of a single random working environment.
The good news is: If you would change the input feature in the capture settings to the advantage of the output render height and at the same time allow any desired or needed width input, everything would be perfect (and correct! and by the way, this convention is followed by all competitor products).
I've made a video to describe what I mean here but for the conceivable case that I'm just too stupid
to follow you, please forgive me and please finally record a video tutorial as well - otherwise we'll still be writing back and forth for months in ping-pong style
https://www.youtube.com/watch?v=9Z6ytsToo0s&feature=youtu.be -
very very good - thanks for sharing (and a presentation size I wouldn't have dared without Enscape ).
A nice house with a successful proportions mix of white plaster and brick and closed walls vs windows sizes.
All in all quite small - is it more kind of a 2nd "weekend house"? Again, really good !! -
I love this not so overdetailed, light and more conceptual style (and hopefully Sean Farrell´s fears above won't come true )
-
@ Maarsso, this is an example: The (in this case) AmbientOcclusion Render is made with Shaderlight, the lines are exported from native SkUp.
Completely independent of Monitor setup, viewport size or -proportion, these two pictures will always fit together in Photoshop. With Enscape this result is impossible so far... -
... sorry bingbing8611, it doesn´t work. Enscape´s somhow dynamic viewport is constantly changing.
Both: if you change its own size or proportion, but also if you change the viewport size of Sketchup (e.g. by different icon bars or tray menu sizes).
This inconsistent behavior prevents e.g. a colleague from being able to produce exactly the same render as me. Or I can't repeat my result later for the same reasons even. So, even the banal reality of using different monitors prevents this.
All other SU-plugin-renderers use a workflow-compatible behavior instead. Their behavior always focuses exclusively on SketchUp´s viewport height. Through this fixation it is always possible to combine native SkUp´s exports with the corresponding rendering in the way you describe it above.If you render in Vray, Twilight, Thea. Shaderlight, Renderin etc etc..., the rendered image will always fit exactly to your SkUp image export, regardless of which viewport settings are set in SkUp itself or in the used renderer. This ability is an indispensable must for our production processes.
The screenshot example below shows that the render result must not be corrupted by the used graphical software setup. In both setups, the render result will be both: a: always exactly the same and b: always exactly matching SkUp´s export.
I am totally amazed !