Patent Description:
A soft shadow effect is typically achieved with real-time lighting simulation, requiring multiple rendering passes and samplings in a shader. Image quality may be relatively low due to coarse resolution of shadow maps. Because higher processing power may consume more power and generate additional heat, rendering realistic shadowing in every frame in real-time has thus not been attainable on VR devices such as untethered head mounted displays (HMDs) with strict thermal requirements.

<NPL> describes the advantages, limitations, rendering quality and cost of real-time soft shadows algorithms. Recommendations are included based on simple characteristics of the application such as static/moving lights, single or multiple light sources, static/dynamic geometry, geometric complexity, directed or omnidirectional lights, etc..

A first aspect is directed to generating dynamic soft shadows without resorting to computationally-expensive multiple render passes and sampling, or lightmap generation. A dynamic soft shadow is rendered in a single pass, which is sufficiently efficient to run on an untethered virtual reality (VR) device, e.g., a head mounted device (HMD). In some embodiments, a script is used with a shader to render a shadow having a realistic size, shape, position, fading factor and sharpness, based on a position and size of a shadow casting element and a light vector. The shadow quality generated by the embodiments disclosed herein is markedly superior to traditional shadow-generating techniques.

A second aspect is directed to rendering a dynamic soft shadow. To do so, a position and size of a shadow casting element is obtained. A light vector direction is also obtained. Based on the distance between the shadow casting element and a shadowed element, a relative direction between the shadow casting element and the shadowed element, and the direction of the light vector, a shadow position, shadow size, and shadow fading are determined based on the distance between the shadow casting element and a shadowed element, a relative direction between the shadow casting element and the shadowed element, and the direction of the light vector. The shadow position, shadow size, and shadow fading may then be used to render a shadow for the shadow casting element on the shadowed element.

The same reference numbers may be used throughout the drawings to refer to the same or like parts. References made throughout this disclosure relating to specific examples and implementations are provided solely for illustrative purposes.

Casting a dynamic soft shadow on user interface (UI) elements can help enhance realism and improve the experience of user interaction in simulated three-dimensional (3D) environments. However, creating soft shadows in real time has previously been challenging on mobile mixed reality (MR) or virtual reality (VR) devices (collectively "VR devices"), particularly head mounted devices (HMDs). The conventional process uses multiple rendering passes and assembles them in order to create a blurred shadow. It may also rely on the resolution of the texture, possibly resulting in lower image quality, due to limited resolution. A typical prior art procedure may include: render an image using a light vector; render onto a texture; load the texture and test whether a particular pixel falls within the shadow area; render an image with a shadow (a hard shadow); to obtain a soft shadow (with blurred edges), multiple passes of edge illumination rendering is required; and then the final rendering is performed. The processing power required to operate such a process in real-time may exceed the thermal limits of HMDs, since faster processing typically consumes more power and generates more heat.

The disclosed components and techniques render a dynamic shadow in a single pass, requiring less processing than conventional methods. This permits effective soft-shadow generation on untethered VR devices, including HMDs with sensitive thermic limits that might otherwise be exceeded with more demanding processing. The dynamic soft shadows generated using the techniques and components disclosed herein may dynamically change in real time after being initially created, requiring far less computing resources to keep the 3D effect realistic because resource-expensive multiple passes and samplings or lightmap generation are no longer needed. The shadows may thus move in real-time as the shadow casting element and/or light vector move. Additionally, the shadow quality generated by the disclosed techniques may be comparable or even superior to those generated with prior processes.

Dynamic soft shadows may be generated without resorting to computationally-expensive multiple render passes and sampling, or lightmap generation. With disclosed systems and methods, a dynamic soft shadow may be rendered in a single pass, which is sufficiently efficient to run on an untethered virtual reality (VR) device, such as a head mounted device (HMD). Despite the efficiency, the shadow quality may be markedly superior to those generated with other methods. In some embodiments, a script may be used with a shader to render a shadow having a realistic size, shape, position, fading factor and sharpness, based on a position and size of a shadow casting element and a light vector.

Embodiments disclosed herein may generate shadows cast by and onto different UI elements. For purposes of this disclosure, the term "UI element" refers to particular object that is visually displayed in a rendered scene. The object may be a rectangular quad, a triangle, a circle, or any other primitive shape, and include a button or an image.

Dynamic shadows may be generated by first determining values for the position and size of a shadow casting (caster) element, and also holding values for the shadow fading factor, as well as the position and the size of the enlarged shadow that includes its blurred edges (soft part). These holding values may also be modified by a light direction vector, relative distance between the caster element and a shadowed (receiver) element. A smoothstep function may then be applied to test positions of pixels against the modified holding values. A shadow is rendered based, at least in part, on the pixel data test. And a script is attached to the receiver element that passes the position and/or size of the caster element to a shader for dynamic updating of the rendered shadow. The script includes particular variables (caster(location) and caster(size)) that are directly tied to the location and size of the caster element. Vertex and fragments shaders use these variables to initially draw a soft shadow and adjust it as the caster moves. Once the receiving element has size and position information, the position of the shadow can be calculated.

