[Rendering order] z-depth and 3D effects

[Steve Withall]

Esteemed experts,

The recent draft "SVG Rendering Order" specification makes a few 3D
effects easier to achieve. So does the draft "Transforms"
specification. They add to what can be done using filters (drop
shadows and lighting, in particular). But all these effects are
independent of one another. There's no underlying 3D model, so it is
possible merely to *contrive* to make individual objects appear 3D.

Of course SVG is a format for 2D graphics, and should stay that way.
For your consideration I suggest that a 3D model sufficient for SVG
could be achieved by allowing a *z-depth* to be defined for each
element: its distance above (or below) a datum plane. (I avoid
calling it z-height because heights in SVG mean the y dimension.)
This single value would be a sufficient basis for calculating
consistent drop shadows and consistent perspective transforms across
many or all elements.

Alternatively a z-depth could be defined for each z-order value.
That's probably sufficient in some situations, but not in others.

An additional use case I have is displaying multiple SVG canvases
layered one above the other. I want each *canvas* to have a z-depth,
so I can throw well-positioned drop shadows from objects in one
canvas on to objects in canvases below. This can be regarded as the
ability to define the "absolute" (wider world) z-depth of the datum
plane for each canvas.

Finally, is it worth the Working Group making a formal statement of
the extent and limits of SVG's 3D ambitions? (Forgive me if this
exists somewhere that I don't know about.) It could be something
along the lines of treating each element as two dimensional, but
offering ways to make collections of these 2D elements appear as if
they exist in a 3D environment.

Thanks, Steve.

[Doug Schepers-3]

Hi, Steve-

Thanks for the additional use cases.  We know we will have to reconcile
any concept of z-index with 2.5D transformations and occlusion, and I'm
not sure we quite have that covered yet.

Jonathan Watt has volunteered to take on formalizing the z-index topic,
along with its ramifications with the rendering model, and to expand the
proposal he made earlier.  Anthony Grasso will be handling the new
transformation stuff, in conjunction with the CSS transformations.

You're right that we should clarify where we intend to go with this...
we certainly don't intend to make SVG a true 3D language, and we will
try to produce a coherent primer or set of examples for common pseudo-3D
effects that will clarify it to authors (and implementers).

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Steve Withall wrote (on 11/10/09 7:56 PM):

> Esteemed experts,
>
> The recent draft "SVG Rendering Order" specification makes a few 3D
> effects easier to achieve. So does the draft "Transforms" specification.
> They add to what can be done using filters (drop shadows and lighting,
> in particular). But all these effects are independent of one another.
> There's no underlying 3D model, so it is possible merely to *contrive*
> to make individual objects appear 3D.
>
> Of course SVG is a format for 2D graphics, and should stay that way. For
> your consideration I suggest that a 3D model sufficient for SVG could be
> achieved by allowing a *z-depth* to be defined for each element: its
> distance above (or below) a datum plane. (I avoid calling it z-height
> because heights in SVG mean the y dimension.) This single value would be
> a sufficient basis for calculating consistent drop shadows and
> consistent perspective transforms across many or all elements.
>
> Alternatively a z-depth could be defined for each z-order value. That's
> probably sufficient in some situations, but not in others.
>
> An additional use case I have is displaying multiple SVG canvases
> layered one above the other. I want each *canvas* to have a z-depth, so
> I can throw well-positioned drop shadows from objects in one canvas on
> to objects in canvases below. This can be regarded as the ability to
> define the "absolute" (wider world) z-depth of the datum plane for each
> canvas.
>
> Finally, is it worth the Working Group making a formal statement of the
> extent and limits of SVG's 3D ambitions? (Forgive me if this exists
> somewhere that I don't know about.) It could be something along the
> lines of treating each element as two dimensional, but offering ways to
> make collections of these 2D elements appear as if they exist in a 3D
> environment.
>
> Thanks, Steve.
>

[Patrick Dengler]

Doug/Steve,

I'm really liking the information that folks discuss on this alias! Thanks Steve.

In 2004 version of the SVG charter clearly stated that 3D was not a part of the WG direction. The latest version omitted this.  It would be great to see this clarification updated in the SVG charter.

