Hey Demian Gutberlet any news on the issue I reported? I had to roll back to preview because the Enscape custom editor browser got very slow to navigate (not the gallery itself, but the 'editor browser', not sure what the right name is for that newly introduced panel).
Hey Pieter, yeah that has been fixed on our end.
Display MoreI'm STILL having a hard time seeing the relevance of the site context feature. The quality of the data is simply SO bad that it is unusable in 95% of cases. I've tried major locations from all over the world, and in most cases it is just too far off reality to be usable in any scenario. And I now know that I have to do a thorough quality control on the imported data before I use it (let alone show it to a client).
Here are some examples:
Paris:
Copenhagen:
Hamburg:
Rome (the Vatican):
Singapore:
And in many places I just got this, when trying to import:
These are some of the major places in the world! And if the quality is that poor here, Then I cant imagine how far off it might be in lesser known areas.
in my opinion this feature is just bloat in the current state. I have a really hard time seeing ANY use case for it, not even for the earliest studies in a project.
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.
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 ...
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?
Just to be clear: this is not targeted at Christian Radowski specifically, just general roadmap feedback.
Don't worry I am not taking it like that I understand the misgivings you and Herbo have I myself cannot do anything about this except for relaying it though.
I know that is how it works
Why not include the thumbnails in the installer? or have them update in the background, so they are ready to use when needed? there are a lot of options that could help
And its pretty much the point from my previous post... half baked features. This should have been fixed a long time ago, but instead new features are prioritized.
Thanks for the feedback
Sorry but here I have to disagree with you I know it seems easy but there are way more concerns than that and baking them into the installer is no option at all. You could set up a shared directory on a network and then store the asset library as an offline library there that way only one person has to download them.
You can also do the same thing locally instead of scrolling through if a network share is no option. That is precisely why we added the offline asset lib. in cases where users want to have access to the entire library all at once.
UPDATE: Also you don't have to do this for every version the local cache should not be cleared really its separate from the installation. The asset releases for the library are also not linked to the installer in any way you could in theory stay on an older version and still get the new assets when they are released.
UPDATE2: I also cannot really comment on the prioritization, I can tell you about the current development cycle and what we are working on right now but the roadmap is being managed and defined by our Product Management team. I don't really want to speak for them I don't know all the details that lead to the prioritization. We are not really a monolith.
That's what we do now but as you can imagine finding what one needs without thumbnails isn't great. Like you said: it works, but it's clunky and because of that it doesn't scale beyond a couple dozen materials.
Display Moresorry to hear that. Working with the matpk. is simply too clunky. it would make SO much sense for this whole workflow to be tightly integrated with the material library... right now you have overlapping features that would benefit a lot from being merged and re-thinked.
I really hope that some of the "low hanging fruits" of features will be prioritized soon. These small things are actually what would bring real value to users. it seems like it would take a fraction of the developement cost compared to the "site model" feature... and it is 10x more important and useful for most firms.
right now it seems that a lot of the new features is implemented in a half finished state, and then they are forgotten about. examples:
1. Material library - without custom materials, it is not suitable for professional work.
2. Custom assets - without a way to organize them (and an easier way to make them), the feature quickly becomes useless and bloated.
3. Linked model - why can't I see a list of all the linked models I have in a file? it would make it much easier to organize a scene
4. video editor - still cumbersome to use in a lot of ways.
5. skybox/hdri - why can't I move it up and down? other renderes allows this?
6. slow loading assets - why has this not been fixed? it takes ages to locate what you need. Why not have the thumbnail pictures stored locally?
... and more.
Please, make all the existing features awesome and useful before moving on to new stuff. Otherwise the software appears half baked and bloated.
1000% Please finish the pieces that have a zillion user complaints but seem to have been left hanging.
I can gladly raise these points internally as well. I fully understand what you guys are talking about when it comes to features not being "finished" in a sense that a first iteration was released but we did not further improve it down the line at the same time there are a billion reasons to prioritize one item over another when it comes to defining a roadmap. I think that our Product Management team is trying to incorporate these "iterations" you are asking for as well.
6. slow loading assets - why has this not been fixed? it takes ages to locate what you need. Why not have the thumbnail pictures stored locally?
... and more.
This is already being done btw. once they have been scrolled into view they are stored locally same goes for them being displayed in the renderer.
I get the performance complaint though, we have improved it several times already but it can still be slow.
Working now
If you run into stuff like that again please submit your error reports like outline here
Otherwise there is now way to really help you ideally just make a screenshot of the import dialog that shows the 2d that will give us a rough indication of what the configuration settings are.
Display MoreGreat progress
The site model feature is not something we are gonna use, so no comments for that
Overriding materials is nice though! really useful! Now we just need custom materials in the library for it to actually be usable
when you finally get around to doing custom materials, here is a suggestion
Hey Herbo, currently no plans for that but as I wrote in my response to Pieter, nothing prevents you from creating .matpk exports and put them into a folder for the time being and import them into the target material I know it's clunky but it works
I don't see myself using the context model but the replace material feature is helpful. If we could add custom materials to the material library it would be even more useful.
Hi Pieter, you can organize material exports to form your custom local library and then just import them from a network share into your target material it does the exact same thing.
Ohhh love the site context!
Would there be a way in the future to have the site model import on the skybox layer so it doesn't interfere with modeled topo (and would look perspective correct at ground)? Bonus would be that it would be friendly on performance too. We often have topography modeled already based on accurate survey data for the plot we are building on, but obviously this doesn't include context for anything outside the survey data. Being able to load a helpful semi-accurate skybox of the surrounding region could help a lot. Unless the site context feature is planned to support incorporating already-modeled topography somehow in its future.
This is aiming more at adding 3d model outlines matching the local surroundings of your project we will add options to hide the native massing if possible for your CAD but we currently have no plans to do this on a skybox level.
Where is a better place to discuss this?
You can send me a detailed list of ideas via PM and I will gladly pin them to the UX bug I will create for this topic. There is no guarantee that this will be exactly the final outcome of us iterating the UI, which in turn is not currently planned either due to the team working on different things but at least your thoughts and ideas don't get lost that way
IMO "deactivate the geometry export when switching views" is technically correct but specific to the point of confusion.
"Refresh View (On/Off)" is brief and clear.
Agreed
Again guys this is not the right place for this discussion and the proposed tooltip is completely missing the mark of what actually happens.
Agree with @Pieter. Enlarge the slider icon. IMO Get rid of the other icon.
I won't really engage in a design discussion about these items in this thread guys a different can of worms and tbh. and as Pieter also already said "highly subjective" changing UI with this resolution (on this micro layer I mean) is best done using quantitative analysis. Don't worry we have filed this feedback and have received Phil's feedback regarding this several times already.
Bottom line for the actual topic of this thread: I'll let you know here once I have an ETA sorry for the wait
Update: This issue just shows up more using linked projects it likely already exists for single projects as well but is less visible. Anyhow we are looking into a fix for this right now. We'll try to include this within a service pack of some sort for 3.2
Okay so in general the toggle works as expected (for me at least with the default Revit project) running 3.2 I can just batch render all views without a re-export:
It appears though as if as soon as you add another linked project we run into a scenario where we actually re-export the linked projects:
I will file this as a bug and we'll look into how this can be fixed and packaged into a 3.2 service pack, for now you could (I know that this is inconvenient) try to merge the linked projects together by binding the link or something similar. Sorry for the inconvenience we'll add this as a test case internally to prevent stuff like this from happening in the future once we have found how to prevent this.
Display MoreI think there are 4 ways the "reload geometry" toggle could be improved
- Add it to the to the batch rendering dialog
- When off: display what view your enscape geometry is based on (right now you just have to remember what view you were on when you turned it off)
- Make it visually more clear (it's hard to understand when it's off an when it's on)
- Remember the slider setting across sessions
I can add this to our internal UX bug backlog but tbh. I personally disagree with point 3 because that toggle button follows all usual conventions.
Display MoreGuess I'll explain again. So we often export 80-100 renders at the same time for a fairly specific reason (we upload these renders into a 360 viewer which we can embed into webpages. So essentially we're rendering a 360 video frame by frame. And no, for our use case, we can't use Pano's).
So within this workflow, we have no need to re-export geometries from Revit for each render, since all of the settings, time of day, exposure, etc. remains the same for each of the 80 renders.
In 2.6 and earlier, we would load up Enscape, set all of the lighting, TOD, etc to what we want and then batch render all 80 renders. This would take maybe 15 minutes.
With 2.7 and onward, every render within a batch is reloaded from Revit into Enscape. So this is similar to closing and reopening Enscape 80 times... So our render times for these 80 renders went from 15 mins to sometimes 3-4 hours depending on the model complexity.
I understand how this may be useful if for example, we have 15 renders, all with vastly different settings. But for our workflow and what we need, this has been and continues to be a huge issue. And I'm not the only one.
What we suggested was implementing a toggle which turns this off. This was implemented in the latest update but for some reason, at least for me, turning the toggle on or off has absolutely no effect on whether or not Revit exports geometries each of the 80 times.
The problem was described precisely over and over again. I got in contact with one of the customer support team on a meeting a few months ago where I described the issue LIVE, and they clearly saw and admitted there's an issue.
Let me verify your bug report this is not the expected behavior the whole purpose of that toggle button is to manifest the exact thing you want only change the camera position, time of day and apply any linked preset not re-export geometry.
Okay thank you this is a bug on our end but there is no indication yet what actually causes the issue it seems like it is specific to VW but we have not yet been able to reproduce the issue locally. Sorry I unfortunately have no quick fix for you. We'll keep digging it does not seem to be related to your VW settings directly as mine look exactly the same.
Does the issue persist though does it always happen with VW and always distort the same elements of the UI?
