Not sure that Facebook is an option for us, the the O2 might be a no go.
I've not tried but you should be able to just make a "Meta" account now, no linking to Facebook needed.
That said I would still go w/Valve Index for build quality and the least overhead in additional software required.
I love enscape but I'm continually forced to drag models into Lumion because the plant library is so much better.... It would be much easier to make the case to my office that we should be using enscape if the plant library were better.
Enscape's strength has always been real-time rendering with a seamless interface to the host app and a direct link into VR, which was years ahead of other packages. While they certainly could broaden some of the asset basics, they can't/don't really compete with companies who have been developing plant libraries for decades. If your focus is on landscape design, you probably need to be looking at other packages, or put the time into finding and building out your own custom library.
Due to the ease of getting good results, Enscape has taken an outsize chunk of the still rendering market when that was not really their primary focus. The VRay merger was a step in addressing that, but it will take time to see dividends.
Regarding your experience when it comes to troubleshooting this for your users, are you strictly talking about what is being communicated here in the Forum, or the support channels? (support@enscape3d.com / Crash Report)
I'm talking about the language in the error message pop-up.
Typically the user is working along just fine rendering lower-res drafts, then they try to do final output and crank up the resolution, and the error occurs. Their first line of action is to call our internal IT helpdesk. Our Helpdesk
- Checks the switching of the internal graphics card. It is always set appropriately.
- Updates drivers. Our drivers are kept fairly up to date, and this never solves the issue.
After wasting time with that, the helpdesk gets in touch with our rendering specialists to troubleshoot the issue further. Turning off RTX features, reducing the amount of geometry in the scene (section box in Revit,) reducing quality from Ultra to High, reducing output resolution, or a combination of those fixes the issue 95% of the time.
Every time I have submitted this error to Enscape, I get a diagnosis of "VRAM maxed out." Every time I see this error discussed on the forum, the diagnosis ends up being "VRAM maxed out." So if that is the leading cause of the crash, why is the message suggesting to switch the graphics card and update drivers?
I'm suggesting the pop-up could say something like "your GPU VRAM has likely reached its capacity. To reduce VRAM usage, try the following...." (suggestions as noted above)
Then maybe "switch graphics card" and "update drivers" as secondary possible solutions.
I would also think that might reduce the number of logs getting submitted to Enscape by giving users more useful advice in troubleshooting their own issue.
,,,however, I would have thought that if the GPU was to run out of VRAM, that shouldnt stop Enscape from functioning properly, but essentially just be much slower, especially if trying to export a render...? So Enscape is saying that unless you have a 3080 at minimum, the software is unable to produce fully developed renders?
Once the VRAM is "full" it isn't a matter of slowing down - the GPU just can't process any more. Enscape is pretty good at adapting to make things fit within the available VRAM, but as you increase model size and render resolution, at a certain point it is entirely possible that it just won't work. You can use GPU-Z to monitor your VRAM usage. (Windows Task Manager shows this also, but it doesn't always seem correct.)
Even high-quality models from third-party vendors can result in your graphics card memory (VRAM) running full and thus producing this crash.
Could you consider updating this message to better indicate what is -actually- causing the crash?
This seems to be the default error that Enscape throws up when anything goes wrong. In 99% of cases the cause is running out of VRAM due to large models, rendering at ultra hi-res, using RTX reflections, or a combination of those. It is almost never solved by updating GPU drivers or changing which graphics card is used. It sends our users and IT dept down useless troubleshooting paths that do not solve the problem.
Maybe it's the price holding enscape back
If they want to compete with assets they either need to charge more, or have subscription tiers, I think corporate clients would be willing to pay more if they could get more useful assets in one place. Then devote a team to just cranking out assets.
Valve Index is my choice for general use. It has the most/easiest adjustability (good for handing around to multiple users.) You'll probably want to pair it with Vive paddles for ease of use rather than controllers it comes with. Good resolution without being over demanding on hardware. Works with just Steam installed; no additional 3rd party Facebook/Vive Portal/Windows Mixed Reality software needed.
Downside is that it gets a bit expensive; Valve has only been selling the full kits (Headset, sensors, controllers) lately. You can piece it together through eBay or Amazon. You'd want the Index headset, along with [V2 Lighthouse/sensors (more rounded front) + Vive 2 controllers (blue)] - OR - [V1 Lighthouse/sensors (more square front) + Vive 1 controllers (grey)]
If you want to go cheaper, I'd choose the HP Reverb G2. It is based on the Index; just a bit of a step down in adjustability/fit. Requires the additional layer of Windows Mixed Reality on top of Steam, but it works fine. Inside-out tracking, so no external sensors required, which is nice if you want to pass it around the office to multiple PCs, Just keep in mind the hardware requirements; most user workstations are not going to be spec'd for VR.
In the meantime, I truly do hope that this isn't causing too much frustration in your day-to-day workflows or that of your users. I'll keep you posted.
Unfortunately it is absolutely causing a lot of frustration in our day-to-day workflows.....
First off, your GPU has 8GB of VRAM, that will be the main limitation. If the scene fits within that, it will render, if not, it won't. Enscape is pretty good at adapting to make things fit within the available VRAM, but as you increase resolution, at a certain point it is entirely possible that it just won't work. Task Manager does not always give a good indication of GPU usage - try GPU-Z.
That said, turning off the RTX options (used to be RTX Raytracing, now Hardware Raytracing, Denoiser, DLSS) can often fix those types of crashes. And/or turning the quality down from Ultra to High. (turning off RTX makes virtually no noticeable difference, and High is often nearly as good as Ultra.)
What other application allows you to overwrite important settings and NOT prompt the user to save the changes, create a new setting or discard changes? Why is accidentally breaking something that's important easy to do? Please fix this unprecedented and confusing workflow.
I also don't understand how little Enscape appreciates that most of us work reproducibly and prozzessly rather than just sporadically randomly nicely.
Bumping this to ask for any kind of response.....?
We have been holding at 2.9 but plan to roll with 3.4 and this preset workflow is going to cause lots of headaches.
Also, easily repeatable results across different users is critical. Due to its ease of use Enscape is probably being used beyond its intended purpose. (not unlike Sketchup...) It is basically our standard for still renderings now, and some development to make that work better would be much appreciated. Clouds and moving plants that can change from one rendering to the next are not helpful.
fwiw, this has been requested for years. It seems like it should be a relatively simple toggle (render transparent on or off in ID channels) but remains unaddressed. Some previous discussions:
Yes, I would totally expect Enscape to have issues with extents 20 miles away. I can't think of a specific recent example, but it is always one of the things I look for in troubleshooting. It isn't unique to Enscape, I've seen glitches in numerous rendering packages in those circumstances.
I would also say, as much as some programs try to hide, it, the absolute 0,0,0 point matters. If you start building a model on top of a CAD file that is 20 miles from the world origin, there are likely to be rendering issues, even if the model extents are relatively contained.
Also note, you might add turning off the various RTX options to your list of usual suspects, if you haven't already tried that.
I recently had a user with a similar issue, but in Rhino. There is a "mystery" tree that appears in Enscape, but not Rhino. And two that appear in Rhino, but not Enscape. If I delete the two circled in red, it gets rid of the one circled in blue.
I have replicated on a couple machines using both local and cloud asset libraries. Tried clearing Enscape's data cache. The single tree in blue is selectable in the Enscape window, but after deleting, it gives an error message "unable to apply changes." I've pasted the relevant elements into a new file, attaching here.
RTX3080 v RTXA4000
A4000 has more VRAM, will handle slightly larger models better, I've found it to be comparable to a 3070 in performance testing.
3080 will be better for VR.
Although at this point the next gen 4000 series (thanks for making things confusing Nvidia...) sounds like it is due to launch in a couple months if you can hold out a bit longer. Supposed to be another significant leap in performance. Though with GPU prices tanking I wouldn't be surprised if they hold off the new release to sell off 30xx stock first.
Any update on this topic? We look into going down the same road with the Varjo headset and where wondering if you can shed some more light onto potential settings that worked for you and if you got the setup to the point where it became "plug and play" with Enscape?
It is as plug-and-play as any other headset that uses Steam VR.
You can pre-download all the Enscape textures. (ctrl-A in the Material window, Import Selection.) Ask your architect what path he has his textures mapped to. (or you can probably see where Revit is trying to find them in the Revit material browser.) If it is something like C:\Work\Project\Enscape\ImportedTextures, you can recreate that path on your PC, download all the Enscape textures there to pre-populate it, and then Revit will find them in the same place.
Unfortunately if he kept the default location, the materials would be going into his user folder. C:\Users\username\Enscape\ImportedTextures. You can create this same folder on your PC, but you can't download directly to it (as you won't have write rights.) However, it looks like if you download them elsewhere, then copy them into that folder, you can still read from it if you point the Enscape material browser to that location in settings.
(to clarify, you can create that "fake" user folder, and copy materials into it, Windows will just ask you for admin approval to do so. However, you can't write directly into it from Enscape, unless possibly you are running Revit+Enscape as "admin")
I hope the Escape devs are working out a better solution, because this is painful for shared work.
There are laptops that could work, but they would cost 2x as much as what you linked. If that is what they suggested, whoever is specifying their hardware should probably get more familiar with the requirements for this type of software (assuming you aren't the only one doing 3D work there...?)
Is this an in-office or work-from-home position? You might want the flexibility of a laptop in the future if things change. That said, If a desktop is fine you will certainly get more performance per $. Do you have a budget?
Something more boutique/custom is typically a better value than anything off-the-shelf from HP, Dell, etc. Look for a 3060 GPU minimum. If you happen to live near a Microcenter, their PowerSpec brand is decent and well-priced. Something like this would be a good basic PC for 3D work. PowerSpec G511 (I'd bump up the RAM and storage space, but those are easy upgrades if $ is a limiting factor for now.)
Maybe also try reexporting form a newer version.
I re-exported from v3.3 and yes, things seem to be performing better by roughly 10 fps.
Also:
- the distortion correction makes a huge difference. It still doesn't feel 100% "locked in" compared to other headsets, but nearly so.
- The quality settings in the Varjo portal make a significant difference (+/-20fps.) On "low" I found framerates to be similar to the Vive Pro, but the Varjo still looks better. So there are plenty of options to play around with and fine-tune.
2.) I unfortunately got HTC Vive controllers, but not the blue ones. (Mistake #1. I have fixed and gotten the blue controllers instead. After more research this was my mistake in not reading instructions carefully enough.)
The other option is to get v1 base stations to use with the "old" controllers. Varjo works with either. Honestly I find the old base stations to be a little less fussy.
- I also think creating a new preset should duplicate from the active preset, not create one with the default settings ...
This is just bizarre behavior. Hitting the "big orange button" should imply that you are saving things the way you are currently seeing them. NOT "change everything" and make me wonder WTF just happened to all the settings I have been tweaking.
