Posts by Christian Radowski

Reminder: If you encounter any issues with Enscape (including installation problems) or your subscription please reach out to our dedicated support team directly through the Help Center or by using the Support button as detailed here. Thank you for your understanding.

    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.

    That could just be the openstreetmaps data that is inaccurate. Unfortunately that's going to be true for 99% of the locations in the world in my experience.

    Just tried the new context creator. Something seems completely off with the topography. I tried importing a part of central copenhagen (one of the flattest cities in the world), and it is full of hills/mountains that does not exist. Most building heights seem way off as well, and most buildings are shown as 1 story, even though they are 5-6 :)

    Like Pieter said the data set for Copenhagen is just not good:

    We have no height information or number of floors here so we fallback to an estimate of 3 floors. All data sets for geospatial information are closed except for OSM really (derivatives of OSM merged with other dbs exist but aren't any better for these cases). Elevation information does not exist at all in OSM we get that from a separate source and merge everything together so unfortunately this is as good as the data can get atm. Unless you wanna go around and fix the data set of Copenhagen before importing it ...