I do agree with you (If I am reading your response correctly).  Retained mode graphics is not ideal for 3d (I was watching my son play a 3d game yesterday and just imagining the millions of objects on that screen at 50 FPS), though pseudo 3d effects make a lot of sense.  3D is more of a "fire and forget" immediate mode model, though there are certainly interesting benefits to layering the two technologies.

Patrick

-----Original Message-----
From: www-svg-request@... [mailto:www-svg-request@...] On Behalf Of Doug Schepers
Sent: Sunday, November 15, 2009 2:31 AM
To: Steve Withall
Cc: www-svg@...
Subject: Re: [Rendering order] z-depth and 3D effects

Hi, Steve-

Thanks for the additional use cases.  We know we will have to reconcile
any concept of z-index with 2.5D transformations and occlusion, and I'm
not sure we quite have that covered yet.

Jonathan Watt has volunteered to take on formalizing the z-index topic,
along with its ramifications with the rendering model, and to expand the
proposal he made earlier.  Anthony Grasso will be handling the new
transformation stuff, in conjunction with the CSS transformations.

You're right that we should clarify where we intend to go with this...
we certainly don't intend to make SVG a true 3D language, and we will
try to produce a coherent primer or set of examples for common pseudo-3D
effects that will clarify it to authors (and implementers).

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Steve Withall wrote (on 11/10/09 7:56 PM):

> Esteemed experts,
>
> The recent draft "SVG Rendering Order" specification makes a few 3D
> effects easier to achieve. So does the draft "Transforms" specification.
> They add to what can be done using filters (drop shadows and lighting,
> in particular). But all these effects are independent of one another.
> There's no underlying 3D model, so it is possible merely to *contrive*
> to make individual objects appear 3D.
>
> Of course SVG is a format for 2D graphics, and should stay that way. For
> your consideration I suggest that a 3D model sufficient for SVG could be
> achieved by allowing a *z-depth* to be defined for each element: its
> distance above (or below) a datum plane. (I avoid calling it z-height
> because heights in SVG mean the y dimension.) This single value would be
> a sufficient basis for calculating consistent drop shadows and
> consistent perspective transforms across many or all elements.
>
> Alternatively a z-depth could be defined for each z-order value. That's
> probably sufficient in some situations, but not in others.
>
> An additional use case I have is displaying multiple SVG canvases
> layered one above the other. I want each *canvas* to have a z-depth, so
> I can throw well-positioned drop shadows from objects in one canvas on
> to objects in canvases below. This can be regarded as the ability to
> define the "absolute" (wider world) z-depth of the datum plane for each
> canvas.
>
> Finally, is it worth the Working Group making a formal statement of the
> extent and limits of SVG's 3D ambitions? (Forgive me if this exists
> somewhere that I don't know about.) It could be something along the
> lines of treating each element as two dimensional, but offering ways to
> make collections of these 2D elements appear as if they exist in a 3D
> environment.
>
> Thanks, Steve.
>

[Jonathan Watt-3]

Hi Steve,

Have you looked at the alternative z-index proposal that I made:

  http://www.w3.org/mid/4AE510F6.6050404@...

It practice it's similar to the "SVG Rendering Order" proposal you refer to, but
more general. Rather than just being able to position sibling elements relative
to each other in the z-axis, you can position elements relative to other
elements in entire element trees.

If this doesn't meet your needs, I'd be very interested to hear about it. A
small concrete example (with code) would also be very useful in that case.

Regards,
Jonathan

On 2009-11-11 1:56 AM, Steve Withall wrote:

