Hi guys, I like the idea behind flairs but it can be very slow to start up if I have texures on the model, and it would be great if it was possible to ignore textures even though they are visible in the rendered mode that the flair is put on top. To get an untextured view I either have to make a new display mode that ignores textures or I have to turn off the texture in the material.
Also I really don’t like the idea that flairs are separate setting that I have to turn off when I go back to shaded. That means going to the menu twice. So I would prefer if the flair was linked to the display mode rather than to the viewport.
Getting a realtime “penguin” like mode is great though, so please shout out if anything is unclear or you want more inputs.
A common approach is to look for discontinuities in the textures that the render pipeline generates for the scene such as the depth texture, normals texture and color texture.
During the edge-detection pass, these textures are sampled and discontinuities are detected using the edge detection operators mentioned earlier. The resulting edge that is drawn can be caused by any discontinuity that was found in one of the 3 buffers. With this technique, the outline gets applied to all the objects that write to these buffers and so you have less control over the outlines on a per-object basis. In the image below, edge contributions by depth/normals/color are represented by the color red/green/blue respectively.
Allowing discontinuities to be detected from different sources makes for a more robust outlining system. In the debug image above you can see that while some edges would be detected by all three discontinuity sources, a lot of them only get picked up from a contribution of a specific discontinuity source. Each discontinuity source can be given a different weight and different thresholds can be used for each of them, allowing you to control the visual of the outline.
The FLR shaders do quite a bit, however, most of it is not exposed in the UI [yet] (on purpose)… We did not want to inundate users with complicated UI, confusing settings, and just an overall frustrating experience right out of the gate… So we’ve come up with simple (but effective) examples that demonstrate specific types of styles/effects, and provide minimal control over them.
The amount of “control” will most likely change/evolve over time…we’ll see.
Ya, that’s probably not going to happen… We could probably disable Flair on a display mode change… It used to do that at one point, but got disabled when it was decided that “any” display mode should work. I can look into adding an option somewhere.
That being said… You shouldn’t be seeing textures in something like a Shaded mode (that would be bug and I think Wim has filed it)… There’s also a new “By Material” setting for “Display Color” in the Object Properties panel… If you select everything, and set it to “By Material”, then your Shaded mode will now “try” to use the rendering material’s Diffuse value… I say “try” because there are still issues with PBR materials, since “Diffuse” can come from any number of places…still working on a solution for that.
Lastly, if you have a GPU that supports “binary shader caching” (which most do on Windows), then any initial delay you see the first time you use a Flair, is the shader(s) being compiled/linked…but that should only happen once per Rhino installation… from there on out, setting a Flair that’s been set before should be almost instant (as far as shader loading is concerned)… the complexity of the scene will determine the overall framerate. Also, if the framerates can’t keep up with what Flair is doing, things are supposed to drop into a more graceful degradation mode, which consists of only “normals edges”, and should be very fast (regardless of GPU) during navigation. If you’re not seeing that, then there’s a bug, so please file it with an example… The exception here is if you’ve set the view FPS to some really low value… If you want to see how things are supposed to act, set the FPS to something really high (like 50)…that should force the degradation on most models.
@Holo, given some of the work I’ve seen you do… you might like the “Da Vinci” style… The defaults don’t really do the style justice… You need to provide a “background canvas” to the style to get its full potential…
This uses a simple “parchment” texture for the canvas…
For this to be really useful for designers it would be great if this was one setting panel where both displaymode and flair could be added at the same time. Come to think of it, a panel would be great for all display modes too, so we don’t need to pull down the viewport tab too much. AND have this saved together with the document.
Yeah, I know this is reaching too far from what I understood from your posts, but for my, and I dare say many designers and architects, this would be great to use in layouts, but then it must be possible to hand the file over to a colleague on a different machine and get the same result there. (This applies to all display modes IMO, I really wish Rhino would operate in a manner where modified display modes were stored in the file)
Thanks for listening though, really appreciate that, and I look forward following the development down the line, this has great potential!
In the end, we may need to open up more of the edge settings to control specific edging going on with specific layers… and by “layers” I don’t mean Rhino Layers… I mean the individual datasets used to produce edging information (see the images in my previous post). It just gets complicated (and confusing for most), along with the UI that would/will accompany/encompass all of it…but I do hear you, and I do understand where you’re coming from.
I’ll experiment with trees and things like leaves… please provide as many examples as you can when you can. I realize that large scenes (i.e. entire structures and buildings) combined with small things (i.e. an individual leaf on a tree) that take up a very, very small percentage of the overall scene, is going to be difficult to get “clean”…but it is something I’m working towards.
I think this is bigger than it sounds… Display modes are “personal preferences” not necessarily “visualizations of your model”. You might use them for that, but most users do not…they use them to get things looking and acting the way “they want”… Users who actually modify display modes, most likely modify all of the display modes, and then add a few of their own… That means Rhino would have to store every single display mode plus custom modes in the file… And then, even if that happened, upon opening the file, you’d now have all of your display modes plus all of the ones in the file…and there’s 100% chance there will be overlap and ambiguities…and I’m pretty sure most users will not want your display modes stepping on their display modes… I can keep going with other problems and issues…but you get the idea. I’m not saying something like this can’t be done, I’m only saying that it’s a lot bigger than I think you think it is, given the current implementation and current user base. This will require some pretty big changes (or something entirely new altogether), Flair is sort of going in that direction…
That being said, all Flair settings can be exported to a .FLR file (All settings, including any images and textures used), and easily transported to other systems (both Mac and Windows)… so it’s possible that those settings might actually find their way into the 3dm file, but probably not in the first release. I do know that we’ll probably need to track specific changes to specific styles, which themselves could then be referenced by a 3dm file…but things aren’t quite that far along yet.
As always, thanks for all the great feedback!