Posts by v-cube

Reminder: If you encounter any issues with Enscape or your subscription please reach out to our dedicated support team through the Help Center or by using the Feedback button as detailed here.

    just today a client asked me specifically if we could use IES Profiles for an indoor rendering job, I told him that unfortunately this is not possible in a Rhino / Enscape workflow and that we have to use another render engine that supports IES.

    I don't get this, sad ...


    The Enscape texture map is an absolute path. When we share the project with colleagues, in addition to the albedo map, the channel path of other texture maps will be prompted to be lost. Can it automatically recognize the root directory or the maps folder like V-ray?

    This is indeed a very reasonable request since collaborative work is a reality ... left's hope that it will really be addressed by the developers...

    Damian Gutberlet
    As I said I understand that many things that might seem to look easy to do for a user can be very hard to implement as a developer. I have done internal alpha / beta testing for some of the big render engines available for Rhino right now, so I know what I am talking about.

    I assume you are in contact with the guys at McNeel to get to a solution for this problem.

    I am patient, since I do not use Enscape for a lot of commercial stuff (yet...), however I am very interested in its development and experiment a lot with the VR abilities it offers and which IMHO are unparalleled in the industry.

    Apart from its VR capabilities, my plan is to use Enscape for projects with a small turnaround time, that do not justify the use of higher end engines like vray or octane.

    Enscape might become a perfect match here, but of course having a speedy workflow is essential for that.

    Thank you for the feedback Damian, I appreciate that you are keeping contact with the users.


    I'm afraid, most of these things which don't help with usability are due to technical limitations

    I´m afraid but this is not good enough for me, if there are technical limitations in this area, your development team has to overcome these, especially in this case since it is killing our workflow. I know that it is easier said than done, but IMHO it is essential and therefore should not be ignored.

    Chita is saying that it is a very bad workflow in terms of having to open / close the Enscape material all the time !

    Material management / assignment is very awkward to use right now. Since we have the Enscape material editor separated from the Rhino material editor in order be able to access advanced Enscape material features. Unfortunately this leads to very frustrating and time consuming workflows, since :

    1. The Enscape material editor is unable to create a new material

    2. The Enscape material editor is unable to assign materials to objects.

    3. The Enscape material editor has to be closed after you are done making changes to your materials, otherwise no Rhino command / navigation is working.

    let me give you an example by describing a basic task : creating and assigning a new material.

    As already mentioned, the Enscape material editor is unable to create a new material, so you first start with the Rhino material editor. 1. you create and name your material, you select "Enscape" as a material type.

    2. Now you have to switch to the enscape material editor and adjust all material features, after that you have to close the enscape material editor again...

    3. Now you go back to your Rhino material in order to assign it to some layers or objects.

    This going back and forth between both editors, together with the fact that the Enscape material editor cannot be kept open but has to be opened and closed each time is extremely annoying and time consuming.

    In addition to that advanced features of the Rhino 7 material Editor e.g. highlighting the material of a selected object or select object by material are of course not accessible from the Enscape material editor.

    I always thought of the Enscape material editor as a temporary fix, which would give us the possibility to use basic Enscape material properties.

    IMHO the integration of it into the Rhino material editor (like other render engines already have since many years...) is long overdue.

    Quote from Simon Weinberger

    In our opinion it's better to have a synchronous rendering, even if this means to miss out on a few other features.

    I have to say I completely disagree ! Total live sync is nice, but if it stops us from having essential features, than it should be optional.

    Let the user decide if he wants livesync or advanced features and manual updating !


    I am sorry to rewake this old tread, but since the problems are still very much there I think it is probably necessary.

    In my opinion the Render Mesh modifiers trump live sync any day

    I couldn't agree more. If total live sync is sooo important than why not make at least make an option for the user to chose. I don't mind pressing the synchronize buttons from time to time if I could get some features that are obviously problematic to implement otherwise.

    Please do not sacrifice features just for the uncompromised dogma of total live sync.