Thanks. It worked. Just a bit strange that I have to do that, since I only have Sketchup and none of the other applications.
This is already something that we have resolved internally - It will not be necessary to install Enscape for all cad solutions with our next upcoming preview 7. Our apologies for the inconvenience.
Are there any bugs relating to saving panoramas? In this and the preview 5 it doesn't seem to save them after they render
Nothing that we would be aware of, I just tried to reproduce this and did not run into any problem.
Can you send in feedback including your logs?
Nothing that we would be aware of, I just tried to reproduce this and did not run into any problem.
Can you send in feedback including your logs?
Done
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 ...
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 ...
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.
Thanks
I just don't see the reasoning behind spending THAT much effort to create something that is basically just bloat for most users.
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.
I get your point, but it really only highlights the question... why on earth spend SO much development time on a feature that 95% of users will never use, due to inaccurate, under-detailed data?
I totally agree with you. I've been using the osm dataset for years and as soon as I learned that OSM was going to be used for this feature I wrote a post here about why I think this will be too basic for most users. IMO, most users will expect google earth style context, which is clearly very far from what OSM can deliver.
The real problem with the OSM dataset, is that both the building roof shapes and the building heights are very unreliable in most places, which really defeats the purpose of trying to use it for context models. In my experience, site context models are all about having the accurate building shapes (for which roof shape and height are absolutely critical).
I agree with Christian that sometimes you want to show the context in a "conceptual, non distracting" way but that is usually achieved by simply rendering it with a white material override. Never once have I heard that people wanted to simplify the shapes of the surrounding buildings so much they become inaccurate in terms of their overall shape.
I should also note that I am a big supporter of open data and opensource software. So it's not that I'm against OSM, far from it. But one also has to be realistic...
Christian Radowski Vertical water was first brought up in a discussion back in October of 2018, almost 4 years ago. Since then, even after numerous posts about it, not a single attempt has been made to address it. It isn't even on the new feature voting page!
Almost every CAD software has some plugin that allows OSM data to be imported into the model itself. If someone wanted to use that data they would put it in their model not add it in the rendering engine. Nobody asked for this feature and I am on Herbo 's side when saying this is another feature I will never use for multiple reasons. I highly doubt this feature will ever stack up to the impact adding a decent vertical water system could make to this program. But OSM importing gets developed first.
Where is the rational behind which features are being added? It makes no sense.
Guess it would be better to connect to something like Nearmap or MetroMap - MetroMap even if you must pay
it will not make the Open-Source fans happy: try OSM in Australia it is completely useless.
The fact is good 3D information costs Money to create but the more use it the cheaper it gets
so the ability to connect to a different data source would be useful.
I can still see me using the site context feature as someone who does a lot of projects in rural-urban interface areas, especially since a lot of our work often overlooks a view. In this case individual building accuracy from context isn't critical. If a project is in a more urban area it doesn't seem like too much of an stretch to just use the site context as a guide for me to trace model in place something that is a bit closer to correct in terms of levels/structure, assuming things like roads/terrain are correct for all the above.
In either case, I can see the feature saving time or adding value.
Nothing that we would be aware of, I just tried to reproduce this and did not run into any problem.
Can you send in feedback including your logs?
The only bug was the one inside my own brain
Where is the rational behind which features are being added? It makes no sense.
I think that this is the wider question that needs to be answered, I have questioned/challenged enscape's development policy/process for some time. The site context "feature" while being useful for some users, to the majority it seems like a complete waste of resources when there are so many other things that could be worked on that would add real value to the existing user base. 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!!!
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.
Those companies were using tools to import context data. Solely for these phases. More tools = more effort = more costs.
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.
Some news for users who use 3dconnexion peripherals. We are stopped at 3.2 preview 6 !!!!!!
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.
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.
I understand that they might use OSM for quick and fast context modeling but the tools to important that data into model software already exist. Just because it's a feature that can be added into Enscape doesn't mean that its one that should be. That's not say every 4 year old feature request needs to be added in first before a new feature, I just highly doubt this feature will be preferred by those 20 firms over their current system.
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.
This makes zero sense and the current system is even worse now than it was pre the voting portal. If anything this current system creates more work on your end.
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.
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.
The issue with the current system is that Demian is telling users to make their suggestions/wishes using the enscape portal. that's great but those suggestions/wishes are NOT being shown on the portal therefore users are not getting a chance to vote. Only suggestions from users that are still making them on the forum are getting upvoted, so users who have transitioned to the portal are being disadvantaged as there is no mechanism for those suggestions to be seen or voted upon. We can comment on "features" that enscape has deemed suitable of development but cannot access other users suggestions. This system is fundamentally flawed and needs to be re thought
Also there needs to be an option other than "Nice to Have" or "Important" or "Critical" it needs to be "NOT REQUIRED" so that features deemed under consideration can be removed and replaced with features that users actually want.
My feedback would be that of the 29 features listed in the under consideration tab
NOT REQUIRED - 12
NICE TO HAVE - 4
IMPORTANT - 4
CRITICAL - 9
Everyone will have a different view of whats important to them but without a clearly designed and transparent voting/suggestion system we will be at the mercy of enscape's already established internal roadmap.
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 ;))