<FIG> are diagrams of a shadowing element casting a shadow on a shadowed element under various geometries, illustrating a changing of a dynamic soft shadow. In <FIG>, a shadow casting element <NUM> is in front of a shadowed element <NUM>, and thus casts a shadow 106a. In <FIG>, however, shadow casting element <NUM> is fairly close to shadowed element <NUM>, so shadow 106a is relatively sharp and dark. In <FIG>, shadow casting element <NUM> has moved further away from shadowed element <NUM>, so shadow 106b is a bit blurred and not quite as dark. In <FIG>, shadow casting element <NUM> has moved even further away from shadowed element <NUM>, so shadow 106c is more blurred and noticeably less dark. In general, as shadow casting element <NUM> moves an increasing distance from shadowed element <NUM>, the resulting shadow will grow in size, have increasing blur (fuzzier edges), and fade (become more faint). Conversely, as shadow casting element <NUM> moves closer to shadowed element <NUM>, the resulting shadow will shrink in size, have sharper edges, and become darker. This behavior, linking the distance between shadow casting element <NUM> and shadowed element <NUM> with shadow size, shadow fading, and shadow sharpness, tracks the noticeable phenomena of real-world shadows to increase realism.

<FIG> illustrates determination of some dimensions and sizes. Shadow casting element <NUM> has a size given by vertical dimension 112a and horizontal dimension 112b. Shadow 106c has a size given by vertical dimension 116a and horizontal dimension 116b. <FIG> illustrates determination of some position, distance, and direction information. Shadow casting element <NUM> is at a position given by a position vector 112p, which may be specified in global coordinates, or may be a relative position, specified as a distance and a direction relative to shadowed element <NUM>. If position vector 112p is a relative position, relative to shadowed element <NUM>, it includes the distance between shadow casting element <NUM> and shadowed element <NUM> and also the relative direction (along that distance) between shadow casting element <NUM> and shadowed element <NUM>. Otherwise, based at least on the position of shadow casting element <NUM>, given by position vector 112p, and the position of shadowed element <NUM>, simple geometric calculations may be used to determine the distance between shadow casting element <NUM> and shadowed element <NUM> and also the relative direction between shadow casting element <NUM> and shadowed element <NUM> along that distance.

A light vector 110v is also shown, having a particular direction. Although <FIG> is a two-dimensional (2D) rendering (e.g. a side perspective), it should be understood that the positions and directions (including 110v and 112p) may have 3D components. The resulting shadow 106c is illustrated having vertical dimension 116a, and located at a vertical position between dimensions 114a and 114b, due to the vertical angular direction component of light vector 110v. The position in the orthogonal (horizontal) dimension may be likewise determinable by the horizontal angular direction component of light vector 110v.

The generated shadows, 106a-106c, may be dynamic in nature, because their computation is sufficiently efficient to be performed in real-time (or near real-time) to update position, size, softness, shape, and/or color based on movements of elements <NUM> and <NUM> and lighting vector 110v. For example, as caster <NUM> moves away from receiver <NUM>, shadow 106a enlarges to shadow 106b and then shadow 106c, becoming larger, lighter, and softer (more highly blurred edges).

<FIG> illustrates shadow fading and sharpness differences between two exemplary shadows <NUM> and <NUM>. Shadow <NUM> is darker and has a sharper edge <NUM>. Shadow <NUM> is illustrated as a pattern of dots reflecting a fainter shadow. Shadow <NUM> has a blurred edge region <NUM>, illustrated as a region of deceasing dot density moving away from the center of shadow <NUM>. This is meant to illustrate that, for a blurred shadow, nearby the edge, there may not be as abrupt of an edge. Thus, shadow <NUM> has a greater sharpness than shadow <NUM>. Shadow <NUM> has greater fading than shadow <NUM>. Shadow fading may be determined by a shadow fading factor.

<FIG> is a block diagram of a dynamic soft shadow operation <NUM>. A shadowing element <NUM> has multiple properties, as illustrated. Position may be absolute or relative; size has multiple dimensional aspects; the shape may be a simple rectangle (quad) or may be a circle (or a general oval), a triangle, or another shape; and may be a UI element or another general object. A shadowed element <NUM> may be of a type specified as a UI element or another general object, and has a particular color or texture (texel). This color, or the color of the texture, will be rendered as darker when depicting a shadow. For example, white will be rendered as a gray, possibly nearly black, and other colors will be rendered as having less luminosity or brightness intensity. Shadowing element <NUM> and shadowed element <NUM> (of <FIG>) were specific manifestations of general shadowing element <NUM> and shadowed element <NUM>. Also, as illustrated, light vector 110v has a direction. In some embodiments, light vector 110v may also have a specified intensity and apparent origin and distribution, used to assist in calculating shadow size, shadow fading, and shadow sharpness.

