Posts by Christian Radowski

Please note: Should you experience issues with Enscape or your subscription, and in case of any urgent inquiries/questions (e.g. regarding our upcoming licensing changes) please reach out to our dedicated support team via the Help Center or Support button as detailed here.

    Hi Christian,

    We tried the latest servicepack and the reflection issue from the other thread seems to be resolved. Remaining known issues from our one user test would be:

    1. Rhino viewport still slow when enscape is running. (Workaround : don't run enscape while working, only rendering)
    2. PNG's does not have transparent background anymore, but white. (Workaround possible by making it into a native enscape material)
    3. Object will move/appear simultaneously/live when live-updates are turned on, which affects performance negatively. As an example, when using the copy command in rhino; The object you are copying disappears in the enscape viewport, the "new" copied object will float around in the enscape viewport until you place it in rhino. The original object will reappear when you are done using the copy command. (I guess there could be more "funny" stuff happening if we tested more commands, like array, loft, flow...). (Workaround : don't run enscape while working, only rendering)
    4. No enscape toolbar showing (Workaround: You need to create a custom toolbar to access the Enscape buttons).
    5. Render results are different every time you render. We tried to render same view, with the same settings, 7 times, a we got 7 different results in terms of shadows and reflections. We tried another one where, the first render was the best result in terms of reflections, we rendered 4 more times which were similar, but worse in terms of glass reflection, sadly. This was not a problem with 3.4.4, and it is a bit "scary" when you think about postproduction and updating renders. (Workaround: none known yet - a risk we have to live with).
    6. The Rhino viewport will change/sync, when selecting a saved view in the enscape viewport. (Workaround: None, just live with it).

    The problems are limited to annoyances, and i do believe we are slowly treading outside the "unusable state". We will try and upgrade more users and hope it will not lead to too much lost work and efficiency.

    Hi there, I've forwarded your list to the team working on the integration. Some of these might just be things we need to fix together with McNeel but I wanted to make sure that all the bug reports are tracked in our system (afaik they are) thank you.

    Christian Radowski The viewport is unmanageable when enscape is running. It is slowing down my workflow and frustrating me. Enscape has been letting its users down since 3.4.4 and i urge you and your team to reflect on how unacceptable it is to charge companies money for such a buggy product.

    1. Did you try the most recent version of Enscape and Rhino together? You should notice an improvement.

    2. We are constantly working together with McNeel to improve the situation we switched to a different part of the SDK using the Rhino ChangeQueue with 3.5 to be able to make use of more Rhino features which are unavailable through the previously used SDK "flavor". Bear in mind this is highly simplified. Anyhow, this is one of the reason for the issues you are facing and we are continuously trying to address these together with McNeel but it isn't as simple as one might think and going back to the older implementation is simply not feasible.

    3. While I get your frustration I think it is misplaced. This change was necessary for multiple reasons, with the best intentions. I am sorry that it takes so long and is so complicated to get it right but the team that is working on the Rhino integration has put a lot of effort into this and is continuing to do so.

    We will release a new service pack for 4.0 today I would ask you to retry that version and provide a list. I am sorry that you are struggling with the product, the forum might not be the most ideal way of that information reaching us though. If you provide a list I assure you we will take a look.

    Can the Enscape team provide us with any sort of reassurance that they are working towards a deadline of fixing the currently know areas where Enscape 4 is worse than Enscape 3.4.4?

    We find ourselves in the peculiar situation where we have bought Rhino 8 but cannot install it because Enscape 4.0 is still too faulty. More urgent is the fact that we are growing and need more Rhino licenses, but haven't even activated our R8 licenses, so this gives a management headache.

    To be very direct, we are looking at a crossroad and are weighing our options. The push from management means we will have to commit to a direction soon (getting a working Enscape in the new version of rhino or change software). Our current internal tipping point will be in two weeks (1. may) where we will retest the latest version of Enscape 4. If it is still not usable we will start transitioning all our Revit users to twinmotion (giving its already included in our revit license) and transition all our designers/rhino-users to D5 + native rhino viewport "rendering". A new public statement from Enscape indicating commitment to fixing the software would give me leverage to maybe extend this, but the people i report to are not happy with the history of excuses.

    I dread the added internal education we will need to make a transition, so i really hope there is a future which includes Enscape. I can see the glimmer of hopes in the latest tests. Good shadow and highlight control, so the render quality is going up, but the usability has unfortunately not followed.

    Hi HNY what problem areas do you need to see addressed? I mean explicitly? We are working on several performance improvements but what beyond that?

    Hi Christian, a customer of ours recently brought this thread to our attention. My understanding is that Steve Baer has been working with your team on all the Rhino 7/8 related issues. Can you tell me more about where we're at with this? We thought we'd handled all the issues reported by your team...

    Brian Gillespie

    Rhinoceros Development

    Robert McNeel & Associates

    Hi Brian,

    You're right every fix needed is in 8.2 but unfortunately not in 7.

    We will support Rhino 8.2 with the next major version where things are looking stellar.

    Thanks once again for your support.

    1.(1.) The issues are unfixable in Rhino 7 on our end, unless McNeel fixes their part of the issue, which I think is unlikely as they are focusing development on Rhino 8.

    2. Very likely.

    3. I think the easiest way you could achieve this would be having different Windows users and a per-user installation.

    I understand your frustration but the Rhino 8 adoption is quickly rising and standstill won't really be an option in the long run.

    I think this is muddying the waters even further....

    1 - When you say latest version, are you talking about 3.5.6? Or an unreleased internal version?

    2 - This seems to be in conflict with #1 - if the issue is not fixed in Rhino 7 or 8, how can the fixes be "in effect in the latest version?"

    3 - "Might" be fixed with fingers crossed....? So even with Enscape 4.0 you are still reliant on McNeel fixing something on their end before it works?

    There is no muddying the water just a good faith attempt at transparency.

    1 & 2 - 3.5.6, there are several performance improvements there, they just don't address your particular issue. We had other reports of performance issues that were in fact addressed there.

    3 - I made it a habit not to promise something that is outside my control. I cannot guarantee you that McNeel will be fixing something. And as state before this issue cannot be fixed by ourselves it's an issue within the API/workings of Rhino when using the change queue part of the API. Returning to the 3.4 way of exporting geometry is out of the question so it is a "fingers crossed" kind of sitaution.

    "- There are parts of the Rhino API that we already reported to McNeal that create this particular problem, it's due to an unintended Idle state that causes what you and the others in this thread are seeing. That issue was not fixed even in the latest Rhino 7 or 8 version unfortunately. A member of our team will reach out to our contact at McNeal again to bump this for subsequent Rhino 8 releases."

    Yet 3.4 works just fine. Why wouldn't 3.4 be experiencing similar issues if the Rhino API is to blame? Just asking the obvious question.

    Because we started using the newer API after that version going through the Rhino change queue which gives us more means to support Rhino better. Improved diff updates and more basically.

    rifkin so we ran an analysis internally and here are the results:

    - Our fixes are in effect in the latest version and there is a definitive performance boost

    - There are parts of the Rhino API that we already reported to McNeal that create this particular problem, it's due to an unintended Idle state that causes what you and the others in this thread are seeing. That issue was not fixed even in the latest Rhino 7 or 8 version unfortunately. A member of our team will reach out to our contact at McNeal again to bump this for subsequent Rhino 8 releases.

    By the time we are ready to release a preview with Rhino 8 support it might be fixed or at the very least there is hope that McNeal fixes the issue in time for our next full release (fingers crossed).

    I will not sugar coat it, I cannot provide you anything other than an apology for the issues you are facing. We fixed a bunch of things but this is something that must be fixed on the Rhino-side before we will see improvements and as the fix did not make it into Rhino 7 there is nothing that can be done until it has been shipped and we add Rhino 8 support.

    I am honestly very disappointed. A Rhino 8 update would waste that much resources really ? I don't think the argument holds much. Your software is expensive ($79 per month floating license), it is double the price of D5, and same price of Twinmotion which are both Rhino 8 compatible already (maybe because Rhino 8 has been in the making for years..).
    Personally, I couldn't care much right now about Mac compatibility or improvement under the hood. Rhino 8 compatibility should be your priority, and we should not even have to point it out to you. More generally ensuring software continuity between old and new versions should be a priority. It is basic sotfware product servicing. This lack of update (until March 2024 sigh) disrupt workflows, imped productivity and make us wonder why we spend so much on Enscape. We are paying full-price for an outdated software right now.

    Once again, very disappointed.

    Hi there,

    while I understand your disappointment the argument holds very true unfortunately.

    The thing we are working on now will ensure that we can return to frequent releases and staying up to date with CAD releases and user requests.

    What you are experiencing now is, to put it in an analogy, asking us to change the tires on an old bus that served us well but is being decommissioned while we are in the process of finishing the new and shiny bus that will come with the fresh tires from the get go. Time spent on the old will cut into time spent on the new and comes with diminished returns as work has to be duplicated.

    You and all our users will benefit from the under the hood improvements and platform independent nature of the new code base. Every singe one. If we were just building a new separate Mac version you'd be absolutely right but that is simply not the case. The reason we cannot provide it earlier is not a lack of understanding of the need on your end it is simply that we needed to make a call what to prioritise on to deliver the best possible results for everyone in the end.

    Please believe me that we are putting a lot of effort into this, it's an investment into the future of the product first and foremost.

    Finally, it might be that we are able to release preview builds with the Rhino support earlier no promises though. So in the end only time will tell if you truly have to wait until the full release. Idk if using those would be an option for you.

    Sure feel free to PM me a link to your project and add the logs I can open up a ticket.

    I have done all these things. No improvements in the latest updates. I sent an example file and tons of logs. This is easily replicable, and I would be happy to jump on a call if needed to walk through it or see things first-hand.

    Phil Read opened the ticket originally on Nov 10 - 173514

    It is a large file, but all worked fine in 3.4.4

    Case is logged in our system but the team is waiting for your logs apparently.

    Don't get me wrong but that is simply not how it works. We are in the process of improving the things under the hood as I said and we will be able to respond to these issues quicker in the future. These things just take time. We are investing into the new code base for the exact reason that we want to serve your needs better and iterate quicker. So all I can say is "it takes time" please have some patience with us, that is all.

    Hey there,

    I know this has been annoying to all of you but 2 things:

    1. Please give the latest Rhino and latest Enscape version a try, we had to work on both sides Enscape and McNeal,
    to improve some of these issues and we did ship the improvements with the last update

    2. If your issues still persist we need your projects and logs or we cannot fix the issue for your particular case.
    I know it seems like a hassle but that is the only way. I know you all need to get your own stuff done but in this case, you have to help us fix this for you and without the specific data and clear descriptions of what actions you perform it is nigh impossible to do a precise root cause analysis and fix everything.

    They can go to D5 or Twinmotion, I saw this stuff coming 18 months ago and moved to D5 and would never come back to Enscape given how there development (or lack of) has been for several years

    Hi dev here,

    we are working on things behind the scenes, there is no lack of development ;)

    The issue is that not everything can be done at once. We plan to add Rhino 8 support Q1 next year (maybe earlier via previews if possible)
    but at the same time we had to work closely with McNeal's own dev team to figure out some issues on both sides to make this happen.

    If an issue only affected, Rhino, or only Skp, or only Revit, so be it, that is something that could be worked around. The bigger problem is that these issues do not impact just one host software - there is not one good Enscape version that is compatible with all of them. Is there a suggested workaround? Provide two PCs or VMs for each user, one for Rhino, one for Revit? Uninstall and reinstall a different version of Enscape each time they want to use Revit or Rhino?

    Perhaps most of your users are individuals or small firms only working in one host software. But for our firm, this is not an "edge case," this is an ongoing pain point that we devote significant resources to testing and working around ever since v3.0 was released.

    This is exactly why we have been quiet for a while we are overall improving the stability of the product underneath the hood. I get your frustration but we are by no means slacking of and ignoring you guys, some things just take time.

    FYI we've improved the interpretation of the data in many of these cases as well as the import error you were seeing.
    That is something to keep in mind when dealing with preview ;) we were not fully done yet.

    Thanks :) This is my point exactly... If the data sets are this broken for most of the places around the world, why build the feature in the first place? Most of us will never use it, and even if the data set were correct, the detail level is still way too low to use in most scenarios.

    I just don't see the reasoning behind spending THAT much effort to create something that is basically just bloat for most users.

    :D that's a bit hyperbolic don't you think? While I don't want to speak for PM when it comes to the decision-making about what should be built I'd like to hold off on the final verdict regarding usefulness until the feature has been released and more users got to try it out.

    Don't get me wrong I am not trying to argue away the quality of the OSM data in this case, but then again it has more accurate or less accurate data depending on the actual location. Additionally I know that you are using a different method to get the surroundings of your model into your actual CAD model but for a lot of users this workflow is not ideal and the "low poly nature" of the current site context implementation does not "distract" so much from the actual model. So I personally see benefit in that not that it matters because I also am not the person deciding what gets build I mostly work on the how part of that equation.