A graphics rendering method

Abstract

The present invention relates to a graphics rendering method. The method comprises obtaining a two-dimensional, 2D, texture that is to be applied to a surface of a target three-dimensional, 3D, virtua

Description

FIELD OF THE INVENTION The present invention relates to computer graphics, and in particular to a graphics rendering method. BACKGROUND Designing packaging for fast-moving consumer goods (FMCG) such as soft drinks, confectionery, cleaning products, personal hygiene products, and the like, typically involves generating virtual mock-ups of the FMCG packaging. This is done so that various quality assurance / control processes may be carried out using the virtual mock-up prior to committing to print. To generate the virtual mock-up, a two-dimensional (2D) image file the packaging’s design is applied to a surface of a three-dimensional (3D) virtual object representing an FMCG (a soft drinks container, for example). This 2D image file is also known as a “mech”, and may be thought of as a texture that is superimposed onto the surface of the 3D virtual object. Once the mech is applied to the 3D virtual object, adjustments to the mech and / or 3D virtual object may be made. For example, the colour of part of the 3D virtual object may be adjusted to match an accent colour of the mech, the positioning of the mech along the surface of the 3D virtual object may be adjusted so that any significant graphical elements of the mech (the logo, product name, and the like) may face the virtual camera to be used for rendering an image of the 3D virtual object, and the like. Such adjustments are typically carried out manually. Once the adjustments have been made, an image of the 3D virtual object is rendered from the point of view (POV) of the virtual camera. This rendered image may then be used as the virtual mock-up. As will be appreciated, mechs are typically designed in a batch, with each mech depicting a packaging design for a different product in a product range (different flavours of a soft drinks brand, for example). While the mechs of the batch may possess certain similarities (similar logos, for example), there may also be differences between the mech (different colours, logo size / placement, additional text / graphical elements, and the like). Thus, in order to generate virtual mock-ups for a whole product range, a graphic designer has to manually apply a different mech of the batch to the 3D virtual object, make adjustments to the mech and / or 3D virtual object, and render the image, all in an iterative fashion. As will be appreciated, this process is laborious, time-consuming and prone to human error. The present invention seeks to mitigate or alleviate these issues. SUMMARY OF INVENTION In a first aspect, there is provided a graphics rendering method, comprising the steps of: obtaining a two-dimensional, 2D, texture that is to be applied to a surface of a target three-dimensional, 3D, virtual object, the 2D texture having metadata associated therewith; instantiating the target 3D virtual object and a virtual camera within a 3D virtual environment; applying the 2D texture to the target 3D virtual object’s surface to obtain an initial virtual scene; adjusting, based on the metadata, one or more parameters of the initial virtual scene to obtain a final virtual scene; rendering the final virtual scene from a point of view, POV, of the virtual camera; and outputting, for display, the rendered final virtual scene. In short, the present invention relates to an automated method of generating virtual mock-ups (that is, rendered final virtual scenes) of FMCG packaging. Advantageously, this method removes the need for manual adjustments to the mech (the 2D texture) and / or the target 3D virtual object prior to rendering. This is achieved by specifying the desired adjustments within metadata associated with the mech—the computing system implementing the method reads the metadata of the mech, and automatically adjusts the parameters of the initial virtual scene (comprising the mech as initially applied to the target 3D virtual object) based on the information contained within the metadata. This way, the time and labour expenditure associated with generating virtual mock-ups is reduced. Additionally, there is an increase in the accuracy of the adjustments made to the initial virtual scene prior to rendering due to the reduction in manual intervention. Optionally, the step of obtaining the 2D texture may comprise obtaining a batch of 2D textures, each 2D texture having respective metadata associated therewith; and the remaining steps of the method are performed as an iterative loop, wherein a different 2D texture of the batch is used in each iteration. This is to say that this automated method may be performed using a batch of mechs in order to produce virtual mock-ups for a whole product range in a quicker, less laborious, and more accurate way. Preferably, the metadata may indicate one or more object properties; and the method comprises the step of obtaining, as the target 3D virtual object, a 3D virtual object that possesses the indicated object properties. Optionally, the one or more object properties may comprise at least one of an object type, an object size, an object shape, and a material. This way, not only does the metadata indicate adjustments to be made to the initial virtual scene, but also indicates which 3D virtual object is to be used in the virtual mock-up. This further reduces the amount of manual intervention required to generate virtual mock-ups, thus further reduces time and labour expenditure, as well as further increasing accuracy. Preferably, the method may comprise the step of obtaining scene data, the scene data indicating a predefined pose with which the target 3D virtual object is to be instantiated relative to the virtual camera; and the instantiating step may comprise instantiating the target 3D virtual object with the predefined pose. More preferably, the metadata (associated with the 2D texture) may comprise the scene data. This further reduces the amount of manual intervention required to generate virtual mock-ups, as the positioning / orienting of the target 3D virtual object may be carried out automatically instead. This has the benefit of further reducing time and labour expenditure, as well as further increasing accuracy. Preferably, the metadata may indicate a target colour; and the step of adjusting one or more parameters may comprise adjusting a colour of one or more parts of the target 3D virtual object to match the target colour. Optionally, the target 3D virtual object may represent a container (such as a soft drinks container, for example); and the one or more parts of the target 3D virtual object may comprise at least one of a virtual lid of the container, and a virtual contents of the container (a soft drinks beverage, for example). As mentioned previously, when generating a virtual mock-up, the colour of part of the 3D virtual object may be adjusted to match an accent colour of the mech. The present invention provides an automated way of doing so. As a non-limiting example of obtaining the target colour, the metadata may comprise a label associated with the target colour (a label of “peach”, for example); the method may comprise the step of obtaining, from an entry within a lookup table, a set of colour values defining the target colour (an RGB colour value set of (246, 161, 146), for example), the entry comprising a correspondence between the label and the set of colour values (“peach” = RGB (246, 161, 146), for example); and the step of adjusting one or more parameters comprises adjusting a colour of one or more parts of the target 3D virtual object based on the set of colour values. Preferably, the applying step may comprise applying the 2D texture to an axisymmetric surface of the target 3D virtual object (such as the cylindrical surface of a virtual soft drinks can / bottle, for example); the metadata may indicate a set of reference pixels within the 2D texture; and the step of adjusting one or more parameters may comprise rotating the 2D texture about an axis of the axisymmetric surface such that the set of reference pixels faces the virtual camera. More preferably, the metadata may comprise a target pixel coordinate for indicating the set of reference pixels. As mentioned previously, when generating a virtual mock-up, the positioning of the mech along the surface of the 3D virtual object may be adjusted so that any significant graphical elements of the mech may face the virtual camera. The present invention provides an automated way of doing so. In particular, the set of reference pixels may coincide with a location of a significant graphical element within the mech (that is, a 2D image file made up of pixels). Therefore, making the set of reference pixels face the virtual camera (by rotating the mech along the target 3D virtual object’s axisymmetric surface) may result in the significant graphical element facing the virtual camera. The location of each pixel within the 2D texture may be defined in terms of a set of pixel coordinates (x, y). As such, the set of reference pixels may be defined by a target pixel coordinate, such as x = 1465, for example. Optionally, the 2D texture may comprise a set of graphical elements, the set comprising a target (or significant) graphical element; and the method may comprise the steps of: obtaining a 2D template image having at least the target graphical element in common with the 2D texture; creating a bounding box circumscribing the target graphical element of the 2D template image; determining a centroid of the bounding box; and identifying, as the target pixel coordinate, a pixel coordinate of the centroid of the bounding box. It may be the case that a group of mechs (within the same batch, or dispersed among different batches) possess an identical significant graphical element in an identical location. In this case, rather than specifying an identical pixel coordinate within each mech’s respective metadata, a 2D template image may be created. This 2D template image may be thought of as one set of metadata that is associated to each mech of the group in a one-to-many fashion. The 2D template image may possess the same significant graphical element in the same location as that of each mech within the group. In order to find the target pixel coordinate for each mech of the group, a bounding box is created around the significant graphical element contained within the 2D template image, and a set of reference pixels coinciding with the centroid of the bounding box is found. Like with the 2D texture, the 2D template image is typically an image file made up of pixels, and so the reference line may be defined in terms of a target pixel coordinate, such as x = 1465, for example. Preferably, at least part of the metadata may be contained within a file name of the 2D texture. As mentioned previously, a mech is typically a 2D image file. Image files typically possess a file name in order to differentiate one from the other. Advantageously, the metadata may be stored as part of the file name, thereby removing the need for additional data types for storing the metadata (such as exif metadata, for example). Thus, the computational overheads of storing and transmitting the mechs may be reduced. In a second aspect, there is provided a computer program comprising processor-implementable instructions which, when executed by a processor, cause the processor to perform the method of the first aspect. In a third aspect, there is provided a non-transitory computer-readable storage medium having stored thereon the computer program of the second aspect. In a fourth aspect, there is provided a computing system, comprising a processor and a memory, the memory having stored thereon processor-implementable instructions which, when executed by a processor, cause the computing device to perform the method of the first aspect. BRIEF DESCRIPTION OF DRAWINGS Embodiments of the present invention will be described with reference to the accompanying Figures, in which: Figure 1 depicts a flowchart illustrating a graphics rendering method according to embodiments of the present invention; Figure 2 depicts automatic colour adjustments according to embodiments of the present invention; Figures 3A to 3D depict automatic texture alignment adjustments according to embodiments of the present invention; Figure 4 depicts a flowchart illustrating a graphics rendering method according to embodiments of the present invention; and Figure 5 schematically illustrates a computing system according to embodiments of the present invention. DETAILED DESCRIPTION A graphics rendering method is disclosed. In the following description, a number of specific details are presented in order to provide a thorough understanding of the embodiments of the present invention. It will be apparent, however, to a person skilled in the art that these specific details need not be employed to practice the present invention. Conversely, specific details known to the person skilled in the art are omitted for the purposes of clarity where appropriate. Graphics Rendering Method Turning now to Figure 1, a graphics rendering method 100 comprises the steps of: obtaining a two-dimensional, 2D, texture that is to be applied to a surface of a target three-dimensional, 3D, virtual object, the 2D texture having metadata associated therewith (step S101); instantiating the target 3D virtual object and a virtual camera within a 3D virtual environment (step S102); applying the 2D texture to the target 3D virtual object’s surface to obtain an initial virtual scene (step S103); adjusting, based on the metadata, one or more parameters of the initial virtual scene to obtain a final virtual scene (step S104); rendering the final virtual scene from a point of view, POV, of the virtual camera (step S105); and outputting, for display, the rendered final virtual scene (step S106). At step S101, the 2D texture (that is, the mech) is obtained by a computing system. For example, the mech may be obtained via an input port of the computing system. Examples of input ports include USB ports, Ethernet ® ports, Wi-Fi ® ports, Bluetooth ® ports, and the like. Alternatively, the mech may be obtained from an internal memory of the computing system. Examples of internal memory include a RAM, ROM, hard drive, solid state drive, and the like. The mech may be a 2D image file made up of pixels. The mech may be in any file format the skilled person deems appropriate. Examples of file formats include JPEG, PNG, PDF, and the like. In order to facilitate the automatic parameter adjustment (in step S104), the mech has metadata associated with it. Preferably, at least part of the metadata is contained within a file name of the 2D texture. The metadata shall be discussed in more detail later herein. At step S102, a processor of the computing system executes software / an application in order to launch a 3D virtual environment on the computing device. The skilled person may use any appropriate software / application for launching a 3D virtual environment. Examples of such software / applications include game engines (such as Unreal Engine 5), 3D animation software (such as Cinema 4D, Blender, or the like), computer aided design software (such as Dassault Systemes Solidworks), and the like. Once the 3D virtual environment is launched, the target 3D virtual object and a virtual camera are instantiated (or inserted) within the 3D virtual environment. This may be performed manually. For example, by manipulating a keyboard and mouse connected to the computing system, a graphic designer may select the target 3D virtual object from a database, and insert the target 3D virtual object and the virtual camera within the 3D virtual environment. The database may be stored within a memory of the computing system, or stored within an external server. Alternatively, step S102 may be performed automatically (that is, by the computing system). In this case, the metadata (associated with the mech) may indicate one or more object properties. Further, the method 100 may comprise the step of obtaining, as the target 3D virtual object, a 3D virtual object that possesses the indicated object properties. This is to say that the computing system may automatically select the target 3D virtual object (from a database, for example) based on the indicated object properties within the metadata. Optionally, the one or more object properties comprise at least one of: • an object type (a soft drinks can or bottle, for example) • object size (a volume of 330 millilitres, for example); • an object shape (a desired axisymmetric profile, for example); • a material (aluminium, or a transparent plastics material, for example). In any case, once the target 3D virtual object has been selected based on the indicated object properties, the computing system may perform step S102 by inserting the target 3D virtual object and the virtual camera within the 3D virtual environment. As will be appreciated, the composition of the final rendered virtual scene (that is, the virtual mock-up) is dependent upon the position / orientation (that is, pose) of the target 3D virtual object relative to the virtual camera. Typically, the process of positioning / orienting the target 3D virtual object has been a manual one. However, to reduce the amount of manual intervention required to generate virtual mock-ups, the method 100 may comprise the step of obtaining scene data, the scene data indicating a predefined pose with which the target 3D virtual object is to be instantiated relative to the virtual camera. The computing system may then perform step S102 by instantiating the target 3D virtual object with the predefined pose. The scene data define a displacement between target 3D virtual object and the virtual camera and / or defining an angle between, say, an axis of the target 3D virtual object and the optical axis of the virtual camera, for example. The scene data may be obtained via the input port of the computing system. It may be different from or comprised within the metadata (associated with the mech). In any case, in step S102, the processor of the computing system may instantiate the target 3D virtual object at a position / orientation relative to the virtual camera which satisfies the predefined displacement / angle. At step S103, the processor of the computing system applies the mech to the surface of the target 3D virtual object. This is colloquially known as “texturing”, and is a process that is typically used in video game graphics rendering pipelines. Detailed discussion of texturing is therefore omitted for brevity’s sake. Applying the mech to the target 3D virtual object results in an initial virtual scene being formed. Subsequently, the parameters of this initial virtual scene are adjusted (at step S104) based on the metadata associated with the mech. At step S104, the processor of the computing system adjusts one or more parameters of the initial virtual scene based on the metadata of the mech to obtain a final virtual scene. This final virtual scene is subsequently rendered (at step S105) and then output / displayed (at step S106) as the virtual mock-up. Turning now to Figure 2, the one or more to-be-adjusted parameters may comprise a colour of one or more parts of the target 3D virtual object. Figure 2 depicts three mechs 201, 202, 203, each of which having a different colour element from the others. Mech 201 has a peach colour element, mech 202 has a raspberry colour element, and mech 203 has a blueberry colour element. As seen in Figure 2, each mech 201, 202, 203 has a file name 201a, 202a, 203a respectively associated with it. Each file name 201a, 202a, 203a comprises metadata indicating a target colour. For example, part of the file name 201a recites “PEACH”, which may be thought of as a label indicating the target colour to be used in step S104. Similarly, each of the file names 202a and 203a recite labels of “RASPBERRY” and “BLUEBERRY”, respectively. Alternatively, the file name 201a may explicitly recite a set of colour values (such in a RGB, HSL, or Hex code format, for example) to indicate the target colour. In this latter case, the processor of the computing system may perform step S104 by adjusting, based on the indicated set of colour values, the colour of parts of the target 3D virtual object to match the target colour. In embodiments where the metadata comprises a label associated with the target colour (as seen in Figure 2), the method 100 may comprise the step of obtaining, from an entry 204a, 204b, 204c within a lookup table 204, a set of colour values defining the target colour, the entry 204a, 204b, 204c comprising a correspondence between the label and the set of colour values. As seen in Figure 2, the lookup table 204 comprises multiple entries 204a, 204b, 204c. Each entry 204a, 204b, 204c may be thought of as a different row of the lookup table 204, and respectively comprises a correspondence between the label of the target colour and a set of colour values (here in RGB format) defining the target colour. For example, entry 204a comprises the label of “Peach” and a corresponding set of RGB colour values of (246, 161, 146). A similar correspondence can be seen in each of entries 204b and 204c. The lookup table 204 may be stored within a memory of the computing system, or stored within an external server. In any case, the computing system accesses the lookup table 204, and queries it to find the entry 204a, 204b, 204c that comprises the same colour label as that indicated in the metadata of the mech. Once the appropriate entry 204a, 204b, 204c is found, the computing system obtains the corresponding set of colour values for use in step S104. Once the set of colour values are obtained, the processor of the computing system may perform step S104 by adjusting, based on the obtained set of colour values, the colour of parts of the target 3D virtual object to match the target colour. Notably in Figure 2, each file name 201a, 202a, 203a also comprises metadata indicating one or more object properties. For example, part of the file name 201a recites “PET_500ml”, which indicates that the target 3D virtual object is to be a soft drinks bottle made of Polyethylene terephthalate (PET) and having a volume / capacity of 500 millilitres. The same can be said for file names 202a and 203a. The processor of the computing system may read this part of the file name 201a, 202a, 203a, and select, as the target 3D virtual object, a virtual object representing a PET bottle having a 500 millilitre capacity. Again, the processor may make the selection from a database storing different virtual objects. As a result of performing step S104 based on the metadata comprised within the file name 201a, 202a, 203a, a final virtual scene is obtained. This final virtual scene may then be rendered (at step S105) and output (at step S106) as a virtual mock-up. Figure 2 depicts multiple virtual mock-ups 205a, 205b, 205c, each of which having been generated based on the metadata comprised within a different one of the file names 201 a, 202a, 203a. For example, virtual mock-up 205a has been generated based on the file name 201 a of mech 201. In particular, the virtual mock-up 205a depicts a 500 millilitre capacity PET bottle with the mech 201 applied to its surface, and a lid (that is, a part) having a “Peach” colour. Similarly, virtual mock-ups 205b and 205c depict the same PET bottle, but with mechs 202 and 203 applied, and its lid having a “Raspberry” and “Blueberry” colour, respectively. Although not depicted in Figure 2, other parts of the PET bottle may be colour-adjusted. For example, the (virtual) fluid contents of the PET bottle may have its colour adjusted to match the target colour. Thus, it will be appreciated that in a case where the target 3D virtual object represents a container (such as a soft drinks container, for example), the one or more parts of the target 3D virtual object (to be colour-adjusted) may comprise at least one of a virtual lid of the container (as depicted in virtual mock-ups 205a, 205b, 205c), and a virtual contents of the container. Turning now to Figures 3Ato 3D, the one or more to-be-adjusted parameters may comprise an alignment of the applied mech with respect to the virtual camera. Figure 3A depicts two mechs 301a, 301b. As can be seen in Figure 3A, the mechs 301a and 301b have similar graphical elements, albeit in different arrangements. When generating virtual mock-ups of the mechs 301a, 301b, it is preferable to have a target (or significant) graphical element (such as a logo, product name, and the like) face the virtual camera to reflect how the physical FMCG will appear on a shelf. As seen in Figure 3A, the virtual mock-up 302a generated using the mech 301a has the target graphical element (the logo in this case) facing the virtual camera. However, the virtual mock-up 302b generated using the mech 301b has the target graphical element facing away from the virtual camera (and towards the right hand side of the page). This is due to the difference in the location of the target graphical element within the mech 301b compared with the mech 301a. As will be appreciated, this alignment issue is particular prevalent in the case where the target 3D virtual object comprises an axisymmetric surface (such as a cylindrical surface of a soft drinks can, as seen in Figure 3A). In this case, and turning now to Figure 3B, the target graphical element of the mech 301a, 301b may be thought of as “facing” the virtual camera 303, when, after the mech 301a, 301b has been applied to the axisymmetric surface of the target 3D virtual object 304 (at step S103), a centroid 305 of the mech’s 301a, 301b target graphical element lies on a reference plane 306 passing through an axis 307 of the target 3D virtual object 304 and the location 308 of the virtual camera 303, the reference plane 306 being parallel to the axis 307. Turning now to Figure 3C, the metadata 301c of mech 301b may indicate a set of reference pixels 301 d which correspond to the location of the target graphical element’s centroid. As seen in Figure 3C, part of the metadata 301c recites “CENTRE_1465”. As will be appreciated, the location of each pixel within the mech 301b may be defined in terms of a set of pixel coordinates (x, y). As such, metadata 301c may indicate the set of reference pixels 301 d by defining a target pixel coordinate (that is, x = 1465 pixels) corresponding to the centroid (“CENTRE”) of the target graphical element. To generate the virtual mock-up 302c (in which the target graphical element now faces the virtual camera), the processor of the computing system performs step S103 by applying mech 301b to an axisymmetric surface of the target 3D virtual object (a cylindrical face of a soft drinks can, for example). Subsequently, the processor performs step S104 by obtaining the set of reference pixels 301 d as indicated by metadata 301c (“CENTRE_1465”), and rotating the applied mech 301 b about an axis 307 of the target 3D virtual object’s axisymmetric surface such that the set of reference pixels 301 d faces the virtual camera 303. This is to say that the mech 301b is rotated along the axisymmetric surface until the set of reference pixels 301 d coincides with in the aforementioned reference plane 306. As will be appreciated, performing this rotation may involve determining a geometric / trigonometric relationship between the set of reference pixels 301 d (when the mech 301b is applied to the axisymmetric surface), the location 308 of the virtual camera 303, and the axis 307 of the target 3D virtual object 304. The skilled person knows how to determine such a geometric / trigonometric relationship, and so further detail is omitted for the sake of brevity. As mentioned previously, it may be the case that a group of mechs (within the same batch, or dispersed among different batches) possess an identical significant graphical element in an identical location. In this case, rather than specifying an identical pixel coordinate within each mech’s respective metadata, a 2D template image may be created. This 2D template image may be thought of as one set of metadata that is associated to each mech of the group in a one-to-many fashion. The 2D template image may possess the same significant (target) graphical element in the same location as that of each mech within the group. Turning now to Figure 3D, the mech 301b may be associated with a 2D template image 309. This 2D template image 309 may be thought of as at least part of the metadata associated with the mech 301b. Like with the mech 301b, the 2D template image 309 may be obtained via the input port of the computing system, or an internal memory thereof. As seen in Figure 3D, the mech 301b comprises a set of graphical elements, and this set may comprise a target graphical element (such as the logo, for example). As also seen in Figure 3D, the 2D template image 309 has at least the target graphical element in common with the mech 301b. This is to say that the 2D template image 309 has the same target graphical element as the mech 301b in the same image location as that of mech 301 b. To determine the target pixel coordinate (for indicating the set of reference pixels 309b), the processor of the computing device may create a bounding box 309a circumscribing the target graphical element. Subsequently, the processor determines a centroid of the bounding box 309a. This may be achieved by averaging the pixel coordinates of two opposing edges of the bounding box 309a. For example, in Figure 3D, the left hand edge of the bounding box 309a has a pixel coordinate of x = 683, and the right hand edge of the bounding box 309a has a pixel coordinate of x = 2303. The mean of these two pixel coordinates is x = 1465, which defines a set of reference pixels 309b passing through the centroid of the bounding box 309a. The pixel coordinate x = 1465 may then be used as the target pixel coordinate (as was the case in Figure 3C) for aligning the mech 301b with respect to the virtual camera (as discussed earlier herein). At step S105, the processor renders the final virtual scene from the point of view (POV) of the virtual camera. The final virtual scene may be rendered with any rendering software / technique / process the skilled person deems appropriate, such as scanline rendering, ray-casting, ray-tracing, rasterization, and the like. Typically, the software used to launch the 3D virtual environment has an in-built rendering pipeline. However, plug-in renderers may be obtained. For example, Cinema 4D possesses an in-built renderer, yet plug-in renderers such as Redshift may alternatively be used. In any case, once the step S105 is complete, an image of the rendered final virtual scene (that is, the virtual mock-up) is obtained. At step S106, the virtual mock-up is output for display. For example, the computing system may output the virtual mock-up via an output port. Examples of output ports include USB ports, Ethernet ® ports, Wi-Fi ® ports, Bluetooth ® ports, and the like. The virtual mock-up may be output to, say, a display screen for displaying the virtual mock-up, thereby allowing the graphic designer to perform quality assurance / control checks on the virtual mock-up prior to committing the mech to print. If immediate display is not required, then the virtual mock-up may be stored in a memory for later display. For example, the virtual mock-up may be transmitted via the output port to an external hard drive or solid state drive, or may be transmitted via an internal I / O bus to an internal ROM, hard drive or solid state drive. As mentioned previously, and turning now to Figure 4, the graphics rendering method 100 may be performed using a batch of mechs in order to produce virtual mock-ups for a whole product range in a quicker, less laborious, and more accurate way. In this case, step S101 may comprise obtaining a batch of 2D textures, each 2D texture having respective metadata associated therewith, and the remaining steps of the method 100 may be performed as an iterative loop, wherein a different 2D texture of the batch is used in each iteration. The batch of mechs may come in the form of a directory comprising multiple image files, each image file corresponding to a different mech of the batch. The directory may be compressed or uncompressed. In any case, at step S101, the computing system may obtain the directory via its input port or its internal memory. Once the directory of mechs is obtained, the remaining steps of the method 100 are then performed as an iterative loop. It should be noted that “the remaining steps” of the method 100 refer to at least steps S102 to S106, and optionally, in cases where embodiments of the present description comprise one or more of the other (optional) steps discussed elsewhere herein, those other (optional) steps of the method 100. As will be appreciated, the iterative loop is terminated when each mech of the directory has been used to generate a respective virtual mock-up. It should be noted that in the case where step S102 is performed manually, it may be that steps S103 to S106 are performed as an iterative loop. Given that each 2D textures of the batch is likely to be applied to the same target 3D virtual object (the same soft drinks can, for example), it may be that a user manually instantiates the target 3D virtual object and the virtual camera, and steps S103 to S106 may be performed automatically as an iterative loop, with each iteration involving the application of a different 2D texture of the batch to the same (manually instantiated) target 3D virtual object. In any case, embodiments of the present description seek to reduce the time and labour expenditure associated with generating virtual mock-ups of FMCG packaging, as well as to increase the accuracy thereof. This is achieved by providing an automated method of generating such virtual mock-ups, thereby eliminating (or at least reducing the amount of) human intervention. A notable aspect of the graphics rendering method 100 lies in its differences from conventional graphics rendering pipelines (as typically used in video game rendering, for example). In video game rendering, any adjustments to parts of a virtual object (such as colouring / shading parts of a video game character) are typically performed independently of the texturing process. However, in the present method 100, any adjustments to parameters of the initial virtual scene are based on metadata that is associated with the 2D texture. Further, in some embodiments of the present method 100, the 2D texture comprises metadata for selecting the target 3D virtual object, and scene data for positioning / orienting the target 3D virtual object relative to the virtual camera. This is to say that in such embodiments, the 2D texture’s metadata affect the composition of the virtual mock-up. This is different from conventional graphics rendering pipelines, in which the composition of the to-be-rendered image frame has already been determined (using telemetry data and a physics engine, for example) prior to the texturing step. Computer Program and Storage Medium It will be appreciated that the above methods may be carried out on conventional hardware (such as computing system 1 of Figure 5) suitably adapted as applicable by software instruction or by the inclusion or substitution of dedicated hardware. Thus the required adaptation to existing parts of a conventional equivalent device may be implemented in the form of a computer program product comprising processor implementable instructions stored on a non-transitory machine-readable medium such as a floppy disk, optical disk, hard disk, solid state disk, PROM, RAM, flash memory or any combination of these or other storage media, or realised in hardware as an ASIC (application specific integrated circuit) or an FPGA (field programmable gate array) or other configurable circuit suitable to use in adapting the conventional equivalent device. Separately, such a computer program may be transmitted via data signals on a network such as an Ethernet, a wireless network, the Internet, or any combination of these or other networks. In a specific (and entirely non-limiting) embodiment, the inventors conceived the computer program as an automation framework built primarily in Python, designed to run on top of Cinema 4D with the Redshift renderer. This framework enables the software to continuously monitor for new input files and drive rendering tasks without manual intervention. At the core of the solution, the inventors implemented a Python watcher service, using the watchdog library, which runs permanently in the background and observes designated directories on the studio’s QNAP servers (private cloud platform provided by QNAP systems, Inc.). When new artwork files (that is, mechs) appear, the service automatically reads and parses each file’s name (that is, metadata) to determine how the mech should be mapped to the target 3D virtual object (such as its rotation and alignment to the virtual camera, for example). The material settings of the target 3D virtual object are also determined using the parsed file name. The watcher then prepares configuration data in JSON format for the rendering process. In parallel, the inventors engineered modular Python components that interact directly with the Cinema 4D Python Software Development Kit. These components dynamically update 3D materials, apply scene parameters, and trigger Cinema 4D to launch in headless mode (that is, an automatic mode that does not feature a graphical user interface). Redshift then handles the rendering, using GPU acceleration on a dedicated high-performance workstation equipped with dual GPUs. To support scalable operation, the inventors developed orchestration logic in Python to coordinate the flow of mechs from the QNAP servers, monitored by the watcher service, to this single render workstation. Rather than relying on multiple render nodes, the current setup processes queued tasks on this single workstation. An SQLite database records details of each render for tracking, reporting, and performance optimisation, while automated post-processing routines written in Python composite the images and prepare them for delivery. Final outputs and notifications are pushed to users through the Slack API, allowing completed renders to be shared in real time. In short, the inventors developed an advanced, always-on automation layer that transforms graphics rendering software such as Cinema 4D or Blender from a manual design tool into a self-managing rendering pipeline. This advancement enables 2D graphic designers to generate their own high-quality renders without the traditional involvement of specialist 3D artworkers. Computing System In embodiments of the present description, a computing system 1 comprises a processor 10 and a memory 20, wherein the memory 20 has stored thereon processor-implementable instructions which, when executed by the processor 10, cause the processor 10 to perform embodiments of the above-described method 100. Turning now to Figure 5, as an example embodiment of the present invention, the circuitry of the computing system 1 may comprise the following components listed in turn below. The computing system 1 comprises a processing unit 10. The processing unit 10 may be a central processing unit (CPU) and / or a graphical processing unit (GPU). The CPU may be a single or multi core processor. The GPU may be physically separate to the CPU, or may be integrated with the CPU as a system on a chip (SoC). The processing unit 10 may be configured to execute processor-implementable instructions which cause it to carry out embodiments of the above-described method 100. The computing system 1 comprises a memory 20. The memory 20 may be a RAM, ROM, and / or the like. The RAM may be physically separate to the CPU and / GPU, or may be integrated therewith as part of an SoC. Alternatively or in addition, the memory 20 may be an external or internal hard drive, or an external or internal solid state drive. The memory 20 may be configured to store the processor-implementable instructions. The computing system 1 may comprise an A / V output port 30. The A / V output port 30 may enable the computing system 1 to transmit audio / visual outputs to one or more other devices / systems via wired / wireless communication means. Examples of the A / V output port 30 include USB ports, Ethernet ® ports, Wi-Fi ® ports, Bluetooth ® ports, and the like. The computing system 1 may comprise an input port 40. The input port 40 may enable the computing system 1 to receive data from one or more other devices / systems via wired / wireless communication means. Examples of the input port 40 include USB ports, Ethernet ® ports, Wi-Fi ® ports, Bluetooth ® ports, and the like. Components of the computing system 1 may be integrated within an SoC. Alternatively, where components of the computing system 1 are not integrated, such components may be connected either by a dedicated data link or via an I / O bus. It will be apparent to a person skilled in the art that variations in the operations of the above computing system 1 corresponding to the various embodiments of the computer-implemented method 100 as described and claimed herein are considered within the scope of the present invention. As will be appreciated, the computing system 1 may take on any form the skilled person deems appropriate. Examples of computing systems include terminal devices such as desktop computers, laptop computers, tablet computers, as well as network devices such as servers, cloud computing platforms and the like. Indeed, the computing system 1 may be a combination of terminal devices and / or network devices forming a distributed network. Conclusion The foregoing discussion discloses and describes merely exemplary embodiments of the present invention. As will be understood by those skilled in the art, the present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting of the scope of the invention, as well as other claims. The disclosure, including any readily discernible variants of the teachings herein, defines, in part, the scope of the foregoing claim terminology such that no inventive subject matter is dedicated to the public.