> Esteemed experts,
>
> The recent draft "SVG Rendering Order" specification makes a few 3D
> effects easier to achieve. So does the draft "Transforms"
> specification. They add to what can be done using filters (drop
> shadows and lighting, in particular). But all these effects are
> independent of one another. There's no underlying 3D model, so it is
> possible merely to *contrive* to make individual objects appear 3D.
>
> Of course SVG is a format for 2D graphics, and should stay that way.
> For your consideration I suggest that a 3D model sufficient for SVG
> could be achieved by allowing a *z-depth* to be defined for each
> element: its distance above (or below) a datum plane. (I avoid
> calling it z-height because heights in SVG mean the y dimension.)
> This single value would be a sufficient basis for calculating
> consistent drop shadows and consistent perspective transforms across
> many or all elements.
>
> Alternatively a z-depth could be defined for each z-order value.
> That's probably sufficient in some situations, but not in others.
>
> An additional use case I have is displaying multiple SVG canvases
> layered one above the other. I want each *canvas* to have a z-depth,
> so I can throw well-positioned drop shadows from objects in one
> canvas on to objects in canvases below. This can be regarded as the
> ability to define the "absolute" (wider world) z-depth of the datum
> plane for each canvas.
>
> Finally, is it worth the Working Group making a formal statement of
> the extent and limits of SVG's 3D ambitions? (Forgive me if this
> exists somewhere that I don't know about.) It could be something
> along the lines of treating each element as two dimensional, but
> offering ways to make collections of these 2D elements appear as if
> they exist in a 3D environment.
>
> Thanks, Steve.
>
>
>
>

[Steve Withall]

Jonathan,

No, I didn't receive your proposal email, despite getting the rest of
the flurry of related emails on 26 October. Oh well ...

The biggest question on the subject of z is conceptual: should we
regard it as abstract (and solely to enable us to render objects in
the order we want), or should we regard it as a dimension one can
move around in in the same way as the first two (and to use for a
range of exciting other purposes)? (How's that for slanted phrasing!)

Your proposal, Andrew Emmons' and HTML/CSS all fall on the abstract
side of the fence. I am on the dimension side (and claim the support
of the Transforms specification). Here's a simple example for you of
how I see it:

<svg width="100mm" height="100mm">
   <title>z example for Jonathan</title>
   <rect x="5mm"  y="5mm"  z="20mm" width="30mm" height="20mm"
style="stroke:red; fill:yellow"/>
   <rect x="25mm" y="15mm" z="10mm" width="30mm" height="20mm"
style="stroke:red; fill:tan">
     <animate attributeName="z" attributeType="XML" begin="0s"
dur="2s" fill="freeze" to="40mm"/>
   </rect>
   <rect x="45mm" y="25mm" z="30mm" width="30mm" height="20mm"
style="stroke:red; fill:plum"/>
</svg>

What could be easier and more natural than that?  :)

Maybe there are ways of getting the best of both worlds, but for the
moment there is a disconnect. Andrew's proposal could reconcile the
two by using z-positions (co-ordinates in the z dimension) instead of
z-indexes. But your stacking contexts extend the abstraction down
into individual groups (self-contained sub-universes, if you like),
which means reconciling local z-indexes with z-positions isn't possible.

If you want to introduce a range of pseudo-3D effects to SVG,
z-positions would enable them directly (such as the animation in my
example above). Integer z-indexes don't help at all. Andrew's
proposal as it stands could be augmented by a mapping table (perhaps
within the <defs> element) of z-indexes to z-positions, but it'd be
unpleasant and of limited value.

We should also not forget what document authors are likely to find
easiest to write and to understand. They all already deal with x and
y positions in SVG and get around in the three dimensions of the real
world. So I'm sure they'll have no trouble working comfortably with
z-positions (and the Transforms specification expects them to). But
z-indexes are artificial, and stacking contexts even more so. Are you
in danger of allowing considerations of performance and ease of
integration with HTML to come at the expense of usability and
flexibility? Take off your programmer's hat for a minute!

