Posts by snowyweston

    Can you incrementally build the scene up, loading links 1-by-1, to isolate the culprit, to focus your troubleshooting?

    Knowing the project, the models aren't built like-for-like, so whilst I also shudder at the thought of turning off door hardware, if you've MEP models loaded, there'd be my first go to to kill off sub-cat. junk. Likewise sub-nested .dwg content hidden in .rfa. All the usual bad stuff in Revit hurts Enscape considerably - but then, so do a lot of proxies.

    I'd also echo Phil's thinking that render assets are playing a huge part - but more again in terms of parity between the models than mega texture maps.

    Q. Is this for an entire site walkaround export? On sites that scale and style I'm surprised you're not going the teleported panaroma route.

    In the end, there's always putting in a purchase order for that Titan. ;)

    to this same point (though I haven't done A/B comparrisons of stills vs keyframes) one thing I find immediately evident (in video outouts) is the "speed" it takes for the automatic exposure to "catch up" with a physcical transition* between scenes of contrasting brightness.

    *time-stepped stills seem to handle it well enough when "only" lighting is changing - but add geometry changes into the mix and it gets laggy.

    I used to know the correct/optical term but have forgotten it - but essentially it's the effect we see a lot in FPS games nowadays when moving indoors/outdoors - and whilst "technically" correct (to experience a bloom/blinding) - and arguably perfect in walkaround.... in an output video, where the movement might be exagerrated (faster) the renderer sometimes appears to "stutter" or "skip" in resolving the difference, resulting in over-blown, or too dark scenes undesirably quite a few frames later.

    DOF transitions seem to suffer similarly.

    Is it that each frame is "only" given a set time to finalise/gather? It's certainly more noticeable when attempting fast changes or cuts.

    For now we've resolved to speed up certain scenes in post (which is where I believe most video-chopping should happen anyway) but instead of requiring us to artificially stretch our keyframe time markers (and increase the number of infill frames to be rendered) - could there be a slider-adjustment for "per frame finalisation" on video outputs, where, GPU memory (and project-time) allowing, we might set "number of passes" - to work in conjunction with our view setting profile(s)

    i.e. a bit like Handbrake's predefined profiles...

    view setting: "ULTRA" + video setting: "FAST" output = min. compute-time per frame

    view setting: "ULTRA" + video setting: "SLOW" output = max. compute-time per frame

    view setting: "DRAFT" + video setting: "FAST" output = min. compute-time per frame

    view setting: "DRAFT" + video setting: "SLOW" output = max. compute-time per frame

    I know it's fashionable to dump on Powerpoint - but it has it's moments - and even though all too often over-used, its slide transitions can still really be used with great effect.

    Why am I talking about Powerpoint? Well, sometimes a story narrative moving through saved viewpoints in Enscape isn't singularly linear - and when one taps the page-down key to move forward through the story and sends everyone powering through a building along the curious pseudo-spline connecting-path the Enscape creates, it can be very jarring.

    By now almost everyone using Enscape must have seen Phil's clever hack-trick with keyframe fades - but that's (only useful) for render-saved video outputs. In standalones, and live-sessions, the "eyes-open-teleport" between disconnected viewpoints becomes a challenge - and whilst we encourage our folk to keep the story as sequential as can be, as if on a walking tour, sometimes you "just" have to launch yourself 100metres into the air, or 1km away.... so... could we perhaps, one day, see some kind of (elective switch-on/off) fade-to-black/white or (other) transition effects?


    noting this tweet about Maya, Nvida & RDC I followed the link - that then leads to Nvidia's Developer Site - I dusted off my account details and signed in, then fetched their "accelerated RDP" tool... installed it on my (remote) work machine running an RTX2070S - restarted, fired up Revit and launched Enscape* with no error!

    Gonna push it round a little before actioning a full rollout - but this could really save uncomplicate some people's lives!

    *albeit a scene with a single hastily modelled wall

    A few teething problems aside, our company is transitioning to work from home fairly well - using RDC over vpn to drive our workstations remotely and, lag aside, get almost at-desk working performance.

    Save, except for, Enscape.

    Now I know it's come up before (perhaps by myself) that the native Windows RDC client does not support Enscape (launches) - and that other remote platforms potentially may*... and i know I almost allude to doubling-down on the please-please-please in my thread title, but we know it's not Enscape's problem that Windows RDC doesn't support te OpenGL stuff...

    So, as a workaround... would it be possible to create standalone exports without needing to launch the viewer? We are fairly confident in our presets, saved views and model content to do this - and then we could either bring the .exe to our local machine - or get to sharing it with our clients & consultants (albeit "blind")

    ...anyone got any suggestions/recommendations? I found RealVNC really clunky.

    We are finding standalones created using 2.7 complain on machines that haven't the required C++ redistributable thingy

    This is the first time we have seen the like (with any version) and makes our move to 2.7 difficult as it forces the hands of others (generally our clients!) to need to update their computers to review items we send them (not cool).

    The error it generates is also vague - and suggests contacting support@enscape - where, it would (should?) just say "you need this installed" to save you/me any comebacks...

    until now, to ask about "scale" for Enscape would have been a perverse notion - but now that we have orthogonal views in 2.7 (YAY!) the immediate follow-on* is...

    To save us all eyeballing pixels-to-pixels when sizing-up and overlay'ing annotatative outputs from other sources (read hidden line views in Revit, text objects in InDesign, etc) - might there be some way to set some kind of "scale" to (ortho) render outputs, so that - for example we might accurately know 1:1 "pixel-to-X" - where x is a real world measure?

    *okay, maybe second after transparent/alpha background exports


    since the above was more an observation than an "idea or request" - here's one to tag on the end:

    when in an orthographic (elevation) view, might right-click "orbit" convert to "turntable", (removing the tilt behaviour) - or better yet, a whole new key/control for such? about model-space-center (as rotation origin point) would be just fine!

    We have just been looking at the orthographic projected view - after wanting (needing?) it so badly for so long.

    But I think we have found a gotcha - that will, at least for now, limit us using it.

    Specifically, the "parallel" view appears to be to NESW, not any given plane - so where we have rotated elevations (almost always) and want to go perpendicular to that façade, we can't. Unless we've missed some setting?

    Hopefully my awful example model shots explain what I'm getting at.

    Quick question from my team - we have a mix of GPUs running in our office, 10 RTX 2070 Supers, 10 GTX 1080, a 1080Ti, and a whole load of Quadro... now with the RTX rendering switch in General Settings, we're curious, what happens (if anything of significant) someone who has, and works with, and then exports an RTX standalone, but the next person to open that file doesn't have a RTX? does it auto-step down to "regular" mode?

    essentially it’s just a list of what’s in the model - I already have that in Revit.

    we do "virtual tours" to walk our project models - screen-grab-snagging all along the way. To be able to select an element and get (at the very least) it's ElementID - to aid in re-locating the problem once back in Revit, has already been imagined by my teams as an incredibly useful function.