A shader <NUM> takes as input light vector 110v, shadowing element <NUM>, and shadowed element <NUM>. Using the properties of input light vector 110v, shadowing element <NUM>, and shadowed element <NUM>, certain values and parameters may be determined. These include distance between shadowing element <NUM> and shadowed element <NUM>; the direction between shadowing element <NUM> and shadowed element <NUM> along that distance; and the direction along light vector 110v toward shadowing element <NUM> that propagates to determine the resulting shadow position on shadowed element <NUM>. Shader <NUM> may use a smoothstep function to test pixels corresponding to shadowed element <NUM>, to test whether the pixels are within the shadow. The position of the shadow may be defined according to its center location and its edges then determined based on the shadow's size or the shadow position may be defined according to its edges, which already includes the shadow's size. Using the edges of a shadow to define its position includes the shadow's size, which is determined, at least partially, based on the size of shadowing element <NUM>, and its distance (along the direction of the shadow, which is parallel to light vector 110v) from shadowed element <NUM>. For example, shadowing element <NUM> may be held in a fixed position relative to shadowed element <NUM>, but as light vector 110v sweeps from near-normal incidence on shadowing element <NUM> toward a grazing angle, the distance along the direction of the shadow, which is parallel to light vector <NUM>10v, will increase as the secant of the angle.

This shadow distance may be used in determining the size, sharpness, and fading of the shadow, and is determined using the distance between shadow casting element <NUM> and shadowed element <NUM>, along with the relative direction between shadow casting element <NUM> and shadowed element <NUM>, in conjunction with the direction of light vector 110v. The shadow fading, and also sharpness, affect the color of the rendered pixels (either solid color or colored texture) of shadowed element <NUM>, for example making the rendered color darker inversely proportional to shadow fading. A shadow with no fading will result in darker pixels (closer to black) than a shadow with a high degree of fading. Additionally, a shape of the shadow can be determined by the shape of shadowing element <NUM> and the direction of light vector 110v. For example, a square shadowing element <NUM> (a special case of a rectangle) may cast an elongated rectangle on shadowed element <NUM>, if light vector 110v has a larger off-normal angle in one dimension (such as horizontal or vertical) than in the other dimension. Similarly, a circular shadowing element <NUM> may cast an oval shadow under some geometric arrangements.

Shader <NUM> may perform an initial rendering <NUM> of a shadow, and generates a shadow script <NUM> that may be attached to shadowed element <NUM> to calculate and pass information such as shadow distance to shader <NUM>. Then, as either the position of shadowing element <NUM> or the direction of light vector 110v changes, shadow script <NUM> may be used to dynamically update shader <NUM> to produce with real-time (or near real-time) shadow rendering <NUM>. Shadow script <NUM> simplifies computations, to make the rendering of a realistic dynamic soft shadow feasible on devices with limited computational power.

<FIG> is a block diagram of a VR device <NUM> equipped with a shadow application capable of generating dynamic soft shadows, according to some of the various examples disclosed herein. VR device <NUM> may alternatively take the form of a mobile computing device or any other portable device, including the illustrated HMD worn by a user <NUM>. For example, VR device <NUM> may be a Hololens®. In some examples, a mobile computing device includes a mobile telephone, laptop, tablet, computing pad, netbook, gaming device, wearable device, HMD and/or portable media player. VR device <NUM> may also represent less portable devices such as desktop personal computers, kiosks, tabletop devices, industrial control devices, wireless charging stations, electric automobile charging stations, and other physical objects embedded with computing resources and/or network connectivity capabilities. Additionally, VR device <NUM> may represent a group of processing units or other computing devices, such as for example a combination of a desktop personal computer and an HMD in communication with the desktop personal computer.

In some embodiments, VR device <NUM> has at least one processor <NUM>, a memory area <NUM>, and at least one user interface component <NUM>, illustrated as having a display and an input component. Processor <NUM> includes any quantity of processing units and is programmed to execute computer-executable instructions for implementing aspects of the disclosure. The instructions may be performed by the processor <NUM> or by multiple processors <NUM> within VR device <NUM> or performed by a processor external to the VR device <NUM>. In some examples, processor <NUM> is programmed to execute instructions such as those that may be illustrated in the other figures. In some examples, processor <NUM> represents an implementation of analog techniques to perform the operations described herein. For example, the operations may be performed by an analog computing device and/or a digital computing device.

The user interface component <NUM> may include a display with a quantity of pixels or other components for displaying elements <NUM>, <NUM>, <NUM>, <NUM> and shadows 106a, 106b, 106c, <NUM>, <NUM> described in relation to the prior figures. For example, user interface component <NUM> may include a mixed- reality display that takes imagery captured through a camera <NUM> of the VR device <NUM> and adds virtual content that includes dynamic shadows disclosed herein. Additionally, VR device <NUM> may include one or more sensors <NUM> for capturing environmental data about a surrounding environment (e.g., thermometer, microphone, GPS, and the like) or user data from user <NUM> wearing the VR device <NUM> (e.g., speech, biometric recognition, motion, orientation, and the like). Further still, VR device <NUM> may also include a transceiver <NUM> for communicating data across a network <NUM>. In some embodiments, VR device <NUM> may access a synthetics service <NUM> via network <NUM>. Synthetics service <NUM> may use a data store <NUM> for synthetic objects and provide data for AR, VR, including 3D gaming, and object recognition.

