[Bf-committers] BGE Shadows proposal and request for branch (Daniel Stokes)

[Josiah Lane]

That sounds like a great proposal to me, Daniel. I'd also like to see a
couple of fixes - one for orthographic shadows (I can show you the minimal
work I've done on that, unless variance shadow maps do this. Or you could
help me out if you don't want to take it on yourself) and a fix to allow
shadows on transparent objects.

Currently, transparent objects don't cast shadows, which would be fine,
except that Mitchell added an awesome function that allows users to toggle
which materials cast shadows or not, so having shadow casting capabilities
on transparent objects would be a good feature to add (since you can turn
them off if you want).

Anyway, I really like this proposal, as I personally use the BGE almost
every time I use Blender. :)

On Sun, Nov 27, 2011 at 3:00 AM, <bf-committers-request at blender.org> wrote:

> Send Bf-committers mailing list submissions to
>        bf-committers at blender.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.blender.org/mailman/listinfo/bf-committers
> or, via email, send a message with subject or body 'help' to
>        bf-committers-request at blender.org
>
> You can reach the person managing the list at
>        bf-committers-owner at blender.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bf-committers digest..."
>
> Today's Topics:
>
>   1. Re: Patch submitted: Equirectangular projection for       sky
>      texture (David)
>   2. requesting reversion of 41550 despite downsides (Bassam Kurdali)
>   3. Re: requesting reversion of 41550 despite downsides
>      (Dalai Felinto)
>   4. Re: requesting reversion of 41550 despite downsides
>      (Daniel Salazar - 3Developer.com)
>   5. BGE Shadows proposal and request for branch (Daniel Stokes)
>   6. Re: New Alembic support branch (Muhamad Faizol Abd. Halim)
>   7. Proposal to exclude tool settings from Global/Mesh        Undo
>      (Dima Glibitsky)
>
>
> ---------- Forwarded message ----------
> From: David <erwin94 at gmx.net>
> To: bf-blender developers <bf-committers at blender.org>
> Date: Sat, 26 Nov 2011 17:36:06 +0100
> Subject: Re: [Bf-committers] Patch submitted: Equirectangular projection
> for sky texture
> On Jul 26, 2011, at 8:27 PM, Perry Parks wrote:
>
> > Hello!  I just wanted to let everyone know that I've just submitted a
> patch
> > which allows projecting equirectangular images (360 by 180 degree
> panorama)
> > as a sky texture.
> >
> > This should be useful to those using Image-Based Lighting since this
> > projection will map to a whole sphere rather than just a hemisphere (as
> the
> > "Sphere" option does).  It also results in much less distortion than
> using
> > angular maps.
> >
> > Patch is here:
> >
> http://projects.blender.org/tracker/index.php?func=detail&aid=28094&group_id=9&atid=127
>
> Hi all,
>
> this really simple, but also really useful patch has been sitting
> in the tracker for quite some time now.
>
> If anybody with knowledge in that area of code could take a look at that,
> it would be greatly appreciated,
>
> thanks, David.
>
>
>
>
> ---------- Forwarded message ----------
> From: Bassam Kurdali <bassam at urchn.org>
> To: bf-blender developers <bf-committers at blender.org>
> Date: Sat, 26 Nov 2011 19:02:25 -0500
> Subject: [Bf-committers] requesting reversion of 41550 despite downsides
> Hi all,
>
>
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=41550
> removes 'partially working' functionality from blender. And breaks
> stnndard workflow for facial rigging. In the past even though this
> feature had problems, It was still used by many to create symetrical
> shapes; some points about this:
>
> -after mirror modifier has been applied
> -symmetric; vertex groups will be later used as masks for left and right
> side.
> -working on only one half of the shape is no good, you need to see the
> total symmetric one, and use the vertex groups to blend, otherwise, you
> get bad blends of left and right.
> -working point by point really, really kills when doing shapekeys.
> Rigging already takes too long.
>
> this feature/workflow is present in almost any animation application.
> Simply removing it from blender is, well, a bit a extreme in my opinion.
>
> usually if you avoided crossing the mirror line with the proportional
> circle you were pretty safe; weird things only happened close to the
> line, at which point we turned it off. This was better than what we have
> now: not having it all.
>
> Can we have it back? pretty please? I know custom builds are possible,
> but... if we want remove partially buggy features from blender, we'd end
> up removing most of the program ;) - we have transform / offsets that
> break in many 'corner cases' , drivers that don't update (due to missing
> dependency graph fixes), python bugs, etc. The reaction isn't to remove
> transform/drivers/python from blender - oh, and please, don't take that
> as a suggestion ;)
>
> cheers
> Bassam
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Dalai Felinto <dfelinto at gmail.com>
> To: bassam at urchn.org, bf-blender developers <bf-committers at blender.org>
> Date: Sat, 26 Nov 2011 16:10:09 -0800
> Subject: Re: [Bf-committers] requesting reversion of 41550 despite
> downsides
> I will second that. Not only because of the functionality (I don't remember
> when I last used it) but more because of the attitude.
> Sure we all want a bug free blender. But if we follow this line of thought
> so many things in Blender wouldn't be there.
>
> As a quick example, how many people have been using Cycles from day one for
> 'top quality' commercial projects? A lot, really a lot. Enough to make us
> proud of our quirks and tohupuu-like features.
>
> Maybe it's time to bring tohupuu back?
>
> Kind regards,
> Dalai
>
>
> 2011/11/26 Bassam Kurdali <bassam at urchn.org>
>
> > Hi all,
> >
> >
> >
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=41550
> > removes 'partially working' functionality from blender. And breaks
> > stnndard workflow for facial rigging. In the past even though this
> > feature had problems, It was still used by many to create symetrical
> > shapes; some points about this:
> >
> > -after mirror modifier has been applied
> > -symmetric; vertex groups will be later used as masks for left and right
> > side.
> > -working on only one half of the shape is no good, you need to see the
> > total symmetric one, and use the vertex groups to blend, otherwise, you
> > get bad blends of left and right.
> > -working point by point really, really kills when doing shapekeys.
> > Rigging already takes too long.
> >
> > this feature/workflow is present in almost any animation application.
> > Simply removing it from blender is, well, a bit a extreme in my opinion.
> >
> > usually if you avoided crossing the mirror line with the proportional
> > circle you were pretty safe; weird things only happened close to the
> > line, at which point we turned it off. This was better than what we have
> > now: not having it all.
> >
> > Can we have it back? pretty please? I know custom builds are possible,
> > but... if we want remove partially buggy features from blender, we'd end
> > up removing most of the program ;) - we have transform / offsets that
> > break in many 'corner cases' , drivers that don't update (due to missing
> > dependency graph fixes), python bugs, etc. The reaction isn't to remove
> > transform/drivers/python from blender - oh, and please, don't take that
> > as a suggestion ;)
> >
> > cheers
> > Bassam
> >
> >
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> ---------- Forwarded message ----------
> From: "Daniel Salazar - 3Developer.com" <zanqdo at gmail.com>
> To: bf-blender developers <bf-committers at blender.org>
> Date: Sat, 26 Nov 2011 19:58:38 -0600
> Subject: Re: [Bf-committers] requesting reversion of 41550 despite
> downsides
> I agree, brought this into attention a few days ago and was told
> gently to piss off
>
> Daniel Salazar
> 3Developer.com
>
>
>
> On Sat, Nov 26, 2011 at 6:10 PM, Dalai Felinto <dfelinto at gmail.com> wrote:
> > I will second that. Not only because of the functionality (I don't
> remember
> > when I last used it) but more because of the attitude.
> > Sure we all want a bug free blender. But if we follow this line of
> thought
> > so many things in Blender wouldn't be there.
> >
> > As a quick example, how many people have been using Cycles from day one
> for
> > 'top quality' commercial projects? A lot, really a lot. Enough to make us
> > proud of our quirks and tohupuu-like features.
> >
> > Maybe it's time to bring tohupuu back?
> >
> > Kind regards,
> > Dalai
> >
> >
> > 2011/11/26 Bassam Kurdali <bassam at urchn.org>
> >
> >> Hi all,
> >>
> >>
> >>
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=41550
> >> removes 'partially working' functionality from blender. And breaks
> >> stnndard workflow for facial rigging. In the past even though this
> >> feature had problems, It was still used by many to create symetrical
> >> shapes; some points about this:
> >>
> >> -after mirror modifier has been applied
> >> -symmetric; vertex groups will be later used as masks for left and right
> >> side.
> >> -working on only one half of the shape is no good, you need to see the
> >> total symmetric one, and use the vertex groups to blend, otherwise, you
> >> get bad blends of left and right.
> >> -working point by point really, really kills when doing shapekeys.
> >> Rigging already takes too long.
> >>
> >> this feature/workflow is present in almost any animation application.
> >> Simply removing it from blender is, well, a bit a extreme in my opinion.
> >>
> >> usually if you avoided crossing the mirror line with the proportional
> >> circle you were pretty safe; weird things only happened close to the
> >> line, at which point we turned it off. This was better than what we have
> >> now: not having it all.
> >>
> >> Can we have it back? pretty please? I know custom builds are possible,
> >> but... if we want remove partially buggy features from blender, we'd end
> >> up removing most of the program ;) - we have transform / offsets that
> >> break in many 'corner cases' , drivers that don't update (due to missing
> >> dependency graph fixes), python bugs, etc. The reaction isn't to remove
> >> transform/drivers/python from blender - oh, and please, don't take that
> >> as a suggestion ;)
> >>
> >> cheers
> >> Bassam
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
> >
>
>
>
> ---------- Forwarded message ----------
> From: Daniel Stokes <kupomail at gmail.com>
> To: bf-blender developers <bf-committers at blender.org>
> Date: Sat, 26 Nov 2011 20:23:18 -0800
> Subject: [Bf-committers] BGE Shadows proposal and request for branch
> Greetings,
>
> I am seeking approval to start a branch called bge_harmony (or ge_harmony
> since I see a few branches omitting the b). The goal of this branch will be
> to improve the Blender Game Engine's light and shadow rendering. This will
> be done in multiple phases to better segment and manage the changes. The
> first phase will be to improve shadows as outlined in the proposal found
> at: http://wiki.blender.org/index.php/User:Kupoman/Harmony_Phase1.
>
> Comments on the above proposal would be greatly appreciated.
>
> Regards,
> Daniel Stokes
>
>
>
> ---------- Forwarded message ----------
> From: "Muhamad Faizol Abd. Halim" <faizol.blender at gmail.com>
> To: bf-blender developers <bf-committers at blender.org>
> Date: Sun, 27 Nov 2011 16:34:18 +0800
> Subject: Re: [Bf-committers] New Alembic support branch
> Hi,
>
>  is there any update info on the Alembic support in Blender? Any
> information on how to get involved?
>
>  Thanks.
>
> On Wed, Oct 19, 2011 at 5:18 AM, Michael Fox <mfoxdogg at gmail.com> wrote:
>
> > I have to say this is very impressive, thank you so much for starting to
> > work on this, alembic *IS* a very important file type, and is indeed
> > very compact and efficient, if you are going to do a new modifier,
> > please make it invisable in the list and only appear when you import
> > something, and have its settings in the modifier (if any) also i don't
> > think pydrivers are supported yet
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> ---------- Forwarded message ----------
> From: Dima Glibitsky <dima.glib at gmail.com>
> To: bf-committers at blender.org
> Date: Sun, 27 Nov 2011 11:22:12 +0200
> Subject: [Bf-committers] Proposal to exclude tool settings from
> Global/Mesh Undo
> In most of the cases, changes to ToolSettings push undo stack, which
> has the following impact on workflow:
>
> 1) To undo/redo meaningful changes to scene contents, user often has
> to go through a number of steps that don't change anything in scene
> ("meaningless" steps from the user's point of view). In such cases,
> the side-effect of changing tool settings on the way is usually
> undesirable and even hindering.
> 2) Another bad side-effect is that any change to tool settings makes
> it impossible to redo currently undone actions.
>
> In short, users are focused on content manipulation, so
> non-content-related history pushes usually just get in the way and
> unnecessarily pollute undo history.
>
> I suggest that in this concern Blender should behave similarly to
> other applications (e.g. GIMP), where each undo history step is
> related to the actual modification of content.
>
> 3) On the other hand, sometimes it is convenient to have a history of
> some (e.g. brush) settings. To be more specific, these are colors and
> slider-regulated properties, such as Weight, Radius, Strength, Jitter,
> and so on (because it takes more effort to set them precisely).
> However, even in this case they should have a separate history -- of
> the "recently used" type, like Colors history in MyPaint.
>
> Actually, there are already precedents of non-undoable/redoable tool
> settings. Besides the 3D cursor (though it's not in ToolSettings, it's
> still separate for each scene), they include:
> - ToolSettings.use_grease_pencil_settings
> - ToolSettings.edge_path_mode
> - ToolSettings.edge_path_live_unwrap
> - ToolSettings.normal_size
> Even though they push undo stack, they do not change on undo/redo.
> Maybe there are others as well, I didn't check each of them.
>
>
> So, summing up, the proposal is the following:
> - Changes to ToolSettings shouldn't be recorded in Global/Mesh Undo
> history, and shouldn't change on Undo/Redo. This may be as well
> generalized to other settings that don't modify the content (e.g.
> display settings, like Mesh.show_all_edges or
> Mesh.show_extra_face_area).
> - Introduce "recently used" option for Color & slider-regulated
> properties. For example, there could be a submenu with recent values
> available when right-clicking on the slider/color.
>
>
> P.S.
> I have also noticed that some Mesh parameters don't change on Undo/Redo
> too:
> - Mesh.use_mirror_x
> - Mesh.use_mirror_topology
> - Settings in Mesh Display panel
> However, use_mirror_x and use_mirror_topology are undoable/redoable in
> Weight Paint mode (perhaps there is a bug?). As for Mesh Display
> settings, I think it would be logical to make them not push undo stack
> ;-)
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
>