Claims

1. A graphics rendering method, comprising the steps of:obtaining a two-dimensional, 2D, texture that is to be applied to an axisymmetric surface of a target three-dimensional, 3D, virtual object, the 2D 5 texture having metadata associated therewith, the metadata indicating a set of reference pixels within the 2D texture;instantiating the target 3D virtual object and a virtual camera within a 3D virtual environment;applying the 2D texture to the target 3D virtual object’s surface to obtain 10 an initial virtual scene;adjusting, based on the metadata, one or more parameters of the initial virtual scene to obtain a final virtual scene, the adjusting step comprising rotating the 2D texture about an axis of the axisymmetric surface such that the set of reference pixels faces the virtual camera;15 rendering the final virtual scene from a point of view, POV, of the virtualcamera; andoutputting, for display, the rendered final virtual scene.

2. A graphics rendering method according to claim 1, wherein:the step of obtaining the 2D texture comprises obtaining a batch of 2D20 textures, each 2D texture having respective metadata associated therewith; and the remaining steps of the method are performed as an iterative loop, wherein a different 2D texture of the batch is used in each iteration.

3. A graphics rendering method according to claim 1 or claim 2, wherein: the metadata indicates one or more object properties; and25 the method comprises the step of obtaining, as the target 3D virtualobject, a 3D virtual object that possesses the indicated object properties.

