[Bf-committers] Proposed Noise Modifier

[metalliandy]

Sorry for the late reply. Replies in-line. :)
On 16/02/2014 04:36, Campbell Barton wrote:
> On Sun, Feb 16, 2014 at 12:48 PM, metalliandy
> <metalliandy666 at googlemail.com> wrote:
>> Campbell,
>>
>> I can understand why you don't want to bloat Blender by adding a bunch
>> of redundant or unnecessary modifiers, but I really don't think that
>> situation is true in this case.
> Whatever the outcome, its worth investigating shortcomings in existing
> features before assuming we need to add new ones.
I agree 100%
>> I just want to be clear that I have only ever use the
>> displacement/texture workflow out of necessity because no other solution
>> exists in Blender and wouldn't use it again if the dedicated modifier
>> was available.
>> The problem is that the displacement modifier is extremely slow to
>> update results to the point where it is probably the slowest modifier in
>> Blender that I personally use. I would rather sculpt the noise in ZBrush
>> much of the time because tweaking values is such an ordeal. :P
> You assume displace modifier is slow-by-design and a new modifier will
> be faster, but I see no reasoning for that.
It's not that I assume that the displacement modifier is slow by design, 
it's just slow when using it with the textures in the workflow that I 
mentioned before.
I should say that I am working with an average of at least 1-1.5m quads 
when using it and it is pretty painful to use at those sort of 
polycounts, which are needed unfortunatly in order to get a good enough 
resolution for baking etc.
>> In any case a displacement modifier isn't a good place to have a
>> dedicated noise function, which should be reserved for actual
>> displacement from height maps etc. This is what people expect from
>> displacement to start with and using it to generate something as simple
>> as random noise is a super hacky and inefficient workflow which we
>> should really be trying to move away from as Blender continues to mature
>> into an application that is taken seriously in production. People won't
>> be looking in the displacement modifier for a noise function because its
>> not the logical place for it to be.
> If its noisy displacement its not so out of place, but at this point I
> can't follow exactly what you're after (not being a zbrush user).
I can see where you are coming from but I meant that it's not the first 
place that people are going to look for such functionality. For the most 
part outside of the Blender this functionality is normally referred to 
as add noise or indeed is a noise modifier in Max, where as displacement 
is normally used only for the purposes of displacing a mesh with a baked 
heightmap to a lower poly mesh. I hope you can see my point that it is 
inefficient to have to add the modifier, then add a texture, then go 
between the texture panel and the modifier satck in order to get the 
look you want. With a dedicated noise modifier it will save all of those 
issues so even if the actual displacement of the mesh isn't faster, the 
workflow will be.
Normally the reason I would want to add noise to a mesh is to give the 
surface some randomisation and to add things like rust instead of 
sculpting it.
>> Rather than adding new features (and more code) to the already slow
>> displacement modifier, wouldn't it be much more efficient and more
>> obvious to the user to have a dedicated noise modifier for the purposes
>> of generating noise on a mesh? Ofc, the displacement modifier can always
>> be rewritten to make it faster at a later date in order to increase its
>> performance too.
> Displacement is totally simple - loop over verts and offset them, the
> fact you find this slow makes me think its blenders textures which are
> the bottleneck since theres really not much else being calculated. If
> thats the case adding a different method wont be slow.
>
> Would be good if you could upload an example thats slow.
>
> Own test on subdiv cube (bounding box draw mode):
> 98306 verts
>
> **with faces**
> - no texture: 23fps
> - clouds texture: 14fps
> - simple deform modifier: 28fps
>
> **without faces/edges** (just verts)
> - no texture: 60fps
> - clouds texture: 34fps
> - simple deform modifier: 60fps
>
> Looks like speed is split between texture lookups and normal calculation.
>
> Also seems like blender has some limit that wont let it play animation
> above 60fps...   should also see why this is :S

Just get any mesh that is 1-1.5m quads or so (with subd modifier), add a 
texture and then change the values in the disp modifier. For me a cube 
takes around 5 seconds to update the settings. More complicated geometry 
is much slower than this
>> It's much more preferable to have 5 dedicated modifiers that are
>> specifically designed for one job each (and do them well) than 1
>> modifier that does 5 jobs poorly.
> First I'd like to understand whats missing from what we have, then
> figure out how to expose to the user.
Yea, no worries there.
>> Cheers,
>>
>> -Andy
>>
>> On 16/02/2014 00:55, Campbell Barton wrote:
>>> If displace is slow and setting up textures is a hassle, maybe its
>>> better if we have a way to select between different displacement
>>> methods [Constant | Noise | Texture].
>>>
>>> Prefer not to add new modifiers just because existing ones could be
>>> implemented better.
>>>
>>> Also, best link to the patch, otherwise everyone needs to search for it:
>>> https://developer.blender.org/D320
>>>
>>> Added initial review.
>>>
>>> On Sun, Feb 16, 2014 at 11:16 AM, Paulo José Amaro <pauloup at gmail.com> wrote:
>>>> Patrick, this is one of the most wanted features I ever seen. Also It's
>>>> amazing to see how well you did the UI for this modifier.
>>>>
>>>> My suggestion is to include another noise options from F-Curve's Noise
>>>> Modifier, like "phase", "scale" and "depth". I'm not sure if they are
>>>> applicable to a mesh modifier, but I hope they are just the same options
>>>> applied to space domain, not time.
>>>>
>>>> Also it would be interesting to provide a seed interpolation option. This
>>>> could be done using the average between top and floor functions of the seed
>>>> value. Lets say seed "1.6" is 40% seed "1" and 60% seed "2". So it would be
>>>> possible to animate smoothly from a seed to another.
>>>>
>>>> Thank you for doing this! I hope I can test this patch... it will be my
>>>> first attempt with patches
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
>