Hey MatthiasB ,
sorry to hear that. Albeit Preview versions may still be unstable, we're of course very interested in what caused those issues. Did you report them via the Feedback button yet? Thanks in advance for any reports, that'll help us iron out those issues faster for the upcoming 2.7 Release.
Congrats that's a really cool project! 
btw I think this would fit very well into the showcase section. Did you post it on purpose in the Sketchup subforum only?
(I teach in a college interior design program, and wish I had the budget for this kind of hardware.) For my work, I've been very happy with the EVGA GTX 1060 6GB card that now costs about $250 -- it seemed like a good entry into GPU rendering and has proved to be so. I use it on a Boxx workstation with Revit, Enscape, and recently Twinmotion. It's a double-slot card, so be sure you have that kind of room, as well as an adequate power supply. I agree with the recommendation about splitting the cost between a larger power supply and the card itself. And... it supports multiple monitors, so put them in next years budget!
Completely agree, just beware that the GTX1060 is also dated in the meantime and that you can get yourself a GTX1660 (super) for the same budget today! 
Hi rbrodhead and welcome to the forums!
If you can't/don't want to change the power supply unit this is going to be difficult. Less power hungry alternatives would be the GTX1660 or GTX1650, but they're on the one hand a lot cheaper than your budget and on the other hand 290W could still be a little tight in that case. They'd however be both a massive improvement compared to the Quadro K620. So maybe spend some of your budget on the power supply 
Maybe anything works right. Orthographic means that you are looking from infinite distance with a nearly 0° view angle. This could cause that you see a very small portion of the BG only and it looks like a constant color. The same happens for the reflections - every coparallel surface shows the same little part of the environment. If you look at your ortho shot than you see that some windows have a white reflection on it and windows in an other direction shows a dark part of the environment and it looks like no reflection. I afraid what you ask for isn't possible. Or I'm wrong? I'm curious.
This is correct - using a skybox as a background would show a solid color, as the view angle for all pixels is parallel. Same goes for reflections: Since view angle is parallel all reflection rays starting at the same surface normal will also result in parallel reflection vectors.
I also found that Artificial Lighting currently also does not work
Artificial lighting should work - can you post a screenshot or provide us with the project where it doesn't?
If the decision is between the RTX 2070 super and the Quadro M4000, then definitely go for the RTX! The Quadro M generation is now outdated for years (almost 5 years old), while the RTX 2070 super is still state of the art. Thus it runs circles around the old quadro Enjoy your upgrade - the performance increase compared to the GTX 670 will be significant!
We've had in fact techncial limitations that prevented us from supporting different texture repeat modes in the past. Starting with 2.7 we'll use a different technology which will eventually also enable us to do that - so this is on our agenda, but will only come some time after 2.7 I'm afraid.
Awesome work!
I'm curious how you achieved the glowing lampshade material? Looks very convincing!
Hi Shilo N and welcome to our forums!
1) Unfortunately decals on transparent surfaces are currently not supported by Enscape, so this is known behavior.
2) Textured transparent materials should work in general. If you select a transparency texture keep in mind that the materials opacity (inverse of transparency) is multiplied by with the brightness of the transparency texture to determine visibility. If transparency is at 100% you won't see your color texture.
Hope that helps!
Hi risaku & welcome to our forums!
This is unfortunately a known issue currently. It has something to do with an optimization we do, where we basically check how far each light-source has to reach (light's with a smaller reach are less expensive to compute). So depending on a light source's surrounding it might get a different light reach radius assigned in Enscape, resulting in different lighting eventhough the light's definition in Revit is the same. There's unfortunately no workaround so far except moving the light source a little and see if that yields different results. We hope to improve that behavior in the future though!
Hope that helps!
Hey Jacob 16a
in addition to what Demian suggested just a heads up that orthographic perspective will come with Enscape 2.7 (and will already be included in the next Preview), which will allow you to do elevation renderings straight out of Enscape
Is there any possibility to reduce the instant GPU usage through a longer wait time for the final image than now?
Yes, we're currently working on a solution that's basically doing that - it will allow you to render higher resolutions with a much lower memory footprint. There're still some issues to solve yet, but early prototypes look promising
Other than that we were also able to reduce some of the memory overhead (around 10-20%) for the RTX implementation and will release that fix in an upcoming 2.6.2 hotfix version
As always spectacular results! 
What's the source of those vegetation models?
Great renderings! Those bicycle handlebars look quite uncomfortable without any bar tape though
Hi Macker
the blur effect is easily achievable by raising the roughness of the frosted glass material:
Hope that helps!
OK, I understand this but, does this not mean we are basically talking speed here ?
Speed is one factor, memory another. Whereas speed is a twofold issue: The actual runtime cost of tracing more geometry during rendering (and this is also largely dependant on the kind geometry, so this doesn't scale linearly, but also the required preparation. So it's not a simple equation of taking 2x the geometry and receiving 2x rendering time. Memory is even more critical - if the resources don't fit into your memory, there's not that much you can do.
I absolutely understand the urge to get more control of these kinds of things as a "power user" and trust me, we've discussed those options internally for many times as well. We do want you guys to be able to achieve optimal results, but at the same time we want Enscape to stay accessible and straightforward to use in a stable way. We're confident to achieve both of these, getting better and closer with every release. I don't want to exclude the possibility of having more options in that regard in the future, but most likely the focus will remain on further optimizing our "1-click" approach e.g. by leveraging more of the available capabilities based on your gpu, which will benefit all user demographics.
Great work, love the train render and also the courtyard with all those plants!
with all due respect , this is not correct IMHO.. I think we are already discussing things a little more specific here, please read the posts a little more thoroughly. Clemens already stated that enscape is in fact already calculating twice as much reflections when rendering vs. live view.
This means that the engine can do it.
To some extend yes (when talking about content beeing visible and not other features), but there're still hardware dependant limits and those are not as easy to control as a user. And please beware that as Gadget already mentioned - still image and video rendering are just some features among others and depending on your focus as a user might or might not play such an important role when using Enscape. That beeing said you still can expect further quality improvements in that regard in future versions, however the basic concept of Enscape beeing a very accessible (real-time) rendering tool for everyone is not planned to change.
Clemens Musterle - if there was a way to render a 'standard' capture in the same manner that panoramas are rendered (meaning how the render frame scrolls from left-to-right across the image field), that would be fantastic, and would seemingly eliminate the problem... I don't export very many panoramas, but when I do they are always set to High resolution, and I have never had Enscape fail while exporting one.
Yes, that's an option we're evaluating for that - however for Panoramas we're already tuning down some of those screen space effects, so one of the downsides of this approach would be that higher resolution renderings that are stitched together wouldn't have the same fidelty as lower resolution ones.
Hi Herbo
we're sorry to hear that. We didn't come across issues like that during the Preview phase of the release, but since 2.6.1 has been rolled out we've received multiple reports like yours.
Since you're using a RTX gpu this might be due to a higher memory demand (and other memory management requirements) by the RTX raytracing implementation, we'll have a closer look at this. Please make sure to submit your log files, so we're able to track down the issue. In the meantime it could also help to minimize any other video memory overhead, e.g. by avoiding multiple CADs (or even Enscape instances) beeing open at once.