Adding my vote in agreement on this as well.
Let me give a little background on this... for the basic jist you can skip to the next paragraph. I was tasked recently with creating an aerial rendering of an entire (large) airport campus. We had individual models for each of the concourses etc in Revit, but even with all unnecessary model categories turned off in Revit, the combined model was too much for Enscape to handle all together in Revit. My solution to this was to export all of these parts to Rhino via FBX and further optimize them in Rhino. This worked perfectly, and I have been extremely pleased with Enscape's load-up and reload performance in Rhino, which is dramatically shorter than Revit's, despite the fact that this model has close to 100 vehicles, almost 10,000 lights, trees, a complex topomesh, a high-resolution custom HDRI skybox, and many reflective and photo-mapped textures. Amazingly to me, despite all of these things the file size of a standalone model from this project comes in just under 500mb. Unfortunately, what I do not have in this model is the detailed interior of our current project, which has been developed in Revit with textures perfected for rendering in Enscape, realistic IES-based lighting, and 3D RPC elements placed throughout. Even with a full export of the Revit project to FBX, these lights, texture settings, and RPC elements are not maintained in the transition to Rhino.
So, here's what I would LOVE to be able to do - to take the Enscape standalone of my Revit-based interior/shell model (for one project within this large airport) and insert or merge it with the Enscape standalone of my Rhino-based site/context model. I'm not really trying to suggest getting into Lumion territory so much, but for this type of task the ability to do our work in Revit and then merge scenes with a photo-mapped site developed in Rhino (or Sketchup for some) would be a game-changer for us in terms of opening up our workflow to use each modeling platform for its strengths without being confined by its limitations.
Is there any chance that this is possible now by dissecting the .exe files, if the two models share a coordinate system and skybox? If not, is it something that has been considered for development? In my opinion, this would get Enscape a lot of attention from the Lumion holdouts, and the ability to take accurately-rendered lighting from Revit and merge it with scenes from other software platforms would be even better than what Lumion offers.
[Blocked Image: https://i.imgur.com/vX2GlCA.jpg]
Thanks to all for the responses. For reference, I am rendering with a GTX1070 or 1080 depending on the model, and have experienced this issue with both the current Enscape build and previous ones, but probably moreso with the current build now that I think about it.
Clemens Musterle - if there was a way to render a 'standard' capture in the same manner that panoramas are rendered (meaning how the render frame scrolls from left-to-right across the image field), that would be fantastic, and would seemingly eliminate the problem... I don't export very many panoramas, but when I do they are always set to High resolution, and I have never had Enscape fail while exporting one.
I have read several posts in the bug reports section regarding Memory Overflow (where Enscape and the host application quit unexpectedly while exporting a high-resolution image). Unfortunately, I have experienced this myself in both Revit and Rhino when rendering large models at 6-8K resolution.
I have recently been asked to create higher-resolution exports of a huge scene that I was unable to render above 4K without experiencing Memory Overflow. The images that I need to provide will be printed on very large banners, so my preference would be to render them at 8K as a minimum.
My question is this:
Does anyone who has suffered from this same issue have a workflow (other than manually adjusting the view and manually stitching in Photoshop) for breaking a set view perspective into 4 constituent quadrants and rendering each of these individually as a way to achieve a higher final-output resolution? I would love to find a way to do this where the images line up perfectly edge-to-edge without stitching manually.
My experience echoes Herbo's, and as someone who also works with both very small/intricate models and VERY large models that don't need and/or can't handle the same level of texture detail, I would like to give a BIG up-vote to the texture-resampling slider that he suggested in his first post.
To add a suggestion to this idea - if a slider offers too much variability for troubleshooting purposes, then perhaps a "low/medium/high/ultra" option similar to the current Render Quality dialog would work instead.
Demian Gutberlet you may already be aware of this, but I did not receive your PM, and when I tried to send you one I received the following error:Quote
Demian Gutberlet is already participating in too many conversations and cannot be added.
Unfortunately, I am not able to share the Revit project with you - however, I would be happy to review any relevant information with you over a web call via GoToMeeting or Skype for Business (which my company uses), as well as send log files (done) and provide you with any desired metrics and data-points relevant to the Revit project and/or hardware.
This issue is still unbelievably frustrating for several users in my company, which currently holds 15 floating Enscape licenses. I am working on animations in a large model, and recognize the significant improvements that have been made to movement and path smoothing between keyframes in 2.5, so again today I tried upgrading from 2.4.1 where I have been stuck for months. I upgraded to 2.6 and was (as noted in another thread) unable to see any of our Archvision RPCs, so I proceeded to reinstall 2.5.2 with the assumption that you must have been correct and my experience was a either a fluke or attributable to textured reflections. Unfortunately, with the same hardware/drivers/model/view/settings as I was using yesterday without issue in 220.127.116.110, 2.5.2 has such extreme input and render lag that it is... not borderline unusable, but completely unusable. That is the case even with Rendering Quality all the way down to Draft (I have never felt the need to work in any setting besides Ultra in my experience with 2.4 and below). This means that I must once again spend an hour or more of billable time closing down my project, reinstalling a legacy Enscape build from 7 months ago, and relaunching my rendered view to work on pathing for an animation which I know would be more successful in newer versions of your software. I am by far the heaviest Enscape user and advocate within my company, and all of our users with whom I am in contact are experiencing the same issues with large models in newer Enscape builds.
I really do love and rely on your software, and I apologize for the tone of this message, but... PLEASE put someone in contact with me or the license-holder for my firm with the intent to work through this until the source of the problem is identified - otherwise we will have no choice but to refocus our attention to other software options for rendering, much to my disappointment.
Tested the same project (blank except for RPCs) in 2019.2 and there was no difference from the above. The RPCs in this test file include Archvision default entourage, AXYZhub 3D+ RPCs purchased through Archvision and referenced from a company server location, and custom 3D+ RPCs created using Archvision's web-based tool and referenced from a local folder... none of them are showing up. Again, triple-checked that "Replace Archvision Content" is UNchecked. Not sure how I could be the only one having these issues.
I just tried this again (with Enscape 2.6) on another machine and I am experiencing the same issue - this time in a fresh project with only the RPCs added to it, and these are RPCs that are working fine in 2.5.2. I can send you the RPCs, just PM me an email address to send them to.
I would like to add onto this a feature request for the ability to export animations as an image sequence with background masks, as this workflow will be near-impossible without that.
As the title says - tried upgrading Enscape to the 2.6 Preview version on a shared graphics machine in our office that is running Win7 / GTX1080Ti / Revit 2018.3.
With 2.6 installed, Enscape functions as it should with the exception that Archvision RPC content does not show in the rendered view. This content IS visible in the same machine/model/view after downgrading to 2.5.2.
For reference, I did triple-check to verify that "Replace Archvision Content" was UNchecked.
To the development team - feel free to give me a shout if you would like to beta-test anything in terms of this functionality... I have immediate use for it.
Thanks for the insight, Alexander. Would you say that the texture downsampling/optimization process would or would not add a perceptible amount of loadup time when comparing a model with no textures above 2048px to an identical model with perhaps 20 textures above 2048px?
To go back to my original post, I am also very curious about the lagginess after the model has loaded that I (and other users in my firm) have experienced with more recent Enscape builds. I was inclined to attribute this to the reduction in texture size limitations, but with the reintroduction of downsampling in 2.5.2, for me at least, the smoothness of navigation and lagginess actually went from bad to way worse, which is what prompted my downgrade to 18.104.22.1680 and this post. My comparison between these two builds is running the same computer, same GPU driver, same model and same Enscape settings.
I know nothing about the backend of this software, but for what it's worth, to me it almost seemed like "Automatic Resolution" was not working, even though I triple-checked Enscape settings to ensure that it was enabled, over multiple attempts to resolve the issue including restarts. The issue I was experiencing (independent of the long load times) was essentially getting one updated frame in the Enscape window every 20 or so seconds. This one frame, when loaded, would be noticeably sharper than usual and even have some pixelation around edges similar to a high-res image that has been scaled down, which is why I mention automatic resolution. Even dragging or resizing the Enscape window itself (not the content loading within it) was cripplingly slow. So at least for me there is some other issue at play here, and given my immediate success with the older Enscape build mentioned, I am disinclined to believe that it is hardware- or driver-related. I should also mention that we have at least two additional staff members who are working in the same model and who are experiencing the same issues.
I am going to add a list of some additional facts about my model below, in the event that it helps the development team or others here answer the question about the source of these issues:
- presence of NURBS content in solid polysurface form brought into Revit from Dynamo (only one family)
- many *'d views... worth noting that the Enscape build that I am having success with is pre- 'Views' sidebar
- *'d views include several 3d views and several perspective views
- presence of roughly 800 Archvision RPC entourage families, many of which are "3D+" (i.e. the rendered content is actually 3d)
- high degree of reflective materials (glass, terrazzo, powdercoated metal, etc)
- Revit model filesize is roughly 970mb; links loaded in our typical rendered views add roughly 650mb to that
...I will update this post if I think of anything else that might be contributing to my issues.
I am using Enscape to render complex Revit projects with several Revit links and large numbers of RPC Entourage coming from Archvision. I do not expect Enscape to work magic in processing such large amounts of data, but it seems like lately my load times have increased substantially and I would like, at a minimum, to develop an understanding of why.
While I understand the ongoing status of texture resolution and downsampling treatment in each release, either this is a huge issue for the model I am working on currently, or there is something else at play. For what it's worth, we have recently gone through all of the textures in this model to eliminate large file sizes and resolutions... nearly all of our bitmap textures are now under 1600px square and 1mb, and most are much smaller, with perhaps 6 exceptions that might be 3000px square and 2.5mb. After crippling startup times and completely unusable lagginess in recent and current (as in today - 5/23/19) Enscape builds, I just rolled back Enscape to 22.214.171.1240 and the difference in smoothness of navigation once the model is opening is night and day (and that's an understatement).
I have immediate use for some of the features in more recent versions of Enscape and would prefer to use the most current build, but unfortunately I am finding that impossible with respect to usability for some reason.
I am on an Alienware R15 with an i7-7820HK, GTX1070 and 32GB RAM. NVIDIA drivers are up-to-date as of today as well.
Independently from the feedback above, I am also curious to understand more about the bottleneck between Revit export and model loadup in Enscape. With a large model I am experiencing at least 10 minutes of "pause" between Revit's completion of the model export to Enscape and Enscape's processor/GPU blitz in the minute or so preceding loadup of the model in Enscape. During this period, Task Manager shows a dropoff in CPU and GPU usage to ~30% or less, RAM usage drops from ~90% to ~60%, and disk usage is negligible. Can someone explain to me what is occurring during this time, and whether there is anything that can be done to reduce it?
Apologies for the slow follow-up on this. I appreciate what others have added to the discussion, but I will elaborate a bit more on what my request pertained to here. Having an inherent understanding of what Tyler points out in his comment, while I would love for some type of scene integration with GES to become a reality, I realize that there are a mountain of different factors that would seem to make this almost completely out of the question. Vincent's and renderwiz's comments are pretty much spot-on. The camera paths and their keyframes, and - importantly - the software's interpolation of movement and smoothing in-between those keyframes, would need to match up perfectly in order for this to work. As mentioned, shadowing would be difficult, but would be left to the user to overcome as needed. The workflow, as I see it, would be to simply overlay rendered content (with a transparent background) on top of GES content for each frame of the animation before assembling these frames into the finished animation. Having the ability to do this would be tremendous, and doesn't seem terribly far-fetched as long as there is some way to reliably and accurately match up the 'starting point' for the animation in GES and Enscape.
Adding a vote for this - I am on the latest version of Enscape and am working on a large project (Revit) with several linked models which are not changing - very frustrating to sit waiting for export and reload of the active model and linked models when the only content in need of updating is a minor change within the active model.
I have not posted here before, but the firm I work for have been using Enscape for several years now and I would say that it has been the best change in our design process since transitioning from AutoCAD to Revit. So - to the development team - thank you! While we have Lumion 9, the integration of Enscape in our application workflow means we use Enscape much more frequently, and are beginning to utilize it for animations in addition to stills, panoramas, and standalone models.
Concurrently, we are also beginning to explore Google's new Earth Studio tool, which provides After-Effects level control for creating animations in Google Earth, and does a far better job of rendering Earth content during the animation process compared to the desktop application since it is not limited to 1gb of RAM and 2gb of disk cache as the Google Earth Pro desktop application was. Importantly to my question here, the content generated when creating an animation with Earth Studio is an image sequence, which is then assembled in After-Effects or similar. Also important to note is the fact that that this tool does still retain support for KML/KMZ files, which can include flight-path data and camera settings.
What I would like to do, and what I am soliciting ideas or improvements for, is the ability to somehow export my Enscape animation path and camera settings to KML format (or vice-versa from GES KML to Enscape animation path) so that - at the end of the day - I can generate the same animation in GES and Enscape, and superimpose the Enscape content on top of the GES content for each frame using After-Effects or a script/action in Photoshop.
This sounds like a tall order, but given the ability of each of these platforms to utilize detailed numbers for setting latitude, longitude, and altitude, as well as data for camera settings like pan, tilt, and focal length, (plus the ability of GES to generate 3D tracking points for After-Effects) I am hopeful that this workflow might be a possibility, either now or in the near future. If it is, it would be of huge benefit for us, as - in the business of designing airports - we would love to do more aerial animations without having to invest the significant amounts of man-hours that it takes to develop site context which can sometimes be spread out over hundreds of acres.
I would love to hear any suggestions from the developers or ideas from other users about how to go about making this workflow a reality.