I am sure they are making great progress as well, and have done a great job on the plugin overall. I am only point out that they are obviously not interested in implementing a simple material solution for Sketchup. To anyone who is currently holding their breath waiting for a usable material system for Sketchup, don't expect it to be done anytime soon.
Simon Weinberger ...Enscape already has a material system for Sketchup which you guys developed (Tags/keywords within material names)
Several people have taken their time on this forum to suggest ways to leverage that functionality for more advanced material editing in Sketchup, but apparently these are not being developed.
Here's another idea for how to do keywords..... Multiple keywords with a percent attached at the end.
MaterialName Tran55 Refl75 Emis19
An expanded tag based method would have the added benefit of being usable regardless of the host program and could be used in conjunction with a UI based method. This would allow you to deploy a basically functional plugin to new host programs quicker, and eventually make it seamless with their material system.
So many simple solutions are possible, but I think the only path that is being considered for Sketchup is the Full Material System that keeps being mentioned... which obviously takes significant time. Hearing that such basic functionality for Sketchup is "on the radar" when coding time is being devoted to other plugin's material systems is not reassuring.
Solo ... be careful with the emissive materials in animation... they seem to experience random "pops" in intensity during movement, so just make sure you test before going that route if that type of error is unacceptable. I attempted to use for faking storefront illumination and it did not go well
could lead to pretty bad results if used wrong .
That can be said about Enscape as it is now or any tool really....
I am concerned that my description may have made it seem more complicated than it is.
The final material editor could look "exactly" like your current settings controls (sliders for settings). The xml files never need to be seen/edited by any user, and are exactly like what your current settings UI produces. Seems about as dead simple as it gets.
Thank you for passing it along.
I would like to be able to define custom keywords for materials. Below is an idea for a material system that would do that. I believe this would work well with sketchup or any other package and is based on your current UI and code.
In this system we would be able to define material "keywords" just like we currently define rendering "settings". Each time we adjust material settings and click "save as new keyword" enscape creates an xml file with that name in a directory "materials". Any new xml files in that directory would make a new "keyword" available to Enscape just as the settings files do now.
You could include the standard keywords that you provide as xml files in the materials directory. If we make changes to the default definitions, and click "save", or edit those xml files directly, we would override the default definitions.
What is nice about this approach is that it would allow for organic growth from what is going on now. You could implement at first without any material UI... just provide the functionality to have enscape look for xml files in the "materials" directory. Doing this would give you time to develop a robust/simple UI for the material editor, while still providing users with the means to create great imagery with your product. In the end, having the ability to edit materials both via UI or a text based workflow would be great for flexibility / productivity and would set your product apart from the competition.
Below is an example of an xml structure similar to your existing settings file that could work.
<!-- Advanced Settings / Maps / Etc -->
I agree that it would be ideal to be able to save the "start and stop" positions for animated segments. I do have a suggestion for how that could be implemented easily.
As it is now, we can save duration, interpolation, etc to the render settings file. All that would need to be added for this additional feature to be implemented, would be to also save the start and stop position in the settings/xml file. This way each animated scene could be saved as a separate settings file and then rerendered exactly as revision are made to the model.
As a bonus, if a subsequent feature would allow a batch rendering of multiple "setting files" in sequence, we would be all set for a fairly automated production pipeline.
In sketchup, it would be very helpful to be able to specify a segment of an animation path. Such as a beginning frame number and an ending frame number (any reproducible method would be fine)
This is useful both for fixing a portion of an animation and for debugging glitches. I have a specific frame in a 10 second animation path that has a rendering glitch. Currently I have to rerender the entire segment each time i make an adjustment to see if I have fixed it.
The ideal would be to also allow saving to a sequence of images as then we could just replace those frames that were an issue.
Just noticed that Skybox data within a setting file seems to remain even after the checkbox is turned off. It would be good to flush that data when unchecking the Skybox checkmark. If not possible, please allow us to change the location for the settings files so they can be moved off the system drive to allow for storage management of system drives
Considering that HDRs are likely going to be a large source of data duplication for Enscape, allowing external referencing for that data would be appreciated.
What do you mean by roll out settings? Not sure when this would be applicable?
Here are some benefits for directly editing the xml files...
1. Backup. I have already screwed up a setting more than once by clicking 'save' instead of 'save as'.
2. Precise input. Call me ocd, but I would like to be able to set my duration for an animation to exactly 10 seconds and currently this is not very convenient with the slider.
3. Repeatability. If I want to make sure that two presets are using the exact same settings, except for duration for example, I can copy and paste all at once.
4. Speed. I can create 10 presets with very specific variations quickly... I can change one settings among 30 presets quickly.
5. etc, etc.
Basically, once I learned the location of your xml settings it occurred to me that you already have the "expert mode" I was requesting in another post. I was hoping to explore that a bit and report back my findings when I ran into this snaffu. I do have a workaround by using a different text editor with a higher size limit on the text file, but editing that huge file is not convenient. Would be ideal if those files could also be referenced to a location outside the xml file.
I was attempting to directly edit the setting files and ran into a problem with settings that use custom HDRs. Those xml files are huge and are locking up my text editor. Can those xml files just reference the external file instead?
Totally get that you guys have obviously gone over this at length. I am hoping to make sure that a possible path of least resistance toward better material adjustments is not overlooked as unacceptable to users.
I believe toward that goal it would be helpful to break down what material adjustments we consider essential and what minimum interface that would be acceptable.
Essential would be basic adjustments to reflection, specularity, transparency, ior. These are essential because right now there are certain scenes which are simply not usable without them. They are also essential because +90% of materials make use and benefit from these settings.
Next would be additional maps such as Bump, Normal, Specular, etc. These are lower in my opinion because a much smaller percent of users even take advantage of thes. Also for most materials in a typical archviz scene they are not required to make a good image.
As it relates to interface, the naming convention does pose issues with naming conflicts. Another possible solution with even more potential would be an external xml file. The xml approach could rely on creating each material entry with the name of one material in our scene. Within that entry we add all the parameters needed. You guys would provide us with the template we need to follow for the xml.
Assuming you can make this type of system adjust in realtime (enscape refreshes the settings upon save of the xml file) this could actually be far more productive than requiring setting be input within the sketchup interface. For example we could simply copy and paste entire material setups, quickly swap out material / filenames, swap out material versions just by replacing renaming the xml file, etc, etc.
To make it approachable for newbies, you could implement all your prebuilt material such as copper, plastic, etc within the xml file, and users could use this as a jumping off point in beginning their adjustments.
Also, if going a route like this would indeed be faster for development, it does not need to be looked at as the only solution... if you implemented something like this prior to, or even alongside an integrated material editor I believe many users would find it useful.
For an example of how two approaches would be useful..... you mention preferring to have textures embedded in a file. I am of the opposite mindset. This leads to bloat when saving incrementally and needing to update multiple files if a texture changes. It would be ideal to be able to choose either method.
While I love the idea of a super easy, quick and intuitive material system, there is a finite time to code such a thing. I would be more than happy with the ability to hack together something based on the tools that sketchup does allow.
Since enscape is pulling material and texture data directly from the sketchup scene, we could embed multiple sub-materials containing the maps we are looking to use, such as brick, brick-bump, brick-normal, brick-displacement, brick-reflection, brick-glossiness, each as a separate material. If Enscape finds one of the sub-materials provided, it would use these to add these additional parameters to the master material it builds. Would probably be best to choose a very unique identifier for the naming structure.
A sub-material's name can also indicate the strength of whatever map or parameter we are supplying. For example, the name"brick-bump-25"would mean 25% strength bump. If we want to supply only a value, we create a material with a name such as "brick-reflection-25", or "brick-glossiness-33"
The other cool thing about breaking it down like this is it could theoretically give Sketchup/Enscape the ability to do separate scaling for each texture . Not sure if Enscape can handled this info, but this method would provide it. For example, "brick-glossiness-33" material could have a texture with a size of 10' x 10', whereas the main "brick" material texture might be sized at 5'x5'. There are many times when the ability to add a different sized submap can help to disguise tiling.
Thank you very much for the heads up on the ground texture files. That is helping already.
I do have a couple more items to suggest if an 'expert mode' is developed.
-Ambient Occlusion Radius
-Ambient Occlusion Strength
Exactly The settings below are where I feel the interface is limiting. Being about to type in a number (or path to file in the last item) would be much more flexible.
General > Quality
Capture > Duration
Capture > Compression Quality
Capture > Panorama Resolution
Capture > FPS
Capture > Noise
Image > Sharpness (Bring back please, some of us are post processing images and video and would like flexibility with sharpening)
Image > Color Temperature
Atmosphere > Sun
Atmosphere > Texture (let us specify a path to an image... this seems to affect the color of 'bounced' light and it would be great to be able to tweak this)
I would like more control than the sliders can provide. One way to do this without making the default install intimidating for new users is an "Expert Mode", or even an expert build. Ideally this would allow direct control over the variables being set and the possibility to go even higher. I would be fine with this being provided similar to the preview versions (ie. use at your own risk) The benefit to Enscape is that we are very motivated to see how far we can push the renderer under a variety of conditions. If you let us do that experimentation for you, everyone wins.
I have noticed that changing the groundplane to black for interiors can eliminate strange glows like this.
If I may offer another perspective... many users want to see higher quality and would be happy to wait longer for rendered frames (I certainly would) I do not think the answer is to stop pushing the limits but rather to give more control to the users to customize the output to their needs. I think it would be wonderful if the plugin could run in different "modes" similar to how vray has simple/advanced/expert, etc. This way the default install would remain simple and "newbie proof" while the more advanced users could either choose to push the quality even higher, or throttle it even lower, than what a simple interface can provide for.
I would like to be able to save animations as image sequences, such as png, tga, tif, exr. When doing video editing it is not good to edit from mp4s due to recompression. We are also able to do much better post processing with clean frames as opposed to compressed mp4s.