VR device <NUM> also has one or more computer-storage media represented as memory area <NUM>. Memory area <NUM> includes any quantity of computer-storage media associated with or accessible by VR device <NUM>. In particular, the memory area <NUM> stores a shadow application <NUM> for generating a dynamic soft shadow. Shadow application <NUM> includes shadow script <NUM> and shader <NUM>. Shader <NUM> includes a vertex shader <NUM> and a fragment shader <NUM>. Shadow application <NUM>, and its constituent parts, are executable by processor <NUM> to generate dynamic soft shadows on a shadowed element (receiver).

In some embodiments, shadow application <NUM> generates a dynamic soft shadow in the following manner. Shadow script <NUM> retrieves and passes the caster (shadowing) element size and position relative to the receiving element <NUM> to shader <NUM>. The vertex shader <NUM> initially calculates and stores holding values that represent the casting element size and position relative to the receiving element, and for the fading amount, as well as the size of the enlarged shadow that includes its soft part. For example, this may be implemented in the code provided below (e.g., using o. casterCenter. casterSize. zw, as both casterCenter and casterSize initialized as vector4 in the example code below).

Vertex shader <NUM> modifies these values by a light direction vector (e.g., light vector 110v); relative distance between the caster and receiver elements (along a direction parallel to light vector 110v); and a shadow fading factor, and the modified values are then passed to the fragment shader <NUM>. In some embodiments, fragment shader <NUM> uses a smoothstep function to test each pixel's position on the quad against the modified values from the previous step. While doing this testing, the position- and distance-adjusted values are used as thresholds. As position and distance variables change values (e.g., due to the casting element moving), the testing thresholds change as well, consequently producing an interpolated value between <NUM> and <NUM> for each of the pixels. These interpolated values are used to render the dynamic soft shadow on the receiver element. In some embodiments, the color of the rendered dynamic soft shadow is adjusted based on the distance between the caster element and the receiver element.

An example embodiment of shader <NUM> is provided below. Alternative ways to implement vertex shader <NUM> and fragment shader <NUM> are possible. <IMG>
<IMG>
<IMG>
<IMG>
<IMG>.

While shown in a VR device <NUM>, the disclosed shadow application <NUM> may alternatively be stored and executed on a client computer (e.g., laptop, personal computer, or the like); a mobile computing device (e.g., a tablet, smartphone, wearable device, or the like); or on a cloud or virtual machine in a cloud-computing environment. Thus, embodiments disclosed herein are not limited to merely VR devices <NUM>, as other computing devices may host and/or execute the shadow application <NUM>.

<FIG> is a flowchart diagram <NUM> of a work flow for rendering soft shadows. Operation <NUM> includes obtaining a position and a size of a shadow casting element. Operation <NUM> includes obtaining a direction of a light vector. Operation <NUM> includes, based at least on a distance between the shadow casting element and a shadowed element, a relative direction between the shadow casting element and the shadowed element, and the direction of the light vector, determining a shadow position, a shadow size, and a shadow fading. Operation <NUM> includes, based at least on the shadow position, the shadow size, and the shadow fading, rendering a shadow for the shadow casting element on the shadowed element.

In accordance with the invention, in an operation for dynamic updating of the rendered soft shadows, a shader adds holding values for the position and size of a shadow casting element (caster element) as well as the size of the enlarged shadow that includes its soft part. A vertex shader modifies and calculates these holding values by a light direction vector, relative distance between caster and (shadowed) receiver elements, and a shadow fading factor. A fragment shader then uses a smoothstep function to test pixel positions against the modified holding values. While performing the testing, the position and distance adjusted values are used as thresholds. As position and distance variables change values, the testing thresholds change with them, and the function returns an interpolated value between <NUM> and <NUM>. A shadow is then rendered on the receiving (shadowed) element using, at least partially, the testing data determined previously. A script is attached to the receiver element that passes the caster element's position and size to the shader. As a result, when the caster element moves around, the shadow follows it on the receiver element. For example, when the caster element moves away or close to the receiver element, the rendered shadow's sharpness and darkness changes, creating a real-time soft shadow casting. The holding values may be initialized using o. casterCenter. casterSize. zw, as both casterCenter and casterSize being initialized as vector4 in the code reproduced above.

