Posts by HNY

Please note: Should you experience issues with Enscape or your subscription, and in case of any urgent inquiries/questions (e.g. regarding our upcoming licensing changes) please reach out to our dedicated support team via the Help Center or Support button as detailed here.

    Tearch One can always hope. I'm well aware of the policy/intentions of Enscape which is why i suggest it as a global setting to go into "advanced mode". Most likely inside the EnscapeOpenGeneralSettingsCommand with a tick box. And probably a "reset to normal" button inside Enscape to save all the less advanced users of the hassle of understanding.

    If I were doing the roadmap for the program I would be concerned with the potential quality of native rendering inside the different CAD programs. If a realtime viewport mode existed with decent light inside e.g. Rhino, why would i bother to open (and pay) Enscape? Assets would be the initial answer, but that too could be replaced by native stuff or other "asset plugins" with the added benefit of being platform free.

    The workaround works fine (as you say), and for all new projects this is "an acceptable limitation" for a render engine. The issue is mostly when quickly re-renderingen old project whit small changes or cases where the change to native material changes the surface behavior in other Rhino viewport-modes.


    Many of the remainding bugs is things i personally have lived with through 3.5 as well, because i choose to endure limitations to my work method to get some features i have missed when using enscape. But for most of our users they are unwilling to accept the slower speed and the lack of ability to run the program while modelling, and they are less aware of the subtle (but IMO important) changes to light and detailing.


    If i should come with a proposal for a development track that would reignite my positive view on Enscape it would be the introduction of tiers in "difficulty/complexity" levels to the engine:

    A "light" mode - somewhere in between the current quality and the browser-version, but crusially able to run on integrated graphics like Xe or Radeon Graphics (You could sell more licenses if the regular laptop guys could open models at meetings without a gamer laptop). This should be done by only using cubemapping reflections or screenspace - no ray tracing and maybe no parallax displacement. Limitation to shadows from spotlight etc.

    A "normal" mode - The same as today - maybe capped raytracing to make the experience equal om most desktops with at least a RTX2060 card.

    A "Advanced" mode - This could enable you to open up for features that for now is kept from us to protect the average user: AO maps, Specular maps, Individual UV-channels for different maps, Ability to add a dirt-map in a new channel (multiplied to diffuse/gloss), maybe even make the dirt with a tickbox to choose self-dirt or affected by other. A slider for dirt amount. A rounding effect (like round corner in D5 and similar in Lumion, using a normalmap to fake a fillet on a corner on a material). Maybe a tickbox to enable translucency to all native Enscape nature (would destroy most computers, so only available in advanced where the user may me knowledgebe enough to limit the scene and have a large GPU). An option to give a density map to grass height (same workflow needed as with the multiple mapping channels - could be used for snow/sand-displacement too). I think this could be done quite elegantly in your current UI. - let me know if you want to hire me for a visual proposal ;)

    We will release a new service pack for 4.0 today I would ask you to retry that version and provide a list. I am sorry that you are struggling with the product, the forum might not be the most ideal way of that information reaching us though. If you provide a list I assure you we will take a look.

    Hi Christian,


    We tried the latest servicepack and the reflection issue from the other thread seems to be resolved. Remaining known issues from our one user test would be:


    1. Rhino viewport still slow when enscape is running. (Workaround : don't run enscape while working, only rendering)
    2. PNG's does not have transparent background anymore, but white. (Workaround possible by making it into a native enscape material)
    3. Object will move/appear simultaneously/live when live-updates are turned on, which affects performance negatively. As an example, when using the copy command in rhino; The object you are copying disappears in the enscape viewport, the "new" copied object will float around in the enscape viewport until you place it in rhino. The original object will reappear when you are done using the copy command. (I guess there could be more "funny" stuff happening if we tested more commands, like array, loft, flow...). (Workaround : don't run enscape while working, only rendering)
    4. No enscape toolbar showing (Workaround: You need to create a custom toolbar to access the Enscape buttons).
    5. Render results are different every time you render. We tried to render same view, with the same settings, 7 times, a we got 7 different results in terms of shadows and reflections. We tried another one where, the first render was the best result in terms of reflections, we rendered 4 more times which were similar, but worse in terms of glass reflection, sadly. This was not a problem with 3.4.4, and it is a bit "scary" when you think about postproduction and updating renders. (Workaround: none known yet - a risk we have to live with).
    6. The Rhino viewport will change/sync, when selecting a saved view in the enscape viewport. (Workaround: None, just live with it).

    The problems are limited to annoyances, and i do believe we are slowly treading outside the "unusable state". We will try and upgrade more users and hope it will not lead to too much lost work and efficiency.

    The latest internal test we did in an attemt to be "upgrade ready" showed the errors explained by "SOS" in this thread:

    SOS

    The key things which render the program unusable in its current state is:

    Transparency errors

    Reflection errors

    Bugging the speed of Rhino down

    The key things which some of our users refuse to live with (which was tried under the Enscape 3.5 period) is:

    Constant live translation of objects moving (in copy, move, array commands etc.)


    Unfortunately i cannot provide a full list of points this time around, simply because we stopped testing the feasibility of the program after we identified enough issues to warrant the extended wait. Hence we may have missed further problems.

    Can the Enscape team provide us with any sort of reassurance that they are working towards a deadline of fixing the currently know areas where Enscape 4 is worse than Enscape 3.4.4?

    We find ourselves in the peculiar situation where we have bought Rhino 8 but cannot install it because Enscape 4.0 is still too faulty. More urgent is the fact that we are growing and need more Rhino licenses, but haven't even activated our R8 licenses, so this gives a management headache.

    To be very direct, we are looking at a crossroad and are weighing our options. The push from management means we will have to commit to a direction soon (getting a working Enscape in the new version of rhino or change software). Our current internal tipping point will be in two weeks (1. may) where we will retest the latest version of Enscape 4. If it is still not usable we will start transitioning all our Revit users to twinmotion (giving its already included in our revit license) and transition all our designers/rhino-users to D5 + native rhino viewport "rendering". A new public statement from Enscape indicating commitment to fixing the software would give me leverage to maybe extend this, but the people i report to are not happy with the history of excuses.


    I dread the added internal education we will need to make a transition, so i really hope there is a future which includes Enscape. I can see the glimmer of hopes in the latest tests. Good shadow and highlight control, so the render quality is going up, but the usability has unfortunately not followed.

    You might consider upgrading while there is still a $200 discount available. (or at least buying the licenses, even if you don't install it - you can run both 7 and 8 concurrently.) You know support is going to come eventually, and McNeel is practically the only software that still charges per release instead of a subscription model. It's not likely to get any cheaper. Unless you want to dig in with Rhino7 and an outdated Enscape until Rhino 9 comes out.

    You are right, and we probably will. Buying before the discount runs out (tomorrow?) was actually why i revisited this forum. And i do agree that McNeel is "one of the good guys" with their licensing strategy. It was wrong of me to use R8 as an example of poorly distributed workforce. My frustration on that subject is more fueled by AutoDesk, Microsoft and Adobe ATM.

    What you are experiencing now is, to put it in an analogy, asking us to change the tires on an old bus that served us well but is being decommissioned while we are in the process of finishing the new and shiny bus that will come with the fresh tires from the get go. Time spent on the old will cut into time spent on the new and comes with diminished returns as work has to be duplicated.

    I find this example quite amusing. In it, what Enscape suggests is not to change the tires on your bus. Instead, stay away from work for months until a new, fancier bus can pick you up. There's no need to go to work until you can do so in a better bus. That would be a waste of the bus company's money.


    I share the appreciation for D5 here(personally), but we are too deeply entrenched(as a company). Habit keeps us sticking with Enscape, so ironically, Enscape is currently costing McNeel money. We have no intention of purchasing Rhino 8 before the two programs are thoroughly tested and integrated with each other. (R8 was a fairly disappointing upgrade option anyway, so maybe it's just a trend? Spend all the money on salespeople in the SaaS business and less on creating actually useful stuff.)

    To anyone in this thread who inquired about edge softening specifically in Enscape for Rhino, this should now be fully working actually with Rhino 7 and Enscape 3.5:

    Great stuff - I look forward to playing with it when the initial bugs makes 3.5 an option. Unfortunately we are currently hit by the "converting material from version 3 to version 4" loop when working in our models.


    But very thrilled with the quality of life updates in the latest update. Huge points for the option to work with the material editor window open!

    I would probably use the video tool more too if it had easier management of multiple clips with easy individual settings. Ideally skipping the cutting in premiere afterwards.


    On the subject: It not a "tool" im looking for. When you draw a simple cube in rhino it will be a certain type/category of geometry. Most likelya cube would be an extrusion. More complex shapes will be difined as a polysurface. There are many ways to create shapes. Common for all is that rhino needs to make a mesh version in the background for you to see it in the viewport at all (except for wireframe mode). It is this "rendermesh" that I wish enscape would just use. Because if they did, other tools would be part of enscape "for free". The "applyedgesoftening" command which started this thread is a simple tool which can add a fillet or chamfer to an object, but retains the original logic, making alterations possible down the line. I normally use this for concrete with chamfers, couches with fillets or just normal wooden objects to give edges specular highligts. (if you have used 3dsMax or blender, this is how many modifiers keeps stuff non-destructive)

    But for some reason Enscape makes its own translation from polysurface to a set of meshfaces (to my knowledge all GPUs need a set of meshfaces to shade anything). Enscape reads meshes just fine. It just chooses to make its own for the polysurfaces. So what i see in my rhino viewport is not the same geometry as Enscape shows. The reason i refer to it as Rendermesh is because rhino has a command called "extractRenderMesh" which makes the shading its own object.

    (On pricing, you are refering to a single fixed seat price - not really relevant for any studio with multiple employees).

    Tearch I see we individually get influenced by our own perception (naturally). I'm surprised to see your estimate of the video-feature usage, since I know loads of Enscape-users (from work and school before that) but very few who uses the video-side of the software. In our office we have approx. 20 users and only one guy who prefer Enscape for video. I've made lots of videos in Lumion and a few in Enscape, so I do share your view on the video-editor needing an update. I was shocked that I could not make more than one clip in a file (without having to save and load them all the time).

    I do think you may also be misunderstanding which feature I would like to see. Everybody who uses Rhino sees the render-mesh without ever using "a mesh". Its simply how Rhino makes Nurbs and other surfaces visible. I just want Enscape to use the same faces as rhino does, and not make its own translation.

    Regarding priority, I think it has merits to add features which can make the renders better. Its not a convenience-feature - its an aesthetic feature which could improve the core product: renderings.

    Regarding price: I see 72.90€/month for Enscape and Lumion 99.97€/month.

    Tearch I can follow your train of thought, but i still believe its a matter of either underestimating the gain it could have for the quality enscape can give or an overestimation of the complexity to implementet it. If i worked for enscape i would always aim to work on features where you get the most "bang for the buck" in terms of work hours. And i do imagine a reworked video-editor would be months of work, GUI-design and coding as opposed to enabling an alternate geometrypipeline which already exist inside Rhino. Vray is now under the same banner as Enscape, and Vray has always used the Render mesh from Rhino, so the knowledge is there. The code might even exist.

    Regarding Lumion i was surpriced to learn last month that Enscape that enscape and lumion is now very similarly priced. So either you have a great deal on your licenses or i am getting scammed. Actually thats in part why im trying to get the rendermesh-thing into enscape:
    So i wont have to convert back to Lumion. We moved because of Lumions steep pricing earlier.

    HNY ... but Enscape isn't going to implement any kind of mesh support because none of the other three (sorry but vectorworks really doesn't count) software supported by Enscape have native mesh modeling...

    I've yet to understand why using the Rhino rendermesh is anything complex for Enscape. If anything it must be worse to have to translate Nurbs itself. I remember aiding in the development of the Lumion liveLink for Rhino. They succeded very fast in altering what was read when they understood the request.

    Mesh modeling or not, there always has to be a mesh to shade the geometry. If i extract the rendermesh, enscape shows it just fine. They just choose to not use it.

    +1 from me. I have for years avoided Enscape at work because the mathematical sharp edges is such a huge givaway to an unprofessional render. If the effect is hard to implement in the Rhino-Enscape translation, maybe just add a button to swap between current mesh generation and "use Rhino rendermesh". This would solve it for me, and also enable other fancy features such at thickness, displacement and piping.


    Shading-based rounding like what D5 or Lumion does would also solve it partly, but i would prefeer the rendermesh option because the normal-map-based edgesoftning washes out details in bump and wont create ambient occlusion in joints.


    I cant find the subject on the "portal" thing. Can i add it somehow?