I understand.
Unfortunately, the tool we are using does not provide an option to change or add more rating values. These three are the only that we have. I am already in contact with them and added a Feature Request (that I also don't see anywhere by the way ;))
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.
Best,
Joachim
So we have to wait for new drivers from 3Dconnexion to see the situation resolved ??
Well, not exactly. WE are waiting for an update of the SDK so that we can incorporate it.
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.
Can I use a 'brush' to 'paint' multiple assets? Of course, I'm speaking mainly around vegetation...
That is something we have planned but it did not fit into 3.2
No specific release where we will include it but we definitely want to provide a brush-like tool.
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.
Exhibitions
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.
Forum
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.
Strategical
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).
Outlook
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.
Best,
Joachim
Hi,
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.
Best,
Joachim
Hi there!
First and foremost: Thanks again for your honest and straight forward feedback! A lot to answer, so let's split it a bit:
General UI changes
I am sorry that you do not like our recent changes on the UI, really. But this feedback helps us to plan further improvements on it and also to understand the urgency from your end.
There are a lot of reasons why we even started to overhaul our UI and relocate some of our features. Partially it is to enable us to add specific features that we would not be able to add if we kept the location of the features. Also, the positioning of some features just did not make a lot of sense.
But as long as it is about the UI being easy and fast to use we will keep considering your feedback and plan further adaptions.
These changes do not happen over night. Every change needs to be identified at first (basically making the decision to change something), defined (requirements by Product Management and the UX by our Designers) and then planned and implemented. If we would change the scope of a release while working on it, the whole planning would be messed up. So please be patient. We are working on it. Really.
Not working on user requests
Sorry, but I would not agree. If I exclude 3.0 (because we were quite busy with other things there) we delivered features that users were asking for with every single release. If you have a look at the planned features for 3.1 you will see at least two things where you can find a lot requests here in the forums (Material Library, Panorama Gallery).
I know that we are not providing every single feature or change that you are asking for in our releases. And I get your frustration. I am also using software that I would have some suggestions to be implemented.
Our ressources are limited. So we need to work on the things by priority. The priority is evaluated by a combination of effort, workflow improvement and strategy.
We are also limited by the integrations. Not every CAD is allowing us to do everything (e.g. rotation or scaling). This is also a reason why we changed the location of some features.
Right now we are providing three releases a year with service packs in between to deliver new things as fast as possible to you.
Please understand that we are just not able to provide everything at once. But we listen, plan and implement as good and fast as possible.
Rendering improvements
There are several development teams working on different areas of our software. Two are dedicated to rendering improvements. All the time. There is no change in responsibilities here. So there are always the same people (plus new hires) working on rendering improvements. We would not even be able to let them work on UI things as they don't have a lot of experience there.
Right now we are finalizing some interesting things that we are not yet allowed to share for legal reasons. If everything goes as planned, they will be included in 3.1.
Rest assured that our rendering quality is as important to us as new features or other improvements.
I hope we can keep up the open and fair communication here in the forums. I, personally, appreciate it very much. It helps me to understand your needs better with every post that I read. And the same is true for my colleagues.
Best,
Joachim
Hi rifkin,
of course there is content out there that could help.
What I can tell you is that it is quite a difference if you are just using those assets for yourself or if you want to include them within your software. Sometimes we are just not able to come to an agreement. Either because of their requirements or the price or the quality.
If we found a provider, we still need to adjust them manually because the external assets are usually just too complex so that they would not match our performance standards.
So there are basically two things that are causing the belated release of specific assets:
1. Finding a GOOD matching external provider
2. Planning the ressources
We just released more diverse people last year in summer. So the priority to add even more is not the topmost at the moment. But we will surely add more as soon as we can.
Ok, a final post on this (because it's quite off topic. If you have a specific question, please reach out to me directly. We are also in exchange with Herbo).
There is no specific waging between the different sources for feature requests. We treat user feedback equally in general. But it is about quantity and quality. Feedback like 'The old version was better' or 'I need it the other way' is valuable but does not help us to understand the WHY. That makes it hard to prioritize it within all the other hundreds of feature requests.
Therefore: More info helps more. What is your use case?
Just because we decided with this particular thing to leave it as it is for the release does not mean we do that every time. It was a separate decision made for this particular case.
We definitely want the early feedback to be able to react in time. That does not necessarily mean that we decide to do so. There are just a lot of things related to that question besides the pure request itself. Capacity, internal processes, company/product strategy, technical limitations and risk management are just a few things that also needs to be considered before making untested (relating to UX testing that we did with the current implementation) undefined (well defined to be implemented) changes right before the release.
Right now our feature definition and UX testing with users take place months before developing them. And there is a reason for it.
I know, this is not the usual discussion that we are having in the forums. I really appreciate it. Even if it is not about the product but the process.
Hey there,
thanks for keeping up your voice about the visual settings, Herbo.
Just to clarify it a bit more from our perspective:
Some of us had the exact same concerns when defining with our UX department the changes for the relocation of functionality. In this case we had strong arguments for both sides. As we did not have enough information to be sure which option would be the better one for all of our users, we let the general UX guidelines decide.
We already knew that it might be possible that it is the wrong decision and that we have to change our direction afterwards. But 'afterwards' in our situation means 'after 3.0'. Before we introduce further changes, we need to have more feedback from more users to base further decisions on a solid basement.
So far we received mixed feedback that is not quite telling (and the forum is not our only source).
This topic IS on our table and we are observing it. But we did not decide to change the current behavior, yet.
Maybe we will introduce a preview with changed behavior in a few weeks. But maybe we won't.
We will keep you up to date on this.
Thanks again. All your feedback is much appreciated!
J0 - what about support of image props - this is. the first request and then we can see whether Vectorworks will solve the problem of embedded image props...
We are considering it but probably not with the highest prio. There are other things about our assets that we want to tackle first.
- Weather effects and seasons, as per some of your competitors would also be good.
Quick question for clarification:
Just as an visual effect? So that it snows/rains in the scene? Or do you mean adding assets (plants) in a specific season? ('both' is not an aswer ;))
- Visible light beams would be really useful for Spotlight users and those doing exhibition design or show lighting.
We are already having a look at this. But it is quite tricky on our side. As we are trying to render an image with ray tracing, it needs to be very close to physical reality. For light beams that would mean that we either create thousands and thousands particles in space where the light would be reflected and spreaded (which would be veeeeery performance heavy) or we make an exception from our usual approach and create a special object that is treated differently (which could cause followup problems).
No decision so far which way we will head but we would definitely like to find a solution that suits your purpose but does not affect our performance too much.
- Your assets don't work when embedded in Vectorworks objects like groups and symbols. If an asset like a tree could be embedded in a plant object or symbol then it would integrate well with normal Vectorworks workflow
We had a chat about this topic with the Vectorworks developers a few days ago. This behavior will not be implemented on our side as it would be too CAD specific. But there is a way to implement it on the Vectorworks side and they are willing to tackle it. But I am not sure about the timeline.
Thank you two for the feedback. We will have a look at the other points and come back to you if we need clearification.
