Posts by snowyweston

    nope spoke too soon, those Block ID: values are internally Rhino based, but exploding one of the asset blocks and reaching to the mesh does give us/me:

    UserData ID: & Plug-in: fields that look promising... but I've (presently) no idea how to get at those...?!


    ...yeah so (as I probably should've expected) this is a bit more involved in Rhino than it is in Revit... I'm certainly not conversant in C# and API to tackle this looks to be leading me down:…ods/user_data_methods.htm

    so I'll have to park this curiosity for now.


    HNY all!

    after what feels like forever I've finally managed to entice some of our Rhino wranglers away from their beloved Vray to play with Enscape. Good news!

    Bad (?) news - their enthusiam for assets (ootb and custom) has led to considerable geometry bloat, stalling both Rhino & Enscape on (fairly) decent machines.

    Disclaimer, I'm not all that au fait with Rhino, so I'm shooting a little in the dark here - but....with Revit we've got around the mesh geometry weight/mess of the enscape assets by using the GUID asset parameter in simple volumetric proxies - and I'm digging around an asset block here in Rhino right now to see if we might do the same... but I can't see where Enscape might be fetching the proxy value (that I'd hope to point our GH peeps at so they can rip them out) - perhaps Enscape-for-Rhino thinks/works different?

    Either way, has nay one any ideas / solutions for approaching the same?


    (further to my email to support)

    Windows Defender has just flagged an .exe (of our making) contains a Trojan:

    the system in question:

    the named trojan appears in Microsoft Answers search returns to be (potentially) a false-flag

    but I'd like to get your assurances please - because this will greatly impair our ability to use, and more importantly share these files with others (which we regularly do) - and would ask what remediation Enscape will undertake to ensure this be countered.

    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"


    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,


    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.


    (Enscape on Revit 2021

    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!