<FIG> is another flowchart diagram <NUM> of a work flow for generating dynamic soft shadows. Operation <NUM> includes attaching a script to the shadowed element that will pass. information to a shader to permit dynamic updating of the rendered shadow. Operation <NUM> includes obtaining the position of the shadow casting element. The obtained position of the shadow casting element may be a relative position, relative to the shadowed element, and thus may already include the distance between the shadow casting element and the shadowed element and the relative direction between the shadow casting element and the shadowed element. Decision operation <NUM> determines whether the position is relative, and if not, operation <NUM> includes obtaining a position of the shadowed element, and based at least on the position of the shadow casting element and the position of the shadowed element, determining the distance between the shadow casting element and the shadowed element and the relative direction between the shadow casting element and the shadowed element. In some embodiments the shadowing element and/or the shadowed element may comprise UI elements. If, however, decision operation <NUM> determines that the position is relative, the process may jump directly to operation <NUM>.

Operation <NUM> includes obtaining a size of a shadow casting element, so that by this point, the combinations of operations <NUM>, <NUM>, and <NUM> have obtained the position and the size of the shadow casting element. Operation <NUM> includes obtaining a shape of the shadow casting element, which in some embodiments may comprise a quad (rectangle) or another shape. Operation <NUM> includes obtaining a direction of a light vector. These values may then be used in other operations, although it should be understood that various orders of operations may be possible.

Operation <NUM> includes determining a shadow position, operation <NUM> includes determining a shadow size; and operation <NUM> includes determining a shadow fading. The combination of operations <NUM>, <NUM>, and <NUM> therefore include, based at least on a distance between the shadow casting element and a shadowed element, a relative direction between the shadow casting element and the shadowed element, and the direction of the light vector, determining a shadow position, a shadow size, and a shadow fading. Operation <NUM> includes, based at least on the distance between the shadow casting element and the shadowed element, the relative direction between the shadow casting element and the shadowed element, and the direction of the light vector, determining a shadow sharpness. Operation <NUM> includes determining a shadow shape. This may be accomplished by starting with the shape of shadow casting element and distort the shadow based on the secant of the light vector direction in each dimension.

Operation <NUM> includes rendering a shadow for the shadow casting element comprises based at least on the shadow position, the shadow size, and the shadow fading, rendering a shadow for the shadow casting element on the shadowed element. In some embodiments, rendering a shadow for the shadow casting element comprises based at least on the shadow position, the shadow size, the shadow fading, and the shadow sharpness, rendering a shadow for the shadow casting element on the shadowed element. In some embodiments, rendering a shadow for the shadow casting element comprises based at least on the shadow position, the shadow size, the shadow fading and the shape of the shadow casting element, rendering a shadow for the shadow casting element on the shadowed element. In some embodiments, rendering a shadow for the shadow casting element comprises based at least on the shadow position, the shadow size, the shadow fading, the shadow sharpness, and the shape of the shadow casting element, rendering a shadow for the shadow casting element on the shadowed element. In some embodiments, rendering a shadow for the shadow casting element comprises testing positions of pixels against the shadow position. In some embodiments, rendering a shadow for the shadow casting element comprises rendering a soft shadow in a single-pass operation.

Dynamically updating the shadow occurs in ongoing operations <NUM>-<NUM>. In some embodiments, operations <NUM>-<NUM> may occur only a single time for each of multiple iterations of operation <NUM>-<NUM>. If there is no need for dynamic updating, for example, shadow casting element and light direction may not change over time.

Some aspects and examples disclosed herein are directed to a solution for rendering a soft shadow comprising: a processor; and a computer-readable medium storing instructions that are operative when executed by the processor to: obtain a position and a size of a shadow casting element; obtain a direction of a light vector; based at least on a distance between the shadow casting element and a shadowed element, a relative direction between the shadow casting element and the shadowed element, and the direction of the light vector, determine a shadow position, a shadow size, and a shadow fading; and based at least on the shadow position, the shadow size, and the shadow fading, render a shadow for the shadow casting element on the shadowed element.

Additional aspects and examples disclosed herein are directed to a process for rendering a soft shadow comprising: obtaining a position and a size of a shadow casting element; obtaining a direction of a light vector; based at least on a distance between the shadow casting element and a shadowed element, a relative direction between the shadow casting element and the shadowed element, and the direction of the light vector, determining a shadow position, a shadow size, and a shadow fading; and based at least on the shadow position, the shadow size, and the shadow fading, rendering a shadow for the shadow casting element on the shadowed element.

Additional aspects and examples disclosed herein are directed to a one or more computer storage devices having computer-executable instructions stored thereon for rendering a soft shadow, which, on execution by a computer, cause the computer to perform operations that may comprise: obtaining a position and a size and a shape of a shadow casting element, wherein the shadow casting element comprises a UI element; obtaining a direction of a light vector; based at least on a distance between the shadow casting element and a shadowed element, a relative direction between the shadow casting element and the shadowed element, and the direction of the light vector, determining a shadow position, a shadow size, a shadow fading, a shadow sharpness, and a shadow shape; and based at least on the shadow position, the shadow size, the shadow fading, the shadow sharpness, and the shadow shape, rendering a shadow for the shadow casting element on the shadowed element, wherein the shadowed element comprises a UI element, wherein rendering a shadow for the shadow casting element comprises testing positions of pixels against the shadow position, and wherein rendering a shadow for the shadow casting element comprises rendering a soft shadow in a single-pass operation; and attaching a script to the shadowed element that passes information to a shader for dynamic updating of the rendered shadow.