A further issue that might be worth pondering sometime is the effect
of the introduction of z-ordering (however it's achieved) on document
structure. To date, rendering order has dictated document structure.
Control over z-order will give authors a lot more freedom. Will it
let them write better organized (for their purposes), more modular
documents? Or could much more messy documents emerge? Might authors
use z-order much more extensively than they need to, in large SVG
documents, and impose a greater processing burden than expected?
Could lazy authoring tools spit out documents with different
z-indexes on everything? Could this have consequences no one has foreseen yet?

Regards, Steve.


At 17/11/2009 04:33 AM, Jonathan Watt wrote:

>Hi Steve,
>
>Have you looked at the alternative z-index proposal that I made:
>
>   http://www.w3.org/mid/4AE510F6.6050404@...
>
>It practice it's similar to the "SVG Rendering Order" proposal you
>refer to, but
>more general. Rather than just being able to position sibling
>elements relative
>to each other in the z-axis, you can position elements relative to other
>elements in entire element trees.
>
>If this doesn't meet your needs, I'd be very interested to hear about it. A
>small concrete example (with code) would also be very useful in that case.
>
>Regards,
>Jonathan
>
>On 2009-11-11 1:56 AM, Steve Withall wrote:
> > Esteemed experts,
> >
> > The recent draft "SVG Rendering Order" specification makes a few 3D
> > effects easier to achieve. So does the draft "Transforms"
> > specification. They add to what can be done using filters (drop
> > shadows and lighting, in particular). But all these effects are
> > independent of one another. There's no underlying 3D model, so it is
> > possible merely to *contrive* to make individual objects appear 3D.
> >
> > Of course SVG is a format for 2D graphics, and should stay that way.
> > For your consideration I suggest that a 3D model sufficient for SVG
> > could be achieved by allowing a *z-depth* to be defined for each
> > element: its distance above (or below) a datum plane. (I avoid
> > calling it z-height because heights in SVG mean the y dimension.)
> > This single value would be a sufficient basis for calculating
> > consistent drop shadows and consistent perspective transforms across
> > many or all elements.
> >
> > Alternatively a z-depth could be defined for each z-order value.
> > That's probably sufficient in some situations, but not in others.
> >
> > An additional use case I have is displaying multiple SVG canvases
> > layered one above the other. I want each *canvas* to have a z-depth,
> > so I can throw well-positioned drop shadows from objects in one
> > canvas on to objects in canvases below. This can be regarded as the
> > ability to define the "absolute" (wider world) z-depth of the datum
> > plane for each canvas.
> >
> > Finally, is it worth the Working Group making a formal statement of
> > the extent and limits of SVG's 3D ambitions? (Forgive me if this
> > exists somewhere that I don't know about.) It could be something
> > along the lines of treating each element as two dimensional, but
> > offering ways to make collections of these 2D elements appear as if
> > they exist in a 3D environment.
> >
> > Thanks, Steve.
> >
> >
> >
> >

[Dr. Olaf Hoffmann]

Hello,

I think, the main problem with a 'real' z-axis is, that
for 3D-transformed objects there can be a different
z for any fragment of the object.
Therefore if there is more than one object, the
objects can intersect in a complex way.
From a simple 2D-viewer one cannot expect
a proper computation of such intersections without
the help of the authors. From a 3D-viewer one can
expect this.

If SVG2.0-viewers are not expected to be such
advanced 3D-viewers, objects can have only one
z-value to rearrange the rendering order without
solving the problem of intersections.
If this z-information is explicitly given or at least
implicitly known to the viewer for each object,
such a 3D-effects model can be kept simple
(there can be of course different approaches more
or less useful/convenient for authors).

The first step to clarify the intended 3D approach for SVG 2.0
therefore would be to say, whether a shape/object/path
can have more than one z-value or not.
After this decision or clarification one can go into details
how to get any effect at all.

Olaf

[Robert O'Callahan-3]

On Wed, Nov 18, 2009 at 10:33 PM, Steve Withall <steve@...> wrote:

The biggest question on the subject of z is conceptual: should we regard it as abstract (and solely to enable us to render objects in the order we want), or should we regard it as a dimension one can move around in in the same way as the first two (and to use for a range of exciting other purposes)? (How's that for slanted phrasing!)

I think those are really quite different features with very different use-cases and implementation requirements. Explicit 3D lets you do a lot of cool stuff, but as Dr Olaf pointed out, one of the first things you're going to want to do is introduce 3D transforms so that an object can have varying depth, and then you need 3D rendering with z-buffers etc.

On the other hand, some use-cases for reordering 2D layers are not addressed by "true 3D" features. For example, jwatt raised the case where you have an SVG fragment that wants to reorder some of its children within a container, e.g. using CSS z-index,
<svg>
  <g style="z-index: 10">...</g>
  <g>...</g>
  <g>...</g>
</svg>
Suppose you want to copy that fragment into the context of some larger SVG document that contains its own uses of z-index. With CSS you can just set "z-index:0" on the <svg> fragment and you get the results you want. With other proposals, including yours, to avoid layers in the outer document being interleaved with layers in the fragment, you have to renumber the z-values in the fragment and/or the outer document.

Another point that jwatt raised which I'll repeat is that certain effects make no sense if they can be "split" into different layers. E.g.
<g opacity="0.5">
  <g z="0">...</g>
  <g z="10">...</g>
</g>
<g z="5">...</g>
The group opacity model assumes you'll be able to paint the entire contents of the translucent group atomically. But here you can't, so what would the rendering be? Similar problems occur with 'mask' and 'filter'.

CSS z-index solves this with the concept of "stacking contexts" and saying that certain properties other than just 'z-index' can introduce a stacking context. But a concept like that doesn't make much sense if you're using true 3D geometry to do your z-ordering.

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

[Steve Withall]

Olaf,

At 18/11/2009 09:54 PM, Dr. Olaf Hoffmann wrote:
>Hello,
>
>I think, the main problem with a 'real' z-axis is, that
>for 3D-transformed objects there can be a different
>z for any fragment of the object.

That's true for 3D. But we're only talking about 2.5D, so
considerable compromises must be made. IMHO, the first major
compromise is to treat a graphical element as existing at one and
only one point in the z dimension, even when transformed.

>Therefore if there is more than one object, the
>objects can intersect in a complex way.

Treating objects as single z points (flat) prevents them intersecting
in complex ways.

> From a simple 2D-viewer one cannot expect
>a proper computation of such intersections without
>the help of the authors. From a 3D-viewer one can
>expect this.
>
>If SVG2.0-viewers are not expected to be such
>advanced 3D-viewers, objects can have only one
>z-value to rearrange the rendering order without
>solving the problem of intersections.
>If this z-information is explicitly given or at least
>implicitly known to the viewer for each object,
>such a 3D-effects model can be kept simple
>(there can be of course different approaches more
>or less useful/convenient for authors).
>
>The first step to clarify the intended 3D approach for SVG 2.0
>therefore would be to say, whether a shape/object/path
>can have more than one z-value or not.
>After this decision or clarification one can go into details
>how to get any effect at all.

I agree.


>Olaf

Steve.

[Steve Withall]

Robert,

At 19/11/2009 07:17 AM, Robert O'Callahan wrote:

On Wed, Nov 18, 2009 at 10:33 PM, Steve Withall <steve@...> wrote:

The biggest question on the subject of z is conceptual: should we regard it as abstract (and solely to enable us to render objects in the order we want), or should we regard it as a dimension one can move around in in the same way as the first two (and to use for a range of exciting other purposes)? (How's that for slanted phrasing!)

I think those are really quite different features with very different use-cases and implementation requirements. Explicit 3D lets you do a lot of cool stuff, but as Dr Olaf pointed out, one of the first things you're going to want to do is introduce 3D transforms so that an object can have varying depth, and then you need 3D rendering with z-buffers etc.

Taking a few careful steps in that direction doesn't mean going the whole way.

On the other hand, some use-cases for reordering 2D layers are not addressed by "true 3D" features. For example, jwatt raised the case where you have an SVG fragment that wants to reorder some of its children within a container, e.g. using CSS z-index,

But what does 'reorder' its children mean if not move them in the z dimension? In the real world, moving something in front of something else means it's nearer. I haven't encountered anyone for whom this behavior is insufficient, and who needs extra use cases.  :)

It's intrusive and inconsiderate to introduce a feature (changing rendering order) that barges its way into the third dimension, at best doesn't help with 2.5D stuff at all, and at worst wants to claim the third dimension exclusively for itself. (I thought this debate might be fun, but I didn't imagine it would turn into Star Wars!)

<svg>
  <g style="z-index: 10">...</g>
  <g>...</g>
  <g>...</g>
</svg>
Suppose you want to copy that fragment into the context of some larger SVG document that contains its own uses of z-index. With CSS you can just set "z-index:0" on the <svg> fragment and you get the results you want. With other proposals, including yours, to avoid layers in the outer document being interleaved with layers in the fragment, you have to renumber the z-values in the fragment and/or the outer document.

I grant that the z values across multiple documents used together need to be compatible. But you can say that about x and y values too. And I would argue that authors are more likely to understand and mesh multiple sets of z co-ordinates than multiple sets of z-indexes.

Another point that jwatt raised which I'll repeat is that certain effects make no sense if they can be "split" into different layers. E.g.
<g opacity="0.5">
  <g z="0">...</g>
  <g z="10">...</g>
</g>
<g z="5">...</g>
The group opacity model assumes you'll be able to paint the entire contents of the translucent group atomically. But here you can't, so what would the rendering be? Similar problems occur with 'mask' and 'filter'.

It *is* possible to apply all the styling of the enclosing groups, even if parts are rendered in different orders, as in your example. (I'm grappling with an implementation of this at the moment. I've made a couple of false starts to improve efficiency, but I think I'm getting there.)

CSS z-index solves this with the concept of "stacking contexts" and saying that certain properties other than just 'z-index' can introduce a stacking context. But a concept like that doesn't make much sense if you're using true 3D geometry to do your z-ordering.

I agree with you there.

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

Steve.

[Robert O'Callahan-3]

On Thu, Nov 19, 2009 at 9:54 PM, Steve Withall <steve@...> wrote:

At 19/11/2009 07:17 AM, Robert O'Callahan wrote:

On Wed, Nov 18, 2009 at 10:33 PM, Steve Withall <steve@...> wrote:

The biggest question on the subject of z is conceptual: should we regard it as abstract (and solely to enable us to render objects in the order we want), or should we regard it as a dimension one can move around in in the same way as the first two (and to use for a range of exciting other purposes)? (How's that for slanted phrasing!)

I think those are really quite different features with very different use-cases and implementation requirements. Explicit 3D lets you do a lot of cool stuff, but as Dr Olaf pointed out, one of the first things you're going to want to do is introduce 3D transforms so that an object can have varying depth, and then you need 3D rendering with z-buffers etc.

Taking a few careful steps in that direction doesn't mean going the whole way.

If you don't introduce transforms, then there is little practical difference between z="3mm" and "z-index:3", except that the units are unnecessary and therefore confusing.

On the other hand, some use-cases for reordering 2D layers are not addressed by "true 3D" features. For example, jwatt raised the case where you have an SVG fragment that wants to reorder some of its children within a container, e.g. using CSS z-index,

But what does 'reorder' its children mean if not move them in the z dimension? In the real world, moving something in front of something else means it's nearer. I haven't encountered anyone for whom this behavior is insufficient, and who needs extra use cases.  :)

Analogies with the "real world" can be misleading... but let's proceed :-). I agree that "moving them in the z dimension" is what you want, but real dimensions aren't wanted here. We don't identify pages in a book by their distance from the cover in millimetres. Ordering objects by numbering them is very natural.

It's intrusive and inconsiderate to introduce a feature (changing rendering order) that barges its way into the third dimension, at best doesn't help with 2.5D stuff at all, and at worst wants to claim the third dimension exclusively for itself. (I thought this debate might be fun, but I didn't imagine it would turn into Star Wars!)

I'm not sure what you're referring to here. CSS z-index definitely helps with "2.5D stuff"; it's widely used in Web development.

<svg>
  <g style="z-index: 10">...</g>
  <g>...</g>
  <g>...</g>

</svg>
Suppose you want to copy that fragment into the context of some larger SVG document that contains its own uses of z-index. With CSS you can just set "z-index:0" on the <svg> fragment and you get the results you want. With other proposals, including yours, to avoid layers in the outer document being interleaved with layers in the fragment, you have to renumber the z-values in the fragment and/or the outer document.

I grant that the z values across multiple documents used together need to be compatible. But you can say that about x and y values too.

Yes. And we have SVG features like "viewport", transforms and other tools to let us rescale and reposition SVG fragments; we don't force authors to manually update the coordinates of the included fragment...

And I would argue that authors are more likely to understand and mesh multiple sets of z co-ordinates than multiple sets of z-indexes.

The goal is to not require authors to "understand and mesh" z-indexes.

Rob
--

"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]