4. A graphics rendering method according to claim 3, wherein the one or more object properties comprise at least one of an object type, an object size, an object shape, and a material.30 5. A graphics rendering method according to any preceding claim, wherein:18 1225the method comprises the step of obtaining scene data, the scene data indicating a predefined pose with which the target 3D virtual object is to be instantiated relative to the virtual camera; andthe instantiating step comprises instantiating the target 3D virtual object 5 with the predefined pose.

6. A graphics rendering method according to claim 5, wherein the metadata comprises the scene data.

7. A graphics rendering method according to any preceding claim, wherein: the metadata indicates a target colour; and10 the step of adjusting one or more parameters comprises adjusting acolour of one or more parts of the target 3D virtual object to match the target colour.

8. A graphics rendering method according to claim 7, wherein:the target 3D virtual object represents a container; and15 the one or more parts of the target 3D virtual object comprise at least oneof a virtual lid of the container, and a virtual contents of the container.

9. A graphics rendering method according to claim 7 or claim 8, wherein: the metadata comprises a label associated with the target colour;the method comprises the step of obtaining, from an entry within a lookup20 table, a set of colour values defining the target colour, the entry comprising a correspondence between the label and the set of colour values; andthe step of adjusting one or more parameters comprises adjusting a colour of one or more parts of the target 3D virtual object based on the set of colour values.25 10. A graphics rendering method according to any preceding claim, whereinthe metadata comprises a target pixel coordinate for indicating the set of reference pixels.

11. A graphics rendering method according to claim 10, wherein:18 1225the 2D texture comprises a set of graphical elements, the set comprising a target graphical element; andthe method comprises the steps of:obtaining a 2D template image having at least the target graphical 5 element in common with the 2D texture;creating a bounding box circumscribing the target graphical element of the 2D template image;determining a centroid of the bounding box; andidentifying, as the target pixel coordinate, a pixel coordinate of the 10 centroid of the bounding box.

12. A graphics rendering method according to any preceding claim, wherein at least part of the metadata is contained within a file name of the 2D texture.

13. A computer program comprising processor-implementable instructions which, when executed by a processor, cause the processor to perform the method 15 of any preceding claim.

14. A non-transitory computer-readable storage medium having stored thereon the computer program of claim 13.

15. A computing system, comprising a processor and a memory, the memory having stored thereon processor-implementable instructions which, when 20 executed by a processor, cause the computing device to perform the method of any of claims 1 to 12.A

Images