<FIG> is a block diagram of an example computing device <NUM> for implementing aspects disclosed herein, and is designated generally as computing device <NUM>. Computing device <NUM> is but one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the embodiments disclosed herein. Neither should the computing device <NUM> be interpreted as having any dependency or requirement relating to any one or combination of components/modules illustrated.

The examples and embodiments disclosed herein may be described in the general context of computer code or machine-useable instructions, including computer-executable instructions such as program components, being executed by a computer or other machine, such as a personal data assistant or other handheld device. Generally, program components including routines, programs, objects, components, data structures, and the like, refer to code that performs particular tasks, or implement particular abstract data types. The discloses examples may be practiced in a variety of system configurations, including personal computers, laptops, smart phones, mobile tablets, hand-held devices, consumer electronics, specialty computing devices, etc. The disclosed examples may also be practiced in distributed computing environments, such as those disclosed in <FIG> described in more detail below, where tasks are performed by remote-processing devices that are linked through a communications network.

Computing device <NUM> includes a bus <NUM> that directly or indirectly couples the following devices: computer-storage memory <NUM>, one or more processors <NUM>, one or more presentation components <NUM>, input/output (I/O) ports <NUM>, I/O components <NUM>, a power supply <NUM>, and a network component <NUM>. Computer device <NUM> should not be interpreted as having any dependency or requirement related to any single component or combination of components illustrated therein. While computer device <NUM> is depicted as a seemingly single device, multiple computing devices <NUM> may work together and share the depicted device resources. For instance, computer-storage memory <NUM> may be distributed across multiple devices, processor(s) <NUM> may provide housed on different devices, and so on.

Bus <NUM> represents what may be one or more busses (such as an address bus, data bus, or a combination thereof). Although the various blocks of <FIG> are shown with lines for the sake of clarity, in reality, delineating various components is not so clear, and metaphorically, the lines would more accurately be grey and fuzzy. For example, one may consider a presentation component such as a display device to be an I/O component. Also, processors have memory. Such is the nature of the art, and reiterate that the diagram of <FIG> is merely illustrative of an exemplary computing device that can be used in connection with one or more disclosed embodiments. Distinction is not made between such categories as "workstation," "server," "laptop," "hand-held device," etc., as all are contemplated within the scope of <FIG> and the references herein to a "computing device.

Computer-storage memory <NUM> may take the form of the computer-storage media references below and operatively provide storage of computer-readable instructions, data structures, program modules and other data for the computing device <NUM>. For example, computer-storage memory <NUM> may store an operating system, a universal application platform, or other program modules and program data. Computer-storage memory <NUM> may be used to store and access instructions configured to carry out the various operations disclosed herein.

As mentioned below, computer-storage memory <NUM> may include computer-storage media in the form of volatile and/or nonvolatile memory, removable or non-removable memory, data disks in virtual environments, or a combination thereof. And computer-storage memory <NUM> may include any quantity of memory associated with or accessible by the display device <NUM>. The memory <NUM> may be internal to the display device <NUM> (as shown in <FIG>), external to the display device <NUM> (not shown), or both (not shown). Examples of memory <NUM> in include, without limitation, random access memory (RAM); read only memory (ROM); electronically erasable programmable read only memory (EEPROM); flash memory or other memory technologies; CDROM, digital versatile disks (DVDs) or other optical or holographic media; magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices; memory wired into an analog computing device; or any other medium for encoding desired information and for access by the display device <NUM>. Additionally or alternatively, the computer-storage memory <NUM> may be distributed across multiple display devices <NUM>, e.g., in a virtualized environment in which instruction processing is carried out on multiple devices <NUM>. For the purposes of this disclosure, "computer storage media," "computer-storage memory," "memory," and "memory devices" are synonymous terms for the computer-storage media <NUM>, and none of these terms include carrier waves or propagating signaling.

Processor(s) <NUM> may include any quantity of processing units that read data from various entities, such as memory <NUM> or I/O components <NUM>. Specifically, processor(s) <NUM> are programmed to execute computer-executable instructions for implementing aspects of the disclosure. The instructions may be performed by the processor, by multiple processors within the computing device <NUM>, or by a processor external to the client computing device <NUM>. In some examples, the processor(s) <NUM> are programmed to execute instructions such as those illustrated in the flowcharts discussed below and depicted in the accompanying drawings. Moreover, in some examples, the processor(s) <NUM> represent an implementation of analog techniques to perform the operations described herein. For example, the operations may be performed by an analog client computing device <NUM> and/or a digital client computing device <NUM>.

Presentation component(s) <NUM> present data indications to a user or other device. Exemplary presentation components include a display device, speaker, printing component, vibrating component, etc. One skilled in the art will understand and appreciate that computer data may be presented in a number of ways, such as visually in a graphical user interface (GUI), audibly through speakers, wirelessly between computing devices <NUM>, across a wired connection, or in other ways.

