Posts by snowyweston

    a thought... instead of doubling up the Enscape asset library content with low-poly variants of models -

    forcing users to swap out low-to-high and vice-versa in a a tedious merry go round,

    why not enable a switch in settings (global, or ideally view) that offers: "read asset Y/N"

    where

    Y=all the details

    N=the facetted model we see whilst in our native applications


    (which are effectively the low-poly version, no?)

    Almost entirely sure someone, perhaps even me, has asked this before - but to double-down AND BUMP


    (speaking to Revit here, but I'm sure other platforms would benefit from this)


    can we please please please get the descriptors used in the asset library thumbnail previews


    injected into a parameter in the family please?


    I use a Dynamo script that parses the geometry* of placed Entourage Planting asset

    *culling the ones that are "only" mesh, or "just" surfaces


    that defines a type definiton (and catalog) of the widget family we use to place in our models - however, the "only" useful information to mine is the family name, leaving us with:



    now that'd be fine if I had a content management tool like Kiwi Browser to better search/filter these for "walking", "elderly", etc - and add tags for "day time use only", and such - but we don't - and I imagine a great many others don't either.... whereas, if the Asset library description (and potential other useful tags) were included in the .rfa, raw, from Enscape, a one-time date-push activity by yourselves could save hundreds/thousands of hours of customer time sifting and sorting the assets into an applicable resource.

    Buying Enscape is only going to help you make an Enscape export - which you're already presumably paying someone to make for you - and so far having issue opening because, despite your generous system ram, your GPU's ram errs toward the lightweight


    Mind, a RTX4000 is no slouch, I run an 8GB 1080 at 3840x2160 on larger standalone files than those w/ no issues - its odd that you are, perhaps the files you're being sent are a bit shabby? have you seen stills from them? Perhaps they're just too crazy detailed? We can only guess.


    w/ regards the web-shared viwer links - they are "open" - but no one can guess the GUID and the author (who shared them) can pull them whenever you request - sure, not the MOST locked-down thing ever - but that's the tradeoff for convenience. Password/access protection has certainly been requested - similarly localised hosting for those with the infrastructure to do so - but its all pipeline.

    To add to this - can we also get more folk in jackets and colder-weather attire generally? not talking polar expeditiongear - but folk in t-shirts look a bit odd in night scenes.


    ..and whilst I'm here, I was recently asked by someone in my team if there were Christmas-themed assets (santa, sleigh, snowpeople, etc) - I groaned, knowing full well what their plan was - but did say I'd pass on the suggestion.

    (Paul) I read it as the "export complete" pop-up message post .exe export - which we're no longer seeing, and so have to eye-ball the save-to location expectantly before starting a new action... which, is, er, annoying,

    Hi!


    I've just run into this aswell - albeit (thankfully / touch-wood) without a crash...



    switching a live enscape session between two-point/ortho/perspective whilst in a workshared model invokes workset borrowing/ownership conflicts -



    querying the ElementID of the error/warning highlights the 'Data Storage Elements' workset is being used by Enscape in some manner - differently (now) to how (if at all) it did in the past.

    Yes, one can "cancel" the workset prompt, see the camera change in Enscape, and proceed (without placing the request) but before we start to see crashes, or find this becomes even more of a nuisance (on bigger projects with longer sync' times) - and noting the age of the OP, could I ask this be looked at (again) soon-ish please.


    Thanks


    (Enscape 3.1.0.51825 on Revit 2021 21.1.21.45)

    I have today noted something not seen before - and can't quite work out what's amiss, so raising this as a potential bug.


    Specifically, we decorate our loose furniture content with some (.rfa not Enscape) entourage families to spruce scenes up a bit - and help differentiate dining tables from dressing tables, etc when working in plan. Amongst these items, an iconic green glass bottle of a particular Dutch pilsner... only, it's not green when I run Enscape from our "Documentation" model that hosts a series of linked models! If I run Enscape when in the model native, they're green. What's weird, is that all the other materials are fine - and this only (so far) appears to affect said bottle - which is no deeper nested or particularly special in any way to other content like the ramen bowl or chopsticks in shot.


    Any one else ever see the same?


    Whilst the material appearance of some fluff content isn't necessarily a pressing concern - the suggestion this might be an issue with linked models (?) is - as we can't be second guessing the consistency between link and source - and our workflow(s) demand we work with Enscape from the "Documentation" model.


    I welcome your insight. Thanks!

    apologies, I can't recall if I've ever posted this here, or raised an equivalent sr, but attempting to open up a (fairly old, but not ancient) standalone I'm getting this:


    file is from Feb'18 -


    Whilst i appreciate nothing last for ever, and .exe aren't an archival format, this is a concern - we have projects/files we want to revisit that are a lot older than 3 years, clients and authorities who reference submitted media spanning decades and leavers taking .exe for portfolios.


    Accepted, this might be a change at an OS level also, so entirely beyond Enscape's scope, but might I ask (in the name of legacy vs progress) that countermeasures for foresight, or retrospective repair be considered a priority?


    Thanks

    is it just me or are there other jelly or frustrated Revit users out there?

    LOL - I'd be better off committing seppuku than suggest on a public forum 'Ketchup is a better alternative (to Revit) for what I do. So no, no jealousy here whatsover.


    This topic is, and has always been, a case of horses for courses. No one tool is perfect, you pick the one that bests meets your needs.


    Yes, the widely available content available for established visualisation-aimed authoring formats like skp, 3dm & .max mean folk can very readily, and convincingly populate their scenes - and outputs (tend to) look good for it. That's great if that's your game - and that's why platforms that aren't really (truly/singularly) aimed at a modelling/viz. workflow offer an array of export output methods from their native .rvt, .pln or .vwx format.


    Sure, it's not frictionless, (regardless of what A'desk marketing might say/sell about Revit-Max Workflows, or what RhinoInside promises) - but that wasn't the issue specifically raised (though arguably should be) not that I want .skp entourage content anywhere near my production models.

    What I find out for now - is that we actually need to have two models, one "real" model, and a very simple model for lightning analysis

    Sadly the "rules of thumb" for analysis still rule - and despite huge leaps in computational power, most software in this space (at least certainly for AECO) is still firmly rooted in "it'll prove enough" thinking - with huge tolerances allowed for calcs.


    This is why/where qualitative appraisal of light/shade with (more generally detailed) design models is arguably better (for Architects & their clients)

    than quantitative measures taken from rudimentary solid forms in an analysis workflow (for compliance auditors and box tickers).


    The problem with the former is that it's fairly easy to cook the books; upping saturation, using area lights, moving the sun, relocating projects to the equator... but of course, if you start doing (some or all of) that you're misrepresenting the (possible) truth - which is a commercial/proffesional risk only you can weigh. Whereas the problem with the latter is that it offers no "feels" and distorts reality by working with simplified geometry and talks only to metrics.


    In the end both need heavy caveats and disclaimers.