[Bf-committers] Camera biggest problem-solution proposal

[Crs Mrn]

Hi. In Blender, the camera has a zoom limit. As you zoom, the pan and zoom
speed is lower, until you realise that you can't zoom or pan anymore. I
have a proposal on how to solve this: in Unity terms- a raycast.
   So, the camera emmits a raycast, that hits a surface. If the lenght of
the raycast is smaller, the zoom and pan speed is automaticly lower. If the
raycast is longer, the reverse. The raycast could not be just a straight
line, it could be some sort of cone, so, if an object is very far away, it
would be easier to hit it.
   I think this would very well solve the problem in which camera gets
stuck, without resetting the view. The raycast could also be limited to
current selected object.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Without internet (again...)

[Bastien Montagne]

Hi Guys,

 

Just to say you I'm without phone nor electricity again since the storm 
yesterday, have no idea how much time it will take... Will try to keep working 
meanwhile, on projects I do not need too much online docs/presence.

 

Cheers,

Bastien
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Camera biggest problem-solution proposal

[Campbell Barton]

Theres a user preference that does something similar to this, see:
Interface -> View manipulation -> Auto Depth

On Sat, Feb 15, 2014 at 9:30 PM, Crs Mrn  wrote:
> Hi. In Blender, the camera has a zoom limit. As you zoom, the pan and zoom
> speed is lower, until you realise that you can't zoom or pan anymore. I
> have a proposal on how to solve this: in Unity terms- a raycast.
>So, the camera emmits a raycast, that hits a surface. If the lenght of
> the raycast is smaller, the zoom and pan speed is automaticly lower. If the
> raycast is longer, the reverse. The raycast could not be just a straight
> line, it could be some sort of cone, so, if an object is very far away, it
> would be easier to hit it.
>I think this would very well solve the problem in which camera gets
> stuck, without resetting the view. The raycast could also be limited to
> current selected object.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Camera biggest problem-solution proposal

[Campbell Barton]

Posted too soon, heres a more comprehensive answer on ways to deal
with this problem:
http://blender.stackexchange.com/a/651/55

On Sun, Feb 16, 2014 at 12:08 AM, Campbell Barton  wrote:
> Theres a user preference that does something similar to this, see:
> Interface -> View manipulation -> Auto Depth
>
> On Sat, Feb 15, 2014 at 9:30 PM, Crs Mrn  wrote:
>> Hi. In Blender, the camera has a zoom limit. As you zoom, the pan and zoom
>> speed is lower, until you realise that you can't zoom or pan anymore. I
>> have a proposal on how to solve this: in Unity terms- a raycast.
>>So, the camera emmits a raycast, that hits a surface. If the lenght of
>> the raycast is smaller, the zoom and pan speed is automaticly lower. If the
>> raycast is longer, the reverse. The raycast could not be just a straight
>> line, it could be some sort of cone, so, if an object is very far away, it
>> would be easier to hit it.
>>I think this would very well solve the problem in which camera gets
>> stuck, without resetting the view. The raycast could also be limited to
>> current selected object.
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
>
>
> --
> - Campbell



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Modernizing Video Sequencer Editor UI

[Paulo José Amaro]

Hi!

It's my first time here in Blender Mail List. I'm Paulo Jose, from Brazil,
and I want to share with you some ideas and suggestions about the Video
Sequencer Editor's user interface.

I'm being a Blender user for many years and the main functionality I use is
the VSE. Along the years, I used many tools, from VirtualDub to Adobe
Premiere. Blender is by far the most complete and powerful open source
software to work with, its flexibility is the keyword here. But there are
some areas of VSE that still can be improved.

Taking advantage of the new Tabs feature which is being implemented in
Blender UI and the current moving to reorganizing things in a better way, I
put my efforts to study how to improve Blender's VSE UI.

In the past days I prepared a little Demo of a modernized UI to VSE, made
with HTML+CSS+JS to simulate the Blender UI and some of its behavior. It's
not a "lets throw everything away", but most like "lets move these options
to here, those to there". The Demo includes a step by step guide to every
change, explaining my motivation about them, so I don't get longer in this
mail.

You can access it here: Blender Sequencer Video Editor -
Demo

The changes are restrict to Properties Panel. You can compare it with the
current UI by clicking on "How was this screen" button. There are some few
new features, but most of them are already in another parts of Blender and
they are not out of scope.

I would like very much to know your opinion. And I'll keep to work on this
based on your feedback. My intent is to try to modernize VSE, starting by
the Properties Panel, then going to menus and so on.

I'm not a developer, but I put myself available to help with design tasks
and maybe coding too if needed. I'm experienced with using Inkscape, coding
with Python and a little of C. I just need some guidance.

I'm sorry for any misspelling, English is not my main language, but I love
to learn! I hope to get familiar with this mail listing and actively
participate of it. :-D

See you soon!

-- 
*Paulo José O. Amaro*
*Estudante na UFSJ-MG-Brazil. Blogueiro na CasaTwain.com*
*Freelancer* em artes gráficas, edição de vídeo, modelagem 3D, interfaces
web, CSS3, HTML5, Javascript, Wordpress e padrões web.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Proposed Noise Modifier

[Patrice Gmail]