Ports <NUM> allow computing device <NUM> to be logically coupled to other devices including I/O components <NUM>, some of which may be built in. Examples I/O components <NUM> include, for example but without limitation, a microphone, joystick, game pad, satellite dish, scanner, printer, wireless device, etc..

The computing device <NUM> may operate in a networked environment via the network component <NUM> using logical connections to one or more remote computers. In some examples, the network component <NUM> includes a network interface card and/or computer-executable instructions (e.g., a driver) for operating the network interface card. Communication between the computing device <NUM> and other devices may occur using any protocol or mechanism over any wired or wireless connection. In some examples, the network component <NUM> is operable to communicate data over public, private, or hybrid (public and private) using a transfer protocol, between devices wirelessly using short range communication technologies (e.g., near-field communication (NFC), Bluetooth™ branded communications, or the like), or a combination thereof.

Turning now to <FIG>, an exemplary block diagram illustrates a cloud-computing architecture <NUM>, suitable for use in implementing aspects of this disclosure. Architecture <NUM> should not be interpreted as having any dependency or requirement related to any single component or combination of components illustrated therein. In addition, any number of nodes, virtual machines, data centers, role instances, or combinations thereof may be employed to achieve the desired functionality within the scope of embodiments of the present disclosure.

The distributed computing environment of <FIG> includes a public network <NUM>, a private network <NUM>, and a dedicated network <NUM>. Public network <NUM> may be a public cloud-based network of computing resources, for example. Private network <NUM> may be a private enterprise network or private cloud-based network of computing resources. And dedicated network <NUM> may be a third-party network or dedicated cloud-based network of computing resources. In some examples, private network <NUM> may host a customer data center <NUM>, and dedicated network <NUM> may host cloud synthetics services <NUM> (which may be similar to synthetics service <NUM> of <FIG>).

Hybrid cloud <NUM> may include any combination of public network <NUM>, private network <NUM>, and dedicated network <NUM>. For example, dedicated network <NUM> may be optional, with hybrid cloud <NUM> comprised of public network <NUM> and private network <NUM>. Along these lines, some customers may opt to only host a portion of their customer data center <NUM> in the public network <NUM> and/or dedicated network <NUM>, retaining some of the customers' data or hosting of customer services in the private network <NUM>. For example, a customer that manages healthcare data or stock brokerage accounts may elect or be required to maintain various controls over the dissemination of healthcare or account data stored in its data center or the applications processing such data (e.g., software for reading radiology scans, trading stocks, etc.). Myriad other scenarios exist whereby customers may desire or need to keep certain portions of data centers under the customers' own management. Thus, in some examples, customer data centers may use a hybrid cloud <NUM> in which some data storage and processing is performed in the public network <NUM> while other data storage and processing is performed in the dedicated network <NUM>.

Public network <NUM> may include data centers configured to host and support operations, including tasks of a distributed application, according to the fabric controller <NUM>. It will be understood and appreciated that data center <NUM> and data center <NUM> shown in <FIG> are merely examples of suitable implementations for accommodating one or more distributed applications, and are not intended to suggest any limitation as to the scope of use or functionality of examples disclosed herein. Neither should data center <NUM> and data center <NUM> be interpreted as having any dependency or requirement related to any single resource, combination of resources, combination of servers (e.g., servers <NUM> and <NUM>) combination of nodes (e.g., nodes <NUM> and <NUM>), or a set of application programming interfaces (APIs) to access the resources, servers, and/or nodes.

Data center <NUM> illustrates a data center comprising a plurality of servers, such as servers <NUM> and <NUM>. A fabric controller <NUM> is responsible for automatically managing the servers <NUM> and <NUM> and distributing tasks and other resources within the data center <NUM>. By way of example, the fabric controller <NUM> may rely on a service model (e.g., designed by a customer that owns the distributed application) to provide guidance on how, where, and when to configure server <NUM> and how, where, and when to place application <NUM> and application <NUM> thereon. One or more role instances of a distributed application may be placed on one or more of the servers <NUM> and <NUM> of data center <NUM>, where the one or more role instances may represent the portions of software, component programs, or instances of roles that participate in the distributed application. In other examples, one or more of the role instances may represent stored data that are accessible to the distributed application.

Data center <NUM> illustrates a data center comprising a plurality of nodes, such as node <NUM> and node <NUM>. One or more virtual machines may run on nodes of data center <NUM>, such as virtual machine <NUM> of node <NUM> for example. Although <FIG> depicts a single virtual node on a single node of data center <NUM>, any number of virtual nodes may be implemented on any number of nodes of the data center in accordance with illustrative embodiments of the disclosure. Generally, virtual machine <NUM> is allocated to role instances of a distributed application, or service application, based on demands (e.g., amount of processing load) placed on the distributed application. As used herein, the phrase "virtual machine" is not meant to be limiting, and may refer to any software, application, operating system, or program that is executed by a processing unit to underlie the functionality of the role instances allocated thereto. Further, the virtual machine(s) <NUM> may include processing capacity, storage locations, and other assets within the data center <NUM> to properly support the allocated role instances.

