Posts by Pieter

Please cast your votes in our two ongoing feedback polls here and here!

    Ideally, from my perspective, duplicated views would 'inherit' the settings of the original view. So if you duplicate a view that had 80% exposure with a field of view of 45degrees, those settings would be inherited by the new view. But if you make changes to the new view those would not affect the original view.

    I have never found myself wanting to change the exposure of all views equally, or wanting to adjust the field of view of all views equally, so for me this would be enough. If you do want a way to update the settings on many views at a time, you would need to introduce the concept of 'presets' again, but I that happens, I think they should be optional, like how view templates work in Revit: each view has its own settings that can be set individually, but a user can opt to select a preset so those settings get managed from a central preset.

    But such a system sounds a lot more complex for Enscape to build and maintain, so I imagine there would need to be enough users demand to warrant it. I for one can't see myself using it because, as mentioned earlier, we typically need/want to configure things per view anyway.

    This is an older thread but very relevant RE: Duplicate views, select/change preset of multiple views & other QoL features

    In the recent poll as to how much of the visual settings should be in the individual views I chose the 2nd option (partial). If you produce 1 or 2 views from a model I can see the attraction of the 3rd option (full) but I usually knock out 20 or 30 views and I need a consistent look to all of them, if I want a slightly lower/higher exposure I can currently; and with the 2nd option make that change once. With the 3rd option; with the exposure (and other relevant settings) in the views I have to make it for every scene.

    As I understood those mockups the exposure is also included in option 2.

    To be honest, I am surprised that using a consistent settings across many views is working for you. We are also exporting 20 or 30 views, but are finding that each view needs its own settings. One shot faces the windows, another faces away, one is in a room with dimmer lights, one is outside.... these are all requiring at least different exposures in our experience.

    For us, the presets are doing more harm than good. So often a user edits a preset, not realizing that other views will (negatively) be affected by it. To get around that, users are recommended to make a unique preset for each view but it's a tedious job. And sometimes people might forget (for example when duplicating a view).

    These are my suggestions relating to the changes to assets introduced in 3.5. Many of these were posted before in the preview release, but I fear most of it got lost in the last-minute scramble towards the release, so I am reposting them here.

    - It's so unfortunate that tweaking materials is constrained to a color picker and some preloaded alternates. I want to be able to apply my own materials to assets. The only type of assets I have found myself wanting to tweak just the colors of are the vehicles. For every other types of assets where I need to modify the materials, it almost always involves swapping texture maps. Swap fabric to leather. Swap marble to wood. Swap oak to pine. Etc. And I want to be able to pick my own materials, and not be constrained to what Enscape thought suitable to include as options. For me, the 'asset types' is the least interesting feature in terms of asset customization because it doesn't really add anything that wasn't possible before. Rather then having asset types, these assets could have also been published as separate assets. Granted, it would make the library a bit more crowded, but that's it. The asset modifications (like material overrides) is where the real value is IMHO.

    - Users have a hard time figuring out how the change the material or swap the subtype of an already placed asset. Most of my users need fin it. They find it unexpected that they have to make a selection, and then click 'edit' to actually make changes to that element. There are very few programs that work like that. I think it would be far more intuitive that when you only have a single type selected, it would immediately switch to edit mode and skip the whole 'edit selection' panel.

    - To be honest, I can't see the benefit of the 'edit selection' panel. Is the idea what we will select all assets in an entire area and then click on each one to tweak them? Seems like a really odd workflow. I'd rather remove it completely in favor of a more simple workflow.

    - In the "edit selection" panel, there does not seem to be a way to way to see which asset has subtypes. But once you are in the 'edit asset' panel that is very clear. Of course this wouldn't be an issue if you 'edit selection' panel was removed

    - There's no way to see whether any materials have been overridden on the 'edit selection' panel. On the 'edit asset' panel it's very clear, even with a nice implementation when you have assets of the same type selected but with different material overrides. Again, I think the 'edit selection' panel is making things harder than it needs to be. Would be better if it jumped immediately to 'edit asset' panel until you select multiple different types of assets. Again, it would not be an issue is the 'edit selection' panel was removed.

    - In the library inside the enscape render window, we can see an icon for 'material can be modified' after clicking on the thumbnail, but in the standalone library the icon for 'material can be modified' is missing.

    - The red layover on the selected assets makes it hard to accurately select the colors. I find myself having to select a color, exit, evaluate, go back in and readjust, etc. Maybe the red layover goes away in edit material mode in favor of just an outline?

    - Often I want to change the material of an asset immediately after placing it. Right now the workflow for that is awkward: we first need to place it, 'apply changes', select it, click on the selection, and only then we can change the material. It would be nice that with changeable material assets, it immediately jumps to edit mode after placing.

    - In both the standalone library and the library inside enscape, the popup only works after clicking on the thumbnail. I liked the previous behavior better. With the current behavior, finding the right asset is taking a lot longer, as there's often some important information in the popup (description, showing the different subtypes, ...).

    - I think the 1/x label in the topright corner of the thumbnails in the standalone library are distractive. I would hide them for all the assets that have no subtypes (1/1) because in those cases they are adding nothing, and just clutter things up. It would also make the assets that do have variants stand out more.

    In my opinion there's been a lack of focus since 3.0. New features barely get improved, bad bugs stay around for years without getting addressed, features seem to be less aligned to popular user requests...

    Demian Gutberlet any e.t.a. on this? I have multiple teams working towards deadlines atm and they are all struggling with this. I'm not talking about adding an extra 5% to total time spend on visualization but rather double or even triple. This issue has existed since Enscape 3.0 and 3.4.3 (that had a limited scope fix for this) has not resolved it for us. And of course 3.5 also has the same issues.

    What they need to do instead, is move the settings of "Rendering Style", "Camera Projection Mode", "Field of View", "Depth of Field" and "Skybox Rotation" to the same Camera Scene Properties, where you can adjust camera XYZ and Sun position. Those 5 properties have nothing to do in the general menus. They are very specific things that should be connected to Scenes, not presets.

    As far as I'm concerned, exposure should also be per camera/per view. Or at least be able to override it per scene.

    4. To get a bit more technical: With 3.4 we have rebuilt the Sketchup plugin to a large extent so that we have a uniform interface between Renderer+UI and all CAD plugins. In the past, the textures from the Sketchup materials were written to the disk using functions in the Sketchup SDK.

    From 3.4 and onward we do that ourselves for all CADs that use bitmap textures like Sketchup, e.g. Vectorworks. This in turn can contribute to that added delay.

    Does this also apply to Revit? Because we saw a noticeable performance decrease of the material editor since 3.4 in Revit as well. I filed a few bug reports about this but none of them went anywhere (supposedly not reproduceable). But I've read so many accounts of the same problem on this forum, that I'm pretty sure the issue was with whatever changed in 3.4 and not user error. We didn't suddenly start using all 4k textures since 3.4. In fact, if we open the same models in 3.3 or lower, the material editor is noticeable faster.

    I used the feedback button, described my problem. And the answer i got was that i had to downscale all my textures to 2K (i haven't done that). Theres must be an issue with the 3.5.1 because it works perfectly on 3.4.4...

    From my experience, the support people that you reach through the feedback button always assume it's user error. It must be either your driver, your setup, your hardware, your project, ... I have stopped submitted feedback through the feedback button because it's a complete waste of time.

    The support staff on the forum here (like Demian Gutberlet and others) are luckily much better :) . I wish there was a way to direct my logs directly to them and skip the feedback portal altogether.

    Issue 1) Design Options.

    Whenever I set up a 'saved view' in Enscape it somehow links it to whichever Design Option that are active at the moment. Meaning that when I choose a certain Saved View, not only does it change to the Saved View, but also change to whatever Design Option that were active when the view was saved. I can not find any solution to the problem I hope that somebody knows of a consistent work-around.

    This is a Revit thing. If you create a new view while inside a design option (regardless of whether that happens through Enscape or you doing it manually in the Revit interface), it will be assigned to that design option. You can re-assign the view back to the main model by doing the following steps:
    - open the view in Revit

    - in the Revit properties palette, find the "visible in option" parameter

    - set it back to 'none'

    Issue 2) Synchronization.

    Sometimes Enscape is 'understood' as an element by Revit - meaning that when we are two people working simultaneously in the same Revit file AND Enscape it is close to unworkable due to having to constantly having to synchronize. In other words; it is as if, we are two people trying to move the same element (EG. a wall) at the same time. The issue is not as frequent, BUT when it occurs it is a very insisting..

    This is due to a design fault in Enscape. They are aware of the issue (myself and countless other users have reported it), but unfortunately very little action has been taken to resolve it. You can make it a tiny bit better by using version 3.4.4 or later and making sure every user is signed into Enscape using their Enscape account, but it's not going to make a major difference.

    Hopefully your post here will remind the Enscape developers that this Revit worksharing issue thing is a huge pain, and it needs to be fixed ASAP.

    This is yet another demonstration that the current preset system is the opposite of discoverable and intuitive.

    The fact that I have to explain the system to every single new Enscape user we've ever had, tells you all you need to know.

    Does this mean we will or will not be able to change a wood to a marble? You say 'will have more assets with adjustable colors AND materials', but from your second paragraph, I understand it's really only color overrides that we will be able to do?

    Now that 3.5 is out, I guess I can answer my own question. It seems some assets have predefined materials that can be swapped out. For example this chair has a few different types of wood.

    This isn't going to be useful, and in my opinion does not address the root of the 'make asset materials adjustable' feature request. We need to be able to pick ourselves. For example, why can I not pick a different type of wood, like pine? Or why can I not stain it black? These are finishes that actually exist for this particular chair.

    Also, these predefined materials' thumbnails look almost identical. At first I thought I was looking at a bug. The red overlay also makes it impossible to see what the material modifications look like. You need to apply every time you make a change, evaluate, reselect the asset, click on 'edit asset' again and make another modification. Ugh.

    Completely and utterly missed the mark in my opinion.

    The advantage of Duplicate as Generic allows materials, etc. to remain. However, this creates a duplicate material - the user still has to manually move the material assignments to the new generic material. :( On the other hand, if you change the appearance type to generic, all the objects with the material assigment are maintained - but you'll still have to remap textures.

    Hey Phil,

    Not sure I understand. Duplicating the appearance asset as generic does not create a new material, nor does it require the users to reassign material assignments.

    All it does is make a new material asset and assign it to the active material. It's true that the old appearance asset stays behind in the model, but that's also the case for the 'replace asset' workflow you described in post #12.