Back when Blender Internal added raytracing there probably also were lots of users complaining that the rendertimes are prohibitive using this feateure. It’s just technology, nothing more, software and algorithms evolve. Like any software Blender has to embrace new concepts and evolve or it will stagnate and die.
As far as I know you don’t have to use cycles with global illumination just turn bounces to zero. It pretty fast if you do that even on the CPU. Any render engine BI to Cycles is going to be slow once you start using global illumination.
if they can’t sort out performance yet,it would be nice to have sculpting layers and some kind of posing tool (like transpose in zbrush)
(In the case of a pathtracer) The time for a final frame to converge to acceptable levels may be hours, however the time for a preview will be much faster. When you don’t need to constantly preprocess things like photon maps, irradiance caches (etc) for a single view, you will be able to judge things like lighting mood much quicker. Also, submitting a render to a pathtracer is a fire-and-forget action, you don’t have to worry e.g. about flickering artifacts occuring over frames, or that your quality setting for a particular element wasn’t quite enough, after all. They key insight is that human time is more valuable than computer time, which is why path-tracing gets more-and-more popular these days.
Now, if that isn’t true for your particular use-case, then you should look for other solutions.
On a tangent: Yes, you could re-use previous-frame samples particularly well in the context of a path-tracer. Instead of gathering samples into a single pixel in a single frame, you could just gather samples in a “frameless” fashion, reconstructing particular frames/pixels by averaging samples spread over time. This is an active area of research.
This case falls out of “better and cheaper”. It’s contradictory to compare “better and cheaper” with an era that the same kind of product or service didn’t exist at all (EDIT: I mean, for the average person, not Richie Rich). There should be a continuity in time where in both cases an option of the same kind is available.
That’s not what I mean. You could’ve done (simple) 3d animations on an amiga or whatever, but if your requirement would’ve been SGI-level quality, you couldn’t have done it. In the same sense, if your requirement today is path-tracing, you need to accept the costs.
I’m not going to speculate on what kind of Blender user he envisioned here, but it’s probably not individuals with dual-core processors at home. The fact is: Cycles is faster than Blender Internal at raytracing. Therefore, only if you don’t use a lot of raytracing, Blender Internal is actually faster. In Cycles, everything is raytraced, which is very accurate and simplifies things a lot, but will almost always be significantly slower than rasterization, buffered shadows and environment maps. If you don’t need (or want) raytraced shadows, occlusion, (glossy) reflections, then don’t use Cycles.
Obviously I misunderstood you (again), I thought your “saved money from improved workflow” was about the render cost, not the human-hours cost!
Yes, this is not true for my use-case, as I’m hiring myself for free, so the render cost is -for the time being, far higher than my man-hours! 
Sounds very interesting (for research) and it will probably lead to huge processing savings. Still, this is just one out of hundreds other possible paths for optimization.
BTW, I bet that a zero noise global illumination renderer is possible, even at the first seconds. The noise on cycles alone, indicates a huge area of possible optimizations. I haven’t studied how it works, but it seems that cycles priority is set (by design) to high-precision first, low-noise later, while the priority should be low-noise first and high precision later. That would be ideal for all cases, as you’d get fast results with low noise early on, while the more you would wait the highest precision you wouldl get.
Right now, to get low noise, you have to reach the highest precision first -that’s definitely not necessary. (That was just an idea of the moment, no requirements and no expectations).
OK, since you put Amiga into the equation, this became a valid example!
I can’t turn it off as I need it for some surfaces, but if this is possible per-object via Blender light path node with an analogous speed increase, it will be awesome as BI might not be needed.
That’s not a speculation, that’s what TON said.
Thanks Zalamander, we all know that obviously raytracing is slower than rasterization, my point is not in what is better (personally I use Cycles and I think is very good), but in what is no more developed.
Performance for sculpting is pretty good for what it is…at least with the multirez, though could always be better across the board. It needs some topology improvements (getting rid of those artifacts and odd surface look), new and dynamic brushes with higher detail capabilities, sliders for deformation and masking tools.
Sculpting is such a powerful feature, and few programs manage to do it well. Blender is doing surprisingly well compared to the rest, so it would be great to see it fully realized.
More development in a BI based/style renderer-rasterizer is needed.
To ask a pathtracer for toon like shading is a little ridiculous.
To ask a pathtracer to bake on a UV maps, well, this is difficult and results could be spectacular. I can’t figure out how it will be possible though. Eastern eggs surprises. Cross your fingers.
Performance for sculpting is pretty good for what it is…at least with the multirez, though could always be better across the board. It needs some topology improvements (getting rid of those artifacts and odd surface look), new and dynamic brushes with higher detail capabilities, sliders for deformation and masking tools.
Is good for what it is? at least with the multires?.. You zb lover LOL
Well, one thing needs more development. A re writing from scratch. The multires modifier.
As for the tools, they are very detailed, similar to zbrush or better. Sorry, different approaches coming from two zbrushers. Fair enough.
It is also the wonderful dyntopo. I find much better than sculptris, much better than dynamesh. Because dynamesh just remeshes and this way it tends to smooth things. (I know the parameters alright, still smooths details)
But, dyntopo should be able to work fast on 1-2-3 millions faces. If this could be possible then… blender could be one of the 2-3 best apps for sculpting. Well, it may be already. LOL (from my point of view)
Of course I love Zb, any digital sculptor should. =P The sculpting tools are good but lets be honest, they are not that good, meaning they are basic, functional, but theres quite a bit of room for improvement. With the same alpha and the same mesh resolution, you can get varying degrees of detail between ZB and Blender. This isnt to say blender is bad, in fact quite far from it, but the difference is still big enough. The approaches are not really all that different as the workflow is pretty much the same across the board for sculpting applications.
Theres nothing wrong for wanting Blender’s sculpting capabilities to get better. =) I will gladly admit the sculpting feature is good, but its not something I can say is good enough to the point of not being further developed. Alphas are a big one… see the difference below:
Same mesh with same resolution, same alpha, same brush, fairly equal settings. Big difference.
Sorry, blender is better, at least on this example. Much more accurate to the map.
And to make the example fair enough, bring the blender mesh into zbrush render environment first. Or do the opposite. All this “beauty” this approximated displacement, looks good just because of the cavity effects of zb shader. You should aware of it. Try to render it under a decent pathtracer and we’ll see then. (decent pathtracer, LOL, I mean cycles)
I mean: blender can handle 32 bit exr files for stencil. Zbrush can’t. Use such displ maps for stencil and we’ll see where quality exists.
OK, let’s stop this pointless thing. Pointless as long multires remains problematic. Try something more complicated than a subdivided cube / sphere and see what I mean.
So, we should love zbrush. I own it and I have to love it LOL.
A little out of topic. Trying to construct a flattener brush in zb. Like the one we have in blender. I can’t. Any ideas how to do this? A decent flattener tool please, like the real one in traditional sculpting, like the blender one. Let me explain further. Something to remove/cut clay and flatten the same time. A knife like.
That’s usually just a problem with the brush curve.
Example with slight tweaking:
I’d like to see better defaults, but I’m not actually sure what the most ideal default would be for something like that. I don’t have much Zbrush experience but I don’t recall seeing it’s users needing to fiddle with things like that nearly as much.
Yes, it is, for example using “instant radiosity”. None of these methods are however magic bullets, they all have their own artifacts that can be unacceptable or unpredictable.
I haven’t studied how it works, but it seems that cycles priority is set (by design) to high-precision first, low-noise later, while the priority should be low-noise first and high precision later. That would be ideal for all cases, as you’d get fast results with low noise early on, while the more you would wait the highest precision you wouldl get.
It just doesn’t work that way. I suggest you do study the methods that people have come up with. They all have their drawbacks. People really don’t care about (unnecessary) precision, they care about robustness and reliability. Don’t you think that if there was a method like you describe that we would all be using it? I actually do follow the research and there’s nothing that solves all your problems, just waiting to be implemented.
You didn’t really get the meaning of the sentence - language barrier I guess.
Thanks Zalamander, we all know that obviously raytracing is slower than rasterization, my point is not in what is better (personally I use Cycles and I think is very good), but in what is no more developed.
You said: “I have the impression that this is no more; unless Cycles gets a real optimization to make the rendertimes comparable to BI.”
I say: Cycles is already as fast or faster if you render comparable scenes (using raytraced shadows, glossy reflections, raytraced ambient light).
It’s not really difficult, all you need to do is rasterize your geometry and start your rays (slightly offset) towards these “surface” pixels.
Glad I waited to respond, you added information about displacement sculpting. This has already been done in zbrush and quite well. The whole displacement argument falls flat.
See: http://www.zbrushcentral.com/showthread.php?170297-Artworks-amp-WIP/page12
Additionally, I dont think anyone can rationally state that Blender is a better sculpting program. Blender is unique in that it offers a full 3d package alongside the sculpting, but for pure sculpting its not better. No way, objectively, is it better. I would love for it to be, but its not.
Now for that example you mention, EXRs for stencil work… I cant see how that makes Blender superior for sculpting. I have yet to see it actually be used in a normal workflow. Perhaps you can provide an example?
As for rendering, within cycles or even modo, you still see the difference. I think you are used to having a “make pretty” workflow within cycles to help sell your detailing, but the fact is the topology…the mesh itself needs that detail. For example Game asset creation needs the mesh detail in order to bake maps for use on lower poly meshes. So if you rely purely on something like cycles and nodes to make your mesh look good, you are limiting yourself. This isnt about rendering, its about sculpting and the mesh result.
I did a quick render btw showing you that working in zbrush, doing the same thing to the same mesh results in more detail in a cycles render.
Also to touch on XRG’s comment about the curve…both alphas make use of the same curve within the image below.
The detailing is just not comparable especially via alphas. Also when I mentioned masking tools… If I really wanted to pull that detail on the fly, I could mask by intensity, cavity, color, even AO, then use a slider to push or pull that geo in or out.
As for the remove or cut clay, flatten tool…I am a bit confused at what you are referring to. Are you referring to actually removing geometry or just flattenting/scraping its surface?
Regardless, I know you enjoy and love blender, I do too and thats why I think we can both agree that we want it to get better.
I’m not really seeing what you’re trying to demonstrate in the pictures. I see slight differences I guess, but either result looks adequate enough for sculpting to me. I generally don’t have too much issue in regards to Blender’s sculpt brushes myself.
Totally agree about the masking tools though – cavity masking would be nice for texture painting too. Sculpt layers would be nice to have down the road too.
Zalamander, you don’t think that everything that was to be invented has already been invented, do you?
If not, then there is always a much better solution to an existing problem waiting to be invented, -that’s a rule, no underestimation intented.
And BTW, my view is that tech evolves way slower than it could, there are many areas stalled for decades, from aircraft to 3D, mostly because companies want to make money really fast today, investing on marketing vs research, so revolutionary tech is very rare today. Even in music there is no inspiration -everyone is copying the past. In 3D, we should have abandoned triangles and polygons in general a long time ago -everything should have been already parametric (not with the current industry meaning necessarily). This is the future, and is at least a decade late.
I am demonstrating what information is picked up and applied from the alpha and the level of detail from the sculpt. It is the same alpha on the same mesh. Blender kind of roughly pulls the geometry but the topology is still iffy on the bottom, zbrush on the other hand is able to define the sculpt with more detail, even picking up on the surface detail…theres texture and substance to the surface.
Blender’s current look is bit like Mudbox in that you get this kind of muddy looking effect, which isnt very good for fine detail, but fine for rough shapes. Furthermore, if you try add fine detail or busy alphas, if becomes easy for artifacts and mesh tearing to occur.
sainthaven I have to strongly disagree with performance being “good enough”
I can get “beastly” with my polycount in zbrush and it only requires 4gb of memory.
michalis and I are fortunate to have stupid amounts of ram,a lot of blender users don’t.Rendering it almost useless for hi-res detail in some cases.Though i’m very unfamiliar with the code behind it. (this is why dyntopo is more popular)
And as michalis says its not just about performance,its a lot about the unpredictability of multires,but I think we all agree there.
p.s. sculpting layers are absolutely necessary for hi res detail,when we are taking about production workflow anyway (a.k.a TD’S who want changes fast hehe)
I dont think you understand my posts. I am not disagreeing with you at all. I also have a “stupid amount of ram” and a license for zbrush. In fact I agree that there needs to be improvements even with the multires. The difference is, I dont think it has to stop with the multi-res and the multi-res isnt the sole fix needed.
What is a ‘beastly’ polycount these days anyway?
My current machine is a crappy $500 HP I picked up in an emergency from Office Max, lol. I only have 8gb of RAM and I can get in the 25~30million poly range with Blender and it’s still completely usable. Anything past that and it just crashes though.
Your right,i’m not understanding.What did you mean by “its good enough for what it is” ?
What it is supposed to be,is a sculpting tool capable of hi res detail, which currently doesn’t really preform that well unless you have a lot of ram,which is why I feel it certainly isn’t good enough for what it is.
Dyntopo however,I would say IS good enough for what it is.(which is a quick sculpt/conceptualizing tool) anyway if you say you agree,I guess its pointless continuing the convo lol.
Its viewport performance overall I would like to see improved,i’m not sure what the status of that project is at this point.
xrg: I’m referring to the polycount vs the amount of ram needed for “ideal” performance i.e. no lagging.
this seems to be related to the polycount of the original mesh,before subdivision,which effects the performance.Which,is an issue I haven’t had in zbrush regardless of the basemesh polycount.Anyway theres an entire thread dedicated to that haha.