Posts by Joachim Hirsch

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.

    Hello again,

    we just shut down the old Productboard Portal and published the new Aha! Portal!

    A few words from my side before you dive in:

    As migrating all the requests that we got in the last years was a lot of manual effort (we need to touch every individual message manually), we had to decide to let go of some of the things for the migration.

    The alternative would have been to either spend months worth of time that we would rather like to spend working on the product itself, or having a mess of thousands of un-reviewed and un-merged entries with hundreds of douplettes.

    We still keep an export of all the requests that we received in the past, so nothing is lost.

    To reduce the effort we decided to not migrate if one of the following was true:

    - The feature was already released.

    - We declined the request.

    - We only received a single request for this feature.

    - It was a request for specific Assets or Materials (these have been handed over to the Cosmos team).

    In the last three weeks, we already transferred the new incoming ideas to Aha! directly as well. There are currently more than 1000 indidvidual messages in there that have been merged to around 60 ideas/feature requests.

    So how will this work?

    As soon as you submit an idea, it will be in the status "New" automatically. But it will only be visible for you until we reviewed it.

    The reason behind is is, that we still get bug reports, requests for things that we already shipped or general feedback. And we don't want the Portal to be cluttered too much.

    Each Friday, we will review the ideas that we received (in some cases we might need to skip the meeting. You know how it is at work). After we had the first look at an idea, we will adjust the status to:

    - Pending (we need to do a little more research or have discussions with others before making futher decisions)

    - Accepted (yes, this is something we want to do)

    - Declined (this is something we currently don't want to do. In that case, we will add a comment visible to all with reasoning)

    - Planned (this is currently on our roadmap, which usually means that we are planning to ship it in the next months)

    - Released (obviously)

    Keep in mind: Status can change, this is just a reflection of the current decisions.

    Here is the link.

    The other product teams in our group are currently working on providing portals as well. The workflow I just described will be the same for them as well.

    The portals for Cosmos, Cloud, Vantageand Cylindo are already public as well.

    Feedback is welcome. Also if you have suggestions for category adjustments!



    Yes. We are currently transferring the new ideas from Productboard to Aha in our weekly meeting. So expect it to appear there as well.

    Maybe not as an individual request. It could be that we merged it with a same/similar request but the original text is still visible there and a vote is added automatically.

    Just be aware that in case we are getting general questions, feedback or bug reports, we will not make them visible in the portal but forward them internally to the respective teams.

    Hello together,

    as most of you know, for the last three years we have been collecting feature requests through our public portal powered by Productboard.

    In a weekly meeting we reviewed, discussed and prioritized each of those messages resulting in more than 1900 individual features in the system.

    After the merger with Chaos two years ago, we are still in the slow transition of aligning all the systems and processes across the individual product teams. One of those steps is to also use the same Product Management tools. That is why we will stop using Productboard and continue with Aha!

    As we did not want to lose any information that we already received from you all, we spent a good chunk of our time to manage the migration as good as possible. Needless to say that it was not just an easy import/export task.

    In that process, we decided to only import requests for features that we did not decline by now. But we will still keep a CSV export of all the requests for later reference, if needed.

    From July 5th on, the public portal from Productboard will be deactivated and we will move on with a public voting portal form Aha!

    One of the benefits of Aha!'s functionality is, that it is a lot easier for us to manage and therefore your submitted ideas will all be visible there, including the number of votes for your ideas.

    We will stick to our weekly internal reviewing process and as soon as we review your request, we will make it visible to all.

    The current status of each idea will also be reflected there to be as transparent as possible with our plannings.

    We will share the link with you as soon as the switch happened.

    I hope, that you will continue submitting ideas with the same frequency in future so that we are able to make the right decisions for our product.

    Thank you so much


    Hey there,

    we are getting a lot of messages regarding the missing Rhino 8 support in Enscape (both, here in the forums, on social media and by mail).

    So we want to share some internal insights what is currently happening behind the curtains and provide an outlook on the next weeks.

    Everybody that has used Enscape before 2023 should be aware that we are usually shipping a Service Pack to support the new version of a host application 2-4 weeks later at the latest. That's what you want, that's what we want.

    This year, things are a bit different. Some of you might have heard that we are currently working on a major technology change for the software (which you will probably not even notice) that will allow to have one code base for Mac and Windows. This project takes time and eats up a lot of resources. That's also the reason why we did not have as many new features and improvements as we used to have in the past.

    This project has the highest priority right now. We already faced some delays. This 4.0 release is currently planned for end of March 2024.

    But how does this affect the implementation of Rhino 8 support?

    In the last couple of months our development teams have been working closely together with the development teams of Rhino to get some critical bugs fixed that prevent us from shipping the integration.

    But as you already understand, these are not easy to fix. That's why it is taking us so long.

    The issue with that is, that we need to stop shipping Service Packs for the old technology at some point. Otherwise, it will be more or less 'wasted' effort and it would cause a further delay of 4.0 and therefore a delay of the whole roadmap for next year.

    The last planned Service Pack that we decided to ship was released just a few minutes ago.

    That means that we will not have an official version that is supporting Rhino 8 until 4.0 is released.

    However, we are planning to provide a Preview version on the new technology in February that will support Rhino 8, so that you are able to keep using Enscape with your upgraded host application.

    As I stated at the beginning, we know that this is not ideal. But forcing an earlier release will just cause more issues.

    This situation is an edge case and after shipping 4.0, we will be able to return to our usual procedure.

    Our colleagues at Rhino are also aware of this situation.

    I hope you understand. We are open for any further question in that regard.


    Product Management

    Can you also comment if any of these issues will be addressed before the release?

    Hey Pieter,

    sorry for the delay. A lot going on here right now.

    You might remember the meeting that we had a few weeks back. We explained why the functionality will only be in a very late Preview and that there will not be a lot time to make adjustments for the release besides bug fixing. We are aware that this is not optimal as we are providing the Previews to get early feedback and adjust the direction we are heading. This did not work this time unfortunately. But that does not mean that we are not discussing feedback and adjusting our plans post release.

    Regarding most of your points: This is very good feedback that I will share with our UX department to understand their reasoning of the decisions better and decide on potential changes.

    The reason why there were a lot of variants but not a lot of assets with adjustable materials is simply caused by the progress of our internal tooling. The variants were easy to prepare without specific tooling. So for the release we will have more assets with adjustable colors and materials. We are currently also planning to ship new (or reworked) assets every month for the rest of the year.

    We decided against doing detailed adjustments in the materials that are used in assets for now. So no, you will not be able to change maps individually.

    I hope this helps.



    Before the voting portal, there were at least some mega threads that people voted on roughly a single feature request. That kept everything somewhat concise and the popular threads always stayed at the top of the forum. Yes, there were times when someone was lazy, didn't look up the mega thread and created a side thread on the topic but linking them to the original thread solved that problem.

    Now, every single thread gets told to add a vote on the portal. 90% of those ideas aren't on the portal, so myself and others submit new ideas to what I'm assuming are threads into your system and someone has to go through and group all the similar ones together. That creates a ton of redundancy verses having one person go through daily/weekly and add all those ideas to the voting portal. I agree not every idea needs to be added to the portal but if you set up a system where as soon as say three people submit a idea it gets added to the under consideration tab that creates less work on your end. Furthermore, if you are looking for feedback create another tab on the portal for "needs feedback" for those ideas you want feedback on. We the forum/program users need to see as many ideas being submitted as possible for the portal to be succesful. Otherwise the voting portal is useless. Especially when you've taken the time to submit ideas and never see them come up on the portal to even be voted on. That is disheartening and a huge turn off towards using the program.

    Thank you for your honest feedback.

    First and foremost: We did exactly what you are proposing in the past (going through the votes in the forums). And no, it is not less effort. By far. Having every information in one place provides much more value for our planning process. And we also have other channels feeding our system with feature requests. Not just the Forum. But I don't want to bother you with the range of features and how we are using it ;)

    If we would add every feature request with three or even ten votes, we would still have hundreds of items in there. Every single one would need their own proper description and sorting. And we all know that we do not have the capacity to develop even half of it in the next three years.

    And still, who would read through ALL of them? Who would give feedback to all of them?

    I see your point in the naming of the 'Under Consideration' tab. It might be a good improvement to change it.

    Some news for users who use 3dconnexion peripherals. We are stopped at 3.2 preview 6 !!!!!!

    Still pushing 3DConnexion to update their API. The issue is currently not on our end. But we are on it with them.

    I'm curious what data sources they used? Did they use OSM and did they find it reliable enough for their use cases?

    I used to do a lot of these preliminary studies and the height data of surrounding buildings was critical. Not to create a pretty rendering, but for other reasons: if the neighboring building is actually one story lower than what you were assuming, it could mean you need to cut one story down from your proposed project (as you often need to match surrounding building heights) which would make it financially unfeasible. So if a project is created based on OSM data and that data was very wrong, you could have serious issues with your feasibility study.

    That varied. Some used OSM. But mostly the companies that JUST used it for Inception and Pre-Design.

    As soon as the height became critical (DD, SD) for basic light studies or general requirements influencing the actual project, they were switching over to different paid services.

    Hi there,

    I totally get your dissatisfaction with the unreliable data from OSM. And I also see that the Site Context feature is not a feature for every user. Especially if the site is not looking close to realistic.

    Almost a year ago we had several discussions with most of the 20 largest architectural companies. And all of them were using Enscape heavily in the early project phases (Inception, Pre-Design, SD, DD). These phases need to be as cheap and as fast as possible without the need for heavy accuracy.

    Those companies were using tools to import context data. Solely for these phases. More tools = more effort = more costs.

    In this case, we saw the opportunity to reduce these costs. On top of that, we could reduce the size of the project.

    We are aware that a good amount of our user base is using Enscape to produce beautiful renderings. Of course this new feature is not very useful here. But these are not all of our users, not all of the use cases we want to support.

    With 3.1 we had the Material Library as main feature to support users that are less interested to play around with materials. This is helpful in most of the architectural phases (except when it's getting close to documentation and construction).

    In 3.2 we released Dynamic Asset Placement to speed up filling the projects with life.

    Now, we are addressing another use case.

    Again: I understand that this is not for everyone. But what I learned since I am at Enscape is that there are a lot of different use cases, practices and preferences with Enscape. So trying to make everybody happy with a feature is just not possible.

    I am sure many of us have made several submissions to the roadmap that would be of far greater use than some of the features "In development" or "under consideration". But without the ability to view and vote on other users (or even enscapes) suggestions we will once again be at the mercy of Enscape's internal roadmap. The Enscape portal was a real opportunity for them to be more transparent and user focused, but alas i can dream!!!

    I posted this already somewhere else. But I am struggling to find it right now.

    We are aware of every single feature request you submitted. We track them all. And also upvotes. And for a lot of them we have a clear understanding of the importance and and additional vote would not make a difference.

    If we would put all the requests on the voting portal, it would just be a huge pile of hundreds of items that nobody wants to go through. Or to maintain.

    That is why we decided that we just put items on there that we definitely need more feedback on to understand the importance and context.

    This way, the users have a small batch of features that they KNOW we NEED their feedback on and that they can go through. But if they have a specific request, they can still submit it and we track their vote.

    This decision is not to hide anything, just to streamline the process and reduce effort on every side. Also on yours.

    I’m sure that at some point in the near future they’ll have an internal planning meeting where the go through the suggestions we’ve made and ‘some’ will appear on the portal.

    Hi Paul,

    you can be sure, we are having these kind of meetings every other week for the last years already. We are using this tool since the beginning of 2021 and started by merging all the requests from our old tool to this. In the meantime, our Customer Service team forwarded every request to this tool.

    There are right now more than 600 individual features in there (with some more sub-features where combining made sense).

    Putting all these requests on the portal would just be hell of an effort. And it would also affect the responses that we would get for it. I (personally) had the experience in another company in the past, that not everybody reads through all the requests. They stop after maybe the top 20-50. So only these will get feedback/votes. Would that lead to a proper representation that we could plan with? Probably not.

    With some requests, we already have a clear understanding that it is asked frequently (and why). So no need to have the 100th vote, if 90 are already telling.

    As Demian already said: In the "Under consideration" tab there are requests where we don't understand, yet, how important these are.

    I get that you would like to see the number of votes in there. But the decision on what to implement is not always just a matter of votes. Also strategy, effort and technology. So it would not be telling how soon the feature would be implemented.

    I hope you can understand that and trust us to track your requests properly.



    Any news about fixing (or "downgrading" to what you had previously) with the Space Mouse?

    We are aware of this situation.

    When removing the old SDK and adding the latest, we expected no bigger issues. But as you know, nothing ever goes as expected. We found some issues. Not on our end but incompatibilities of the SDK with plugins that also want to access a Spacemouse while the host software has access to it.

    3DConnexion are right now adapting the API for it.

    We are also not happy with it and I hope you understand.

    Again, thanks a lot for your feedback.

    You can totally count on Demians comment here. We do not have the intention to remove functionality from the host app.

    About the other requests that you mentioned:

    Without going into details, we are already working on most of the things that you mentioned.

    But these are not easy to implement as it was not respected in the data structure originally. And some things would right now just not fit into the workflow as we imagine it.

    There is a lot of work for preparation going on right now to make things happen in future. And of course you can not see this preparation.

    Think about the release cycles of other programs. They are usually releasing once a year. And sometimes they are also not able to deliver things right away. Even though we have three releases a year does not mean that we are faster with developing. We are just doing smaller chunks to provide new things more frequently.

    Hi again!

    Awesome discussion, thank you for that.

    Usually, I don't tend to share insights from internal processes. But I remember that you have been interested in our ways to collect feedback the last time we talked about it. So let me roughly show you how we gather our impressions (in no specific order). Beware! The wall of text:

    Trello Board (discontinued)

    The Trello Board was a very good tool as long as the company and the number of requests was small. With our current internal tool we are managing more than 500 individual feature requests. That would be quite the complicated in Trello to be honest.

    Still, the old Trello Board exists and we are constantly delivering the requests that are listed on it. Just to show you some:

    Of course there are still items left (like animations, SLI graphic cards, 360° Videos, measurement tools, etc.). But we tracked all of them in our internal tool as well and we keep evaluating them.


    When starting at Enscape I immediately got the benefit from talking to users while working with the software. You see how they are working and understand the 'why' behind it even better compared to a textual description what you would like to see. Thanks to Corona we did not attend at a lot of exhibitions the last years. And it is also quite the difference if you are talking online or offline. But I am optimistic that we will soon come back to normal in this regard.


    As already discussed, you are a very important source of information. And we definitely know that everyone of you is representing their company.

    You are also the most responsive group of users, which makes it easier for us to find out the reasoning behind your requests rather than 'just' always doing what is requested.

    When the need arises, we also get in touch with some of you directly. Either some of our developers (for the more technical discussions) or someone from product management or ux.

    Customer Service

    I don't even know the exact numbers but there are hundreds of tickets coming into our Customer Service constantly. And many of them are not bug reports but feature requests or descriptions of specific workflows. These information are always forwarded to Product Management. And in case we want to learn more, we also get in touch with those users.

    Big Customers & Resellers

    As we are already in contact with some of our big customers and resellers in other positions within the company, having conversations with them about the biggest pain points is just a small step.

    Potential Customers

    One side of the medal is supporting the users that we already have and providing improvements for them. But the other side is understanding why other potential customers are not switching to Enscape. That is why we are also talking to CAD users that are not using Enscape (or not even one of our competitors to be more precise).

    CAD Vendors

    To understand better how the CADs are used, a more holistic overview of the usage can provide quite the insights, that single users are not able to see. Our contacts at the offices of the CAD vendors have access to usage statistics and their own customer service. This is just another perspective that we can add for our overview.

    Social Media

    Similar to the requests coming into our customer service, some colleagues are maintaining and monitoring everything that is going on in the different social media platforms. This includes YouTube as well as Twitter, Instagram, LinkedIN, etc.

    Of course are we generating content here. But we are also discussing feedback that we receive. Most of the time we don't even know whether this is coming from a user or not. But if there is a need for clarification, we try to get in touch with them.

    Market Trends

    We are not just looking at the current state and how to improve them. We are also observing and discussing market trends in the architecture world with internals as well as with externals to think a step ahead and maybe even being able to act a step ahead. Right now we know that we are late/behind with some topics where we should be further at the moment. We are trying to catch up here but we also want to prevent that this will happen in future as well.


    With a growing company it is a common thing that you need to set a strategical direction at some point. And some features that we are planning to implement are serving that direction. But they are always requested.

    I hope that clarifies a bit what we are doing all day long and how we evaluate the priority of the requests from a demand perspective (complexity for development is another story).


    There are two things we are currently working on that I would like to share with you.

    We are working on a concept to work very closely together with a very small amount of users (not companies). The participants would be able to influence (not dictate) the roadmap and the UX of planned features. We would get a better understanding of the needs and reasoning.

    The plan is to start end September / early October with the selection process and then get the whole thing rolling at the end of the year.

    As soon as we start, we will have a separate thread here in the forum.

    Additionally, we are reevaluating a replacement for the Trello Board.

    As mentioned above, the old concept required more and more maintenance and provided less and less value for us. That is why we decided to stop it, take a break and have another look at it after a while.

    With the more objective view that we have, now, we collected pros and cons. The next weeks we will have some discussions about that topic and how we could address it so that every side can benefit from it.

    Thank you all for your feedback!

    Also, another follow up question: if I make a modification to the asset in Revit (for example I placed the asset in Revit -> Edit Family -> Change category), and now I place the asset again in the same project but this time from within the Render window, will it use my edited asset Family, or create a fresh asset family without my previous changes?

    As we are not yet completely done with the implementation, we are also not 100% sure how the behavior will be. We are highly depending on the data structure that is provided by the CAD. But we suspect that the already existing families are used as long as you did not rename them. As the fitting IDs will be checked, the described process should work.

    Here's an idea .... why don't you go after the users who've stolen/got pirated copies of Enscape instead of trying to cripple those of us who's paid you money.

    You'll get a round of applause from us instead of comments like the above.

    A 10-second search found sources for 2.8, 2.91, 3.0, 3.0.2 and 3.1.51316 all on the 1st page of results with more to be had.

    We are already and always going after the people that are distributing cracked Enscape versions. But as these people are usually not living in a country where it is easy to find out who they are to sue them, this is a very tricky process. Still, we are working on it.

    Why is this additional feature necessary? It is a redundancy that is not needed at all and just adds complexity to the program that we do not want or have ever requested. If Enscape was bringing cross compatibility between 3d modeling software I could maybe understand the decision but that is not the case.

    I really understand your point of view here.

    The users in the forum are not the only Enscape users that we are talking to. Counting the total users here, they are representing less than 10% of our monthly unique users of the software. And not all of them are very active.

    We are listening to and evaluating every single feature request that we receive from you guys. And rest assured that we highly appreciate them. That is why a lot of my colleagues are also active in this forum (Demian, Hana, Adrian, Clemens, Alex, etc.) and why we constantly provide features that you were asking for (Batch Panorama, Panorama Gallery, Material Library, updating uploads, Views for ArchiCAD, etc.). But the same is true for all the other users that we are talking to.

    You can be sure that we are not planning to implement features that nobody is asking for.

    Good question (that we discussed excessively).

    In the first iteration that we will release with 3.2, we will only provide the tools that are also native to the respective host software.

    During development, we already found some ways to potentially bypass the limited tooling in some CADs. But as we (as a company) have never done something like this before and bypassing the transformation functions of the host could lead to unwanted or even bad results, we prefer to provide a stable tooling at first and then expand it if we find suitable ways to do so.

    Hi Pieter,

    we are well aware of the criticality/value of this request.

    You are right, the legal questions are mainly tied to the external providers that we work with for some vegetation and people. Clearing things up with them was not possible, I'm afraid. We tried that in the past.

    I hope you can understand that right now we do not want to provide a possibility to export our assets to a format that allows to distribute the content freely to the outside world. But we definitely want to provide a possibility to you all to tweak the assets to a specific grade to provide more variety in your designs.

    There are a lot of things we are considering or working on right now (resizing, exchanging materials, switching colors, different seasons, switched on/off lights).

    But due to the fact that this all needs to happen within Enscape, a definition and implementation of a new Asset file format (that is also compatible with older Enscape versions) is the first step to head in that direction. The second step would then be to provide the tooling within the plug-in. And then, finally, creating/adapting the Assets.

    Don't get me wrong: We know that this request would be easier to solve if we would 'just' provide our Assets in common file format. But that will not happen from what we currently know and plan.

    The topic is a rolling stone and it is something that we plan to release in the next year.




    we already got some requests for 3DS Max. But the same is true for several other programs that some users wants to have an integration for.

    We have to select the programs that we want to integrate to very carefully. Because it is not just the initial development effort. Imagine: Every feature that we develop, we need to adapt to every single integration that we have. So it piles up our work massively with every integration. And therefore it needs to be really worth it.

    Right now we are focusing on architectural CADs. I know, 3DS is also used in architecture but definitely not the same way. So some of our features won't even make sense there.

    That is why we are currently not planning to integrate it. But it is still on our radar and is re-evaluated on a regular basis.