Hello,  I have submitted a patch for a proposed "noise modifier". Hope 
it gets some (positive) feedback !   And a question regarding deform vs 
non-deform modifier is included at the end.   Many thanks.

Here's what it does:

The "Noise Modifier" will make it possible to add some randomness into 
mesh objects, duplicated objects and arrays of objects.

It may be used in one of three modes, or scopes.

In vertex mode, each individual vertex will be shifted by a random 
amount, somewhere between zero and the set maximum. The probability that 
a given vertex is altered can be defined, and the scope of the modifier 
can be limited to a vertex group, with vertex weight acting as a 
multiplier to the translation.

In whole mesh mode, the mesh is transformed as a whole, while it's 
origin remains. Transformation may be a combination of translation, 
rotation and scaling. This is mostly useful when duplicating objects, 
either with Shift-D or Alt-D. However, for each object to have it's own 
random transformation, the "Use ID as seed" checkbox must be used.

Finally, the loose parts mode is used mostly with arrays of objects. 
Indeed, this appears to be the only way one can add randomness into 
arrays, due to the way the modifier stack operates. Each loose part, 
i.e. set of vertices connected by edges, will be transformed as a whole.

I do have one area where I would like the advice of experienced 
developpers, that is whether to make it a deform or a non-deform 
modifier. In theory, it is deform only, meaning vertices are just moved 
around, never created, and neither are edges and faces. But deform-only 
modifiers receive as input an array of vertex coordinates, not the 
actual BMVert objects. For Vertex mode and Whole Mesh Mode, I could do 
with a deform-only modifier, which is probably a lighter modifier in 
terms of memory usage. But for loose parts mode, I need to identify 
loose parts by walking the mesh through BMW_CONNECTED_VERTEX, which I 
did not manage to do with deform-only. So I switched to non-deform 
modifier. Don't know exactly how much of an issue this is.

Other than this, the only features that are not included at this point 
is rotation and scaling in loose parts mode. It will require finding the 
bounding box center for each loose part.


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposed Noise Modifier

[metalliandy]

+1
This is something I have been waiting for in Blender for a very long 
time. Currently if you want to add noise to a mesh you need to use 
displacement and a texture. Even if it only reduces this step it would 
be well worth it because the displacement modifier is really slow.

Can't wait to test this out.

  :)

-Andy

On 15/02/2014 21:01, Patrice Gmail wrote:
> Hello,  I have submitted a patch for a proposed "noise modifier". Hope
> it gets some (positive) feedback !   And a question regarding deform vs
> non-deform modifier is included at the end.   Many thanks.
>
> Here's what it does:
>
> The "Noise Modifier" will make it possible to add some randomness into
> mesh objects, duplicated objects and arrays of objects.
>
> It may be used in one of three modes, or scopes.
>
> In vertex mode, each individual vertex will be shifted by a random
> amount, somewhere between zero and the set maximum. The probability that
> a given vertex is altered can be defined, and the scope of the modifier
> can be limited to a vertex group, with vertex weight acting as a
> multiplier to the translation.
>
> In whole mesh mode, the mesh is transformed as a whole, while it's
> origin remains. Transformation may be a combination of translation,
> rotation and scaling. This is mostly useful when duplicating objects,
> either with Shift-D or Alt-D. However, for each object to have it's own
> random transformation, the "Use ID as seed" checkbox must be used.
>
> Finally, the loose parts mode is used mostly with arrays of objects.
> Indeed, this appears to be the only way one can add randomness into
> arrays, due to the way the modifier stack operates. Each loose part,
> i.e. set of vertices connected by edges, will be transformed as a whole.
>
> I do have one area where I would like the advice of experienced
> developpers, that is whether to make it a deform or a non-deform
> modifier. In theory, it is deform only, meaning vertices are just moved
> around, never created, and neither are edges and faces. But deform-only
> modifiers receive as input an array of vertex coordinates, not the
> actual BMVert objects. For Vertex mode and Whole Mesh Mode, I could do
> with a deform-only modifier, which is probably a lighter modifier in
> terms of memory usage. But for loose parts mode, I need to identify
> loose parts by walking the mesh through BMW_CONNECTED_VERTEX, which I
> did not manage to do with deform-only. So I switched to non-deform
> modifier. Don't know exactly how much of an issue this is.
>
> Other than this, the only features that are not included at this point
> is rotation and scaling in loose parts mode. It will require finding the
> bounding box center for each loose part.
>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposed Noise Modifier

[Paulo José Amaro]

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@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposed Noise Modifier

[Campbell Barton]

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  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@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposed Noise Modifier

[metalliandy]

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.

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

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.

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.

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.

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  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@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
>

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposed Noise Modifier

[Campbell Barton]

On Sun, Feb 16, 2014 at 12:48 PM, metalliandy
 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 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.

> 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).

> 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

> 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.

> 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  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@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell
___
Bf-committers mailing list
Bf-comm

Re: [Bf-committers] Proposed Noise Modifier

[Dan McGrath]

Campbell,

Also seems like blender has some limit that wont let it play animation
> above 60fps...   should also see why this is :S


Could your video card/monitor refresh be capping this if it were set to
60Hz?


Dan
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers