I think, the biggest problem with the cycles hype is that the underlying technologies aren’t understood. Making Cycles render toon-shading or render only silhouettes should technically be possible for a raytracer. After you molest the code that is. But because it’s a raytracer you are asking it to first calculate the scene and then for stylised lighting, throw away half of it’s calculations.
Blender Internal will never have as sophisticated rendering of metals and glass as Cycles has, again because of the underlying technology. But it is much more efficient to use for stylised lighting that the shader we’re talking about specialises in. And, because of the underlying technology, it’s easier to have control over the shapes themselves. BI registers objects as different objects, Cycles doesn’t, which means that in Cycles you can have excelent radiosity and reflections, and BI is excellent for avoiding those.
And then, I’m not an expert on Blender itself, but I think it should be possible to combine the output of both if you need a delicate mix.
Besides, the fact that the devs recently put in a realtime render port for BI shows that they don’t consider BI to be garbage. At most, I think, BI needs it’s UI cleaned up a bit to allow for better switching between the node editor and the side menu.
About the “normals”.
I have read the “Normals control” section in the doc: http://wiki.blender.org/index.php/User:LightBWK
I think there is one point missing: Normals and ramps should be directly usable from a toolbar in the 3D view.
The point of using this technique is speed-up the workflow avoiding ugly lighting problems. So in the 3D View(where we animate) we should have access to those controls.
However there is a problem.
If we have 4 characters in the scene and we are controlling mids, highs, and shadows, then we have 3*4=12 controllers. Each controller will be composed of a Normal sphere and a color ramp. So this will take a loooot of vertical space in the toolbar.
I will try to speak with DÜ about this, maybe we could get back with a propose.
By the way current Normal Nodes need to be improved:
-Current ones don’t allow you to reset the normal vector
-a numeric entry for the vector is needed
-a input slot (vector type) is needed in the left of the node
And the color ramp also needs to be improved (I think):
-numeric entries for each color and the position of the color in the ramp
-a dynamic number of input slots in the node. One per color used in the ramp and maybe a first input slot for indicating the number of slots to introduce.
-alternative color method for doing the ramp. I don’t mean the “constant, linear and so”. I mean about this (HSV,CIE Lab,Lab LCh,etc.): http://www.colorcodehex.com/color-model.html
So from Red to Green maybe we could pass through Blue (I’m guessing).
Don’t think it’s right to group everyone who uses Cycles into the same NRP hating boat. I’d love it if BI was developed into a brilliant tool for NRP. Don’t think there’s much point pushing BI to match the realism of Cycles though. That’s why Cycles was developed, to give more realistic renders. All about the right tool for the right job.
I think the “shadows being too perfect” problem could be partially solved by a keyable “temporary bake” option. When a character moves - for example - his head vertically, the highlights, shadows etc… don’t always change. So, the primary position’s values could be temporarily baked in and then removed later in the animation when needed.
I’m not sure how plausible this idea actually is.
Of course, this method is intended for printers, so there’s no anti-aliasing, which might be an issue for renders. But you could describe hatching patterns this way as well.
Another thing, because a 2d gradient is much more complex than a 1d gradient, it might be an idea to have, next to colour points, mixing points?
These mixing points would be abstractions of multiple colour points, so you could choose to have a sharp transition(the abstracted colour points having a high contrast compared to eachother, low contrast compared to the concrete colour points) or a smooth transition(the abstracted colour points being more like a mixture of the concrete colour points, relatively low contrast to eachother)
So in short, you difine how sharp the transition is at a certain point in a gradient.
It’s a little abstract in text, so I’ll make a mock-up later on, but I think it would simplify editing 2d gradients while keeping it sane to implement.
i dom’t like Cycles and it users base, they think that Cycles is the best and Blender need to stop everithing for it,
Please don’t think this way.
BI and cycles together confuse the whole UI. This has to have an end.
Cycles will be the basic renderer.
Meanwhile, I also use BI, especially under toon shading and freestyle. And I mostly handle it via nodes. Which is the more appropriate way to handle a renderer. A toon renderer, a toon shader, yes. I like this. I wold also love to see more development on BI. After all a pathtracer is irrelevant to such approaches.
I know other people reacted to this, but so will I. This isn’t a free minded approach. Yes, achieving photorealism is a nice feat …for some. But once you work in an environment that ONLY acknowledges photorealism (hint: I work at digicpictures) you start to appreciate simple things…
please have respect for others who don’t go nuts about ultra realism.
thank you
Now this thread is really promising and I too would like to see blender internal develop in some way, stylized rendering has a lot of potential…why not in that direction?!
The current system is easy, but not very flexible. The result you’re showing is basically the only possible result, all the others require ridiculous node setups, and even then there’s still weaknesses.
Xtoon specifically would simplify setting up athmospheric perspective, and allow fairly complex distance effects to be used in animation with relative ease. Amongst others, because the system can actually be implemented more flexibly.
Your words seem a bit contradictory-- If you could code it in less time, why not do it? Then everyone who is using elaborate setups will also benefit from this time saver!
As far as UI goes, just because one does not see how it can fit, does not mean another will not be able be creative enough to make a cohesive interface for it.
The current system is great for those who have spent time figuring out how to best utilize it. That said, there is always room for optimization and improvements. Some of the goals of this adventure are to add features AND optimizations of techniques that are already in use. Essentially a leaner, meaner, NPR machiner!
Here is an example of a principal that I would like to see optimized. Fake AO/Distance Fade (could be called mist).
The example gives a fake darkness based on distance from cam, or you can use for landscape of course. But with all these nodes, (which could use some improvements themselves), the control is all over the place, and very difficult to hand off to another user to actually “USE”.
Here is a Paper on the study of “fake” or real time AO that looks pretty interesting.
I am thinking about workflow. If one could simply “turn on” this AO for instance and then “turn on” Distance Shading (or something named like that), each with simple parameters under them–the features are then clearer and easier to utilize from a user perspective.
Well, since this was discussed with Ton and people like to make elaborate mock-ups for the most mundane feature requests I figured that maybe there’s some information on this out there. Plus, AFAICT, the lighting loop doesn’t do texture lookups so there’d need to be a way to either a) have a Toon Texture that does the 2d texture/color ramp lookups based on z-depth or b) somehow pass the texture + z-depth into the shader so it can do the lookups. Or perhaps c) forget all that and just write it as a stand alone shader node.
The algorithm itself is super simple (also doesn’t hurt that I found some example code), the hard part is shoehorning it into the light/material/texture shading loops.
IDK, maybe I’ll just prototype it as an OSL node and see how far that gets me.
Uncle Entity - Even if you coded and made just the 2d mapping possible, as mundane as it may seem to some, we would welcome it with open arms. The thing is, we are trying to make a large number of advanced or extended shading features, and X toon mapping is just one. In other discussion groups we have many more ideas for an improved overall shading that compliments and extends the current set. If it is a node to start with, that is fine, we can at least have its function in a material to experiment with further instead of basing what we think we need more on theory. Please do code something if you happen to have the time!
You can actually make use of group nodes to hide most of that functionality, that way you have a single node that displays a list of values that’s easy for the user to configure.
Still, that doesn’t mean your work is invalid, it would be good to see this additional NPR shading in BI when you consider the fact that you can’t easily do it in BI’s node system (which is a bit more limited than the one for Cycles).
Even better, this shader could eventually become part of a true legacy-based node system for BI where all of the materials can be built from scratch without touching the old material UI. So you’d have…
Cycles - Physically based material building with various options to cheat the physics if needed.
BI - Legacy-based material building that could be akin to renderman ect… with nodes.
