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.

    Ok, I think I have to apologize...

    I just did some extensive testing and as far as I can tell Enscape does indeed look for folders in the root folder where the Rhino file is placed.

    Was that added at some point?
    Is this documented somewhere?

    best

    Andreas

    rant on/


    This is another desperate try to bring some attention to this issue:



    It is 2024, 3 years have passed without any reaction from the Enscape team.


    Here is the problem in a nutshell again:


    We need an option to be able to collaborate with other enscape operators / clients who are not on the same local network.


    For us the main problem here is, that textures used by Enscape materials in a scene are not incorporated in the Rhino file.

    Therefore if a client wants to open an Rhino / Enscape file, the materials are broken.


    I already completely gave up the hope that we will get a halfway professional asset management system, like many other SW has.


    However the least thing you guys could do would be to incorporate a standard, relative path from the root folder where the Rhino file is located e.g. "/textures"

    If that is too hard to do give us at least an absolute path like "C:\Program Files\Enscape\textures" !


    This way we would at least be able to put all used textures there and tell the other person to do the same.


    Of course this is a rather futile approach in times where everybody is working cloud based, but it would be better than having what we have now (nothing!)


    I really hope that this post will somehow reach someone with the background to get the importance of this,

    if Enscape has the aspiration to be more than a semi professional engine used by individual users or groups on the same network.


    rant off/


    Andreas

    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 ...

    Quote

    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.

    Quote

    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 !


    Andreas