In operation, the virtual machines are dynamically assigned resources on a first node and second node of the data center, and endpoints (e.g., the role instances) are dynamically placed on the virtual machines to satisfy the current processing load. In one instance, a fabric controller <NUM> is responsible for automatically managing the virtual machines running on the nodes of data center <NUM> and for placing the role instances and other resources (e.g., software components) within the data center <NUM>. By way of example, the fabric controller <NUM> may rely on a service model (e.g., designed by a customer that owns the service application) to provide guidance on how, where, and when to configure the virtual machines, such as virtual machine <NUM>, and how, where, and when to place the role instances thereon.

As described above, the virtual machines may be dynamically established and configured within one or more nodes of a data center. As illustrated herein, node <NUM> and node <NUM> may be any form of computing devices, such as, for example, a personal computer, a desktop computer, a laptop computer, a mobile device, a consumer electronic device, a server, the computing device <NUM> of <FIG>, and the like. In one instance, the nodes <NUM> and <NUM> host and support the operations of the virtual machine(s) <NUM>, while simultaneously hosting other virtual machines carved out for supporting other tenants of the data center <NUM>, such as internal services <NUM>, hosted services <NUM>, and storage <NUM>. Often, the role instances may include endpoints of distinct service applications owned by different customers.

Typically, each of the nodes include, or is linked to, some form of a computing unit (e.g., central processing unit, microprocessor, etc.) to support operations of the component(s) running thereon. As utilized herein, the phrase "computing unit" generally refers to a dedicated computing device with processing power and storage memory, which supports operating software that underlies the execution of software, applications, and computer programs thereon. In one instance, the computing unit is configured with tangible hardware elements, or machines, that are integral, or operably coupled, to the nodes to enable each device to perform a variety of processes and operations. In another instance, the computing unit may encompass a processor (not shown) coupled to the computer-readable medium (e.g., computer storage media and communication media) accommodated by each of the nodes.

The role of instances that reside on the nodes may be to support operation of service applications, and thus they may be interconnected via APIs. In one instance, one or more of these interconnections may be established via a network cloud, such as public network <NUM>. The network cloud serves to interconnect resources, such as the role instances, which may be distributed across various physical hosts, such as nodes <NUM> and <NUM>. In addition, the network cloud facilitates communication over channels connecting the role instances of the service applications running in the data center <NUM>. By way of example, the network cloud may include, without limitation, one or more communication networks, such as local area networks (LANs) and/or wide area networks (WANs). Such communication networks are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet, and therefore need not be discussed at length herein.

Although described in connection with an example computing device <NUM>, examples of the disclosure are capable of implementation with numerous other general-purpose or special-purpose computing system environments, configurations, or devices. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with aspects of the disclosure include, but are not limited to, smart phones, mobile tablets, mobile computing devices, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, gaming consoles, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, mobile computing and/or communication devices in wearable or accessory form factors (e.g., watches, glasses, headsets, or earphones), network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, VR devices, holographic device, and the like. Such systems or devices may accept input from the user in any way, including from input devices such as a keyboard or pointing device, via gesture input, proximity input (such as by hovering), and/or via voice input.

By way of example and not limitation, computer readable media comprise computer storage media and communication media. Computer storage media include volatile and nonvolatile, removable and non-removable memory implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or the like. Computer storage media are tangible and mutually exclusive to communication media. Computer storage media are implemented in hardware and exclude carrier waves and propagated signals. Computer storage media for purposes of this disclosure are not signals per se. Exemplary computer storage media include hard disks, flash drives, solid-state memory, phase change random-access memory (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. In contrast, communication media typically embody computer readable instructions, data structures, program modules, or the like in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media.

The examples illustrated and described herein, as well as examples not specifically described herein but within the scope of aspects of the disclosure, constitute exemplary means for providing an immersive feedback loop for improving AI in a cloud computing environment. The order of execution or performance of the operations in examples of the disclosure illustrated and described herein is not essential, and may be performed in different sequential manners in various examples.

Claim 1:
A system for rendering a soft shadow, the system comprising:
a processor (<NUM>); and
a computer-readable medium (<NUM>) storing instructions that are operative when executed by the processor to:
obtain a position and a size of a shadow casting element (<NUM>);
obtain a direction of a light vector (<NUM>);
based at least on a distance between the shadow casting element and a shadowed element, a relative direction between the shadow casting element and the shadowed element, and the direction of the light vector, determine a shadow position, a shadow size, and a shadow fading (<NUM>);
based at least on the shadow position, the shadow size, and the shadow fading, render a shadow for the shadow casting element on the shadowed element (<NUM>); and
attach a script to the shadowed element that passes information to a shader for dynamic updating of the shadow, wherein said information comprises the position and size of the shadow casting element, for dynamic updating of the rendered shadow